On 05/05/17 18:58, Peter Bowen wrote: >> Right now the policy does not require disclosure of CA-certificates >> that the CA deems are technically constrained.
I believe this was made the case for some mix of the following reasons: a) the CA did not want to reveal every customer it had; b) this would significantly increase the volume of disclosure required; c) we didn't think we needed to know about these. >> We have seen numerous >> cases where the CA misunderstood the rules or where the rules had >> unintentional gaps an disclosing the certificate as constrained will >> allow discovery of these problems. For example the current policy >> says "an Extended Key Usage (EKU) extension which does not contain >> either of the id-kp-serverAuth and id-kp-emailProtection EKUs" which >> means a certificate that has EKU extension with only the >> anyExtendedKeyUsage KeyPurposeId fall outside of the scope. This is >> obviously wrong, but would not be discovered today. Is it obviously wrong? Firefox doesn't respect anyEKU. OTOH, Kathleen recently told me that she feels that because the Mozilla root store is used by others, we should continue to keep anyEKU intermediates in scope. But do you think Mozilla also needs to know about these for Firefox/Thunderbird purposes? If so, why? >> The flow chart at https://imagebin.ca/v/3LRcaKW9t2Qt shows my proposal for >> disclosure; it is a >> revised version from the one I posted to the CA/Browser Forum list and >> depends on the same higher level workflow Apologies that your message got held up. Looking at that flowchart: * Does "Log certificate" mean "in CT"? * The "Subject/Key list" is the list of intermediate certs which need to be disclosed? * This diagrem represents your proposal, not the status quo? Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
