When does Technically Constrained != Technically Constrained?

[Rob Stradling]

The following intermediate certificate is not "technically constrained"
according to the Policy. It contains id-kp-codeSigning, but does not
"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."
https://crt.sh/?sha1=4f5ea6a9e4ba30a4575dead4e4e9d3b2da66ea7b

https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F
...says that "All certificates that are capable of being used to issue
new certificates, and which directly or transitively chain to their
certificate(s) included in Mozilla’s CA Certificate Program that are not
technically constrained as described in section 9 of Mozilla's CA
Certificate Inclusion Policy" need to be disclosed.

That page also says that this includes (emphasis mine) "every
intermediate certificate (chaining up to a root certificate in Mozilla's
program with the Websites trust bit enabled) that is not Technically
Constrained via Extended Key Usage *and* Name Constraint settings."

So far, ISTM that this intermediate certificate MUST be disclosed to
Salesforce.

However, then that page says...
"Intermediate certificates are considered to be technically constrained,
and do not need to be added to the CA Community in Salesforce if:
- The intermediate certificate has the Extended Key Usage (EKU)
extension and the EKU does not include any of these KeyPurposeIds:
anyExtendedKeyUsage, id-kp-serverAuth;
- The intermediate certificate includes the Name Constraints extension
as described in section 7.1.5 of the CA/Browser Forum's Baseline
Requirements; or
- The root certificate is not enabled with the Websites trust bit."

There's an "or" between the 2nd and 3rd bullets, but it's not clear
whether or not there's an implied "and" between the 1st and 2nd bullets.

The Policy's definition of "technically constrained" would suggest that
there is an implied "and". However, I'm not sure that that's your intent.

What's the actual disclosure requirement for intermediate certificates
that don't meet the Policy's definition of "technically constrained"?
a) MUST disclose to Salesforce?
or
b) MUST disclose to a place of the CA's choosing.
?

Thanks.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Dimitris Zacharopoulos]

This intermediate seems technically constrained for SSL and S/MIME certificates, which are the only type of certs under the current Mozilla policy. Having extra nameConstraints for this particular intermediate, seems to be unnecessary, for the Mozilla root program.

DZ.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Kathleen Wilson]

I added "or" between the 1st and 2nd bullets.

> What's the actual disclosure requirement for intermediate certificates
> that don't meet the Policy's definition of "technically constrained"?
> a) MUST disclose to Salesforce?
> or
> b) MUST disclose to a place of the CA's choosing.

Per the March 2016 CA Communication, CAs are now required to disclose their non-technically-constrained certs in the CA Community in Salesforce.

I added a note to add this to the next version of the policy.
https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Proposed_Changes_That_Need_To_Be_Discussed


Thanks,
Kathleen

[Rob Stradling]

On 18/05/16 17:23, Dimitris Zacharopoulos wrote:
> This intermediate seems technically constrained for SSL and S/MIME certificates, which are the only type of certs under the current Mozilla policy.

Dimitris, are we looking at the same version of the Mozilla policy?

I'm looking at this one:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/

Code Signing _is_ still mentioned.

> Having extra nameConstraints for this particular intermediate, seems to be unnecessary, for the Mozilla root program.
>
> DZ.
>
>
>

>> On 18 Μαΐ 2016, at 17:16, Rob Stradling <rob.st...@comodo.com> wrote:
>>
>> The following intermediate certificate is not "technically constrained" according to the Policy. It contains id-kp-codeSigning, but does not "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."
>> https://crt.sh/?sha1=4f5ea6a9e4ba30a4575dead4e4e9d3b2da66ea7b
>>
>> https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F
>> ...says that "All certificates that are capable of being used to issue new certificates, and which directly or transitively chain to their certificate(s) included in Mozilla’s CA Certificate Program that are not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy" need to be disclosed.
>>
>> That page also says that this includes (emphasis mine) "every intermediate certificate (chaining up to a root certificate in Mozilla's program with the Websites trust bit enabled) that is not Technically Constrained via Extended Key Usage *and* Name Constraint settings."
>>
>> So far, ISTM that this intermediate certificate MUST be disclosed to Salesforce.
>>
>> However, then that page says...
>> "Intermediate certificates are considered to be technically constrained, and do not need to be added to the CA Community in Salesforce if:
>> - The intermediate certificate has the Extended Key Usage (EKU) extension and the EKU does not include any of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth;
>> - The intermediate certificate includes the Name Constraints extension as described in section 7.1.5 of the CA/Browser Forum's Baseline Requirements; or
>> - The root certificate is not enabled with the Websites trust bit."
>>
>> There's an "or" between the 2nd and 3rd bullets, but it's not clear whether or not there's an implied "and" between the 1st and 2nd bullets.
>>
>> The Policy's definition of "technically constrained" would suggest that there is an implied "and". However, I'm not sure that that's your intent.
>>

>> What's the actual disclosure requirement for intermediate certificates that don't meet the Policy's definition of "technically constrained"?
>> a) MUST disclose to Salesforce?
>> or
>> b) MUST disclose to a place of the CA's choosing.

>> ?
>>
>> Thanks.
>>
>> --
>> Rob Stradling
>> Senior Research & Development Scientist
>> COMODO - Creating Trust Online
>>
>> _______________________________________________
>> dev-security-policy mailing list
>> dev-secur...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.

[Rob Stradling]

On 18/05/16 19:38, Kathleen Wilson wrote:
> On Wednesday, May 18, 2016 at 7:17:01 AM UTC-7, Rob Stradling wrote:

<snip>

>> However, then that page says...
>> "Intermediate certificates are considered to be technically constrained,
>> and do not need to be added to the CA Community in Salesforce if:
>> - The intermediate certificate has the Extended Key Usage (EKU)
>> extension and the EKU does not include any of these KeyPurposeIds:
>> anyExtendedKeyUsage, id-kp-serverAuth;
>> - The intermediate certificate includes the Name Constraints extension
>> as described in section 7.1.5 of the CA/Browser Forum's Baseline
>> Requirements; or
>> - The root certificate is not enabled with the Websites trust bit."
>>
>> There's an "or" between the 2nd and 3rd bullets, but it's not clear
>> whether or not there's an implied "and" between the 1st and 2nd bullets.
>>
>> The Policy's definition of "technically constrained" would suggest that
>> there is an implied "and". However, I'm not sure that that's your intent.
>

> I added "or" between the 1st and 2nd bullets.

Hi Kathleen. With that change to the wiki page, I'm now certain that
you are simultaneously using multiple incompatible definitions of
"technically constrained".

The policy (v2.2) says that an intermediate certificate is either
"technically constrained" or it isn't. In other words, it MUST be
"technically constrained" for every one of the three (id-kp-serverAuth,
id-kp-emailProtection and id-kp-codeSigning) purposes that it is
permitted to issue for, or else it is _not_ considered to be
"technically constrained" _at all_.

But, on the wiki page, you're suggesting that an intermediate can be
considered "technically constrained" for id-kp-serverAuth whilst
simultaneously being considered "unconstrained" for id-kp-codeSigning.

>> What's the actual disclosure requirement for intermediate certificates
>> that don't meet the Policy's definition of "technically constrained"?
>> a) MUST disclose to Salesforce?
>> or
>> b) MUST disclose to a place of the CA's choosing.
>
>

> Per the March 2016 CA Communication, CAs are now required to disclose their non-technically-constrained certs in the CA Community in Salesforce.

For which definition of "non-technically-constrained"?!?

Specifically, what are the disclosure requirements for intermediates
that can only issue id-kp-emailProtection and/or id-kp-codeSigning
end-entity certs?
AFAICT, you want us to both disclose them, and to not disclose them, to
Salesforce!!!

Please clarify.

Thanks.

> I added a note to add this to the next version of the policy.
> https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Proposed_Changes_That_Need_To_Be_Discussed

[Dimitris Zacharopoulos]

On 19/5/2016 4:36 μμ, Rob Stradling wrote:
> On 18/05/16 17:23, Dimitris Zacharopoulos wrote:
>> This intermediate seems technically constrained for SSL and S/MIME
>> certificates, which are the only type of certs under the current
>> Mozilla policy.
>
> Dimitris, are we looking at the same version of the Mozilla policy?
>
> I'm looking at this one:
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
>
>
> Code Signing _is_ still mentioned.

According to the discussion from

https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/004uvRRnVyY/Ljo_vWJdCAAJ

policy version 2.3 will remove code signing references. Should we still
invest in this EKU in the Mozilla program? Should all CAs publish
information about codeSigning Intermediate CAs even when these will be
obsolete when policy 2.3 will be published? I was in favor of keeping
the code signing trust bit but it seems that this decision is final and
not up to further discussion.

Best regards,

Dimitris.

[Rob Stradling]

On 19/05/16 15:23, Dimitris Zacharopoulos wrote:
> On 19/5/2016 4:36 μμ, Rob Stradling wrote:
>> On 18/05/16 17:23, Dimitris Zacharopoulos wrote:
>>> This intermediate seems technically constrained for SSL and S/MIME
>>> certificates, which are the only type of certs under the current
>>> Mozilla policy.
>>
>> Dimitris, are we looking at the same version of the Mozilla policy?
>>
>> I'm looking at this one:
>> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
>>
>>
>> Code Signing _is_ still mentioned.
>
>
> According to the discussion from
>
> https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/004uvRRnVyY/Ljo_vWJdCAAJ
>
> policy version 2.3 will remove code signing references.

The future policy is not the current policy.

The current policy is the policy that is in force. The current policy
was referenced by the March 2016 CA Communication.

> Should we still invest in this EKU in the Mozilla program? Should all CAs publish
> information about codeSigning Intermediate CAs even when these will be
> obsolete when policy 2.3 will be published?

Yes, according to the current policy.

The current policy is authoritative. What you or I might consider to be
"common sense" is not authoritative.

> I was in favor of keeping
> the code signing trust bit but it seems that this decision is final and
> not up to further discussion.
>
> Best regards,
>
> Dimitris.

[Kathleen Wilson]

On Thursday, May 19, 2016 at 6:58:36 AM UTC-7, Rob Stradling wrote:
> Specifically, what are the disclosure requirements for intermediates
> that can only issue id-kp-emailProtection and/or id-kp-codeSigning
> end-entity certs?

Quotes form policy and supporting wiki page:
~~
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
Section 9:
"... 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-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."


https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Frequently_Asked_Questions
"3. How do I technically constrain a subordinate CA certificate that will only be used to issue end-user certificates intended for client authentication?
- For the subCA certificate to be considered technically constrained according to item #9 of Mozilla's CA Certificate Inclusion Policy, the subCA certificate must have the Extended Key Usage (EKU) extension with the id-kp-clientAuth KeyPurposeId (and whatever else they need), and the EKU extension must not include any of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, id-kp-emailProtection, id-kp-codeSigning.
-- If the EKU extension includes id-kp-serverAuth, then (in order to be considered technically constrained) the subCA certificate must also include the Name Constraints extension as described in item #9 of Mozilla's CA Certificate Inclusion Policy.
-- If the EKU extension includes id-kp-emailProtection, then (in order to be considered technically constrained) technical and/or business controls need to be in place to ensure that the subCA only issues certs for email addresses that the CA has confirmed the subCA is authorized to use, as described in item #9 of Mozilla's CA Certificate Inclusion Policy.
-- If the EKU extension includes id-kp-codeSigning, then (in order to be considered technically constrained) the SubCA certificate must also contain a directoryName permittedSubtrees constraint as described item #9 of Mozilla's CA Certificate Inclusion Policy.
4. If an included trust anchor does not have the websites (SSL/TLS) trust bit enabled, can it be exempt from items #9 and #10 of Mozilla's CA Certificate Inclusion Policy?
- A subordinate CA certificate that transitively chains to a trust anchor that only has the email trust bit enabled may be considered technically constrained as per item #9 of Mozilla's CA Certificate Inclusion Policy even when it does not include an EKU extension.
- A subordinate CA certificate that transitively chains to an included trust anchor that has the Code Signing and/or websites (SSL/TLS) trust bit(s) enabled must either include an EKU extension and constraints as per item #9 of Mozilla's CA Certificate Inclusion Policy, or must be audited and publicly disclosed as per item #10 of Mozilla's CA Certificate Inclusion Policy."
~~

My interpretation of the above regarding root certificates with only the Email trust bit enabled or intermediate certificates with only id-kp-emailProtection EKU is that in order to be technically constrained, the CA has to make sure (via technical and/or business controls) that the subordinate CA only issues certs for which the subscriber owns/controls the email address to be included in the certificate. There are many ways the CA can do this enforcement without the restrictions being directly in the issuing certificate. If a CA has the Email trust bit enabled for their root certificate, but they are not ensuring that their subordinate CAs only issue certs for which the subscriber owns/controls the email address to be included in the certificate, then their are in direct violation of section 7 of Mozilla's CA Certificate Policy.

If the CA has a root certificate that only has the Email trust bit enabled, but that is cross-signed by another root certificate that has the Websites trust bit enabled, then all of its intermediate certs do have to be disclosed in the hierarchy chaining to the Website-enabled root certificate, unless the intermediate certificate has an EKU that does not include KeyPurposeIds anyExtendedKeyUsage and id-kp-serverAuth.

Does that clear it up for S/MIME issuing certs?


Regarding Code Signing...
We have decided to remove the code signing trust bit in the next version of the policy.
https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Changes_Made_to_DRAFT_Version_2.3
So, I am not going to be spending any more time on Code Signing.
For the currently included root certs that have the Code Signing trust bit enabled but not the Websites trust bit, please use the logic I described above -- if the intermediate certs are cross-signed by root certs with the Websites trust bit enabled, then those intermediate certs should be disclosed in that hierarchy (with the root enabled with Websites trust bit).


Thanks,
Kathleen

[Kathleen Wilson]

On 5/19/16 9:02 AM, Ben Wilson wrote:
> What about when Microsoft starts to rely on the SalesForce
> database? Won't they want more information, including code
> signing and other information they might consider relevant?

Possibly. That will be for Jody to decide.

My approach to Salesforce so far has been to customize it and use it in
a manner that I need for Mozilla's program. So, the initial
customizations and data are Mozilla-centric.
As other root store operators begin to use the CA Community in
Salesforce, we will update/redesign the customization to add what they
need. Then the other root store operators can enter (or ask the CAs) to
enter the additional data that they need.

Thanks,
Kathleen

[Rob Stradling]

On 19/05/16 17:39, Kathleen Wilson wrote:
<snip>

> My interpretation of the above regarding root certificates with only the Email trust bit enabled or intermediate certificates with only id-kp-emailProtection EKU is that in order to be technically constrained, the CA has to make sure (via technical and/or business controls) that the subordinate CA only issues certs for which the subscriber owns/controls the email address to be included in the certificate. There are many ways the CA can do this enforcement without the restrictions being directly in the issuing certificate. If a CA has the Email trust bit enabled for their root certificate, but they are not ensuring that their subordinate CAs only issue certs for which the subscriber owns/controls the email address to be included in the certificate, then their are in direct violation of section 7 of Mozilla's CA Certificate Policy.
>
> If the CA has a root certificate that only has the Email trust bit enabled, but that is cross-signed by another root certificate that has the Websites trust bit enabled, then all of its intermediate certs do have to be disclosed in the hierarchy chaining to the Website-enabled root certificate, unless the intermediate certificate has an EKU that does not include KeyPurposeIds anyExtendedKeyUsage and id-kp-serverAuth.
>
> Does that clear it up for S/MIME issuing certs?

Yes, thanks.

> Regarding Code Signing...
> We have decided to remove the code signing trust bit in the next version of the policy.
> https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Changes_Made_to_DRAFT_Version_2.3
> So, I am not going to be spending any more time on Code Signing.
> For the currently included root certs that have the Code Signing trust bit enabled but not the Websites trust bit, please use the logic I described above -- if the intermediate certs are cross-signed by root certs with the Websites trust bit enabled, then those intermediate certs should be disclosed in that hierarchy (with the root enabled with Websites trust bit).

OK. So, to summarize, what you're saying is that the following clause
in policy v2.2 is no longer in effect, despite the fact that the current
policy says otherwise:

"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."

Please consider publishing a v2.2.1 of the policy that just removes this
clause, so that the written policy matches what you consider to be the
actual policy. Thanks.

I've just updated https://crt.sh/mozilla-disclosures. It no longer
claims that disclosure is required when an intermediate cert contains
the id-kp-codeSigning EKU OID but no directoryName constraint.

[Kathleen Wilson]

It has been pointed out to me, that I should not have added the "or" without updating the next bullet point.

So, here's what I changed it to:

https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F

"Intermediate certificates are considered to be technically constrained, and do not need to be added to the CA Community in Salesforce if:

- The intermediate certificate has the Extended Key Usage (EKU) extension and the EKU does not include any of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth; or
- The EKU extension in the intermediate certificate includes the anyExtendedKeyUsage or id-kp-serverAuth KeyPurposeIds, and the intermediate certificate includes the Name Constraints extension as described in section 7.1.5 of the CA/Browser Forum's Baseline Requirements; or

- The root certificate is not enabled with the Websites trust bit."

Without the clarification, it sounded like an intermediate certificate with nameConstraints did not need to have an EKU. But we (Mozilla) do indeed want the intermediate certificate to explicitly have the appropriate EKU, even if it has nameConstraints.

Please let me know if the wiki page still isn't clear in this regards.

Thanks,
Kathleen

[Rob Stradling]

On 23/05/16 18:59, Kathleen Wilson wrote:
<snip>

> It has been pointed out to me, that I should not have added the "or" without updating the next bullet point.
>
> So, here's what I changed it to:
>
> https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F

> "Intermediate certificates are considered to be technically constrained, and do not need to be added to the CA Community in Salesforce if:

> - The intermediate certificate has the Extended Key Usage (EKU) extension and the EKU does not include any of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth; or

> - The EKU extension in the intermediate certificate includes the anyExtendedKeyUsage or id-kp-serverAuth KeyPurposeIds, and the intermediate certificate includes the Name Constraints extension as described in section 7.1.5 of the CA/Browser Forum's Baseline Requirements; or

> - The root certificate is not enabled with the Websites trust bit."
>
>

> Without the clarification, it sounded like an intermediate certificate with nameConstraints did not need to have an EKU. But we (Mozilla) do indeed want the intermediate certificate to explicitly have the appropriate EKU, even if it has nameConstraints.
>
> Please let me know if the wiki page still isn't clear in this regards.

Kathleen, thanks for clarifying this. BRs section 7.1.5 requires the
EKU extension to be present, so I think your old text was already
implicitly clear. But now it's explicitly clear. :-)

BTW, you might want to take a look at the Internet Draft for the "EKU
constraints" certificate extension that the SPASM group is working on:
https://mailarchive.ietf.org/arch/search/?email_list=spasm

They're starting from the viewpoint that using the EKU extension as a
constraint mechanism is not compatible with RFC5280, but that clearly
there's a need for an EKU constraint mechanism.

I don't how on earth they expect to persuade Mozilla and Microsoft to
switch from (ab)using the EKU extension to using this proposed new
extension. Clearly it won't be backwards compatible with existing code
or existing EKU-constrained intermediates certs.

[Richard Barnes]

On Mon, May 23, 2016 at 4:41 PM, Rob Stradling <rob.st...@comodo.com>
wrote:

> On 23/05/16 18:59, Kathleen Wilson wrote:
> <snip>
>
>> It has been pointed out to me, that I should not have added the "or"
>> without updating the next bullet point.
>>
>> So, here's what I changed it to:
>>
>>
>> https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F

>> "Intermediate certificates are considered to be technically constrained,
>> and do not need to be added to the CA Community in Salesforce if:
>> - The intermediate certificate has the Extended Key Usage (EKU) extension
>> and the EKU does not include any of these KeyPurposeIds:

>> anyExtendedKeyUsage, id-kp-serverAuth; or
>> - The EKU extension in the intermediate certificate includes the

>> anyExtendedKeyUsage or id-kp-serverAuth KeyPurposeIds, and the intermediate

>> certificate includes the Name Constraints extension as described in section
>> 7.1.5 of the CA/Browser Forum's Baseline Requirements; or
>> - The root certificate is not enabled with the Websites trust bit."
>>
>>

>> Without the clarification, it sounded like an intermediate certificate
>> with nameConstraints did not need to have an EKU. But we (Mozilla) do
>> indeed want the intermediate certificate to explicitly have the appropriate
>> EKU, even if it has nameConstraints.
>>
>> Please let me know if the wiki page still isn't clear in this regards.
>>
>
> Kathleen, thanks for clarifying this. BRs section 7.1.5 requires the EKU
> extension to be present, so I think your old text was already implicitly
> clear. But now it's explicitly clear. :-)
>
> BTW, you might want to take a look at the Internet Draft for the "EKU
> constraints" certificate extension that the SPASM group is working on:
> https://mailarchive.ietf.org/arch/search/?email_list=spasm

More direct link:

https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-01

> They're starting from the viewpoint that using the EKU extension as a
> constraint mechanism is not compatible with RFC5280, but that clearly
> there's a need for an EKU constraint mechanism.
>
> I don't how on earth they expect to persuade Mozilla and Microsoft to
> switch from (ab)using the EKU extension to using this proposed new
> extension. Clearly it won't be backwards compatible with existing code or
> existing EKU-constrained intermediates certs.
>

I've had a bit of discussion with the authors, and that was basically my
starting point -- what value does this add over what we do now? AFAICT,
the only value is in cleaning up the relationship between RFC 5280 and
reality, and ISTM there are cheaper ways to do that -- i.e., fixing the
spec.

That said, if this were something that the industry were interested in,
code can be written. It would just be a simple matter of transitioning
from the old thing to the new thing, which I know this community loves to
do. </irony>

--Richard

>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online

[Rob Stradling]

On 23/05/16 21:59, Richard Barnes wrote:
<snip>

> They're starting from the viewpoint that using the EKU extension as
> a constraint mechanism is not compatible with RFC5280, but that
> clearly there's a need for an EKU constraint mechanism.
>
> I don't how on earth they expect to persuade Mozilla and Microsoft
> to switch from (ab)using the EKU extension to using this proposed
> new extension. Clearly it won't be backwards compatible with
> existing code or existing EKU-constrained intermediates certs.
>
>
> I've had a bit of discussion with the authors, and that was basically my
> starting point -- what value does this add over what we do now? AFAICT,
> the only value is in cleaning up the relationship between RFC 5280 and
> reality, and ISTM there are cheaper ways to do that -- i.e., fixing the
> spec.

It's been claimed that some implementations take the (not unreasonable)
view that the EKU extension constrains what the public key in _that_
certificate can be used for. Since there's no EKU OID defined for "can
issue certificates", these implementations apparently do not recognize
any CA certificates that contain the EKU extension as CA certificates.

> That said, if this were something that the industry were interested in,
> code can be written. It would just be a simple matter of transitioning
> from the old thing to the new thing, which I know this community loves
> to do. </irony>

Why invent a new thing?

At least one alternative old thing already exists in several generations
of Windows [1] (Microsoft's "Application Policies" extension).

There's also some evidence [2] that Windows supports the "Key Usage
Restriction" extension [3] that was deprecated before RFC2459 was published.

Then there's "Policy Constraints".

And let's not forget "Netscape Certificate Type".


[1] https://technet.microsoft.com/en-us/library/cc776986(v=ws.10).aspx

[2]
https://msdn.microsoft.com/en-us/library/windows/desktop/aa377206(v=vs.85).aspx

[3] https://tools.ietf.org/html/draft-ietf-pkix-ipki-part1-01

[Richard Barnes]

On Mon, May 23, 2016 at 5:28 PM, Rob Stradling <rob.st...@comodo.com>
wrote:

> On 23/05/16 21:59, Richard Barnes wrote:
> <snip>
>
>> They're starting from the viewpoint that using the EKU extension as
>> a constraint mechanism is not compatible with RFC5280, but that
>> clearly there's a need for an EKU constraint mechanism.
>>
>> I don't how on earth they expect to persuade Mozilla and Microsoft
>> to switch from (ab)using the EKU extension to using this proposed
>> new extension. Clearly it won't be backwards compatible with
>> existing code or existing EKU-constrained intermediates certs.
>>
>>
>> I've had a bit of discussion with the authors, and that was basically my
>> starting point -- what value does this add over what we do now? AFAICT,
>> the only value is in cleaning up the relationship between RFC 5280 and
>> reality, and ISTM there are cheaper ways to do that -- i.e., fixing the
>> spec.
>>
>
> It's been claimed that some implementations take the (not unreasonable)
> view that the EKU extension constrains what the public key in _that_
> certificate can be used for. Since there's no EKU OID defined for "can
> issue certificates", these implementations apparently do not recognize any
> CA certificates that contain the EKU extension as CA certificates.
>

Right, the "fix the spec" vs. "fix the Web PKI" question sort of comes down
to whether we want to make browsers and WebPKI CAs change, or these other
systems. I would be interested to learn more about how prevalent this
behavior is, both in terms of RPs and in terms of CAs conforming to those
RPs' expectations.

>
> That said, if this were something that the industry were interested in,
>> code can be written. It would just be a simple matter of transitioning
>> from the old thing to the new thing, which I know this community loves
>> to do. </irony>
>>
>
> Why invent a new thing?
>

Even if we make an old thing new, there's still the transition :)

--Richard

>
> At least one alternative old thing already exists in several generations
> of Windows [1] (Microsoft's "Application Policies" extension).
>
> There's also some evidence [2] that Windows supports the "Key Usage
> Restriction" extension [3] that was deprecated before RFC2459 was published.
>
> Then there's "Policy Constraints".
>
> And let's not forget "Netscape Certificate Type".
>
>
> [1] https://technet.microsoft.com/en-us/library/cc776986(v=ws.10).aspx
>
> [2]
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa377206(v=vs.85).aspx
>
> [3] https://tools.ietf.org/html/draft-ietf-pkix-ipki-part1-01
>
>

[Rob Stradling]

On 23/05/16 22:41, Richard Barnes wrote:
> On Mon, May 23, 2016 at 5:28 PM, Rob Stradling wrote:
<snip>

> Why invent a new thing?
>
>
> Even if we make an old thing new, there's still the transition :)

That's true, but it would be an easier transition.