RE: question about DNS CAA and S/MIME certificates

[Tim Hollebeek via dev-security-policy]

> 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 for issue /
> issuewild / issueclient sensibly.

Yup.  I'm optimistic it's something we can get done quickly.

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

[Phillip Hallam-Baker via dev-security-policy]

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 for issue / 
issuewild / issueclient sensibly. 

But that is only half the job really. If we want to get S/MIME widely used, we 
have to do ACME for client certs and integrate it into the MUAs. Not difficult 
but something needing to be done. 

More difficult is working out what an S/MIME CA does, where organizational 
validation etc. adds value and how this relates to the OpenPGP way of doing 
things. 


It occurred to me last night that the difference between S/MIME and OpenPGP 
trust is that one if by reference and the other is by value. S/MIME is 
certainly the solution for Paypal like situations because the trust 
relationship is (usually) with Paypal, not the individual I am talking to. Key 
fingerprints have the advantage of binding to the person which may be an 
advantage for non organizational situations.

These are not disjoint sets of course and there is no reason to switch mail 
encryption technologies depending on the context in which we are communicating. 
I would rather add certificate capabilities to OpenPGP-as-deployed and/or 
S/MIME-as-deployed.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: question about DNS CAA and S/MIME certificates

[Tim Hollebeek via dev-security-policy]

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 mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: question about DNS CAA and S/MIME certificates

[Tim Hollebeek via dev-security-policy]

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+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
> 
> 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 domains (or not).
> 
> If gmail want to limit the issue of Certs to one CA, fine. That is a
business choice
> they have made. If you want to have control of your online identity, you
need
> to have your own personal domain. That is why I have hallambaker.com. All
my
> mail is forwarded to gmail.com but I control my identity and can change
mail
> provider any time I want.
> 
> One use case that I see as definitive is to allow paypal to S/MIME sign
their
> emails. That alone could take a bite out of phishing.
> 
> But even with gmail, the only circumstance I could see where a mail
service
> provider like that would want to restrict cert issue to one CA would be if
they
> were to roll out S/MIME with their own CA.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/XjZsJF4yykVlCzqgt57_FIwsOTe0fR6a3C5kS
> Yh_IZ4=?d=lJg-wcLQ8TKi5x2vK8SJOJCjdKNbOFzJppz0UZwOpX_uS1wS1Mw-
> 5j_nOlfxrvZ_g0tSYqMRWJezQvAWyNySPmWiq8oV2gEI6bF-
> MXCodHj66yn6adEuwqxiAwHJd6tamadI6Kf-
> pHadUoBbCN15Wb8AEG3D126zrUxw7umhl5JRMC5lYu4kHiYb5kss5F0cvapf8h_
> U7XuRliUCpAUdVY_VtggCy6Hbk0u6x2IlNY411Cb49wMqOGMavYTwrT8CADJZ_
> OJ3cmVnrJLAclZ2Y96VSVSZpzc4h5UeBneGuFjm8T-ikCgGY3kDZfTHOOex-
> VrdHh0nbhZf-yoOgGiXg0naMQ0MnoHA_-L9tUotMKl1e-yScY5S-
> BG6sVyAe68iMOFtJaUYcyEV14-JlCiHpK8pRgYpdvB1V8O3IASeKCzuOiTPvJLrn-
> gCM2xICBAH-
> QzxWPVhgGZtP9OqMlqRDCJUeiAg9PJt=https%3A%2F%2Flists.mozilla.org%
> 2Flistinfo%2Fdev-security-policy


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

[Ryan Sleevi via dev-security-policy]

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 (and even server-mediated S/MIME
- https://support.google.com/a/answer/6374496?hl=en ).

It's the same distinction between, say, Google AppEngine (in which Google
manages the certs and TLS termination) versus Google Cloud Platform (in
which you could fully terminate TLS in your VM with your own domain).

On Tue, May 15, 2018 at 9:21 PM, Phillip Hallam-Baker via
dev-security-policy  wrote:

> 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 domains (or not).
>
> If gmail want to limit the issue of Certs to one CA, fine. That is a
> business choice they have made. If you want to have control of your online
> identity, you need to have your own personal domain. That is why I have
> hallambaker.com. All my mail is forwarded to gmail.com but I control my
> identity and can change mail provider any time I want.
>
> One use case that I see as definitive is to allow paypal to S/MIME sign
> their emails. That alone could take a bite out of phishing.
>
> But even with gmail, the only circumstance I could see where a mail
> service provider like that would want to restrict cert issue to one CA
> would be if they were to roll out S/MIME with their own CA.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Phillip Hallam-Baker via dev-security-policy]

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 domains (or not).

If gmail want to limit the issue of Certs to one CA, fine. That is a business 
choice they have made. If you want to have control of your online identity, you 
need to have your own personal domain. That is why I have hallambaker.com. All 
my mail is forwarded to gmail.com but I control my identity and can change mail 
provider any time I want.

One use case that I see as definitive is to allow paypal to S/MIME sign their 
emails. That alone could take a bite out of phishing. 

But even with gmail, the only circumstance I could see where a mail service 
provider like that would want to restrict cert issue to one CA would be if they 
were to roll out S/MIME with their own CA.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

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 do it" seems inconsistent
with "another RFC explaining CAA for email" - rough consensus and running
code.

I agree that it's useful to determine what the priorities should be.

CAs' CP/CPS can document today what they do with CAA in S/MIME. CAA, as
written today, absolutely can support email. In an ideal world, CAs would
take the maximally restrictive approach to issuance, recognizing that
domain operators have primacy over their domains compared to any other
entity within their management authority, and that necessarily includes
e-mail.

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.

That said, this is all largely moot, because CAs have strong incentives to
not do anything with CAA until they're forced to, and to try to make it
someone else's problem as much as possible (passing the buck between CABF,
IETF, and root stores for S/MIME), and in the mean time, site operators
lose because unless and until CAs do something about it, there's no way
they can restrict S/MIME issuance, and thus there's fundamentally
questionable value to S/MIME issuance today. To the extent CAs want to cut
off their nose to spite their face, I suppose that's their prerogative.

The principle at play here, though - that CAA is not an intent to do
exactly what it says, which is restrict the issuance of certificates
bearing that domain (in all forms), is deeply troubling for any future
PKIs, and merely shows the trouble with reliance on third-party CAs in any
new PKIs.

On Tue, May 15, 2018 at 3:42 PM, Tim Hollebeek <tim.holleb...@digicert.com>
wrote:

> 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’s
> no document out there that specifies what ‘right’ is yet.  And there isn’t
> much value to CAA if only a few CAs do it.
>
>
>
> That’s why I think we need 8644-bis first.  Or another RFC explaining CAA
> for email.
>
>
>
> -Tim
>
>
>
> *From:* Ryan Sleevi [mailto:r...@sleevi.com]
> *Sent:* Tuesday, May 15, 2018 12: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 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 <
> tim.holleb...@digicert.com> wrote:
>
> 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.
>
>
>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: question about DNS CAA and S/MIME certificates

[Tim Hollebeek via dev-security-policy]

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’s no 
document out there that specifies what ‘right’ is yet.  And there isn’t much 
value to CAA if only a few CAs do it.

 

That’s why I think we need 8644-bis first.  Or another RFC explaining CAA for 
email.

 

-Tim

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Tuesday, May 15, 2018 12: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 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 <tim.holleb...@digicert.com 
<mailto:tim.holleb...@digicert.com> > wrote:

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: question about DNS CAA and S/MIME certificates

[Tim Hollebeek via dev-security-policy]

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 [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: 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 presence of any 
CAA record, but that is a challenge as long as ecosystem participants view CAA 
as applicable only to server certificates. The sooner we address this issue, 
the better.

 

Mozilla policy isn't a great place to define CAA syntax. 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 AM Tim Hollebeek via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

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 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.
>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Matthew Hardeman via dev-security-policy]

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 understanding historically
(whether or not correct) that CAA pertained to server certificates.

On Tue, May 15, 2018 at 11:40 AM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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 presence of
> any CAA record, but that is a challenge as long as ecosystem participants
> view CAA as applicable only to server certificates. The sooner we address
> this issue, the better.
>
> Mozilla policy isn't a great place to define CAA syntax. 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 AM Tim Hollebeek via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > 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.
> >
> >
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

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 make up stories here to
support your argument. Unless the argument is that "Nobody bothered with
deploying CAA records until CAA existed", by presuming that the 'run-up'
was from existence to requirement, in which case, that's a tautologically
true statement being used to try to misrepresent and mislead. Which is,
itself, problematic.


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

Similarly, this continues to present opinion as fact.


>
> It is, in practical terms, revisionist to change the impact of those extant
> deployments.
>
> On Tue, May 15, 2018 at 11:14 AM, Ryan Sleevi  wrote:
>
> > 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 certificate issuance? Couldn't they
> > have been (in this poor stretch of logic) trying to restrict issuance of
> > S/MIME certificates instead?
> >
> > That's why the argument makes no sense.
> >
> > As to rfc822 names not being mapped onto DNS, that's just definitionally
> > inaccurate. RFC822 names include a domain component. The addr-spec is
> > local-part "@" domain. With domain being the routable definition that we
> > all know and love. You can't just pretend that's not part of the scoping
> or
> > authority here.
> >
> >
> > On Tue, May 15, 2018 at 12:06 PM, Matthew Hardeman via
> dev-security-policy
> >  wrote:
> >
> >> 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.  The name
> spaces
> >> are different for email addresses versus DNS names.  CAA aligns cleanly
> to
> >> DNS names.  It does not align cleanly to rfc822 names.
> >>
> >> Mr. Sleevi's complaints regarding fail-open security are reasonable.
> >> However, they seem misplaced within the scope of CAA, which at the most
> >> basic level is a fail-open mechanism: lack of a CAA record assumes all
> >> issuance allowed.
> >>
> >> Reinterpreting the scope of extant CAA records might well have a
> chilling
> >> effect on further adoption of CAA.
> >>
> >> When an expressed intent such as CAA has (by definition OR by real-world
> >> effect) a limited scope, many participants will not appreciate that
> scope
> >> being expanded.
> >>
> >> I believe the "issue" and "issuewild" tags should be regarded as
> >> pertaining
> >> only to certificates which either 1) lack any EKU OR 2) include either
> >> anyPurpose EKU or serverAuth EKUs.
> >>
> >>
> >>
> >> On Tue, May 15, 2018 at 10:57 AM, Neil Dunbar via dev-security-policy <
> >> dev-security-policy@lists.mozilla.org> wrote:
> >>
> >> >
> >> > > On 15 May 2018, at 07:59, Matthew Hardeman 
> >> wrote:
> >> > >
> >> > > For that matter, can whoever is in charge of gmail.com <
> >> > http://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, not uncommon
> >> relative to
> >> > the universe of issued S/MIME certificates.)
> >> >
> >> > Well, I don’t see a CAA record for gmail.com ,
> thus
> >> > even if CAA issue tags were reinterpreted, as suggested, to cover
> >> S/MIME,
> >> > such issuance would not be prohibited (unlike, say, google.com <
> >> > http://google.com/>, which does have a CAA record).
> >> >
> >> > In other words, those certificates that you were issued hitherto could
> >> not
> >> > have violated CAA policy, since there was no such expression of
> policy.
> >> >
> >> > Regards,
> >> >
> >> > Neil
> >> > ___
> >> > dev-security-policy mailing list
> >> > dev-security-policy@lists.mozilla.org
> >> > https://lists.mozilla.org/listinfo/dev-security-policy
> >> >
> >> ___
> >> dev-security-policy mailing list
> >> dev-security-policy@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-security-policy
> >>
> >
> >
> ___
> 

Re: question about DNS CAA and S/MIME certificates

[Wayne Thayer via dev-security-policy]

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 presence of
any CAA record, but that is a challenge as long as ecosystem participants
view CAA as applicable only to server certificates. The sooner we address
this issue, the better.

Mozilla policy isn't a great place to define CAA syntax. 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 AM Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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.
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

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 dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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...@mydomain.com while
> allowing the following CAs to issue for any email address over the same
> domain.
>
> On Tue, May 15, 2018 at 11:15 AM, Ryan Sleevi  wrote:
>
> > 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
> >  wrote:
> >
> >> 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 versus SAN dnsNames.  The X.509 certificate
> >> distinguishes these names as belonging to separate name spaces.  CAA
> does
> >> not presently have this concept.  Yet the proposal here would have us
> >> relying upon the more simplistic DNS names expressed in CAA records.
> >>
> >> On Tue, May 15, 2018 at 10:57 AM, Neil Dunbar via dev-security-policy <
> >> dev-security-policy@lists.mozilla.org> wrote:
> >>
> >> >
> >> > > On 15 May 2018, at 07:59, Matthew Hardeman 
> >> wrote:
> >> > >
> >> > > For that matter, can whoever is in charge of gmail.com <
> >> > http://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, not uncommon
> >> relative to
> >> > the universe of issued S/MIME certificates.)
> >> >
> >> > Well, I don’t see a CAA record for gmail.com ,
> thus
> >> > even if CAA issue tags were reinterpreted, as suggested, to cover
> >> S/MIME,
> >> > such issuance would not be prohibited (unlike, say, google.com <
> >> > http://google.com/>, which does have a CAA record).
> >> >
> >> > In other words, those certificates that you were issued hitherto could
> >> not
> >> > have violated CAA policy, since there was no such expression of
> policy.
> >> >
> >> > Regards,
> >> >
> >> > Neil
> >> > ___
> >> > dev-security-policy mailing list
> >> > dev-security-policy@lists.mozilla.org
> >> > https://lists.mozilla.org/listinfo/dev-security-policy
> >> >
> >> ___
> >> dev-security-policy mailing list
> >> dev-security-policy@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-security-policy
> >>
> >
> >
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: question about DNS CAA and S/MIME certificates

[Tim Hollebeek via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Matthew Hardeman via dev-security-policy]

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 terms, revisionist to change the impact of those extant
deployments.

On Tue, May 15, 2018 at 11:14 AM, Ryan Sleevi  wrote:

> 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 certificate issuance? Couldn't they
> have been (in this poor stretch of logic) trying to restrict issuance of
> S/MIME certificates instead?
>
> That's why the argument makes no sense.
>
> As to rfc822 names not being mapped onto DNS, that's just definitionally
> inaccurate. RFC822 names include a domain component. The addr-spec is
> local-part "@" domain. With domain being the routable definition that we
> all know and love. You can't just pretend that's not part of the scoping or
> authority here.
>
>
> On Tue, May 15, 2018 at 12:06 PM, Matthew Hardeman via dev-security-policy
>  wrote:
>
>> 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.  The name spaces
>> are different for email addresses versus DNS names.  CAA aligns cleanly to
>> DNS names.  It does not align cleanly to rfc822 names.
>>
>> Mr. Sleevi's complaints regarding fail-open security are reasonable.
>> However, they seem misplaced within the scope of CAA, which at the most
>> basic level is a fail-open mechanism: lack of a CAA record assumes all
>> issuance allowed.
>>
>> Reinterpreting the scope of extant CAA records might well have a chilling
>> effect on further adoption of CAA.
>>
>> When an expressed intent such as CAA has (by definition OR by real-world
>> effect) a limited scope, many participants will not appreciate that scope
>> being expanded.
>>
>> I believe the "issue" and "issuewild" tags should be regarded as
>> pertaining
>> only to certificates which either 1) lack any EKU OR 2) include either
>> anyPurpose EKU or serverAuth EKUs.
>>
>>
>>
>> On Tue, May 15, 2018 at 10:57 AM, Neil Dunbar via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> >
>> > > On 15 May 2018, at 07:59, Matthew Hardeman 
>> wrote:
>> > >
>> > > For that matter, can whoever is in charge of gmail.com <
>> > http://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, not uncommon
>> relative to
>> > the universe of issued S/MIME certificates.)
>> >
>> > Well, I don’t see a CAA record for gmail.com , thus
>> > even if CAA issue tags were reinterpreted, as suggested, to cover
>> S/MIME,
>> > such issuance would not be prohibited (unlike, say, google.com <
>> > http://google.com/>, which does have a CAA record).
>> >
>> > In other words, those certificates that you were issued hitherto could
>> not
>> > have violated CAA policy, since there was no such expression of policy.
>> >
>> > Regards,
>> >
>> > Neil
>> > ___
>> > dev-security-policy mailing list
>> > dev-security-policy@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-security-policy
>> >
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Matthew Hardeman via dev-security-policy]

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...@mydomain.com while
allowing the following CAs to issue for any email address over the same
domain.

On Tue, May 15, 2018 at 11:15 AM, Ryan Sleevi  wrote:

> 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
>  wrote:
>
>> 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 versus SAN dnsNames.  The X.509 certificate
>> distinguishes these names as belonging to separate name spaces.  CAA does
>> not presently have this concept.  Yet the proposal here would have us
>> relying upon the more simplistic DNS names expressed in CAA records.
>>
>> On Tue, May 15, 2018 at 10:57 AM, Neil Dunbar via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> >
>> > > On 15 May 2018, at 07:59, Matthew Hardeman 
>> wrote:
>> > >
>> > > For that matter, can whoever is in charge of gmail.com <
>> > http://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, not uncommon
>> relative to
>> > the universe of issued S/MIME certificates.)
>> >
>> > Well, I don’t see a CAA record for gmail.com , thus
>> > even if CAA issue tags were reinterpreted, as suggested, to cover
>> S/MIME,
>> > such issuance would not be prohibited (unlike, say, google.com <
>> > http://google.com/>, which does have a CAA record).
>> >
>> > In other words, those certificates that you were issued hitherto could
>> not
>> > have violated CAA policy, since there was no such expression of policy.
>> >
>> > Regards,
>> >
>> > Neil
>> > ___
>> > dev-security-policy mailing list
>> > dev-security-policy@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-security-policy
>> >
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

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 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 versus SAN dnsNames.  The X.509 certificate
> distinguishes these names as belonging to separate name spaces.  CAA does
> not presently have this concept.  Yet the proposal here would have us
> relying upon the more simplistic DNS names expressed in CAA records.
>
> On Tue, May 15, 2018 at 10:57 AM, Neil Dunbar via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> >
> > > On 15 May 2018, at 07:59, Matthew Hardeman 
> wrote:
> > >
> > > For that matter, can whoever is in charge of gmail.com <
> > http://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, not uncommon relative
> to
> > the universe of issued S/MIME certificates.)
> >
> > Well, I don’t see a CAA record for gmail.com , thus
> > even if CAA issue tags were reinterpreted, as suggested, to cover S/MIME,
> > such issuance would not be prohibited (unlike, say, google.com <
> > http://google.com/>, which does have a CAA record).
> >
> > In other words, those certificates that you were issued hitherto could
> not
> > have violated CAA policy, since there was no such expression of policy.
> >
> > Regards,
> >
> > Neil
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

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 certificate issuance? Couldn't they have been (in this poor
stretch of logic) trying to restrict issuance of S/MIME certificates
instead?

That's why the argument makes no sense.

As to rfc822 names not being mapped onto DNS, that's just definitionally
inaccurate. RFC822 names include a domain component. The addr-spec is
local-part "@" domain. With domain being the routable definition that we
all know and love. You can't just pretend that's not part of the scoping or
authority here.

On Tue, May 15, 2018 at 12:06 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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.  The name spaces
> are different for email addresses versus DNS names.  CAA aligns cleanly to
> DNS names.  It does not align cleanly to rfc822 names.
>
> Mr. Sleevi's complaints regarding fail-open security are reasonable.
> However, they seem misplaced within the scope of CAA, which at the most
> basic level is a fail-open mechanism: lack of a CAA record assumes all
> issuance allowed.
>
> Reinterpreting the scope of extant CAA records might well have a chilling
> effect on further adoption of CAA.
>
> When an expressed intent such as CAA has (by definition OR by real-world
> effect) a limited scope, many participants will not appreciate that scope
> being expanded.
>
> I believe the "issue" and "issuewild" tags should be regarded as pertaining
> only to certificates which either 1) lack any EKU OR 2) include either
> anyPurpose EKU or serverAuth EKUs.
>
>
>
> On Tue, May 15, 2018 at 10:57 AM, Neil Dunbar via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> >
> > > On 15 May 2018, at 07:59, Matthew Hardeman 
> wrote:
> > >
> > > For that matter, can whoever is in charge of gmail.com <
> > http://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, not uncommon relative
> to
> > the universe of issued S/MIME certificates.)
> >
> > Well, I don’t see a CAA record for gmail.com , thus
> > even if CAA issue tags were reinterpreted, as suggested, to cover S/MIME,
> > such issuance would not be prohibited (unlike, say, google.com <
> > http://google.com/>, which does have a CAA record).
> >
> > In other words, those certificates that you were issued hitherto could
> not
> > have violated CAA policy, since there was no such expression of policy.
> >
> > Regards,
> >
> > Neil
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Matthew Hardeman via dev-security-policy]

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 versus SAN dnsNames.  The X.509 certificate
distinguishes these names as belonging to separate name spaces.  CAA does
not presently have this concept.  Yet the proposal here would have us
relying upon the more simplistic DNS names expressed in CAA records.

On Tue, May 15, 2018 at 10:57 AM, Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> > On 15 May 2018, at 07:59, Matthew Hardeman  wrote:
> >
> > For that matter, can whoever is in charge of gmail.com <
> http://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, not uncommon relative to
> the universe of issued S/MIME certificates.)
>
> Well, I don’t see a CAA record for gmail.com , thus
> even if CAA issue tags were reinterpreted, as suggested, to cover S/MIME,
> such issuance would not be prohibited (unlike, say, google.com <
> http://google.com/>, which does have a CAA record).
>
> In other words, those certificates that you were issued hitherto could not
> have violated CAA policy, since there was no such expression of policy.
>
> Regards,
>
> Neil
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Matthew Hardeman via dev-security-policy]

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.  The name spaces
are different for email addresses versus DNS names.  CAA aligns cleanly to
DNS names.  It does not align cleanly to rfc822 names.

Mr. Sleevi's complaints regarding fail-open security are reasonable.
However, they seem misplaced within the scope of CAA, which at the most
basic level is a fail-open mechanism: lack of a CAA record assumes all
issuance allowed.

Reinterpreting the scope of extant CAA records might well have a chilling
effect on further adoption of CAA.

When an expressed intent such as CAA has (by definition OR by real-world
effect) a limited scope, many participants will not appreciate that scope
being expanded.

I believe the "issue" and "issuewild" tags should be regarded as pertaining
only to certificates which either 1) lack any EKU OR 2) include either
anyPurpose EKU or serverAuth EKUs.



On Tue, May 15, 2018 at 10:57 AM, Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> > On 15 May 2018, at 07:59, Matthew Hardeman  wrote:
> >
> > For that matter, can whoever is in charge of gmail.com <
> http://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, not uncommon relative to
> the universe of issued S/MIME certificates.)
>
> Well, I don’t see a CAA record for gmail.com , thus
> even if CAA issue tags were reinterpreted, as suggested, to cover S/MIME,
> such issuance would not be prohibited (unlike, say, google.com <
> http://google.com/>, which does have a CAA record).
>
> In other words, those certificates that you were issued hitherto could not
> have violated CAA policy, since there was no such expression of policy.
>
> Regards,
>
> Neil
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Neil Dunbar via dev-security-policy]

> 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 seek Google's blessing to do so.  I can 
> not imagine that was an uncommon case.  (At least, not uncommon relative to 
> the universe of issued S/MIME certificates.)

Well, I don’t see a CAA record for gmail.com , thus even if 
CAA issue tags were reinterpreted, as suggested, to cover S/MIME, such issuance 
would not be prohibited (unlike, say, google.com , which 
does have a CAA record).

In other words, those certificates that you were issued hitherto could not have 
violated CAA policy, since there was no such expression of policy.

Regards,

Neil
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

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


Sure they do. A CA that wished to do the right thing could define a syntax
in the CA/Browser Forum that all issuers are supposed to understand, such
as "scope=https" or even 'ekus=[foo,bar,baz]'

Absent a scope issuer parameter, then it's presumed to be global scope.
Present a scope parameter, it's syntax is defined.

That's an application of policy - what to do when CAA restrictions exist -
and that can be 'easily' defined.

There is, of course, the route of adding new flags or properties, both with
spec-required registries, but a security-positive CA can and should be
exploring ways to issue scoped restrictions (e.g. could introduce an
'issueserverauth')


> CAA was introduced by the BRs, and is thus felt as server-only and is used
> as server-only. Changing that is absolutely possible, but should be done
> with care, as there are use-cases which will break if CAA is adopted
> naively for email certs.
>

Sure, and in the absence of a force that actually ensures CAs respect
domain holders, we know there's not going to be any 'naive' adoption - that
is, it's clear that unless and until Root Stores require it, CAs won't
adopt it.


>
> This is all about responsible change.
>

CAA was introduced in the BRs because, despite 5 years of discussion, CAs
were opposed to it, because it would restrict what they could issue. The
same story is now playing out, with the same set of overwrought concerns.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Jürgen Brauckmann via dev-security-policy]

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

Current CAA syntax lacks the possibility to distinguish between those
two, which will come as a big surprise for organisations who whish to
limit issuance of server certificates, but want to set different (or
none at all) policies for email certificates.

Mandating CAA checks in its current form also for email certificates
destroys or at least greatly hinders the rather creative technique of
having a general "no-issuance" CAA record and setting short-lived
issue-properties, as described in 6.3 of
https://www.net.in.tum.de/fileadmin/bibtex/publications/papers/caa17.pdf

Isn’t this exactly what I said?


That CAs need to work out how to describe “disallow for server auth, allow
for S/MIME?”


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



We absolutely have to take CAA as an expression of CA restriction. It’s in
the very name! If you want to allow some CAs for some use cases, you need a
syntax to describe that.


Which is lacking today.


But you cannot make a reasonable argument that
“Just because they locked the door, they didn’t mean for us to not break a
window” - which is what every proposal to suggest CAA is server-only
fundamentally amounts to.


CAA was introduced by the BRs, and is thus felt as server-only and is 
used as server-only. Changing that is absolutely possible, but should be 
done with care, as there are use-cases which will break if CAA is 
adopted naively for email certs.


This is all about responsible change.

Jürgen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Matthew Hardeman via dev-security-policy]

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, not uncommon relative to
the universe of issued S/MIME certificates.)

On Mon, May 14, 2018 at 11:13 PM, 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,
> > especially amongst CAs, then does it behove them to specify as quickly as
> > possible a 'fail closed' model, so that we don't have to try and divine
> > intent and second guess site operators as to whether they meant to
> restrict
> > HTTPS or everything?
>
> While this is in no way comprehensive or scientific, could we not just
> poll those (larger) domain owners who also operate publicly available mail
> services (like Yahoo) what they consider the scope of their CAA assertions?
> There can’t be a super abundance of them, surely?
>
> I’m no friend of ‘default-allow’ semantics, but I’m also not a fan of
> ninja-changing semantics either. If domain owners intended to only express
> a company policy on TLS certs (whether HTTPS, LDAP/STARTTLS, IMAP/STARTTLS
> or whatever); then might they not be amenable to altering their expression
> to an ‘issue(wild)?-tls’ tag instead, but only if they were aware of the
> scope of their (in-)actions?
>
> That would then enable a future move for CAs to respect ‘issue’ and
> ‘issuewild’ to cover all cert types, while still allowing domain owners
> finer grained expression of their policies. It’s pretty much an entire
> reversal of my earlier suggestion(!), but perhaps a modification which
> would preserve the expressions of (handwave, handwave) 95% of CAA records
> owners who don’t operate public mail services, and yet still can cover
> those mail providers?
>
> But without the courtesy of at least asking those few domain owners what
> they meant, it just seems a bit rude to assume their intentions.
>
> Regards,
>
> Neil
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

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 CAs are not
interested in doing the 'right' thing. That is, to actually treat the CAA
as part of an integrated system of domain validation. The only reason we
even have HTTPS today is because browsers - notably Mozilla taking the lead
- required that CAs check CAA for HTTPS as a condition for remaining
trusted.

It appears that you're stating that unless a CA is forced to do something,
they have no incentive to actually adopt it. Rather than help establish
what secure norms are - that is, treat CAA is exactly what it tries to be
(a restriction on what CAs can issue) - it seems that you're arguing "As
long as everyone else can do bad, we have no reason to be better."

CAA has been finalized for 6 years (modulo the delay in editorial
formatting), and as a concept, goes back 8 years. Every step along the way,
a number of CAs opposed to, because they were concerned they wouldn't be
able to issue certs. Now we're hearing the same argument.

I hope you can do better than that, and that this sort of response doesn't
sully what remaining good will that DigiCert has. Consider how you could,
as a CA, more productively contribute to the discussion:

From a purely informational standpoint:
1) Check CAA during the issuance of S/MIME certificates, and share details
about how many S/MIME certificates would fail the CAA check
2) Require CAA checks to succeed for S/MIME by default. If they fail,
require the customer/applicant give details about why the failure

From an actually lead in security, rather than hide in a crowd of bad
actors:
3) Require CAA checks to succeed for S/MIME. Require the domain holder to
demonstrate explicit intent to allow DigiCert S/MIME issuance (for example,
adding a parameter to their issue records)

There are ways in which DigiCert is uniquely capable of showing technical
leadership and contributing to the discussion. Glib replies like this do
not do that, and only further cement the "CAs are shady" idea that further
erodes trust in PKIs, particularly S/MIME.

On Tue, May 15, 2018 at 9:11 AM, Tim Hollebeek <tim.holleb...@digicert.com>
wrote:

> 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 <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
>
>
>
> I'm not sure how that's advancing the discussion forward or adding new
> information. The discussion of CAA and wanting to get feedback predates
> even the IETF finalization, as multiple browsers kept encouraging CAs to
> experiment with and attempt to deploy CAA so that we could make sure the
> kinks were ironed out.
>
>
>
> Regardless of posturing and grandstanding for past statements, can we at
> least agree that a model that argues "fail open" as a solution is a
> fundamentally insecure one? 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 have to try and divine
> intent and second guess site operators as to whether they meant to restrict
> HTTPS or everything?
>
>
>
> Put differently, if you want to argue that CAA is HTTPS only, then you
> need to define a way to ensure it's not HTTPS-only, and ASAP. Otherwise,
> the solution is that when S/MIME BRs come around, we simply cannot and
> should not second guess site operators and try to argue CAA was only
> 'those' type of certs - and instead require anyone with a CAA record to
> explicitly opt-in to allowing (potentially unbounded) S/MIME. I don't see
> any other realistic or practical solution - you can't say "This protects
> you" and then propose 2 years down the road, with S/MIME BRs, that it
> didn't actually 'protect' the site operator - the same way you can't say
> "Restrict access to these five email addresses" and then introduce a dozen
> more 2 years down the road.
>
>
>
> On Mon, May 14, 2018 at 11:07 PM, Tim Hollebeek via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> Normally I’d agree that IETF cannot and should not be a blocker for action
> at Mozilla and/or C

Re: question about DNS CAA and S/MIME certificates

[Neil Dunbar via dev-security-policy]

> 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 equal access.
> 
> It has a recasting failure mode as well, in that anyone who isn’t aware of 
> the subtlety of this proposed redefinition ends up less secure.
> 
> Surely you would agree that both of these consequences should be unacceptable?

Then it seems we are at an impasse. I am 100% in favour of allowing domain 
holders (defined broadly) being able to express policy via CAA (and since CAA 
tags are extensible, such policies have only just begun to be developed), I am 
not yet convinced that current CAA expressions intended to bind anything except 
TLS certificate issuance for end entities within the domain holders.

If I might rudely (and probably wrongly) paraphrase Tim, my opinion on what is 
or should be is all but irrelevant, if those are the facts on the ground.

I’m certainly not in favour of ‘ask the big players what it means’ if that 
means accepting everything they have to say as holy writ - but garnering 
expressions of intent, from a clearly impacted contingent, in order to better 
inform a debate, is not equivalent to that, to my way of thinking.

At the very least, Mozilla would want to publicise more widely the scope of any 
proposed reinterpretation of CAA records; having the reinterpretation happen 
within a relatively small, though not exclusive, conclave doesn’t seem like 
good policy.

Regards,

Neil
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: question about DNS CAA and S/MIME certificates

[Tim Hollebeek via dev-security-policy]

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

 

I'm not sure how that's advancing the discussion forward or adding new 
information. The discussion of CAA and wanting to get feedback predates even 
the IETF finalization, as multiple browsers kept encouraging CAs to experiment 
with and attempt to deploy CAA so that we could make sure the kinks were ironed 
out.

 

Regardless of posturing and grandstanding for past statements, can we at least 
agree that a model that argues "fail open" as a solution is a fundamentally 
insecure one? 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 have to try and divine intent and second guess 
site operators as to whether they meant to restrict HTTPS or everything?

 

Put differently, if you want to argue that CAA is HTTPS only, then you need to 
define a way to ensure it's not HTTPS-only, and ASAP. Otherwise, the solution 
is that when S/MIME BRs come around, we simply cannot and should not second 
guess site operators and try to argue CAA was only 'those' type of certs - and 
instead require anyone with a CAA record to explicitly opt-in to allowing 
(potentially unbounded) S/MIME. I don't see any other realistic or practical 
solution - you can't say "This protects you" and then propose 2 years down the 
road, with S/MIME BRs, that it didn't actually 'protect' the site operator - 
the same way you can't say "Restrict access to these five email addresses" and 
then introduce a dozen more 2 years down the road.

 

On Mon, May 14, 2018 at 11:07 PM, Tim Hollebeek via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

Normally I’d agree that IETF cannot and should not be a blocker for action at 
Mozilla and/or CABF, but based on our experience with CAA for web certificates, 
I would encourage people to get in their time machines and go back two to three 
years, and listen to Tim standing up and saying “I like CAA for the Web PKI, 
but what have we not thought of?”



-Tim



From: Ryan Sleevi [mailto:r...@sleevi.com <mailto:r...@sleevi.com> ] 
Sent: Monday, May 14, 2018 8:24 PM
To: Tim Hollebeek <tim.holleb...@digicert.com 
<mailto:tim.holleb...@digicert.com> >
Cc: r...@sleevi.com <mailto:r...@sleevi.com> ; Pedro Fuentes 
<pfuente...@gmail.com <mailto:pfuente...@gmail.com> >; 
mozilla-dev-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 Mon, May 14, 2018 at 6:20 PM, Tim Hollebeek via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org>  
<mailto:dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > > wrote:

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 effect on July 3rd, I'm cautiously 
optimistic
we can start writing requirements for e-mail certificates and phasing out bad 
practices
and phasing in good practices soon.  CAA for e-mail certificates is definitely 
worth
considering as part of that process.



Isn't this an IETF issue? Shouldn't those who issue e-mail certificates begin 
looking at the level of authentication provided for domains today?


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org>  
<mailto:dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > 
https://lists.mozilla.org/listinfo/dev-security-policy




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> 
https://lists.mozilla.org/listinfo/dev-security-policy

 



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

[Ryan Sleevi via dev-security-policy]

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 respected.
>
> 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
> requirements.
>
> Current CAA syntax lacks the possibility to distinguish between those
> two, which will come as a big surprise for organisations who whish to
> limit issuance of server certificates, but want to set different (or
> none at all) policies for email certificates.
>
> Mandating CAA checks in its current form also for email certificates
> destroys or at least greatly hinders the rather creative technique of
> having a general "no-issuance" CAA record and setting short-lived
> issue-properties, as described in 6.3 of
> https://www.net.in.tum.de/fileadmin/bibtex/publications/papers/caa17.pdf
>
> Isn’t this exactly what I said?

That CAs need to work out how to describe “disallow for server auth, allow
for S/MIME?”

I feel like proponents of the minimally scoped CAA interpretation are in an
indefensible position - and the very self-same arguments that it “only”
applies to server auth could be made, just as incorrectly, that CAA only
applies to HTTPS certs and not SMTPS or the like.

We absolutely have to take CAA as an expression of CA restriction. It’s in
the very name! If you want to allow some CAs for some use cases, you need a
syntax to describe that. But you cannot make a reasonable argument that
“Just because they locked the door, they didn’t mean for us to not break a
window” - which is what every proposal to suggest CAA is server-only
fundamentally amounts to.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

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,
> > especially amongst CAs, then does it behove them to specify as quickly as
> > possible a 'fail closed' model, so that we don't have to try and divine
> > intent and second guess site operators as to whether they meant to
> restrict
> > HTTPS or everything?
>
> While this is in no way comprehensive or scientific, could we not just
> poll those (larger) domain owners who also operate publicly available mail
> services (like Yahoo) what they consider the scope of their CAA assertions?
> There can’t be a super abundance of them, surely?
>

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 equal access.

It has a recasting failure mode as well, in that anyone who isn’t aware of
the subtlety of this proposed redefinition ends up less secure.

Surely you would agree that both of these consequences should be
unacceptable?


> I’m no friend of ‘default-allow’ semantics, but I’m also not a fan of
> ninja-changing semantics either. If domain owners intended to only express
> a company policy on TLS certs (whether HTTPS, LDAP/STARTTLS, IMAP/STARTTLS
> or whatever); then might they not be amenable to altering their expression
> to an ‘issue(wild)?-tls’ tag instead, but only if they were aware of the
> scope of their (in-)actions?
>
> That would then enable a future move for CAs to respect ‘issue’ and
> ‘issuewild’ to cover all cert types, while still allowing domain owners
> finer grained expression of their policies. It’s pretty much an entire
> reversal of my earlier suggestion(!), but perhaps a modification which
> would preserve the expressions of (handwave, handwave) 95% of CAA records
> owners who don’t operate public mail services, and yet still can cover
> those mail providers?
>
> But without the courtesy of at least asking those few domain owners what
> they meant, it just seems a bit rude to assume their intentions.
>
> Regards,
>
> Neil
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Jürgen Brauckmann via dev-security-policy]

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 
certificates, following the guidance of the BRs.


Email certificates are a different use case with different internal 
requirements.


Current CAA syntax lacks the possibility to distinguish between those 
two, which will come as a big surprise for organisations who whish to 
limit issuance of server certificates, but want to set different (or 
none at all) policies for email certificates.


Mandating CAA checks in its current form also for email certificates 
destroys or at least greatly hinders the rather creative technique of 
having a general "no-issuance" CAA record and setting short-lived 
issue-properties, as described in 6.3 of 
https://www.net.in.tum.de/fileadmin/bibtex/publications/papers/caa17.pdf


  Jürgen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Neil Dunbar via dev-security-policy]

> 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 have to try and divine
> intent and second guess site operators as to whether they meant to restrict
> HTTPS or everything?

While this is in no way comprehensive or scientific, could we not just poll 
those (larger) domain owners who also operate publicly available mail services 
(like Yahoo) what they consider the scope of their CAA assertions? There can’t 
be a super abundance of them, surely?

I’m no friend of ‘default-allow’ semantics, but I’m also not a fan of 
ninja-changing semantics either. If domain owners intended to only express a 
company policy on TLS certs (whether HTTPS, LDAP/STARTTLS, IMAP/STARTTLS or 
whatever); then might they not be amenable to altering their expression to an 
‘issue(wild)?-tls’ tag instead, but only if they were aware of the scope of 
their (in-)actions?

That would then enable a future move for CAs to respect ‘issue’ and ‘issuewild’ 
to cover all cert types, while still allowing domain owners finer grained 
expression of their policies. It’s pretty much an entire reversal of my earlier 
suggestion(!), but perhaps a modification which would preserve the expressions 
of (handwave, handwave) 95% of CAA records owners who don’t operate public mail 
services, and yet still can cover those mail providers?

But without the courtesy of at least asking those few domain owners what they 
meant, it just seems a bit rude to assume their intentions.

Regards,

Neil
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

I'm not sure how that's advancing the discussion forward or adding new
information. The discussion of CAA and wanting to get feedback predates
even the IETF finalization, as multiple browsers kept encouraging CAs to
experiment with and attempt to deploy CAA so that we could make sure the
kinks were ironed out.

Regardless of posturing and grandstanding for past statements, can we at
least agree that a model that argues "fail open" as a solution is a
fundamentally insecure one? 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 have to try and divine
intent and second guess site operators as to whether they meant to restrict
HTTPS or everything?

Put differently, if you want to argue that CAA is HTTPS only, then you need
to define a way to ensure it's not HTTPS-only, and ASAP. Otherwise, the
solution is that when S/MIME BRs come around, we simply cannot and should
not second guess site operators and try to argue CAA was only 'those' type
of certs - and instead require anyone with a CAA record to explicitly
opt-in to allowing (potentially unbounded) S/MIME. I don't see any other
realistic or practical solution - you can't say "This protects you" and
then propose 2 years down the road, with S/MIME BRs, that it didn't
actually 'protect' the site operator - the same way you can't say "Restrict
access to these five email addresses" and then introduce a dozen more 2
years down the road.

On Mon, May 14, 2018 at 11:07 PM, Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Normally I’d agree that IETF cannot and should not be a blocker for action
> at Mozilla and/or CABF, but based on our experience with CAA for web
> certificates, I would encourage people to get in their time machines and go
> back two to three years, and listen to Tim standing up and saying “I like
> CAA for the Web PKI, but what have we not thought of?”
>
>
>
> -Tim
>
>
>
> 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.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 <
> dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@
> lists.mozilla.org> > wrote:
>
> 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 effect on July 3rd, I'm cautiously
> optimistic
> we can start writing requirements for e-mail certificates and phasing out
> bad practices
> and phasing in good practices soon.  CAA for e-mail certificates is
> definitely worth
> considering as part of that process.
>
>
>
> Isn't this an IETF issue? Shouldn't those who issue e-mail certificates
> begin looking at the level of authentication provided for domains today?
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@
> lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: question about DNS CAA and S/MIME certificates

[Tim Hollebeek via dev-security-policy]

Normally I’d agree that IETF cannot and should not be a blocker for action at 
Mozilla and/or CABF, but based on our experience with CAA for web certificates, 
I would encourage people to get in their time machines and go back two to three 
years, and listen to Tim standing up and saying “I like CAA for the Web PKI, 
but what have we not thought of?”

 

-Tim

 

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.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 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

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 effect on July 3rd, I'm cautiously 
optimistic
we can start writing requirements for e-mail certificates and phasing out bad 
practices
and phasing in good practices soon.  CAA for e-mail certificates is definitely 
worth
considering as part of that process.



Isn't this an IETF issue? Shouldn't those who issue e-mail certificates begin 
looking at the level of authentication provided for domains today?


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> 
https://lists.mozilla.org/listinfo/dev-security-policy

 



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

[Ryan Sleevi via dev-security-policy]

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
> 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 effect on July 3rd, I'm cautiously
> optimistic
> we can start writing requirements for e-mail certificates and phasing out
> bad practices
> and phasing in good practices soon.  CAA for e-mail certificates is
> definitely worth
> considering as part of that process.
>
>
>
> Isn't this an IETF issue? Shouldn't those who issue e-mail certificates
> begin looking at the level of authentication provided for domains today?
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: question about DNS CAA and S/MIME certificates

[Tim Hollebeek via dev-security-policy]

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 effect on July 3rd, I'm cautiously 
optimistic
we can start writing requirements for e-mail certificates and phasing out bad 
practices
and phasing in good practices soon.  CAA for e-mail certificates is definitely 
worth
considering as part of that process.

 

Isn't this an IETF issue? Shouldn't those who issue e-mail certificates begin 
looking at the level of authentication provided for domains today?



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

[Pedro Fuentes via dev-security-policy]

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 policies should be for email
> certificate issuance.
> 
> -Tim

Maybe I'd add to the equation too that sometimes end-users can't easily choose 
which CA can use in a certain jurisdiction or user community.

I will subscribe the statement above from Neil: "Please note: I’m not opposed 
to CAA stipulations applying to S/MIME. I would just want all participants in 
the PKI world to know what their statements mean and how far they reach. "
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: question about DNS CAA and S/MIME certificates

[Tim Hollebeek via dev-security-policy]

> 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 CA that values "# of right things done" more
highly than "# of certificates issued".  Actually, I can think of two or 
three.
There are probably more.

> Yes, it means that introducing CAA restrictions for
> S/MIME necessarily means there will need to be a way to distinguish these
> cases, so that an organization could restrict e-mail vs HTTPS - so CAs that 
> wish
> to issue S/MIME should start working on these.

Right.  CAA-bis is a pre-requisite here.

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 policies should be for email
certificate issuance.

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

[Jakob Bohm via dev-security-policy]

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 in line with reality.

For example, if anti-spam systems applied per-account algorithms, then
there's an incentive for spammers to add themselves to the list. This is
demonstrable by some CAs using rate limiting at the PSL boundary, causing a
surge in additions to bypass those rate limits - similarly for various
browser security mechanisms.



I was not aware that the domain PSL allowed random self-addition without
checks, and thus related abuses.  The hypothetical mail PDL would be
based on external observation and confirmation, not self-declaration, as
true PDL entries (3rd party e-mail hosts) are in a partially adversarial
role to their (paying) users.


Regarding the domain holder acting as behalf as the user - it's absolutely
true they can. The position advocated is like suggesting that 3.2.2.4.6 is
more secure than 3.2.2.4.2/.3 - the domain holder has primacy over the
website operator, and the postmaster has primacy over individual mailboxes.



That's arguing the conclusion.  The question is what the hierarchy of
supremacy should be for e-mail, given that e-mail is a different
landscape than website hosting.  And I am arguing that the correct
answer depends heavily on the nature of the e-mail system involved.

A company postmaster has obvious supremacy over company e-mail accounts.

But a common carrier ISP postmaster should not have supremacy over their
users.


On Mon, May 14, 2018 at 12:10 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


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 public suffix list for
domain delegations):

1. E-mails from these domains are not presumed to represent the opinion
   of the domain holder in various contexts (including validation of TLS
   certs against non-reserved e-mail addresses).

2. Anti-spam systems could apply a more per-account algorithm for
   computing reputation scores.

3. S/MIME certificate issuance does not assume the domain holder can
   act on behalf of the e-mail users.  Thus validation with
   postmas...@example.net would not be valid for joesh...@example.net,
   but on the other hand CAA records for example.net would not apply
   to S/MIME (both if example.net was on the public e-mail domain list).


On 14/05/2018 17:48, Neil Dunbar 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 make the assertion “All of our web
certificates should come from DigiCert”, are they aware that they are also
making the statement “And all of our user mail accounts should only be
granted S/MIME certificates from DigiCert too”.

Perhaps they are, perhaps not, but I’m willing to bet that a fair number
of Yahoo accounts have S/MIME certificates not issued by DigiCert - a shift
to CAA-S/MIME enforcement could cause some unwelcome disruption to Yahoo’s
customers.

Please note: I’m not opposed to CAA stipulations applying to S/MIME. I
would just want all participants in the PKI world to know what their
statements mean and how far they reach.

Since the syntax of CAA is extensible, perhaps ‘issue’ could indeed be
restricted to TLS certificates, and a newer tag ‘issueall’ be taken to mean
‘covering all possible forms of certificates’?

Just a thought,

Neil

On 14 May 2018, at 08:39, Ryan Sleevi via dev-security-policy <

dev-security-policy@lists.mozilla.org> wrote:

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 wishes to restrict some types of certificates (e.g.
HTTPS) while allow others (e.g. S/MIME), this could be accomplished
through
additional expressions within the CAA syntax.

However, it would be a long-lasting, and tragic mistake if CAA was
presumed
to 'only' apply to HTTPS - because it would make the same mistake of
nameConstraints - namely, everything that is not expressly listed as
permitted/restricted is implicitly permitted - rather than doing what
security practitioners have long known is the safe and secure base -
forbid
unless expressly permitted (default-deny).

In terms of order of concerns and constituents, the domain holders needs
and security goals outweigh those of the notion of users 'owning' an
email
address.

On Mon, May 14, 2018 at 3:45 AM, Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

Just 

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

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 think
> it would be irresponsible to apply it to e-mail certificates right now
> without carefully
> considering the consequences.
>
> With CABF governance reform coming into effect on July 3rd, I'm cautiously
> optimistic
> we can start writing requirements for e-mail certificates and phasing out
> bad practices
> and phasing in good practices soon.  CAA for e-mail certificates is
> definitely worth
> considering as part of that process.
>

Isn't this an IETF issue? Shouldn't those who issue e-mail certificates
begin looking at the level of authentication provided for domains today?


>
> Slightly higher priority is making sure authenticated encryption modes are
> used with
> S/MIME, so people can't play silly games with CBC and harvested
> ciphertexts.
> Everything really needs to start transitioning away from CBC ... but I
> digress.
>

Indeed, it would be extremely unfortunate if the CABF tried to prioritize
the encryption modes over reliable certificate authentication, considering
that the encryption modes are not related to the certificates themselves.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

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 anti-spam systems applied per-account algorithms, then
there's an incentive for spammers to add themselves to the list. This is
demonstrable by some CAs using rate limiting at the PSL boundary, causing a
surge in additions to bypass those rate limits - similarly for various
browser security mechanisms.

Regarding the domain holder acting as behalf as the user - it's absolutely
true they can. The position advocated is like suggesting that 3.2.2.4.6 is
more secure than 3.2.2.4.2/.3 - the domain holder has primacy over the
website operator, and the postmaster has primacy over individual mailboxes.

On Mon, May 14, 2018 at 12:10 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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 public suffix list for
> domain delegations):
>
> 1. E-mails from these domains are not presumed to represent the opinion
>   of the domain holder in various contexts (including validation of TLS
>   certs against non-reserved e-mail addresses).
>
> 2. Anti-spam systems could apply a more per-account algorithm for
>   computing reputation scores.
>
> 3. S/MIME certificate issuance does not assume the domain holder can
>   act on behalf of the e-mail users.  Thus validation with
>   postmas...@example.net would not be valid for joesh...@example.net,
>   but on the other hand CAA records for example.net would not apply
>   to S/MIME (both if example.net was on the public e-mail domain list).
>
>
> On 14/05/2018 17:48, Neil Dunbar 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 make the assertion “All of our web
>> certificates should come from DigiCert”, are they aware that they are also
>> making the statement “And all of our user mail accounts should only be
>> granted S/MIME certificates from DigiCert too”.
>>
>> Perhaps they are, perhaps not, but I’m willing to bet that a fair number
>> of Yahoo accounts have S/MIME certificates not issued by DigiCert - a shift
>> to CAA-S/MIME enforcement could cause some unwelcome disruption to Yahoo’s
>> customers.
>>
>> Please note: I’m not opposed to CAA stipulations applying to S/MIME. I
>> would just want all participants in the PKI world to know what their
>> statements mean and how far they reach.
>>
>> Since the syntax of CAA is extensible, perhaps ‘issue’ could indeed be
>> restricted to TLS certificates, and a newer tag ‘issueall’ be taken to mean
>> ‘covering all possible forms of certificates’?
>>
>> Just a thought,
>>
>> Neil
>>
>> On 14 May 2018, at 08:39, Ryan Sleevi via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org> wrote:
>>>
>>> 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 wishes to restrict some types of certificates (e.g.
>>> HTTPS) while allow others (e.g. S/MIME), this could be accomplished
>>> through
>>> additional expressions within the CAA syntax.
>>>
>>> However, it would be a long-lasting, and tragic mistake if CAA was
>>> presumed
>>> to 'only' apply to HTTPS - because it would make the same mistake of
>>> nameConstraints - namely, everything that is not expressly listed as
>>> permitted/restricted is implicitly permitted - rather than doing what
>>> security practitioners have long known is the safe and secure base -
>>> forbid
>>> unless expressly permitted (default-deny).
>>>
>>> In terms of order of concerns and constituents, the domain holders needs
>>> and security goals outweigh those of the notion of users 'owning' an
>>> email
>>> address.
>>>
>>> On Mon, May 14, 2018 at 3:45 AM, Pedro Fuentes via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org> 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.

 El sábado, 12 de mayo de 2018, 2:30:58 (UTC+2), Wayne Thayer  escribió:

> 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 

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

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 make the assertion “All of our web
> certificates should come from DigiCert”, are they aware that they are also
> making the statement “And all of our user mail accounts should only be
> granted S/MIME certificates from DigiCert too”.
>
> Perhaps they are, perhaps not, but I’m willing to bet that a fair number
> of Yahoo accounts have S/MIME certificates not issued by DigiCert - a shift
> to CAA-S/MIME enforcement could cause some unwelcome disruption to Yahoo’s
> customers.
>

Sure, but Yahoo still remains the authority as to what the localpart of the
mailbox means - and thus absolutely should have that control over issuance,
and should be treated as such.


> Please note: I’m not opposed to CAA stipulations applying to S/MIME. I
> would just want all participants in the PKI world to know what their
> statements mean and how far they reach.
>
> Since the syntax of CAA is extensible, perhaps ‘issue’ could indeed be
> restricted to TLS certificates, and a newer tag ‘issueall’ be taken to mean
> ‘covering all possible forms of certificates’?
>

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. This is the same problem as introducing new forms of
certificate validation methods - if it leaves insecure someone who has
taken steps to secure things, then it's making things worse.

That's why a solution to opt-out, rather than opt-in, is the right approach.

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. Yes, it means that introducing CAA
restrictions for S/MIME necessarily means there will need to be a way to
distinguish these cases, so that an organization could restrict e-mail vs
HTTPS - so CAs that wish to issue S/MIME should start working on these.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: question about DNS CAA and S/MIME certificates

[Tim Hollebeek via dev-security-policy]

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.

With CABF governance reform coming into effect on July 3rd, I'm cautiously 
optimistic
we can start writing requirements for e-mail certificates and phasing out bad 
practices
and phasing in good practices soon.  CAA for e-mail certificates is definitely 
worth
considering as part of that process.

Slightly higher priority is making sure authenticated encryption modes are used 
with
S/MIME, so people can't play silly games with CBC and harvested ciphertexts.
Everything really needs to start transitioning away from CBC ... but I digress.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Ryan
> Sleevi via dev-security-policy
> Sent: Monday, May 14, 2018 11:39 AM
> To: Pedro Fuentes <pfuente...@gmail.com>
> Cc: mozilla-dev-security-policy 
> <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 wishes to restrict some types of certificates (e.g.
> HTTPS) while allow others (e.g. S/MIME), this could be accomplished through
> additional expressions within the CAA syntax.
> 
> However, it would be a long-lasting, and tragic mistake if CAA was presumed to
> 'only' apply to HTTPS - because it would make the same mistake of
> nameConstraints - namely, everything that is not expressly listed as
> permitted/restricted is implicitly permitted - rather than doing what security
> practitioners have long known is the safe and secure base - forbid unless
> expressly permitted (default-deny).
> 
> In terms of order of concerns and constituents, the domain holders needs and
> security goals outweigh those of the notion of users 'owning' an email 
> address.
> 
> On Mon, May 14, 2018 at 3:45 AM, Pedro Fuentes via dev-security-policy < dev-
> security-pol...@lists.mozilla.org> 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.
> >
> > El sábado, 12 de mayo de 2018, 2:30:58 (UTC+2), Wayne Thayer  escribió:
> > > 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 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 client certificates when the email address is for
> > > > > a
> > domain
> > > > > that already has a valid CAA policy published in DNS?
> > > > >
> > > > >
> > > > > RFC 6844 doesn't seem to make any distinction between server and
> > S/MIME
> > > > > client certificates, it combines them together by referring to
> > > > certificates
> > > > > "for that domain" as a whole.
> > > > >
> > > > >
> > > > > i tested this last night - i obtained an email certificate from
> > > > > one
> > of
> > > > the
> > > > > CAs participating here (not for this exact address though) and
> > > > > it was happily issued even if CAA records authenticated by
> > > > > DNSSEC do not
> > allow
> > > > > their CA to issue for this domain.
> > > > >
> > > > > Now, this is technically not a mis-issuance because it was a
> > > > > proper email-validated address and their CPS says that CAA is
> > > > > only checked
> &g

Re: question about DNS CAA and S/MIME certificates

[Jakob Bohm via dev-security-policy]

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 public suffix list 
for domain delegations):


1. E-mails from these domains are not presumed to represent the opinion
  of the domain holder in various contexts (including validation of TLS
  certs against non-reserved e-mail addresses).

2. Anti-spam systems could apply a more per-account algorithm for
  computing reputation scores.

3. S/MIME certificate issuance does not assume the domain holder can
  act on behalf of the e-mail users.  Thus validation with
  postmas...@example.net would not be valid for joesh...@example.net,
  but on the other hand CAA records for example.net would not apply
  to S/MIME (both if example.net was on the public e-mail domain list).


On 14/05/2018 17:48, Neil Dunbar 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 make the assertion “All of our web 
certificates should come from DigiCert”, are they aware that they are also 
making the statement “And all of our user mail accounts should only be granted 
S/MIME certificates from DigiCert too”.

Perhaps they are, perhaps not, but I’m willing to bet that a fair number of 
Yahoo accounts have S/MIME certificates not issued by DigiCert - a shift to 
CAA-S/MIME enforcement could cause some unwelcome disruption to Yahoo’s 
customers.

Please note: I’m not opposed to CAA stipulations applying to S/MIME. I would 
just want all participants in the PKI world to know what their statements mean 
and how far they reach.

Since the syntax of CAA is extensible, perhaps ‘issue’ could indeed be 
restricted to TLS certificates, and a newer tag ‘issueall’ be taken to mean 
‘covering all possible forms of certificates’?

Just a thought,

Neil


On 14 May 2018, at 08:39, Ryan Sleevi via dev-security-policy 
 wrote:

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 wishes to restrict some types of certificates (e.g.
HTTPS) while allow others (e.g. S/MIME), this could be accomplished through
additional expressions within the CAA syntax.

However, it would be a long-lasting, and tragic mistake if CAA was presumed
to 'only' apply to HTTPS - because it would make the same mistake of
nameConstraints - namely, everything that is not expressly listed as
permitted/restricted is implicitly permitted - rather than doing what
security practitioners have long known is the safe and secure base - forbid
unless expressly permitted (default-deny).

In terms of order of concerns and constituents, the domain holders needs
and security goals outweigh those of the notion of users 'owning' an email
address.

On Mon, May 14, 2018 at 3:45 AM, Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> 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.

El sábado, 12 de mayo de 2018, 2:30:58 (UTC+2), Wayne Thayer  escribió:

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 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 client certificates when the email address is for a

domain

that already has a valid CAA policy published in DNS?


RFC 6844 doesn't seem to make any distinction between server and

S/MIME

client certificates, it combines them together by referring to

certificates

"for that domain" as a whole.


i tested this last night - i obtained an email certificate from one

of

the

CAs participating here (not for this exact address though) and it was
happily issued even if CAA records authenticated by DNSSEC do not

allow

their CA to issue for this domain.

Now, this is technically not a mis-issuance because it was a proper
email-validated address and their CPS says that CAA is only checked

for

server-type certificates. It doesn't say anything about CAA

validation

for

such client certificates.

I got in touch with them and they seemed equally surprised by such
intended use case for CAA, so my second question is: is anyone

actually

Re: question about DNS CAA and S/MIME certificates

[Neil Dunbar via dev-security-policy]

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 statement “And all of our user mail accounts should only be granted 
S/MIME certificates from DigiCert too”.

Perhaps they are, perhaps not, but I’m willing to bet that a fair number of 
Yahoo accounts have S/MIME certificates not issued by DigiCert - a shift to 
CAA-S/MIME enforcement could cause some unwelcome disruption to Yahoo’s 
customers.

Please note: I’m not opposed to CAA stipulations applying to S/MIME. I would 
just want all participants in the PKI world to know what their statements mean 
and how far they reach.

Since the syntax of CAA is extensible, perhaps ‘issue’ could indeed be 
restricted to TLS certificates, and a newer tag ‘issueall’ be taken to mean 
‘covering all possible forms of certificates’?

Just a thought,

Neil

> On 14 May 2018, at 08:39, Ryan Sleevi via dev-security-policy 
>  wrote:
> 
> 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 wishes to restrict some types of certificates (e.g.
> HTTPS) while allow others (e.g. S/MIME), this could be accomplished through
> additional expressions within the CAA syntax.
> 
> However, it would be a long-lasting, and tragic mistake if CAA was presumed
> to 'only' apply to HTTPS - because it would make the same mistake of
> nameConstraints - namely, everything that is not expressly listed as
> permitted/restricted is implicitly permitted - rather than doing what
> security practitioners have long known is the safe and secure base - forbid
> unless expressly permitted (default-deny).
> 
> In terms of order of concerns and constituents, the domain holders needs
> and security goals outweigh those of the notion of users 'owning' an email
> address.
> 
> On Mon, May 14, 2018 at 3:45 AM, Pedro Fuentes via dev-security-policy <
> dev-security-policy@lists.mozilla.org> 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.
>> 
>> El sábado, 12 de mayo de 2018, 2:30:58 (UTC+2), Wayne Thayer  escribió:
>>> 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 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 client certificates when the email address is for a
>> domain
> that already has a valid CAA policy published in DNS?
> 
> 
> RFC 6844 doesn't seem to make any distinction between server and
>> S/MIME
> client certificates, it combines them together by referring to
 certificates
> "for that domain" as a whole.
> 
> 
> i tested this last night - i obtained an email certificate from one
>> of
 the
> CAs participating here (not for this exact address though) and it was
> happily issued even if CAA records authenticated by DNSSEC do not
>> allow
> their CA to issue for this domain.
> 
> Now, this is technically not a mis-issuance because it was a proper
> email-validated address and their CPS says that CAA is only checked
>> for
> server-type certificates. It doesn't say anything about CAA
>> validation
 for
> such client certificates.
> 
> I got in touch with them and they seemed equally surprised by such
> intended use case for CAA, so my second question is: is anyone
>> actually
> checking CAA records for client certificates where an email address
>> is
> included in the certificate subject info and the EKU includes Secure
 Email?
> 
> 
> Or is CAA usually checked only for server-type certificates, even if
>> RFC
> 6844 refers to certificates "for that domain" as a whole?
> 
 
 CAs are generally only checking CAA when they're required to in order
>> to be
 trusted.
 
 Right now, CAs are only required to check CAA for server-type
>> certificates
 (by virtue of the Baseline Requirements Section 3.2.2.8).
 CAs are not presently being required to check CAA for e-mail. They
>> can, but
 they are required to do it, so they are unlikely to do it.

Re: question about DNS CAA and S/MIME certificates

[Adrian R. via dev-security-policy]

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 is a problem with eIDAS certificates not with CAA - eIDAS 
certificates identify the person, and (assuming that email validation is even 
performed) that they have temporary control of an email address, but if the 
email is on a corporate domain this does nothing to address the issuance 
against policies of that company.


>From this point of view, an email address should not even be part of an eIDAS 
>certificate (and thus CAA would not apply), but an email is usually included 
>for convenience. (why?)

This is because the eIDAS regulation 910/2014 does not contain the words 
"e-mail", "email" or "message" at all. (!!!)
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32014R0910

As it is now, it is even possible to use and 'verify control' of anonymous 
disposable email services (e.g. mailinator) for an eIDAS certificate because 
the CA TSP doesn't care about the email or domain policies.


As is noted on the GitHub issue, many providers of free email services have 
been careful to avoid deploying CAA for the domain names used by their email 
users, but some have deployed restrictive CAA policies that might affect their 
users if CAA checking is done (e.g. Yahoo, Yandex).



Adrian R.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Pedro Fuentes via dev-security-policy]

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 (UTC+2), Wayne Thayer  escribió:
> 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 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 client certificates when the email address is for a domain
> > > that already has a valid CAA policy published in DNS?
> > >
> > >
> > > RFC 6844 doesn't seem to make any distinction between server and S/MIME
> > > client certificates, it combines them together by referring to
> > certificates
> > > "for that domain" as a whole.
> > >
> > >
> > > i tested this last night - i obtained an email certificate from one of
> > the
> > > CAs participating here (not for this exact address though) and it was
> > > happily issued even if CAA records authenticated by DNSSEC do not allow
> > > their CA to issue for this domain.
> > >
> > > Now, this is technically not a mis-issuance because it was a proper
> > > email-validated address and their CPS says that CAA is only checked for
> > > server-type certificates. It doesn't say anything about CAA validation
> > for
> > > such client certificates.
> > >
> > > I got in touch with them and they seemed equally surprised by such
> > > intended use case for CAA, so my second question is: is anyone actually
> > > checking CAA records for client certificates where an email address is
> > > included in the certificate subject info and the EKU includes Secure
> > Email?
> > >
> > >
> > > Or is CAA usually checked only for server-type certificates, even if RFC
> > > 6844 refers to certificates "for that domain" as a whole?
> > >
> >
> > CAs are generally only checking CAA when they're required to in order to be
> > trusted.
> >
> > Right now, CAs are only required to check CAA for server-type certificates
> > (by virtue of the Baseline Requirements Section 3.2.2.8).
> > CAs are not presently being required to check CAA for e-mail. They can, but
> > they are required to do it, so they are unlikely to do it.
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Wayne Thayer via dev-security-policy]

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 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 client certificates when the email address is for a domain
> > that already has a valid CAA policy published in DNS?
> >
> >
> > RFC 6844 doesn't seem to make any distinction between server and S/MIME
> > client certificates, it combines them together by referring to
> certificates
> > "for that domain" as a whole.
> >
> >
> > i tested this last night - i obtained an email certificate from one of
> the
> > CAs participating here (not for this exact address though) and it was
> > happily issued even if CAA records authenticated by DNSSEC do not allow
> > their CA to issue for this domain.
> >
> > Now, this is technically not a mis-issuance because it was a proper
> > email-validated address and their CPS says that CAA is only checked for
> > server-type certificates. It doesn't say anything about CAA validation
> for
> > such client certificates.
> >
> > I got in touch with them and they seemed equally surprised by such
> > intended use case for CAA, so my second question is: is anyone actually
> > checking CAA records for client certificates where an email address is
> > included in the certificate subject info and the EKU includes Secure
> Email?
> >
> >
> > Or is CAA usually checked only for server-type certificates, even if RFC
> > 6844 refers to certificates "for that domain" as a whole?
> >
>
> CAs are generally only checking CAA when they're required to in order to be
> trusted.
>
> Right now, CAs are only required to check CAA for server-type certificates
> (by virtue of the Baseline Requirements Section 3.2.2.8).
> CAs are not presently being required to check CAA for e-mail. They can, but
> they are required to do it, so they are unlikely to do it.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

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 client certificates when the email address is for a domain
> that already has a valid CAA policy published in DNS?
>
>
> RFC 6844 doesn't seem to make any distinction between server and S/MIME
> client certificates, it combines them together by referring to certificates
> "for that domain" as a whole.
>
>
> i tested this last night - i obtained an email certificate from one of the
> CAs participating here (not for this exact address though) and it was
> happily issued even if CAA records authenticated by DNSSEC do not allow
> their CA to issue for this domain.
>
> Now, this is technically not a mis-issuance because it was a proper
> email-validated address and their CPS says that CAA is only checked for
> server-type certificates. It doesn't say anything about CAA validation for
> such client certificates.
>
> I got in touch with them and they seemed equally surprised by such
> intended use case for CAA, so my second question is: is anyone actually
> checking CAA records for client certificates where an email address is
> included in the certificate subject info and the EKU includes Secure Email?
>
>
> Or is CAA usually checked only for server-type certificates, even if RFC
> 6844 refers to certificates "for that domain" as a whole?
>

CAs are generally only checking CAA when they're required to in order to be
trusted.

Right now, CAs are only required to check CAA for server-type certificates
(by virtue of the Baseline Requirements Section 3.2.2.8).
CAs are not presently being required to check CAA for e-mail. They can, but
they are required to do it, so they are unlikely to do it.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy