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

I don't think that is true. Remember for OV/IV/EV certificates, the Subscriber is the natural person or Legal Entity identified in the certificate Subject. If the Subscriber is using the certificate on a CDN, it is probably better to have the CDN generate the key rather than the Subscriber. The

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

On Tue, May 15, 2018 at 9:17 PM Tim Hollebeek wrote: > 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. > > > This is already a Mozilla requirement [1] - we're just moving

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

As you note, the focus on gmail.com is to entirely miss the point of paypal.com - and virtually every other organizational identity out there that wishes to sign their certificates. Further, even when using 'hosted' mail provisioning, it's possible to use S/MIME, possibly even with

Re: question about DNS CAA and S/MIME certificates

When I wrote CAA, my intention was for it to apply to SSL/TLS certs only. I did not consider S/MIME certs to be relevant precisely because of the al...@gmail.com problem. I now realize that was entirely wrong and that there is in fact great utility in allowing domain owners to control their

Re: question about DNS CAA and S/MIME certificates

There's a lot of contradictory statements here, so I'm not sure how best to unpack them. "I think CAA is and should be HTTPS only" is inconsistent, it seems, with https://groups.google.com/d/msg/mozilla.dev.security.policy/NIc2Nwa9Msg/PZgO5Qe0CQAJ "There isn't much value to CAA if only a few CAs

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

Reminder: there is one week left in the discussion period for this inclusion request. On Tue, May 1, 2018 at 12:02 PM Wayne Thayer wrote: > This request is for inclusion of the OISTE WISeKey Global Root GC CA as > documented in the following bug: >

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

I'm coming to the conclusion that this discussion is about "security theater"[1]. As long as we allow CAs to generate S/MIME key pairs, there are gaping holes in the PKCS#12 requirements, the most obvious being that a CA can just transfer the private key to the user in pem format! Are there any

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

The LAMPS re-charter is still open for discussion. I personally have no problem with CAA for email being in scope for 6844-bis. I’m actually in favor of that if it really is currently out of scope (I haven’t checked). Best to ask on the LAMPS charter thread. -Tim From: Wayne Thayer

Re: Audit Reminder Email Summary

Forwarded Message Subject: Summary of May 2018 Audit Reminder Emails Date: Tue, 15 May 2018 19:00:06 + (GMT) Mozilla: Audit Reminder Root Certificates: GDCA TrustAUTH R5 ROOT** ** Audit Case in the Common CA Database is under review for this root certificate.

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

On 15/5/2018 6:51 μμ, Wayne Thayer via dev-security-policy wrote: Did you consider any changes based on Jakob’s comments? If the PKCS#12 is distributed via secure channels, how strong does the password need to be? I think this depends on our threat model, which to be fair is not

Re: question about DNS CAA and S/MIME certificates

Tim, Could you clarify then. Are you disagreeing that CAA is HTTPS only? As these were your words only 3 hours ago - https://groups.google.com/d/msg/mozilla.dev.security.policy/NIc2Nwa9Msg/0quxT0CpCQAJ On Tue, May 15, 2018 at 12:28 PM, Tim Hollebeek wrote: >

Re: question about DNS CAA and S/MIME certificates

I concur with Wayne's position that the discussion up to this point isn't leading to a solution. I represent nothing further than that I'm a systems and DNS administrator and domain holder (and thus, I submit, an interested and not entirely uninformed ecosystem participant) who has had an

Re: question about DNS CAA and S/MIME certificates

On Tue, May 15, 2018 at 12:25 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Nobody bothered with deploying CAA records until the run-up to eventual > enforcement for issuance of server certificates. > This is also factually untrue. You can't just

Re: question about DNS CAA and S/MIME certificates

I don't see how this debate is leading us to a solution. Can we just acknowledge that, prior to this discussion, the implications of CAA for the issuance of email certificates was not well understood by CAs or domain name registrants? I share the desire to have a system that fails closed in the

Re: question about DNS CAA and S/MIME certificates

That's shifting the goalposts in order to argue against a strawman. The minimum necessary for CAA for email is to restrict the domain access. Might some people desire more feature-rich syntax? Perhaps. Is that a necessary requirement? No. On Tue, May 15, 2018 at 12:22 PM, Matthew Hardeman via

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

Nobody bothered with deploying CAA records until the run-up to eventual enforcement for issuance of server certificates. It was the incentive of having control over who would be permitted to issue server certificates that inspired those who have done so to deploy CAA records. It is, in practical

Re: question about DNS CAA and S/MIME certificates

They certainly do share a common namespace. The trouble is that the email address has more than just that common namespace. If CAA is proposed for email certificates, I should be able to define a CAA policy that prevents any CA from issuing for

Re: question about DNS CAA and S/MIME certificates

Both types share a common namespace. The domain name space. On Tue, May 15, 2018 at 12:10 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Agreed. My point was to query the position of the administration of a > large generic email service as to

Re: question about DNS CAA and S/MIME certificates

Disingenuous seems like an unreasonable stretch. By the logic expressed here, applying CAA enforcement to HTTPS was applying CAA "after the fact" - after all, until CAs were required to enforce CAA, how do we know that domains (... such as google.com or opera.com) meant to restrict server

Re: question about DNS CAA and S/MIME certificates

Agreed. My point was to query the position of the administration of a large generic email service as to their understanding of the implications of CAA on their domains. Certificates have different types of SANs for good cause: the nuances of the name space differ. For example, SAN rfc822Names

Re: question about DNS CAA and S/MIME certificates

It is disingenuous to apply CAA to S/MIME and other certificate purposes after the fact. As a domain holder myself, having implemented CAA in certain domains, I did intent to restrict issuance of server certificates. I have never intended this to be a restriction of S/MIME certificate issuance.

Re: question about DNS CAA and S/MIME certificates

> On 15 May 2018, at 07:59, Matthew Hardeman wrote: > > For that matter, can whoever is in charge of gmail.com > speak to their intent as to CAA for S/MIME? > > I've certainly held certificates which include my personal gmail address > before. At no

Re: question about DNS CAA and S/MIME certificates

On Tue, May 15, 2018 at 11:02 AM, Jürgen Brauckmann via dev-security-policy wrote: > > I don't see how this can be done on a CA level. > > How does example.org express "server certs from letsencrypt, S/MIME from > anybody" with current CAA syntax?

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

On Tue, May 15, 2018 at 7:51 AM Doug Beattie wrote: > Wayne, > > > > 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

Re: question about DNS CAA and S/MIME certificates

Am 15.05.2018 um 15:01 schrieb Ryan Sleevi: On Tue, May 15, 2018 at 3:53 AM Jürgen Brauckmann wrote: Today, site operators have taken steps to secure issuance of server certificates, following the guidance of the BRs. Email certificates are a different use case with

Re: question about DNS CAA and S/MIME certificates

For that matter, can whoever is in charge of gmail.com speak to their intent as to CAA for S/MIME? I've certainly held certificates which include my personal gmail address before. At no point did I need or seek Google's blessing to do so. I can not imagine that was an uncommon case. (At least,

Re: question about DNS CAA and S/MIME certificates

Tim, I hope you can see how this sort of response doesn't really do much to engender faith and trust in CAs. I am not sure if you're aware of how this can be perceived, but I suspect if you were, it might not have been so glibly dismissed. The only reason that "CAA is HTTPS-only" today is

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

Wayne, 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

> On 15 May 2018, at 05:56, Ryan Sleevi wrote: > > No. I am expressly opposed to any solution that is “ask the big guys and let > them decide what it means for the Internet”. > > While I can’t speak for Mozilla, that definitely seems against the spirit of > Mozilla’s

RE: question about DNS CAA and S/MIME certificates

CAA is HTTPS only today. That’s the reality. I don’t have to want to argue in favor of reality. Reality wins regardless of what I do. -Tim From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Monday, May 14, 2018 11:55 PM To: Tim Hollebeek Cc:

Re: question about DNS CAA and S/MIME certificates

On Tue, May 15, 2018 at 3:53 AM Jürgen Brauckmann wrote: > Ryan Sleevi via dev-security-policy wrote on 14.05.2018 20:52: > > And that still moves to an 'insecure-by-default', by making every site > > operator that has taken steps to actually restrict issuance not have >

Re: question about DNS CAA and S/MIME certificates

On Tue, May 15, 2018 at 12:13 AM Neil Dunbar via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > On 14 May 2018, at 20:55, Ryan Sleevi via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > If there are proponents of a 'fail open' model, > >

Re: question about DNS CAA and S/MIME certificates

Ryan Sleevi via dev-security-policy wrote on 14.05.2018 20:52: And that still moves to an 'insecure-by-default', by making every site operator that has taken steps to actually restrict issuance not have those wishes respected. Today, site operators have taken steps to secure issuance of server