Re: Incidents involving the CA WoSign
On Fri, Oct 07, 2016 at 03:21:48AM +, Peter Gutmann wrote: > Kurt Roeckx writes: > > >This is why browsers have something like OneCRL, so that they actually do > >know about it and why Rob added that information to the bug tracker ( > >https://bugzilla.mozilla.org/show_bug.cgi?id=906611#c2). > > That still doesn't necessarily answer the question, Google have their CRLSets > but they're more ineffective than effective in dealing with revocations > (according to GRC, they're 98% ineffective, > https://www.grc.com/revocation/crlsets.htm). Given how hard it is to > determine whether cross-certifications exist (we really have no way of telling > until a cross-certificate suddenly turns up somewhere), it'd be good to have > some firm indication of whether a revocation will actually take effect or not. > Certainly for CRLSets it seems it won't. Mozilla now requires the disclosue of all intermedidate certificates, including those cross-certificates. I understand that the CRL information for all of them should be provided too, and that Mozilla will import all those in OneCRL. So the problem would be the undisclosed certificates. In theory we would could go and make a whitelist of the disclosed ones. I'm not sure if Mozilla actually has any plans for that. We should at some point probably also start to add the known but undisclosed ones to OneCRL. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incidents involving the CA WoSign
Kurt Roeckx writes: >This is why browsers have something like OneCRL, so that they actually do >know about it and why Rob added that information to the bug tracker ( >https://bugzilla.mozilla.org/show_bug.cgi?id=906611#c2). That still doesn't necessarily answer the question, Google have their CRLSets but they're more ineffective than effective in dealing with revocations (according to GRC, they're 98% ineffective, https://www.grc.com/revocation/crlsets.htm). Given how hard it is to determine whether cross-certifications exist (we really have no way of telling until a cross-certificate suddenly turns up somewhere), it'd be good to have some firm indication of whether a revocation will actually take effect or not. Certainly for CRLSets it seems it won't. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incident Report - certificate with 'sb' as a SAN:dnsName
On Thu, Oct 6, 2016 at 7:33 AM, Peter Bowen wrote: > On Thu, Oct 6, 2016 at 7:29 AM, Rob Stradling > wrote: >> On 04/10/16 19:39, Peter Bowen wrote: >>> On Tue, Oct 4, 2016 at 6:29 AM, Rob Stradling >>> wrote: On 04/10/16 13:18, Nick Lamb wrote: > On Tuesday, 4 October 2016 11:14:01 UTC+1, Rob Stradling wrote: >> Neither. I'd like to run cablint over all certs pre-issuance, but >> unfortunately it's not practical to do this yet because 1) cablint is >> too slow and 2) there are some differences of opinion that have been >> discussed at CABForum but not yet resolved. > > Can you expand on what "too slow" would mean here? Or does it tread too > much on specific commercial performance criteria you don't want to talk > about? Running cablint means firing up the Ruby interpreter, then fork/exec'ing a separate executable umpteen times. IIRC, last time I checked, crt.sh was only managing to cablint ~10 certs per second. (Prior to that, before I'd figured out a way to avoid having to take the "firing up the Ruby interpreter" hit again and again for every single cert, it was only managing to cablint ~3 certs per second). >>> >>> cablint could be much faster if the asn1 code could be moved in >>> process. Doing so requires someone who can work in C and has some >>> experience building Ruby extensions. This change would avoid the many >>> many fork/exec calls during a single certificate lint. >>> >>> If anyone is willing to volunteer, I can provide more detail. >> >> Woo! Matt Palmer accepted the challenge... >> >> https://github.com/awslabs/certlint/pull/38 > > And I just finished doing the initial tests. The fork/exec version > took 227.427 seconds to check a specific set of certificates. The > extension version took 14.306 seconds.A 15x speedup! > > I'm going to do some more testing, but this looks amazing! Matt rocks! > > Oh, and it gives better error messages as a side effect ;) I did some more testing. Using a single run it now does over 615 certificates per second. Running 16 in parallel processed 8948 per second. So it is pretty fast now :) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Include Symantec-brand Class 1 and Class 2 Root Certs
On Thu, Oct 6, 2016 at 3:57 PM, Richard Barnes wrote: > I seem to recall we had some discussion a while back about what criteria > should be applied to email CAs. Where did we end up on that? I don't believe anything was settled. There is one small item in the CA policy: "for a certificate to be used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf;" Other than that, I don't think there are any requirements. It isn't clear to me that the subordinate CA disclosure rule even applies to e-mail only roots. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Include Symantec-brand Class 1 and Class 2 Root Certs
On Thu, Oct 6, 2016 at 12:09 PM, Kathleen Wilson wrote: > This request from Symantec is to include the following 4 root certificates > and enable the Email trust bit for them. > To be clear: The request is for *only* the email trust bit to be set? I seem to recall we had some discussion a while back about what criteria should be applied to email CAs. Where did we end up on that? --Richard > 1) Symantec Class 1 Public Primary Certification Authority - G6 > 2) Symantec Class 2 Public Primary Certification Authority - G6 > 3) Symantec Class 1 Public Primary Certification Authority - G4 > 4) Symantec Class 2 Public Primary Certification Authority - G4 > These Symantec-brand root certs will eventually replace the VeriSign-brand > class 1 and 2 root certs that are currently included in NSS. > The G6 root certs are SHA-256, and the G4 root certs are ECC. > > The request is documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=833986 > > And in the pending certificates list: > https://wiki.mozilla.org/CA:PendingCAs > > Summary of Information Gathered and Verified: > https://bug833986.bmoattachments.org/attachment.cgi?id=8798532 > > * Root Certificate Download URLs: > https://www.symantec.com/content/en/us/enterprise/ > verisign/roots/PCA_1_G6.pem > https://www.symantec.com/content/en/us/enterprise/ > verisign/roots/PCA_2_G6.pem > https://www.symantec.com/content/en/us/enterprise/ > verisign/roots/Symantec_Class_1_Public_Primary_ > Certification_Authority_G4.pem > https://www.symantec.com/content/en/us/enterprise/ > verisign/roots/Symantec_Class_2_Public_Primary_ > Certification_Authority_G4.pem > > * The primary documents such as CP and CPS are provided in English. > > CA Document Repository: > https://www.symantec.com/about/profile/policies/repository.jsp > CP Document: > https://www.symantec.com/content/en/us/about/media/repository/stn-cp.pdf > CPS Document: > https://www.symantec.com/content/en/us/about/media/repository/stn-cps.pdf > > * CA Hierarchy: These root certs will be used to sign Class 1 and Class 2 > subordinate CAs for SMIME and Client Auth purposes. SubCA keys will > operate at Symantec or Symantec Affiliate sites. > > * This request is to turn on the Email trust bit for these root certs. > > ** CP and CPS section 3.2.2: Where a domain name or e-mail address is > included in the certificate Symantec or an Affiliate authenticates the > Organization’s right to use that domain name either as a fully qualified > Domain name or an e-mail domain. > > ** CP and CPS section 3.2.3: > *** Class 1 -- No identity authentication. > Limited confirmation that the certificate subscriber has access to the > email address. > Symantec performs a challenge-response type of procedure in which Symantec > sends email to the email address to be included in the certificate, > containing unpredictable information such as a randomly generated > PIN/Password unique to the owner of the email address. The owner of the > email address (the subscriber of the certificate) demonstrates control over > the email address by using the information within the email, to then > proceed with accessing a portal with the unique information sent in the > email, to download and install the certificate. > *** Class 2 -- Authenticate identity by: > Manual check performed by the enterprise administrator customer for each > subscriber requesting a certificate, “in which the subscriber receives the > certificate via an email sent to the address provided during enrollment” > or > Passcode-based authentication where a randomly-generated passcode is > delivered out-of-band by the enterprise administrator customer to the > subscriber entitled to enroll for the certificate, and the subscriber > provides this passcode at enrollment time > or > Comparing information provided by the subscriber to information contained > in business records or databases (customer directories such as Active > Directory or LDAP. > > * EV Policy OID: Not Requesting EV treatment and not requesting the > Websites trust bit for these root certs. > > * Test Certs: An example cert chaining up to each root is provided as > attachments in https://bugzilla.mozilla.org/show_bug.cgi?id=833986 > > * CRL URLs: > http://crl.ws.symantec.com/pca1-g6.crl > http://crl.ws.symantec.com/pca2-g6.crl > http://crl.ws.symantec.com/pca1-g4.crl > http://crl.ws.symantec.com/pca2-g4.crl > > * Audit: Annual audits are performed by KPMG according to the WebTrust > criteria. > https://www.symantec.com/content/en/us/about/media/ > repository/Symantec-STN-WTCA-2015.pdf > https://www.symantec.com/content/en/us/about/media/ > repository/1_symantec_stn_wtca_6-15-2016.pdf > > * Potentially Problematic Practices: > (http://wiki.mozilla.org/CA:Problematic_Practices) > ** Delegation of Domain / Email validation to third parties - CPS section > 1.3.2: Third parties, who enter into a contractual relationship with > Symantec or an affiliate, may operate their own RA and authorize the
Re: Include Symantec-brand Class 1 and Class 2 Root Certs
Thanks Kathleen. I have no substantive objections to this inclusion (with only the Email trust bit to be set) at this time but I do have a minor editorial nitpick which might as well go back to Symantec while we're here. On page 1 of the Introduction of the CP document, a footnote refers to "this CPS" when I suspect "this CP" is intended, in the phrase "this CPS describes practices that pertain to any Class 2 or Class 3 certificate" And similar language "this CPS" referring to what is in fact a CP occurs in a few other places such as in the box out in 13.1 about the pulled roots. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: WoSign and StartCom: next steps
On Tuesday, October 4, 2016 at 9:25:16 AM UTC-7, Gervase Markham wrote: > On 29/09/16 16:40, Gervase Markham wrote: > > Following the publication of the recent investigative report, > > representatives of Qihoo 360 and StartCom have requested a face-to-face > > meeting with Mozilla. We have accepted, and that meeting will take place > > next Tuesday in London. > > This meeting happened today; thank you to representatives of Qihoo 360, > StartCom and WoSign who travelled great distances to come. I'm happy > that Mozilla was able to successfully communicate what we hoped to see > from these companies, and expect to see a proposed plan from them very > shortly. > > Once that plan is published, we will be able to discuss whether the > steps contained in it should lead to Mozilla changing our proposal for > the measures we intend to take. > > Gerv Hi Gerv, Do you have any further updates regarding this plan? This seems to have stalled any further discussions about next steps. Best, Ryan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Include Symantec-brand Class 1 and Class 2 Root Certs
This request from Symantec is to include the following 4 root certificates and enable the Email trust bit for them. 1) Symantec Class 1 Public Primary Certification Authority - G6 2) Symantec Class 2 Public Primary Certification Authority - G6 3) Symantec Class 1 Public Primary Certification Authority - G4 4) Symantec Class 2 Public Primary Certification Authority - G4 These Symantec-brand root certs will eventually replace the VeriSign-brand class 1 and 2 root certs that are currently included in NSS. The G6 root certs are SHA-256, and the G4 root certs are ECC. The request is documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=833986 And in the pending certificates list: https://wiki.mozilla.org/CA:PendingCAs Summary of Information Gathered and Verified: https://bug833986.bmoattachments.org/attachment.cgi?id=8798532 * Root Certificate Download URLs: https://www.symantec.com/content/en/us/enterprise/verisign/roots/PCA_1_G6.pem https://www.symantec.com/content/en/us/enterprise/verisign/roots/PCA_2_G6.pem https://www.symantec.com/content/en/us/enterprise/verisign/roots/Symantec_Class_1_Public_Primary_Certification_Authority_G4.pem https://www.symantec.com/content/en/us/enterprise/verisign/roots/Symantec_Class_2_Public_Primary_Certification_Authority_G4.pem * The primary documents such as CP and CPS are provided in English. CA Document Repository: https://www.symantec.com/about/profile/policies/repository.jsp CP Document: https://www.symantec.com/content/en/us/about/media/repository/stn-cp.pdf CPS Document: https://www.symantec.com/content/en/us/about/media/repository/stn-cps.pdf * CA Hierarchy: These root certs will be used to sign Class 1 and Class 2 subordinate CAs for SMIME and Client Auth purposes. SubCA keys will operate at Symantec or Symantec Affiliate sites. * This request is to turn on the Email trust bit for these root certs. ** CP and CPS section 3.2.2: Where a domain name or e-mail address is included in the certificate Symantec or an Affiliate authenticates the Organization’s right to use that domain name either as a fully qualified Domain name or an e-mail domain. ** CP and CPS section 3.2.3: *** Class 1 -- No identity authentication. Limited confirmation that the certificate subscriber has access to the email address. Symantec performs a challenge-response type of procedure in which Symantec sends email to the email address to be included in the certificate, containing unpredictable information such as a randomly generated PIN/Password unique to the owner of the email address. The owner of the email address (the subscriber of the certificate) demonstrates control over the email address by using the information within the email, to then proceed with accessing a portal with the unique information sent in the email, to download and install the certificate. *** Class 2 -- Authenticate identity by: Manual check performed by the enterprise administrator customer for each subscriber requesting a certificate, “in which the subscriber receives the certificate via an email sent to the address provided during enrollment” or Passcode-based authentication where a randomly-generated passcode is delivered out-of-band by the enterprise administrator customer to the subscriber entitled to enroll for the certificate, and the subscriber provides this passcode at enrollment time or Comparing information provided by the subscriber to information contained in business records or databases (customer directories such as Active Directory or LDAP. * EV Policy OID: Not Requesting EV treatment and not requesting the Websites trust bit for these root certs. * Test Certs: An example cert chaining up to each root is provided as attachments in https://bugzilla.mozilla.org/show_bug.cgi?id=833986 * CRL URLs: http://crl.ws.symantec.com/pca1-g6.crl http://crl.ws.symantec.com/pca2-g6.crl http://crl.ws.symantec.com/pca1-g4.crl http://crl.ws.symantec.com/pca2-g4.crl * Audit: Annual audits are performed by KPMG according to the WebTrust criteria. https://www.symantec.com/content/en/us/about/media/repository/Symantec-STN-WTCA-2015.pdf https://www.symantec.com/content/en/us/about/media/repository/1_symantec_stn_wtca_6-15-2016.pdf * Potentially Problematic Practices: (http://wiki.mozilla.org/CA:Problematic_Practices) ** Delegation of Domain / Email validation to third parties - CPS section 1.3.2: Third parties, who enter into a contractual relationship with Symantec or an affiliate, may operate their own RA and authorize the issuance of certificates by a STN CA. Third party RAs must abide by all the requirements of the STN CP, the relevant CPS and any Enterprise Service Agreement entered into with Symantec. RAs may, however implement a more restrictive practices based on their internal requirements. ** Allowing external entities to operate subordinate CAs -- CPS section 1.3.1: Symantec enterprise customers may operate their own CAs as a subordinat
Re: Incidents involving the CA WoSign
On 10/6/2016 10:49 AM, Peter Bowen wrote: > I think the community has discussed cross-signing both in this > discussion and in the broader discussion of the trust graph. > > https://wiki.mozilla.org/CA:WoSign_Issues#Cross_Signing lists all the > known cross-signs of WoSign. > > https://wiki.mozilla.org/CA:SubordinateCAcerts provides info on all > subordinate (including cross-signed) CAs for each root in the Mozilla > program. Rob Stradling of Comodo combined this with certificate > transparency information to generate > https://crt.sh/mozilla-disclosures. > > As for Comodo, they have published > https://secure.comodo.com/products/publiclyDisclosedSubCACerts for a > while now. It shows which subordinates are operated by Comodo and > which are independently operated. Thank you for putting all information in one place. At the moment, they are pieces of disclosure records only but that's good to work on it. > > The next step for Mozilla is to determine how to handle the 285 CA > certificates not disclosed in the Mozilla SF system and the 80 that > are under disclosed. Sure, Mozilla and this community should. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incident Report - certificate with 'sb' as a SAN:dnsName
On Thu, Oct 6, 2016 at 7:29 AM, Rob Stradling wrote: > On 04/10/16 19:39, Peter Bowen wrote: >> On Tue, Oct 4, 2016 at 6:29 AM, Rob Stradling >> wrote: >>> On 04/10/16 13:18, Nick Lamb wrote: On Tuesday, 4 October 2016 11:14:01 UTC+1, Rob Stradling wrote: > Neither. I'd like to run cablint over all certs pre-issuance, but > unfortunately it's not practical to do this yet because 1) cablint is > too slow and 2) there are some differences of opinion that have been > discussed at CABForum but not yet resolved. Can you expand on what "too slow" would mean here? Or does it tread too much on specific commercial performance criteria you don't want to talk about? >>> >>> Running cablint means firing up the Ruby interpreter, then fork/exec'ing >>> a separate executable umpteen times. IIRC, last time I checked, crt.sh >>> was only managing to cablint ~10 certs per second. (Prior to that, >>> before I'd figured out a way to avoid having to take the "firing up the >>> Ruby interpreter" hit again and again for every single cert, it was only >>> managing to cablint ~3 certs per second). >> >> cablint could be much faster if the asn1 code could be moved in >> process. Doing so requires someone who can work in C and has some >> experience building Ruby extensions. This change would avoid the many >> many fork/exec calls during a single certificate lint. >> >> If anyone is willing to volunteer, I can provide more detail. > > Woo! Matt Palmer accepted the challenge... > > https://github.com/awslabs/certlint/pull/38 And I just finished doing the initial tests. The fork/exec version took 227.427 seconds to check a specific set of certificates. The extension version took 14.306 seconds.A 15x speedup! I'm going to do some more testing, but this looks amazing! Matt rocks! Oh, and it gives better error messages as a side effect ;) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incident Report - certificate with 'sb' as a SAN:dnsName
On 04/10/16 19:39, Peter Bowen wrote: > On Tue, Oct 4, 2016 at 6:29 AM, Rob Stradling > wrote: >> On 04/10/16 13:18, Nick Lamb wrote: >>> On Tuesday, 4 October 2016 11:14:01 UTC+1, Rob Stradling wrote: Neither. I'd like to run cablint over all certs pre-issuance, but unfortunately it's not practical to do this yet because 1) cablint is too slow and 2) there are some differences of opinion that have been discussed at CABForum but not yet resolved. >>> >>> Can you expand on what "too slow" would mean here? Or does it tread too >>> much on specific commercial performance criteria you don't want to talk >>> about? >> >> Running cablint means firing up the Ruby interpreter, then fork/exec'ing >> a separate executable umpteen times. IIRC, last time I checked, crt.sh >> was only managing to cablint ~10 certs per second. (Prior to that, >> before I'd figured out a way to avoid having to take the "firing up the >> Ruby interpreter" hit again and again for every single cert, it was only >> managing to cablint ~3 certs per second). > > cablint could be much faster if the asn1 code could be moved in > process. Doing so requires someone who can work in C and has some > experience building Ruby extensions. This change would avoid the many > many fork/exec calls during a single certificate lint. > > If anyone is willing to volunteer, I can provide more detail. Woo! Matt Palmer accepted the challenge... https://github.com/awslabs/certlint/pull/38 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA-1 exception First Data
On 06/10/2016 15:58, Gervase Markham wrote: On 06/10/16 12:38, Jakob Bohm wrote: Which is why I have repeatedly suggested that maybe the rules should be changed to promote/demote some of the historic SHA-1 root certs into "SHA-1 forever" roots that can service older devices and browsers, even for regular websites concerned about allowing visits from older devices while transitioning their websites to HTTPS-only. That has effectively happened; those roots have been removed from current root stores, but if you talk to the right CA you can still get a cert from one. Good, now communicate it. Ideally, there should also be a way for TLS servers (such as web servers) to detect if the TLS client suffers from historic public key limitations such as SHA-1 only, low maximum DH key size etc., thus allowing the TLS server to use stronger certificates and FS keys for new clients. Again, this exists - people use the cipher suite set, or support (or lack of it) for TLS or TLS 1.2. I know, I do that too, but it is quite a wobbly heuristic as there is no clear set of those to indicate e.g. support for >1024 bit EDH or >256 bit ECC EDH. Nor do I see a good candidate for indicating >16384 bits RSA (as a future example not yet supported by some SSL clients). P.S. I seem to receive 3 copies of your replies, 2 in my inbox and 1 in the newsgroup. 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA-1 exception First Data
On 06/10/16 12:38, Jakob Bohm wrote: > Which is why I have repeatedly suggested that maybe the rules should be > changed to promote/demote some of the historic SHA-1 root certs into > "SHA-1 forever" roots that can service older devices and browsers, even > for regular websites concerned about allowing visits from older devices > while transitioning their websites to HTTPS-only. That has effectively happened; those roots have been removed from current root stores, but if you talk to the right CA you can still get a cert from one. > Ideally, there should also be a way for TLS servers (such as web > servers) to detect if the TLS client suffers from historic public key > limitations such as SHA-1 only, low maximum DH key size etc., thus > allowing the TLS server to use stronger certificates and FS keys for > new clients. Again, this exists - people use the cipher suite set, or support (or lack of it) for TLS or TLS 1.2. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA-1 exception First Data
On 06/10/2016 07:46, Peter Bowen wrote: On Wed, Oct 5, 2016 at 10:02 PM, Michael Ströder wrote: Dean Coclin wrote: First Data's customers don't use browsers so Firefox can disable SHA-1 tomorrow and not affect them. So why to have your CA certificate trusted in Firefox's cert DB? First Data has asked for a reasonable extension which doesn't affect browsers. If it does not "affect browsers" why do you need an extension? The impact on browsers could be broken down into two parts: 1) An expectation they would work with the resulting certificate 2) The risk that someone uses this to create hash collision allowing them to create a different certificate that is used with browsers. I think Dean's point is that #1 is not true here. Presumably these certificates could even be blacklisted by browsers. However #2 is where the risk lies. As we have seen with previous requests, the core challenge here is that many device vendors have chosen to embed a CA trust list in their devices that is based on the list used by web browsers. From my own experience, this is something that continues today with consumer electronics. They take a point in time snapshot of the Mozilla list, embed it in the device, and expect anyone interacting with the device to get a certificate from one of those CAs. This inherently sets up a conflict -- these same device vendors frequently don't release updates for the devices, so the assumption is that the CAs they choose (which is usually a unilateral decision) will continue to issue certs compatible with the device for the lifetime of the device. With the transition to SHA-256 or better, this has become a challenge. I think we can all look back with 20/20 hindsight and say that device vendors should not use the same roots as browsers and that maybe CAs should have created "SHA-1 forever" roots for devices that never plan to update, but that is great hindsight. We have the problem now, so we need an answer. Which is why I have repeatedly suggested that maybe the rules should be changed to promote/demote some of the historic SHA-1 root certs into "SHA-1 forever" roots that can service older devices and browsers, even for regular websites concerned about allowing visits from older devices while transitioning their websites to HTTPS-only. This should of cause be supplemented by stronger serial number randomness rules such as at least 100 bits of unpredictable CA-supplied entropy in the serial number, mandatory numeric high entropy serial number in the distinguished name, 1 year end certificates issued by 15 month intermediary certs that change quarterly. The justified comment by someone else that they shouldn't have made devices then refused to update them is true, but unlike "rent-a-payment- terminal" financial services (who are big enough to go through individual applications for CAB/F exceptions), most unupdatable devices were sold in large numbers to end users in the form of phones, PDAs etc. Ideally, there should also be a way for TLS servers (such as web servers) to detect if the TLS client suffers from historic public key limitations such as SHA-1 only, low maximum DH key size etc., thus allowing the TLS server to use stronger certificates and FS keys for new clients. 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
