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

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 specify scope

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: question about DNS CAA and S/MIME certificates

; bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Phillip > Hallam-Baker via dev-security-policy > Sent: Tuesday, May 15, 2018 9:22 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: question about DNS CAA and S/MIME certificates > > Whe

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

b...@digicert.com> > *Cc:* r...@sleevi.com; Pedro Fuentes <pfuente...@gmail.com>; > mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org > > > *Subject:* Re: question about DNS CAA and S/MIME certificates > > > > Tim, > &

RE: question about DNS CAA and S/MIME certificates

:44 PM To: Tim Hollebeek <tim.holleb...@digicert.com> Cc: r...@sleevi.com; Pedro Fuentes <pfuente...@gmail.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: question about DNS CAA and S/MIME certificates Tim, Could you cla

RE: question about DNS CAA and S/MIME certificates

[mailto:wtha...@mozilla.com] Sent: Tuesday, May 15, 2018 12:41 PM To: Tim Hollebeek <tim.holleb...@digicert.com> Cc: Ryan Sleevi <r...@sleevi.com>; Pedro Fuentes <pfuente...@gmail.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re

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

Monday, May 14, 2018 11:55 PM > > *To:* Tim Hollebeek <tim.holleb...@digicert.com> > *Cc:* r...@sleevi.com; Pedro Fuentes <pfuente...@gmail.com>; > mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org > > > *Subject:* Re: question about DNS CAA

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

Cc: r...@sleevi.com; Pedro Fuentes <pfuente...@gmail.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: question about DNS CAA and S/MIME certificates I'm not sure how that's advancing the discussion forward or adding new information. The

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

Re: question about DNS CAA and S/MIME certificates

> On 14 May 2018, at 20:55, Ryan Sleevi via dev-security-policy > wrote: > > If there are proponents of a 'fail open' model, > especially amongst CAs, then does it behove them to specify as quickly as > possible a 'fail closed' model, so that we don't

Re: question about DNS CAA and S/MIME certificates

; From: Ryan Sleevi [mailto:r...@sleevi.com] > Sent: Monday, May 14, 2018 8:24 PM > To: Tim Hollebeek <tim.holleb...@digicert.com> > Cc: r...@sleevi.com; Pedro Fuentes <pfuente...@gmail.com>; > mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozill

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

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 < dev-security-policy@lists.mozilla.org> wrote: > There’s an IETF component, but minimum necessary standards for email >

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

El lunes, 14 de mayo de 2018, 23:59:07 (UTC+2), Tim Hollebeek escribió: > As Neil correctly notes, it would be foolish to try to impose semantics and > apply > policy from the web CAA records onto email certificate issuance without first > figuring out what the semantics, requirements and

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

On 14/05/2018 20:55, Ryan Sleevi wrote: The Public Suffix List is a model for failure, not success - and I say that as one of the two PSL maintainers. As to the remaining points, I think each and every one of them doesn't actually hold up to scrutiny, and in fact, the opposite conclusion is more

Re: question about DNS CAA and S/MIME certificates

On Mon, May 14, 2018 at 1:10 PM, Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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

Re: question about DNS CAA and S/MIME certificates

The Public Suffix List is a model for failure, not success - and I say that as one of the two PSL maintainers. As to the remaining points, I think each and every one of them doesn't actually hold up to scrutiny, and in fact, the opposite conclusion is more in line with reality. For example, if

Re: question about DNS CAA and S/MIME certificates

On Mon, May 14, 2018 at 11:48 AM, Neil Dunbar via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > But it also seems reasonable for organisations making CAA assertions to > know the scope of their stipulations before they make them, no? > > So, if in the case of Yahoo, they

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 > > It seems perfectly reasonable and desirable to require that CAs, regardless of > the type of certificate they are issuing, respect CAA. > > If an email provider wishe

Re: question about DNS CAA and S/MIME certificates

Another approach could be to have something akin to the (non-ICANN) public suffix list, but for e-mail. This would list e-mail domains where the e-mail address holders are not the subordinates (employees, students, etc.) of the domain holder. Such a list would have multiple uses (just like the

Re: question about DNS CAA and S/MIME certificates

But it also seems reasonable for organisations making CAA assertions to know the scope of their stipulations before they make them, no? So, if in the case of Yahoo, they make the assertion “All of our web certificates should come from DigiCert”, are they aware that they are also making the

Re: question about DNS CAA and S/MIME certificates

Pedro Fuentes wrote: > Just to say that looking at this from Europe, I don't see this feasible. > > Citizens getting their personal eIDAS-compliant certificate go through > face-to-face validation and will give virtually any valid e-mail address to > appear in their certificate. > Then that

Re: question about DNS CAA and S/MIME certificates

Just to say that looking at this from Europe, I don't see this feasible. Citizens getting their personal eIDAS-compliant certificate go through face-to-face validation and will give virtually any valid e-mail address to appear in their certificate. El sábado, 12 de mayo de 2018, 2:30:58

Re: question about DNS CAA and S/MIME certificates

I created a new issue suggesting that we add this requirement to Mozilla policy: https://github.com/mozilla/pkipolicy/issues/135 On Wed, May 9, 2018 at 4:59 PM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wed, May 9, 2018 at 11:47 AM, Adrian R. via

Re: question about DNS CAA and S/MIME certificates

On Wed, May 9, 2018 at 11:47 AM, Adrian R. via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hello, > this question is somewhat outside the current Baseline Requirements, but... > > wouldn't it be normal for the same CAA rules for server certificates to > also apply to