Re: Technically Constrained Sub-CAs

[Gervase Markham]

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

Re: Technically Constrained Sub-CAs

[Ryan Sleevi]

On Mon, Nov 21, 2016 at 11:51 AM, Brian Smith  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Brian Smith]

Ryan Sleevi  wrote:

> On Mon, Nov 21, 2016 at 11:01 AM, Brian Smith 
> 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.

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

Re: Technically Constrained Sub-CAs

[Ryan Sleevi]

On Mon, Nov 21, 2016 at 11:01 AM, Brian Smith  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Brian Smith]

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

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

Re: Technically Constrained Sub-CAs

[Rob Stradling]

On 18/11/16 20:21, Brian Smith wrote:


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

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

Re: Technically Constrained Sub-CAs

[Gervase Markham]

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

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

Re: Technically Constrained Sub-CAs

[Brian Smith]

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

Re: Technically Constrained Sub-CAs

[Brian Smith]

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

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

Re: Technically Constrained Sub-CAs

[Gervase Markham]

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

Re: Technically Constrained Sub-CAs

[Jeremy Rowley]

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  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
> 
> ___
> dev-security-policy mailing list
> 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: Technically Constrained Sub-CAs

[Gervase Markham]

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

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

Re: Technically Constrained Sub-CAs

[Gervase Markham]

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

Re: Technically Constrained Sub-CAs

[Jakob Bohm]

On 18/11/2016 06:23, Brian Smith wrote:

Andrew Ayer  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?



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.


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

Re: Technically Constrained Sub-CAs

[Brian Smith]

Andrew Ayer  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?

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

Re: Technically Constrained Sub-CAs

[Matt Palmer]

On Thu, Nov 17, 2016 at 04:55:37PM -0800, Peter Bowen wrote:
> On Thu, Nov 17, 2016 at 4:38 PM, Matt Palmer  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

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

Re: Technically Constrained Sub-CAs

[Brian Smith]

Ryan Sleevi  wrote:

> On Thu, Nov 17, 2016 at 3:12 PM, Nick Lamb  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/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Ryan Sleevi]

On Thu, Nov 17, 2016 at 3:12 PM, Nick Lamb  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Matt Palmer]

On Thu, Nov 17, 2016 at 02:10:58PM -1000, Brian Smith wrote:
> Nick Lamb  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

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

Re: Technically Constrained Sub-CAs

[Andrew Ayer]

On Thu, 17 Nov 2016 09:28:43 -1000
Brian Smith  wrote:

> On Mon, Nov 14, 2016 at 6:39 PM, Ryan Sleevi  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.

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

Re: Technically Constrained Sub-CAs

[Brian Smith]

Nick Lamb  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.)

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

Re: Technically Constrained Sub-CAs

[Nick Lamb]

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

Re: Technically Constrained Sub-CAs

[Brian Smith]

On Mon, Nov 14, 2016 at 6:39 PM, Ryan Sleevi  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/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Jakob Bohm]

On 17/11/2016 01:14, Matt Palmer wrote:

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.



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.


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

Re: Technically Constrained Sub-CAs

[Jakob Bohm]

On 16/11/2016 02:13, Nick Lamb wrote:

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.



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.


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

Re: Technically Constrained Sub-CAs

[Ryan Sleevi]

On Tue, Nov 15, 2016 at 7:27 AM, 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?

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

Re: Technically Constrained Sub-CAs

[Nick Lamb]

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

Re: Technically Constrained Sub-CAs

[Matt Palmer]

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

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

Re: Technically Constrained Sub-CAs

[Gervase Markham]

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

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

Re: Technically Constrained Sub-CAs

[Matt Palmer]

On Mon, Nov 14, 2016 at 11:46:28AM +, 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

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

Re: Technically Constrained Sub-CAs

[Matt Palmer]

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

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

Re: Technically Constrained Sub-CAs

[Ryan Sleevi]

On Mon, Nov 14, 2016 at 3:46 AM, Gervase Markham  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?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Rob Stradling]

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

Re: Technically Constrained Sub-CAs

[Nick Lamb]

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

Re: Technically Constrained Sub-CAs

[Andrew Ayer]

On Mon, 14 Nov 2016 06:00:24 -0800
Peter Bowen  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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Gervase Markham]

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


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

Re: Technically Constrained Sub-CAs

[Peter Bowen]

On Mon, Nov 14, 2016 at 8:51 AM, Jakob Bohm  wrote:
> On 14/11/2016 16:31, Peter Bowen wrote:
>>
>> On Mon, Nov 14, 2016 at 7:14 AM, Gervase Markham  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.
>>
>
> #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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Jakob Bohm]

On 14/11/2016 16:31, Peter Bowen wrote:

On Mon, Nov 14, 2016 at 7:14 AM, Gervase Markham  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.



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

Re: Technically Constrained Sub-CAs

[Eric Mill]

On Mon, Nov 14, 2016 at 9:00 AM, Peter Bowen  wrote:

> On Mon, Nov 14, 2016 at 3:46 AM, Gervase Markham  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-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



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

Re: Technically Constrained Sub-CAs

[Gervase Markham]

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

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

Re: Technically Constrained Sub-CAs

[Peter Bowen]

On Mon, Nov 14, 2016 at 7:14 AM, Gervase Markham  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Kurt Roeckx]

On 2016-11-14 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.

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?


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

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

Re: Technically Constrained Sub-CAs

[Peter Bowen]

On Mon, Nov 14, 2016 at 3:46 AM, Gervase Markham  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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs and the BRs

[Santhan Raj]

> Certificates that are capable of being used to issue new certificates MUST 
> either be Technically Constrained in line with section 7.1.5 and audited in 
> line with section 8.7 only, or Unconstrained and fully audited in line with 
> all remaining requirements from this section
> 
> Section 8.7 reads:
> During the period in which a Technically Constrained Subordinate CA issues 
> Certificates, the CA which signed the Subordinate CA SHALL monitor adherence 
> to the CA’s Certificate Policy and the Subordinate CA’s Certification 
> Practice Statement. On at least a quarterly basis, against a randomly 
> selected sample of the greater of one certificate or at least three percent 
> of the Certificates issued by the Subordinate CA, during the period 
> commencing immediately after the previous audit sample was taken, the CA 
> shall ensure all applicable CP are met. 
> 
> 
> That is, according to the BRs, the issuer of a technically constrained 
> subordinate CA has a BR-obligation to ensure that their TCSCs are adhering to 
> the BRs and the issuing CA's policies and practices, as well as conduct a 
> sampling audit quarterly.

May be I'm missing it, but I don't see 8.7 (or at least the lines quoted above) 
requiring TCSC to be compliant with BR. I read it as TCSCs must adhere to the 
Issuing CA's CP and their own (TCSC's) CPS, adhereance towards which should be 
verified by the Issuing CAs, however it doesn't (explicitly) state TCSC 
compliance towards BR. 

Is this how you arrived at "TCSC should adhere to BRs", (which to me at least, 
personally, sounds fair and logical): 
Issuing CA must be BR compliant 
  -> Issuing CA's CP must be BR compliant (unless the CA gets creative) 
 -> TCSC's CPS should adhere Issuing CA's CA 
-> TCSC's CPS should adhere to BR
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs and the BRs

[Gervase Markham]

On 26/10/16 18:53, Ryan Sleevi wrote:
> interpretation of #2. This is also why I support the mandatory
> disclosure of TCSCs to Mozilla Salesforce, to ensure that the
> Technical Constraints are properly implemented and conforming in
> order for the CA to claim its exclusion.

If we were to require this, would it present administrative issue? At
the moment, we are dealing with approximately 2500 intermediates in
Salesforce. If we added the TCSCs, do we have any idea what that number
would go up to? Rob has only discovered 300 TCSCs, so perhaps the
increase would not be so large? Or are lots of them hidden from public view?

> Since we have precedent of using the BRs to set ecosystem-wide
> minimum security requirements (to receive secure UI), such as using
> unambiguous subjectAltNames, presenting the right EKU, and using
> reasonably sufficient cryptographic key sizes (RSA-2048, ECC-256), I
> think the interpretation that nothing below a TCSC can do any harm is
> a bad interpretation.

I think you are correct. The view "it can't hurt" was, at least in my
mind, related to the risk of misissuance. And therefore I was not so
concerned about them getting an audit, using a level 4 HSM and so on.
Perhaps we did not give sufficient consideration to issues like use of
SHA-1.

> While I'm supportive, in general, of you're suggested modification, I
> do want to highlight the implications that it brings. It means that
> TCSCs must ensure FIPS 140-2 Level 3 HSMs and key protection, audit
> logs, etc. In effect, the only benefit a TCSC provides is that it
> allows you to avoid an independent auditor, but doesn't allow you to
> avoid any of the substantial obligations in capital to conform to the
> BRs and the netsec requirements.

Right - but we would just be matching what the BRs already require,
wouldn't we? So if we adopted this view, we wouldn't be giving anyone
any costs they didn't already have.

> Alternatively, we could try to suggest that a TCSCs' certificates
> must conform to the certificate profile, but not other obligations
> (like separation of duty, offline protection, etc), but then we still
> have to figure out which elements of that technical profile are
> relevant - for example, OCSP and CRL services for the TCSC.

This seems like a route worth investigating; the work required to decide
this would not be massive.

Gerv

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

RE: Technically Constrained Sub-CAs and the BRs

[Jeremy Rowley]

One thing I forgot to mention:

Although I think Viriginia's view of the process is fine, passing the ballot
now puts the requirement into a weird status where it may be adopted or not
adopted, depending on the CA's interpretation on when changes are adopted.
This then becomes an exercise in whether the auditor believes the process is
allowed instead of something that is prohibited. The status of the ballot as
binding may be unclear from the Forum's perspective but that at least shifts
it over to the CA to explain to auditors. The process definitely needs
clarification, but I can see the point in Wayne wanting to pass the ballot
before the governance/IPR issues are resolved (that plus we never voted to
suspend ballots so I think we permit members to continue following the
process until there is clarity - we're no worse off than we were before)

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Ryan Sleevi
Sent: Wednesday, October 26, 2016 11:53 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Technically Constrained Sub-CAs and the BRs

On Wednesday, October 26, 2016 at 3:52:23 AM UTC-7, Gervase Markham wrote:
> Perhaps it would be worth revisiting the reasons why technically 
> constrained sub-CAs were excluded from Mozilla policy. As I remember, 
> this was a privacy requirement - CAs wanted to be able to have some 
> sub-CAs which were not publicly disclosed, as Mozilla policy was set 
> to require. The compromise reached was that public disclosure was not 
> necessary if the sub-CA were name-constrained. Am I correct in this, 
> or were there other reasons? Are there parts of Mozilla's policy 
> and/or the BRs that it would be reasonable for such sub-CAs to be exempt
from?

My understanding was actually that it was two-fold:

1) A small subset of CAs felt that TCSCs should be private.
2) Generally, it was felt that because the most 'harm' you can do with a
TCSC is to your own domains, the need for a third-party audit, or for some
of the more substantial requirements (e.g. standing up an OCSP and CRL
responder, HSM protection, etc) were unnecessary, and more an element of
local security policy.

I'm actually entirely unsympathetic to the argument in 1, and even RFC 6962
(early drafts) and RFC 6962-bis (current draft) seemed to support this,
without objection from CAs, by requiring that a TCSC be disclosed via CT,
but that it's leaves would be exempt. Independent of Chrome's view of that
(wearing that hat for only this sentence), by allowing leaves under a TCSC
to be unlogged seems to support the interpretation of #2. This is also why I
support the mandatory disclosure of TCSCs to Mozilla Salesforce, to ensure
that the Technical Constraints are properly implemented and conforming in
order for the CA to claim its exclusion.

The challenge with the interpretation in #2 is that, while the damage may be
localized to a specific domain, we know that it can present ecosystem
issues, particularly around deprecation. If we fully accept that TCSCs can
do no harm to the Web PKI, then arguably, requirements such as using
2048-bit RSA keys are unnecessary in the BRs, because they're also
"localized" harm (if for a non-CA cert).

Since we have precedent of using the BRs to set ecosystem-wide minimum
security requirements (to receive secure UI), such as using unambiguous
subjectAltNames, presenting the right EKU, and using reasonably sufficient
cryptographic key sizes (RSA-2048, ECC-256), I think the interpretation that
nothing below a TCSC can do any harm is a bad interpretation.

So then the question becomes - what ARE the things that TCSCs should be
exempt from, and to what degree? As it stands in the BRs, they are exempt
from only one thing: An independent, third-party audit. All other
requirements are in full force, regarding the certificate profile, key
protection, and key revocation services. Under Mozilla policy, as
interpreted at present, they are exempt from all requirements. This is the
core inconsistency - because the Issuing CA has a BR obligation to ensure
the TCSC is compliant.


While I'm supportive, in general, of you're suggested modification, I do
want to highlight the implications that it brings. It means that TCSCs must
ensure FIPS 140-2 Level 3 HSMs and key protection, audit logs, etc. In
effect, the only benefit a TCSC provides is that it allows you to avoid an
independent auditor, but doesn't allow you to avoid any of the substantial
obligations in capital to conform to the BRs and the netsec requirements.

Alternatively, we could try to suggest that a TCSCs' certificates must
conform to the certificate profile, but not other obligations (like
separation of duty, offline protection, etc), but then we still have to
figure out which elements of that technical profile are relevant - for
example, OCSP and CRL services for the TCSC.

Or we c

Re: Technically Constrained Sub-CAs and the BRs

[Ryan Sleevi]

On Wednesday, October 26, 2016 at 3:52:23 AM UTC-7, Gervase Markham wrote:
> Perhaps it would be worth revisiting the reasons why technically
> constrained sub-CAs were excluded from Mozilla policy. As I remember,
> this was a privacy requirement - CAs wanted to be able to have some
> sub-CAs which were not publicly disclosed, as Mozilla policy was set to
> require. The compromise reached was that public disclosure was not
> necessary if the sub-CA were name-constrained. Am I correct in this, or
> were there other reasons? Are there parts of Mozilla's policy and/or the
> BRs that it would be reasonable for such sub-CAs to be exempt from?

My understanding was actually that it was two-fold:

1) A small subset of CAs felt that TCSCs should be private.
2) Generally, it was felt that because the most 'harm' you can do with a TCSC 
is to your own domains, the need for a third-party audit, or for some of the 
more substantial requirements (e.g. standing up an OCSP and CRL responder, HSM 
protection, etc) were unnecessary, and more an element of local security policy.

I'm actually entirely unsympathetic to the argument in 1, and even RFC 6962 
(early drafts) and RFC 6962-bis (current draft) seemed to support this, without 
objection from CAs, by requiring that a TCSC be disclosed via CT, but that it's 
leaves would be exempt. Independent of Chrome's view of that (wearing that hat 
for only this sentence), by allowing leaves under a TCSC to be unlogged seems 
to support the interpretation of #2. This is also why I support the mandatory 
disclosure of TCSCs to Mozilla Salesforce, to ensure that the Technical 
Constraints are properly implemented and conforming in order for the CA to 
claim its exclusion.

The challenge with the interpretation in #2 is that, while the damage may be 
localized to a specific domain, we know that it can present ecosystem issues, 
particularly around deprecation. If we fully accept that TCSCs can do no harm 
to the Web PKI, then arguably, requirements such as using 2048-bit RSA keys are 
unnecessary in the BRs, because they're also "localized" harm (if for a non-CA 
cert).

Since we have precedent of using the BRs to set ecosystem-wide minimum security 
requirements (to receive secure UI), such as using unambiguous subjectAltNames, 
presenting the right EKU, and using reasonably sufficient cryptographic key 
sizes (RSA-2048, ECC-256), I think the interpretation that nothing below a TCSC 
can do any harm is a bad interpretation.

So then the question becomes - what ARE the things that TCSCs should be exempt 
from, and to what degree? As it stands in the BRs, they are exempt from only 
one thing: An independent, third-party audit. All other requirements are in 
full force, regarding the certificate profile, key protection, and key 
revocation services. Under Mozilla policy, as interpreted at present, they are 
exempt from all requirements. This is the core inconsistency - because the 
Issuing CA has a BR obligation to ensure the TCSC is compliant.


While I'm supportive, in general, of you're suggested modification, I do want 
to highlight the implications that it brings. It means that TCSCs must ensure 
FIPS 140-2 Level 3 HSMs and key protection, audit logs, etc. In effect, the 
only benefit a TCSC provides is that it allows you to avoid an independent 
auditor, but doesn't allow you to avoid any of the substantial obligations in 
capital to conform to the BRs and the netsec requirements.

Alternatively, we could try to suggest that a TCSCs' certificates must conform 
to the certificate profile, but not other obligations (like separation of duty, 
offline protection, etc), but then we still have to figure out which elements 
of that technical profile are relevant - for example, OCSP and CRL services for 
the TCSC.

Or we could go with the current perceived interpretation - out of sight, out of 
mind - in which case, that means that any BR-violating sub-CA may be reissued 
as a TCSC, provided that its only for domains it controls. That, of course, 
leaves the situation I described as a possibility - largescale, automated TCSC 
issuance as a way to avoid BR-based deprecations - but we can cross that bridge 
when it comes up.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs and the BRs

[okaphone . elektronika]

Reading this makes me wonder. Will it still be possible to have such a thing as 
a non disclosed sub-CA now that Chrome has announced that they soon will 
require CT?

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

Re: Technically Constrained Sub-CAs and the BRs

[Kurt Roeckx]

On Tue, Oct 25, 2016 at 12:12:47PM -0700, Ryan Sleevi wrote:
> 8. All certificates that are capable of being used to issue new certificates, 
> and which directly or transitively chain to a certificate included in 
> Mozilla’s CA Certificate Program, MUST be operated in accordance with 
> Mozilla’s CA Certificate Policy and MUST either be technically constrained or 
> be publicly disclosed and audited.
> 
> This wording implies that technically constrained sub-CAs, from a Mozilla 
> Policy standpoint, are not required to adhere to the Baseline Requirements.

So I think what you're trying to say is that you interprete it as:
"MUST either be (technically constrained) or (be publicly disclosed and 
audited)"
While maybe it was meant to say:
"MUST either be (technically constrained or be publicly disclosed) and audited"

Where audited can either be done by an external auditor, or by the
CA that issued the TCSC. But you could also interprete is like we
only require an audit report from those that are not technically
constrained.

To avoid confusing, you could make it a list like:
- technically constrained or be publicly disclosed
- audited

It's also not clear from that sentence that they need to adhere to
the BRs, but I guess that comes from the audit requirements.


Kurt

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

Re: Technically Constrained Sub-CAs and the BRs

[Gervase Markham]

On 26/10/16 02:30, Ryan Sleevi wrote:
> So we certainly know that Mozilla's policies are, in some ways,
> designed to minimize the number of errors that users are presented
> with, by allowing a gradual fade out of insecure or undesirable
> practices. A change in the BRs is, in theory, supposed to be fully
> reflected in all valid certificates within 39 months of the effective
> date, after which time, application software vendors can remove
> support.

I certainly agree that this is the goal. And, insofar as the BRs are
only meaningful to CAs because root program policy requires it, we need
to make sure that Mozilla's application of the BRs is correctly scoped.

Perhaps it would be worth revisiting the reasons why technically
constrained sub-CAs were excluded from Mozilla policy. As I remember,
this was a privacy requirement - CAs wanted to be able to have some
sub-CAs which were not publicly disclosed, as Mozilla policy was set to
require. The compromise reached was that public disclosure was not
necessary if the sub-CA were name-constrained. Am I correct in this, or
were there other reasons? Are there parts of Mozilla's policy and/or the
BRs that it would be reasonable for such sub-CAs to be exempt from?

If privacy was the extent of the issue, would it solve the problem to
change bullet 8 of the inclusion policy as follows?

8. All certificates that are capable of being used to issue new
certificates, and which directly or transitively chain to a certificate
included in Mozilla’s CA Certificate Program, MUST be operated in
accordance with Mozilla’s CA Certificate Policy and MUST either be
technically constrained or be publicly disclosed and audited.

->

8. All certificates that are capable of being used to issue new
certificates, and which directly or transitively chain to a certificate
included in Mozilla’s CA Certificate Program, MUST be operated in
accordance with Mozilla’s CA Certificate Policy (including being
included in audits) and MUST either be technically constrained or be
publicly disclosed.

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

Re: Technically Constrained Sub-CAs and the BRs

[Nick Lamb]

On Wednesday, 26 October 2016 02:31:07 UTC+1, Ryan Sleevi  wrote:
> Yes. There is no obligation or expectation, presently communicated, to revoke 
> extant certificates. Indeed, CAs were adamantly opposed to such a 
> requirement. So these certificates will still very much be valid.

Ah yes, I had muddled this with the obligation to revoke remaining certificates 
for non-Internet addresses (e.g. example.corp, 10.20.30.40) at the start of 
this month for which it's on my TODO list to verify the extent of compliance. 
So this would be a significant risk.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs and the BRs

[Ryan Sleevi]

On Tuesday, October 25, 2016 at 4:56:57 PM UTC-7, Nick Lamb wrote:
> Is it possible for someone to write up the details of the non-compliant 
> issuances and so on ? I would find it much easier to comment on the 
> particulars of 1311200 if they were more specific.

This doesn't seem relevant; that is, the specifics of 1311200 are irrelevant, 
so much as we're discussing BR non-compliance. Even if the issues are seen as 
technically trivial, we have an inconsistency the deserves some degree of 
guidance.

> Unless I'm missing something, these constrained certificates pose a much 
> smaller risk under our expected threat model for SHA-1.

I think you're missing a key purpose of the sunset date of 1/1/2016, which 
perhaps wasn't as clearly communicated outside the Forum.

The purpose of having a date for no new issuance, and distinct from full 
distrust of SHA-1, was to allow a graduated fade-out without having a giant 
flag day of disruption, which would then also suffer from the first-mover 
problem due to browsers non-uniform schedules.

That is, had we simply stated 1/1/2017 as the date SHA-1 was turned off, we 
would have seen continued issuance up to that day. As a result, turning it off 
would have broken huge numbers of sites - and for compatibility reasons, been 
re-enabled. This isn't theoretical either - we saw this both with attempts to 
deprecate MD5 (which lacked such a schedule) and with Mozilla's attempts to 
disable new SHA-1 certificates.

So I think the remaining discussion of the technical details of a SHA-1 
collision are largely immaterial, because the point I was making about it, and 
apologies for not being clearer on this, was that some of the things we 
deprecate in the CA/Browser Forum so that browsers can eventually remove 
support for the (insecure) thing, while minimizing disruption/breakage of sites.

As a further example, consider the requirement that a subjectAltName field be 
present, and that the CN field, if present, contains a value represented in the 
SAN. The entire purpose of such a requirement is to ensure that the technical 
representation of authorized hosts uses an unambiguous representation (which 
dNSName and iPAddress are), rather than the ambiguous heuristic of CN. This 
goal itself was expressed as far back as 1999, in RFC 2818, but it still took 
15 years after that (2014) before it actually became standard practice of CAs, 
and only then, because of the Baseline Requirements.

In spite of this, we still see CAs issuing certs lacking a SAN, which 
potentially means applications still need to support these certs (for another 
~3 years). While Mozilla has taken steps to phase this practice out, they're 
only doing it on the basis of a notBefore of *this* year, in order to minimize 
breakage.

So we certainly know that Mozilla's policies are, in some ways, designed to 
minimize the number of errors that users are presented with, by allowing a 
gradual fade out of insecure or undesirable practices. A change in the BRs is, 
in theory, supposed to be fully reflected in all valid certificates within 39 
months of the effective date, after which time, application software vendors 
can remove support.

An interpretation that suggests TCSCs don't have to abide by these policies - 
which Mozilla policy implies, but the BRs prohibit - means that any such 
deprecations do not apply to TCSCs, and as a consequence, such things bear a 
greater compatibility risk when they are removed. If we imagine a world with 
millions of TCSCs - something that the TLS WG has expressed interest in, in the 
past - potentially means breakage for millions of sites, and means that the 
path of deprecating things via the CA/Browser Forum may no longer be a viable 
solution to minimizing user disruption.

Does that more concretely express the concerns, which are more fundamental than 
specifics about commonNames or SHA-1?

> Finally, as I understand it the hypothetical SHA-1 TSCSs would be revoked 
> along with any other still extant SHA-1 certificates by the issuing CA, 
> before the planned Firefox 51 public release. So I don't think this would 
> imperil the planned action in Firefox 51. Am I wrong about that ?

Yes. There is no obligation or expectation, presently communicated, to revoke 
extant certificates. Indeed, CAs were adamantly opposed to such a requirement. 
So these certificates will still very much be valid.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs and the BRs

[Nick Lamb]

On Tuesday, 25 October 2016 21:16:36 UTC+1, Ryan Sleevi  wrote:
> The linked bug is a concrete example, where an unconstrained sub-CA was 
> revoked, due to non-compliance with the BRs, but has now been cross-certified 
> as a constrained sub-CA. All of these non-BR compliant certificates are now 
> valid, by utilizing the technically constrained path. From a Mozilla policy, 
> what are the implications of this new cross-certified constrained sub-CA?

Is it possible for someone to write up the details of the non-compliant 
issuances and so on ? I would find it much easier to comment on the particulars 
of 1311200 if they were more specific.

> A very concrete example of the implications of this relate to SHA-1 
> certificates. If, prior to Dec 31, 2015, CAs had issued some N-million TCSCs, 
> signed with SHA-1, to all parties that wished to keep issuing SHA-1, could 
> these TCSCs have continued issuing SHA-1 certificates without violating the 
> Mozilla requirements? One interpretation is that yes, they could have, at 
> least from Mozilla policy. However, from the BRs, the answer is that no, they 
> couldn't have.

Unless I'm missing something, these constrained certificates pose a much 
smaller risk under our expected threat model for SHA-1.

We suppose a bad guy can (or will soon be able to) pull off a chosen prefix 
attack on SHA-1 enabling them to trick a CA into signing document A and then 
use its signature on document B successfully.

Back when this happened for MD5, many CAs were issuing from roots, or at best 
from completely unconstrained intermediates, just because. The attack was used 
to produce a working unconstrained CA:TRUE certificate. One successful attack 
translated into unlimited issuing power across all of the Web PKI. It seem 
eminently reasonable to believe this one certificate might be extremely 
valuable to criminals with an effective plan to exploit it before any effective 
remedy is deployed, and everybody in the Web PKI (which is now basically 
everyone) is put at risk.

In contrast for the TCSCs a successful attack would produce /at best/ another 
constrained intermediate, and in most cases I've seen not even a working 
CA:TRUE certificate but just some arbitrary wildcard end entity certificate for 
a subset of the constrained names. The attack must also be launched against 
infrastructure controlled by the very organisation the certificates will be 
used to impersonate, not some unrelated third party as with the MD5 attacks.

Finally, as I understand it the hypothetical SHA-1 TSCSs would be revoked along 
with any other still extant SHA-1 certificates by the issuing CA, before the 
planned Firefox 51 public release. So I don't think this would imperil the 
planned action in Firefox 51. Am I wrong about that ?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs and the BRs

[Kurt Roeckx]

On Tue, Oct 25, 2016 at 12:12:47PM -0700, Ryan Sleevi wrote:
> That is, according to the BRs, the issuer of a technically constrained 
> subordinate CA has a BR-obligation to ensure that their TCSCs are adhering to 
> the BRs and the issuing CA's policies and practices, as well as conduct a 
> sampling audit quarterly.

My expection of this is that the CA (CA1) that issued such a
constrained CA (CA2) is responsible for auditing CA2. when CA is
then audited, part of that audit is that they check that the
audits of CA2 have been done.


Kurt

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