It looks like https://fedir.comsign.co.il/test.html is trusted by OS X, which for me meets the criteria for a PubliclyâTrusted Certificate. That certificate was issued on 2nd Feb, so I presume the 90 day clock is ticking.
Andrew R. Whalley | Crypto Wrangler | Chrome Networking and Security | +1 415-736-7248 On Wed, Mar 30, 2016 at 12:20 AM, Eli Spitzer <elis.co...@gmail.com> wrote: > 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 > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
