On Thu, Jul 01, 2010 at 01:29:33AM +2600, Martin Rex wrote: > Actually, _some_ of the PKIX-heavy APPS might want to restrict > usability of server certificates by "extendedKeyUsage" in addition > to what we define as server endpoint identification here. > > The wording in rfc-5280 section 4.2.1.12 appears a self-contradictory > to me, because it conditionalizes "MUST only" with "applications MAY do > whatever they see fit", and application negligence is likely to be > the norm. And btw. how "applications MAY" is used it refers to > individual implementations and such an interpretation aligns well > with the more easily understandable text in rfc-2459. > > > If the extension is present, then the certificate MUST only be used > for one of the purposes indicated. If multiple purposes are > indicated the application need not recognize all purposes indicated, > as long as the intended purpose is present. Certificate using > applications MAY require that the extended key usage extension be > present and that a particular purpose be indicated in order for the > certificate to be acceptable to that application. > > > -Martin
Yeah, I was actually waiting to see who brings this up first! :-) A smaller group of us had discussions about this (via private e-mail prior to the certid list being set up). I'm sure the others will chime in with their thoughts. But our general impression is that KU/EKU are very poorly understood. Some of my principal concerns with using them for application restriction are that the current ones aren't defined precisely enough. Ideally you need a new EKU for every new application protocol for proper security compartmentalization. Also they depend on a more complicated set of things happening correctly on both the server and client side. The client has to perform an additional step in addition to matching the subject identity. And actually to ensure that the use of the cert is being constrained, the EKU extension has to be marked critical (which I think breaks some modes of migration) - assuming of course that client software rejects the cert if they don't understand the EKU extension, which may not be a true assumption for the deployed base of software. --Shumon. _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
