Subject: UTF-8 encoding after December 31 2003

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 26 Jan 2004 17:22:33 -0000

All,

I have a problem with the UTF-8 requirements in RFC 3280 after December
31, and would appreciate guidance on interpretation of RFC 3280 as well
as other implementers view on this.

The situation:

Conforming CA:s must encode attributes of DirectotyString types as UTF-8
after 

December 31, 2003.

Exceptions are stated in RFC 3280 (section 4.1.2.4):

   Exceptions to the December 31, 2003 UTF8 encoding requirements are as

   follows:

      (a)  CAs MAY issue "name rollover" certificates to support an

      orderly migration to UTF8String encoding.  Such certificates would

      include the CA's UTF8String encoded name as issuer and and the old

      name encoding as subject, or vice-versa.

      (b)  As stated in section 4.1.2.6, the subject field MUST be

      populated with a non-empty distinguished name matching the

      contents of the issuer field in all certificates issued by the

      subject CA regardless of encoding.

My interpretation of this is:

a) only applies for self issued certificates with the same CA name as
issuer and subject (but in different encodings). Introducing such name
roll-over certificates extend the certificate chain and may be
problematic since it may break both naming and path length constraints
expressed by chaining CAs.

b) seams to be a catch 22. You can populate the subject field with old
encoding to match old encoded issuer names in descending certificates,
but since no descending CA can populate the issuer field with old
encoding it doesn't really apply.

The issue:

There seems to be a problem with practical reality here in case the
interpretation above is correct.

Question 1)

What if I have a Root CA valid to 2020 with subject and issuer name in
old encoding?

Can that Root CA issue an intermediary CA certificate with the issuer
field in old encoding, matching the subject field of the current root CA
Certificate?

Question 2)

What if I have a CA with a current operating CA certificate that expires
2006. Can this CA issue certificates after December 31, with the issuer
name in old encoding, matching the encoding of the current CA
certificate until it expires, or must this CA change its name and have
its CA certificate renewed before December 31?

If RFC 3280 prevents operating CAs to issue certificates with the issuer
field matching the CA:s current certificate, until it expires, then we
face a huge legacy problem. Especially since name matching for different
encoding types are not required.

4.1.2.4 states

"(a)  attribute values encoded in different types (e.g.,

      PrintableString and BMPString) MAY be assumed to represent

      different strings;"

If my concerns are wrong and the issuing such certificates is allowed,
then this needs to be clarified.

Stefan Santesson

Program Manager, Windows Security

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 26 Jan 2004 12:31:31 -0800

Stefan,
 
I don't read (b) in the same way as you do.  I read this as saying if a
CA has a certificate with a non-UTF8 encoded subject name, then the
issuer name in all certificates it issues MUST be the non-UTF8 subject
name of the CA.  This means you don't need to update the CA certificate,
but that all new certificates issued by the CA must be using UTF8
strings.
 
jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Monday, January 26, 2004 9:23 AM
To: [email-masked]
Subject: UTF-8 encoding after December 31 2003

All,

The situation:

December 31, 2003.

   follows:

 

 

The issue:

Question 1)

Question 2)

4.1.2.4 states

      different strings;"

 

Stefan Santesson