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