[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. Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
