Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Technically Constrained Sub-CAs

508 views
Skip to first unread message

Gervase Markham

unread,
Nov 14, 2016, 6:47:05 AM11/14/16
to mozilla-dev-s...@lists.mozilla.org
Hi all,

RFC 6962bis (the new CT RFC) allows certs below technically-constrained
sub-CAs (TCSCs) to be exempt from CT. This is to allow name privacy.
TCSCs themselves are also currently exempt from disclosure to Mozilla in
the Common CA Database.

If this is the only privacy mechanism available for 6962bis, I suspect
we will see a lot more TCSCs about, particularly if CAs figure out ways
to mint them at scale within the letter of the BRs and other requirements.

CT is getting to be very useful as a way of surveying the certificate
ecosystem. This is helpful to assess the impact of proposed policy
changes or positions, e.g. "how many certs don't have an EKU", or "how
many certs use a certain type of crypto". If certs under TCSCs are
exempt and this becomes popular, CT would become less useful for that.

One possible answer is just to say: "Mozilla will not accept 'but we
have a lot of certs under TCSCs which will be affected by this' as a
valid reason not to do something. In other words, if you hide stuff and
it breaks, you get to keep both pieces. But in practice, such a line
might not hold.

Thoughts and suggestions?

Gerv

Peter Bowen

unread,
Nov 14, 2016, 9:00:35 AM11/14/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
On Mon, Nov 14, 2016 at 3:46 AM, Gervase Markham <ge...@mozilla.org> wrote:
>
> If this is the only privacy mechanism available for 6962bis, I suspect
> we will see a lot more TCSCs about, particularly if CAs figure out ways
> to mint them at scale within the letter of the BRs and other requirements.

It is very easy to mint TCSCs at scale without violating the letter or
the spirit of the BRs and other requirements.

> CT is getting to be very useful as a way of surveying the certificate
> ecosystem. This is helpful to assess the impact of proposed policy
> changes or positions, e.g. "how many certs don't have an EKU", or "how
> many certs use a certain type of crypto". If certs under TCSCs are
> exempt and this becomes popular, CT would become less useful for that.
>
> One possible answer is just to say: "Mozilla will not accept 'but we
> have a lot of certs under TCSCs which will be affected by this' as a
> valid reason not to do something. In other words, if you hide stuff and
> it breaks, you get to keep both pieces. But in practice, such a line
> might not hold.

I think this is the right answer. Yes, CT has helped provide a better
view into galaxy of CAs that is WebPKI, that was not its stated
purpose. CT was created to help domain registrants have visibility
into what is issued for their domain names. If domain holders want to
keep their certificates semi-private, then they need to be aware that
security is a moving target and their input on data-driven decisions
may be diminished.

Thanks,
Peter

Kurt Roeckx

unread,
Nov 14, 2016, 9:04:07 AM11/14/16
to mozilla-dev-s...@lists.mozilla.org
Before there was CT, we already made decisions based on those
certificates that we actually get to see based on various ways to see
them. It's also not because they won't be required to be in CT they
won't end up in CT, either because they really don't have a reason to
hide them or that other people that saw the certificate added them.


Kurt

Gervase Markham

unread,
Nov 14, 2016, 10:14:57 AM11/14/16
to Peter Bowen
On 14/11/16 14:00, Peter Bowen wrote:
> It is very easy to mint TCSCs at scale without violating the letter or
> the spirit of the BRs and other requirements.

I guess I didn't mean to imply that it was hard or easy, only that it
hasn't been done so far. But I did wonder about auditors witnessing key
ceremonies - would that be a necessary component? Does that make things
more complicated?

> I think this is the right answer.

Well, one can always say this but, policies aside, the impact of a
change is measured by the amount of breakage it actually causes, and not
by the amount that you can predict in advance.

That doesn't mean it's not the right answer, it might just mean that our
ability to predict the impact of changes is now much better but still
less than perfect, and we have to accept that.

> Yes, CT has helped provide a better
> view into galaxy of CAs that is WebPKI, that was not its stated
> purpose. CT was created to help domain registrants have visibility
> into what is issued for their domain names. If domain holders want to
> keep their certificates semi-private, then they need to be aware that
> security is a moving target and their input on data-driven decisions
> may be diminished.

(And that because anyone can submit a cert to CT, this privacy may not
be as total as they would like anyway.)

Gerv

Peter Bowen

unread,
Nov 14, 2016, 10:31:56 AM11/14/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
On Mon, Nov 14, 2016 at 7:14 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 14/11/16 14:00, Peter Bowen wrote:
>> It is very easy to mint TCSCs at scale without violating the letter or
>> the spirit of the BRs and other requirements.
>
> I guess I didn't mean to imply that it was hard or easy, only that it
> hasn't been done so far. But I did wonder about auditors witnessing key
> ceremonies - would that be a necessary component? Does that make things
> more complicated?

1) Auditors are not required to witness key generation ceremonies for
non-Root CA keys when the new CA is operated by the same entity as the
parent CA.
2) There is no requirement that the binding between CA distinguished name
and key pair occur during the key generation ceremony
3) There is no requirement that each CA have a unique key pair.

Combine all three of these and there are multiple paths to easy TCSC
creation.

Gervase Markham

unread,
Nov 14, 2016, 10:48:37 AM11/14/16
to Peter Bowen
On 14/11/16 15:31, Peter Bowen wrote:
> 1) Auditors are not required to witness key generation ceremonies for
> non-Root CA keys when the new CA is operated by the same entity as the
> parent CA.
> 2) There is no requirement that the binding between CA distinguished name
> and key pair occur during the key generation ceremony
> 3) There is no requirement that each CA have a unique key pair.
>
> Combine all three of these and there are multiple paths to easy TCSC
> creation.

OK, makes sense, thank you.

Does anyone think that any of these 3 lack-of-requirements presents a
risk? I can't see one immediately but it's worth asking the question.

Gerv

Eric Mill

unread,
Nov 14, 2016, 11:02:12 AM11/14/16
to Peter Bowen, mozilla-dev-s...@lists.mozilla.org, Gervase Markham
On Mon, Nov 14, 2016 at 9:00 AM, Peter Bowen <pzb...@gmail.com> wrote:

> On Mon, Nov 14, 2016 at 3:46 AM, Gervase Markham <ge...@mozilla.org> wrote:
> >
> > One possible answer is just to say: "Mozilla will not accept 'but we
> > have a lot of certs under TCSCs which will be affected by this' as a
> > valid reason not to do something. In other words, if you hide stuff and
> > it breaks, you get to keep both pieces. But in practice, such a line
> > might not hold.
>
> I think this is the right answer. Yes, CT has helped provide a better
> view into galaxy of CAs that is WebPKI, that was not its stated
> purpose. CT was created to help domain registrants have visibility
> into what is issued for their domain names.


CT's original purpose is useful to know, but not as important as what
benefit Mozilla wishes to gain from CT as a root program and browser.

Right now, there aren't a lot of TCSCs, and so the impact to ecosystem
visibility is small. Once they're made easy to mint (which seems like a
good thing) an exemption from CT could, over time, drastically impact the
ecosystem visibility benefits that CT has demonstrated (which seems like a
bad thing).

Chrome's been really clear that, CT spec or not, the use of a TCSC isn't
enough to get out of SCT requirements. At least until the community does
more work at identifying name redaction use cases and how to best address
them over the next few months, I would recommend Mozilla stick with
Chrome's position.

-- Eric


> If domain holders want to
> keep their certificates semi-private, then they need to be aware that
> security is a moving target and their input on data-driven decisions
> may be diminished.
>
> Thanks,
> Peter
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



--
konklone.com | @konklone <https://twitter.com/konklone>

Jakob Bohm

unread,
Nov 14, 2016, 11:51:49 AM11/14/16
to mozilla-dev-s...@lists.mozilla.org
#3 would be in apparent violation of the BR applicability document you
proposed in another thread. Alternative would be to pre-create
resellable TCSC key pairs in advance during auditor visits, then throw
away unsold ones at the next such ceremony.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Jakob Bohm

unread,
Nov 14, 2016, 11:57:20 AM11/14/16
to mozilla-dev-s...@lists.mozilla.org
On 14/11/2016 12:46, Gervase Markham wrote:
> Hi all,
>
> RFC 6962bis (the new CT RFC) allows certs below technically-constrained
> sub-CAs (TCSCs) to be exempt from CT. This is to allow name privacy.
> TCSCs themselves are also currently exempt from disclosure to Mozilla in
> the Common CA Database.
>
> If this is the only privacy mechanism available for 6962bis, I suspect
> we will see a lot more TCSCs about, particularly if CAs figure out ways
> to mint them at scale within the letter of the BRs and other requirements.
>

If this is the only privacy mechanism in 6962bis, I would suggest that
everyone not employed by either Google or another mass-monitoring
service block its adoption on human rights grounds and on the basis of
being a mass-attack on network security.

> CT is getting to be very useful as a way of surveying the certificate
> ecosystem. This is helpful to assess the impact of proposed policy
> changes or positions, e.g. "how many certs don't have an EKU", or "how
> many certs use a certain type of crypto". If certs under TCSCs are
> exempt and this becomes popular, CT would become less useful for that.
>
> One possible answer is just to say: "Mozilla will not accept 'but we
> have a lot of certs under TCSCs which will be affected by this' as a
> valid reason not to do something. In other words, if you hide stuff and
> it breaks, you get to keep both pieces. But in practice, such a line
> might not hold.
>
> Thoughts and suggestions?
>
> Gerv
>


Peter Bowen

unread,
Nov 14, 2016, 12:45:55 PM11/14/16
to Jakob Bohm, mozilla-dev-s...@lists.mozilla.org
On Mon, Nov 14, 2016 at 8:51 AM, Jakob Bohm <jb-mo...@wisemo.com> wrote:
> On 14/11/2016 16:31, Peter Bowen wrote:
>>
> #3 would be in apparent violation of the BR applicability document you
> proposed in another thread. Alternative would be to pre-create
> resellable TCSC key pairs in advance during auditor visits, then throw
> away unsold ones at the next such ceremony.

#3 doesn't violate the doc I proposed. The callout is that a non-Root
CA may not share a key pair with a Root CA and that a single CA may
not have multiple key pairs (e.g. don't attempt key rotation without
changing the name). It is completely permissible to have multiple CAs
with the same key pair as long as all have the same operator.

I think you are pointing out the need for a diagram.

Thanks,
Peter

Gervase Markham

unread,
Nov 14, 2016, 1:00:18 PM11/14/16
to Jakob Bohm
On 14/11/16 16:56, Jakob Bohm wrote:
> If this is the only privacy mechanism in 6962bis, I would suggest that
> everyone not employed by either Google or another mass-monitoring
> service block its adoption on human rights grounds and on the basis of
> being a mass-attack on network security.

I think you are overstating the in-practice benefits of attempting to
keep your internal hostnames secret.

As a wise person pointed out at CAB Forum, if I wanted to find out lots
of hostnames on Microsoft's internal network, I would just run a network
sniffer at the local Starbucks and look at what DNS requests were made.

Also, wildcards are an additional mechanism by which you can keep the
leftmost part of your hostname private, for subdomains.

Gerv


Jakob Bohm

unread,
Nov 14, 2016, 1:32:10 PM11/14/16
to mozilla-dev-s...@lists.mozilla.org
On 14/11/2016 18:59, Gervase Markham wrote:
> On 14/11/16 16:56, Jakob Bohm wrote:
>> If this is the only privacy mechanism in 6962bis, I would suggest that
>> everyone not employed by either Google or another mass-monitoring
>> service block its adoption on human rights grounds and on the basis of
>> being a mass-attack on network security.
>
> I think you are overstating the in-practice benefits of attempting to
> keep your internal hostnames secret.

There are also the names of non-public e-mail addresses, such as the
e-mail addresses of individuals.

>
> As a wise person pointed out at CAB Forum, if I wanted to find out lots
> of hostnames on Microsoft's internal network, I would just run a network
> sniffer at the local Starbucks and look at what DNS requests were made.
>

But those would only be a specific subset (those used by local area
remote-workers) of internal hostnames from a single company. CT
without privacy gives you all the public-certificate-holding servers of
every company, and organization, world-wide. Without having to travel
to the country of your victim.

Comparison to the reasons for the introduction of NSEC3 DNSSEC records
are highly relevant here.

> Also, wildcards are an additional mechanism by which you can keep the
> leftmost part of your hostname private, for subdomains.
>

But wildcard certs are weaker in terms of security.

Andrew Ayer

unread,
Nov 14, 2016, 1:54:45 PM11/14/16
to Peter Bowen, mozilla-dev-s...@lists.mozilla.org, Gervase Markham
On Mon, 14 Nov 2016 06:00:24 -0800
Peter Bowen <pzb...@gmail.com> wrote:

> > CT is getting to be very useful as a way of surveying the certificate
> > ecosystem. This is helpful to assess the impact of proposed policy
> > changes or positions, e.g. "how many certs don't have an EKU", or "how
> > many certs use a certain type of crypto". If certs under TCSCs are
> > exempt and this becomes popular, CT would become less useful for that.
> >
> > One possible answer is just to say: "Mozilla will not accept 'but we
> > have a lot of certs under TCSCs which will be affected by this' as a
> > valid reason not to do something. In other words, if you hide stuff and
> > it breaks, you get to keep both pieces. But in practice, such a line
> > might not hold.
>
> I think this is the right answer. Yes, CT has helped provide a better
> view into galaxy of CAs that is WebPKI, that was not its stated
> purpose. CT was created to help domain registrants have visibility
> into what is issued for their domain names.

I disagree with your characterization of CT. The first sentences of
RFC6962 say:

"Certificate transparency aims to mitigate the problem of misissued
certificates by providing publicly auditable, append-only, untrusted
logs of all issued certificates. The logs are publicly auditable so
that it is possible for anyone to verify the correctness of each log
and to monitor when new certificates are added to it. The logs do
not themselves prevent misissue, but they ensure that interested
parties (particularly those named in certificates) can detect such
misissuance."

Although issuing a certificate without the authorization of the domain
registrant is the most serious type of misissuance, it is not the only
type. Apart from audits, TCSCs are subject to the Baseline
Requirements, and failure to comply is a type of misissuance that is of
interest to the Internet community, particularly to root store
operators and certificate validation implementers like Mozilla.

In any case, standards can provide unexpected benefits. It would
be self-defeating to discount a benefit just because it wasn't
originally stated as a goal of the standard.

> If domain holders want to keep their certificates semi-private, then
> they need to be aware that security is a moving target and their
> input on data-driven decisions may be diminished.

Unfortunately, domain holders do not act rationally. Just look at all
the domain holders who requested redacted franken-certificates from
Symantec for publicly-accessible websites even when it was immediately
apparent that such certificates do not work in Chrome. Domain holders
would likewise fail to take heed that certificates issued from TCSCs
might stop working at some point in the future, and probably in greater
numbers since the consequences of their actions would be more abstract
and less proximate.

Meanwhile, end users have no say over what certificate a site uses
and just want their browser to work. No browser maker wants to break
sites for users. The rule about ignoring TCSCs when making decisions
will surely be reverted the first time it causes widespread breakage.
Then we'll be back in the same situation we are in now, where the lack
of complete information makes it difficult to make changes that
improve the security and robustness of the Web PKI.

I appreciate the need for domain name privacy, but it must be balanced
against the needs of the public. I find the label redaction approach
in draft-strad-trans-redaction-00 to be more balanced, as it hides only
the minimum amount of information needed to provide domain name privacy.

Regards,
Andrew

Nick Lamb

unread,
Nov 14, 2016, 3:37:44 PM11/14/16
to mozilla-dev-s...@lists.mozilla.org
On Monday, 14 November 2016 16:57:20 UTC, Jakob Bohm wrote:
> If this is the only privacy mechanism in 6962bis, I would suggest that
> everyone not employed by either Google or another mass-monitoring
> service block its adoption on human rights grounds and on the basis of
> being a mass-attack on network security.

Whereas I would say almost the precise opposite, the Web PKI is a _public_ resource, if you don't want your certificates to be examined by the _public_ then you are in the wrong place and need to look into a private CA. Redaction has no place in public CT logs. If a private CA wants to operate redacted logs in which everything is too murky to make any useful conclusions about anything they're welcome to do just that.

Even from this very limited perspective of protecting a subscriber from themselves, redaction falls down badly as I explained in my posts when Chromium mooted what redaction policies should be accepted earlier this year.

The snooping argument amounts to very little. If you were paying attention to CT logs when greatagain.gov was launched, or if you really stare hard at all the new certificates logged for the .gov TLD you will have discovered what Hillary's transition site would have been called. But amid a media saturated with wall-to-wall with US election news, focusing on even the tiniest slivers of new information, nobody even mentioned it. Not because the White House staff have some elite redaction technology that allowed them keep it off the record but because it's just not that interesting.

Rob Stradling

unread,
Nov 14, 2016, 4:30:16 PM11/14/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
[Resending due to nondelivery on two earlier attempts]

On 14/11/16 11:46, Gervase Markham wrote:
> Hi all,
>
> RFC 6962bis (the new CT RFC) allows certs below technically-constrained
> sub-CAs (TCSCs) to be exempt from CT.

6962-bis may or may not still say that after the TRANS meeting in Seoul
tomorrow!

Even if that option remains in 6962-bis, I'm not hopeful (based on
various comments from Ryan Sleevi) that Chrome's future 6962-bis
implementation will allow it.

My preference would be to move that option to
draft-strad-trans-redaction, so that further discussions and edits can
occur (that might make it more palatable to Chrome). However, 6962-bis
has completed Working Group Last Call, so this may well not be possible.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

Ryan Sleevi

unread,
Nov 14, 2016, 11:40:32 PM11/14/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
On Mon, Nov 14, 2016 at 3:46 AM, Gervase Markham <ge...@mozilla.org> wrote:
> If this is the only privacy mechanism available for 6962bis, I suspect
> we will see a lot more TCSCs about, particularly if CAs figure out ways
> to mint them at scale within the letter of the BRs and other requirements.

This is the only privacy mechanism that will be in -bis, it sounds
like. There was not consensus to remove it, since that would force it
to go back through WGLC. Instead, it will likely largely be ignored by
one major CT implementor (Chrome), but will exist in a documented
state that simply documents 'how' you could do it, not whether you
should. That is, the RFC documents technology, *not* policy.

While this is unfortunate, it's pragmatic - it allows 6962-bis to
carry on as-is, without having to restart discussion, even if it
contains technology that is unimplemented and will likely remain
unimplemented indefinitely. That's just SDOs as usual.

I think it'd be useful to resolve the questions I asked on this thread
- https://groups.google.com/d/msg/mozilla.dev.security.policy/ZMUjQ6xHrDA/ySofsF_PAgAJ
- to figure out what Mozilla expects/wants of TCSCs with respect to
the BRs, as that seems like it would significantly affect how you want
CT to play or not play in that role.

As Andrew Ayer points out, currently, CAs are required to ensure TCSCs
comply with the BRs. Non-compliance is misissuance. Does Mozilla share
that view? And is Mozilla willing to surrender the ability to detect
misissuance, in favor of something which clearly doesn't address the
use cases for redaction identified in the CA/Browser Forum and in the
IETF?

Matt Palmer

unread,
Nov 14, 2016, 11:58:38 PM11/14/16
to dev-secur...@lists.mozilla.org
On Mon, Nov 14, 2016 at 06:00:24AM -0800, Peter Bowen wrote:
> into what is issued for their domain names. If domain holders want to
> keep their certificates semi-private, then they need to be aware that
> security is a moving target and their input on data-driven decisions
> may be diminished.

A brief examination of the explanations coming from organisations that have
requested SHA-1 issuance exceptions should provide a solid case study as to
how well *that's* going to work.

- Matt

Matt Palmer

unread,
Nov 15, 2016, 12:28:17 AM11/15/16
to dev-secur...@lists.mozilla.org
On Mon, Nov 14, 2016 at 11:46:28AM +0000, Gervase Markham wrote:
> CT is getting to be very useful as a way of surveying the certificate
> ecosystem. This is helpful to assess the impact of proposed policy
> changes or positions, e.g. "how many certs don't have an EKU", or "how
> many certs use a certain type of crypto". If certs under TCSCs are
> exempt and this becomes popular, CT would become less useful for that.
>
> One possible answer is just to say: "Mozilla will not accept 'but we
> have a lot of certs under TCSCs which will be affected by this' as a
> valid reason not to do something. In other words, if you hide stuff and
> it breaks, you get to keep both pieces. But in practice, such a line
> might not hold.
>
> Thoughts and suggestions?

I don't think TCSCs should be exempted from any CT requirements; as you say,
there is significant value in having a near-complete picture of the state of
the WebPKI. There is extensive evidence that a browser's position that "if
your private stuff breaks, sucks to be you" will *not* stick in the face of
post-change breakage, regardless of how much notice certificate holders and
their issuers are given. Only by knowing what is going on in the WebPKI can
browsers have any hope of not inadvertantly causing problems.

- Matt

Jakob Bohm

unread,
Nov 15, 2016, 4:35:17 AM11/15/16
to mozilla-dev-s...@lists.mozilla.org
On 14/11/2016 21:37, Nick Lamb wrote:
> On Monday, 14 November 2016 16:57:20 UTC, Jakob Bohm wrote:
>> If this is the only privacy mechanism in 6962bis, I would suggest that
>> everyone not employed by either Google or another mass-monitoring
>> service block its adoption on human rights grounds and on the basis of
>> being a mass-attack on network security.
>
> Whereas I would say almost the precise opposite, the Web PKI is a _public_ resource, if you don't want your certificates to be examined by the _public_ then you are in the wrong place and need to look into a private CA. Redaction has no place in public CT logs. If a private CA wants to operate redacted logs in which everything is too murky to make any useful conclusions about anything they're welcome to do just that.
>

Google and the "information wants to be free" crowd want everything
connected to the Internet to be declared public and everything to be
connected to the Internet.

Many others tend to disagree.

The HTTPS-everywhere tendency, including the plans of some people to
completely remove unencrypted HTTP from implementations, makes it
necessary for non-public stuff connected to the Internet to get
Internet-compatible TLS certificates. That happens to be the same as
the WebPKI, thus the need for an ability to get a WebPKI certificate
without announcing your address to every script-kiddie automated
mass-attack tool out there.

> Even from this very limited perspective of protecting a subscriber from themselves, redaction falls down badly as I explained in my posts when Chromium mooted what redaction policies should be accepted earlier this year.
>

Chromium=Google=Peeping Tom.

> The snooping argument amounts to very little. If you were paying attention to CT logs when greatagain.gov was launched, or if you really stare hard at all the new certificates logged for the .gov TLD you will have discovered what Hillary's transition site would have been called. But amid a media saturated with wall-to-wall with US election news, focusing on even the tiniest slivers of new information, nobody even mentioned it. Not because the White House staff have some elite redaction technology that allowed them keep it off the record but because it's just not that interesting.
>

Maybe because that was just too insignificant to shout about, or maybe
because the political journalists are not up to speed on CT yet.

Gervase Markham

unread,
Nov 15, 2016, 10:27:48 AM11/15/16
to ry...@sleevi.com
On 15/11/16 05:39, Ryan Sleevi wrote:
> I think it'd be useful to resolve the questions I asked on this thread
> - https://groups.google.com/d/msg/mozilla.dev.security.policy/ZMUjQ6xHrDA/ySofsF_PAgAJ
> - to figure out what Mozilla expects/wants of TCSCs with respect to
> the BRs, as that seems like it would significantly affect how you want
> CT to play or not play in that role.

I think the answer to that question is that in general, TCSCs need to
adhere to the BRs but there may be some bits we don't need them to
adhere to. We should clarify our policy on this point.

https://github.com/mozilla/pkipolicy/issues/36

> As Andrew Ayer points out, currently, CAs are required to ensure TCSCs
> comply with the BRs. Non-compliance is misissuance. Does Mozilla share
> that view? And is Mozilla willing to surrender the ability to detect
> misissuance, in favor of something which clearly doesn't address the
> use cases for redaction identified in the CA/Browser Forum and in the
> IETF?

I certainly think our view of redaction will be driven by use cases.
AIUI, you are strongly encouraging use cases to be brought to the IETF.
However, if 6962bis is in Last Call, and won't be updated, is the TRANS
group still listening to and accumulating use cases for redaction?

Gerv

Matt Palmer

unread,
Nov 15, 2016, 5:40:30 PM11/15/16
to dev-secur...@lists.mozilla.org
On Tue, Nov 15, 2016 at 04:27:09PM +0100, Gervase Markham wrote:
> I certainly think our view of redaction will be driven by use cases.
> AIUI, you are strongly encouraging use cases to be brought to the IETF.
> However, if 6962bis is in Last Call, and won't be updated, is the TRANS
> group still listening to and accumulating use cases for redaction?

AFAIK, the trans WG isn't shutting down after 6962bis is published. There's
a redaction draft that's gotten some support for being worked on, at least,
so I'd be surprised if plausible use cases for redaction weren't given an
open hearing.

- Matt

Nick Lamb

unread,
Nov 15, 2016, 8:14:09 PM11/15/16
to mozilla-dev-s...@lists.mozilla.org
On Tuesday, 15 November 2016 09:35:17 UTC, Jakob Bohm wrote:
> The HTTPS-everywhere tendency, including the plans of some people to
> completely remove unencrypted HTTP from implementations, makes it
> necessary for non-public stuff connected to the Internet to get
> Internet-compatible TLS certificates.
> That happens to be the same as the WebPKI

No. You mistake a convenience for a necessity. It is certainly _convenient_ if everything in the world trusts your claim of identity without any action but it's not _necessary_ that it must be so. If you want this convenience, you must pay us the courtesy of being open and honest. If you would rather not, too bad we don't trust you. Let me be more specific: I don't trust you.

Ryan Sleevi

unread,
Nov 15, 2016, 10:11:06 PM11/15/16
to Gervase Markham, Ryan Sleevi, mozilla-dev-s...@lists.mozilla.org
On Tue, Nov 15, 2016 at 7:27 AM, Gervase Markham <ge...@mozilla.org> wrote:
> I certainly think our view of redaction will be driven by use cases.
> AIUI, you are strongly encouraging use cases to be brought to the IETF.
> However, if 6962bis is in Last Call, and won't be updated, is the TRANS
> group still listening to and accumulating use cases for redaction?

(Chrome/Google hat)

6962-bis has completed WGLC. It describes the base mechanism for
logging certificates - but makes no statements about the policy (e.g.
when it is appropriate to log a certificate). It describes, at
present, a single technical mean to avoid logging a certificate. This
is covered in https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-20#section-4

The TRANS WG also seems to have rough consensus to continue to discuss
https://datatracker.ietf.org/doc/draft-strad-trans-redaction/ on the
path to adoption. This draft would define additional methods for
redaction, as driven by the use cases, for which you could log a
'certificate' in a way with less information than the methods provided
by 6962-bis.

So the topic of redaction is by no means closed. Rather, it's being
worked on in parallel, with 6962-bis defining the 'base' technology,
and the redaction I-D covering more of the nuanced use cases.

You might imagine this as the distinction between 'certificates' and
'precertificates' within the existing CT ecosystem. A 'precertificate'
has a specific prescribed shape and signalling, and when implemented,
is 'as good as' logging the certificate. Similarly, the redaction ID
defines a specific shape of how to restrict some information from
being logged - without setting any policies on when it may or may not
be appropriate to employ that method, versus say 6962-bis full
certificate logging, or when 6962-bis' existing defined mechanism may
not be sufficient.

So the policy is disjoint from the technology (as IETF is awful with
policy and tries to avoid it, thankfully); the I-D describing the
technical forms to address the use cases is still under active work,
but in order to ensure a timely completion, we (Chrome) want to make
sure the use cases are fed in as much as possible early in the
process, to allow sufficient exploration of a technical solution, and
if a technical solution isn't viable, to push towards a policy
solution.

Ben Laurie

unread,
Nov 16, 2016, 6:24:22 AM11/16/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
On 14 November 2016 at 11:46, Gervase Markham <ge...@mozilla.org> wrote:
> Hi all,
>
> RFC 6962bis (the new CT RFC) allows certs below technically-constrained
> sub-CAs (TCSCs) to be exempt from CT. This is to allow name privacy.
> TCSCs themselves are also currently exempt from disclosure to Mozilla in
> the Common CA Database.
>
> If this is the only privacy mechanism available for 6962bis, I suspect
> we will see a lot more TCSCs about, particularly if CAs figure out ways
> to mint them at scale within the letter of the BRs and other requirements.
>
> CT is getting to be very useful as a way of surveying the certificate
> ecosystem. This is helpful to assess the impact of proposed policy
> changes or positions, e.g. "how many certs don't have an EKU", or "how
> many certs use a certain type of crypto". If certs under TCSCs are
> exempt and this becomes popular, CT would become less useful for that.
>
> One possible answer is just to say: "Mozilla will not accept 'but we
> have a lot of certs under TCSCs which will be affected by this' as a
> valid reason not to do something. In other words, if you hide stuff and
> it breaks, you get to keep both pieces. But in practice, such a line
> might not hold.
>
> Thoughts and suggestions?

You could decide by policy that you do not allow such an exemption.
Given discussions so far around name privacy, this might be the better
option.

>
> Gerv

Jakob Bohm

unread,
Nov 16, 2016, 10:35:57 AM11/16/16
to mozilla-dev-s...@lists.mozilla.org
You are confusing everything with something.

What is typically wanted when requesting non-public/redacted WebPKI
certificates is that the certificate is trusted by those devices that
are used by authorized visitors but which don't allow installing
corporate CA roots to their trust stores.

There is also the case where the authorized user has a limited trust
relationship (e.g. a paying customer or a paid supplier) such that they
would not install an unrestricted corporate CA certificate capable of
signing certificates outside the certificate holder's domain(s).

Redacted CT records that tell the world that "there is this single
certificate with this full TBS hash and these technical extensions
issued to some name domain/e-mail under example.com, but it is not
public which specific name/e-mail address" would fulfill all the truly
needed openness without giving away the specific contact point where
the subject holder can be harassed or attacked.

Matt Palmer

unread,
Nov 16, 2016, 7:14:55 PM11/16/16
to dev-secur...@lists.mozilla.org
On Wed, Nov 16, 2016 at 04:35:18PM +0100, Jakob Bohm wrote:
> Redacted CT records that tell the world that "there is this single
> certificate with this full TBS hash and these technical extensions
> issued to some name domain/e-mail under example.com, but it is not
> public which specific name/e-mail address" would fulfill all the truly
> needed openness without giving away the specific contact point where
> the subject holder can be harassed or attacked.

The problem of redaction is far more subtle than that. This is why the
trans WG is looking for redaction use cases to be described and discussed on
its list, so the full set of use cases can be considered when specifying a
standardised redaction mechanism.

- Matt

Jakob Bohm

unread,
Nov 17, 2016, 2:07:10 PM11/17/16
to mozilla-dev-s...@lists.mozilla.org
Please expand on that and don't just point to a presumably huge
discussion list as containing an explanation of whatever "subtle
problem" you percieve.

Brian Smith

unread,
Nov 17, 2016, 2:28:54 PM11/17/16
to ry...@sleevi.com, mozilla-dev-s...@lists.mozilla.org, Gervase Markham
On Mon, Nov 14, 2016 at 6:39 PM, Ryan Sleevi <ry...@sleevi.com> wrote:

> As Andrew Ayer points out, currently, CAs are required to ensure TCSCs
> comply with the BRs. Non-compliance is misissuance. Does Mozilla share
> that view? And is Mozilla willing to surrender the ability to detect
> misissuance, in favor of something which clearly doesn't address the
> use cases for redaction identified in the CA/Browser Forum and in the
> IETF?
>

I don't agree that a third-party TCSC failing to conform to the BRs should
be considered misissuance in every case, when the technical constrain is
name constraints.

Let's run with an example where I am Example Corp, I own example.com, I
want to get a name-constrained CA certificate for example.com and *.
example.com.

Let's say I screw up something and accidentally issue a certificate from my
sub-CA for google.com or addons.mozilla.org. Because of the name
constraints, this is a non-issue and shouldn't result in any sanctions on
the original root CA or Example Corp. (Note that this means that relying
parties need to implement name constraints, as Mozilla products do, and so
this should be listed as a prerequisite for using Mozilla's trust anchor
list in any non-Mozilla product.)

Let's say I issue a SHA-1-signed certificate for
credit-card-readers.example.com. Again, that's 100% OK, if unfortunate,
because after 2017-1-1 one shouldn't be using Mozilla's trust store in a
web browser or similar consumer product if they accept SHA-1-signed
certificates.

Let's say that the private key for https://www.example.com gets
compromised, but I didn't create any revocation structure so I can't revoke
the certificate for that key. That's really, really, unfortunate, and that
highlights a significant problem with the definition of name-constrained
TCSCs now. In particular, it should be required that the name-constrained
intermediate be marked using this mechanism
https://tools.ietf.org/html/rfc7633#section-4.2.2 in order to be considered
technically-constrained.

Let's say I issue a malformed certificate that is rejected from my
name-constrained intermediate. Again, IMO, we simply shouldn't care too
much. The important thing is that implementations don't implement
workarounds to accomodate such broken certificates.

Let's say I issue a SHA-2 certificate that is valid for 20 years from my
name-constrained certificate. Again, that is not good, but it won't matter
as long as clients are rejecting certificates that are valid for too long,
for whatever definition of "too long" is decided.

Why is it so important to be lenient like this for name-constrained TCSC's?
One big reason is that HPKP is dangerous to use now. Key pinning is really
important, so we should fix it by making it less dangerous. The clearest
way to make it safer is to use only pin the public keys of multiple TCSCs,
where each public key is in an intermediate issued by multiple CAs. But,
basically no CAs are even offering TCSCs using name constraints as the
technical constraint, which means that websites can't do this, and so for
the most part can't safely use key pinning. Absolving CAs from having to
babysit their customers' use of their certificates will make it more
practical for them to make this possible.

Cheers,
Brian
--
https://briansmith.org/

Nick Lamb

unread,
Nov 17, 2016, 6:12:30 PM11/17/16
to mozilla-dev-s...@lists.mozilla.org
On Thursday, 17 November 2016 19:28:54 UTC, Brian Smith wrote:
> Let's say I screw up something and accidentally issue a certificate from my
> sub-CA for google.com or addons.mozilla.org. Because of the name
> constraints, this is a non-issue and shouldn't result in any sanctions on
> the original root CA or Example Corp.

Signifies incompetence. This CA as operated is untrustworthy due to incompetence, root CA should decide whether corrective action by Example Corp is possible and appropriate or revoke the sub-CA. Trust stores should oversee CA investigation and if inadequate, consider sanctions.

> Let's say I issue a SHA-1-signed certificate for
> credit-card-readers.example.com. Again, that's 100% OK, if unfortunate,
> because after 2017-1-1 one shouldn't be using Mozilla's trust store in a
> web browser or similar consumer product if they accept SHA-1-signed
> certificates.

Once again, incompetence.

There's a recurring pattern in most of the examples. A technical counter-measure would be possible, therefore you suppose it's OK to screw-up and the counter-measure saves us. I believe this is the wrong attitude. These counter-measures are defence in depth. We need this defence because people will screw up, but that doesn't make screwing up OK.

Brian Smith

unread,
Nov 17, 2016, 7:11:08 PM11/17/16
to Nick Lamb, mozilla-dev-s...@lists.mozilla.org
Nick Lamb <tiala...@gmail.com> wrote:

> There's a recurring pattern in most of the examples. A technical
> counter-measure would be possible, therefore you suppose it's OK to
> screw-up and the counter-measure saves us.


Right.


> I believe this is the wrong attitude. These counter-measures are defence
> in depth. We need this defence because people will screw up, but that
> doesn't make screwing up OK.
>

With that attitude, CAs would never issue intermediate CAs with name
constraints as the technical constraint on reasonable terms (not costing a
fortune, not forcing you to let the issuing CA have the private key), and
key pinning would remain too dangerous for the vast majority of sites to
ever deploy. Giving up those things would be a huge cost. What's the actual
benefit to end users in giving them up?

(Note: Key pinning isn't the only advantage to being able to freely operate
your own intermediate CA.)

Andrew Ayer

unread,
Nov 17, 2016, 7:28:43 PM11/17/16
to Brian Smith, ry...@sleevi.com, Gervase Markham, mozilla-dev-s...@lists.mozilla.org
On Thu, 17 Nov 2016 09:28:43 -1000
Brian Smith <br...@briansmith.org> wrote:

> On Mon, Nov 14, 2016 at 6:39 PM, Ryan Sleevi <ry...@sleevi.com> wrote:
>
> > As Andrew Ayer points out, currently, CAs are required to ensure
> > TCSCs comply with the BRs. Non-compliance is misissuance. Does
> > Mozilla share that view? And is Mozilla willing to surrender the
> > ability to detect misissuance, in favor of something which clearly
> > doesn't address the use cases for redaction identified in the
> > CA/Browser Forum and in the IETF?
> >
>
> I don't agree that a third-party TCSC failing to conform to the BRs
> should be considered misissuance in every case, when the technical
> constrain is name constraints.
>
> Let's run with an example where I am Example Corp, I own example.com,
> I want to get a name-constrained CA certificate for example.com and *.
> example.com.
>
> Let's say I screw up something and accidentally issue a certificate
> from my sub-CA for google.com or addons.mozilla.org. Because of the
> name constraints, this is a non-issue and shouldn't result in any
> sanctions on the original root CA or Example Corp. (Note that this
> means that relying parties need to implement name constraints, as
> Mozilla products do, and so this should be listed as a prerequisite
> for using Mozilla's trust anchor list in any non-Mozilla product.)
>
> Let's say I issue a SHA-1-signed certificate for
> credit-card-readers.example.com. Again, that's 100% OK, if
> unfortunate, because after 2017-1-1 one shouldn't be using Mozilla's
> trust store in a web browser or similar consumer product if they
> accept SHA-1-signed certificates.
>
I see the appeal of this. However, I'm concerned that allowing
leniency with name-constrained TCSCs will make it hard for Mozilla to
make security improvements to its certificate validation in the
future. Improvements like rejecting SHA-1, 1024-bit RSA keys, and
certificates valid for more than 39 months were only possible because
CAs were first made to stop issuing these types of certificates. If
policies are not enforced on the issuance of certificates from TCSCs,
how will Mozilla make these types of changes in the future without
causing massive breakage?

Regards,
Andrew

Matt Palmer

unread,
Nov 17, 2016, 7:39:11 PM11/17/16
to dev-secur...@lists.mozilla.org
On Thu, Nov 17, 2016 at 02:10:58PM -1000, Brian Smith wrote:
> Nick Lamb <tiala...@gmail.com> wrote:
> > There's a recurring pattern in most of the examples. A technical
> > counter-measure would be possible, therefore you suppose it's OK to
> > screw-up and the counter-measure saves us.
>
> Right.
>
> > I believe this is the wrong attitude. These counter-measures are defence
> > in depth. We need this defence because people will screw up, but that
> > doesn't make screwing up OK.
> >
>
> With that attitude, CAs would never issue intermediate CAs with name
> constraints as the technical constraint on reasonable terms (not costing a
> fortune, not forcing you to let the issuing CA have the private key), and
> key pinning would remain too dangerous for the vast majority of sites to
> ever deploy. Giving up those things would be a huge cost. What's the actual
> benefit to end users in giving them up?

Survivability in the event that the technical constraint is implemented in a
flawed manner. It doesn't seem right to let one party's mistake ("whoops we
issued a 20 year certificate for addons.mozilla.org and don't have any
revocation infrastructure!") pass without any sanction, while another
party's mistake ("there was a flaw in the application of name constraints in
intermediate CA certificates under certain circumstances") results in
mass-pwnage.

> (Note: Key pinning isn't the only advantage to being able to freely operate
> your own intermediate CA.)

I don't see how freely operating your own intermediate CA is a pre-requisite
for key pinning, either. Nor do I accept that running a TCSC in line with
the minimum standards agreed for participation in the WebPKI *must*,
absolutely and without need for further justification, be prohibitively
expensive.

- Matt

Ryan Sleevi

unread,
Nov 17, 2016, 7:49:23 PM11/17/16
to Nick Lamb, mozilla-dev-s...@lists.mozilla.org
On Thu, Nov 17, 2016 at 3:12 PM, Nick Lamb <tiala...@gmail.com> wrote:
> There's a recurring pattern in most of the examples. A technical counter-measure would be possible, therefore you suppose it's OK to screw-up and the counter-measure saves us. I believe this is the wrong attitude. These counter-measures are defence in depth. We need this defence because people will screw up, but that doesn't make screwing up OK.

I think there's an even more telling pattern in Brian's examples -
they're all looking in the past. That is, the technical mitigations
only exist because of the ability of UAs to change to implement those
mitigations, and the only reason those mitigations exist is because
UAs could leverage the CA/B Forum to prevent issues.

That is, imagine if this was 4 years ago, and TCSCs were the vogue,
and as a result, most major sites had 5 year 1024-bit certificates.
The browser wants the lock to signify something - that there's some
reasonable assurance of confidentiality, integrity, and authenticity.
Yet neither 5 year certs nor 1024-bit certificates met that bar.

As I understand the argument being put forward, this would have
involved browsers just breaking things - saying "no more" and just
adding the checks. That is, actively breaking an untold number of
sites - and without CT, this information would have been even harder
to obtain. Until they did, none of the argument that "It's not a big
deal" holds - the lock is meaningfully less secure and actively
misleading, but to change the display, it involves actively breaking
sites - which we know UAs are loathe to do.

While it's easy to argue "Well, we have these checks now, it's not a
problem" - it completely ignores the fact that security is not a
static target, that we will need to deprecate more things in the
future (such as SHA-1), and adopting the position being advocated
means that UAs should bear all of the cost in breakage, and have no
levers except 'all or nothing'. Worse, it amplifies the coordination
problem - from coordinating between browsers and several hundred CAs
to trying to coordinate between browsers and millions of sites. The
rate of progress of the Web in deprecating JS APIs (read: glacially
slow and extremely painfully) suggests this is exactly the model we
should NOT be striving for, by adopting a "TCSCs don't matter"
position.

Peter Bowen

unread,
Nov 17, 2016, 7:55:47 PM11/17/16
to Matt Palmer, dev-secur...@lists.mozilla.org
On Thu, Nov 17, 2016 at 4:38 PM, Matt Palmer <mpa...@hezmatt.org> wrote:
>> (Note: Key pinning isn't the only advantage to being able to freely operate
>> your own intermediate CA.)
>
> I don't see how freely operating your own intermediate CA is a pre-requisite
> for key pinning, either.

If you don't have your own CA you have to choose between pinning to a
CA who might collapse or change their business model such that you
can't use them or pinning end-entity keys which is highly limiting.

> Nor do I accept that running a TCSC in line with
> the minimum standards agreed for participation in the WebPKI *must*,
> absolutely and without need for further justification, be prohibitively
> expensive.

If you have to meet the BRs (which is currently the terms of the BRs,
even for TCSC), then you must have a physically segregated set of
systems just for the CA that have physical access restriction to only
CA personnel. You must have at least two FIPS 140 Level 3 HSMs, a
disaster recover facility, an annual penetration test, quarterly
vulnerability scans, at least two people to run the CA, and pay an
auditor to witness the key generation ceremony.

I'm sure you can find some options to cut costs, but right now I'm
sure this is tens of thousands of USD to get set up.

Thanks,
Peter

Brian Smith

unread,
Nov 17, 2016, 8:44:07 PM11/17/16
to Ryan Sleevi, Nick Lamb, mozilla-dev-s...@lists.mozilla.org
Ryan Sleevi <ry...@sleevi.com> wrote:

> On Thu, Nov 17, 2016 at 3:12 PM, Nick Lamb <tiala...@gmail.com> wrote:
> > There's a recurring pattern in most of the examples. A technical
> counter-measure would be possible, therefore you suppose it's OK to
> screw-up and the counter-measure saves us. I believe this is the wrong
> attitude. These counter-measures are defence in depth. We need this defence
> because people will screw up, but that doesn't make screwing up OK.
>
> I think there's an even more telling pattern in Brian's examples -
> they're all looking in the past. That is, the technical mitigations
> only exist because of the ability of UAs to change to implement those
> mitigations, and the only reason those mitigations exist is because
> UAs could leverage the CA/B Forum to prevent issues.
>
> That is, imagine if this was 4 years ago, and TCSCs were the vogue,
> and as a result, most major sites had 5 year 1024-bit certificates.
> The browser wants the lock to signify something - that there's some
> reasonable assurance of confidentiality, integrity, and authenticity.
> Yet neither 5 year certs nor 1024-bit certificates met that bar.
>

The fundamental problem is that web browsers accept certificates with
validity periods that are years long. If you want to have the agility to
fix things with an N month turnaround, reject certificates that are valid
for more than N months.

In fact, since TCSCs that use name constraints as the technical constraints
basically do not exist, you could even start enforcing even stricter
enforcement than other certificates. For example, externally-operated name
constrained intermediates could be limited to 12 months of validity even if
other certificates aren't so restricted. Just make sure you actually
enforce it in the browser.

If you have a better plan for getting people to actually issue TCSCs of the
name constrained variety, let's hear it.

Cheers,
Brian.
--
https://briansmith.org/

Matt Palmer

unread,
Nov 17, 2016, 9:12:35 PM11/17/16
to dev-secur...@lists.mozilla.org
On Thu, Nov 17, 2016 at 04:55:37PM -0800, Peter Bowen wrote:
> On Thu, Nov 17, 2016 at 4:38 PM, Matt Palmer <mpa...@hezmatt.org> wrote:
> >> (Note: Key pinning isn't the only advantage to being able to freely operate
> >> your own intermediate CA.)
> >
> > I don't see how freely operating your own intermediate CA is a pre-requisite
> > for key pinning, either.
>
> If you don't have your own CA you have to choose between pinning to a
> CA who might collapse or change their business model such that you
> can't use them or pinning end-entity keys which is highly limiting.

Yes, pinning end-entity keys is a great way to very effectively blow your
foot off at the neck. I don't see how pinning an open intermediate is any
worse than pinning a TCSC, though. An organisation which pinned a TCSC
issued by Wosign or Startcom, to use the villains du jour, is in exactly the
same position as if they'd pinned one of their open intermediates.

- Matt

Jakob Bohm

unread,
Nov 17, 2016, 9:19:16 PM11/17/16
to mozilla-dev-s...@lists.mozilla.org
(Please ignore the fanatics trying to shout down any attempt to get
privacy working in the real world).

A reasonable thing would be the following, as already *required* by the
basic certificate specs (x509 etc.):

- The effective end date of any cert is the smaller of the end dates
of all certificates in the currently considered chain (which may
differ depending on configuration etc.) That provides the needed
deadlines without additional rules.

The following polices and technical measures would encourage use of
name constraints:

- End entity name constrained 3rd party intermediary CA certificates
must be validated to EV standards and confer green bar etc. with the
green bar related owner information displayed being that of the
end-entity name constrained intermediary, not the lower certificates.
They must *also* be EKU restricted as either of the categories
accepted for end entity certs.
This means that for browser/mailprog user security, the certificates
issued by those constrained CAs would be no worse than the security
from protocols that generate temporary public keys on the fly, such
as TLS ciphers with PFS (DHE, ECDHE etc.).
- TLD/public suffix constrained name constrained 3rd party
intermediary CA certificates remain subject to the full set of BR
requirements, but are allowed to be subject to national legislative
requirements such as SM ciphers in China or special practices in
Belgium.
- Future acceptance of national CA roots into the root program
could/should be conditional on those CA roots being name restricted
to their particular country. For multi-TLD countries (US has .us,
.gov, .mil and .edu, CN has .cn, .hk etc., DK has .dk, .gl and .fo,
etc.) name constraints allowing that set of alternatives or a subset
would be accepted.

Andrew Ayer

unread,
Nov 17, 2016, 9:19:37 PM11/17/16
to Brian Smith, Ryan Sleevi, Nick Lamb, mozilla-dev-s...@lists.mozilla.org
On Thu, 17 Nov 2016 15:43:57 -1000
Brian Smith <br...@briansmith.org> wrote:

> Ryan Sleevi <ry...@sleevi.com> wrote:
>
> > On Thu, Nov 17, 2016 at 3:12 PM, Nick Lamb <tiala...@gmail.com>
> > wrote:
> > > There's a recurring pattern in most of the examples. A technical
> > counter-measure would be possible, therefore you suppose it's OK to
> > screw-up and the counter-measure saves us. I believe this is the
> > wrong attitude. These counter-measures are defence in depth. We
> > need this defence because people will screw up, but that doesn't
> > make screwing up OK.
> >
> > I think there's an even more telling pattern in Brian's examples -
> > they're all looking in the past. That is, the technical mitigations
> > only exist because of the ability of UAs to change to implement
> > those mitigations, and the only reason those mitigations exist is
> > because UAs could leverage the CA/B Forum to prevent issues.
> >
> > That is, imagine if this was 4 years ago, and TCSCs were the vogue,
> > and as a result, most major sites had 5 year 1024-bit certificates.
> > The browser wants the lock to signify something - that there's some
> > reasonable assurance of confidentiality, integrity, and
> > authenticity. Yet neither 5 year certs nor 1024-bit certificates
> > met that bar.
> >
>
> The fundamental problem is that web browsers accept certificates with
> validity periods that are years long. If you want to have the agility
> to fix things with an N month turnaround, reject certificates that
> are valid for more than N months.

The N month turnaround is only a reality if operators of TCSCs start
issuing certificates that comply with the new rules as soon as the new
rules are announced. How do you ensure that this happens?

Regards,
Andrew

Brian Smith

unread,
Nov 18, 2016, 12:23:26 AM11/18/16
to Andrew Ayer, Ryan Sleevi, Nick Lamb, mozilla-dev-s...@lists.mozilla.org
Andrew Ayer <ag...@andrewayer.name> wrote:

> The N month turnaround is only a reality if operators of TCSCs start
> issuing certificates that comply with the new rules as soon as the new
> rules are announced. How do you ensure that this happens?
>

Imagine that the TCSCs are also required to have a short validity period, N
months. Further, require that each TCSC indicate using a certificate policy
(as already in the spec, or perhaps some simpler mechanism) that indicates
the version of the technical requirements on certificates that that TCSC is
trusted for. Then the end-entity certificates are also similarly marked.
Each policy implicitly maps to a period of time for which that policy
applies. At any given time, trusted CAs are only allowed to issue TCSCs
with validity periods that are within the period of time specified by all
policies listed in that TCSC.

Let's say that this was implemented already two year ago. At that time CAs
could issue SHA-1 certificates and so a TCSC could be issued for the policy
which browsers understand allows TCSCs to be issued. Root programs require
that all such TCSCs expire before January 1, 2016, because that's when
SHA-1 issuance became disallowed. Also, browsers have code in them that
make it so that certificates without that policy OID included won't be
trusted for SHA-1.

Now, let's say I got a TCSC for example.com in March 2015, and I want to
issue SHA-1 certificates, so I ask for that allow-SHA1 policy OID to be
included in my TCSC. That means my certificate will expire in January 2016,
because that's the end date for the allow-SHA1 policy. And also, browsers
would be coded to not recognize that policy OID after January 2016 anyway.

Now, December 2015 roles around and I get another TCSC for January
2016-January 2017. But, the allow-SHA1 policy isn't allowed for that
validity period, so my TCSC won't have that policy; instead it will have
the only-SHA2 policy.

Now, here are my choices:

* Do nothing. My intermediate will expire, and all my servers' certificates
will become untrusted.

* Issue new SHA-1 end-entity certificates from my new only-SHA2
intermediate. But, browsers would not trust these because even if the
end-entity cert contains the allow-SHA1 policy OID, my TCSC won't include
it.

* Issue new SHA-2 end-entity certificates from my new only-SHA2
intermediate.

The important aspects with this idea are:
1. Every TCSC has to be marked with the policies that they are to be
trusted for.
2. Root store policies assign a validity period to each policy.
3. Browsers must enforce the policies in code, and the code for enforcing a
policy must be deployed in production before the end (or maybe the
beginning) of the policy's validity period.
4. A TCSC's validity period must be within all the validity periods for
each policy they are marked with; that is, a TCSC's notAfter must never be
allowed to be after any deprecation deadline that would affect it.

Note that for the latest root store policies, we may not know the end date
of the validity period for the policy. This is where we have to choose an
amount of time, e.g. 12 months, and say we're never going to deprecate
anything with less than 12 months (unless there's some emergency or
whatever), and so we'll allow TCSCs issued today for the current policies
to be valid for up to 12 months.

Also note that the existing certificate policy infrastructure used for the
EV indicator could probably be used, so the code changes to certificate
validation libraries would likely be small.

Thoughts?

Jakob Bohm

unread,
Nov 18, 2016, 1:55:06 AM11/18/16
to mozilla-dev-s...@lists.mozilla.org
You are throwing the baby out with the bathwater. You are letting a
desire to prevent potential incompatibility with hypothetical future
changes destroy basic functionality which would only cause problems in
a minority of cases.

Just let the TCSCs have the usual certificate validity and note that
the organizations running TCSCs need to be aware that if they don't
keep up to date with the policies that apply to the parent CA,
certificates that don't follow those policies might stop working due
to 3rd parties (such as Browser vendors) enforcing those policies as
part of their certificate validity checks.

Gervase Markham

unread,
Nov 18, 2016, 9:09:50 AM11/18/16
to Andrew Ayer
On 18/11/16 00:28, Andrew Ayer wrote:
> I see the appeal of this. However, I'm concerned that allowing
> leniency with name-constrained TCSCs will make it hard for Mozilla to
> make security improvements to its certificate validation in the
> future. Improvements like rejecting SHA-1, 1024-bit RSA keys, and
> certificates valid for more than 39 months were only possible because
> CAs were first made to stop issuing these types of certificates. If
> policies are not enforced on the issuance of certificates from TCSCs,
> how will Mozilla make these types of changes in the future without
> causing massive breakage?

Mozilla's policy certainly needs some sections to apply to every cert
issued under the roots in the store, and some sections which apply only
to server certs (BR-compliant; recognised by Firefox) or email certs. I
hope, before too long, to rearrange it in this way. It could then also
have requirements which only apply to non-TCSC-issued certs. The
question is, which rules which should in which category.

Gerv

Gervase Markham

unread,
Nov 18, 2016, 9:12:26 AM11/18/16
to Brian Smith
On 18/11/16 01:43, Brian Smith wrote:
> The fundamental problem is that web browsers accept certificates with
> validity periods that are years long. If you want to have the agility to
> fix things with an N month turnaround, reject certificates that are valid
> for more than N months.

That's all very well to say. The CAB Forum is deadlocked over a proposal
to reduce the max validity of everything to 2 years + 3 months; some
people like it because it removes a disadvantage of EV (which already
has this limit), other's don't like it because people like not having to
change their cert and are willing to pay for longer. Mozilla is in
support, but without agreement, we can hardly implement unilaterally -
the breakage would be vast.

Gerv

Jeremy Rowley

unread,
Nov 18, 2016, 9:29:00 AM11/18/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org, Brian Smith
So much has changed since the last time we discussed shorter validity periods at CAB forum that it'd be worth bringing up again. I think the vocal minority opposed the change last time and they may have switched positions by now.

> On Nov 18, 2016, at 7:12 AM, Gervase Markham <ge...@mozilla.org> wrote:
>
>> On 18/11/16 01:43, Brian Smith wrote:
>> The fundamental problem is that web browsers accept certificates with
>> validity periods that are years long. If you want to have the agility to
>> fix things with an N month turnaround, reject certificates that are valid
>> for more than N months.
>
> That's all very well to say. The CAB Forum is deadlocked over a proposal
> to reduce the max validity of everything to 2 years + 3 months; some
> people like it because it removes a disadvantage of EV (which already
> has this limit), other's don't like it because people like not having to
> change their cert and are willing to pay for longer. Mozilla is in
> support, but without agreement, we can hardly implement unilaterally -
> the breakage would be vast.
>
> Gerv
>

Gervase Markham

unread,
Nov 18, 2016, 12:14:43 PM11/18/16
to mozilla-dev-s...@lists.mozilla.org
On 18/11/16 14:28, Jeremy Rowley wrote:
> So much has changed since the last time we discussed shorter
> validity periods at CAB forum that it'd be worth bringing up again. I
> think the vocal minority opposed the change last time and they may
> have switched positions by now.

I like your optimism :-) We can add it to the long list of issues to
discuss when we've at least established a timeline for fixing the IPR mess.

Gerv

Brian Smith

unread,
Nov 18, 2016, 2:13:48 PM11/18/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
Gervase Markham <ge...@mozilla.org> wrote:

> On 18/11/16 01:43, Brian Smith wrote:
> > The fundamental problem is that web browsers accept certificates with
> > validity periods that are years long. If you want to have the agility to
> > fix things with an N month turnaround, reject certificates that are valid
> > for more than N months.
>
> That's all very well to say. The CAB Forum is deadlocked over a proposal
> to reduce the max validity of everything to 2 years + 3 months; some
> people like it because it removes a disadvantage of EV (which already
> has this limit), other's don't like it because people like not having to
> change their cert and are willing to pay for longer. Mozilla is in
> support, but without agreement, we can hardly implement unilaterally -
> the breakage would be vast.
>

Regardless, the main point of that message of mine was left out: You could
limit, in policy and in code, the acceptable lifetime of name-constrained
externally-operated sub-CAs and/or the end-entity certificates they issue
strictly, independently of whether it can be done for all certificates, and
doing so would be at least part of the solution to making name-constrained
externally-operated sub-CAs actually a viable alternative in the market.

Brian Smith

unread,
Nov 18, 2016, 3:21:11 PM11/18/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
Gervase Markham <ge...@mozilla.org> wrote:

> RFC 6962bis (the new CT RFC) allows certs below technically-constrained
> sub-CAs (TCSCs) to be exempt from CT. This is to allow name privacy.
> TCSCs themselves are also currently exempt from disclosure to Mozilla in
> the Common CA Database.
>
> If this is the only privacy mechanism available for 6962bis,


First, here's the RFC 6969-bis draft:
https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-20#section-4.2.

Please see my other messages in this thread, where I pointed out that
Mozilla's own definition of externally-operated name-constrained sub-CAs
should be improved because name constraints don't mitigate every serious
concern one might have regarding technically-constrained sub-CAs. I think
that's clearly true for what RFC 6962-bis is trying to do with name
constraints too.

I think there might be ways to fix the name-constrained sub-CA stuff for
RFC 6962-bis, but those kinds of improvements are unlikely to happen in RFC
6962-bis itself, it seems. They will have to happen in an update to RFC
6962-bis.

I also disagree with Google's position that it is OK to leave bad stuff in
the spec and then ignore it. The WGLC has passed, but that doesn't mean
that the spec can't be changed. Google's already proposed a hugely
significant change to the spec in the last few days (which I support),
which demonstrates this.

Accordingly, I think the exception mechanism for name-constrained sub-CAs
(section 4.2) should be removed from the spec. This is especially the case
if there are no browsers who want to implement it. If the draft contains
things that clients won't implement, then that's an issue that's relevant
for the IETF last call, as that's against the general IETF philosophy of
requiring running code.

Cheers,
Brian

Gervase Markham

unread,
Nov 21, 2016, 4:51:48 AM11/21/16
to Brian Smith
Hi Brian,

On 18/11/16 19:13, Brian Smith wrote:
> Regardless, the main point of that message of mine was left out: You could
> limit, in policy and in code, the acceptable lifetime of name-constrained
> externally-operated sub-CAs

Presumably the "externally-operated" part would need to be policy, or a
code-detectable marker enforced by policy, because there's no way of
detecting that otherwise?

> and/or the end-entity certificates they issue
> strictly, independently of whether it can be done for all certificates, and
> doing so would be at least part of the solution to making name-constrained
> externally-operated sub-CAs actually a viable alternative in the market.

I'm not sure what you mean by "a viable alternative" - I thought the
concern was to stop them proliferating, if what's underneath them was
opaque? And if it's not opaque, why are they not a viable alternative
now, and why would restricting their capabilities make them _more_ viable?

Sorry to be lost,

Gerv

Rob Stradling

unread,
Nov 21, 2016, 5:19:43 AM11/21/16
to Brian Smith, mozilla-dev-s...@lists.mozilla.org, Gervase Markham
On 18/11/16 20:21, Brian Smith wrote:
<snip>
> I think there might be ways to fix the name-constrained sub-CA stuff for
> RFC 6962-bis, but those kinds of improvements are unlikely to happen in RFC
> 6962-bis itself, it seems. They will have to happen in an update to RFC
> 6962-bis.
>
> I also disagree with Google's position that it is OK to leave bad stuff in
> the spec and then ignore it. The WGLC has passed, but that doesn't mean
> that the spec can't be changed. Google's already proposed a hugely
> significant change to the spec in the last few days (which I support),
> which demonstrates this.
>
> Accordingly, I think the exception mechanism for name-constrained sub-CAs
> (section 4.2) should be removed from the spec. This is especially the case
> if there are no browsers who want to implement it. If the draft contains
> things that clients won't implement, then that's an issue that's relevant
> for the IETF last call, as that's against the general IETF philosophy of
> requiring running code.

Brian, please consider sending your comments to TRANS.

FWIW, after Ryan Sleevi publicly stated that Chrome won't be supporting
this exception mechanism as currently specified in 6962-bis, I attempted
(without success) to obtain approval to move it out of 6962-bis and into
draft-strad-trans-redaction.

Maybe if there are more people saying the same thing...

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

Brian Smith

unread,
Nov 21, 2016, 2:01:37 PM11/21/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
Gervase Markham <ge...@mozilla.org> wrote:

> On 18/11/16 19:13, Brian Smith wrote:
> > Regardless, the main point of that message of mine was left out: You
> could
> > limit, in policy and in code, the acceptable lifetime of name-constrained
> > externally-operated sub-CAs
>
> Presumably the "externally-operated" part would need to be policy, or a
> code-detectable marker enforced by policy, because there's no way of
> detecting that otherwise?
>

In another message in this thread, I suggested one way to mark intermediate
certificates as meeting the criteria of an name-constrained
externally-operated sub-CA that uses certificate policy OIDs. That proposed
mechanism also ensures externally-operated sub-CAs comply with Mozilla's
technical requirements (e.g. SHA-1 deprecation and future deprecations or
transisitions).


>
> > and/or the end-entity certificates they issue
> > strictly, independently of whether it can be done for all certificates,
> and
> > doing so would be at least part of the solution to making
> name-constrained
> > externally-operated sub-CAs actually a viable alternative in the market.
>
> I'm not sure what you mean by "a viable alternative" - I thought the
> concern was to stop them proliferating,


Absolutely we should be encouraging them to proliferate. Every site that is
doing anything moderately complex and/or that wants to use key pinning
should be using them.


> if what's underneath them was
> opaque? And if it's not opaque,


If draft-ietf-trans-rfc6962-bis section 4.2 discourages Mozilla from making
externally-operated name-constrained certificates viable then please have
somebody from Mozilla write to the TRANS list asking for section 4.2 to be
removed from the draft.


> why are they not a viable alternative
> now, and why would restricting their capabilities make them _more_ viable?
>

Go out and try to find 3 different CAs that will sell you a
name-constrained sub-CA certificate where you maintain control of the
private key and with no strings attached (no requirement that you implement
the same technical controls as root CAs or being audited to the same level
as them). My understanding is that you won't be able to find any that will
do so, because if you go off and issue a google.com certificate then
Mozilla and others will then hold the issuing root CA responsible for that.

My hypothesis is that CAs would be willing to start selling such
certificates under reasonable terms if they weren't held responsible for
the things signed by such sub-CAs. It would be good to hear from CAs who
would be interested in that to see if that is true.

To reiterate, I disagree that the name-constraint redaction is bad because
the certificates issued by the externally-operated name-constrained CAs
must be subject to all the terms of browsers' policies, including the BRs.
That kind of thinking is 100% counter to the reason Mozilla created the
exceptions for externally-operated name-constrained CAs in its policy in
the first place. (Similarly, the requirements on externally-operated
name-constrained CAs in the baseline requirements defeat the purpose of
treating them specially.) However, i do agree that the technical details
regarding (externally-operated) name-constrained CAs in Mozilla's policy
and in draft-ietf-trans-rfc6962-bis are insufficient, and that's why I
support (1) removing section 4.2 from draft-ietf-trans-rfc6962-bis-20, and
(2) improving Mozilla's policy and the BRs so that the technical details do
become sufficient. After that we can then see if it makes sense to revise
rfc6962-bis to add redaction based on the revised details of how root
stores treat name-constrained externally-operated sub-CAs.

Ryan Sleevi

unread,
Nov 21, 2016, 2:15:52 PM11/21/16
to Brian Smith, mozilla-dev-s...@lists.mozilla.org, Gervase Markham
On Mon, Nov 21, 2016 at 11:01 AM, Brian Smith <br...@briansmith.org> wrote:
> Absolutely we should be encouraging them to proliferate. Every site that is
> doing anything moderately complex and/or that wants to use key pinning
> should be using them.

I do hope you can expand upon the former as to what you see.
As to the latter, key pinning is viable without the use of TCSCs. It's
clear that you view there being a different risk/reward calculus for
TCSCs, but I don't think I'd agree with that calculus. Many of the
same considerations that exist with pinning EE certs still remain, and
many of the same considerations that exist with pinning CA certs still
remain.

> If draft-ietf-trans-rfc6962-bis section 4.2 discourages Mozilla from making
> externally-operated name-constrained certificates viable then please have
> somebody from Mozilla write to the TRANS list asking for section 4.2 to be
> removed from the draft.

Why, if it's completed WGLC, and describes a viable technical
mechanism that may simply not be implemented via policy until
sufficient policy controls exist?

> Go out and try to find 3 different CAs that will sell you a
> name-constrained sub-CA certificate where you maintain control of the
> private key and with no strings attached (no requirement that you implement
> the same technical controls as root CAs or being audited to the same level
> as them).

If you find a single one, do please report to this list - because
that's not permitted under the Baseline Requirements today.

> My hypothesis is that CAs would be willing to start selling such
> certificates under reasonable terms if they weren't held responsible for
> the things signed by such sub-CAs. It would be good to hear from CAs who
> would be interested in that to see if that is true.

That would require a change to the BRs, right? So far, no CAs have
requested such a change, so why do you believe such CAs exist?

> However, i do agree that the technical details
> regarding (externally-operated) name-constrained CAs in Mozilla's policy
> and in draft-ietf-trans-rfc6962-bis are insufficient, and that's why I
> support (1) removing section 4.2 from draft-ietf-trans-rfc6962-bis-20, and
> (2) improving Mozilla's policy and the BRs so that the technical details do
> become sufficient. After that we can then see if it makes sense to revise
> rfc6962-bis to add redaction based on the revised details of how root
> stores treat name-constrained externally-operated sub-CAs.

Why should a technical document be blocked on the policy document?
Shouldn't it be the other way around - or at least in parallel?
6962-bis describes a technical form, without making any statements on
when that technical form may or may not be appropriate or suitable.
That's a question of policy, much like the question of which CT logs
to accept, or how many SCTs to require, isn't it? It's unclear what
you see as technically deficient versus simply an incomplete policy
requirement.

Brian Smith

unread,
Nov 21, 2016, 2:51:38 PM11/21/16
to Ryan Sleevi, mozilla-dev-s...@lists.mozilla.org, Gervase Markham
Ryan Sleevi <ry...@sleevi.com> wrote:

> On Mon, Nov 21, 2016 at 11:01 AM, Brian Smith <br...@briansmith.org>
> wrote:
> > Absolutely we should be encouraging them to proliferate. Every site that
> is
> > doing anything moderately complex and/or that wants to use key pinning
> > should be using them.
>
> I do hope you can expand upon the former as to what you see.
> As to the latter, key pinning is viable without the use of TCSCs.


A lot of people disagree, perhaps because they read the text after
"WARNING:" in
https://noncombatant.org/2015/05/01/about-http-public-key-pinning/.

If nothing else, using your own intermediate can help avoid the problems
with Google Chrome's implementation. (FWIW, Firefox's implementation also
can be coerced into behaving as badly as Chrome's, in some situations,
IIRC.)


> > My hypothesis is that CAs would be willing to start selling such
>
> certificates under reasonable terms if they weren't held responsible for
> > the things signed by such sub-CAs. It would be good to hear from CAs who
> > would be interested in that to see if that is true.
>
> That would require a change to the BRs, right? So far, no CAs have
> requested such a change, so why do you believe such CAs exist?
>

It would require changes to browsers' policies. Changing the BRs is one way
to do that, but it seems like CAB Forum is non-functional right now so it
might be better to simply route around the BRs.


> Why should a technical document be blocked on the policy document?
>

Nobody said anything about blocking 6962-bis. Removing that one section is
a smaller change in terms than the change Google made to the document just
last week, as far as the practical considerations are concerned.

Regardless, the argument for removing it is exactly your own arguments for
why you don't want to do it in Chrome. Read your own emails to learn more
about my technical objections to it.

Ryan Sleevi

unread,
Nov 21, 2016, 2:58:27 PM11/21/16
to Brian Smith, Ryan Sleevi, mozilla-dev-s...@lists.mozilla.org, Gervase Markham
On Mon, Nov 21, 2016 at 11:51 AM, Brian Smith <br...@briansmith.org> wrote:
> Nobody said anything about blocking 6962-bis. Removing that one section is a
> smaller change in terms than the change Google made to the document just
> last week, as far as the practical considerations are concerned.

With IETF process, having completed WGLC, it would, effectively,
require blocking it, so as to send it back to the WG, remove it,
re-enter WGLC, and recomplete.

That is, the time for that comment is more or less over, as Rob
Stradling found out with respect to the chairs' position on that
matter.

> Regardless, the argument for removing it is exactly your own arguments for
> why you don't want to do it in Chrome. Read your own emails to learn more
> about my technical objections to it.

Have you supplied those to TRANS? Have you provided compelling
evidence that the document, as currently written, is so flawed that it
would need to re-enter WGLC?

The process point alone is enough to let it alone, and it doesn't seem
like you're proposing any substantial technical change to it; that is,
the substance of the changes are attached to policy, not the technical
definition.

Gervase Markham

unread,
Nov 22, 2016, 6:24:27 AM11/22/16
to Brian Smith
On 21/11/16 19:01, Brian Smith wrote:
> In another message in this thread, I suggested one way to mark intermediate
> certificates as meeting the criteria of an name-constrained
> externally-operated sub-CA that uses certificate policy OIDs. That proposed
> mechanism also ensures externally-operated sub-CAs comply with Mozilla's
> technical requirements (e.g. SHA-1 deprecation and future deprecations or
> transisitions).

I confess I didn't follow all the details of that proposal, or its
ramifications; could you write it up in a document or wiki page
somewhere, where it can be commented on, expanded and updated as
questions and clarifications arise?

Gerv
0 new messages