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
