SHA-1 S/MIME certificates

[Kathleen Wilson]

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

[Kathleen Wilson]

I am, indeed, receiving this question from multiple CAs.

As for responding to the survey, note that Action #1a and Action #1b ask for dates regarding SHA-1 SSL certs (unless their included root certs do not have the Websites trust bit set).

"ACTION #1a: ... Please enter the last date that a SHA-1 based TLS/SSL certificate was issued that chained up to your root certificates included in Mozilla's program. ..."

"ACTION #1b: ... Enter the date when all of the SHA-1 based TLS/SSL certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked. ..."

ACTION #1c is where CAs should provide information about their plans regarding SHA-1 S/MIME certificates, and any other types of SHA-1 certificates still being issued that chain up to the CA's included root certificates.

I will greatly appreciate your input as to what would be reasonable expectations for CAs in regards to SHA-1 S/MIME certificates.

Thanks,
Kathleen

[Jakob Bohm]

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
old SHA-1 (or older) root cert).

2. Any 3rd party certificates using outdated certificate signing
algorithms (such as certificates signed using SHA-1) must include CA
generated random values that are not known by the 3rd party prior to
issuance (and thus prior to request generation). Any such random
values must contain the same number of bits as the signing hash (e.g.
20 bytes/160 bits for SHA-1 signed certificates). Any such random
values must occur before most (preferably all) 3rd party supplied
fields to protect against prefix collision based attacks. In
practice, placing the first 160 random bits in the certificate serial
number, adding the next 12 random bits to the "NotBefore time" as a
count of seconds, the next 12 random bits to the "NotAfter time" as a
count of seconds and inserting any remaining bits as an early element
in the subject distinguished name would be the closest allowed by
X.509v3 and older.

3. Document, for each such external usage the exact technical reason
why subscribers are presumed unable to use certificates using modern
algorithms. For example: "These certificates are for US medical
persons needing access to the US FDA server at foo.bar.gov, which
does not accept better algorithms" . Or "These certificates are
exclusively for users communicating with users of the Microsoft
Office 2007 Outlook MUA, which does not support better algorithms"

4. Any CA internal certificates using outdated certificate signing
algorithms (such as certificates signed using SHA-1) must be issued
in a very minimal count and with short validity periods (1 to 16
months), even though this would imply more frequent reissuing. Any
such internal CA certificates must serve a specific purpose in
servicing existing or acceptable certificates using such algorithms,
such as OCSP signing, online timestamping or the restricted subCAs
specified by rule 1 above). Additional administrative procedures
must be used to prevent the internal requests for such certificates
from being generated with malicious content, for example they might
be generated only by specially trusted hardware with private keys
securely transported to the point of usage after issuance.

5. Any other CA usage of outdated signing algorithms in signatures
traceable to Mozilla trusted roots must be done in the minimal count
possible and only to serve a specific purpose in servicing existing
or acceptable certificates using such algorithms, such as CRL signing
or OCSP signing where a documented technical reason must be given for
not making such signatures using dedicated certificates (for example,
a specific named client implementation might fail to accept OCSP
responses and/or CRL signatures not signed directly by the CA).
As an example of reducing the frequency of such signatures, CRLs
might be issued with longer than usual refresh intervals for older
CAs that have few remaining valid certificates and are mostly
reissuing CRLs to provide trusted lists of historic revocation dates.

6. Any other CA usage of outdated signing algorithms in signatures
traceable to Mozilla trusted roots must include CA generated random
values that are not known by the 3rd party prior to issuance (and
thus prior to request generation). Any such random values must
contain the same number of bits as the signing hash (e.g. 20
bytes/160 bits for SHA-1 signed certificates). Any such random
values must occur before most (preferably all) 3rd party supplied
data elements to protect against prefix collision based attacks. For
example CRLs could include revocation of one or more never-issued
certificates with random serial numbers at both ends of the CRL.
Similarly, OCSP responses for actually issued certificates should be
pre-generated independent of incoming OCSP requests and include the
random values as close to the beginning of the response as
technically possible. Dynamically generated OCSP responses (for
multiple certicates, never-issued certificates etc.) should include a
random value before any request-supplied values totaling more than
half the number of bits in the signing hash.

7. Mozilla would prefer if issuers of such certificates with outdated
signing algorithms stand up a new root certificate, which is
self-signed with a modern signing algorithm and will not be used to
sign (directly or indirectly) certificates with lesser algorithms.
The CA should also publish a date after which the old root cert used
for issuing certificates with lesser signing algorithms will no
longer be the root of still-valid certificates with modern signing
algorithms. Mozilla will remove most trust bits from the old root
certificate on or before that date, but will include (in its master
list, but not necessarily in its software releases) an indication of
the extent to which the old root certificate is valid for
(re)checking old data provably from before the cut-off date, such as
externally time stamped documents and/or recipient time-stamped
e-mails.

8. When standing up such a replacement root CA, Mozilla will understand
that the switch to using the new root CA for issuing certificates
with modern signing algorithms will be delayed by the time it takes
to deploy the new root in all relevant software releases and updates,
not just those of Mozilla. For example use of a new root CA for
signing S/MIME e-mail certificates would await its inclusion in both
Mozilla Thunderbird, the vast majority of 3rd party e-mail clients
and the OS level root CA list of most operating systems releases,
such as Microsoft Windows and the various Linux distributions.

9. All procedures performed to comply with the above rules must be
documented in the relevant CPS and verified by the annual audit.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Jakob Bohm]

On 30/03/2016 22:53, Jeremy Rowley wrote:
> 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).
>

OK, it seemed like others in this newsgroup/on this list were acting
like the deprecation by the CAB/F applied to non-TLS certificates.

My proposed rules were intended for an environment in which such
deprecation exists.

> 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.
>

Indeed, hence the proposed requirements to clearly isolate SHA1
certificates to old SHA1 roots, especially considering the existence of
other trust lists than the one from Mozilla, and other X.509
implementations than the one written by Mozilla (Considering the
likelihood/fact of other implementations only deprecating SHA1 at
specific chain levels).

> 3) Because Mozilla doesn't have a policy against reissuance of SHA1 intermediates for client certificates, I don't think your suggestion to only permit reissuance of limited SHA1 intermediates is feasible. I do think requiring a constraint against general SHA1 intermediates (that lack technical restrictions to prevent server certs) is a good idea to ensure the intermediates are only used for s/MIME or code signing.
>

Again the proposal was for an environment where such (re)issuance would
otherwise be deprecated and discouraged.

The phrasing was intended to permit the level of technical restrictions
relevant to the uses that would be documented. For example some subCAs
could be restricted to S/MIME only (think e-mail only subCAs target at
older e-mail clients enumerated in the reason text). Some other subCAs
could be restricted to e.g. C=US subjects doing TLS client auth (for
use with a specific broken US government services enumerated in the
reason text) etc.

> 4) Documenting why outdated algorithms/key sizes/anything else are used always ends up being "For support of legacy devices". I don't see much value in that. It becomes an exercise in creating an automatic label applied to each certificate.
>

The phrasing was intended to require more specific reasons, naming the
relevant "legacy devices" and/or "legacy software", with different
SubCAs for different groups of such legacy parties. This in turn would
be intended to facilitate easy determination of when the various
categories of legacy parties cease to exist in practice.

Other proposed rules were about establishing practices that prevent the
various known types of attacks on SHA-1 and other recently broken hash
algorithms, such that it becomes less likely that someone would
succesfully request a certificate or other SHA-1 signed message on data
specially constructed to allow the attacker to convert this into
something that the CA would never have signed.

Those more informed than me about the workings of the known attacks
should check the sufficiency of these rules in stopping the known
attacks (including almost-ready attacks likely to become reality soon).


> In all, I think clientAuth certs are different than serverAuth certs. CAs issuing clientAuth certs wouldn't necessarily be aware of the intent to deprecate. I also do not think Mozilla has as large of stake in client certificates as it does server certs. Therefore, any plan to move away from SHA1 client certs should start with:
> A) An announcement that client certs will be deprecated

If not yet made, I would expect such an announcement to be forthcoming
from someone.

> B) A question to the public about what software is still requiring the use of SHA1 certs and the impact of requiring SHA2 certs, and

I believe that some CAs have already done a lot of published research
on this issue. For instance GlobalSign has published their findings on
their web page, and my examples were based on my (imperfect)
recollection of that page.

> C) A date when SHA1 client certs will be deprecated
>
> Again, I'm not opposed to moving to SHA2 client certs, but I don't think Mozilla has conveyed to the public its intent to do so.

>
>
> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of Jakob Bohm
> Sent: Wednesday, March 30, 2016 12:06 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: SHA-1 S/MIME certificates
>
> On 30/03/2016 18:49, Kathleen Wilson wrote:

[Kathleen Wilson]

On 3/30/16 1:53 PM, Jeremy Rowley wrote:
> 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).
>

> 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.
>

> 3) Because Mozilla doesn't have a policy against reissuance of SHA1 intermediates for client certificates, I don't think your suggestion to only permit reissuance of limited SHA1 intermediates is feasible. I do think requiring a constraint against general SHA1 intermediates (that lack technical restrictions to prevent server certs) is a good idea to ensure the intermediates are only used for s/MIME or code signing.
>

> 4) Documenting why outdated algorithms/key sizes/anything else are used always ends up being "For support of legacy devices". I don't see much value in that. It becomes an exercise in creating an automatic label applied to each certificate.
>

> In all, I think clientAuth certs are different than serverAuth certs. CAs issuing clientAuth certs wouldn't necessarily be aware of the intent to deprecate. I also do not think Mozilla has as large of stake in client certificates as it does server certs. Therefore, any plan to move away from SHA1 client certs should start with:
> A) An announcement that client certs will be deprecated

> B) A question to the public about what software is still requiring the use of SHA1 certs and the impact of requiring SHA2 certs, and

> C) A date when SHA1 client certs will be deprecated
>
> Again, I'm not opposed to moving to SHA2 client certs, but I don't think Mozilla has conveyed to the public its intent to do so.
>
>

I think Jeremy is correct, that Mozilla's previous communications about
SHA-1 certs was only in regards to TLS/SSL certs.

Would anyone object to me changing Actions 1a and 1b to the following?
(note, using date 2016-04-01 for the CAs who don't have the Websites
trust bit enabled will make it so we can easily filter out those responses)
~~
ACTION #1a: As previously communicated, CAs should no longer be issuing
SHA-1 certificates chaining up to root certificates included in
Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as
well as any intermediate certificates that they chain up to. Check your
systems and those of your subordinate CAs to ensure that SHA-1 based
TLS/SSL certificates chaining up to your included root certificates are
no longer being issued, and that any such certificates issued after
2016-01-01 have been revoked. Please enter the last date that a SHA-1

based TLS/SSL certificate was issued that chained up to your root

certificates included in Mozilla's program. If your included root
certificates do not have the Websites trust bit enabled, then please
enter 2016-04-01. (Required)


ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL

certificates that chain up to your root certificates included in

Mozilla's CA Certificate Program will either expire or be revoked. If
your included root certificates do not have the Websites trust bit
enabled, then enter 2016-04-01.

As previously communicated we plan to show the “Untrusted Connection”
error whenever a SHA-1 certificate is encountered in Firefox after
January 1, 2017.

We recommend that you put safeguards into place that will prevent the
future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1
based intermediate certificates that chain up to your root certificates
included in Mozilla's CA Certificate Program. (Required)

~~


I think we can keep Action 1c as-is, because option (d) should capture
information about issuance of S/MIME certs.


Thanks,
Kathleen

[Andrew R. Whalley]

On Wed, Mar 30, 2016 at 2:23 PM, Kathleen Wilson <kwi...@mozilla.com>
wrote:

Looks reasonable to me.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Kathleen Wilson]

On 3/30/16 4:57 PM, Andrew R. Whalley wrote:
> On Wed, Mar 30, 2016 at 2:23 PM, Kathleen Wilson <kwi...@mozilla.com>
> wrote:
>
>> On 3/30/16 1:53 PM, Jeremy Rowley wrote:

>> ...

>> I think Jeremy is correct, that Mozilla's previous communications about
>> SHA-1 certs was only in regards to TLS/SSL certs.
>>
>> Would anyone object to me changing Actions 1a and 1b to the following?
>>
>
> Looks reasonable to me.
>

I updated Actions 1a and 1b in the survey to remove 'S/MIME' from a
couple sentences, and to ask the CAs who don't have the Websites trust
bit enabled to use the date 2016-04-01.

https://wiki.mozilla.org/CA:Communications#March_2016

Thanks,
Kathleen

[Charles Reiss]

On 03/30/16 20:53, Jeremy Rowley wrote:
> 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).

Is issuing non-SHA-1 certificates proscribed by any of these national
schemes? Have any of these national schemes not contemplated a
transition away from SHA-1 for many years?

> 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.

I'd guess that many non-browser users (e.g. curl/wget on many Linux
distros) of Mozilla's root store will continue to accept SHA-1 server
certificates and/or OCSP responses for quite a while after Mozilla's
browsers start rejecting them.

[Varga Viktor]

Hi,

My replies are inline marked with ***

regards, Viktor Varga / Netlock

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+varga.viktor=netlo...@lists.mozilla.org] On Behalf Of Jeremy Rowley
Sent: Wednesday, March 30, 2016 10:54 PM
To: Jakob Bohm <jb-mo...@wisemo.com>; mozilla-dev-s...@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.

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.

On 30/03/2016 18:49, Kathleen Wilson wrote:

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
old SHA-1 (or older) root cert).

*** just one suggestion: define a minimum key length also.

WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________

[Jakob Bohm]

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=netlo...@lists.mozilla.org] On Behalf Of Jeremy Rowley
> Sent: Wednesday, March 30, 2016 10:54 PM
> To: Jakob Bohm <jb-mo...@wisemo.com>; mozilla-dev-s...@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
> old SHA-1 (or older) root cert).
>
>
> *** just one suggestion: define a minimum key length also.

Indeed, hence why I keep saying "outdated certificate signing
algorithms" with SHA-1 as just a current example.

[Steve]

Using the same language I would, because browser is too narrow a definition
of the public trust network, root store policy is a term that some would
call browser policy. The reference is to any organization that explicitly
trusts a collection of roots and sets policies to retain that trust. It
doesn't refer to the actual roots themselves.

> 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.
>
>

> On 30/03/2016 18:49, Kathleen Wilson wrote:

> 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
> old SHA-1 (or older) root cert).
>
>
> *** just one suggestion: define a minimum key length also.
>

[Jakob Bohm]

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=digice...@lists.mozilla.org] On Behalf Of Jakob Bohm
> Sent: Friday, April 1, 2016 4:55 AM
> To: mozilla-dev-s...@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=netlo...@lists.mozi
>> lla.org] On Behalf Of Jeremy Rowley
>> Sent: Wednesday, March 30, 2016 10:54 PM
>> To: Jakob Bohm <jb-mo...@wisemo.com>;
>> mozilla-dev-s...@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
>> old SHA-1 (or older) root cert).
>>
>>
>> *** just one suggestion: define a minimum key length also.
>

> Indeed, hence why I keep saying "outdated certificate signing algorithms" with SHA-1 as just a current example.
>
>>