Subject: Which RFC specifies: E=[email-masked]?

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

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

Anders

---

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

> 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: 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.

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.
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.

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: Jean-Marc Desperrier <[email-masked]>
Date: Mon, 12 Nov 2001 15:52:20 +0100

> 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.

> 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: Phil Griffin <[email-masked]>
Date: Mon, 12 Nov 2001 10:07:56 -0500

Anders Rundgren wrote:
> representation.  

I assume here that you mean the DER encoding of
these values. Note that the new X.693 (in last 
call) XER rules may offer some help in matching
values.

Clause 9.1.3 states that the value of any ASN.1
type "shall be encoded using Universal Transformation
Function 8 (UTF-8) to produce a string of octets".

And clause 10 specifies a canonical encoding of these
values C-XER. These rules require that the dotted 
numeric form (same as that used in LDAP) of object
identifiers be used. 

Phil

>                 Although this is also the case for LDAP, I

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 12 Nov 2001 16:59:26 +0100

Phil,

No XER does not apply to XML DSIG.  Unfortunately.
There had been no interop issue if XER had been used.
But now it is DN strings in UTF-8 and not DER.

Anders

----- Original Message -----
From: "Phil Griffin" <[email-masked]>
To: <[email-masked]>
Sent: Monday, November 12, 2001 16:07
Subject: Re: Which RFC specifies: E=[email-masked]?

Phil

---

From: Rich Salz <[email-masked]>
Date: Mon, 12 Nov 2001 11:49:20 -0500

> 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: Michael Ströder <[email-masked]>
Date: Mon, 12 Nov 2001 18:05:08 +0100

> using the official IETF meaning of SHOULD.

RFC2253 is *not* unambigous regarding attribute type names as long
as you don't strictly mandate using OIDs. There are only very few
attribute types mentioned by names (see RFC 2253, section 2.3.):

------------------------- snip ---------------------------
   If the AttributeType is in a published table of attribute types
   associated with LDAP [4], then the type name string from that
table
   is used, otherwise it is encoded as the dotted-decimal encoding
of
   the AttributeType's OBJECT IDENTIFIER. The dotted-decimal
notation is
   described in [3].  As an example, strings for a few of the
attribute
   types frequently seen in RDNs include:

                    String  X.500 AttributeType
                    ------------------------------
                    CN      commonName
                    L       localityName
                    ST      stateOrProvinceName
                    O       organizationName
                    OU      organizationalUnitName
                    C       countryName
                    STREET  streetAddress
                    DC      domainComponent
                    UID     userid
------------------------- snip ---------------------------

The term "published table of attribute types associated with LDAP"
is a very vague statement probably referring to the LDAPv3 subschema
subentry where a LDAP application can look up the exact OID for an
attribute type name. Not usable in general.

Also an e-mail address is not mentioned there. This was Anders'
original question. Additionally we were reminded today that LDAP
standards (RFC1274 and RFC2798) and PKCS#9 are using different OIDs
for specifying the RFC822 e-mail address...sigh!

Ciao, Michael.

---

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

Rich,
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.  

Anders

---

From: Rich Salz <[email-masked]>
Date: Mon, 12 Nov 2001 12:59:45 -0500

> key.  Some are 100% safe but some are not.  What the majority will use

Totally agree.

I vote for xkms myself. :)
-- 
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.

---

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

> key.  Some are 100% safe but some are not.  What the majority will use

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

Ciao, Michael.

---

From: Phil Griffin <[email-masked]>
Date: Mon, 12 Nov 2001 16:02:53 -0500

> But now it is DN strings in UTF-8 and not DER.

Anders,

Understood. But note that there is now a standardized way
to represent values of every ASN.1 type in a canonical
XML markup format regardless of which binary encoding
rules are used to transfer these values. This canonical
format is a UTF-8 encoding.

Phil Griffin

---

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

Hi,
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!

Anders

---

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

> 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: "Anders Rundgren" <[email-masked]>
Date: Wed, 14 Nov 2001 14:28:55 +0100

Micheal,
2.4:

   If the AttributeValue is of a type which does not have a string
   representation defined for it, then it is simply encoded as an
   octothorpe character ('#' ASCII 35) followed by the hexadecimal
   representation of each of the bytes of the BER encoding of the X.500
   AttributeValue.  This form SHOULD be used if the AttributeType is of
   the dotted-decimal form.

Hum,
My colluege still think that the last line says something else!
i.e. since the e-mail *type* must be represented as dotted decimal
its value SHOULD be in hex rather than IA5String.  Or is this bad writing?

Anders

----- Original Message -----
From: "Michael Ströder" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 14, 2001 13:18
Subject: Re: RFC2253 e-mail address

Ciao, Michael.

---

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

> its value SHOULD be in hex rather than IA5String.  Or is this bad writing?

Might be a good idea to ask on the IETF-LDAPBIS list.

Ciao, Michael.