Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in encodingRDNs

From: Tom Gindin <[email-masked]>
Date: Thu, 13 May 2004 20:07:55 -0400

Wan-Cheng:

        The bottom line of the statements you have quoted is that some 
fully RFC 3280-compliant RP implementations will treat all rollover 
certificates as self-issued, some will treat no rollover certificates as 
self-issued, and some will treat many rollover certificates as self-issued 
but some as not.  Thus, whether a given rollover certificate is deemed to 
be self-issued by a compliant RP is implementation dependent - probably a 
worse situation than "rollover certificates are not interpreted as 
self-issued".
        IMHO, it would really help if we had a list of CA's who encode 
their current DN's using BMPString with characters in the surrogate range, 
and whether they are compliant to UTF-16 or not, and a list of CA's who 
encode their current DN's using T61String.  Most other character 
conversions under the ASN.1 standard are simple algorithms.

                Tom Gindin

P.S. -  The above opinions are mine, and not necessarily those of my 
employer.

"Wen-Cheng Wang" <[email-masked]>
Sent by: [email-masked]
05/12/2004 05:10 AM

        To:     "Stefan Santesson" <[email-masked]>, "Stephen Kent" <[email-masked]>, 
"Santoni Adriano" <[email-masked]>
        cc:     <[email-masked]>, <[email-masked]>, "Steve Hanna" 
<[email-masked]>
        Subject:        Re: R: I: R: RFC3280: doubt on the use of UTF8String in encodingRDNs

> Yes, you can do a lot of cool things in theory.
>
> The cruel truth is that your name encoding roll-over certs (e.g.
> CA1-CA1-p-u-cert) is not self issued according to RFC 3280.

That is why I said that the definition of self-issued certificates in RFC
3280 (or maybe its definition in the X.509 standard itself) should
be revised or be clarified in son-of-3280 (or in an amendment of
the X.509 standard as well).

>
> RFC 3280 section 6.1:
>    A certificate is self-issued if the DNs that appear in the subject
>    and issuer fields are identical and are not empty.
>
> RFC 3280 section 4.1.2.4:
>       (a)  attribute values encoded in different types (e.g.,
>       PrintableString and BMPString) MAY be assumed to represent
>       different strings;

Remenber that RFC 3280 section 4.1.2.4 also said:

   Implementations of this profile are permitted to use the comparison
   algorithm defined in the X.500 series.

In that respect, you can not said that name rollover certificates are not
self-issued.

>
> So in current implementations of RFC 3280, many valid certificates will
> fail after introduction of name rollover certs in the chain, because
> path validation will not treat them as self-issued.

I admit that most CURRENT implementations of RFC 3280 path
validation will fail to treat name rollover certificates as self-issued, 
but
it does not mean that we should not recommend FUTURE revisions
of those implementations and new implementations to treat them as
self-issued.

>
> Further, the name constraint problem persists, adds to this but also
> exist regardless of this problem.
>
> RFC 3280 section 4.2.1.11
>    When applying restrictions of the form directoryName, an
>    implementation MUST compare DN attributes.  At a minimum,
>    implementations MUST perform the DN comparison rules specified in
>    Section 4.1.2.4.

That is why I said RFC 3280 path validation algorithm should also be
revised.

>
> Fixing next version of RFC 3280 to include better name matching rules is
> a good thing but far from enough to take care of real problems with
> current infrastructure.

Fixing next version of RFC 3280 does not magically take care of real
problems with current infrastructure, but it encourge current 
infrastructure
to migrate to solve the problems.

>
> We have to try to keep in mind what we make all this hassle for!!
>
> This is NOT about whether we should use UTF-8 or not to accommodate
> complex character sets!! This is about what we are prepared to do to
> make sure NOTHING is encoded as PrintableString WHEN PrintableString is
> sufficient.
>
> This old transition rule was created in RFC 2459 before the modern path
> validation algorithm was invented and before self-issued certificates
> was a special case.

That does not mean that name rollover certificates can not solve the
mixed name-encoding  problem.

>
> Let's just admit that we overlooked this issue when we created RFC 3280
> and reshaped path validation. It was an understandable human error,
> which lead to a defect.

Yes, RFC 3280 indeed overlooked this issue. That is why it should be
revised.

>
> So let's then also admit that REQUIRING UTF-8 when printableString is
> sufficient, is not a very good idea when all practical matters are
> measured, and that it never should have made it to more than a
> RECOMMENDATION.

Isn't it the IETF policy to encourge all new implementations to migrate
to support UTF-8? The philosophy is that if one encoding is sufficient to
cover universal characters, why should we recommend two?

>
> Whatever we say here, this is a requirement that many implementers will
> have to ignore for a many years to come.

Conformance to any IETF RFC is all voluntary. No one can enfoce any
implementer for that if the implementer chooses to ignore the requirement
or recommendation of any IETF RFC. RFC 3280 might not have the
power to enforce all implementation to migrate to UTF-8 encoding.
However, as an IETF RFC, it definitely has a great effect. At least, I
see more and more applications can correctly handle certificates with
named in UTF-8 encoding. Therefore, I prefer to see son-of-3280 to
continue requiring conformant implementations to migrate to UTF-8
encoding.

Wen-Cheng Wang

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Fri, 14 May 2004 15:20:42 +0800

Tom,

> worse situation than "rollover certificates are not interpreted as
Yes, the current situation is that some RP implementations will treat
name rollover certificates (if any) as self-issued but some will not.
The root cause of inconsistency on interpreting self-issued certificates
among different implementations is the deficiency of name matching
rules in RFC 3280 and the X.509 standard. There can be a debate
on whether name rollover certificates should be interpreted as
self-issued or not. However, the current situation is the current
situation. The situation will not change unless the deficiency in
RFC 3280 and the X.509 standard is mended and hopefully
all RP implementations will migrate to  a consistent way of
interpreting self-issued certificates. The point is that even if we finally
agree that  "name rollover certificates should not interpreted as
self-issued", we still need to revise or amend  RFC 3280 and the
X.509 standard to make it clear.

> conversions under the ASN.1 standard are simple algorithms.
That might be an interesting investigation, but I do not think it will
help for resolving the inconsistency on interpreting self-issued
certificates. As I said above, the root cause is the deficiency of
name matching rules. Paying more attention to mend the deficiency
might be more helpful. If we have name matching rules that can take
care of name string in different character sets and/or in different
encoding, it will not only resolve the inconsistency on interpreting
self-issued certificates but also will reduce the needs of issuing
name rollover certificates.

Wen-Cheng Wang

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 14 May 2004 10:48:36 +0200

Tom Gindin wrote:

>their current DN's using BMPString 
>
Probably not many. This might have happened mostly with some CA having 
left a few requests using BMPString slip in.

>with characters in the surrogate range, 
>and whether they are compliant to UTF-16 or not, 
>
I certainly believe nobody did that. Is it required to precise that 
UTF8String is the only reliable way to encode surrogate/non BMP unicode 
characters ?

>and a list of CA's who 
>encode their current DN's using T61String.
>
The bug database of Mozilla enables to localize some of them, for example :
E = [email-masked], CN = neam Gesellschaft für Kommunikationslösungen mbH, 
OU = Security, O = neam CA, C = DE (this is in T61)

Most of those CAs are clearly not used for certificates that were 
actually intended to be publicly distributed (thus did not care too much 
about interoperability problems).

There is in that database a very interesting case of a CA with a UTF8 
name that issued a cert with a BMPString name :
You can download that from this link :
http://bugzilla.mozilla.org/attachment.cgi?id=109214&action=view

I think this certainly demonstrate a CA wishing to switch to the use of 
UTF8String, but that unfortunately also allowed it's software to issue 
BMPString when it allowed "unicode" in certificate names.
Implementers should beware of such situations.

>  Most other character