Re: Action-41

Correction, this should close ACTION-42. (Sending message so tracker  
associates with action note.)

regards, Frederick

Frederick Hirsch
Nokia


On Jun 1, 2007, at 1:01 PM, ext Juan Carlos Cruellas wrote:

>
> 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 Tuesday, 5 June 2007 12:26:50 UTC