Eddy,
        You said:
> - Unlucky formulation of "4.2.1 Secure Server Certificates Validation
> Process" (Code Signing versus Server Certs).
I agree.  4.2.1 could do with a different sub-title, given its frequent re-use.

> - Subsection 1 doesn't apply I guess.
Subsection 1 did not apply for code signing certificates for a long time, but 
for the last few months we have been doing a subsection 1 validation check on 
the domain name used in the applicant email address (which is also the one that 
usually goes in the subject of the code signing certificate).  We are acutely 
aware of the growing prevalence of the use of code-signing certificate in 
malware of all sorts.  
We have various other checks in this area which we apply in addition to those 
explicitly mentioned in the CPS.  I appreciate that doesn't help you much 
because we wouldn't disclose them publicly, but they are disclosed to our 
WebTrust auditors during our audits and we would probably be prepared to 
discuss them further with Mozilla (and other browser / OS providers) under NDA.
We also have means whereby we are able to spot the misuse of our code-signing 
certificates at an early stage.  We revoke code-signing certificates and push 
new CRLs out at very short notice when we become aware of fraud / malware 
involving them.

> - Subsection 2 says:
> 
>     The applicant is an accountable legal entity, whether an
>     organization or an individual.
>     • Validated by requesting official company documentation, such as
>     Business License, Articles of Incorporation, Sales License or other
>     relevant documents.
>     • For non-corporate applications, documentation such as bank
> statement,
>     copy of passport, copy of driving license or other relevant
> documents.
> 
> Further it says:
> 
>     The above assertions are _*reviewed through an automated process*_,
>     manual review of
>     supporting documentation and reference to third party official
>     databases.
That's good general stuff which would cover almost anything we wanted to do 
with it really!
The only automated processes which occur now are to avoid the unnecessary 
duplication of validation work.  To try and clarify that a little, when we 
undertake some validation work we give that information a lifetime.  If we 
check the existence of a legal domain, or domain ownership, we will not repeat 
that work if the same organization buys another certificate within some 
prescribed timescale.  Obviously if they buy for a different domain then we 
have to validate the new domain - but we can rely on the validation work done 
for the earlier purchase for the validation of the legal entity.

> Scrolling further down to 4.2.8 (applies to Code Signing Certificate /
> Time Stamping Certificate):
> 
>     Code Signing Certificates and Time Stamping Certificates are
>     processed by a Comodo validation officer in accordance with the
>     process outlined in section 4.2.1 of this CPS.
> 
> OK, I was at 4.2.1 already, Comodo received and reviewed the material
> received and referenced to third party sources.
> 
>     Comodo may employ the data held by IdAuthority to expedite the
>     validation process. _*If application data matches the records*_
> held
>     by IdAuthority, _*manual validation intervention is not required*_.
>     In the event that the application data does not match the
>     pre-validated records, the application is processed manually by a
>     Comodo validation officer in accordance with the process outlined
> in
>     section 4.2.1 of this CPS.
I'm afraid that the important word there with relation to our current 
validation procedures is "may".  "Comodo *may* employ the data held by 
IdAuthority".  We don't any more.  We found that it ceased to be cost effective 
to keep the quality of the information in the IdAuthority database at a high 
enough level that we could use it as a source of validation information.

> 
> Again I'm pointed to 4.2.1...
> 
> IdAuthority = "contains records of over 5 million unique legal entities
> sourced from a combination of publicly available resources. Where
> possible, _*the directory will be used to confirm the identity of a
> certificate applicant*_. If the directory cannot be used to
> sufficiently
> validate a certificate applicant, further validation processes will be
> used. These may include an out of bands validation of the applicant’s
> submitted information."
> 
> I'm missing here an important step in these validation procedure. Can
> Comodo explain how it establishes the connection between the applicant
> and the documents received on one side and through its automated
> process, its own database of information and third party databases on
> the other side? Please point me to the exact reference in the CPS since
> I most likely missed it.
I know you will find this disappointing, but I'm going to point you back to 
4.2.1 again.  Any internal databases that we refer to for validation 
information are just snapshots in time of the same information we gather for 
4.2.1.  IdAuthority (when it was in use as a source of validation information) 
was just a bulk snapshot of information that we would have gathered for 4.2.1.
The 3rd party databases mentioned are the domain registries (for Whois records) 
or the jurisdictions of incorporation (for evidence of legal existence and 
correctness of address details, etc, of the legal entity).

Regards
Robin Alden
Comodo CA Ltd.

_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to