At 6:56 PM -0700 6/11/10, Henry B. Hotz wrote: >On Jun 11, 2010, at 3:53 PM, Paul Hoffman wrote: > >> At 2:54 PM -0600 6/11/10, Peter Saint-Andre wrote: >>> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; >>> micalg=sha1; boundary="------------ms020609010501090708040406" >>> >>> Version -05 of draft-saintandre-tls-server-id-check has some warning >>> text about Domain Components (DCs). However, the more I delve the matter >>> the less I think that we need to warn people away from using DCs from a >>> security perspective. The problem with them would arise from confusion >>> about the order of DCs based on the string representation, however that >>> kind of confusion is possible for any RDNs and is not limited to DCs (so >>> follow the DER order, not the string order). There might be other >>> reasons to discourage DCs, but so far I have not heard them, so I'm >>> inclined to remove the warnings from -06. >>> >>> Do speak up if you're concerned about this proposal. >> >> Finally decloaking after being off this topic for a while. >> >> I am *quite* concerned about this. The DC ordering problem is not "based on >> the string representation": it is because the set of DCs can be read *by the >> program* in two directions. For example, think about a cert with "dc=com >> dc=net". Both net.com and com.net exist today. For different applications, >> that one cert could apply to two completely different domains. > >But is the problem unique to DC's?
To the best of my knowledge, yes. It is the "component" part of DC that makes them susceptible to "guess the ordering". All other relevant PKIX identifier fields are the full identifier. _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
