Re: PKIX-1 - use of UTF8

[John_Wray@xxxxxxxx]

Tim Polk <wpolk@nist.gov> wrote:

>Consider the same chain CA0, CA1, CA2, and EE.  Let {x,y} mean a
>certificate issued by x with subject y.
>
>Case 1:  CA0 "switches" to UTF8
>
>CA0 issues two certificates {CA0(T61),CA0(UTF8)} and {CA0(UTF8),
>CA0(T61)}.  New users trusting CA0(UTF8) can now trust old paths;
>old users trusting CA0(T61).
>
>Case 2: CA2 "switches" to UTF8
>
>CA2 issues two certificates {CA2(T61),CA2(UTF8)} and {CA2(UTF8),
>CA2(T61)}.  The path from CA0 to the EE cert is still valid.
>
>CA2 requests a new cert from CA1 for its UTF8 encoded name.
>CA1 issues the cert {CA1,CA2(UTF8)} with the UTF8 name constraints.
>
>At this point, the path from CA0 to the EE certificate does not use ANY
>of the new certificates.
>
>The EE cert expires.  CA2 issues {CA2(UTF8), EE(UTF8)}.
>
>There are two paths from CA0 to the EE certificate.  The first path is
>the "old" path with the name rollover certificate.  It is NOT VALID
>becasue of the name constraints.  The second path uses {CA1,CA2(UTF8)}
>and does not use the name rollover certificate.  This path satisfies
>the name constraints and is valid.

This is basically saying that whenever the first entity changes over to
UTF8, everything above it in a trust chain will have to change over
immediately in order for the new name can be recognized.  Since CA2 doesn't
know which trust chain a verifier is going to want to use when trying to
determine EE's key, it'll have to request new certs from every CA that has
issued one for it, not just from CA1. That's not a migration - that's a
stampede :-)

How do the CAs know that a name encoded in T61 is the same as a name
encoded
in UTF8 (so they will just simply OK the new certificate request)?  Is this
expected to require manual approval, or is it automatic?  If it's
automatic,
it means they can do codeset conversion, so why not build that same ability
now into end-systems and avoid the requirement for a sudden switch-over?

John