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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf