Re: FNMT Root Inclusion Request
> + 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
Re: ComSign Root Renewal Request
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: DocuSign (OpenTrust/Keynectis/Certplus) root renewal request
Bonsoir, Le jeudi 18 février 2016 22:42:17 UTC+1, Erwann Abalea a écrit : [...] > > These certificates chain to the 'Certplus Class 2' root and contain a > > trailing space in one of their dNSName SANs: > > > > notBefore in 2016: > > https://crt.sh/?id=12994171&opt=cablint > > notBefore in 2015: > > https://crt.sh/?id=10643272&opt=cablint > > https://crt.sh/?id=9651778&opt=cablint > > Thank you for the information, we will investigate the events chains that > came to the production of these certificates. > On first analysis, it seems it's a human error during a copy/paste operation, > and a clarification of the procedures is necessary. > > The self-audit tool we use for our quarterly self-audits will also be > extended to detect that kind of defect. I forgot an update on this case. First-hand analysis was right, it was cut/paste errors. The rules were repeated to our customer service and to our customers acting as RAs. Parallel to that, we're currently modifying the configuration of what is exposed to our customers and to the customer service, to check that what is declared as an FQDN is correctly formed (only valid characters plus an optional star as leftmost label, valid total length, valid labels lengths). And the self-audit tool is being modified to detect that kind of defect. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DocuSign (OpenTrust/Keynectis/Certplus) root renewal request
Bonsoir, Le vendredi 19 février 2016 00:55:02 UTC+1, Charles Reiss a écrit : > On 02/18/16 21:40, Erwann Abalea wrote: > > Bonsoir, > > > > Le mercredi 10 février 2016 00:15:11 UTC+1, Charles Reiss a écrit : > >> On 02/09/16 20:07, Kathleen Wilson wrote: > >>> This request by DocuSign (OpenTrust/Keynectis/Certplus) is to > >>> include the following root certificates, turn on the Websites and > >>> Email trust bits for all of them, and enable EV treatment for all > >>> of them. These new certs will eventually replace the 'Certplus > >>> Class 2' root certificate that was included via Bugzilla Bug > >>> #335392. + Certplus Root CA G1 - (SHA512, RSA4096) + Certplus > >>> Root CA G2 - (SHA384, ECC) + OpenTrust Root CA G1 - (SHA256, > >>> RSA4096) + OpenTrust Root CA G2 - (SHA512, RSA4096) + OpenTrust > >>> Root CA G3 - (SHA384, ECC) > >>> > >>> Previously the company was known as Keynectis, with the Certplus > >>> and OpenTrust brands, issuing certs to public or private > >>> corporations, associations. > >>> > >>> Ownership changed November 3, 2015, from Keynectis to DocuSign > >>> France, which was acquired by DocuSign Inc. The root keys > >>> remained at the same physical location operated by the same team. > >>> During the transfer of activity, all past agreements/contracts > >>> and so on remain available. People linked to this activity were > >>> also transferred to the new company. > >>> > >>> The request is documented in the following bug: > >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1025095 > >>> > >>> And in the pending certificates list: > >>> https://wiki.mozilla.org/CA:PendingCAs > >>> > >>> Summary of Information Gathered and Verified: > >>> https://bugzilla.mozilla.org/attachment.cgi?id=8692112 > >>> > >>> Noteworthy points: > >>> > >>> * The primary documents are the RCA CP, SSL CP, and EV CPS. > >>> Documents are provided in French and some are translated into > >>> English. > >>> > >>> Document Repository (French): http://www.OpenTrust.com/PC > >>> Document Repository (English): > >>> https://www.opentrustdtm.com/security-policies/?lang=en RCA - > >>> Root Certificate Authorities - CP (English): > >>> https://www.opentrustdtm.com//wp-content/uploads/2015/03/OpenTrust_DMS_RCA-Program_OpenTrust_CP-v-1.2s2.pdf > >> > >> > >> > >>> My reading of section 8.1 of the CP is that if CA is > >> - _not_ technically constrained (as defined by Mozilla); and - not > >> "issuing SSL certificates" (e.g. a CA lacking any EKU or name > >> constraints that only issues certificates to individuals), then, it > >> can be audited only by auditors who do not meet Mozilla's > >> definition of an independent auditor. (8.2 allows internal auditors > >> to be only "sufficiently organizationally separated from that > >> entity to provide an unbiased, independent evaluation", which seems > >> like it could include a CA employee.) Is this correct? > > > > For CAs not issuing TLS certificates, an internal audit is performed, > > as permitted by Mozilla's definition of an independent auditor. See > > Mozilla Inclusion Policy version 2.2, items 11, 12, 13, and 14. > > Mozilla's definition of independent auditor requires that the auditor " > not [be] affiliated with the CA as an employee or director". I assume > that this will be the case for subCAs for which an internal audit is > performed by virtue of the audit being performed employees of the parent > CA, a different company. > > I don't believe having CAs audit their unconstrained subCAs is within > the spirit of Mozilla's policy (since a sufficiently non-compliant subCA > is an existential risk to the parent CA) though it is probably > technically in conformance. > > I assume you believe the internal audit fits the third option of item > 14's second requirement: "the party is bound by law, government > regulation, and/or a professional code of ethics to render an honest and > objective judgement regarding the CA" (since I imagine you aren't going > to be disclosing your financial relationship with external subCAs). Can > you identify what law, regulation, or code of ethics is involved? Our Root CA and intermediate CAs are ETSI TS 102042 compliant, and the audit is performed by an external auditor (LSTI). As described in our CP (section 8), we have an internal organization that allows fulfilling the requirements set in ETSI TS 102042 section 7.5, including the independence of trusted roles regarding to any "commercial, financial, or other pressures which might adversely influence trust in the services it provides." The organization team at DocuSign France performing the internal audits and validating the CP/CPS is the PMA (Policy Management Authority), and has no hierarchical relationship with the department operating the CAs. This is also in line with TS 102042 section 5.4.1). This requirement is verified during the annual ETSI TS 102042 audit performed by the external auditor. > [snip] > > > >> Section 9.3.3 of this CP states in par
RE: SHA-1 S/MIME certificates
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 technically restricted SHA-
Re: SHA-1 S/MIME certificates
On 05/04/2016 04:16, Jeremy Rowley wrote:
Note that is only for roots submitted after Jan 1, 2016. Roots submitted prior
to Jan 1 2016 are unaffected.
Which part of the long text below is only for roots submitted after Jan
1, 2016???
-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 technically restricted SHA-1 SubCA that chains to an
