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: Guang Dong Certificate Authority (GDCA) root inclusion request

[Jakob Bohm]

On 17/11/2016 12:19, Gervase Markham wrote:

Hi Kathleen,

On 15/11/16 00:51, Kathleen Wilson wrote:

There were some recommendations to deny this request due to the
versioning problems between the English documents and the original
documents.

Do you all still feel that is the proper answer to this root
inclusion request?


As I understand it, what happened was as follows:

* As part of their application, GDCA provided both Chinese and English
versions of their CP/CPS, posted to m.d.s.policy on 3rd August:

Chinese CP: http://www.gdca.com.cn/cp/cp
Chinese CPS: http://www.gdca.com.cn/cps/cps
English CP: https://bugzilla.mozilla.org/attachment.cgi?id=8650346
English CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8688749

(I don't immediately have URLs for their EV CP and CPS in Chinese or
English from the original submission.)

* On 26th September, it was pointed out by Andrew Whalley that the
English versions had lower version numbers than the Chinese versions
(CP: 1.2 vs. 1.4; CPS: 4.1 vs 4.3)

* On 27th September, one day later, GDCA provided new English versions
with the same version numbers as the Chinese versions:

CP V1.4: https://bugzilla.mozilla.org/attachment.cgi?id=8795090
CPS V4.3: https://bugzilla.mozilla.org/attachment.cgi?id=8795091
EV CP V1.2: https://bugzilla.mozilla.org/attachment.cgi?id=8795093
EV CPS V1.3: https://bugzilla.mozilla.org/attachment.cgi?id=8795094

* It was pointed out by more than one person that there were significant
content differences between the English and Chinese versions which were
both labelled with the same version number

* GDCA said this was due to a "poor CP/CPS English translation" and on
28th October, provided new English versions (again) with the same
version numbers

CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543
CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8805545
EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546
EV CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8805547

What Mozilla has to decide is whether this was incompetence or malice.
Were GDCA trying to hide something? If so, their inclusion must be in
doubt. If they were not trying to hide something and just need a lesson
in version control, that is not necessarily something which
disqualifies, although it does give one concern.



I believe their overall excuses can be rephrased as:

1. The previous Mozilla policy guidance only requiring a partial
  translation.  Mozilla has since fixed that, though I can't find
  the posting that mentioned that document fix.

2. Sloppy translation work, including sloppyness when trying to quickly
  update the 4.1 translation to match the 4.3 Chinese documents.

3. At the time, the English translations were not version controlled,
  only the Chinese versions.  They have promised to change this for the
  next version, where they will even request an outside audit of the
  translation.

4. That consistent pair of a new CP/CPS in Chinese and English has not
  been posted yet, indicating that Mozilla will just have to put the
  inclusion request on hold until then.

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]

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: Include Symantec-brand Class 1 and Class 2 Root Certs

[Tarah Wheeler]

Thanks, Jakob; I'll try and replicate that to check. 

Tarah Wheeler
Principal Security Advocate
Senior Director of Engineering, Website Security
Symantec
ta...@symantec.com


> On Nov 17, 2016, at 2:13 AM, "dev-security-policy-requ...@lists.mozilla.org" 
>  wrote:
> 
> Re: Include Symantec-brand Class 1 and Class 2 Root Certs
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Han Yuwei]

在 2016年11月16日星期三 UTC+8下午3:59:12，wangs...@gmail.com写道：
> 在 2016年11月16日星期三 UTC+8上午1:11:05，Han Yuwei写道：
> > 在 2016年11月15日星期二 UTC+8下午7:03:07，wangs...@gmail.com写道：
> > > 在 2016年11月15日星期二 UTC+8上午8:51:25，Kathleen Wilson写道：
> > > > On Friday, October 28, 2016 at 7:29:56 AM UTC-7, wangs...@gmail.com 
> > > > wrote:
> > > > > We have uploaded the lastest translantion of CP/CPS.
> > > > > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543
> > > > > CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545
> > > > > EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546
> > > > > EV CPS: 
> > > > > https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547
> > > > > 
> > > > > Because of our English level, there maybe some mistakes. If you have 
> > > > > any questions, please contact us.
> > > > 
> > > > 
> > > > Thanks to all of you who have reviewed and commented on this request 
> > > > from Guangdong Certificate Authority (GDCA) is to include the "GDCA 
> > > > TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit, and 
> > > > enabled EV treatment. 
> > > > 
> > > > There were some recommendations to deny this request due to the 
> > > > versioning problems between the English documents and the original 
> > > > documents. 
> > > > 
> > > > Do you all still feel that is the proper answer to this root inclusion 
> > > > request?
> > > > 
> > > > Or should we proceed with reviewing these new English translations of 
> > > > the documents, and make our decision based on the new versions?
> > > > 
> > > > Thanks,
> > > > Kathleen
> > > 
> > > Because we misunderstand that we only need to provide the related 
> > > chapters of CP/CPS in English, and non-related sections are not required. 
> > > We are terribly sorry that we misinterpreted your requirement and upload 
> > > an inconsistent CP/CPS in English. Someone inferred that we don’t utilize 
> > > a version control for CP/CPS. In fact, we do have a strict control for 
> > > master version CP/CPS (see section 1.5 in CP/CPS).
> > > We understand that it is our responsibility to provide accurate English 
> > > versions and ensure consistency and synchronicity between Chinese and 
> > > English versions. Hence, we have decided to strictly implement version 
> > > controlling of English version CP/CPS according to section 1.5 in CP/CPS. 
> > > The auditor is reviewing our complete CP/CPS in English and the new 
> > > version will be published as soon as possible.
> > > We will keep open mind to process any further issues.
> > 
> > Ok, this is what I want to see. Maybe next time you could be more specific 
> > about the problems and not just like "translation problem". If you can't 
> > describe your opinion exactly in English you can use Chinese and let others 
> > translate. But it's best for you to hire a professional translator.
> > Since CPS is very critical, I hope you understand what I said before. I 
> > don't want another Wosign incident happen again.
> 
> Thanks for proposing many good questions, which push us to utilize version 
> controls for English CP/CPS. We are looking forward to your further comments 
> and suggestions. 
> We plan to attend the CA/B Forum meetings in February next year, If it is 
> lucky to meet you there, we are looking forward to have your consultation and 
> suggestions.

So are you going to conduct a complete investgation about this? I am still 
waiting for it.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Gervase Markham]

Hi Kathleen,

On 15/11/16 00:51, Kathleen Wilson wrote:
> There were some recommendations to deny this request due to the
> versioning problems between the English documents and the original
> documents.
> 
> Do you all still feel that is the proper answer to this root
> inclusion request?

As I understand it, what happened was as follows:

* As part of their application, GDCA provided both Chinese and English
versions of their CP/CPS, posted to m.d.s.policy on 3rd August:

Chinese CP: http://www.gdca.com.cn/cp/cp
Chinese CPS: http://www.gdca.com.cn/cps/cps
English CP: https://bugzilla.mozilla.org/attachment.cgi?id=8650346
English CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8688749

(I don't immediately have URLs for their EV CP and CPS in Chinese or
English from the original submission.)

* On 26th September, it was pointed out by Andrew Whalley that the
English versions had lower version numbers than the Chinese versions
(CP: 1.2 vs. 1.4; CPS: 4.1 vs 4.3)

* On 27th September, one day later, GDCA provided new English versions
with the same version numbers as the Chinese versions:

CP V1.4: https://bugzilla.mozilla.org/attachment.cgi?id=8795090
CPS V4.3: https://bugzilla.mozilla.org/attachment.cgi?id=8795091
EV CP V1.2: https://bugzilla.mozilla.org/attachment.cgi?id=8795093
EV CPS V1.3: https://bugzilla.mozilla.org/attachment.cgi?id=8795094

* It was pointed out by more than one person that there were significant
content differences between the English and Chinese versions which were
both labelled with the same version number

* GDCA said this was due to a "poor CP/CPS English translation" and on
28th October, provided new English versions (again) with the same
version numbers

CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543
CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8805545
EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546
EV CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8805547

What Mozilla has to decide is whether this was incompetence or malice.
Were GDCA trying to hide something? If so, their inclusion must be in
doubt. If they were not trying to hide something and just need a lesson
in version control, that is not necessarily something which
disqualifies, although it does give one concern.

Looking at the CPS (using pdf2txt and diff), the differences between the
originally-submitted v4.1 and the first 4.3 are very minor. One
intermediate certificate changes name throughout, as does the name of
GDCA. Three certs in an appendix are replaced with others. Other than
that, the only changes are these:

https://gist.github.com/gerv/fc311785c49c7fdfdfba78d6d5ad4aa9

This seems like an odd change, removing specificity about how domain
validation is done. This change was _added_ to the Chinese version of
3.2.5 between 4.1 and 4.2, and moved to section 3.2.7 in version 4.3. So
how does going from 4.1 to 4.3 in the English version lead to it being
removed?

The differences between the first 4.3 and the second one are much more
extensive.

So I'd say the questions for GDCA are these:

* When you were asked to produce a version of your CPS matching Chinese
version 4.3, within a day you came up with:
https://bugzilla.mozilla.org/attachment.cgi?id=8795091
That clearly doesn't match Chinese version 4.3, and yet it has "version
4.3" written in it. And the effective date marked within it is one month
_earlier_ than the effective date of the Chinese 4.3. How did this
happen? How did such a document come to exist with such a version number
and date attached, when it is so massively different from the real 4.3,
and so similar to the previous 4.1?

* You say you only translated the relevant bits rather than all of it,
which is why there is a discrepancy, but the diff between 4.1 and the
first version of 4.3 reveals no additions, only one deletion. How does
that fit?

Gerv

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