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'm not sure I really have a strong opinion on ordering per-se, but .. 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. 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. Having a preferred ordering consistent with that goal is probably a good thing. I might be wandering too far away from your specific question now, so I'll stop. -- Shumon Huque University of Pennsylvania. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf