RE: Clarification request: ECC subCAs under RSA Root

I know where this kind of requirement is coming from ... it's a common requirement in key management systems, but they generally operate in worlds that are completely different from the Web PKI. Even there, it often causes more problems than it solves. I've spent more of my life dealing with the

RE: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

In the definition of EV TLS Capable, I'd move the last bullet up to the top. This is because the definition is inherently recursive, and it's easy to miss that if the recursion rule isn't first. For example, I had a question about whether "revoked" meant just the certificate itself, or whether

RE: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

Ben, We're concerned that these changes could unintentionally prevent many new auditors from being able to conduct audits, despite being Qualified Auditors. The problem is that CAs will understandably be very hesitant to use a new auditor, as they cannot risk having an audit conducted, and

RE: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

So, I'd like to drill down a bit more into one of the cases you discussed. Let's assume the following: 1. The CAO [*] may or may not have requested removal of the CAC, but removal has not been completed. The CAC is still trusted by at least one public root program. 2. The CAO has destroyed the

RE: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

So, from our perspective, the security implications are the most important here. We understand them, and even in the absence of any compliance obligations they would constitute an unacceptable risk to trustworthiness of our OCSP responses, so we have already begun the process of replacing the ICAs

RE: Terms and Conditions that use technical measures to make it difficult to change CAs

Generally, I'm in favor of transparency requirements, and many of Ryan's ideas would be useful or interesting to pursue. Transparency is often the first and best step towards improving business practices. And the entire purpose of a CPS is to disclose the business practices that implement a

RE: About upcoming limits on trusted certificates

> On 3/11/20 3:51 PM, Paul Walsh wrote: > > Can you provide some insight to why you think a shorter frequency in > domain validation would be beneficial? > > To start with, it is common for a domain name to be purchased for one year. > A certificate owner that was able to prove ownership/control

RE: Acceptable forms of evidence for key compromise

I agree with Corey on this. I was disappointed that the LAMPS discussion two years ago was not as helpful as it could have been. For what it's worth, while we generally try to accept any reasonable proof of key compromise, we have seen quite a large variety of things sent to us. This includes

Terms and Conditions that use technical measures to make it difficult to change CAs

Hello, I'd like to start a discussion about some practices among other commercial CAs that have recently come to my attention, which I personally find disturbing. While it's perfectly appropriate to have Terms and Conditions associated with digital certificates, in some circumstances,

RE: [FORGED] Re: How Certificates are Verified by Firefox

Someone really should write up "AIA chasing considered harmful". It was disputed at the TLS session at IETF 105, which shows that the reasoning behind it is not as widely understood as it needs to be, even among TLS experts. I'm very appreciative of Firefox's efforts in this area. Leveraging

RE: DigiCert OCSP services returns 1 byte

Subject: Re: DigiCert OCSP services returns 1 byte On Thu, Sep 19, 2019 at 1:52 PM Tim Hollebeek via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: I think that's fine as Mozilla and/or the CABF can and should override RFCs when it makes sense to

RE: DigiCert OCSP services returns 1 byte

> Thanks Wayne. You're right. > > (I read the "SHOULD NOT" requirement, forgot it had been superseded, and > didn't read further. I wonder if it would be reasonable to remove the > superseded requirement from the BRs now, given that it was superseded over > 6 years ago?) Removing out of date

RE: DigiCert OCSP services returns 1 byte

t; >> Sent: Friday, September 13, 2019 4:22 AM > >> To: Tim Hollebeek ; Jeremy Rowley > >> ; Alex Cohn > >> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer > >> > >> Subject: Re: DigiCert OCSP services returns 1 byte > >>

RE: DigiCert OCSP services returns 1 byte

r > > Subject: Re: DigiCert OCSP services returns 1 byte > > On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote: > > So, this is something that would be helpfully clarified via either an > > IETF draft, > > There's already a 6962-bis draft [1] in I

RE: DigiCert OCSP services returns 1 byte

On Thu, Sep 12, 2019 at 3:49 PM Tim Hollebeek via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: So, this is something that would be helpfully clarified via either an IETF draft, or clarifications in the BRs. There are various things in the OCSP RFCs

RE: DigiCert OCSP services returns 1 byte

So, this is something that would be helpfully clarified via either an IETF draft, or clarifications in the BRs. There are various things in the OCSP RFCs and even the BRs that can be read as precluding good OCSP responses for pre-certificates, although the situation is unclear since the

RE: CA handling of contact information when reporting problems

DigiCert currently has a policy of not publishing the names of those who report things to us without their permission. It just seems like the right thing to do. If we do find that people are abusing that protection to selectively harass people that they personally have issues with, we may need

RE: Use of Certificate/Public Key Pinning

So, pinning is an extremely complicated topic that I've always wanted to write a blog post about, but have never had the time to do it. It happens fairly regularly that we have to assist a company that has painted themselves into a corner with a poorly thought out pinning scheme. In my

RE: Incident Report - Entrust Datacard issued certificates with the incorrect Organization Name

What is the rationale for waiting until March 20th for revocation given that the issue was noticed on March 7th? -Tim > -Original Message- > From: dev-security-policy On > Behalf Of Bruce via dev-security-policy > Sent: Friday, March 15, 2019 4:59 PM > To:

RE: Possible DigiCert in-addr.arpa Mis-issuance

> On 27/02/2019 00:10, Matthew Hardeman wrote: > > Is it even proper to have a SAN dnsName in in-addr.arpa ever? > > > > While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it > > rarely has anything other than PTR and NS records defined. > > > > While there is no current use, and the

RE: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

> On 2019-01-24 20:19, Tim Hollebeek wrote: > > I think the assertion that the commonName has anything to do with what > > the user would type and expect to see is unsupported by any of the > > relevant standards, and as Rob noted, having it be different from the > > SAN strings is not in

RE: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

I think the assertion that the commonName has anything to do with what the user would type and expect to see is unsupported by any of the relevant standards, and as Rob noted, having it be different from the SAN strings is not in compliance with the Baseline Requirements. It's also deprecated.

RE: AlwaysOnSSL web security issues

Here's the article we published on this subject a while ago: https://www.digicert.com/blog/keeping-subscribers-safe-partner-best-practices/ -Tim > -Original Message- > From: dev-security-policy > On Behalf Of Jeremy Rowley via dev-security-policy > Sent: Thursday, January 10, 2019 4:47

RE: DNS fragmentation attack subverts DV, 5 public CAs vulnerable

The problem is that the attackers get to choose the CA they use, so multi-perspective validation doesn't provide any benefits unless everyone has to do it. I brought it up several times at the validation working group and as a discussion topic at the Shanghai face to face, but unfortunately there

RE: Violation report - Comodo CA certificates revocation delays

I don't think we've commented on this before, but I'll note that sending an e-mail from the e-mail address listed as the contact address on a website is not one of the approved methods of showing ownership or control of a website as specified in section 3.2.2.4. The approved methods of validating

RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

That may be true, but I don't see any upside for using that date. If you need to make a minor CPS update in early January for any reason, you now have additional work. I think late December policy changes should be avoided as a general rule. -Tim > -Original Message- > From:

RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

I agree with you, but December 31 is a particularly horrible compliance deadline. Perhaps January 31? -Tim > -Original Message- > From: dev-security-policy On > Behalf Of Wayne Thayer via dev-security-policy > Sent: Monday, October 22, 2018 6:00 PM > To: Kathleen Wilson > Cc:

RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

I think blank sections should be disallowed. The entire purpose of "No stipulation" is to make it clear that the omission of content was intentional. With regards to some of these sections being useful, I agree that a good CPS contains more than the minimum content required from the BRs. I

RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS

I think "Not applicable" would be superior to "No stipulation", when appropriate. "3.2.2.5. No IP address certificates are issued under this CPS." is even clearer. I haven't looked into the implications of this, but perhaps it would be worth considering not allowing "No stipulation" in CPSs

RE: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

RFC 3647 disagrees: "Rather, a particular CP or CPS may state "no stipulation" for a component, subcomponent, or element on which the particular CP or CPS imposes no requirements or makes no disclosure." " It is recommended that each and every component and subcomponent be included in a CP

RE: Concerns with Dun & Bradstreet as a QIIS

Getting the whitelist figured out and workable will take a while. Disclosure could happen much faster. And I’m curious why you think it would be unauditable. It seems pretty straightforward to verify such disclosures. It think both ideas are worth considering. There’s no reason we

RE: Concerns with Dun & Bradstreet as a QIIS

Perhaps a simple first step is to mandate disclosure of which information source was used for validation. Then if someone uses Google Maps or similar, People Who Pay Attention To Such Things can start a public discussion about whether the source is a QIIS, and whether the certificate is

RE: Concerns with Dun & Bradstreet as a QIIS

I'm glad you added the smiley, because in my experience CAs have rarely, if ever, have had any discretion in such matters. Nor do we (DigiCert) particularly want to, to be honest. I prefer clear, open, and transparent validation rules that other CAs can't play games with. Whitelisting and

RE: SHA-1 exception history

> On Thu, 27 Sep 2018 14:52:27 + > Tim Hollebeek via dev-security-policy > wrote: > > > My personal impression is that by the time they are brought up here, > > far too many issues have easily predicted and pre-determined outcomes. > > It is probably true tha

RE: Concerns with Dun & Bradstreet as a QIIS

> The question and concern about QIIS is extremely reasonable. As discussed in > past CA/Browser Forum activities, some CAs have extended the definition to > treat Google Maps as a QIIS (it is not), as well as third-party WHOIS services > (they’re not; that’s using a DTP). It's worth noting that

Re: SHA-1 exception history

Speaking for myself ... My personal impression is that by the time they are brought up here, far too many issues have easily predicted and pre-determined outcomes. I know most of the security and key management people for the payment industry very well [1], and they're good people. The

RE: Concerns with Dun & Bradstreet as a QIIS

There have been previous discussions about this very issue at CA/Browser Forum Validation Working Group meetings (see also draft Ballot 225). I think it is widely recognized that the rules around QIISs are far too weak and in need of improvement. I actually recently asked Kirk to add an item on

RE: Telia CA - problem in E validation

There are lots of useful ways to publish unverified and potentially inaccurate information. Putting that information into a certificate signed by a public Certificate Authority is not one of them. By the way, OUs need to be accurate as well, not just "partially verified", so you might want to

RE: Telia CA - problem in E validation

Yeah, but unvalidated "information" is not "informative" in any useful way. -Tim > -Original Message- > From: dev-security-policy On > Behalf Of pekka.lahtiharju--- via dev-security-policy > Sent: Tuesday, August 21, 2018 9:59 AM > To: mozilla-dev-security-pol...@lists.mozilla.org >

RE: Telia CA - problem in E validation

Previous discussions on this list, which all CAs are required to follow, have made it clear that either challenge-response or domain validation is sufficient to meet Mozilla's policy for e-mail addresses. Yes, the context was SMIME validation, but I am very troubled to hear that instead of using

RE: Telia CA - problem in E validation

The BRs indeed do not have many requirements about the validation of email addresses, but Mozilla policy is much more proscriptive here. See, for example, the first two items of section 2.2. These make it pretty clear that unverified addresses are prohibited by Mozilla policy, and validation of

RE: A vision of an entirely different WebPKI of the future...

The only thing I'm going to say in this thread is that ICANN, registrars, and registries had two years to figure out how to handle GDPR and email addresses in WHOIS, and we all know how that turned out. Maybe we should let them figure out how to handle their existing responsibilities before we

RE: localhost.megasyncloopback.mega.nz private key in client

Also, I'd like to encourage other CAs to comply with Issue 98 pro-actively, even if it is not required. We're already in compliance. -Tim > -Original Message- > From: dev-security-policy On > Behalf Of Tim Hollebeek via dev-security-policy > Sent: Thursday, August 9, 2

RE: localhost.megasyncloopback.mega.nz private key in client

in Issue 98, this did not result in a normative change to the CP/CPS. On Wed, Aug 8, 2018 at 10:22 PM, Tim Hollebeek via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: IIRC we recently passed a CABF ballot that the CPS must contain instructions for subm

RE: localhost.megasyncloopback.mega.nz private key in client

IIRC we recently passed a CABF ballot that the CPS must contain instructions for submitting problem reports in a specific section of its CPS, in an attempt to solve problems like this. This winter or early spring, if my memory is correct. -Tim > -Original Message- > From:

RE: Possible violation of CAA by nazwa.pl

I agree. I've actually thought about adding definitions of categories of misissuance to the BRs before. Some of the requirements like revocation are really hard to write and understand if you don't first categorize all the misissuance use cases, many of which are very, very different. And just

RE: Do We Now Require Separate Cross-certificates for SSL and S/MIME?

Yeah, I agree I don’t think it was intended. But now that I am aware of the issue, I think the crossing workaround per EKU is actually a good thing for people to be doing. Unless someone can point out why it's bad ... Might want to give people a little more time to plan and adapt to that

RE: Do We Now Require Separate Cross-certificates for SSL and S/MIME?

Doesn't the "created after January 1, 2019" mean that there is no problem with old crosses? It would just be a new policy for new crosses as of next year? -Tim > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- >

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

/juHBkWV4CwAJ [5] https://groups.google.com/d/msg/mozilla.dev.security.policy/7AcHi_MgKWE/O5rwCV96CwAJ [6] https://groups.google.com/d/msg/mozilla.dev.security.policy/7AcHi_MgKWE/lpU2dpl8CwAJ On Wed, May 23, 2018 at 11:29 AM, Tim Hollebeek via dev-security-policy <dev-security-pol

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

You’re free to misattribute whatever motives you want to me. They’re not true. In fact, I would like to call on you yet again to cease speculating and imputing malicious motives onto well-intentioned posts. The CAA logging requirements failed in this instance. How do we make them better?

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

What that wall of text completely misses is the point I and others have been trying to make. The logs have to have enough information so you don’t end up in the situation Let’s Encrypt is currently, and unfortunately, in. Yes, what they did is compliant, and that’s exactly what most

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

What precisely was the antecedent of “this” in your message? Re-reading it, I’m not clear which sentence you were referring to. The only reasons I can think of for not keeping DNSSEC signed RRs are storage and/or performance, and we think those concerns should not be the driving force in

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

> Given the TTLs and the key sizes in use on DNSSEC records, why do you believe > this? DigiCert is not sympathetic to disk space as a reason to not keep sufficient information in order to detect misissuance due to CAA failures. In fact, inspired by this issue, we are taking a look internally

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

Ok. My biggest concern is not you guys, who are pretty security conscious, but whether we need to improve the language to make it more clear that the logging has to be sufficient so that in the event of a bug in the CAA logic, it is possible to determine which issued certificates are affected and

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

> Our logging of the CAA records processed does not provide the case > information we need to determine whether other issuances were affected by > this bug. We put a requirement in the BRs specifically so this problem could not occur: "The CA SHALL log all actions taken, if any, consistent with

RE: question about DNS CAA and S/MIME certificates

> On Wednesday, May 16, 2018 at 2:16:14 AM UTC-4, Tim Hollebeek wrote: > > This is the point I most strongly agree with. > > > > I do not think it's at odds with the LAMPS charter for 6844-bis, > > because I do not think it's at odds with 6844. > > Updating 6844 is easy. Just define the tag and

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

When we debated it last, my predictions were hypothetical. I wish they had remained hypothetical. -Tim From: Wayne Thayer [mailto:wtha...@mozilla.com] Sent: Wednesday, May 16, 2018 12:33 AM To: Tim Hollebeek ; mozilla-dev-security-policy

RE: question about DNS CAA and S/MIME certificates

This is the point I most strongly agree with. -Tim I do not think it's at odds with the LAMPS charter for 6844-bis, because I do not think it's at odds with 6844. smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

> This going to require 19 randomly generated Base64 characters and that does > not include removing common confused characters which will drive up the > length a bit more, but if this is what the Mozilla risk assessment came up > with, > then we’ll all have to comply. I hope there is a

RE: question about DNS CAA and S/MIME certificates

I agree with Phillip; if we want email CAA to be a thing, we need to define and specify that thing. And I think it should be a thing. New RFCs are not that hard and need not even be that long. -Tim > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- >

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

My only objection is that this will cause key generation to shift to partners and affiliates, who will almost certainly do an even worse job. If you want to ban key generation by anyone but the end entity, ban key generation by anyone but the end entity. -Tim > -Original Message- >

RE: question about DNS CAA and S/MIME certificates

I think CAA is and should be HTTPS only until there are clear rules for how it should work for email, and how to keep web CAA from interfering with email CAA. E-mail is currently the wild west and that needs to be fixed. I’m strongly in favor of email CAA, once we get it ‘right’. But

RE: question about DNS CAA and S/MIME certificates

ax. The CA/Browser Forum currently has no jurisdiction over email, so at best could define syntax to limit CAA scope to server certificates. The scope of the LAMPS recharter for 6844bis appears too narrow to include this. What is the best path forward? - Wayne On Tue, May 15, 2018 at 9:29

RE: question about DNS CAA and S/MIME certificates

Blatantly false. I actually suspect DigiCert might already support CAA for email. I haven’t double-checked. -Tim The only reason that "CAA is HTTPS-only" today is because CAs are not interested in doing the 'right' thing. smime.p7s Description: S/MIME cryptographic signature

RE: question about DNS CAA and S/MIME certificates

security-policy <mozilla-dev-security-pol...@lists.mozilla.org <mailto:mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Re: question about DNS CAA and S/MIME certificates I don't actually think there is any IETF component to this. There can be, but it's not required to be. On

RE: question about DNS CAA and S/MIME certificates

<mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: question about DNS CAA and S/MIME certificates I don't actually think there is any IETF component to this. There can be, but it's not required to be. On Mon, May 14, 2018 at 6:20 PM, Tim Hollebeek via dev-security-policy &l

RE: question about DNS CAA and S/MIME certificates

There’s an IETF component, but minimum necessary standards for email certificate issuance is a policy issue, not a technical one. Somewhere, it needs to say “CAs issuing e-mail certificates MUST check CAA in accordance with CAA-bis.” -Tim With CABF governance reform coming into

RE: question about DNS CAA and S/MIME certificates

> Today this is a "non-issue" because nothing is obligating CAs to respect > CAA, > and thus they can (and are) doing the thing that helps them issue more > certificates (and, presumably, make more money) - but that doesn't > necessarily > mean its the right thing. I can think of at least one

RE: question about DNS CAA and S/MIME certificates

Yes, but as you correctly point out, this should be taken care of as part of the CAA-bis effort. The original RFC had enough errors with respect to web certificates; I think it would be irresponsible to apply it to e-mail certificates right now without carefully considering the consequences.

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

For the record, I posted someone else's strength testing algorithm, and pointed out that it was bad  I personally don't think building strength testing algorithms is hopeless, and I think good ones are very useful. I tend to agree with the current NIST recommendation, which is to primarily

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

> Maybe you want n = 112 / 8 = 14 bytes. Doh! Yes. -Tim 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: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

It has generally been understood that a string still "contains at least 112 bits of output from a CSPRNG" if that string has been fed through an encoding mechanism like Base64 or Base32. Furthermore, explicit requirements about including mixed case or special characters leads to some very, very

RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

> I'd recommend making a requirement that it be "protected" by at least as many > bits of strength as the key it protects. Not doing so could cause compliance > issues: things like PCI [1] and the NIST [2] recommendations require this type of > protection. You don't have compliance problems

RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

I get that, but any CA that can securely erase and forget the user’s contribution to the password and certainly do the same thing to the entire password, so I’m not seeing the value of the extra complexity and interaction. -Tim From: Ryan Hurst [mailto:ryan.hu...@gmail.com] Sent:

RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

OOB passwords are generally tough to integrate into automation, and if the channel really is “secure” then they might not be buying you anything, depending where the “secure” channel starts and ends and how it is authenticated. That might not be a GOOD reason to allow it, but it is the one

RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

Once again, CSPRNGs are not overkill. They are widely available in virtually every programming language in existence these days. I have never understood why there is so much pushback against something that often appears near the top of many top ten lists about basic principles for secure

RE: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

leb...@digicert.com> > Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> > Subject: RE: "multiple perspective validations" - AW: Regional BGP hijack of > Amazon DNS infrastructure > > On Mon, 30 Apr 2018, Tim Hollebeek via de

RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

32 bits is rather ... low. > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Buschart, > Rufus via dev-security-policy > Sent: Monday, April 30, 2018 2:25 AM > To: mozilla-dev-security-policy

RE: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

> I don't think this opinion is in conflict with the suggestion that we > required > DNSSEC validation on CAA records when (however rarely) it is deployed. I > added this as https://github.com/mozilla/pkipolicy/issues/133 One of the things that could help quite a bit is to only require DNSSEC

RE: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

> > which is why in the near future we can hopefully use RDAP over TLS > > (RFC > > 7481) instead of WHOIS, and of course since the near past, DNSSEC :) > > I agree moving away from WHOIS to RDAP over TLS is a good low hanging fruit > mitigator once it is viable. My opinion is it is viable now,

RE: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

> Independent of EV, the BRs require that a CA maintain a High Risk Certificate > Request policy such that certificate requests are scrubbed against an internal > database or other resources of the CAs discretion. Unless you're Let's Encrypt, in which case you can opt out of this requirement via

RE: Policy 2.6 Proposal: Require English Language Audit Reports

Call me crazy, but for this particular requirement, I think simple sentences might be better. "The audit information MUST be publicly available. An English version MUST be provided. The English version MUST be authoritative." -Tim > -Original Message- > From: dev-security-policy

RE: 825 days success and future progress!

gt; Cc: Alex Gaynor <agay...@mozilla.com>; MozPol <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: 825 days success and future progress! On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek via dev-security-policy <dev-security-policy@lists.mozilla.org <ma

RE: 825 days success and future progress!

Yes, if we wanted to go to 13 months quickly, we would have gone directly there. Getting to 13 months quickly is not a goal. That’s not having it both ways, that having an understanding of how the ecosystem actually works. The majority of the CAB forum, and not just CAs, but also many

RE: 825 days success and future progress!

18 months is not significantly different from 825 days. So there's really no benefit. People have to stop wanting to constantly change the max validity period. It's difficult enough to communicate these changes to consumers and customers, and it really drives them nuts. I can only imagine what

RE: Policy 2.6 Proposal: Require disclosure of S/MIME validation practices

I like this one. It will be very useful as a starting point if we finally get a CABF S/MIME working group, which is likely to happen. -Tim > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of

RE: Policy 2.6 Proposal: Update domain validation requirements

The language you quoted from me is a bit imprecise, my apologies. I was trying to get CAs to disclose previously undisclosed uses of (4). There are disclosed uses of (4), including from DigiCert, that haven’t made it into the BR methods yet, because in the past year, we have failed to pass

RE: TunRootCA2 root inclusion request

My reaction was primarily based on the following suggestion: "Generally speaking I would insist on the fact that for country CAs, some kind of fast tracks should be established because the impact of time losing at country level is highly expensive." The answer is, and must be, no. -Tim >

RE: TunRootCA2 root inclusion request

Nobody is blocking any country from advancing. There are no Mozilla rules that prevent any country from having the best CA on the planet. If a bunch of penguins at McMurdo station run an awesome CA, I'll ask some hard questions about how they meet the OCSP requirements with their limited

RE: Allowing WebExtensions to Override Certificate Trust Decisions

Wow, this is a tough one. I've wanted to write such an extension myself for quite some time. In fact, I probably would write one or more extensions, if Mozilla were to allow this, for a variety of use cases. That said, such extensions are extremely dangerous, and users are just going to

RE: Google OCSP service down

Ryan, Wayne and I have been discussing making various improvements to 1.5.2 mandatory for all CAs. I've made a few improvements to DigiCert's CPSs in this area, but things probably still could be better. There will probably be a CA/B ballot in this area soon. DigiCert's 1.5.2 has our support

RE: Mozilla’s Plan for Symantec Roots

> OK. I'm researching what approach should be used for the Fedora Linux > distribution, where a single CA trust list (based on Mozilla's CA trust > list) is used for the whole system, including Firefox, and other > applications that > use other certificate validation logic, like the ones built

RE: Misissuance/non-compliance remediation timelines

, 2018 at 8:30 PM, Tim Hollebeek via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: Paul, I understand your frustration. I've read some of the recent threads about "how long does it take to update a CPS?"

RE: Misissuance/non-compliance remediation timelines

s of coming up with their own schemes, while “least bad” is more actionable - as “most bad” is more likely to receive sanctions. On Tue, Feb 6, 2018 at 10:03 PM Tim Hollebeek via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org>

RE: Misissuance/non-compliance remediation timelines

Absolutely not. I view the competition as being based as the “most best”. You cannot get an “A” (or even A- or B+) without significantly exceeding the minimum requirements, or demonstrating behaviors and practices that, while not required, are behaviors Mozilla wants to encourage.

RE: IP Validation using method 3.2.2.5 (4) "any other method"

-security-pol...@lists.mozilla.org> Subject: Re: IP Validation using method 3.2.2.5 (4) "any other method" On Tue, Jan 30, 2018 at 10:37 AM, Tim Hollebeek via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.

IP Validation using method 3.2.2.5 (4) "any other method"

I'm sending this to this list because CAs are required to monitor this list, and I need to get feedback from smaller and more obscure CAs. The validation working group is thinking about proposing removal of 3.2.2.5 (4) in the near future. If you are currently using that method to validate

RE: DRAFT January 2018 CA Communication

Wayne, You might want to highlight that method 1 sub-method 3 would survive even if ballot 218 passes, as a new method 12 with some changes and improvements that CAs who use sub-method 3 should pay close attention to. With regards to TLS-SNI-01, I believe TLS-SNI-02 is also affected by the same

RE: GlobalSign certificate with far-future notBefore

>> propose > > a > >> ballot that addresses pre and postdating certificates? > >> > >> Doug > >> > >>> -Original Message- > >>> From: dev-security-policy [mailto:dev-security-policy- > >>> bounces+doug.beattie=glo

RE: GlobalSign certificate with far-future notBefore

ose a > ballot that addresses pre and postdating certificates? > > Doug > > > -Original Message- > > From: dev-security-policy [mailto:dev-security-policy- > > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of > > bounces+Tim > > Ho

  1   2   >