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.ho...@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:
ry...@sleevi.com]
> *Sent:* Monday, May 14, 2018 11:55 PM
>
> *To:* Tim Hollebeek <
tim.ho...@digicert.com>
> *Cc:*
ry...@sleevi.com; Pedro Fuentes <
pfuen...@gmail.com>;
> mozilla-dev-security-policy <
mozilla-dev-s...@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-secur...@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:
ry...@sleevi.com]
> Sent: Monday, May 14, 2018 8:24 PM
> To: Tim Hollebeek <
tim.ho...@digicert.com>
> Cc:
ry...@sleevi.com; Pedro Fuentes <
pfuen...@gmail.com>;
> mozilla-dev-security-policy <
mozilla-dev-s...@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-secur...@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