[x500standard] Re: SV: Re: Processing of extended key usage extension
- From: Santosh Chokhani <SChokhani@xxxxxxxxxxxx>
- To: "x500standard@xxxxxxxxxxxxx" <x500standard@xxxxxxxxxxxxx>
- Date: Sun, 4 Nov 2012 08:01:31 -0500
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.
* 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.
* 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.
* 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.
Other related posts:
