Re: BR compliance of legacy certs at root inclusion time

On 21/08/17 06:20, Peter Kurrasch wrote: > The CA should decide what makes the most sense for their particular > situation, but I think they‎ should be able to provide assurances that > only BR-compliant certs will ever chain to any roots they submit to the > Mozilla root inclusion program. So

BR compliance of legacy certs at root inclusion time

Sometimes, CAs apply for inclusion with new, clean roots. Other times, CAs apply to include roots which already have a history of issuance. The previous certs issued by that CA aren't always all BR-compliant. Which is in one sense understandable, because up to this point the CA has not been bound

Re: Responding to a misissuance

On 18/08/17 13:03, Doug Beattie wrote: > And if there is any guidance on processing misissuance reports for > Name constrained sub-CA vs. not name constrained, that would be > helpful also. What parts of a response do you think might be different for name-constrained sub-CAs? Gerv

Re: Responding to a misissuance

Hi Rich, On 18/08/17 12:51, richmoor...@gmail.com wrote: > Perhaps some explicit statements about sub-CAs would be helpful - > detailing where responsibility lies and how a CA is required to deal > with a sub-CA who is found to have misissued. Do you specifically mean sub-CAs which are run by

Re: Bugzilla Bugs re CA issuance of non-compliant certs

On 17/08/17 00:18, Kathleen Wilson wrote: > == Let’s Encrypt == > RESOLVED (no bug needed) > == Staat der Nederlandend / PKIoverheid == > RESOLVED (no bug needed) While the timely responses and performance of these CAs is commendable, it may be worth opening a bug and recording the events and

Re: O=U.S. Government for non-USG entity (IdenTrust)

On 17/08/17 20:31, Jeremy Rowley wrote: > Without an FQDN, I doubt they are in scope for the baseline requirements. Not according to the BRs themselves. However, the Mozilla Policy 2.5 specifically says: "Insofar as the Baseline Requirements attempt to define their own scope, the scope of this

Re: Certificate with invalid dnsName issued from Baltimore intermediate

On 15/08/17 16:53, Ben Wilson wrote: > Attached is an audit from 2016. They are due for another one for 2017. Attachments don't appear on this list, but I have the docs. Please email me if you'd like them. I've asked Ben to update CCADB to point to them, and to also update any other entries

Responding to a misissuance

I've started a wiki page giving Mozilla expectations and best practices for CAs responding to a misissuance report. (No idea why I decided to write that now...) https://wiki.mozilla.org/CA/Responding_To_A_Misissuance Comments on whether the content is correct, and what might be missing, are most

Re: Bugzilla Bugs re CA issuance of non-compliant certs

On 15/08/17 21:24, Kathleen Wilson wrote: > Mozilla's Root Store policy says: "CAs MUST follow and be aware of > discussions in the mozilla.dev.security.policy forum, where Mozilla's > root program is coordinated." > > There is no indication about how frequently a representative of the > CA must

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

On 07/08/17 22:30, Jakob Bohm wrote: > Since the CT made it possible, I have seen an increasing obsession with > enforcing every little detail of the BRs, things that would not only > have gone unnoticed, but also been considered unremarkable before CT. I am firmly of the opinion that all BR and

Re: Expired Certificates Listed by Certificate Manager

On 15/08/17 13:59, Ryan Sleevi wrote: > Note: adding to certdata.txt, at present, will have various undesirable > side-effects: > > - Distrust records, without associated certs, can present UI issues when > viewing and editing (which is why the associated certs are included in > certdata.txt)

Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

On 14/08/17 16:44, Arno Fiedler wrote: > fulfilled. On 20-07-17 Mozilla asked D-TRUST for clarification, due > to the holiday period this message reached us on 07-08-17, AF > answered on 08-08-17 I was going to complain about this but, re-reviewing the CCADB Common Policy[0], it says:

Re: Misissued certificates

On 10/08/17 19:35, Jeremy Rowley wrote: > This is interesting. We had one Sub CA who mis-issued some pre-certs but > then never issued an actual certificate tied to the pre-certificate. There > was a previous Mozilla discussion (link coming) where mis-issuance of a > pre-certificate was akin to

Re: CA Problem Reporting Mechanisms

On 08/08/17 20:02, Jeremy Rowley wrote: > +1. CAs should be required to support certificate problem reports > sent through a specified email address. It simplifies the process a > lot if CAs use at least one common mechanism. https://github.com/mozilla/pkipolicy/issues/98 Gerv

Re: Miss-issuance: URI in dNSName SAN

On 08/08/17 14:33, Alex Gaynor wrote: > Following up on this thread, 8 days ago I emailed Camerfirma, I have not > heard back from them, nor have they taken any action. What is the > appropriate next step here? I have emailed the primary Point of Contact at Camerfirma to enquire as to what is

Re: Miss-issuance: URI in dNSName SAN

On 31/07/17 15:14, Alex Gaynor wrote: > So far I've encountered issues with: > > - DocuSign (OpenTrust/Keynectis) - who neglected to fill out that field > - StartCom - who filled out "web publication", I don't know what that means I have emailed both of these CAs to request that they provide

Re: English translation for Certinomis root CP/CPS?

On 04/08/17 16:11, Jonathan Rudenberg wrote: >> CAs must provide English versions of any Certificate Policy, >> Certification Practice Statement and Audit documents which are not >> originally in English, with version numbers matching the document >> they are a translation of. Note that this

Re: Certificate with invalid dnsName issued from Baltimore intermediate

Hi Ben, On 03/08/17 15:38, Ben Wilson wrote: > Here is the response from Intesa Sanpaolo concerning the disruption that > revocation will cause to their banking operations: I've looked up the certs relating to this sub-CA in the CCADB. The key in question:

Re: Certificate with invalid dnsName issued from Baltimore intermediate

Hi Ben, On 03/08/17 14:32, Ben Wilson wrote: > That would be fine. Also, we have given Intesa Sanpaolo a scheduled > revocation date of 15 August 2017, and I'm waiting to hear back. That's today; is it still the plan to revoke their intermediate? Gerv

Re: TunRootCA2 root inclusion request

On 03/08/17 08:01, Olfa Kaddachi wrote: > ==> Some of these controls are already in place (such as the field CN and > Subject Alternative Name that does not contain a private IP address). That doesn't quite answer my question. Let me ask another way: for how long has the Government of Tunisia

Re: Expired Certificates Listed by Certificate Manager

On 01/08/17 09:21, userwithuid wrote: > In this context @Mozilla: Those additional distrust entries are > coming from NSS, but they are all pre-OneCRL afaics. Is this > coincidence (= there wasn't any "high-profile" enough distrust > warranting nss addition) or has the certdata-based distrust been

Re: Bad characters in dNSNames

Hi Rob, On 26/07/17 11:21, Rob Stradling wrote: > https://docs.google.com/spreadsheets/d/1IACTYMDXcdz4DoMKxkHfePfb5mv2XN68BcB7p6acTqg/edit?usp=sharing Thanks for this. Any chance of saving me a bit of time by cross-referencing each line with the "CA owner" from the CCADB? If that's too much

Re: SRVNames in name constraints

On 06/07/17 16:56, Ryan Sleevi wrote: > Relevant to this group, id-kp-serverAuth (and perhaps id-kp-clientAuth) So what do we do? There are loads of "name-constrained" certs out there with id-kp-serverAuth but no constraints on SRVName. Does that mean they can issue for any SRVName they like? Is

Re: FW: P-521

On 05/07/17 11:40, Arkadiusz Ławniczak wrote: > As CERTUM, we are not aware of any implementations which do not > support P-521 (with the exception of BoringSSL where P-512 is > disabled but not unsupported). Yes, but that means that whenever Chrome uses BoringSSL, your roots won't work, right?

Re: High traffic on this list, and Mozilla root program involvement

Hi Jeremy, On 09/08/17 21:57, Jeremy Rowley wrote: > I was thinking you should just have the Cas add them all for you. Makes it > easier on you and demonstrates they are tracking and remediating these > issues. If I were going to create a bug for these in Mozilla would you > prefer to see one

Re: High traffic on this list, and Mozilla root program involvement

On 09/08/17 00:12, Jeremy Rowley wrote: > Do you want that added as a new bug for all the issues listed? I'm not sure I follow. Do I want what added? I will be filing any additional appropriate bugs when I get around to triaging all the messages in this forum. Gerv

Re: Final Decision by Google on Symantec

On 28/07/17 07:14, Gervase Markham wrote: > I would like to make a decision on this matter on or before July 31st, After listening to the opinions here on m.d.s.p., and consultation within Mozilla and with our engineering teams, on the matter of when to distrust various bits of the existing

Re: Final Decision by Google on Symantec

On 31/07/17 15:17, Jakob Bohm wrote: > I am referring to the fact that EV-trust is currently assigned to roots, > not to SubCAs, at least as far as visible root store descriptions go. You said the problem was Mozilla-specific; do other root stores not do it this way? Gerv

Re: Miss-issuance: URI in dNSName SAN

On 25/07/17 18:13, Jeremy Rowley wrote: > I would also love to see a more standardized notice mechanism that is > universal to all CAs. Right now, notifying CAs is a pain as some have > different webforms, some use email, and some don't readily tell you how to > contact them about certificate

Re: Final Decision by Google on Symantec

On 29/07/17 23:45, Peter Bowen wrote: > First, when the server authentication trust will bits be removed from > the existing roots. This is of notable importance for non-Firefox > users of NSS. Based on the Chrome email, it looks like they will > remove trust bits in their git repo around August

Re: TunRootCA2 root inclusion request

Hi Olfa, On 31/07/17 11:55, Olfa Kaddachi wrote: > 2) The deficiencies identified in those controls after the misissuance of > each of these certificates are essentially: > •controls on the field subject alternative names : > o this field must not contains private addresses > o this

Final Decision by Google on Symantec

Google have made a final decision on the various dates they plan to implement as part of the consensus plan in the Symantec matter. The message from blink-dev is included below. Most of the dates have consensus - the dates for Symantec to implement the Managed CA infrastructure are agreed by all,

Re: Symantec Update on SubCA Proposal

Hi Rick, Some more thoughts on your post. I continue to invite community commentary on the issues we are discussing. On 21/07/17 07:00, Rick Andrews wrote: > In our June 1 post, we stated that we would update the community after the > end of the month. Indeed. I was more referring to the

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

On 20/07/17 21:31, Ryan Sleevi wrote: > Broadly, yes, but there's unfortunately a shade of IP issues that make it > more difficult to contribute as directly as Gerv proposed. Gerv may accept > any changes to the Mozilla side, but if the goal is to modify the Baseline > Requirements, you'd need to

Re: Symantec Update on SubCA Proposal

On 21/07/17 07:00, Rick Andrews wrote: > In light of all of these implications, we respectfully request that Mozilla, > Google and the community consider the dates Symantec has proposed, which are > the results of our earnest and extensive efforts to implement the spirit of > the SubCA

Re: Symantec Update on SubCA Proposal

Hi Steve, Thanks for posting this. I appreciate the level of detail provided, which is useful in giving us a basis for discussion. It's a little regrettable, though, that it was published a couple of weeks after we were led to expect it... One note before we start: Symantec's business dealings

Re: Validation of Domains for secure email certificates

Hi Doug, On 20/07/17 13:04, Doug Beattie wrote: > Since there is no BR equivalent for issuance of S/MIME certificates (yet), > this is all CAs have to go on. I was curious if you agree that all of these > methods meet the above requirement: As you might imagine, this question puts me in a

Re: Miss-issuance: URI in dNSName SAN

On 19/07/17 14:53, Alex Gaynor wrote: > I'd like to report the following instance of miss-issuance: Thank you. Again, I have drawn this message to the attention of the CAs concerned (Government of Venezuela and Camerfirma). Gerv ___ dev-security-policy

Re: dNSName containing '/' / low serial number entropy

On 18/07/17 23:25, Charles Reiss wrote: > https://crt.sh/?id=174827359 is a certificate issued by D-TRUST SSL I'm supposed to be on holiday :-), but I have emailed the 3 CAs concerned drawing these issues to their attention, and asking them to comment here when they have discovered the cause.

Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

On 18/07/17 17:51, Matthew Hardeman wrote: > The broader point I wish to make is that much can be done do improve the > strength of the various subset of the 10 methods which do rely solely on > network reliant automated validation methodologies. The upside would be a > significant,

Re: How long to resolve unaudited unconstrained intermediates?

On 12/07/17 21:18, Ben Wilson wrote: > For CAs with emailProtection and proper name constraints, where would such > CAs appear in > https://crt.sh/mozilla-disclosures? > >

Re: WoSign new system passed Cure 53 system security audit

On 13/07/17 04:43, Matt Palmer wrote: > Who should we contact at Cure 53? Or should we just use the "business > enquiries" contact address on their website? I doubt Cure53 would be able to tell you anything more than what has been said in the released summary document. Gerv

Re: Leaking private keys through web servers

On 12/07/17 15:47, Ryan Sleevi wrote: > One challenge to consider is how this is quantified. Obviously, if you > reported to Comodo the issue with the key, and then they issued another > certificate with that key, arguably that's something Comodo should have > caught. I'd say so. > However, if

Re: Root Store Policy 2.5: Call For Review and Phase-In Periods

On 06/07/17 16:31, Doug Beattie wrote: > Moving to a new CA within 6 months is certain reasonable, but having > enterprise customers also replace all certificates so the CA can be revoked > within 6 months might be a bit short, especially since several of those > months are over the holidays.

Re: FW: P-521

On 06/07/17 16:20, Ryan Sleevi wrote: > compelling to add support for, and the security boundary between 192-bits > and 256-bits is somewhere in the "heat death of the universe" level > security (see > https://www.imperialviolet.org/2014/05/25/strengthmatching.html ) Perhaps this is the

Re: Machine- and human-readable format for root store information?

On 05/07/17 18:08, Ryan Sleevi wrote: > That is, the difference between, say: > "label": "Verisign/RSA Secure Server CA" > And > CKA_LABEL "Verisign/RSA Secure Server CA" Not much, but you've picked the clearest part of certdata.txt to compare :-) > It isn't, because JSON can't. As Rob notes,

Re: Machine- and human-readable format for root store information?

On 06/07/17 14:44, Kai Engert wrote: > My response was based on my interpretation of Gerv's suggestion, which I > understood as follows: > - certdata.txt remains the master, keeps maintained and published with NSS > - we define a new file format that's accepted as the standard for several > root

Re: SRVNames in name constraints

On 05/07/17 15:10, Peter Bowen wrote: > The second bullet says “any”. As the rule for name constraints is that if > they are not present for a type, then any name is allowed, you have to > include name constraints for all four types. The issue comes down to the > definition of “working

Re: FW: P-521

On 05/07/17 14:49, Alex Gaynor wrote: > Is it really true that additional curves are just additional parameters? I That was my assumption; additional clue on this point would be welcome. Gerv ___ dev-security-policy mailing list

Re: FW: P-521

I agree crypto algorithms are not "gotta catch 'em all", but the algorithm is ECDH, which NSS must implement anyway to support P-256 and P-384, and a curve is just another set of parameters to it. I also think that there is little value and there is potential confusion (as we have seen) in Mozilla

Re: Machine- and human-readable format for root store information?

On 03/07/17 16:09, Kai Engert wrote: > I'd prefer a simple open source tool that operates on files, which can be used > from a command line, with a free license, e.g. MPL2. Of course. > If the intention is to define a file format that is shared with other groups, > who would be the owner of the

Re: Machine- and human-readable format for root store information?

On 03/07/17 16:53, Kai Engert wrote: > On Wed, 2017-06-28 at 15:08 -0700, Ryan Sleevi via dev-security-policy wrote: >> On Wednesday, June 28, 2017 at 5:29:19 PM UTC-4, Gervase Markham wrote: >>> Well, the fact that we now use Git, > > NSS and the root store don't use Git, it uses HG/Mercurial.

Re: Machine- and human-readable format for root store information?

On 29/06/17 16:27, Ryan Sleevi wrote: > Well, the current certdata.txt is a text file. Do you believe it's > human-readable, especially sans-comments? Human readability is, of course, a little bit of a continuum. You can open it in a text editor and get some sense of what's going on, but it's

Re: SRVNames in name constraints

On 03/07/17 17:44, Peter Bowen wrote: > We still need to get the policy changed, even with the ballot. As > written right now, all name constrained certificates are no longer > considered constrained. I'm not sure what you mean... What's the issue you are raising here? Gerv

Re: SRVNames in name constraints

On 03/07/17 17:29, Peter Bowen wrote: > "name constraints which do not allow Subject Alternative Names (SANs) > of any of the following types: dNSName, iPAddress, SRVName, > rfc822Name" > > SRVName is not yet allowed by the CA/Browser Forum Baseline > Requirements (BRs), so I highly doubt any CA

Re: Symantec meeting and status

Hi Peter, I note you have copied in our press team and that you are a journalist; I will answer your question as I would the same question from any member of our community here if it were asked in this forum. On 03/07/17 16:54, Loshin, Peter wrote: > Other than stating that it will be publishing

Symantec meeting and status

Hi everyone, As I was in the Bay Area for the Mozilla All Hands, Symantec requested a face-to-face meeting with Mozilla, which happened last Friday. In attendance were Tom Ritter, Aaron Wu and I for Mozilla, and the following people from Symantec (I hope I have the titles right): * Quentin Liu

Re: Machine- and human-readable format for root store information?

Hi Kai, On 30/06/17 17:38, Kai Engert wrote: > given that today we don't have a single place where all of Mozilla's > certificate > trust decisions can be found, introducing that would be a helpful. I'm glad you see the value in my goal :-) > I think the new format should be as complete as

Re: P-521

On 29/06/17 00:11, Arkadiusz Ławniczak wrote: > P-256, P-384 and P-521 curves are commonly implemented in all popular > cryptographic libraries such as OpenSSL, Microsoft Crypto API NB (CNG) or > Bouncy Castle, popular web browsers and FIPS 140-2 certified hardware > cryptographic modules. Are

Re: Machine- and human-readable format for root store information?

On 28/06/17 15:08, Ryan Sleevi wrote: > It already (effectively) requires a tool to make sure it's done right, AIUI :) Well, we should ask Kai what methods he uses to maintain it right now, and whether he uses a tool. > You can have a JSON file, but that doesn't mean it's human-readable in the

Re: Machine- and human-readable format for root store information?

On 28/06/17 06:38, Ryan Sleevi wrote: > Not really, at least from the NSS perspective. There's been the CVS -> > Mercurial -> Git(ish) transitions, but otherwise, the tools and > dependencies have largely remained the same. Well, the fact that we now use Git, I suspect, means anyone could plug in

Re: Machine- and human-readable format for root store information?

On 27/06/17 12:17, Ryan Sleevi wrote: > This was something the NSS developers explicitly moved away from with > respect to certdata.c It would be interesting to know the history of that; but we are in a different place now in terms of the SCM system we use and the CI tools available, versus what

Re: Machine- and human-readable format for root store information?

On 27/06/17 10:35, Ryan Sleevi wrote: > If that is the goal, it may be useful to know what the proposed limitations > / dependencies are. For example, the translation of the txt to the c file > generated non-trivial concern among the NSS development team to support. I propose it be part of the

Re: P-521

On 27/06/17 07:17, Kurt Roeckx wrote: > I suggest you keep it for now. An opinion without a rationale is not all that useful :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: Machine- and human-readable format for root store information?

On 27/06/17 04:16, Rob Stradling wrote: > If the aim is to replace certdata.txt, authroot.stl, etc, with this new > format, then I'm more interested. I can't speak for other providers, but if such a spec existed, I would be pushing for Mozilla to maintain our root store in that format, and

Re: Machine- and human-readable format for root store information?

On 26/06/17 17:36, Ryan Sleevi wrote: > Do you anticipate this being used to build trust decisions in other > products, or simply inform what CAs are trusted (roughly)? I don't have strong opinions about what people use the data for; I would hope it would be usable for either purpose. After all,

P-521

This issue seems to come up regularly, and I can never find the discussion I'm sure we had about it, so I'm starting a thread here with "P-521" in the subject so it'll be clear. Should we be permitting use of this curve in our policy? I removed it from the policy in

Machine- and human-readable format for root store information?

A few root store operators at the recent CAB Forum meeting informally discussed the idea of a common format for root store information, and that this would be a good idea. More and more innovative services find it useful to download and consume trust store data from multiple parties, and at the

Mozilla Root Store Policy 2.5 Published

Version 2.5 of Mozilla's CA Policy has now been published. You can find it here: https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md This document incorporates by reference the Common CCADB Policy 1.0.1: https://github.com/mozilla/pkipolicy/blob/2.5/ccadb/policy.md or

Re: Root Store Policy 2.5: Call For Review and Phase-In Periods

On 21/06/17 16:58, Doug Beattie wrote: >> It's worth noting that if we had discovered this situation for SSL - that an >> unconstrained intermediate or uncontrolled power of issuance had been >> given to a company with no audit - we would be requiring the intermediate >> be revoked today, and

Re: Root Store Policy 2.5: Call For Review and Phase-In Periods

On 21/06/17 13:13, Doug Beattie wrote: >> Do they have audits of any sort? > > There had not been any audit requirements for EKU technically > constrained CAs, so no, there are no audits. In your view, having an EKU limiting the intermediate to just SSL or to just email makes it a technically

Re: Root Store Policy 2.5: Call For Review and Phase-In Periods

Hi Doug, On 20/06/17 16:31, Doug Beattie wrote: > I'd like to recommend a phase in of the requirement for technically > constrained CAs that issue Secure email certificates. For those following along at home, that is this change: https://github.com/mozilla/pkipolicy/issues/69

Re: Symantec response to Google proposal

On 20/06/17 01:21, Jakob Bohm wrote: > 2. For any certificate bundle that needs to be incorporated into the > Mozilla root stores, a significant period (3 to 6 months at least) > will be needed between acceptance by Mozilla and actual trust by > Mozilla users. Not if the roots were

Principles and Goals

I think it might be useful to take a step back and remind ourselves of Mozilla's mission, principles and goals with regard to resolving the situation with Symantec. These will be useful as we flesh out the details of the consensus proposal, particularly concerning dates. First, a quick reminder

Re: New undisclosed intermediates

On 09/06/17 16:37, Jakob Bohm wrote: > This seems to directly violate the often proposed (but apparently not > yet enacted) rule that different root certs must have different keys > (if that rule has been incorporated into a current policy). This has come up enough times now that I've filed an

Re: New undisclosed intermediates

On 09/06/17 11:29, Rob Stradling wrote: > These two certs share the same Name and Key. Therefore, the signature > on the first can be verified by the public key in the second; and vice > versa. And clearly the Subject Name in each one matches the Issuer Name > in the other. This means that the

Re: New undisclosed intermediates

On 08/06/17 15:37, Jeremy Rowley wrote: > If you added them automatically to OneCRL, how would you create new > intermediates? Would it be anything over X days old and undisclosed is > automatically added? Yes, that :-) Sorry if that wasn't clear. The deadline, as of policy 2.5, is a week

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

On 08/06/17 19:46, Jakob Bohm wrote: > How about the following, which seems more correct Yes; I'm not sure why David thought the original version's two sentences were contradicting rach other. > Insofar as the Baseline Requirements attempt to define their own scope, > the scope of this policy

Root Store Policy 2.5: Call For Review and Phase-In Periods

Hi everyone, I've made the last change I currently intend to make for version 2.5 of Mozilla's Root Store Policy. The last task before shipping it is to assess whether any of the changes require a phase-in period, i.e. for some reason, they can't be applicable immediately. CAs and others are

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

On 02/06/17 11:28, Gervase Markham wrote: > Proposal: add a bullet to section 2.3, where we define BR exceptions: > > "Insofar as the Baseline Requirements attempt to define their own scope, > the scope of this policy (section 1.1) overrides that. Mozilla expects > CA operations relating to

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On 04/06/17 03:03, Matt Palmer wrote: > For whatever it is worth, I am a fan of this way of defining "misissuance". This is an "enumerating badness" vs. "enumerating goodness" question. My original draft attempted to (without limitation) enumerate some badness, and you and Ryan are suggesting

Re: New undisclosed intermediates

On 08/06/17 10:17, Gervase Markham wrote: > What downsides would there be, other than the obvious "some sites might > break", to us just adding any such intermediate certs directly to OneCRL? We provide reports which allow CAs to download the stored intermediate cert data:

Re: New undisclosed intermediates

On 08/06/17 00:42, Jonathan Rudenberg wrote: > Yet another batch of undisclosed intermediates has shown up in CT: Like, seriously? Every CA in our program indicated that they would disclose all their intermediates by June 30th, 2016:

Re: Mozilla requirements of Symantec

On 07/06/17 22:30, Jakob Bohm wrote: > Potential clarification: By "New PKI", Mozilla apparently refers to the > "Managed CAs", "Transition to a New Symantec PKI" and related parts of > the plan, not to the "new roots" for the "modernized platform" / "new > infrastructure". I expect those things

Re: An alternate perspective on Symantec

On 07/06/17 06:14, userwithuid wrote: > 2. Having Symantec inform their subscribers, as David mentions, is a great > idea. I believe Ryan has pointed out, here or elsewhere, why "must notify customers" requirements are problematic. Gerv ___

Re: Symantec response to Google proposal

On 06/06/17 19:59, Jakob Bohm wrote: > I don't see a problem in access to this being subject to a reasonable > NDA that allows Mozilla to show it to their choice of up to 50 external > experts (I don't expect to be one of those 50). The problem with an NDA is that if the audit reports significant

Mozilla requirements of Symantec

Hi Steve, I'm writing to you in your role as the Primary Point of Contact for Symantec with regard to the Mozilla Root Program. I am writing with a list of Mozilla-specific additions to the consensus remediation proposal for Symantec, as documented by Google. We note that you have raised a

Re: Symantec response to Google proposal

Here are some thoughts from me: On 06/06/17 15:02, Gervase Markham wrote: > 1) Scope of Distrust I have sought more information from Google on this. > 2) Timeline I think the question here is, what is our position, and on what basis do we decide it? If we want to impose an aggressive but

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On 04/06/17 03:03, Matt Palmer wrote: > For whatever it is worth, I am a fan of this way of defining "misissuance". So you think we should use the word "misissuance" for all forms of imperfect issuance, and then have a gradated reaction depending on the type and circumstances, rather than use the

Re: New undisclosed intermediates

On 05/06/17 14:29, Alex Gaynor wrote: > As I've expressed before, I find it baffling that this still happens. I am also disappointed. I have half a mind to keep track of how often this happens per CA, and impose a mandatory delay of 1 month per incident to that CA's next attempt to include a new

Re: On remedies for CAs behaving badly

On 05/06/17 16:52, Matthew Hardeman wrote: > Has there ever been an effort by the root programs to directly assess > monetary penalties to the CAs -- never for inclusion -- but rather as > part of a remediation program? Another fact to bear in mind when discussing this is that, for a number of

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

On 02/06/17 17:07, Peter Bowen wrote: > Should Mozilla include a clear definition of "SSL certificates" in the > policy? And should it be based on technical attributes rather than > intent of the issuer? Absolutely Yes to your second sentence :-). We do have a clear definition of what's in

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

On 02/06/17 17:24, Kurt Roeckx wrote: > On Fri, Jun 02, 2017 at 04:50:44PM +0100, Gervase Markham wrote: >> On 02/06/17 12:24, Kurt Roeckx wrote: >>> Should that be "all certificates" instead of "all SSL certificates"? >> >> No; the Baseline Requirements apply only to SSL certificates. > > Then I

Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

On 02/06/17 12:29, Ryan Sleevi wrote: > 2) "performing RA or DTP functions" I'll go with that :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

On 02/06/17 12:24, Kurt Roeckx wrote: > Should that be "all certificates" instead of "all SSL certificates"? No; the Baseline Requirements apply only to SSL certificates. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

The scope of the BRs is ambiguous, and almost certainly smaller than the scope of the Mozilla policy. It might be useful to explicitly draw attention to that fact, for the avoidance of doubt. Proposal: add a bullet to section 2.3, where we define BR exceptions: "Insofar as the Baseline

Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

On 01/06/17 13:59, Gervase Markham wrote: > Perhaps this leads to the solution? We say: > > "enforce multi-factor authentication for all accounts capable of causing > certificate issuance or performing RA or DTP functions as defined by the > Baseline Requirements" or "enforce multi-factor

Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

On 01/06/17 14:22, Doug Beattie wrote: > If this is the case, then in what cases do you see 2-factor auth being a > requirement where it was not before? Well, Mozilla policy didn't require that all RA accounts had multi-factor, only those directly capable of causing certificate issuance. Maybe

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On 01/06/17 13:49, Ryan Sleevi wrote: > I would encourage you to reconsider this, or perhaps I've misunderstood > your position. To the extent that Mozilla's mission includes "The > effectiveness of the Internet as a public resource depends upon > interoperability (protocols, data formats,

Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

On 01/06/17 13:45, Ryan Sleevi wrote: > The reason why I don't think it's a valid reasoning is that if we accept > that this provision in the policy could be read to cover such emails, then > we're implicitly agreeing that the act of clicking that email is performing > a validation function

<    1   2   3   4   5   >