Subject: R: R: I: R: RFC3280: doubt on the use of UTF8String in encoding R DNs

From: Santoni Adriano <[email-masked]>
Date: Thu, 6 May 2004 08:42:31 +0200

Thanks to both Kent and Santesson for their comments.

Of course, it was not my intention to argument against the adoption of
UTF8String. On the contrary, I am personally convinced that is (would be?
will be?) a good and sensible initiative.

And of course, my previous message was provocative, as I am perfectly aware
that "if we were never able to call for a change in how things are done when
we update a standard, then we could never make any changes", and that "IETF
standards are voluntary. failure to comply is not punishable"; I dare to say
that is quite obvious to almost anyone in the industry.

Actually, it is not just the compliance to IETF standards which is
voluntary. It is also the degree of compliance and the very meaning of
compliance, to be voluntary. It is just too easy to claim compliance to any
standard. What if RFCs had an incipit saying something like <<Failure to
comply to any of the mandatory features herein described shall be equivalent
to not being compliant at all with this standard. It is prohibited to claim
compliance with this standard unless each and all of the mandatory features
herein described are fully obeyed to>>. Well, I know I am being too candid
with this idea...

However, it would be nice to see a meaningful number of CAs discuss this
topic and try to decide on the way to go. Should we try to switch to
UTF8String during the current year? Or in the next year? Or just leave any
CA do what it likes, regardless of any "MUST" or deadlines that happen to
show up in RFCs? This mailing list should be the right place to discuss
that, but it seems the topic is not very interesting...

Adriano

-----Messaggio originale-----
Da: Stefan Santesson [mailto:[email-masked]] 
Inviato: giovedì 6 maggio 2004 2.18
A: Stephen Kent; Santoni Adriano
Cc: [email-masked]; [email-masked]
Oggetto: RE: R: I: R: RFC3280: doubt on the use of UTF8String in encoding
RDNs

Steve,

There is one unfortunate side effect that makes this requirement worse than
other evolutions of standards.

It is almost never feasible to replace all certificates in a hierarchy at
once. This means that you over time will have a mixed environment where e.g.
the same organization name will exist in different encoding in many places
of your hierarchy.

It will then be virtually impossible to apply name constraining in such
environment because RFC 3280 does not mandate the full X.500 name matching
rules and a client may subsequently decide that names with different
encoding is a no-match.

This seams to be an unsolvable problem that, looking in the mirror, is
inadequately addressed and shouldn't have passed in its current form. In
fact it is probably a defect that needs to be addressed in sonOfRfc3280 in
one way or the other.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Stephen Kent
> Sent: den 5 maj 2004 13:36
> To: Santoni Adriano
> Cc: [email-masked]'; [email-masked]
> Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
encoding
> RDNs
> 
> 
> At 9:54 AM +0200 4/23/04, Santoni Adriano wrote:
> >A rule that is "at odds with reality" should not be expressed in
terms of
> >MUST, but rather in terms of SHOULD. I wonder how it came that RFC
3280
> >reached the status of an official IETF standard, if it contains one
or
> more
> >areas that are "at odds with reality".
> >
> >I suppose the answer is one of these:
> >- RFC 3280 does not really contain areas that are "at odds with
reality"
> -
> >it's just that we do not understand them;
> 
> RFC 3280 established a requirement for a change in how DNs are 
> encoded, for a future point in time. Thus, at the time the RFC was 
> published as a standard of course it did not match "reality." since it 
> was calling for a change.  By the way, this change was not the idea of 
> the PKIX WG but rather is consistent with the overall IETF mandate to 
> better accommodate character sets for a wide range of languages.
> 
> >- containing areas that are "at odds with reality" is not an obstacle
to
> >becoming a standard;
> 
> Think of the implication of your comment. if we were never able to 
> call for a change in how things are done when we update a standard, 
> then we could never make any changes.  obviously this would be unduly 
> limiting.
> 
> >- expressions like "MUST" in IETF standard are really to be taken as
mere
> >suggestions;
> 
> IETF standards are voluntary. failure to comply is not punishable :-)
> 
> >- nobody really cares.
> 
> one might say that in environments where a few vendors or service 
> providers control a significant market share, their deviation from 
> standards, or failure to accommodate changes in standards, can have 
> profound impacts.
> 
> Steve

*******************Internet Email Confidentiality Footer******************* 
Qualsiasi utilizzo non autorizzato del presente messaggio nonche' dei suoi
allegati e' vietato e potrebbe costituire reato. Se lei ha ricevuto
erroneamente il presente messaggio, Le saremmo grati se, via e-mail, ce ne
comunicasse la ricezione e provvedesse alla distruzione del messaggio stesso
e dei suoi eventuali allegati. Le dichiarazioni contenute nel presente
messaggio nonche' nei suoi eventuali allegati devono essere attribuite
esclusivamente al mittente e non possono essere considerate come trasmesse o
autorizzate da SIA S.p.A.; le medesime dichiarazioni non impegnano SIA
S.p.A. nei confronti del destinatario o di terzi. 
SIA S.p.A. non si assume alcuna responsabilita' per eventuali
intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 

Any unauthorized use of this e-mail or any of its attachments is prohibited
and could constitute an offence. If you are not the intended addressee
please advise immediately the sender by using the reply facility in your
e-mail software and destroy the message and its attachments. The statements
and opinions expressed in this e-mail message are those of the author of the
message and do not necessarily represent those of SIA. Besides, The contents
of this message shall be understood as neither given nor endorsed by SIA
S.p.A.. 
SIA S.p.A. does not accept liability for corruption, interception or
amendment, if any, or the consequences thereof.