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 Subject: Re: Bit encoding (AW: Policy 2.6 Proposal

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 mail

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)

The usual ANSI/ISO rule is that if you protect a strong key with a weak key, the strong key is now weak. This is true pretty much regardless of your threat model. It is absurdly hard to express in terms of auditable requirements, though. "Your AES-128 key has 112 bits of security because you

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 it into the policy document.

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 sufficie

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- > bounces+t

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

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 auto-enrollment

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 dom

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: > https://bugzilla.mozilla.org/show_bug.cgi?id=14

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 obj

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 there’

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 [m

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. Standar

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 something

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: > Blatantly false. I actually suspect

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 understa

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 m

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 pr

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 de

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 particular.maligned.user.undeserving.of.email.secur.

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 their

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 certific

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 ve

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 point did I need or se

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? CA-specific issue values don't help with > that p

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 Mozilla risk assessment came > up

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 different internal requir

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 because

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 sufficien

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 principles of open and e

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: r...@sleevi.com; Pedro Fuentes ; mozilla-

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 > those > > wishes respecte

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

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