Action-41 from Juan Carlos Cruellas on 2007-06-01 (public-xmlsec-maintwg@w3.org from June 2007) (original) (raw)

Dear all, this should complete action 41. Sorry for the long message.

Dear all,

If we asume that by default is implicit that no matter the fact that RFCs 2253 and 4515 speak about allowing

plain '<' in the string, the XML rule that any '<' within a node text must be escaped, then I concur that

this is not an issue. Maybe a note warning about this fact could be worth....

As for the CDATA section vs. node text, I have read somewhere that in fact the CDATA section is a kind of

convention that applications should know and treat as a node text except by the fact that escaping as defined

by XML is not required there. My understanding of what I read is that this not require even a xml schema

change (although I could be wrong: I am not sure, but I have not found any mention to CDATA sections in the

XML Schema specs -I found mention to CDATA type but at first reading it does nothing to do).

Nevertheless, after re-reading RFCs 2253 and 4515, I think that we could have still a different issue. The

origin of this discussion are the different elements within X509Data that, according XMLSig, should allow to

identify a certain certificate. One of these means is the pair X509IssuerName, X509SerialNumber.... I propose

to give a thougth to the string representation and asses whether this might make it unfeasible the

identification of a certificate given the X509IssuerName.

TheRFCs themselves provide a clear warning in sectin 7.2 of RFC 2253, and 5.2 of RFC 4514 (Use of

Distinguished Names in Security Applications):

" The transformations of an AttributeValue value from its X.501 form to an LDAP string representation are not always reversible back to the same BER or DER form. An example of a situation which requires the DER form of a distinguished name is the verification of an X.509 certificate.

For example, a distinguished name consisting of one RDN with one AVA,
in which the type is commonName and the value is of the TeletexString
choice with the letters 'Sam' would be represented in LDAP as the
string CN=Sam.  Another distinguished name in which the value is
still 'Sam' but of the PrintableString choice would have the same
representation CN=Sam.

Applications which require the reconstruction of the DER form of the
value SHOULD NOT use the string representation of attribute syntaxes
when converting a distinguished name to the LDAP format.  Instead,
they SHOULD use the hexadecimal form prefixed by the octothorpe ('#')
as described in the first paragraph of section 2.4.

"

I read this as that it looks like if people use regular strings (CN=John....) instead the scaped octet

representation preceded by the dot representation of the OID, applications could not rebuild the orignial DER

encoding Distinguished Name and not find the certificate.

On the other hand, if the method is the contrary, i.e. to convert the Distinguished Name of the certificates

to be inspected to String using the RFC 2253 / 4514, still seems that there are possibilities for getting

different strings.

RFC2253 (section 2.3) when speaks about converting the AttributeTypeAndValue says: "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:... " And gives an example table... and I wonder about hte possibility that a generating application uses some a

short name that the verifying application does not know and then how this one could actually match both

strings?

RFC 4514 has introduced some changes. In section 2.3 speaks about a registration process of short names

(descriptors) managed by IANA, but in its sectin 3 it gives a table and says: "Implementations MUST recognize AttributeType name strings (descriptors) listed in teh following table, but

MAY recognize other name strings" and later on :

" Implementations MAY recognize other DN string representations. However, as there is no requirement that alternative DN string representations be recognized (and, if so, how), implementations SHOULD only generate DN strings in accordance with Section 2 of this document. "

In summary, I wonder whether we should think a bit more on giving some guidance that would avoid this problem

of identifying the referenced certificate by a X509IssuerSerial element.

Sorry if I raise some issue that was already discussed in the XMLSig WG (and if so, please forget it) and also for this long message

Juan Carlos

Received on Friday, 1 June 2007 17:01:53 UTC