[x500standard] Re: SV: Re: Processing of extended key usage extension
- From: Santosh Chokhani <SChokhani@xxxxxxxxxxxx>
- To: David Chadwick <d.w.chadwick@xxxxxxxxxx>, "x500standard@xxxxxxxxxxxxx" <x500standard@xxxxxxxxxxxxx>
- Date: Sun, 4 Nov 2012 10:42:55 -0500
That said, I can see graceful rejection by older clients by marking the
extension critical and only including the EKU OIDs that are new ones in the
intermediate certificates and are intended for constraining the downstream CAs.
-----Original Message-----
From: Santosh Chokhani
Sent: Sunday, November 04, 2012 10:38 AM
To: 'David Chadwick'; x500standard@xxxxxxxxxxxxx
Subject: RE: [x500standard] Re: SV: Re: Processing of extended key usage
extension
David,
I am afraid that this is not so simple. The semantics of the OID will impact
the path processing and calculation of the intersection of the applicable OIDs
in the path and then "mapping and then intersecting" with EKU OIDs in the end
certificates since their values are different per your proposal and finally
letting the application know which purposes the certificate can be used for.
-----Original Message-----
From: David Chadwick [mailto:d.w.chadwick@xxxxxxxxxx]
Sent: Sunday, November 04, 2012 8:39 AM
To: x500standard@xxxxxxxxxxxxx
Cc: Santosh Chokhani
Subject: Re: [x500standard] Re: SV: Re: Processing of extended key usage
extension
I see a serious problem with the current Mozilla approach, in that they are not
defining new EKUs for use in the EKU extension (which would be OK, in line with
my devil's advocate message below), but rather they are using existing EKUs and
RE-DEFINING them with their own semantics. This should be a strict NO NO since
it means that there are now two different interpretations of the same EKU OID.
Which one should an implementor use? Since OIDs are cheap and plentiful, why
cant they simply use the existing EKU extension and then define their own OIDs
with their own semantics to put in there. We could change the X.509 definition
of EKU to say that values placed there could apply to the current certificate
or to certificate's issued by this CA's certificate, but the EKU values must be
different in both cases to stop ambiguity and confusion
regards
David
On 04/11/2012 13:01, Santosh Chokhani wrote:
> Eric,
>
> There can be problems with toolkits that process the extension as intended.
>
> Note that MSFT and Mozilla definition seems to apply to the
> certificate path and hence the end certificate as well and not just to
> the certificate EKU is asserted in.
>
> I am also concerned, albeit have no known example, that a toolkit or
> application could reject a CA certificate with EKU in it since there
> is no EKU that says use the certificate to verify signatures on other
> certificates or CRL. If it did that, it would be in compliance with
> X.509 and 5280.
>
> That said, I have no objection to redefining the semantics of the
> extension if the implementers agree. Is there a mechanism to arrive a
> consensus on a change that is material and breaks backward compatibility?
>
> Would you want to do this in concert with PKIX?
>
> *From:*x500standard-bounce@xxxxxxxxxxxxx
> [mailto:x500standard-bounce@xxxxxxxxxxxxx] *On Behalf Of *Erik
> Andersen
> *Sent:* Sunday, November 04, 2012 5:59 AM
> *To:* x500standard@xxxxxxxxxxxxx
> *Subject:* [x500standard] SV: Re: Processing of extended key usage
> extension
>
> Just a thought in line with David C's second message.
>
> What would the implications be if we redefine the semantics of the
> extension, where the current semantics applies for an EKU in an
> end-entity public-key certificate and the MS/Mozilla definition
> applies to CA-certificates?
>
> Erik
>
> *Fra:*x500standard-bounce@xxxxxxxxxxxxx
> <mailto:x500standard-bounce@xxxxxxxxxxxxx>
> [mailto:x500standard-bounce@xxxxxxxxxxxxx] *På vegne af *Santosh
> Chokhani
> *Sendt:* 2. november 2012 19:21
> *Til:* x500standard@xxxxxxxxxxxxx <mailto:x500standard@xxxxxxxxxxxxx>
> *Emne:* [x500standard] Re: Processing of extended key usage extension
>
> Dave,
>
> I see some benefit in using an extension that constrains the path. In
> order to ensure backward compatibility, that should be done using a
> new extension.
>
> I wonder what the response would be if we approached Mozilla and MSFT
> with this recommendation.
>
> *From:*x500standard-bounce@xxxxxxxxxxxxx
> <mailto:x500standard-bounce@xxxxxxxxxxxxx>
> [mailto:x500standard-bounce@xxxxxxxxxxxxx] *On Behalf Of *David A.
> Cooper
> *Sent:* Friday, November 02, 2012 2:00 PM
> *To:* x500standard@xxxxxxxxxxxxx <mailto:x500standard@xxxxxxxxxxxxx>
> *Subject:* [x500standard] Re: Processing of extended key usage
> extension
>
> These seem like good ideas. I've never seen an intermediate
> certificate with an extended key usage extension, and this may be part
> of the reason that Microsoft's implementation of extended key usage
> hasn't caused much of a problem. Unfortunately, the reason that I
> found out about Mozilla's plans is that they intend to actively
> encourage the inclusion of extended key usage extensions in
> intermediate certificates that include currently defined key purpose
> OIDs
> (http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html):
>
> * For a certificate to be considered *technically constrained*, the
> certificate MUST include an Extended Key Usage (EKU) extension
> specifying all extended key usages that the subordinate CA is
> authorized to issue certificates for. The anyExtendedKeyUsage
> KeyPurposeId MUST NOT appear within this extension.
>
> o If the certificate includes the id-kp-serverAuth extended key
> usage, then the certificate MUST include the Name Constraints
> X.509v3 extension. The Name Constraints extension MUST contain a
> dNSName permittedSubtrees constraint that only contains domains
> for which the issuing CA has confirmed that the subordinate CA
> has registered or has been authorized by the domain registrant
> to act on the registrant's behalf. If there are no such dNSNames
> (e.g. because the certificate is for issuing IP-address-based
> certificates), then the certificate MUST contain a dNSNames
> constraint that prohibits all DNS names.
>
> o If the certificate includes the id-kp-emailProtection extended
> key usage, then all end-entity certificates MUST only include
> e-mail addresses or mailboxes that the issuing CA has confirmed
> (via technical and/or business controls) that the subordinate CA
> is authorized to use.
>
> o If the certificate includes the id-kp-codeSigning extended key
> usage, then the certificate MUST contain a directoryName
> permittedSubtrees constraint where each permittedSubtree
> contains the organizationName, localityName (where relevant),
> stateOrProvinceName (where relevant) and countryName fields of
> an address that the issuing CA has confirmed belongs to the
> subordinate CA.
>
>
> Mozilla's draft policy imposes additional requirements on CA
> certificates that are not "technically constrained."
>
> The general response on the Mozilla web site
> (https://bugzilla.mozilla.org/show_bug.cgi?id=725351) seems to be
> "everyone else is ignoring the X.509 semantics for extended key usage,
> so why shouldn't Mozilla?". I asked why, if everyone feels that the
> X.509 semantics are wrong, no one has proposed a change to the standard.
> The only response I've gotten so far cam from Brian Smith who said "I
> expect that will happen as part of the WebPKI effort at the IETF." I
> would certainly hope the IETF wouldn't try to use the Web PKI
> Operations working group (assuming one forms) to try to change the
> semantics of an
> X.509 extension. Any change would have to be made in X.509, not in
> the IETF, and get the impression from the discussions on this list
> that there isn't interest in changing X.509.
>
> Dave
>
> On 10/27/2012 10:43 AM, Michael Ströder wrote:
>
> Basically for PKI practitioners this means:
>
> 1. Never ever set extendedKeyUsage in intermediate certs.
>
> 2. Never ever sign certs with a key for which the accompanying
> public-key cert
>
> contains the extendedKeyUsage extension.
>
>
> On 10/22/2012 05:46 PM, David Chadwick wrote:
>
> However, one could possible use this line of argument (I am not
>
> condoning their current approach, only playing devil's advocate
> for
>
> them). EKU is a bucket which allows new extended key uses to be defined.
>
> If all the EKUs that they define, specify in their definition that
> this
>
> EKU does not apply to the certificate in question, but to the
>
> certificate of the subject, then one could argue that it is OK,
> since
>
> you have to understand the value of the EKU in order to implement
> it,
>
> and when you understand the value you understand the semantics
> that are
>
> applied to the value
>
> ----- www.x500standard.com <http://www.x500standard.com>: The central
> source for information on the X.500 Directory Standard.
>
-----
www.x500standard.com: The central source for information on the X.500 Directory
Standard.
Other related posts:
