Re: Include Renewed Kamu SM root certificate

[tugba onder via dev-security-policy]

Hi Ryan,
 
>Right, but the reason I highlighted this is that the audit noted 
>conformance to v1.4.1, but the process you described wasn't consistent with 
>v1.4.1. It's understandable that the auditable controls for 1.4.1 have not 
>been developed, so I'm not particularly surprised that this wouldn't have 
>been called out in the audit, but it did highlight a divergence between the 
>statement as to how you validate domains and the stated compliance.
 
 
- Yes, our annual audit report states that we are in compliance with CAB Forum 
1.4.1 and in CAB Forum v1.4.1 section 3.2.2.4 it states that: 
 
"The CA SHALL confirm that as of the date the Certificate issues, either the CA 
or a Delegated Third Party has validated each Fully-Qualified Domain Name 
(FQDN) listed in the Certificate using at least one of the methods listed 
below." 
 
Here, the part that needs to be taken care is "validate using at least one of 
the methods listed". Although we mentioned it in our previous response, I guess 
you missed it; we do not make verification just with respect to 3.2.2.4.6. For 
the further satisfaction of 3.2.2.4, we first apply 3.2.2.4.1, then 3.2.2.4.3 
or 3.2.2.4.4 and then 3.2.2.4.5. Therefore, even if we do not implement 
3.2.2.4.6 at all, we satisfy the condition "validate using at least one of the 
methods listed" in 3.2.2.4.
 
While we are implementing 3.2.2.4.6, we generate the "Required Website Content" 
concept described in ballot 169, including only the information that uniquely 
identifies the subscriber without a random value or request token. This 
practice comes from item 6 of section 3.2.2.4 of BR v1.3.7. The important thing 
that should be noted here is, the use of random value or request token is 
coming with ballot 169. The effective date for ballot 169 was 1 March 2017, and 
the date on which we have received our audit report was December 2016, before 
the effective date. 
 
Although we satisfy 3.2.2.4 by implementing multiple choices at the same time, 
we believe, not necessarily but additionally implemented current version of 
3.2.2.4.6, even if it is not fully consistent with the latest version, will 
bring more security than the case it was never implemented. But we will also 
fix it. 
 
Similarly, at the time audit report was produced, Section 10.3 ("End Entity 
SSL Certificate Template") was not consistent with Section 1 (current BRs). 
 
Throughout the Mozilla Root Certificate Program, we have tried to fulfill all 
requests with great appreciation. We believe this program, its partners, public 
reviewers and also CA communications serve in the name of ensuring the 
security, applicability, and interoperability by forcing CA/B Forum BR and make 
CAs' fix their inconsistencies, if there exists, according to the updated BRs'. 
We have considered Andrew's warning in this manner and deployed early 
implemented but not deployed 64-bit random number in serial instead of early 
deployed 32-bit. If you consider any other inconsistencies, please inform us, 
we will appreciate it.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy