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

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 12 May 2004 11:24:43 +0100

Wen-Cheng,

I think we agree on the theory parts. No need to repeat them.

The only disagreement is whether RFC 3280 should REQUIRE UTF-8 where
printable string is sufficient.

I think it should not do so. It should limit itself to a recommendation
(SHOULD)

RFC 3280 is an important profile, and while it may seem as a voluntary
profile for many, it is actually something that gets imposed as real
requirements for others.

Requiring UTF-8 causes interoperability problems, also among those who
have faithfully followed RFC 3280, and thus it is a bad requirement.

I also pledge that name encoding rollover certificates, as specified in
RFC 3280 is in error and thus has little merit in the real world.
Migration should thus be allowed in such pase that no name
encoding-rollover certificates are needed.

----
Except from this I agree that we should try to fix X.509 name matching
in RFC 3280 name constraining, which is a bug. But that is a separate
issue.

/Stefan

> -----Original Message-----
> From: Wen-Cheng Wang [mailto:[email-masked]]
> Sent: den 12 maj 2004 11:11
> To: Stefan Santesson; Stephen Kent; Santoni Adriano
> Cc: [email-masked]; [email-masked]; Steve Hanna
> 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: Wed, 12 May 2004 20:07:20 +0800

Stefan,

Although I personally prefer to remain it as a 'MUST', but if
PKIX WG majority decide to change it to be a 'SHOULD',
I will accept that.

Another compromise is not to REQUIRE CAs established
before the deadline to migrate to UTF8String encoding. That is,
if an old CA already use PrintableString encoding it can continue
to use PrintableString encoding. One day if the old CA need
perform to key rollover, it is STRONGLY RECOMMENDED (MUST?)
to take that opportunity to migrate to UTF8String encoding.
For CAs established after the deadline, it is STRONGLY
RECOMMENDED (MUST?) to adopt UTF8String encoding
from the beginning. By doing so, I believe that the infrastructure
will ultimately uniform the name encoding.

As for the deadline, since the deadline REQUIRED by RFC 3280
had already been past and it did not come true, a new deadline will
be needed.

Wen-Cheng Wang