Subject: Re: RFC2253 e-mail address

From: Michael Ströder <[email-masked]>
Date: Wed, 14 Nov 2001 13:18:35 +0100

Anders Rundgren wrote:
> 
> In 2253 there is a paragraph 2.4 saying that if there are no
> Attribute value defined for it (like e-email) it should be
> outputted as 1.2.840.113549.1.9.1=#AD45FE
> I.e. given as HEX!
> 
> Is this a correct interpretation?  Yeck!

You're mixing attribute *type* with attribute *value* here. Reread
the paragraph. It only talks about string representation of
attribute values. E-Mail addresses are you usually IA5String and
therefore indeed have a string representation.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Mon, 12 Nov 2001 21:42:58 +0100

Anders Rundgren wrote:
> 
> It is true that XML DSIG allows a number of ways to identify the signing
> key.  Some are 100% safe but some are not.  What the majority will use
> is still to be seen.

Which translates to "XML-DSIG - yet another PKI standard too
complicated to be ever implemented completely and correctly."

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Sun, 11 Nov 2001 16:05:03 +0100

Anders Rundgren wrote:
> 
> Although e-mail addresses are decprecated in Subject fields, this
> habit will probably not cease.  During our XML Dsig interperability testing
> we have found "dialects" in how rfc822 names are written symbolically.
> 
> Some (MS) use E=x while others like SUN use EMAIL=x
> 
> And I can't find the RFC!  Which one is it?
> 
> No matter what the answer is, this will be an interoperability issue

Yes, it is an interoperability issue. But the PKIX lib/application
used is responsible for that. An application should never rely on
attribute type name strings being used. It should handle the OID of
the attribute type directly.

Further I'd suggest to use LDAP string representation of DNs like
described in RFC 2253 (e.g. OpenSSL does it since some time if
explicitly requested). Note: The string representation will not be
reversible since the knowledge about the used character set of a
string (encoded as different ASN.1 string types) is lost and the
attribute type name is undefined too (OIDs could be used instead).

Ciao, Michael.

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 14 Nov 2001 13:12:23 +0100

Hi,

I.e. given as HEX!

Anders

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Mon, 12 Nov 2001 15:52:20 +0100

Anders Rundgren wrote:

> BTW, neither Email= nor E= are to be found in the referred RFC.
> I guess one should use the OID for that one as you suggest.

Anders, it sound like you still haven't realised this OID has been created by RSA
(it's in the RSA OID arc) and was first described in the PKCS#9 document.

The name RSA gave it in pkcs#9 is emailAddress.

> To only use OIDs is an option but looks awful.  The point with
> XML was that you should be able to read it as well.

The name never have really been normative in the ASN1/DER world, OIDs always were
the real reference.

---

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 11 Nov 2001 11:58:38 +0100

Anders

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 12 Nov 2001 10:49:02 +0100

Michael,
This is slightly more complicated in XML Dsig compared to CMS.
In CMS the signers' certificate is specified by ASN1 data that
normally is one-to-one of the associated certificate.  The chance
of misinterpretation is then zero.  In XML Dsig the Issuer, Subject
etc. are given as UTF-8 strings which must be matched against the ASN
representation.  Although this is also the case for LDAP, I
believe XML Dsig which is used for "machines talking to
machines" is likely to be more hurt by the historic lack of
stringens in DN strings.

Anders

----- Original Message -----
From: "Michael Ströder" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, November 11, 2001 16:05
Subject: Re: Which RFC specifies: E=[email-masked]?

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Mon, 12 Nov 2001 14:56:16 +0100

> machines" is likely to be more hurt by the historic lack of

I don't know of any authorative registry mapping the OIDs of
attribute types to unambigous strings. If XML-DSIG relies on
something which isn't exactly defined XML-DSIG is flawed.

Using "Email" or simply "E" is somewhat strange anyway. IMHO PKI
applications should take a look into the LDAP world where "mail"
(RFC 2798) and "rfc822Mailbox" (RCF 1274) is used for
0.9.2342.19200300.100.1.3.

But this does not only affect XML-DSIG. It affects all components
which handle a string representation of a subject DN. E.g. web
applications using CGI-BIN environment vars set by the SSL-capable
web server.

Ciao, Michael.

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 12 Nov 2001 18:29:42 +0100

Rich,

Anders

----- Original Message ----- 
From: "Rich Salz" <[email-masked]>
To: <[email-masked]>
Cc: "Anders Rundgren" <[email-masked]>; <[email-masked]>
Sent: Monday, November 12, 2001 17:49
Subject: Re: Which RFC specifies: E=[email-masked]?

> If XML-DSIG relies on

It doesn't, and it isn't. :)

XML DSIG allows a number of ways to identify a sigining key, including:
issuer and serial# (number and string, respectively)
subject name (string)
x509 certificate (base64 encoded DER)
subject key identifier (base64 encoded value [i.e., not DER])
The spec says that the DN strings SHOULD be compliant with RFC2253,
using the official IETF meaning of SHOULD.
/r$

-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com

---

From: Andreas Sterbenz <[email-masked]>
Date: Mon, 12 Nov 2001 19:15:14 +0000

> No matter what the answer is, this will be an interoperability issue

If by SUN you mean the code that is in J2SE, the situation is this:

  . cert.getSubjectDN().getName() returns a String in an implementation 
dependent format. In case of the Sun X509Certificate implementation, an 
RFC1779 style syntax extended with common non-standard keywords such as 
EMAIL is used.

  . cert.getSubjectX500Principal().getName() return a String in RFC2253 
format. The PKCS#9 email address attribute is encoded using the OID 
format. This API is new in 1.4, currently in beta. See also 
http://java.sun.com/j2se/1.4/docs/api/javax/security/auth/x500/X500Principal.html

If you have any other questions, please contact me off-list.

Andreas.