Re: [lamps] Proposed recharter text

[Russ Housley <[e-mail]>]

Ryan:

> Are there even two interoperable implementations of 5280?
> No, I think things will need to be stripped out.
> 
> 
> I agree, but I also worry it will open re-litigation of things that are de-facto, but not standardized, despite efforts to the contrary.
> 
> As a concrete example, the handling of extendedKeyUsage within intermediates is one of those issues that comes up every few years, but to not much progress. This debate goes back (as far as I can tell) to even the RFC 2459 work, where rough consensus and running code (at the time, and at the present) implemented something different. This is something that affects (2) with respect to the process of determining validity.
> 
> As an example of (3), consider the use of StringPrep with regards to DN handling/comparison, which itself was a concession to the failed flag-days of UTFString that earlier drafts had. Few implementations support it, even fewer support it as specified (due to the evolution of StringPrep and the Unicode tables). However, removing the normalization of DNs prior to comparison creates backwards compat issues that previous drafts prioritized avoiding, hence the complexity in the first place.

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.

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.  

Russ