Re: Extending Android Device Compatibility for Let's Encrypt Certificates
I think it is a mistake to assume that the "intermediate" (i.e. your ISRG Root X1 cross-signed by DST Root CA X3) is the same certificate as your self-signed ISRG Root X1. The "intermediate" can only be chained up to expired DST Root CA X3. On 08-Jan-21 1:31 AM, Aaron Gable via dev-security-policy wrote: Clients using OpenSSL 1.0.x were failing, because they couldn't recognize that one of the intermediates in the chain was in their own trust store. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Extending Android Device Compatibility for Let's Encrypt Certificates
I'm curious whether this approach of cross-signing from a root certificate which has already expired is exceptional for Let's Encrypt. I'm not aware of any discussion on what conditions this approach could be accepted by Mozilla and other root certificate programs. Or, is it just an usual practice of CA? If yes, this approach may provide some new solutions in the CA ecosystem. Firstly, for those new CAs who do not have their root certificates included in the root certificate programs, they may acquire an expired root certificate from an existing CA who are probably more willing to sell the expired root certificate rather than an active root certificate. Secondly, for some CAs whose root certificates are going to expire, they may continue using the root certificates to issue intermediate CA certificates beyond its expiry. So, there will be no need for rollover of root certificates to new one. Are they good or bad things? On 22-Dec-20 7:42 AM, jo...--- via dev-security-policy wrote: We (Let's Encrypt) just announced a new cross-sign from IdenTrust which is a bit unusual because it will extend beyond the expiration of the issuing root. More details can be found here: https://letsencrypt.org/2020/12/21/extending-android-compatibility.html Best, Josh ___ 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: 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: Incidents involving the CA WoSign
It is an interesting aspect that the Mozilla community has not discussed thoroughly, or at all. Cross-signing a third party intermediate cert is equivalent to sharing of trust, that any CA should only consider it with extreme care. Is it possibly know how many intermediate cert that is cross-signed by Comodo? Is there any Comodo's practice statement of cross-signing ? Comodo seems to be quite keen on this kind of business even after the lesson learn from its last incident in 2011 (https://blog.mozilla.org/security/2011/03/25/comodo-certificate-issue-follow-up/). On 10/5/2016 4:43 AM, Kurt Roeckx wrote: > I can't remember if there were other cross signatutures. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Comodo issued a certificate for an extension
On 10/3/2016 11:50 AM, Peter Bowen wrote: > 3.2.2.4.4, 3.2.2.4.6, 3.2.2.4.9, and 3.2.2.4.10 all use the newly > defined "Authorization Domain Name", which should avoid this in the > future. Thank you for pointing me to those sections, but my confusion may be starting from the definition of "Authorization Domain Name". Does it simply mean one of the aliases of a FQDN that is specifically used to obtain authorization for that FQDN? I think an example of "Authorization Domain Name" could help me jump out from such abstraction of definition/term. Thank you. By simply reading the requirement, I feel that if I can create a CNAME record to let "www." pointing to "", and I prove to a CA that I control the "www.", then the CA should be able to issue a certificate of "" according to those sections, correct? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Comodo issued a certificate for an extension
Peter, I'm confused why only the section 3.2.2.4.7 specifically addresses this concern, and how. If only it does, would it implies that CA must use this method of section 3.2.2.4.7 to validate a Base Domain Name, which happened to be an Authorization Domain Name requested by the applicant ? However, according to section 3.2.2.4, each FQDN listed in the certificate is required to be validated using AT LEAST one of the methods only. Thanks, Man On 10/3/2016 3:53 AM, Peter Bowen wrote: > The new section 3.2.2.4.7 specifically > addresses DNS validation. Under the new rules, which should be in > effect as of 1 March 2017, validating www. will not be a valid > method of showing control of . The name is true for any valid > hostname under . The only note is that names in the form > _. (that is starting with an underscore) can be > used to validate . ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Hongkong Post recently issued SHA1 cert that could be used in TLS
On 9/1/2016 6:13 PM, Matt Palmer wrote: > You might want to let them know it's time to get new certs. > > - Matt We did inform all subscribers back in October 2014 that SHA-1 SSL server cert was CEASED since 1 January 2016, and reminded each of them individually that SHA-1 SSL server cert will no longer be trusted by browsers starting from 1 January 2017. Some of them might have replaced their SHA-1 SSL server cert by new cert (either from us or other CA, I don't know), without letting us know to revoke their SHA-1 SSL server cert. Some of them might want to keep using their SHA-1 SSL server cert until its expiry, which is still well before the well-known deadline 1 January 2017. I believe that their rights to use SHA-1 SSL server cert before deadline should not be affected. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Hongkong Post recently issued SHA1 cert that could be used in TLS
On 9/1/2016 3:52 AM, Nick Lamb wrote:
> It may make sense to explicitly tell Hongkong Post that it must not do
> anything which would have the effect of subverting/ undoing this change. For
> example, if Hongkong Post wants to create a new certificate for the
> intermediate "Hongkong Post e-Cert CA 1 - 10" (perhaps now with constraints
> forbidding SSL Server certs) it should ensure Mozilla understands and agrees
> the contents of that new certificate as appropriate first.
We actually planned to create a new Sub CA ("Hongkong Post e-Cert CA 2 -
16") for transitioning end-entity certs (except the SSL server certs)
under "Hongkong Post e-Cert CA 1 - 10" to it. All SSL server certs under
"Hongkong Post e-Cert CA 1 - 10" would be naturally expired, or revoked
by 31 Dec 2016. The key cutting and certificate generation is scheduled
in next week. It's great for Mozilla understanding the new Sub CA and I
highly appreciate your input so that we're explicitly told about the
requirement of intermediate certificate - that does not issue SSL server
cert.
But the creation of the new Sub CA seems to be off-topic. I will open
another thread when we're ready.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Hongkong Post recently issued SHA1 cert that could be used in TLS
What about our existing SSL server certs, which are still valid until 31 Dec 2016? Majority of those cert. subscribers are offering government and public services to residents of Hong Kong. And I believe the impact to residents of Hong Kong will be huge when the browser suddenly prompt a warning of insecure. In fact, all those cert. subscribers have their own plans to migrate to new SHA-256 SSL server certs by 31 Dec 2016. Are those existing SSL server certs going to be put in a white list at the same time? On 9/1/2016 2:32 AM, Kathleen Wilson wrote: > Thanks to all of you who have provided thoughtful and constructive input into > this discussion. > > I have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1299579 to request > that the "Hongkong Post e-Cert CA 1 - 10" intermediate cert be added to > OneCRL. See the bug for further details. > > Kathleen > > > ___ > 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: Should we block Blue Coat's 'test' intermediate CA?
I think the issue or concern on Blue Coat's intermediate CA certificate is irrelevant to "Symantec's policies and governance on its public CA operation". The concern is on Blue Coat's intermediate CA operation. If it's allowed to continue operation, this intermediate CA certificate can generate any number of forge SSL certificates for any website. How can these certificates be differentiated in CT logs? Some exception treatment again? Secondly, the risk of MITM to internet users will all depend on where Blue Cost is deployed. If it is deployed in country-wide internet gateway, all internet users of the country will be at risk. I'd say "Wow, what a mess to the CA ecosystem!" On 6/15/2016 12:02 PM, sanjay_m...@symantec.com wrote: > The integrity of Symantec’s public certification authority will not be > impacted as a result of the Blue Coat acquisition. Until the acquisition > is complete, Symantec and Blue Coat will continue to operate as two > separate companies. Once the transaction is complete, Symantec’s public CA > infrastructure and capabilities will continue to remain separate and > independent from Blue Coat’s technology and products. In addition, > policies and governance will be established to ensure the public CA > operations will not be used to facilitate packet inspection in the Blue > Coat offerings that will become a part of Symantec’s portfolio. > ___ > 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: Undisclosed CA certificates
Thanks. I see. It's by the best effort approach. On 4/29/2016 4:29 PM, Rob Stradling wrote: > >> My understanding >> is that it gives that warning when the serial is not long enough. > > Seems so. See > https://github.com/awslabs/certlint/blob/master/lib/certlint/cablint.rb#L69 > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Undisclosed CA certificates
Hi Rob, I know that there is a discussion regarding "bits of entropy" or "unpredictable bits" in certificate serial number. I do not familiar with this topic, but my gut feeling is that "unpredictable bits" is relatively subjective. What is your definition of "bits of entropy" used in crt.sh? Could you elaborate a bit more on how "bits of entropy" is verified? Cheers, Man On 4/28/2016 7:31 PM, Rob Stradling wrote: > On 28/04/16 01:15, Richard Barnes wrote: >> Dear CAs, >> >> As you guys are working toward the June 30 deadline for disclosing >> intermediate certificates in SalesForce, I thought I would share some >> notes >> on the undisclosed certificates that we're seeing, so that you can make >> sure you get them all uploaded. >> >> Zakir Durumeric from UMich/Censys.io has helpfully compiled a list of CA >> certificates that have been observed in Censys scans of the Internet, >> and >> noted which of those certificates are not in SalesForce so far. > > Also, crt.sh now regularly downloads > https://wiki.mozilla.org/CA:SubordinateCAcerts and automatically links > the audit info to the relevant CA certificates. > (Example: https://crt.sh/?id=3706739) > > I'm aiming to produce an (automatically updated) list of CA > certificates that are known to CT but are not (yet) in SalesForce. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy Update Proposal: Remove Code Signing Trust Bit
On 9/17/2015 10:26 AM, Peter Kurrasch wrote: > As a counter exaple, consider that some in-car entertainment systems > offer (or want to offer) "downloadable app" capabilities. Obviously, Mozilla's position is that it should be the car manufacturer's responsibility to maintain their own trust list, but not shifting the responsibility to Mozilla purely because they used the NSS module in their system. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Automated the Included CA List
I am wondering the purpose of the new column "Geographic Focus" and how it is defined. First of all, why is it necessary to distinguish "Geographic Focus"? is it for browsers to implement technically constraint business of the root CAs to such areas? Secondly, is it defined by business location of a root CA's sub CAs operating in an area? Or, by business location of customer to whom a certificate is issued? Or, by ccTLD of the customer's domain name? Anyway given this new column has been added, I think "People's Republic of China" = "China", isn't it? And Hongkong Post's geographic focus should be "Hong Kong (SAR), China" because Hongkong Post has not yet been able to issue certificates to customers in other provinces of China. - Man On 8/5/2015 5:05 AM, Kathleen Wilson wrote: > On 8/4/15 1:26 PM, Peter Bowen wrote: >> On Tue, Aug 4, 2015 at 1:17 PM, Kathleen Wilson >> wrote: >>> The Included CAs list is now being automatically generated directly >>> from >>> Salesforce: >>> >>> https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport >>> >>> >>> If everyone is OK with this new report, I will change >>> https://wiki.mozilla.org/CA:IncludedCAs to point to this new report, >>> and >>> will remove the Google spreadsheet that is currently included in the >>> page. >>> (and I will no longer update the Google spreadsheet) >> >> Is there a way to download the Salesforce data in CSV, xlsx, ods, or >> some other non-HTML format. >> >> Thanks, >> Peter >> > > We have it on our to-do list: Create a way to download a CSV version > of the new auto-generated Included CAs report. > We were planning to tackle that in September. Do you need it earlier? > > Also, I should mention that there is a new column in the report: > Geographic Focus. > I've been filling that data in as I update CA records in Salesforce > (when I remember). CAs, please send me email if there is particular > data in this report that should be updated. > > Kathleen > > ___ > 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: Policy about root cert transfers
On 4/24/2015 7:21 AM, Kathleen Wilson wrote: > how to transfer a root certificate from one CA to another The term "transfer" a root certificate is new to me. What are the rationale of such transferal? Move from one location to another location, or from one HSM to another HSM? Ownership of the CA had changed from one organization to another organization? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 答复: 答复: Consequences of mis-issuance under CNNIC
On 3/27/2015 1:29 AM, Charles Reiss wrote: > Although it's rather irrelevant to whether CNNIC has complied with Mozilla's > policies: This device designed to issue certs without verifying domain > control. > Does CNNIC not regard this as strong evidence that MCS's agreement was made in > bad faith? Yeah, if this device is designed to issue certificates automatically. Why does it have this feature? The answer is obviously for traffic monitoring. But then why Paloalto would develop such problematic feature which violate security principle? If it is a common feature in Paloalto firewall (or even other brands of firewalls), I'd believe that many organizations are doing the same thing. Should firewall vendors or developers take some responsibilities too? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Peers of Mozilla's CA Certificates and CA Certificate Policy modules
Looking at the other way - if Mozilla would promote Let's Encrypt, the current composition (i.e. all 3 peers are from Mozilla) would do a better job. Richard Barnes is a replacement of Johnathan Nightingale only, that make no difference. Now, adding Ryan Sleevi from Google shows a bit of openness and transparency. However, if Mozilla would add one more peer from CA background (except Let's Encrypt), it'd be even better. On 2/6/2015 5:07 AM, Jeremy Rowley wrote: > Just one thought - Richard Barnes involvement with Let's Encrypt makes it > look like Mozilla is promoting its own CA over the others. If there's any > question on Let's Encrypt getting favoritism, Mozilla will be opening itself > up to an anti-trust lawsuit, especially in Europe where vertical integrations > are much more suspect. > > > -Original Message- > From: dev-security-policy > [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] > On Behalf Of Steve Workman > Sent: Thursday, February 5, 2015 2:03 PM > To: Kathleen Wilson > Cc: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Updating Peers of Mozilla's CA Certificates and CA Certificate > Policy modules > > +1 > > On Thu, Feb 5, 2015 at 12:58 PM, Kathleen Wilson > wrote: > >> According to https://wiki.mozilla.org/Modules: "A module is a discrete >> unit of code or activity. An owner is the person in charge of a module >> or sub-module. A peer is a person whom the owner has appointed to help them." >> >> There are two modules associated with the CA Program. >> >> Module #1 >> Name: Mozilla CA Certificate Policy >> Owner: Kathleen Wilson >> Peers: Gervase Markham, Johnathan Nightingale, Sid Stamm >> URL: http://www.mozilla.org/projects/security/certs/policy/ >> >> Module #2 >> Name: CA Certificates >> Description: Determine which root certificates should be included in >> Mozilla software products, which trust bits should be set on them, and >> which of them should be enabled for EV treatment. Evaluate requests >> from Certification Authorities (CAs) for inclusion or removal of root >> certificates, and for updating trust bit settings or enabling EV >> treatment for already included root certificates. >> Owner: Kathleen Wilson >> Peer(s): Gervase Markham, Johnathan Nightingale, Sid Stamm Bugzilla >> Component(s): mozilla.org::CA Certificates >> >> >> I propose making the following changes to the Peers list for these modules. >> >> 1) Remove Johnathan from the Peers list of both modules. Johnathan >> provided valuable guidance and insight over my first few years of >> working on Mozilla’s CA program. But, alas, he has not been very >> involved in Mozilla's CA program since he became VP of Firefox. >> >> 2) Add Richard Barnes to the Peers list of both modules. Richard has >> been contributing to Mozilla's CA program and managing Mozilla's >> Crypto Engineering team for the past year, and has been working (and >> managing >> work) on related projects including OneCRL, https://wiki.mozilla.org/CA: >> RevocationPlan, https://wiki.mozilla.org/PKI:CT, ability to add name >> constraints to built-in certificates, and research into SSL cert and >> CA root cert usage (more about this later, stay tuned). Many of you >> also know Richard from his work in the IETF. >> >> 3) Add Ryan Sleevi to the Peers list of the "CA Certificates" module. >> Ryan has been an active contributor to the mozilla.dev.security.policy >> forum for three years. He provided technical guidance and helped >> refine the updates to versions 2.1 and 2.2 of Mozilla's CA Certificate >> Policy, and he regularly contributes to discussions about root >> inclusion/change requests. >> Many of you are also aware of Ryan's active involvement in the NSS >> team, Google's root program, CT, and the CA/Browser forum. >> >> I will appreciate your thoughtful and constructive feedback on these >> proposed changes. >> >> Kathleen >> ___ >> 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 > ___ > 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: Question about BR Commitment to Comply
On 2/4/2015 10:27 PM, Kurt Roeckx wrote: > So maybe the CP/CPS should indicate what the version is they comply > with, and update it on regular basis? Or maybe just say that they will > follow the updates? Since Mozilla's CP requires CA to submit audit report annually, the CA's assertion of compliance is also updated annually. Unless the frequency of updating CP/CPS is more often than annual basis, it makes no difference whether it is stated in CP/CPS or the Webtrust audit statement. I want to point out that having the CA's assertion of compliance with BR in Webtrust audit is a proper approach because it can be read together with Webtrust audit report. If some CAs want to make a statement in CP/CPS to commit "willingness" of following the BR, it should be optional as an expression of endeavor. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Question about BR Commitment to Comply
On 2/4/2015 6:08 PM, Gervase Markham wrote: > They are not refusing to comply, they > just want to change the location of the compliance statement. In practice, Webtrust BR audit report requires the CA's assertion of compliance with BRs. It is a proper place to make the compliance statement because it can be read together with the audit report. > Or are they basically saying they do not wish to be bound by the latest > version of the BRs, but only by the version current at the time of their > last audit? > > If so, I'd say No. Mozilla expects all CAs in our program, whether CAB > Forum members or not, to comply with the latest version of the BRs > (taking into account any phase-in periods given in resolutions to adopt > new measures). Inability to do this might be considered indicative of > deeper problems at the CA. The point of discussion is misunderstood. It is no doubt that CAs are willing, or actually required, to commit its compliance with the latest version of BRs. Otherwise the CA simply refuses to join the root program. But making a statement in CP/CPS means that CA "has already complied" with the "latest version" of BRs. In other words, CA has already complied with all potential changes of BRs at all time. Such statement could be a false statement when the "latest version" of BRs has been changed and CA actually cannot comply with the changes at that time. Hence, users are misled by the statement at that time. > It may be true that we can only have the compliance of a particular CA > checked formally once a year at audit time, but we still expect ongoing > compliance, and reserve the right to use other methods of checking it > (such as examining issued certificates). By all means, Mozilla always has the right to check ongoing compliance as stated in Mozilla's CP. Making a statement in CP/CPS or not, doesn't mean anything. -- Man ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Question about BR Commitment to Comply
On 1/31/2015 3:42 AM, Jeremy Rowley wrote: > Snipped to try and make the convo less confusing. > > [MH] If that's the case, the trustworthiness of a Webtrust audit would be > weakened. Auditors should obtain the CA's assertion of compliance, and assess > whether it's reasonable with respect to the CA's CP/CPS and the target scope > of audit (i.e. the BR). And finally give their opinions in Webtrust audit > report for public knowledge. > [JR] Per 8.3 that assertion of compliance must (and should) be made publicly. > You're not representing to the auditors that the CA is compliant, you're > representing compliance to the Mozilla's end users. To me, that's a very > important assertion. [MH] The CA's assertion of compliance with the Webtrust audit report is also open to public. Since it is an important assertion, it must be read together with the audit report. If a CA fails some BRs according to "latest version" of BRs, but had already made that statement (probably because it was true in previous version), it becomes a false statement which in fact mislead end users. > > [MH] Requiring CA to comply with BRs is good thing. But I also point out that > once a CA put a statement of compliance with "latest version" of BRs in > CP/CPS, the CA has committed to public that it "has already complied" with > all potential changes of BRs at all time. That may be a false statement. The > proper approach is for Mozilla's CP to require the CA to perform audit on the > latest version of BR. And the audit report must state which version of BR > that the CA adhere to. > [JR] I agree, but the CA should also represent which version they are > complying with. Audits only happen annually. Reliance on certificates is a > year-around event. I want to know if the CA changes their policies to match > the most current version of the BRs. Unless you have a daily audit, that > only happens with a CA's assertion of compliance. [MH] BRs may be changed at any time before the next audit of a CA. For public knowledge whether the CA would need to change its practice due to changes of BR version, Mozilla had been doing this through Mozilla's communications and then maintained a spreadsheet. I think it is the better way. > > [MH] CA's assertion is a mandatory requirement of Webtrust audit. If an > auditor has prepared the audit report, it should be no doubt. > [JR]Only at the time of the audit. What about the other 364 days? [MH] As you said reliance on certificates is a year-round matter. I'd prefer to know exactly what BRs the CA has already complied, rather than being misled by a statement for the other 364 days. > > > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Question about BR Commitment to Comply
On 1/30/2015 5:59 AM, Jeremy Rowley wrote: >> Some initial thoughts: >> >> 1) Membership in the CAB Forum is not required for a CA to commit to >> complying with the BR, and if non-membership avoids any obligation to comply >> with the BRs, I think you'll quickly see a mass exodus from the group. No >> member of the CAB Forum is bound to its requirements by agreement or through >> participation. Instead, the requirements are only imposed by the browsers >> are part of their root programs. > The question is only whether a CA can have their Webtrust audit statement > indicate their commitment to comply with the BRs, rather than putting the > commitment to comply statement in the CP/CPS. Therefore, the CA is still > required to comply with BR according to Webtrust audit. > [JR] No - as Kurt mentioned, the CA is attesting to its compliance, not the > auditors. Putting it in the audit statement doesn't make sense as the audit > statement is only the auditors opining on your compliance with whatever audit > criteria is relevant not the CA's assertion of compliance. [MH] If that's the case, the trustworthiness of a Webtrust audit would be weakened. Auditors should obtain the CA's assertion of compliance, and assess whether it's reasonable with respect to the CA's CP/CPS and the target scope of audit (i.e. the BR). And finally give their opinions in Webtrust audit report for public knowledge. > >> 2) The goal of Section 8.3 is for the CA to inform the public about which >> certs are being issued in compliance with the BRs and which are not. It's >> not a marketing requirement. It's a technical requirement to provide >> relying parties (and browsers) information about how the CA operates. >> Section 8.3 basically requires the CA to assert that it is doing the MINIMUM >> required to issue certs. Any CA unwilling to assert this should not be >> issuing trusted certs. > The CA's assertion to issue certificate in accordance to BR is REQUIRED by > Webtrust audit anyway. The assertion is also publicly disclosed with the > audit report. Again, the question is only whether a CA should put a statement > in the CP/CPS as section 8.3 required. If yes, it is a marketing requirement, > because not aware of other audit requirements or standardization bodies that > have such requirement, e.g. Webtrust, ETSI, even Mozilla's CP itself. > [JR] Not true. Audits can have restricted scope and only cover the CA's > compliance with its CPS. Not all audit reports are clear on what parts of > the audit covered which certs. > >> 3) Every CA should comply with the latest version of BRs. CAs who are so >> inflexible that they can't keep up with the "minor" changes made by the CAB >> Forum really shouldn't be issuing certs. Recent "minor" changes include >> deprecation of 1024 bit certs, SHA2 migration, deprecation of internal >> names, etc. These are pretty important issues, all of which should be >> promptly implemented by CAs when adopted. > Exactly. Changes in BR may be "minor" or "important" from different point of > views. A CA may be in trouble of making a false statement in its CP/CPS if > the latest version of BR suddenly changed. Worst of all, the BR is suddenly > changed just before annual audit. But of course, the "minor" changes that you > have mentioned should have already fulfilled by CAs. > [JR] That's my point. Minor is not in the discretion of the CA. If the > CA/Browser Forum adopted a change, there was a probably a good reason behind > it. Also, as Kurt mentioned, changes restricting a practice are always > enacted with a lead time to give CAs time to comply. Truly minor changes > (those without a lead time) don't restrict a CAs practices, just permit > additional ways for compliance. [MH] Requiring CA to comply with BRs is good thing. But I also point out that once a CA put a statement of compliance with "latest version" of BRs in CP/CPS, the CA has committed to public that it "has already complied" with all potential changes of BRs at all time. That may be a false statement. The proper approach is for Mozilla's CP to require the CA to perform audit on the latest version of BR. And the audit report must state which version of BR that the CA adhere to. > >> 4) Although relying parties might not frequently review audit reports and >> CPS docs, the Mozilla community does look at CPS docs. Asserting compliance >> in the CPS lets the community know the criteria under which the CA is >> operated and permits them to compare the CPS to a third party standard. >> Without the assertion, the CA isn't telling you anything about which policy >> they are operating under. > I think Mozilla community should have no problem looking at Webtrust report > and CA's assertion to which version of BR since it's required by Mozilla's > CP. I understand that Kathleen is somehow maintaining a spreadsheet of CA > audits, isn't it? This approach is actually a better alternative.
Re: Question about BR Commitment to Comply
-- Man Ho On 1/29/2015 7:10 AM, Jeremy Rowley wrote: > Some initial thoughts: > > 1) Membership in the CAB Forum is not required for a CA to commit to > complying with the BR, and if non-membership avoids any obligation to comply > with the BRs, I think you'll quickly see a mass exodus from the group. No > member of the CAB Forum is bound to its requirements by agreement or through > participation. Instead, the requirements are only imposed by the browsers > are part of their root programs. The question is only whether a CA can have their Webtrust audit statement indicate their commitment to comply with the BRs, rather than putting the commitment to comply statement in the CP/CPS. Therefore, the CA is still required to comply with BR according to Webtrust audit. > 2) The goal of Section 8.3 is for the CA to inform the public about which > certs are being issued in compliance with the BRs and which are not. It's > not a marketing requirement. It's a technical requirement to provide relying > parties (and browsers) information about how the CA operates. Section 8.3 > basically requires the CA to assert that it is doing the MINIMUM required to > issue certs. Any CA unwilling to assert this should not be issuing trusted > certs. The CA's assertion to issue certificate in accordance to BR is REQUIRED by Webtrust audit anyway. The assertion is also publicly disclosed with the audit report. Again, the question is only whether a CA should put a statement in the CP/CPS as section 8.3 required. If yes, it is a marketing requirement, because not aware of other audit requirements or standardization bodies that have such requirement, e.g. Webtrust, ETSI, even Mozilla's CP itself. > 3) Every CA should comply with the latest version of BRs. CAs who are so > inflexible that they can't keep up with the "minor" changes made by the CAB > Forum really shouldn't be issuing certs. Recent "minor" changes include > deprecation of 1024 bit certs, SHA2 migration, deprecation of internal names, > etc. These are pretty important issues, all of which should be promptly > implemented by CAs when adopted. Exactly. Changes in BR may be "minor" or "important" from different point of views. A CA may be in trouble of making a false statement in its CP/CPS if the latest version of BR suddenly changed. Worst of all, the BR is suddenly changed just before annual audit. But of course, the "minor" changes that you have mentioned should have already fulfilled by CAs. > 4) Although relying parties might not frequently review audit reports and CPS > docs, the Mozilla community does look at CPS docs. Asserting compliance in > the CPS lets the community know the criteria under which the CA is operated > and permits them to compare the CPS to a third party standard. Without the > assertion, the CA isn't telling you anything about which policy they are > operating under. I think Mozilla community should have no problem looking at Webtrust report and CA's assertion to which version of BR since it's required by Mozilla's CP. I understand that Kathleen is somehow maintaining a spreadsheet of CA audits, isn't it? This approach is actually a better alternative. > > Obviously, I think an exception to this simple requirement is a mistake. Obviously I don't think that section 8.3 of BR is a simple requirement. > > Jeremy > > > > > -Original Message- > From: dev-security-policy > [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] > On Behalf Of Kathleen Wilson > Sent: Wednesday, January 28, 2015 3:49 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Question about BR Commitment to Comply > > All, > > https://wiki.mozilla.org/CA:BaselineRequirements > Currently says: "The CA's CP or CPS documents must include a commitment to > comply with the BRs, as described in BR section 8.3." > > I have been asked if a CA can have their Webtrust audit statement indicate > their commitment to comply with the BRs, rather than putting the commitment > to comply statement in the CP/CPS. > > Here are the reason: > > 1) We are not a member of CAB/Forum and do not have any mutual agreement that > can bind the obligations and responsibilities of both parties. It seems that > the BR keeps changing very often. > > 2) The requirement of BR section 8.3 is quite weird as there is no such > requirement in other audit criteria such as WebTrust. Would it be a marketing > requirement rather than a technical requirement? > > 3) Further to (1) above, the proposed statement in BR section 8.3 also > requires CA to adhere to the latest published version. But nobody can assure > compliance with it all the time. Even if a particular version number could be > stated, practically it'll take quite a long time to modify our CPS just due > to some minor changes in BR by CAB/Forum. > > 4) On the other hand, since CAs are required to perform Webtrust audit > annually anyway, it seems more appropriate for
Re: Short-lived certs
In an open forum like here, we discuss on standard practice, policy and baseline requirements so to make browsing the Internet more secure. Ad-hoc pre-approval process is not a good practice because it probably has no rules. Moreover, who is going to approve it? Mozilla or members in this group? Will it become another super "Authority"? On 9/6/2014 12:27 AM, Ben Wilson wrote: > Maybe an ad-hoc pre-approval process would work. > > -Original Message- > From: Peter Bowen [mailto:pzbo...@gmail.com] > Sent: Thursday, September 4, 2014 1:07 PM > To: Ben Wilson > Cc: Gervase Markham; mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Short-lived certs > > On Thu, Sep 4, 2014 at 7:54 AM, Ben Wilson wrote: >> Options for trying this out might fit under an exception, if one were >> created, for "test, experimental, temporary, pilot, provisional, etc." >> certificate types. > Ben, > > I think there is value in allowing some level of non-compliance for the > purposes of testing and development, as that is the only way to get real > world > data. However the challenge is going to be not creating a loophole large > enough to drive a truck (or business) through. I have no question there are > customers who would love to pay a CA to issue a 1024-bit RSA certificate > directly from a root with a subject of "CN=exchange" with no subject > alternative name. What would prevent a CA from issuing such a certificate as > a "test, experimental, temporary, pilot, provisional, etc." type certificate? > > Thanks, > Peter > > > ___ > 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: The case for point in time readiness audits (PITRAs)
PITRA should by definition only assess something that are yet to happen, such as new root/sub root and new changes. A normal audit cover the same scope of PITRA and also audit its performance (so called operational efficiency) over a period of time. On 9/3/2014 8:25 PM, Kurt Roeckx wrote: > On 2014-09-02 22:26, Kathleen Wilson wrote: >> >> As always, I will appreciate thoughtful and constructive feedback on >> this. > > Do we need to specify what we understand of that a PITRA should do > exactly, and how it's different from a normal audit? > > > Kurt > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > . > smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: The case for point in time readiness audits (PITRAs)
On 9/3/2014 4:26 AM, Kathleen Wilson wrote: > I updated the wiki page some more, here's the text... > > https://wiki.mozilla.org/CA:BaselineRequirements#BR_Point_in_Time_Readiness_Assessment_.28BR_PITRA.29 > > == BR Point in Time Readiness Assessment (BR PITRA) == > > We previously said: "Any Certificate Authority being considered for > root inclusion after February 15, 2013 must comply with Version 2.1 or > later of Mozilla's CA Certificate Policy. This includes having a > Baseline Requirements audit performed if the websites trust bit is to > be enabled. *Note that the CA's first Baseline Requirements audit may > be a Point in Time audit.*" > > There are two cases when a Point in Time Readiness Assessment of BR > compliance (BR PITRA) may be used: > > 1.The CA has created a new root certificate, which is not yet in > operation producing real certificates. In this case a BR PITRA prior > to inclusion may be used, but the next annual audit after inclusion > would need to be a full performance audit. Note: If the inclusion > process spans more than one annual audit cycle, then more than one BR > PITRA may be used, until the root certificate has been included or the > root certificate is put into operation producing real certificates, > whichever comes first. CAs should have their self-assessment on their readiness to comply with BRs before performing the BR PITRA. In fact, I will not surprise that you will only get "clean" report from those CAs. If not, why the CA bother to submit to Mozilla? Then I suppose that the root certificate should be included in trust store based on the "clean" PITRA report. Finally the CA put the root certificate into operation to produce real certificates. No "whichever comes first" because CA may not have real customers of certificates if the root certificate has not been included yet. Mozilla should then expect the first performance audit within 12 months. > > 2.The CA did not know about the BRs, so did not get audited > according to the BRs during their previous audit cycle. However, the > CA does have a current valid audit statement indicating compliance > with WebTrust Principles and Criteria for Certification Authorities or > ETSI TS 102 042. > -- The BR PITRA option was initially provided for CAs to use > for their first BR audit, so they would not have to go through another > full audit until their next regularly scheduled annual audit. > -- The BR PITRA shall include a performance audit covering at > least one month, or more as determined by the auditor. If it is a performance audit, it is not a PITRA by definition. In some conversations with auditors, they are quite confused at this point. > -- However, it means that an untold number of the previously > issued certificates might not conform to the BRs. This could be > serious, depending on which BRs the CA did not previously comply with, > the number of BRs the CA did not previously comply with, and the > quantity of such certificates issued. Depending on the situation, the > CA may be asked to create a new root certificate for inclusion. Understood that's why you can expect a BR PITRA which may not be a "clean" report. > -- The CA and/or auditor shall provide a list of the BRs that > the previously issued certificates did not comply with. > -- The CA's next annual audit must include a full BR > performance audit. CAs usually perform annual audit over a 12 months period in the past. For example, an audit report dated in January 2015 shows the audit result of the period January - December 2014. If the first BR PITRA audit is performed now in 2014, which may contains a list of the BRs that yet to be complied with, CA must fix the issues on the list in 2015. If so, the first annual audit that include a full BR performance audit should be in January 2016. Is my understanding correct? > == > > As always, I will appreciate thoughtful and constructive feedback on > this. > > Kathleen > > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Allow Redaction of issues detailed in BR Audit statements?
On 8/28/2014 9:42 AM, Man Ho (Certizen) wrote: > I think some CAs don't > even want to claim they are CAB/Forum BR compliant, but just want to be > included in all root certificate programs. What I mean is that some CAs don't want to claim they are CAB/Forum BR compliant, but committed to conform to it in order to be included in all root certificate programs. They just don't bother to publicly claim that they have any connection with CAB/Forum. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Allow Redaction of issues detailed in BR Audit statements?
CA's management assertions is exactly for this purpose, i.e. a public-facing statement. And according to Webtrust, auditor should give an independent opinion on the assertions. Concerning about a list of BRs that the CA is still working to conform with, I don't think CAs will agree to publish in public for security reason and also because of business sensitivity. I think some CAs don't even want to claim they are CAB/Forum BR compliant, but just want to be included in all root certificate programs. On 8/28/2014 12:15 AM, Kathleen Wilson wrote: > On 8/27/14, 7:11 AM, Jean-Marc Desperrier wrote: >> David E. Ross a écrit : >>> With a redacted audit report, the presumption >>> should be that hidden negative information exists that would disqualify >>> the certification authority from having its root certificate in the NSS >>> database if such information were disclosed. >>> >>> any redaction would imply the existence of hidden negative >>> information that would necessitate removal of the affected root >>> certificate from the NSS database if such information were disclosed. >> >> I think there's miscomprehension here. >> >> I understand that the CAs are OK with people knowing that some unknown >> serial numbers would give status “good”, but not with them knowing the >> exact values of the concerned serial numbers, which could be used to >> attack the system. Likewise with the 1024-bit certs with validity beyond >> 2013, it's useful to know they existed but a different matter to get the >> name of the client (in that case, Mozilla could published the number of >> certificates concerned). >> Or letting people know which accounts exactly didn't have multi-factor >> authentication for certificate issuance. >> >> I understand the redaction not to be about which kind of problem there >> was, but about letting specific nominative information be published >> about each problem. > > > Yes. That is a good explanation of the issue. > > So, I thought I would float the idea and see what happens, or see if > others had ideas about this. > > Based on the discussion so far, I think the answer is that the CAs > need to work with their auditors to create a public-facing audit > statement that does not have information in it that the CA considers > sensitive, but that sufficiently lists the BRs that the CA is still > working to conform with. > > Thanks, > Kathleen > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Convergence.
On 4/16/2014 12:08 AM, Daniel Veditz wrote: > The main practical problems with convergence are that it introduces a > dependency on traffic to a 3rd party which hurts privacy, reliability, > and performance. The same problem applies to Certificate Transparency too, but not to OCSP revocation checking. -Man Ho smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Seeking guidance on proceeding with KISA root inclusion request
Hi All, In this discussion of KISA CA, it seems to conclude that KISA root certificate should not be included in Mozilla trust list AND the subordinate CAs should apply for inclusion themselves. On the other hand, in the discussion regarding "Super CA", Mozilla seems to accept inclusion of "Super CA" by saying that their subordinate CAs must apply for inclusion of their own certificate until certain criteria are satisfied. It is very confusing what position Mozilla will take. Does the subordinate CAs required to apply for inclusion themselves? It looks like that KISA CA is by definition also a "Super CA", isn't it? regards Man On 4/1/2014 6:26 AM, Kathleen Wilson wrote: > On 3/4/14, 11:38 AM, Kathleen Wilson wrote: >> All, >> >> I will appreciate your input on how to proceed with the KISA root >> inclusion request. >> > > > All, > > Thank you for your thoughtful and constructive input. > > I believe that there is consensus on the following three points. > > 1) The KISA CA does not issue end-entity certificates for websites > (SSL/TSL), Code Signing, or email (S/MIME), so there is no need for > Mozilla to include the KISA root certificate. > > 2) LCAs are CAs who are licensed by KISA to operate in Korea, and they > issue certificates for websites, code signing, and/or email. LCAs > should apply for inclusion themselves and be audited annually > according to Mozilla's CA Certificate Policy. (sections 11 through 14 > of > http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/) > > 3) Mozilla's policy requires audits that incorporate certain audit > criteria, including the CA/Browser Forum's Baseline Requirements. KISA > may incorporate this audit criteria into their annual audits of their > LCAs, and demonstrate this audit criteria to Mozilla. Or the LCAs may > get another audit from another organization according to this audit > criteria. > > Please let me know if I've missed anything. > > Thanks, > Kathleen > > > > > ___ > 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: Which SHA-2 algorithm should be used?
On 1/8/2014 8:12 PM, Rob Stradling wrote: > Based on the NIST guidance, we've been using SHA-384 when using > RSA-4096 and secp384r1 CA private keys to sign certificates. I've not > yet become aware of any interop issues with stuff that claims to talk > SHA-2. Do you mean using SHA-384 to sign sub-root certificate and then that sub-root certificate sign SHA-384 end-entity certificates? BTW, I have a second thought that the sub-root certificate can be signed with SHA-384 while the end-entity certificates can be signed with SHA-256, or vice versa. It should be possible, shouldn't it? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Which SHA-2 algorithm should be used?
On 1/9/2014 9:34 AM, Peter Gutmann wrote: > What extra security does -512 give you that -256 doesn't? I mean actual > security against real threats, rather than just "it has a bigger number so it > must be better"? According to NIST SP 800-57, only SHA-512 can provide a security strength of 256 bits, while SHA-256 can only provide 128 bits. I am not an expert on crypto, but at least it is what it said. > SHA-512 certainly leads to a loss in performance when used as a MAC > and you have to attach 64 bytes of MAC to a ten-byte payload. I just did a google search again. One analysis is that SHA-256 and SHA-512 have block size of 32 bits and 64 bits respectively. On 64-bit processor, the arithmetic operations can be performed in the same number of clock cycles as either 32-bit or 64-bit operations. Therefore, when working on a 64-bits message, SHA-256 requires two block operations (each performing 64 iterations of arithmetic operations). SHA-512 requires only one block operations (performing 80 iterations of arithmetic operations). It also estimate that when performing operations on 64 bit (8 bytes) message, SHA-512 is about 17% faster and performance levels out with message size of 4096 bits (512 bytes) at about 53% faster. > In addition the > need to have 64-bit op support makes SHA-512 suck on 32-bit systems, which is > most of the embedded world. Yes, this is a real concern Man ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Which SHA-2 algorithm should be used?
On 1/8/2014 8:12 PM, Rob Stradling wrote: > On 08/01/14 11:58, Peter Gutmann wrote: >> Rob Stradling writes: >> >>> SHA-256, SHA-384 and SHA-512 are the algorithms that CAs should use. >> >> In my playing around with all the TLS and SSH implementations I could >> find >> that talk SHA-2, I've found that SHA-256 is the new SHA-1. In other >> words if >> you want interoprability with anything that does SHA-2, go with SHA-256. > > Peter, do you have a list of software/versions that have TLS > implementations that work fine with SHA-256 in certificate signatures > but fail to work with SHA-384 and/or SHA-512 in certificate signatures? > > Based on the NIST guidance, we've been using SHA-384 when using > RSA-4096 and secp384r1 CA private keys to sign certificates. I've not > yet become aware of any interop issues with stuff that claims to talk > SHA-2. > > Thanks. > If there is no constraints on choosing SHA-256, SHA-384 or SHA-512, why CAs are so conservative and prefer SHA-256 rather than SHA-512? I think going directly to a higher security strength should be preferable. Peter mentioned about interop issues. Does anyone encounter interop issues with SHA-512? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Which SHA-2 algorithm should be used?
Hi, I have noted that a lot of arguments being discussed regarding deprecation of SHA-1 certificates, both intermediate CA certificate and end-entity certificates. However, we know SHA-2 is a set of algorithms SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256. Which SHA-2 algorithm should CAs use? It seems that most CAs who has SHA-2 root certificate trusted in Mozilla products has chosen SHA-256. Do you know why not to choose SHA-512 given that SHA-512 is stronger security strength than SHA-256? Man Ho ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Which SHA-2 algorithm should be used?
Hi, I have noted that a lot of arguments being discussed regarding deprecation of SHA-1 certificates, both intermediate CA certificate and end-entity certificates. However, we know SHA-2 is a set of algorithms SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256. Which SHA-2 algorithm should CAs use? It seems that most CAs who has SHA-2 root certificate trusted in Mozilla products has chosen SHA-256. Do you know why not to choose SHA-512 given that SHA-512 is stronger security strength than SHA-256? Man Ho ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
