On Wednesday, March 30, 2016 at 4:36:44 AM UTC+3, Andrew Whalley wrote: > 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
Hello Andrew and Jesus, As mentioned, the Audit reports that we have are only Point-in-Time reports. We haven't started issuing public certificates yet, and at the moment we are not planning to do so until the inclusion in the Mozilla Root program. Once we finish the inclusion process and start issuing public certificates we will conduct a period audit as required by WebTrust BR Eli _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
