At 11:29 AM -0500 11/17/09, Stephen Kent wrote: >This is primarily a client issue, right? Probably not. The relying party (the "client") needs to match names with what the identity that the CA (the "server"?) intended. So, it's an issue for both. I see nothing in RFC 5280 section 7 that indicates that the material is only for relying parties: it says "conforming implementations" many places. >Section 7.1 established a MUST for comparison of IDNs, based on the LDAP StringPrep profile. Clients need to perform comparisons, e.g., a CA Subject name to CA name in a CRL, etc. This depends on your view of what the comparison is made to. I think it is made to the CA's naming rules. > 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? >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.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.