At 7:16 PM -0400 7/19/10, Shumon Huque wrote: >On Sun, Jul 18, 2010 at 03:04:55PM -0700, Paul Hoffman wrote: >> At 1:59 PM -0400 7/18/10, Shumon Huque wrote: >> >Well, one reason would be to reduce the number of verification >> >steps imposed on a client by a certificate with a more preferred >> >or more specific identity type. >> >> Is there something more than just a non-mandatory optimization? The >> three bullet points in the list all have MUSTs, and it sounds like >> these MUSTs, and the statement that "The client then orders the list >> in accordance with the following rules" passes muster with RFC 2119. >> --Paul Hoffman, Director >> --VPN Consortium > >Right, I agree with that. > >I'm not clear on whether you're objecting to an ordering rule. Or >saying that the additional text in 4.3 about ordering is unnecessary. I am objecting to a MUST- or SHOULD-level ordering rule where it does not affect interoperability or security. I am still open to someone showing why this particular rule might affect those, but after many rounds, none has come forth, so I am suggesting dropping the rule altogether or making it MAY-level (with some reasoning as to why it is even worth the effort). >There are multiple possible identity types. Clients will presumably >search for them in some order. Should we just tell them to try in whatever >order they want, including random? Or should we tell them to try in >the order of identities that we preferred application services to use, >and move the deprecated ones (CN-ID) to the bottom of that list? >Optimizing for the preferred use cases sounds to me like a reasonable >thing to do. Why is it reasonable? It is *we* who are preferring the order, not them, even though we admit that any value returned from the order is secure enough. >I do have a stronger opinion on the following point: I think there is >a longer term security goal here, of nudging application protocols to >use application specific identity types -- so that we avoid situations >where a certificate with a generic domain name identity, if compromised >for a particular service, can be used to impersonate other unrelated >services at that domain name. As a general rule, different application >services running at the same domain name should not be using the same >certificates, unless by conscious choice of the deployer. Fully agree, and that is correctly addressed, repeatedly, in the rest of the document. >Having a preferred ordering consistent with that goal is probably >a good thing. Arrrgh. Why? >I might be wandering too far away from your specific question now, >so I'll stop. No, please continue. I truly would be happy if you could show why forcing them to order their search would help even though any match would do. I just am not seeing it. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf