RE: CA Problem Reporting Mechanisms

See BR 1.5.2. CAs are already required to have contact information in their CPS. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+thollebeek=trustwave@lists.mozilla.org] On Behalf Of David E. Ross via dev-security-policy Sent: Tuesday, August 8,

RE: Efficient test for weak RSA keys generated in Infineon TPMs / smartcards

I think this is right. ROCA-detect appears to just be an implementation of the fingerprinting algorithm described in the 2016 paper (https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_svenda.pdf). There are already plenty of clues in the 2016 paper that something

RE: Anomalous Certificate Issuances based on historic CAA records

So it turns out DNSSEC solves CAA problems for almost nobody, because almost nobody uses DNSSEC. And given the serious flaws both in DNSSEC itself and exiting DNSSEC implementations, it is unlikely to be part of any solution to the current problems CAA is facing. The presence of DNSSEC in the BR

RE: Anomalous Certificate Issuances based on historic CAA records

ys of achieving this one such as requiring CAs to "gossip" CAA records, or requiring CAA checks be performed from multiple network locations. Wayne On Thu, Nov 30, 2017 at 2:00 PM, Tim Hollebeek via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-pol

RE: Anomalous Certificate Issuances based on historic CAA records

Paul, Improving CAA by moving it to a protocol other than DNS is certainly worth considering, going forward. With respect to people using proper DNS libraries and not inventing their own CNAME / DNAME handling, the problem was that RFC 6844 accidentally specified semantics for CNAME / DNAME

RE: CA generated keys

> A policy allowing CAs to generate key pairs should also include provisions > for: > - The CA must generate the key in accordance with technical best practices > - While in possession of the private key, the CA must store it securely Don't forget appropriate protection for the key while it is

RE: CA generated keys

erated keys On Wed, Dec 13, 2017 at 4:06 PM, Tim Hollebeek via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: Wayne, For TLS/SSL certificates, I think PKCS #12 delivery of the key and certificate at the same time

RE: On the value of EV

; Gervase Markham > <g...@mozilla.org>; mozilla-dev-security-pol...@lists.mozilla.org; Tim > Shirley <tshir...@trustwave.com> > Subject: Re: On the value of EV > > On 14/12/17 00:25, Tim Hollebeek via dev-security-policy wrote: > > If you look at where the HTTPS phi

RE: CA generated keys

> On 15/12/17 16:02, Ryan Hurst wrote: > > So I have read this thread in its entirety now and I think it makes sense for it > to reset to first principles, specifically: > > > > What are the technological and business goals trying to be achieved, > > What are the requirements derived from those

RE: On the value of EV

If you look at the phishing data feeds and correlate them with EV certificates, you'll find out that Tim's "speculation" is right. In my experience, it's generally a bad idea to disagree with Tim Shirley. -Tim > -Original Message- > From: dev-security-policy [mailto:dev-security-policy-

RE: On the value of EV

If you look at where the HTTPS phishing certificates come from, they come almost entirely from Let's Encrypt and Comodo. This is perhaps the best argument in favor of distinguishing between CAs that care about phishing and those that don't. -Tim > -Original Message- > From:

RE: On the value of EV

I don't want to spend too much time digressing into a discussion of the same origin policy as a basis for a reasonable security model for the web, but I hope we could all agree on one thing that was abundantly obvious twenty years ago, and has only become more obvious: Anything originally

RE: CA generated keys

Wayne, For TLS/SSL certificates, I think PKCS #12 delivery of the key and certificate at the same time should be allowed, and I have no problem with a requirement to delete the key after delivery. I also think server side generation along the lines of RFC 7030 (EST) section 4.4 should be

RE: CA generated keys

Hollebeek <tim.holleb...@digicert.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: CA generated keys On Wed, Dec 13, 2017 at 11:06 AM, Tim Hollebeek via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> &

RE: CA generated keys

3, 2017 at 12:40 PM, Tim Hollebeek via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: As I’m sure you’re aware, RSA key generation is far, far more reliant on the quality of the random number generation and the prime s

RE: On the value of EV

There are also the really cool hash-based revocation ideas that actually do help even against active attackers on the same network. I really wish those ideas got more serious attention. -Tim > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- >

RE: CA generated keys

> The more I think about it, the more I see this is actually a interesting question :-) I had the same feeling. It seems like an easy question to answer until you start thinking about it. > I suspect the first thing Mozilla allowing this would do would be to make it much more common. (Let's

RE: On the value of EV

t; On Dec 11, 2017, at 14:14, Tim Hollebeek via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > > It turns out that the CA/Browser Validation working group is currently > looking into how to address these issues, in order to tighten up > validati

RE: On the value of EV

It turns out that the CA/Browser Validation working group is currently looking into how to address these issues, in order to tighten up validation in these cases. We discussed it a bit last Thursday, and will be continuing the discussion on the 21st. If anyone has any good ideas, we'd be more

RE: On the value of EV

ng emails that point to various other URLs, which show unrelated phishing contents. Alex On Mon, Dec 11, 2017 at 2:14 PM, Tim Hollebeek via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: It turns out

RE: On the value of EV

lt;mailto:tim.holleb...@digicert.com> > Cc: Ryan Sleevi <r...@sleevi.com <mailto:r...@sleevi.com> >; mozilla-dev-security-pol...@lists.mozilla.org <mailto:mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: On the value of EV > On Dec 11, 2017, at 14:14, T

RE: On the value of EV

On the contrary, everything needs to be improved with time. Just because it could be made better doesn’t make it useless or bad. -Tim From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Monday, December 11, 2017 1:09 PM To: Tim Hollebeek Cc: r...@sleevi.com;

CA generated keys

Apologies for the new thread. It's difficult for me to reply to messages that were sent before I joined Digicert. With respect to CA generated SSL keys, there are a few points that I feel should be considered. First, third parties who are *not* CAs can run key generation and escrow

RE: On the value of EV

This is useful feedback. Thanks. -Tim -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Jakob Bohm via dev-security-policy Sent: Tuesday, December 12, 2017 6:36 AM To:

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: 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: 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: 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

<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: 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)

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

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

> 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: 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

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

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: 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

> 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

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

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

> 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: 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 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)

> 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: 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: 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

> 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: "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: 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

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

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: 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: DRAFT November 2017 CA Communication

I don't like erratum 5097. It just deletes the mention of DNAME, which can easily be misinterpreted as not permitting DNAME following for CAA (or even worse, allows DNAME to be handled however you want). Erratum 5097 also has not been approved by IETF (and shouldn't be, for this reason). The

RE: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

> For comparison of "What could be worse", you could imagine a CA using the > .10 method to assert the Random Value (which, unlike .7, is not bounded in its > validity) is expressed via the serial number. In this case, a CA could validate a > request and issue a certificate. Then, every 3 years

Incident report: Failure to verify authenticity for some partner requests

Hi everyone, There was a bug in our OEM integration that led to a lapse in the verification of authenticity of some OV certificate requests coming in through the reseller/partner system. As you know, BR 3.2.5 requires CAs to verify the authenticity of a request for an OV certificate

RE: Updating Root Inclusion Criteria

Wayne, I support "encouraging" those who are currently using the public web PKI for internal uses to move to their own private PKIs. The current situation is an artifact of the old notion that there should be a global "One CA List to Rule Them All" owned by the operating system, and everyone

RE: Updating Root Inclusion Criteria

> I think this is a vote for the status quo, in which we have been accepting > CAs that don't meet the guidance provided under 'who may apply' Perhaps slightly less strong than that. I think Mozilla should be willing to consider accepting them if there is a compelling reason to do so. “Why

RE: TLS-SNI-01 and compliance with BRs

My recollection is that there were a number of CA/B forum participants (including me) who asked repeatedly if method #10 could be expanded beyond a single sentence. I don't remember anyone speaking up in opposition, just silence. I continue to support making sure that all of the validation

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: 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

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

RE: GlobalSign certificate with far-future notBefore

> > This incident makes me think that two changes should be made: > > > > 1) The Root Store Policy should explicitly ban forward and back-dating the > notBefore date. > > I think it would be reasonable and sensible to permit back-dating insofar as it is > deemed necessary to accommodate

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: 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

, 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

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: 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: Serial number length

> -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Paul > Kehrer via dev-security-policy > Sent: Friday, December 29, 2017 12:46 PM > To: mozilla-dev-security-pol...@lists.mozilla.org >

RE: On the value of EV

Wayne, Thanks for updating us on Mozilla's thinking on this issue. On behalf of the CA/Browser forum Validation Working Group, I would like to thank everyone for their time and contributions. We will be going over everyone's points and take them all into consideration as we look into what

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: 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: 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

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: 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: 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: 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: 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

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: 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: 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: 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: 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: 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: 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 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: 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: 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!

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: 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: 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: "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: 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

> 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

> 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: 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

  1   2   >