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. -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert....@lists.mozilla.org] On Behalf Of Jakob Bohm Sent: Wednesday, March 30, 2016 12:06 PM To: [email protected] Subject: Re: SHA-1 S/MIME certificates 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). 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 _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
