Re: [pkix] Registration of a new sAN:otherName (NAIRealm)

[[e-mail] (Martin Rex)]

Jim Schaad wrote:
> 
> > >
> > > The section numbers are still the same. There is one change in content:
> > > It's not an IA5String but a UTF8String. The value in the cert needs to
> > > be compared with the NAI realm; and that realm is itself UTF-8. So to
> > > enable byte-by-byte comparison of non-ASCII realms, it's got to be
> > > UTF8String.
> > 
> > Uh-oh!
> > 
> > Comparisons for the purpose of authentication (or endpoint identification)
> > require clear and strict canonicalization and comparison rules (e.g. case-
> > sensitivity).
> 
> In this case the ramifications are being considered in the document
> describing NAIs (http://datatracker.ietf.org/doc/draft-ietf-radext-nai/) and
> we have been beating this issue around for a long time.


The draft you mention properly describes the underlying problem:

                                                  We RECOMMEND that the
   owner of the realm pre-provision all proxies with the "utf8-realm"
   portion of the NAI, along with the value returned from passing the
   "utf8-realm" to the ToAscii function.  This key-value pair can then
   be placed into the logical AAA routing table discussed above.  Having
   only one entity perform the ToAscii function ensures that the result
   returned by that function are considered as canonical by all other
   participants in a AAA network.


For the TLS extension ServerNameIndication this means, that
the certifcate (sAN-DNSName) *MUST* contain the A-label
(which is also necessary since it is limited to IA5String),
and the TLS extension SNI conveys the A-label, and the Server
does a binary matching of the server name conveyed through
TLSextSNI to the DNSName-sANs of his server certificates.

In the TLSextSNI scenario, the "only one entity" doing the ToAscii
is the TLS Client (more likely the application caller on top of it),
so that what the client will use to perform ServerEndpointIdentification
with the Server's Certificate is the exact same A-Label that is sent
in TLSextSNI and the exact same A-Label that the server uses for
choosing the most appropriate server certificate.


Admittedly, I haven't check this draft, but storing an
UTF8String in a certificate sAN is very likely to cause multiple
independent entities having to compare user input to that sAN,
and the trouble-maker that the above paragraph warns about.


-Martin