Hello Jesus,
Great points!
> Reviewing the BR audit report of Comsign Ltd I have a few doubts regarding
> the audits accepted by Mozilla and may someone can help me.
>
> The BR audit was conducted according to the WebTrust forCertification
> Authorites - SSL Baseline Requirements Audit Criteria version 1.1 and it's a
> point-of-time (as of April 26, 2015).
> Although this audit criteria is accepted according to the Mozilla CA
> Certificate Inclusion Policy 2.2, the BR audit version 1.1 was superseded by
> Webtrust SSL Baseline with Network Security version 2.0 (effective for audit
> periods starting on or after July 1, 2014).
>
> Webtrust audit criteria states that "The point-in-time readiness assessment
> shall be completed no earlier than twelve (12) months prior to issuing
> Publicly-Trusted Certificates and shall be followed by a complete audit under
> such scheme within ninety (90) days of issuing the first Publicly-Trusted
> Certificate. (See SSL Baseline Requirements Section 17.4)". Should Mozilla
> expect a complete audit 90 days after the point-in-time BR audit report or
> after the first certificate (I don't know when was issued)?
Neither of the other audit reports I can find by Sharony - Shefler & Co, for
"ComSign CA" (https://bugzilla.mozilla.org/attachment.cgi?id=868616) and
"Comsign Secured CA" (https://bugzilla.mozilla.org/attachment.cgi?id=8686170),
give an audit duration and only state a point in time.
Eli, please confirm when we can expect a period audit and what period it will
cover.
> In addition and regarding the OCSP Responder certificate with Serial Number:
> 0e:2b:cd:a4:aa:4f:8f:80:da:16:94:4e:ba:33:35:33, the validity is 3 years.
> According the RFC 6960 "A CA may specify that an OCSP client can trust a
> responder for the lifetime of the responder's certificate. The CA does so by
> including the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical
> extension. The value of the extension SHALL be NULL. CAs issuing such a
> certificate should realize that a compromise of the responder's key is as
> serious as the compromise of a CA key used to sign CRLs, at least for the
> validity period of this certificate. CAs may choose to issue this type of
> certificate with a very short lifetime and renew it frequently." Which is the
> maximum acceptable lifetime for this type of certificates that contains the
> id-pkix-ocsp-nocheck extension?
Three years seems excessive, but doesn't appear to be uncommon:
http://ocsp.entrust.net
Not Before: Jun 4 19:15:34 2015 GMT
Not After : Jun 4 19:45:34 2017 GMT
http://crl.quovadisglobal.com/qvocag2.crl
Not Before: May 28 14:33:37 2014 GMT
Not After : May 28 14:33:37 2017 GMT
And there are some are valid for much longer:
http://root-c3-ca2-2009.ocsp.d-trust.net
Not Before: Jul 2 10:03:07 2013 GMT
Not After : Nov 5 08:35:58 2029 GMT
It sounds like limiting the validity period of OCSP signing certs would be an
excellent topic to discuss generally, but I don't consider it a blocking issue
for this application.
Andrew
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
