Re: [pkix] way forward for 5280

[Stephen Kent <kent at bbn.com>]

At 9:07 AM -0800 11/17/09, Paul Hoffman wrote:
> 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.

I was thinking that an RP needs to match subject and issuer names in 
certs during path validation, and sometimes with names in CRLs. Also, 
an RP may have to perform a match with some local access control 
info, which might have come from an LDAP directory, hence the desire 
to use the LDAP string prep algorithm.

I think we agree that both CAs and RPs want to have names compared on 
a consistent basis, even though CAs are putting the names into 
structures and RPs are generally consuming the names and doing the 
comparisons.

>  >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'm not so clear on this point. Could you elaborate?

>  >  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?

Fair point.

>  >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.

True, but it also may not be seen to support the IETF (IESG/IAB) 
agenda of promoting use of UFT8 via our standards. That's why I asked 
Tim and Russ for their views on this issue.

Steve