Subject: Re: DN Encoding by UTF8String

From: [email-masked] (Peter Gutmann)
Date: Tue, 16 Dec 2003 00:22:09 +1300

Richard Levitte - VMS Whacker <[email-masked]> writes:

>OpenSSL provides a limit set of rules for comparing DNs: it does space
>normalization and a case insensitive compare for PrintableString, and case
>insensitive comparison for IA5String if the attribute type is emailAddress
>from pkcs#9.  For all other strings, a straight memcmp() is done.  Would you
>say we're going overkill?  

Hmm, I don't know if it's a good idea to encourage this sort of behaviour
(that is, apps that generate certs that require custom code in order to work).
Some years ago (after I snapped out of my X.520 delusion and switched to
memcmp()) a vendor complained that cryptlib was failing to find a cert with a
canonicalised name.  I told them to try the same thing with Netscape and MSIE,
and fairly soon afterwards (within a matter of days, I think) they had a
service release out that didn't try and modify names any more.

If cryptlib had still been using the X.520 comparison at that time, they might
have gone ahead and deployed a product that failed in the field once it was
exposed to other implementations.  Better to be strict and let darwinism do
its work.  If Netscape had been less lenient about accepting all kinds of
broken HTML, it wouldn't have encouraged the spread of apps that generate the
broken HTML.

>I'm not sure about that, since those special cases were added fairly
>recently, after we got some user complaint, and possibly after I had a run
>with the NIST PKI test bunch...

Are those test certs representative of real-world usage though?  There's a
danger of adding all sorts of special-case complexity that nothing (except
some artificial test vectors) ever exercise, which then comes back to bite you
later when there's some exploitable problem in there.  That's why I eventually
removed the X.520 comparison code, it's so complex (and complex in a system-
specific way, since you're dependant on different levels of i18n support on
different systems) that it'd be pretty much impossible to ever guarantee it
worked as required.  Guaranteeing the behaviour of memcmp() is much easier.

You could always enable a NIST-test-vector mode that uses ad-hoc fixups, and a
normal-use mode that uses memcmp().  In other words, make it explicit to the
user, through having to enable it via a #define or use a configure option,
that what they're doing is likely to cause problems down the track.

Peter.

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Mon, 15 Dec 2003 12:43:54 +0100 (CET)

In message <[email-masked]> on Tue, 16 Dec 2003 00:22:09 +1300, [email-masked] (Peter Gutmann) said:

pgut001> Richard Levitte - VMS Whacker <[email-masked]> writes:
pgut001> 
pgut001> >OpenSSL provides a limit set of rules for comparing DNs: it
pgut001> >does space normalization and a case insensitive compare for
pgut001> >PrintableString, and case insensitive comparison for
pgut001> >IA5String if the attribute type is emailAddress from pkcs#9.
pgut001> >For all other strings, a straight memcmp() is done.  Would
pgut001> >you say we're going overkill? 
pgut001> 
pgut001> Hmm, I don't know if it's a good idea to encourage this sort
pgut001> of behaviour (that is, apps that generate certs that require
pgut001> custom code in order to work).  Some years ago (after I
pgut001> snapped out of my X.520 delusion and switched to memcmp()) a
pgut001> vendor complained that cryptlib was failing to find a cert
pgut001> with a canonicalised name.  I told them to try the same thing
pgut001> with Netscape and MSIE, and fairly soon afterwards (within a
pgut001> matter of days, I think) they had a service release out that
pgut001> didn't try and modify names any more.
pgut001> 
pgut001> If cryptlib had still been using the X.520 comparison at that
pgut001> time, they might have gone ahead and deployed a product that
pgut001> failed in the field once it was exposed to other
pgut001> implementations.  Better to be strict and let darwinism do
pgut001> its work.  If Netscape had been less lenient about accepting
pgut001> all kinds of broken HTML, it wouldn't have encouraged the
pgut001> spread of apps that generate the broken HTML.

I understand your thoughts, and I agree that following the KISS
principle (does anyone need that explained?) is tempting.  However,
I'd say that your comparison between non-compliance with X.520
comparison rules and Netscape's boken HTML is flawed.  On one hand,
from the point of view of X.520, MSIE and Netscape are broken since
they don't follow the rules, and that's what you want to encourage.
On the other hand, Netscape's acceptance of some HTML was also broken
from the point of view of HTML, and you seem to want to discourage
that.  The conclusion is that you support breaking the rules in some
cases, while not in others.  That doesn't seem very consistent to
me...

Now from the point of view of "this makes sense", I can understand
your views, but I have to ask "from whose point of view?"  Is everyone
accepting Peter Gutmann as an authority?  I can accept that if that's
the common rule :-).

pgut001> >I'm not sure about that, since those special cases were
pgut001> >added fairly recently, after we got some user complaint, and
pgut001> >possibly after I had a run with the NIST PKI test bunch...
pgut001> 
pgut001> Are those test certs representative of real-world usage
pgut001> though?

Considering it's NIST we're talking about, I wouldn't be surprised if
there are some US gov. examples behind those tests...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

---

From: Tim Polk <[email-masked]>
Date: Mon, 15 Dec 2003 18:15:48 -0500

Name comparison is definitely a thorny problem.  The name comparison rules 
in RFC 2459 and 3280 were an attempt to establish a reasonable bar that 
current implementations already met, or could easily meet.

2459 and 3280 require white space compression and case-insensitive match 
for PrintableString because client implementations already met this 
standard.  It is also very easy - strings never get longer and a single 
pass is all one ever needs to prepare for the comparison.  (In fact you 
could probably compare in a single pass, normalizing as you go!)

This functionality is expected to be present, and is reflected by the 
content of existing certificates.  For example, the country code is 
sometimes uppercase and sometimes lower case.  Implementations that only 
performed case sensitive matching would not interpret "C=mx" and "C=MX" as 
equivalent.

On the other hand, normalization for more complex character sets is fraught 
with danger.  Strings can actually grow during this process, several passes 
may be required, etc...  Name comparison for these character sets was *not* 
"a reasonable bar that current implementations already met, or could easily 
meet."  So we required, at a minimum, support for a straight binary 
comparison but we permit an implementation to do more...

Some specific comments:

Peter noted:
 > I found out very quickly that one thing you never, ever do is
 > change the DN encoding once it's been created by the
 > originator

Basically, I would agree.  This is reflected by the RFC 3280 requirement 
that the encoding of an established CA's name be preserved when issuing CA 
certs.  Depending upon clients to perform string normalization accurately 
and consistently is risky.  No matter what they do (or don't) implement, 
preserving the encoding should provide dependable results.

Richard stated:
 > OpenSSL provides a limit set of rules for comparing DNs: it does
 > space normalization and a case insensitive compare for PrintableString,
 > and case insensitive comparison for IA5String if the attribute type is
 > emailAddress from pkcs#9. For all other strings, a straight memcmp()
 > is done. Would you say we're going overkill?

RFC 3280 is silent with respect to emailAddress.  RFC 3280 requires space 
normalization and a case insensitive compare for PrintableString.  For 
other types, a straight binary comparison is the minimum but more complex 
name comparison is permitted...

General observation #1:  implementing additional name comparison should not 
create *new* problems.  I see three cases.   Case 1: If the two strings 
match for binary comparison, then they will match afterwards.  (However, 
you may get the blue screen of death if the strings grow beyond the 
expected size and overwrite something it shouldn't!)  Case 2: Consider two 
strings that are a theoretical match but were encoded in different binary 
forms - if the name comparison rules detect the match, that's great; if not 
well you didn't make the situation worse.  Case 3: Only if two 
theoretically different string get munged by the normalization process and 
become inappropriately equivalent would you have a real problem.  Case 3 
failure seems the less likely than case 2, in my opinion...

General Observation #2:  False positives are more dangerous than false 
negatives... the one place name comparison can result in name 
constraints.  An inappropriate match for permitted subtrees could result in 
a false positive.  An inappropriate non-match for excluded subtrees could 
result in a false positive.  If you buy my theory that case 2 failure is 
more likely than case 3, that says you should use permitted subtrees where 
ever possible.  It also says that for either type of constraint, you should 
respect the encoding of the attributes by the issuer.

I don't think RFC 3280 is too much at odds with the OpenSSL implementation 
or Peter's guidance.  However, I should note that name comparison for 
directory strings encoded in UTF8STRING is a task we have been directed to 
tackle by the IESG.    As the name comparison work progresses in the IETF, 
the PKIX WG intends to have a document that describes the "right way" to 
perform such a comparison.

Thanks,

Tim Polk

At 12:43 PM 12/15/2003 +0100, Richard Levitte - VMS Whacker wrote:

>In message <[email-masked]> on Tue, 16 Dec 
>2003 00:22:09 +1300, [email-masked] (Peter Gutmann) said:
>

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Tue, 16 Dec 2003 00:43:38 +0100 (CET)

I just figured out a specific example where you might need to use
X.520 comparison rules (or at least the rules outlined by RFC3280).
At least with OpenSSL, it's possible to restrict what certificates
'openssl ca' can issue by configuring some parts of the requested
subject in the CSR match the same parts of the subject in the signing
CA certificate.  So to take Tim's example with 'C=MX' vs. 'C=mx', a CA
that is only allowed to issue certificates with C=MX, and does the
same kind of enforcement OpenSSL can do, it would have to be able to
match the country code regardless of case (and provided an encoding
where the case-insensitive matching rule applies).  I don't really see
a way out of the possibility of this happening.

Of course, there's the thought that it's better with a few false
negatives than a few false positives, as Tim pointed out...

-----

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 16 Dec 2003 01:21:18 +0000

Since this partly relates to OpenSSLs ASN1 handling I feel compelled to 
reply :-)

> a way out of the possibility of this happening.

Whilst that is true, OpenSSL's normal handling of DNs in the X509_NAME 
structure will preserve the original encoding. SSLeay did this also.

This effectively means that when a DN is copied when a certificate is 
issued the encoding is preserved between the CAs subject name and the 
issued certificates issuer name.

I've only ever come across two obscure certificates (other than in test 
suites) where two matching DNs did not have the same encoding.

IIRC one was a PrintableString case variation which would fit the 
RFC3280 comparison rules. The other changed the string type from 
PrintableString to T61 which would require the X520 comparison. Both 
were horribly broken in that they were supposed to be valid CA 
certificate but they didn't include a basicConstraints extension.

I'd be interested to know how common these (i.e. matching DNs with 
different encodings) are and how many people have come across them.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: "Marc Poulaud" <[email-masked]>
Date: Tue, 16 Dec 2003 16:29:19 -0000

Hi,

Appreciating this a PKI group, I wanted to know if there is any knowledge
of, or experience in IDPKC vs PKI. My intention is not to start a
religious war, but just understand if there is anything approaching a
consensus view. Also, does anybody know of any real/serious
implementations of IDPKC. I'll take private emails, if people feel it's
off topic.

Marc.
iSolve Ltd.

---

From: "Ambarish Malpani" <[email-masked]>
Date: Tue, 16 Dec 2003 11:58:33 -0800

There is a company in the SF Bay Area that is developing
products around it - Voltage Security (www.voltage.com).

Regards,
Ambarish

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Marc Poulaud
> Sent: Tuesday, December 16, 2003 8:29 AM
> To: [email-masked]
> Subject: IDPKC
> 
> 
> Hi,
> 
> Appreciating this a PKI group, I wanted to know if there is 
> any knowledge of, or experience in IDPKC vs PKI. My intention 
> is not to start a religious war, but just understand if there 
> is anything approaching a consensus view. Also, does anybody 
> know of any real/serious implementations of IDPKC. I'll take 
> private emails, if people feel it's off topic.
> 
> Marc.
> iSolve Ltd.
>

---

From: Masaki SHIMAOKA <[email-masked]>
Date: Wed, 17 Dec 2003 11:39:48 +0900

Tim,

> name comparison is permitted...

Basically I agree with your simple requirement as binary comparison, but
I do not prefer to permit other implementation.
When we have two implementations, one may make false-positive even
though other makes false-negative.
If we allow to some implementations, we MUST get to keep same result of
name-comparison.

Such my concept consents with your observation below, does not it?

> create *new* problems.  

> perform such a comparison.

I am pleased that PKIX is tackling such work.

Now I have one question.
How will son of RFC3280 address this UTF8Sting issue which is described
at clause 4.1.2.4 in RFC3280?

Thanks,
-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: +81 422 91 8498 (ext.3605)
Fax: +81 422 45 0536
e-mail: [email-masked]

---

From: Russ Housley <[email-masked]>
Date: Wed, 17 Dec 2003 10:45:42 -0500

It is not clear that a son-of-rfc3280 is needed.  I believe that an update 
addressing this one aspect of the document can be generated much more 
quickly than reopening the whole document.  I believe that speedy 
resolution is desirable for all concerned.

Russ

---

From: "Marco Casassa Mont" <[email-masked]>
Date: Wed, 17 Dec 2003 16:29:19 -0000

Hi.

HP Labs in Bristol have been working on IDPKC for the last 2 years. 

We call it identifier-based encryption (IBE). Please find links to HPL
documentation at the end of this e-mail.

HP Labs have a full working (and optimised) implementation of IBE
cryptographic libraries. We ran a trial based on this technology with
the NHS (the UK Health Care Service).

IBE (IDPKC) is a cryptographic schema. We believe it is more appropriate
to compare IBE with public key cryptography rather than PKI (e.g. a
public key infrastructure). 

Keith Harrison is our lead researcher on IBE cryptography: he can
provide more detailed information. Marc, if you want to contact him,
please let me know.

Best Regards,
Marco Casassa Mont

---

1. *** HPL documents about IBE cryptography  follow:
A. HPL-2003-25
Identity based authenticated key agreement protocols from pairings Liqun
Chen and Caroline Kudla
http://www.hpl.hp.com/techreports/2003/HPL-2003-25.html

B. HPL-2003-48
Multiple trusted authorities in identifier based cryptography from
pairings on elliptic curves Liqun Chen and Keith Harrison
http://www.hpl.hp.com/techreports/2003/HPL-2003-48.html

C. HPL-2003-18
Certification of public keys within an identity based system Liqun Chen,
Keith Harrison, Andrew Moss, David Soldera and Nigel Smart
http://www.hpl.hp.com/techreports/2003/HPL-2003-18.html

D. HPL-2003-17
Applications of multiple trust authorities in pairing based
cryptosystems Liqun Chen, Keith Harrison, David Soldera and Nigel Smart
http://www.hpl.hp.com/techreports/2003/HPL-2003-17.html

2. *** Information about the NHS trial can be found at:
A. A Flexible Role-based Secure Messaging Service: Exploiting IBE
Technology in a Health Care Trial 
http://www.hpl.hp.com/research/papers/2003/messaging.html
http://www.hpl.hp.com/techreports/2003/HPL-2003-21.html

B. A presentation that goes into more detail about the trial and the
applied technology  
http://www-uk.hpl.hp.com/people/mcm/Documents/Papers/TrustBus2003-RSM-mc
m.ppt

C. Another one that talks more about the "problem space":
The NHS as a Proving Ground for Cryptosystems 
http://www.hpl.hp.com/techreports/2003/HPL-2003-203.html

3. *** Additional information about IBE applications can be found at: A.
HPL-2002-243  The HP Time Vault Service: Innovating the way confidential
information is disclosed, at the right time - Casassa Mont, 
 Marco; Harrison, Keith; Sadler, Martin 
 http://www.hpl.hp.com/techreports/2002/HPL-2002-243.html

B. HPL-2003-49
Towards Accountable Management of Identity and Privacy:
Sticky Policies and Enforceable Tracing Services - Casassa 
Mont, Marco; Pearson, Siani; Bramhall, Pete 
http://www.hpl.hp.com/techreports/2003/HPL-2003-49.html
 
C. HPL-2003-101
IBE Applied to Privacy and Identity Management - Casassa
Mont, Marco; Bramhall, Pete 
http://www.hpl.hp.com/techreports/2003/HPL-2003-101.html

========================================================================
=
 Marco Casassa Mont
 Trusted Systems Laboratory                  +++++++++++++++++++++++++++
 Hewlett-Packard Laboratories                +++++++   _/        +++++++
 Filton Road, Stoke Gifford                  +++++    _/           +++++
 BRISTOL, BS34 8QZ, UK.                      ++++    _/_/_/  _/_/_/ ++++
                                             +++    _/  _/  _/  _/   +++
 Phone:  +44 117 312 8794 (direct)           ++++  _/  _/  _/_/_/   ++++
 Telnet: 312 8794                            +++++        _/       +++++
 Fax:    +44 117 312 9250                    +++++++     _/      +++++++
 Email:  [email-masked]           +++++++++++++++++++++++++++
========================================================================
=
        External HomePage: http://www-uk.hpl.hp.com/people/mcm/
========================================================================
=
    'All points of view are my own and not necessarily HP's as well'

> Sent: 16 December 2003 16:29
> To: [email-masked]
> Subject: IDPKC
> 
> 
> Hi,
>