Re: [lamps] Proposed recharter text

[Ryan Sleevi <[e-mail]>]

On Thu, Feb 11, 2021 at 2:20 PM Russ Housley <[e-mail]> wrote:

> I do not agree with your characterization of the extendedKeyUsage concern,
> but I do agree that implementation in CA certificates does not match RFC
> 5280.  I proposed a solution to this situation some years ago, but
> implementers did not want to change.  In addition, RFC 5280 is a profile of
> X.509, so RFC 5280 should not specify a different behavior than X.509.  I
> continue to believe that a different OID should be used if a different
> behavior is desired.
>

Russ,

Thanks for helping emphasize the points I'm making, on both points.
2459/3280/5280 emerged in parallel to existing implementations of "PKI
things", whether it be SSLeay, 'the code that would become" Mozilla NSS,
the "IE code that became CryptoAPI", etc. Rich can speak better to/for
OpenSSL, but I would suggest that, for a number of implementations of
"certificate things", the goal was not "implement X.509v3", nor "implement
5280", but "implement enough for TLS". While it's true that there used to
be more diversity of implementations that purely targeted 5280 (and the
abstract goals), and certainly Microsoft's efforts on CryptoAPI and
Sun-Oracle's on Java eventually circled to "implement everything spec'd in
5280", the reality is that much of the running code does not and has not
had 5280 as the target for interoperability.

This is to the point (2). Efforts during the 2459/3280/5280 work each tried
to bring this issue re: EKUs, and resolve, and the reaction you raise now
was much the same then: "If you want this, you should do something
different" - yet the implementers had already implemented their logic, and
it was the immovable object of objections like you raise here that
ultimately lead these behaviors not to appear in the specs, yet still lead
to all sorts of surprising interactions and potential risks (e.g. Flame,
which was both in part possible and mitigated due to this EKU chaining
behaviour).


> Internationalization is hard. This was the outcome of many very long
> discussions. This is an area where RFC 5280 could be improved but
> stringPrep was the advice from the ART Area folks at the time.
>

This isn't strictly about internationalization, though. This was about
trying to bend over backwards with existing certificates/PKIs, while trying
to get stuff to use the internationalization-capable "new" features. This
is readily clear through RFC 2459's language, which 3280 inherited, which
set that migration date of December 31, 2003 - but tried to maintain
backwards compat.

5280 significantly altered this with the StringPrep, but still, my point
was that this "feature" is ***only*** relevant if you're:
a) Trying to use The Directory to look up certificates, and thus needing to
use DAP/LDAP
b) Trying to ensure all (new) certificates conform to a particular profile,
without requiring the replacement of existing root/intermediate
certificates.

My point in highlighting this was that twenty years later, we know (a) is
largely not true in a "PKIX" sense, even if it remains true for a number of
enterprise PKIs. Equally, we know that (b) was a giant own-goal to the goal
it was trying to achieve, because rather than encouraging transition,
implementations just kept the non-UTF8String approaches around.

So when revisiting 5280, and asking in the context of (3), it's reasonable
to ask "Is this feature a product of design assumptions re: The Directory,
and thus suitable to cut, or is this feature essential simply because it's
used in a non-Internet-wide-PKI-sense". And, in the context of (1), where
this varies greatly, "Does this feature prevent us from progressing to
Internet Standard". Concretely, an alternative would be to simply do what
other PKI communities have done (including the CA/B Forum), and which
reflect the algorithm of 2459/3280, which is to say "memcmp() is the only
comparison function", which works as equally fine for UTF8String as it does
for PrintableString.

Again, I'm not particularly excited to revisit all of this, precisely
because this is a tremendous amount of effort. As it relates, however, to
the discussion relevant to the charter, I'm suggesting that if folks aren't
looking for multiple years of debate and relitigation, then the draft
charter should provide better guidance for what is in scope and out of
scope, so that we can resolve such discussions as early as possible, before
they suck up years of effort and energy.

The last time the IETF touched these docs, PKI was the old-Blockchain, and
the excitement led to everything and the kitchen sink being included. Do we
still pretend that's the case, in order to progress far enough to make the
"minor" adjustments may not (and may never) reflect implementations, or do
we accept the Internet has changed since 2005, and try to adjust how
implementations have evolved, even if that will take us years?