Re: SHA1 root CA

On 01/03/17 10:36, benjaminp...@gmail.com wrote: > screenshot of the error message: http://imgur.com/a/BIQUm That error message will not occur if only the root CA is SHA-1 signed, because Firefox does not check the signatures on root CAs. There must be some other certificate in the chain that

Re: Intermediates Supporting Many EE Certs

On 13/02/17 12:23, Gervase Markham wrote: > The GoDaddy situation raises an additional issue. > What can be done about the potential future issue (which might happen > with any large CA) of the need to untrust a popular intermediate? > Suggestions welcome. Reviewing the d

Re: Google Trust Services roots

Ryan H, On 23/02/17 04:40, Peter Bowen wrote: > Both Gerv and I posted follow up questions almost two weeks ago. I > know you have been busy with CT days. When do you expect to have > answers available? Ping? :-) Gerv ___ dev-security-policy

Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)

On 26/02/17 00:50, Itzhak Daniel wrote: > I talked with Ofer from Incapsula, he said the domain exist at some > point; Someone have access to domain tools or other tool to verify > this matter? Based on domaintools I can say the domain did exist but > I can't tell when it cease to exist. I think

Re: (Possible) DigiCert EV Violation

On 27/02/17 21:41, Ryan Sleevi wrote: > During a past discussion of precertificates, at > https://groups.google.com/d/msg/mozilla.dev.security.policy/siHOXppxE9k/0PLPVcktBAAJ > , Mozilla did not discuss whether or not it considered > precertificates misissuance, although one module peer (hi! it's

Re: Suspicious test.com Cert Issued By GlobalSign

Hi Doug, On 15/02/17 17:09, Gervase Markham wrote: > But currently GlobalSign employees still are? > > If so, can you help us understand why that's necessary? Given that you > control the domains used for testing, you should be able to set them up > to auto-pass some form of autom

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

On 24/02/17 07:08, blake.mor...@trustis.com wrote: > Certificates for the HMRC SET Service are issued from the SHA-1 “FPS > TT Issuing Authority”, which is now only used for this service. The > replacement server certificate for hmrcset.trustis.com was issued > from the FPS TT IA, via a manual

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

On 22/02/17 17:08, Richard Wang wrote: > I think "apple-id-2.com" is a high risk domain that must be blocked to issue > DV SSL to those domains. I don't represent Let's Encrypt, but their policy on such things is relevant to this discussion, and it is here:

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

On 22/02/17 14:42, Tony Zhaocheng Tan wrote: > On 2017-01-03, Let's Encrypt issued a certificate for apple-id-2.com. > However, until today, the domain apple-id-2.com has apparently never > been registered. How was the certificate issued? On Hacker News, Josh Aas writes: "Head of Let's Encrypt

Mozilla CA Policy 2.4 RC1, and timing

Hi everyone, We've now worked our way through all 21 issues which were scheduled for Mozilla CA Policy 2.4. You can see the current text here: https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md https://github.com/mozilla/pkipolicy/blob/master/ccadb/policy.md

Re: Policy 2.4 Proposal: Update algorithms and key sizes list

On 07/02/17 17:45, Gervase Markham wrote: > We want to update the permitted algorithms and key sizes list. Resolution: resolved as specced (using English descriptions rather than AlgorithmIdentifiers). Gerv ___ dev-security-policy mailing list

Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban

On 07/02/17 17:25, Gervase Markham wrote: > Therefore, we would like to update Mozilla's CA policy to implement a > "proper" SHA-1 ban. Resolution: resolved pretty much as drafted. Gerv ___ dev-security-policy mailing list dev

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

On 16/02/17 18:26, blake.mor...@trustis.com wrote: > Trustis has now revoked the SHA-1 Certificate for hmrcset.trustis.com > and replaced it with a SHA-256 Certificate. This status is reflected > in the latest CRL. Hi Blake, We are pleased to hear that, but the detail of your report compares

Re: SHA-1 serverAuth cert issued by HydrantID (QuoVadis) in January 2017

Hi Stephen, On 16/02/17 18:37, Stephen Davidson wrote: > Incident Report Thank you for your prompt and detailed incident report. It seems to me that this highlights the particular extra care that needs to be taken by all CAs regarding manual issuances which do not use the normal software into

Re: GoDaddy Misissuance Action Items

On 13/02/17 23:53, Wayne Thayer wrote: > Gerv - this makes sense and it is GoDaddy's intent to perform these steps > within 3 months. No significant objections have been put forward about this action plan, and so I have filed a Bugzilla bug to track GoDaddy's implementation:

Re: Intermediates Supporting Many EE Certs

On 13/02/17 19:22, Jeremy Rowley wrote: > As we tied the intermediate to a specific set of companies (which correlated > roughly to a specific volume of certificates), renewal and pinning were > non-issues. As long as each company was identified under the same umbrella, > an entity renewing,

Re: Intermediates Supporting Many EE Certs

On 13/02/17 17:34, okaphone.elektron...@gmail.com wrote: > Isn't this mostly something that CAs should keep in mind when they > setup "shop"? > > I mean it would be nice to have a way of avoiding that kind of impact > of course, but if they think it's best to put all their eggs in one > basket...

Re: Intermediates Supporting Many EE Certs

On 13/02/17 16:17, Steve Medin wrote: > Getting all user agents with interest is issuance limits to implement > the CA Issuers form of AIA for dynamic path discovery and educating > server operators to get out of the practice of static chain > installation on servers would make CA rollovers fairly

Re: Suspicious test.com Cert Issued By GlobalSign

On 13/02/17 14:34, Doug Beattie wrote: > This was for GlobalSign account used for testing, so it was a > GlobalSIgn employee. Customers are not, nor have they ever been, > permitted to add domains without GlobalSign enforcing the domain > verification process. But currently GlobalSign employees

Re: GoDaddy Misissuance Action Items

On 13/02/17 23:13, Santhan Raj wrote: > One thing to highlight here is that the WebTrust audits are performed > against the BRs and not against the root program requirements. This is true, although (apart from the relative importance of domain validation) this is similarly true of many items in

Re: Suspicious test.com Cert Issued By GlobalSign

On 13/02/17 14:34, Doug Beattie wrote: > This was for GlobalSign account used for testing, so it was a > GlobalSIgn employee. Customers are not, nor have they ever been, > permitted to add domains without GlobalSign enforcing the domain > verification process. OK, then I'm a bit confused. You

Re: GoDaddy Misissuance Action Items

On 13/02/17 16:41, Nick Lamb wrote: > GoDaddy came up with). Thus, even though some of the methods from > Ballot 169 are not included in the Baseline Requirements today, > Mozilla intends to oblige root programme members to pick from those > ten methods. Yes. And this is permitted by the BRs

Re: GoDaddy Misissuance Action Items

On 13/02/17 14:34, Nick Lamb wrote: > I don't think Ballot 169 represents best practices per se. Instead as > with the rest of the Baseline Requirements what we have here are > _minimums_, we aren't asking that CAs should do no more than what is > described, but that they must do at least what is

Re: Misissued/Suspicious Symantec Certificates

Hi Steve, On 12/02/17 15:27, Steve Medin wrote: > A response is now available in Bugzilla 1334377 and directly at: > https://bugzilla.mozilla.org/attachment.cgi?id=8836487 Thank you for this timely response. Mozilla continues to expect answers to all reasonable and polite questions posed in our

Intermediates Supporting Many EE Certs

The GoDaddy situation raises an additional issue. Mozilla is neither adding any of the 8951 revoked certificates to OneCRL, nor untrusting any GoDaddy intermediates. However, a more serious incident might have led us to consider that course of action. In that regard, the following information is

GoDaddy Misissuance Action Items

As members of the group will be aware, last month GoDaddy filed an incident report concerning a problem with their domain validation system. Domain validation is the most important task a CA can undertake, any any flaws in it are serious. This is why the CAB Forum has been working for some time

Re: Taiwan GRCA Root Renewal Request

On 11/02/17 12:13, Peter Gutmann wrote: > Is no-one at Mozilla able to explain why they did this? It's a nontrivial > piece of code to implement, surely someone must know what the thinking was > behind doing it this way? Peter: you are going to have to re-summarise your question. And then, if

Re: Google Trust Services roots

Hi Ryan, On 09/02/17 19:55, Ryan Hurst wrote: > - The EV OID associated with this permission is associated with GlobalSign > and not Google and, Which EV OID are you referring to, precisely? > - GlobalSign is active member in good standing with the respective root > programs and, > - Google

Re: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

On 10/02/17 05:10, Peter Bowen wrote: > On Thu, Feb 9, 2017 at 7:41 AM, Gervase Markham via >> A) The date Google took control of the GlobalSign roots >> B) The date Google publicly announced GTS >> >> you will see there's quite a big delta. If you assume Google

Re: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

On 10/02/17 06:15, Richard Wang wrote: > I think Mozilla should have a very clear policy for: > (1) If a company that not a public trusted CA acquired a trusted root key, > what the company must do? > (2) If a company is a public trusted CA that acquired a trusted root key, > what the company

Re: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

On 09/02/17 14:32, Gijs Kruitbosch wrote: > Would Mozilla's root program consider changing this requirement so that > it *does* require public disclosure, or are there convincing reasons not > to? At first glance, it seems like 'guiding' CAs towards additional > transparency in the CA

Re: Question about Baseline Requirements section #7.1.4.2

On 24/01/17 00:01, Peter Bowen wrote: > I agree that the BRs could be clearer, but it seems to me that the > only requirements are country and organization name. Hi Peter, Can you point me at which section requires those two fields? Thanks, Gerv ___

Re: Suspicious test.com Cert Issued By GlobalSign

On 01/02/17 19:47, Doug Beattie wrote: > 9/11/2015 11:41:20 - test.com added as a prevetted domains Who added this - a customer, or a GlobalSign employee? Were customers permitted to add domains to the prevetted list in their enterprise accounts without GlobalSign confirming that they actually

Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban

On 07/02/17 21:02, okaphone.elektron...@gmail.com wrote: > You start by noticing "The scope of the BRs is a matter of > debate..." > > And then you use that same "scope of the BRs" in 1) to specify > Mozilla's requirements. Isn't that somewhat strange, if what you are > trying to do is solve some

Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban

On 07/02/17 19:15, Jakob Bohm wrote: >> Point 2 does not apply if the certificate is an OCSP signing certificate >> manually issued directly from a root. > > Should be point 1 (on OCSP signing certificate is an EE cert) Nope, I'm fairly sure I mean point 2. Rules about intermediate certs don't

Re: Misissued/Suspicious Symantec Certificates

On 05/02/17 09:47, Gervase Markham wrote: > On 05/02/17 06:20, Peter Gutmann wrote: >> That's not a cert issue, it's Firefox objecting to the version of SSL/TLS the >> server is advertising. Hey, it would be pretty funny if the cert auditors' >> certs were broken, but

Re: Appropriate role for lists of algorithms and key sizes

On 07/02/17 18:23, Ryan Sleevi wrote: > For something technical, would you prefer an onlist wording suggestion or > as an on-github submission/pull request? Happy with either, as long as the PR includes any relevant additional text from my recently-posted proposal here. Gerv

Re: Appropriate role for lists of algorithms and key sizes

On 27/01/17 18:53, Ryan Sleevi wrote: > Nits and niggles: Perhaps 2048, 3072, 4096? > > - 8K RSA keys cause Web PKI interop problems > - RSA keys that aren't modulo 8 create interop problems This raises the question if, should our approach to interop problems be: a) We ban anything which

Policy 2.4 Proposal: Implement "proper" SHA-1 ban

It has been noted that currently, Mozilla's SHA-1 ban is implemented via the ban in the BRs, which we require all CAs to adhere to. However, implementing the ban via the BRs is problematic for a number of reasons: * It allows the issuance of SHA-1 certs in publicly-trusted hierarchies in those

Re: Policy 2.4 Proposal: Codify requirements relating to Common CA Database into the policy

On 24/01/17 14:53, Gervase Markham wrote: > It is proposed that we dealing with this from a policy perspective by > doing the following: Resolution: branch merged as drafted. > 5) We will need to update the CCADB-related pages on the Mozilla wiki to > disentangle and remove poli

Re: Policy 2.4 Proposal: Require full CP/CPS in English

On 25/01/17 11:33, Gervase Markham wrote: > "CAs must provide English versions of any Certificate Policy and > Certification Practice Statement documents which are not originally in > English, with version numbers matching the document they are a > translation of. Th

Re: Misissued/Suspicious Symantec Certificates

Hi Steve, On 31/01/17 03:51, Steve Medin wrote: > Our response to questions up to January 27, 2017 has been posted as an > attachment to bug https://bugzilla.mozilla.org/show_bug.cgi?id=1334377. It's now ten days later; are Symantec in a position to answer the next batch of questions, and also

Re: Misissued/Suspicious Symantec Certificates

On 05/02/17 06:20, Peter Gutmann wrote: > That's not a cert issue, it's Firefox objecting to the version of SSL/TLS the > server is advertising. Hey, it would be pretty funny if the cert auditors' > certs were broken, but it's just the browser complaining about something else. That machine

Re: Misissued/Suspicious Symantec Certificates

On 04/02/17 14:32, Ryan Sleevi wrote: > Gerv, as the information Steve shared about their other RAs show, their > issues with RAs are not limited to CrossCert, unfortunately. Check out the > rest of the details included. Ouch. Thank you for drawing these to my attention; I had neglected to read

Re: Misissued/Suspicious Symantec Certificates

On 31/01/17 04:51, Steve Medin wrote: > Our response to questions up to January 27, 2017 has been posted as an > attachment to bug https://bugzilla.mozilla.org/show_bug.cgi?id=1334377. Quoting that document: "Q: 4) In response to the previous incident, Symantec indicated it updated its internal

Re: Misissued/Suspicious Symantec Certificates

On 30/01/17 12:51, Nick Lamb wrote: > CrossCert Certification Practice Statement Version 3.8.8 Effective > Date: JUNE 29, 2012 That date is interesting. The BRs require CPSes to be revised yearly. > "End-user Subscriber Certificates contain an X.501 distinguished name > in the Subject name field

Re: Misissued/Suspicious Symantec Certificates

Hi Nick, On 29/01/17 12:39, Nick Lamb wrote: > 2. It had been my assumption, based on the CPS and other documents, > that CrossCert was restricted in their use of Symantec's issuance > function to C=KR Could you point is at the parts of the CPS or other documents which led you to that belief?

Re: Appropriate role for lists of algorithms and key sizes

On 27/01/17 18:53, Ryan Sleevi wrote: > There's the AlgorithmIdentifier of the key, and the AlgorithmIdentifier of > the signature produced with that key. For the key, you can allow something > like P-256, but for the signature, you want to restrict it to P-256 with > SHA-256. > > This is similar

Re: Misissued/Suspicious Symantec Certificates

Hi Steve, On 27/01/17 01:30, Steve Medin wrote: > Here is an attached PDF update regarding this certificate problem report. Thanks for the update. Here are some questions: * It's not clear what the problem is with the issuance in category F. I don't see any mention of "dev119money.com" in

Re: Policy 2.4 Proposal: Codify requirements relating to Common CA Database into the policy

On 25/01/17 18:38, Ryan Sleevi wrote: > I'm a little wary of introducing #1 until you know what #2 contains, > because to introduce #1, you want to have some way of building > consensus/agreement with different consumers, and that remains unspecified. It does remain unspecified... However, while

Re: Suspicious test.com Cert Issued By GlobalSign

On 25/01/17 17:36, Andrew Ayer wrote: > I found another certificate for www.test.com that I believe was > mis-issued by GlobalSign: > > > https://crt.sh/?sha256=9d503e7c6c4fb6e6d7436c07ff445b95214871ea13ac1cb3b0d7abbce9be6cfb Yes, that looks mis-issued. I realise this was some time ago

Re: Policy 2.4 Proposal: Codify requirements relating to Common CA Database into the policy

On 25/01/17 18:38, Ryan Sleevi wrote: > I'm a little wary of introducing #1 until you know what #2 contains, > because to introduce #1, you want to have some way of building > consensus/agreement with different consumers, and that remains unspecified. > Further, because of the existence of #2, it

Re: Policy 2.4 Proposal: Require full CP/CPS in English

On 25/01/17 07:25, Jakob Bohm wrote: > Tiny nit: What if the original language of the CP/CPS is English. Then > there can't be a "translation" etc. I meant to cover that using the phrasing "must provide English versions", but you are right that I later to on to assume they are translations.

Re: Policy 2.4 Proposal: Require full CP/CPS in English

On 25/01/17 05:15, Matt Palmer wrote: > Is that referring to a dispute between Mozilla (or "a trust store operator", > if you prefer) and the CA, or between a relying party and the CA? I simply mean that the CA has to attest to us that the two are effectively the same. So in any discussion with

Re: Question about Baseline Requirements section #7.1.4.2

On 24/01/17 06:50, Dimitris Zacharopoulos wrote: > The CA/B Forum Policy Review WG made some effort > to > clarify this by merging information between these sections, but there > was not enough support to proceed. Dean's summary

Re: Appropriate role for lists of algorithms and key sizes

On 24/01/17 17:12, Ryan Sleevi wrote: > This means, as a practical matter, I strongly agree with Brian Smith's > suggestion of having an explicit, enumerated list of algorithms (and > parameters) in the Mozilla policy, with the caveat/expectation that Mozilla > policy will be able to be updated in

Re: I found some SHA-1 certificates issued by Symantec

On 24/01/17 15:48, Gervase Markham wrote: > That's because it chains up to the following two roots: > > 1) OU=Class 3 Public Primary Certification Authority > https://crt.sh/?caid=25 This root had its SSL bits disabled around June 2014: https://bugzilla.mozilla.org/show_bug.cgi?id=

Re: I found some SHA-1 certificates issued by Symantec

On 24/01/17 16:08, Peter Bowen wrote: >> Indeed, if they issued these before yesterday, this seems like a problem. > > I'm a little surprised to read this. This SHA-1 "private" hierarchy > is not new news and has been discussed in various forums over the year > or 18 months. At least one other

Re: Question about Baseline Requirements section #7.1.4.2

On 24/01/17 15:48, Peter Bowen wrote: > I think it would be completely reasonable for Mozilla to require a > commonName in an update to the policy. I thought it was there, but a > CA pushed back on a cablint error about not having one a while ago and > I wasn't able to find any proof it was

Re: I found some SHA-1 certificates issued by Symantec

On 24/01/17 16:00, Richard Barnes wrote: > Except of course the non-zero slice of users that haven't updated yet. True, although I think it's unreasonable to give CAs a dependency on the quality of our automatic update infrastructure. We can have a discussion about whether "checked into master"

Re: I found some SHA-1 certificates issued by Symantec

On 24/01/17 14:11, w...@gmail.com wrote: > I was searching on crt.sh and I found something confusing by accident. > View this page : https://crt.sh/?Identity=%25=7198 > I can see many SHA-1 certificates issued in 2016 and one is issued in 2017. Your list is a list of certificates issued by

Appropriate role for lists of algorithms and key sizes

A discussion inspired by https://github.com/mozilla/pkipolicy/issues/5 Should Mozilla's root store policy contain any list of approved and/or disapproved algorithms/key sizes, or not? Possible positions include at least: 0) No; what algorithms and/or key sizes are supported by Firefox and/or NSS

Policy 2.4 Proposal: Require full CP/CPS in English

The proposal is to require that all CP and CPS documents be provided in English, in addition to whatever original language they were written in. The reason for this is that the working language of the Mozilla root program is English, and Mozilla's root program staff cannot be expected to read the

Policy 2.4 Proposal: Codify requirements relating to Common CA Database into the policy

Mozilla has started using the Common CA Database to track root certificates in its root program, and the intermediate certificates which chain up to those roots. This has led to substantial changes to the practical processes that CAs must follow. In addition, it is hoped and anticipated that other

Re: Certificate validation phishing

On 24/01/17 09:08, Nick Lamb wrote: > That's absolutely key to understanding why this trick works. Such an > understanding is completely absent from the patent, because the > patent isn't describing what the Baseline Requirements call a Request > Token but only a Random Value which it calls the

Re: Policy 2.4 Proposal: Define how quickly audit reports must be provided

On 18/01/17 15:31, Kurt Roeckx wrote: > And I would like to see that as a requirement in the audit report, > which CA are actually checked. https://github.com/mozilla/pkipolicy/issues/50 . Gerv ___ dev-security-policy mailing list

Re: Policy 2.4 Proposal: Define how quickly audit reports must be provided

On 17/01/17 23:27, Jakob Bohm wrote: > Notes on the text in that branched section (other than the actual > change discussed here): > > - It does not include some other changes under discussion (such as the > new version of the BRs). This may need to be manually reapplied after > merging in the

Re: Policy 2.4 Proposal: Define how quickly audit reports must be provided

On 17/01/17 23:33, Jakob Bohm wrote: > How about "_and versions and strong (>= 256 bits) hashes_", Do people think we need to go this far? If we do, we'll need them to specify filenames, not just document titles. Otherwise, one wouldn't know if the hash was a .doc, a .pdf, or what. Gerv

Re: Policy 2.4 Proposal: Update required version number of Baseline Requirements to 1.3.7

On 17/01/17 23:32, Ryan Sleevi wrote: > BRs 1.3.0 ( https://cabforum.org/wp-content/uploads/CAB-Forum-BR-1.3.0.pdf > ) already include the clause (in Section 2.2) that: > "The CA SHALL publicly give effect to these Requirements and represent > that it will adhere to the latest published version."

Re: Policy 2.4 Proposal: Define how quickly audit reports must be provided

On 13/01/17 02:00, Ryan Sleevi wrote: > Suggestion: "List of CA policy documents _and versions_" Yes, good idea. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.4 Proposal: Update required version number of Baseline Requirements to 1.3.7

On 13/01/17 01:56, Ryan Sleevi wrote: > Notably, 1.3.7 also has IP encumbrances - and uncertainty - the same > as 1.4.1, so presumably, Mozilla is OK with having encumbered methods > included. Considering some of these exclusions have existed since the > BR's adoption, that doesn't seem an

Re: GoDaddy verification issue history appears incomplete: possible regression of bug in 2010

On 13/01/17 17:10, Fred Emmott wrote: > In January 2010, I reported two issues to GoDaddy, with an example > certificate that should have been rejected: - their website-based > authentication required a request to an URL including a random string > to include the same random string. Reading

Policy 2.4 Proposal: Define how quickly audit reports must be provided

The current CA policy does not specify when audit reports are due to Mozilla relative to the end date of the audit period. It only says that CAs much provide the reports to Mozilla within 30 days of receiving the report from their auditor. Peter Bowen proposed some revised and more specific

Policy 2.4 Proposal: Update required version number of Baseline Requirements to 1.3.7

Point 12 of the Inclusion section requires conformance to the Baseline Requirements version 1.3, released on 16th April 2015. The current version is 1.4.1. I propose changing to version 1.3.7. This is the one before the version which updated the domain validation requirements and which has had to

Policy 2.4 Proposal: Update version number of EV Guidelines to 1.6

Currently, Inclusion point 7 requires conformance to EV 1.4 or later. This was released in May 2012. The current version of EV (as of a week ago) was 1.6. We should update directly to 1.6, which was released in July 2016. This is: https://github.com/mozilla/pkipolicy/issues/29 --- This is

Re: Policy 2.4 Proposal: Update entropy requirements for EE certificates

On 16/12/16 15:18, Gervase Markham wrote: > Nevertheless, we should update our policy to also use this text, because > our policy also covers email certificates. We discussed this at the All > Hands recently and we did not think that there were any compelling > reasons to provid

Re: Policy 2.4 Proposal: Define or remove the word "misused"

On 16/12/16 15:20, Gervase Markham wrote: > Kathleen's proposal is to change: > > "or that the certificate has otherwise been misused;" > > to > > "or that the certificate has been used for a purpose outside of that > indicated in the certific

Re: Policy 2.4 Proposal: Require OCSP responses to be signed by certs with lifetime longer than response

On 16/12/16 15:15, Gervase Markham wrote: > Proposal: add another sentence to the second bullet in point 3 of the > Maintenance section: > > "The nextUpdate of the OCSP response must be before or equal to the > notAfter date of the certificate which signs it, and all

Re: Policy 2.4 Proposal: Use language of capability throughout

On 08/12/16 20:46, Gervase Markham wrote: > We want to change the policy to make it clear that whether a cert is > covered by our policy or not is dependent on whether it is technically > capable of issuing server certs, not whether it is intended by the CA > for issuing server certs

Re: Incident Report – Certificates issued without proper domain validation

Hi Wayne, Thanks for these prompt and detailed responses. On 12/01/17 00:27, Wayne Thayer wrote: > Our initial response as reported yesterday was to fix the bug > introduced in July. Based on internal discussions and comments here, > as of 12 midnight PST last night (1/11) we stopped using this

Re: Incident Report – Certificates issued without proper domain validation

Hi Wayne, As others have said, thanks for bringing this to our attention. On 11/01/17 03:02, Wayne Thayer wrote: > results even when the HTTP status code was not 200. Since many web > servers are configured to include the URL of the request in the body > of a 404 (not found) response, and the

Re: Compliance with 7.1.4.2.1 (internal names revocation)

On 03/01/17 18:11, Nick Lamb wrote: > As mentioned previously I have been working on verifying that CAs > complied with BR 7.1.4.2.1 Thank you for your vigilance :-) > Do we care in m.d.s.policy about such deviations? Or only those which > affect CAs trusted, recently trusted or soon to be

Re: wosign and letsencrypt.cn / letsencrypt.com.cn

On 22/12/16 14:30, Tom Delmas wrote: > There are other mechanisms. But hard to use, especially between > countries. As a Firefox user, > I expect that CA trusted by Firefox are clearly identifiable and > distinguishable from each others. If CAs ever did something specific to Firefox or the root

Re: wosign and letsencrypt.cn / letsencrypt.com.cn

On 21/12/16 12:42, tdel...@gmail.com wrote: > I think Mozilla still doesn't answer my first question:what is the > position of Mozilla regarding CA that act in bad faith regarding the > usage of the names associated with others CA (like, registering such > trademarks or domains) ? It's never come

Re: SHA-1 exception First Data

On 16/12/16 17:55, Nick Lamb wrote: > So here we are, three months later, First Data are back, as predicted, asking > for another "exception". Those reading the CAB Forum list will note that Mozilla has declined to grant an additional exception. Gerv

Re: Policy 2.4 Proposal: Require open licensing of CPs and CPSes

On 21/12/16 05:38, Jakob Bohm wrote: >> I'm not sure what you are getting at; m.d.s.p is "in writing", as is "in >> Bugzilla". I say "in writing" because I want to make sure some CA >> doesn't come back with "you said it was OK when we chatted at CAB >> Forum", or "you implied it was OK by

Re: sha1 Jan 2017

On 19/12/16 16:54, Michael Jones wrote: > Can someone clarify if the sha1 deprication will apply also to > intermediate and or CA certs? Yes, and no, respectively. > Will this cause any issues in the new year? We'll see :-) Hopefully not. > I see mention of Intermediate Certs but no mention of

Re: Policy 2.4 Proposal: Use language of capability throughout

On 16/12/16 21:56, Brian Smith wrote: > What does "working" mean? If I were a CA I would interpret "working" > to mean "works in Firefox" Working means, I guess, "RFC 5280 etc. expect it to work". Conflicting name constraints, no-one expects to work. AnyEKU, some people do. > which would then

Policy 2.4 Proposal: Define or remove the word "misused"

The word "misused" in the policy could do with clarifying. The Maintenance Policy states: "2. CAs must revoke Certificates that they have issued upon the occurrence of any of the following events: ... the CA obtains reasonable evidence that the subscriber’s private key (corresponding to the

Policy 2.4 Proposal: Update entropy requirements for EE certificates

Currently, the policy says: "all new end-entity certificates must contain at least 20 bits of unpredictable random data (preferably in the serial number)." We should require the random data to be in the serial number, and also update the number of bits required. BRs 1.3.7 and later say:

Policy 2.4 Proposal: Require OCSP responses to be signed by certs with lifetime longer than response

When an OCSP response signing certificate expires before the OCSP responses signed by the certificate expire, multiple websites break, particularly sites that use OCSP stapling. Make it a requirement that every OCSP response must have a nextUpdate field that is before or equal to the notAfter date

Re: Policy 2.4 Proposal: Require open licensing of CPs and CPSes

On 14/12/16 23:13, Eric Mill wrote: > Sure, that works. Is the "in writing" part necessary? You might say instead > "publicly accepted by Mozilla.", which would imply text on m.d.s.p or > bugzilla that would necessarily be in writing, while also ensuring better > visibility. I'm not sure what you

Re: Policy 2.4 Proposal: Require open licensing of CPs and CPSes

On 08/12/16 20:48, Gervase Markham wrote: > Require CAs to publish their CPs and CPSes under one of the following > Creative Commons licenses: CC-BY, CC-BY-SA or CC-BY-ND. > > This is so that there is no legal impediment to their proper storage, > scrutiny etc. by relying parties

Re: Policy 2.4 Proposal: Require all OCSP responses to have a nextUpdate field

On 08/12/16 20:47, Gervase Markham wrote: > Proposal: update the second bullet in point 3 of the Maintenance section > so that the last sentence reads: > > OCSP responses from this service must have a defined value in the > nextUpdate field, and it must be no more than

Re: Policy 2.4 Proposal: Use language of capability throughout

On 10/12/16 21:25, Brian Smith wrote: > Again, it doesn't make sense to say that the forms of names matter for > name constraints, but don't matter for end-entity certificates. If an > end-entity certificate doesn't contain any names of the forms dNSName, > iPAddress, SRVName, rfc822Name, then it

Re: Policy 2.4 Proposal: Use language of capability throughout

On 10/12/16 21:14, Brian Smith wrote: > "Unable to issue" means "unable to sign with the private key" which > can only happen if they don't have the private key. But they do have > the private key so they're always able to issue certificates with any > contents they want. Thus "unable to issue" is

Re: Policy 2.4 Proposal: Require open licensing of CPs and CPSes

On 12/12/16 05:35, Eric Mill wrote: > It's possible there are other edge cases out there that make blanket CC0 or > CC-BY nor practical. I think adding some catch-all text that allows for a > solution ensuring no copyright-based restrictions of any kind would allow > for the bit of flexibility

Re: Policy 2.4 Proposal: Require open licensing of CPs and CPSes

On 08/12/16 11:41, Jakob Bohm wrote: > This could easily conflict with other legal obligations, such as > requirements to license said documents under a specific other license. I don't think so; nothing prevents a CA providing multiple potential sets of license terms for a document. > It would

Re: Policy 2.4 Proposal: Use language of capability throughout

On 08/12/16 13:06, Brian Smith wrote: > In particular, I suggest replacing "unable to issue server or email > certificates" with "unable to issue *trusted* server or email > certificates" or similar. I think I would prefer not to make that tie, because the obvious question is "trusted in which

Re: Policy 2.4 Proposal: Require all OCSP responses to have a nextUpdate field

On 08/12/16 12:46, Brian Smith wrote: > Are you intending to override the BR laxness for maximum OCSP lifetime > for intermedaites, or just match the BR requirements? The wider context of this section includes an "For end-entity certificates:". So the wording as proposed matches the BRs in terms

<    1   2   3   4   5   6   7   8   9   10   >