Paul Hoffman wrote: > >> I reread David's comment as to why this would not be a problems client, due to CA adherence to uniform encoding of names, but you are right that we don't have an obvious way to address this apparent lack of conformance. > > We have no way of measuring "CA adherence to uniform encoding of names", do we? > Do we need uniform encoding of names or just consistent encoding? For example if a CA has decided to encode a name in a certain way it sticks to that encoding afterwards and never uses a different one. >> Russ & Tim, how would you like PKIX to proceed? We could wait for compliant implementations to appear (and we can try to encourage such), or we could downgrade the MUST to a SHOULD (but would the IESG be satisfied with this, given what I perceive as an overall desire to push for UTF8 support?). > > Another alternative is to scrap the rules altogether and go back to exact match, with a note proposing how to achieve interop (CAs should normalize before issuing). I think this would achieve our goals of interoperability more than either of two given above. > We already have this: CAs MUST encode the distinguished name in the subject field of a CA certificate identically to the distinguished name in the issuer field in certificates issued by that CA. If CAs use different encodings, implementations might fail to recognize name chains for paths that include this certificate. As a consequence, valid paths could be rejected. but this only covers the special case of subject and issuer fields of CAs and not CRLs, alternative names, name constraints etc. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson at drh-consultancy.co.uk, PGP key: via homepage.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.