Subject: RE: UTF-8 encoding after December 31 2003

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 26 Jan 2004 14:18:33 -0800

Hi Stefan,

You have another problem with name rollover with policy constraint
extension processing and self issued certificates.

4.1.2.4 of RFC3280

"(a) attribute values encoded in different types (e.g., PrintableString
and BMPString) MAY be assumed to represent different strings;

 (b) attribute values in types other than PrintableString are case
sensitive (this permits matching of attribute values as binary objects);

And in 6.1.4

"(h)  If the issuer and subject names are not identical:

(1)  If explicit_policy is not 0, decrement explicit_policy by 1.

(2)  If policy_mapping is not 0, decrement policy_mapping by 1.

(3)  If inhibit_any-policy is not 0, decrement inhibit_any- policy by
1."

So an implementation interpreting the two values as different under
clause (a) above will decrement the policy constraints coulters with
name rollover when there is an encoding change.

Also encoding "CA" and "cA" in two separate rollover CA certificates as
printable sting will not decrement the counters but encoding the same
stings in UTF-8 will lead to different policy constraints path length
results with name rollover under clause (b) above.

Trevor

________________________________

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,

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: "Stefan Santesson" <[email-masked]>
Date: Mon, 26 Jan 2004 21:01:56 -0000

Jim

I hope you are right.

However I have read it back and forth numerous of times and I have not
been able to conclude for sure that you are right even though I have
made my best efforts to do so.

My strict reading is that first you must violate RFC 3280 and issue
certs with old encoded issuer names, THEN you are allowed to use the
exception rule to issue a matching CA cert.

I would like to have it stated the other way around.

I.e:

A CA MUST issue certificates with an Issuer field that match the subject
name of the CA certificate it has selected for its operation, regardless
of encoding. (or similar wording).

Is my English knowledge fooling me here or is there someone lese having
problem with RFC 3280?

/Stefan

From: Jim Schaad [mailto:[email-masked]] 
Sent: den 26 januari 2004 21:32
To: Stefan Santesson; [email-masked]
Subject: RE: UTF-8 encoding after December 31 2003

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,

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

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

	      contents of the issuer field in all certificates issued by
the

	 

	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

	      different strings;"

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

	Stefan Santesson

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 30 Jan 2004 16:40:54 -0000

Due to the silence on this thread I have to restate the question and ask
for WG chairs and RFC 3280 editors' clarification:

I'm asking for clarification on how to interpret the exceptions to UTF-8
encoding after December 31, 2003 stated in 4.1.2.4.

Case:

I have a CA (root or intermediate) with an operational CA certificate
that is valid far into the future e.g. 2010. This CA certificate has
Issuer and subject name in old encoding.

Question: 

Is it OK to issue certificates from that CA that has an Issuer name
matching the subject name of the existing CA certificate (in old
encoding)?

/Stefan

On Behalf Of Jim Schaad

Stefan,

jim

	-----Original Message-----

	All,

	The situation:

	December 31, 2003.

	   follows:

	 

	 

	The issue:

	Question 1)

	Question 2)

	4.1.2.4 states

	      different strings;"

	 

	Stefan Santesson