Action-41

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