Subject: Re: Changes to RFC2459

From: [email-masked] (Peter Gutmann)
Date: Tue, 6 Apr 1999 11:45:02 (NZST)

Stephen Kent <[email-masked]>
 
>If that's the argument, then we need to consider such a change based on at
>least these issues:
>
>       - under what circumstances would an EE use a self-signed cert? note
>        that PKIX always describes self-signed certs in the context of CAs,
>         not of EEs.  X.509 makes NO mention of self-signed certs
 
Internal use within an organisation is quite popular.  Give a J.Random Luser a
PKI toolkit and a "Get it going by the end of the week" and you'll end up with
self-signed certs everywhere ("We tried all the options, when we clicked on
this one everything started working.  We're doing X.509, right?").
 
>       - should PKIX change to accommodate current browser conventions that
>       are still ambiguous with regard to strict adherence to X.509?
 
I'd say we need to take current browser (and anything else) conventions into 
account.  Given the choice between working with existing implementations and 
claiming compliance to a standard, I'd say the majority of implementors will 
go with the former (I can't see too many implementors getting far telling 
their boss that "It breaks/exhibits undefined behaviour with any web browser, 
but it is compliant with <standard which boss has probably never heard of>").  
For an example of this thinking in action, look at the use of the 
email/rfc822Address in the DN vs the alt name - the major CA's are still 
putting it in the DN for compatibility with legacy stuff even though RFC 2459 
says you're not supposed to do this (I've had a report that one major vendors 
email software will crash when it finds a cert with the email address in the 
alt name instead of the DN, moving it into the DN fixes the problem.  Needless 
to say the people working with this have decided to go for compatibility 
rather than compliance (and I had to hack my code to selectively transport the 
email address across furlongs of extensions into the DN where it's not even
supposed to be)).
 
(Insert at this point the can-of-worms argument about "do we need to track
 every broken implementation out there?" - this is why I've been trying to
 document all the known problems in the style guide).
 
Peter.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 6 Apr 1999 10:15:33 -0400

Peter,

>this one everything started working.  We're doing X.509, right?").

Good example. I imagine such behavior will/does occur, but that does not
mean that our standards should encourage it via codification.

> document all the known problems in the style guide).

There are legitimate, differing views of whether a standard should attempt
to encompass existing practice of the sort you note, or should focus on
what the standard developers believe is "the right thing to do."  We have
examples in the IETF of both sorts of standards.  My preference is for the
latter, and the authors of RFC 2459 have taken this path in several
instances; you noted the name for for e-mail addresses above. This document
went through WG and IETF last call, and IESG approval, before being
published as an RFC.  Thus, it's rather late in the process to be
questioning this philosophical orientation. So far, I see no compelling
reason to change our direction in this regard.

Steve