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.
On Fri, Apr 1, 2016 at 6:45 AM Varga Viktor <[email protected]> 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 > [email protected]] On Behalf Of Jeremy Rowley > Sent: Wednesday, March 30, 2016 10:54 PM > To: Jakob Bohm <[email protected]>; > [email protected] > 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: > > 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. > > 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 > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
