On 9/29/10 4:20 PM, Paul Hoffman wrote: > At 2:03 PM -0600 9/29/10, Peter Saint-Andre wrote: >> [trimming tls@ and ietf@ from cc list] >> >> On 9/23/10 11:43 AM, Henry B. Hotz wrote: >>> >>> On Sep 22, 2010, at 9:44 AM, Paul Hoffman wrote: >>> >>>> At 10:21 AM -0600 9/22/10, Peter Saint-Andre wrote: >>>>> On 9/14/10 12:51 AM, Stefan Santesson wrote: >>>>>> General: I would consider stating that server certificates >>>>>> according to this profile either MUST or SHOULD have the >>>>>> serverAuth EKU set since it is allways related to the use >>>>>> of TSL and server authentication. At least it MUST be set >>>>>> when allowing checks of the CN-ID (see 2.3 below). >>>>> >>>>> [..snip..] >>>> >>> >>>> What possible advantage is there to making certificates that do >>>> not have this flag set be excluded from the practices you are >>>> defining? That is, if a TLS client gets a certificate from a >>>> TLS server that the TLS server says is its authentication >>>> certificate, why should the client care whether or not that >>>> flag is set? That flag is an assertion from the CA, not from >>>> the server who is authenticating. >>> >>> >>> Does this point need discussion? Without checking, I suspect >>> that 5280 says you obey the EKU, period. OTOH I think Paul >>> raises a valid point. >>> >>> OTOH (again) one could argue that the EKU provides a way to >>> prevent a stolen cert/key issued to the machine for a different >>> function from being repurposed to support a fake server. (I'm >>> not convinced this is significant, but it's something.) >>> >>> Absent discussion and consensus, I vote for whatever 5280 says, >>> which I suppose is what the current silence on the topic equates >>> to. >> >> This I-D shall never be taken to override anything in RFC 5280 or >> any other normatively-referenced specification on which it depends. >> If folks think we need a blanket statement to that effect, please >> let us know. Version -10 will have a new section containing an >> applicability statement, which starts as follows: >> >> This document does not supersede the rules for certificate >> validation provided in [RFC5280]. >> >> But we can always add a stronger statement if need be. > > This misses the point I made when I started this thread.
That's because I was replying only to the small item of whether the server-id-check can be taken to override RFC 5280. > Stefan > proposed a change that would require that only certs that included > this EKU be considered, you said you would consider that, I think I said only that Jeff and I hadn't discussed it yet. It's still on our todo list. > and I said > that would be a bad change. Henry's point did not negate or support > my proposal. My sense of the discussion so far is that there's no strong agreement to accept the proposal that Stefan made. Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
