At 7:12 PM +0200 6/21/10, Peter Sylvester wrote: >>Exactly. Someone reading the *text* of RFC 5280 would see the components in >>left-to-right order; only those who read the non-normative dumps would see >>that they actually appear in the certificate in the correct right-to-left >>order. >> >Yes. >>No one would ever make the mistake of only reading the normative text, of >>course... >> >Or write RFCs with ambiguous normative part which cannot be understood >with the non-normative part. :-) >>--Paul Hoffman, Director >>--VPN Consortium >> >As I said in a previous message, the pb also occurs in a string form >like cn=Paul, O=VPN Consortium
Quite true. >I think one might want enhance the normative part of RFC 5280: > > The Name describes a hierarchical name composed of attributes, such > as country name, and corresponding values, such as US. The type of > the component AttributeValue is determined by the AttributeType; in > general it will be a DirectoryString. > >without other texts of X5xx this is also ambiguous. It doesn't say >how the hierarchy is encoded, etc for name constraints, what >is a subtree (prefix or suffix)? I may have overlooked something? You have overlooked the fact that this effort is to create a new document, not to update RFC 5280, which the PKIX group insists is readable enough. I am well-known for disagreeing, and that is why I think that this new document allowing constructs that are known security problems is a bad idea. --Paul Hoffman, Director --VPN Consortium _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
