Re: When does Technically Constrained != Technically Constrained?

[Rob Stradling]

On 23/05/16 22:41, Richard Barnes wrote:

On Mon, May 23, 2016 at 5:28 PM, Rob Stradling wrote:



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.

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

Re: When does Technically Constrained != Technically Constrained?

[Rob Stradling]

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


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.


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

Re: When does Technically Constrained != Technically Constrained?

[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 

RE: When does Technically Constrained != Technically Constrained?

[Ben Wilson]

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?

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On 
Behalf Of Rob Stradling
Sent: Thursday, May 19, 2016 9:54 AM
To: Dimitris Zacharopoulos <ji...@it.auth.gr>
Cc: mozilla-dev-security-pol...@lists.mozilla.org 
<dev-security-policy@lists.mozilla.org>
Subject: Re: When does Technically Constrained != Technically Constrained?

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-grou
>> p/certs/policy/inclusion/
>>
>>
>> Code Signing _is_ still mentioned.
>
>
> According to the discussion from
>
> https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/004u
> vRRnVyY/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.

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: When does Technically Constrained != Technically Constrained?

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


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

Re: When does Technically Constrained != Technically Constrained?

[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:



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


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

Re: When does Technically Constrained != Technically Constrained?

[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  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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


___
dev-security-policy mailing list
dev-security-policy@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.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: When does Technically Constrained != Technically Constrained?

[Kathleen Wilson]

On Wednesday, May 18, 2016 at 7:17:01 AM UTC-7, Rob Stradling 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.


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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: When does Technically Constrained != Technically Constrained?

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



> On 18 Μαΐ 2016, at 17:16, Rob Stradling  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-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy