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. Stefan proposed a change that would require that only certs that included this EKU be considered, you said you would consider that, and I said that would be a bad change. Henry's point did not negate or support my proposal. --Paul Hoffman, Director --VPN Consortium _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
