Disclose also TCSC to CCADB

[RufusJWB]

As discussed on the list (https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/XsVpyOGlagE/m/xw8JGJYZBAAJ) it seems to be reasonable to require also technically constraint sub CAs to be disclosed to CCADB if they chain up to a root in Mozilla's root store.

[RufusJWB]

@BenWilson-Mozilla as discussed on the list

[BenWilson-Mozilla]

This proposed change would also require a change in section 5 of the CCADB Policy document - https://www.ccadb.org/policy, which currently excepts from reporting when "The certificate is technically-constrained as described in section 7.1.5 of the CA/Browser Forum Baseline Requirements, ..."

[RufusJWB]

This proposed change would also require a change in section 5 of the CCADB Policy document - https://www.ccadb.org/policy, which currently excepts from reporting when "The certificate is technically-constrained as described in section 7.1.5 of the CA/Browser Forum Baseline Requirements, ..."

If I don't misread the CCADB policy, then CCADB is not forbidding to upload technically constrained CAs. They don't require it, but one can upload technically constrained CA. This would mean, we can do this change to the Mozilla Root Store Policy without adapting the CCADB policy.

[BenWilson-Mozilla]

That's fine. I don't disagree, but we ought to change it in all places so that it is consistent and clear.

[RufusJWB]

That's fine. I don't disagree, but we ought to change it in all places so that it is consistent and clear.

I can't open a PR for the CCADB policy. Can you do so?

[robstradling]

Just for reference:
This proposal was discussed a few years ago, and in https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg06905.html Gerv seemed to be in favour.
https://crt.sh/mozilla-disclosures#constrained currently shows 43 TCSCs that are in scope for the Mozilla Root Store Policy and known to crt.sh but not yet known to CCADB.

[RufusJWB]

@BenWilson-Mozilla is it truly the intend of Mozilla, that a technical constrained CA doesn't have to be audited?

[BenWilson-Mozilla]

@BenWilson-Mozilla is it truly the intend of Mozilla, that a technical constrained CA doesn't have to be audited?

I think that is currently the stated policy, although there is nothing to prevent that from changing in the future. Looking at it from a standard, WebTrust audit perspective, I think all subordinate CAs should be listed and included in the audit. However, if a CA isn't "technically capable" because it has an EKU which is not the serverAuth EKU or anyEKU EKU, then I wouldn't expect to see it in a WebTrust Baseline Requirements audit.
If a single ETSI conformity assessment is performed to cover all certificate types, then it should probably include all subordinate CAs, including those that are technically constrained.
Maybe not relevant here, but there are edge cases, too, where a CA certificate might be listed in an audit different from the one for the root that issued it. E.g. the CCADB allows specific audits to be identified for a given CA certificate, rather than having the checkbox marked for "Same audit as parent".
Finally, Mozilla is focused primarily on the websites and email trust bits. Other root stores have more reasons for why they might want to examine technically constrained CAs more closely.

[RufusJWB]

@BenWilson-Mozilla is it truly the intend of Mozilla, that a technical constrained CA doesn't have to be audited?

I think that is currently the stated policy, although there is nothing to prevent that from changing in the future. Looking at it from a standard, WebTrust audit perspective, I think all subordinate CAs should be listed and included in the audit. However, if a CA isn't "technically capable" because it has an EKU which is not the serverAuth EKU or anyEKU EKU, then I wouldn't expect to see it in a WebTrust Baseline Requirements audit.

Based on the definition of chapter 5.3.1 MRSP paragraph 2 a CA would also be "technically constrained" if it includes both: the EKU serverAuth and name constraints. This would mean, that the operation of an TLS Issuing CA with name constraints would not have to be covered by an audit. Only the issuance of this Issuing CA would be covered in the audit of the intermediate CA. And in case the issuing CA is operated by a organization different to the intermediate CA, it could end up in a situation, where a Issuing CA is operated by an organization that is not audited at all.

If a single ETSI conformity assessment is performed to cover all certificate types, then it should probably include all subordinate CAs, including those that are technically constrained.

The ETSI audit of the intermediate CA would only mention (actually I don't even see a requirement to do so), that the issuing CA was generated but it would not cover the operational compliance to the BRGs of the issuing CA.

And the same would be true for S/MIME CAs.

[BenWilson-Mozilla]

@BenWilson-Mozilla is it truly the intend of Mozilla, that a technical constrained CA doesn't have to be audited?

I think that is currently the stated policy, although there is nothing to prevent that from changing in the future. Looking at it from a standard, WebTrust audit perspective, I think all subordinate CAs should be listed and included in the audit. However, if a CA isn't "technically capable" because it has an EKU which is not the serverAuth EKU or anyEKU EKU, then I wouldn't expect to see it in a WebTrust Baseline Requirements audit.

Based on the definition of chapter 5.3.1 MRSP paragraph 2 a CA would also be "technically constrained" if it includes both: the EKU serverAuth and name constraints. This would mean, that the operation of an TLS Issuing CA with name constraints would not have to be covered by an audit. Only the issuance of this Issuing CA would be covered in the audit of the intermediate CA. And in case the issuing CA is operated by a organization different to the intermediate CA, it could end up in a situation, where a Issuing CA is operated by an organization that is not audited at all.

If a single ETSI conformity assessment is performed to cover all certificate types, then it should probably include all subordinate CAs, including those that are technically constrained.

The ETSI audit of the intermediate CA would only mention (actually I don't even see a requirement to do so), that the issuing CA was generated but it would not cover the operational compliance to the BRGs of the issuing CA.

And the same would be true for S/MIME CAs.

Does anyone have suggested language changes to propose that might address any concerns?

[RufusJWB]

@BenWilson-Mozilla is it truly the intend of Mozilla, that a technical constrained CA doesn't have to be audited?

I think that is currently the stated policy, although there is nothing to prevent that from changing in the future. Looking at it from a standard, WebTrust audit perspective, I think all subordinate CAs should be listed and included in the audit. However, if a CA isn't "technically capable" because it has an EKU which is not the serverAuth EKU or anyEKU EKU, then I wouldn't expect to see it in a WebTrust Baseline Requirements audit.

Based on the definition of chapter 5.3.1 MRSP paragraph 2 a CA would also be "technically constrained" if it includes both: the EKU serverAuth and name constraints. This would mean, that the operation of an TLS Issuing CA with name constraints would not have to be covered by an audit. Only the issuance of this Issuing CA would be covered in the audit of the intermediate CA. And in case the issuing CA is operated by a organization different to the intermediate CA, it could end up in a situation, where a Issuing CA is operated by an organization that is not audited at all.

Does anyone have suggested language changes to propose that might address any concerns?

My remarks are not 'concerns'. I'm only trying to understand the intend of Mozilla. If the intent is, that the operations of a name constrained, technically constrained TLS CA doesn't have to be audited, the current language is in principle okay. Only if this is not the intent, we would have to update the language.

[sleevi]

@RufusJWB I believe the intent is to disclose, as part of the operations of the issuing CA, all technically-constrained sub-CAs issued, not to require that the sub-CA is audited. Maybe I misunderstood #229 (comment) but I thought Ben’s remark was for possible changes in the future, not the present.

[BenWilson-Mozilla]

Does anyone have suggested language changes to propose that might address any concerns?

My remarks are not 'concerns'. I'm only trying to understand the intend of Mozilla. If the intent is, that the operations of a name constrained, technically constrained TLS CA doesn't have to be audited, the current language is in principle okay. Only if this is not the intent, we would have to update the language.

Thanks for the clarification. There may be nuanced situations that will make it important for a TCSC to be audited, so I'm not closing the door. However, Section 8 of the Baseline Requirements currently states that a TLS CA must either have an audit or be technically constrained. I am thinking that if Mozilla desired to change its policy, that we would approach the CA/Browser Forum for a discussion and ballot on this issue.

[RufusJWB]

Does anyone have suggested language changes to propose that might address any concerns?

My remarks are not 'concerns'. I'm only trying to understand the intend of Mozilla. If the intent is, that the operations of a name constrained, technically constrained TLS CA doesn't have to be audited, the current language is in principle okay. Only if this is not the intent, we would have to update the language.

Thanks for the clarification. There may be nuanced situations that will make it important for a TCSC to be audited, so I'm not closing the door. However, Section 8 of the Baseline Requirements currently states that a TLS CA must either have an audit or be technically constrained. I am thinking that if Mozilla desired to change its policy, that we would approach the CA/Browser Forum for a discussion and ballot on this issue.

Understood! Thank you for clarification. In that case, I think the proposed language of yours is totally fine.