RE: SHA-1 S/MIME certificates

2016-04-04 Thread Jeremy Rowley 
Note that is only for roots submitted after Jan 1, 2016. Roots submitted prior 
to Jan 1 2016 are unaffected. 

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Jakob Bohm
Sent: Friday, April 1, 2016 4:55 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: SHA-1 S/MIME certificates

On 01/04/2016 12:44, Varga Viktor wrote:
> Hi,
>
> My replies are inline marked with ***
>
> regards, Viktor Varga / Netlock
>
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+varga.viktor=netlock...@lists.mozi
> lla.org] On Behalf Of Jeremy Rowley
> Sent: Wednesday, March 30, 2016 10:54 PM
> To: Jakob Bohm ; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: SHA-1 S/MIME certificates
>
> I think a required move away from SHA1 client certs requires a bit more 
> planning.
>
> 1) There hasn't been a formal deprecation of all SHA-1 certificates in any 
> root store policy. There has been a formal deprecation by the CAB Forum of 
> SHA1 server certificates. Considering many of the client cert issuance is 
> governed by various national schemes (FBCA in the US and the Qualified Cert 
> program in the EU), care is necessary in enacting policies that impact the 
> use of client certificates. Although I recognize the need for Mozilla to 
> ensure a safe onine experience for all its users, I'm sure they don't want to 
> undermine entire trust frameworks built on these certificates. (Yes, I know 
> FBCA requires SHA2 now).
>
> *** Dont forget, that the roots doesn't needs to be deprecated because their 
> signing algorithm.
> *** The roots are not trusted because their algorithms, they are trusted 
> because CAs are enrolled in root programs, and the root certificates are 
> physically in your browser.
> *** So for the roots, the algorithm on itself doesnot counts on deprecation, 
> but the key length should large enough.
>
> *** Also dont forget, that the Microsoft is also removing the old roots, and 
> the Apple does the same, but they are asking CAs about the remove, not 
> publishing anyone.
>

Microsoft has deprecated SHA-1 in the root store policy for roots with the 
"code signing" trust bit, but only for the root stores on Windows 7 or later, 
and with special exceptions for roots that are in both Vista and Windows 7 
stores.  In fact Microsoft has phrased their entire SHA-1 deprecation policy as 
a change in their root store policy, even the parts that describe changes in 
the acceptance of end certificates on a context specific basis.

> 2) The browsers are already deploying code to reject SHA1 certificates 
> encountered. If this is true, what is the harm in continued SHA1 client 
> certificate issuance until the national schemes have all updated their 
> requirements? Mozilla is protected but the national bodies (and financial 
> institutions) can continue using their software for client authentication. I 
> do think we should move to SHA2, but I don't think the prior notice has 
> occurred with respect to SHA1 client certs.
>
> *** In Hungary, we had legislation to use sha256 only, so we completely moved 
> to sha256.
>
> *** I think ist much bigger problem for the usage of certs is the same origin 
> policy.
> *** The remove of NPAPI, Java support and the windows.crypto gives the real 
> problem for web applications here in Hungary, especcially for the 
> governmental applications, because the are using one of the technologies i 
> mentioned, and the need to move on quickly.
>

Fortunately, there are Mozilla forks which maintain at least NPAPI.

>
> On 30/03/2016 18:49, Kathleen Wilson wrote:
>> All,
>>
>> In response to the 'March 2016 CA Communication' I received the 
>> following question from a CA. I think we should discuss it here, 
>> because I suspect there will be other CAs in this same situation.
>>
>>   > We have a problem since we still issue SHA-1 S/MIME  > 
>> certificates. Do we really have to stop issue after 2017?
>>
>> I will appreciate your thoughtful and constructive input into setting 
>> reasonable expectations for CAs in regards to SHA-1 S/MIME certificates.
>>
>> Thanks,
>> Kathleen
>
> I would suggest the following minimum requirements:
>
> 1. Any 3rd party certificates using outdated certificate signing
> algorithms (such as certificates signed using SHA-1) must be issued
> under dedicated subCAs with as many technical constraints in the
> subCA's certificate validity as possible, such as restrictions in key
> usage, extended key usage, subCA validity period and distinguished
> name ("path name restrictions").  Mozilla will allow the issuing and
> reissuing of a reasonably low number of such SubCAs, provided they
> chain only through and to certificates that use the same or older
> outdated signing algorithm.  (For example SHA-1 certificates should
> be issued by a

Re: ComSign Root Renewal Request

2016-04-04 Thread Andrew R. Whalley 
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  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

Re: FNMT Root Inclusion Request

2016-04-04 Thread rafamdn 
> + AC RAIZ FNMT-RCM
>+ AC Administración Pública
>  - Issues: SSL certs, QCP certs
>  - Audits: WebTrust for CAs, WebTrust SSL BRs, ETSI 101 456
>+ AC Componentes Informáticos
>  - Issues: SSL certs
>  - Audits: WebTrust for CAs, WebTrust SSL BRs
>+ AC FNMT Usuarios
>  - Issues: issues QCP certs, not restricted by EKU extension
>  - Audits: (ETSI 101 456 or WebTrust for CAS) and audit of non-existence 
> of SSL certs
>+ ISA CA Will be revoked in early 2016
>+ AC APE No longer used. Will be revoked in early 2016 

According to the plan, last week "AC APE" subordinate CA was revoked.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy