> -----Original Message----- > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 01, 2006 8:29 PM > To: Joseph Salowey (jsalowey); [email protected] > Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt > > > > A valid EAP-TLS client certificate SHOULD contain an > > > extendedKeyUsage > > > value indicating support for Client Authentication > > > (1.3.6.1.5.5.7.3.2). A valid EAP-TLS server certificate SHOULD > > > contain an extendedKeyUsage value indicating support for Server > > > Authentication (1.3.6.1.5.5.7.3.1). > > > > >[Joe] I think I remember that some protocols specify the > presence of a > >specific EKU or the ANY EKU. > > Any references I should look at? Other than RFC 3280, the > only reference I > could find is this: > http://www.drizzle.com/~aboba/CPW/Hardjono-IETF55-TLScertProfile.pdf >
Good question, SMIME (RFC3850) discusses EKU in section 4.4.4 is the only reference I found to anyExtendedKeyUsage. Documents such as RFC4556 (PKINIT) and RFC4334 (WLAN CERTS) use MAY when discussing EKU. There are also examples where a specific EKU is required in RFC3161 (Time stamping protocol). It seems that 3850,4556 and 4334 are more consistent with EAP-TLS usage. > >[Joe] I haven't looked at [He] in a while, but I thought > that it wasn't > >applications in general, but applications that use a protocol that > >bindly signs arbitrary data. Perhaps this should be a bit clearer. > > Yes, that was the issue. > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
