Thanks Kathleen,

I have briefly inspected this BR Self Assessment document. Nothing terrifying 
leaped out at me that would lead me to ask that Mozilla deny the renewal, 
however I did find things worth mentioning here.

The only listed 3.2.2.4 method is 3.2.2.4.5, Domain Authorization Document. 
This explains why Certigna has chosen to outsource the validation to an RA, the 
documents for 3.2.2.4.5 might require local expertise to obtain and interpret, 
as distinct from technical and automatable methods like 3.2.2.4.10. 
Nevertheless, involvement of human agents is always a weak point in security 
systems, we saw with Symantec that problems can arise if the CA outsources this 
work but doesn't make the effort to inspect what is being done on their behalf. 
So we need to keep a particular eye on the results.

AFNIC is mentioned by name. I understand that Certigna specialises in 
particular in French-speaking locales (maybe mostly ex-French colonies?) but 
it's not obvious to me in these documents whether Certigna by policy doesn't 
issue certificates for names that aren't under AFNIC's control. If not, why 
call them out particularly?


For 3.2.2.6 Wildcard Domain Validation the submission responds with a lot of 
content about validation of identities. Section 3.2.2.6 actually concerns 
special considerations for the dnsName wildcard, such as verifying whether the 
requested wildcard is for a Public Suffix or Registry-controlled Label. It is 
important that the CA has some procedure to avoid issuing, for example, *.co.uk 
or other wildcards that must not exist and this procedure should be in their 
policy documents AND the relevant sections highlighted in the assessment. Is 
this an error by Certigna? Or do I misunderstand the requirement here?

For 4.2.1 Mozilla's document specifically requests information about the CA's 
policy for High Risk Certificate Requests. Nothing is indicated about this. [ 
Kathleen: Consider *bolding* the relevant text for emphasis so that it stands 
out from cells which are just repeating the relevant RFC section header name? ]

For 4.9.{2,3} We need clarity on how Relying Parties, including but not limited 
to people who read m.d.s.policy can report a problem with a certificate despite 
not being the subscriber or a representative of the subscriber. This isn't 
listed - but maybe it is actually documented somewhere? I think previous 
m.d.s.policy discussions found that the most appropriate thing is to supply an 
email address to which such problems can be reported.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to