Configuring Graduated Trust for Non-Browser Consumption

[Cory Benfield]

All,

While this ongoing discussion regarding Symantec is going on, I wanted to chime in quickly to make a suggestion about graduated trust. Many of the proposals that Mozilla, Google, and other teams running CA programs put forward in cases of CA misbehaviour is to transition a CA from “trusted” to “partially trusted”: that is, to explicitly distrust certain CA-issued certificates that would ordinarily be trusted. For example, one of the WoSign remediations was to distrusted new WoSign certificates: that is, certificates whose notBefore date was after a certain date.

While I’m very supportive of this kind of remediation, it is not a remediation that non-browser implementations can follow very easily. For example, I run a downstream non-browser HTTP client[1] that by default uses a processed version of the Mozilla CA database[2] to define its list of trusted roots. This is very convenient, as it allows me to delegate the job of running a CA program to Mozilla and MDSP, a collection of people much better equipped to handle the job. This is a common approach throughout the open source ecosystem: for example, curl also makes available a processed version of the Mozilla trust database.

Unfortunately, it is currently *not* possible to distribute any kind of partial trust information: that is, tools that consume the Mozilla trust database can only completely trust, or completely distrust, a CA. That means that non-browser tools cannot follow the guidance of MDSP or Mozilla, even though we’d very much like to. In practice, this means that we will almost always continue to trust certificates that browsers would not. This prevents us from providing a unified front on this issue, and also exposes our users to risk from misbehaving CAs that we continue to trust to issue new certificates, even though Mozilla would not. We’d like to follow your lead on this: however, it’s just beyond our resources to keep writing custom code to handle these cases each time they come up.

If Mozilla is interested in doing a substantial public service, this situation could be improved by having Mozilla and MDSP define a static configuration format that expresses the graduated trust rules as data, not code. Essentially, a file could exist beside the list of root CA certificates that notes any graduated trust rules (e.g. must have notBefore earlier than x, must contain signatures without these hash algorithms, etc.) that would be used by Firefox to build its graduated trust rules. That file could then be distributed with processed versions of the Mozilla trust database, and tools that are able to understand it could apply the graduated trust rules that Mozilla is applying as well.

This is just a suggestion: defining, writing, and maintaining this config file would be a decent amount of work and would provide pretty minimal benefit to Mozilla directly. I wouldn’t be at all surprised to find that this is not something Mozilla is interested in pursuing. However, I think it would be of substantial value to the wider HTTP and TLS community if we were able to form a unified front with Mozilla in trusting CAs.

Thanks,

Cory

[co...@lukasa.co.uk]

On Thursday, May 11, 2017 at 3:21:41 PM UTC+1, Cory Benfield wrote:

> While I’m very supportive of this kind of remediation, it is not a remediation that non-browser implementations can follow very easily. For example, I run a downstream non-browser HTTP client[1] that by default uses a processed version of the Mozilla CA database[2] to define its list of trusted roots. This is very convenient, as it allows me to delegate the job of running a CA program to Mozilla and MDSP, a collection of people much better equipped to handle the job. This is a common approach throughout the open source ecosystem: for example, curl also makes available a processed version of the Mozilla trust database.

I find it's useful to actually provide the footnotes you say you will:

[1]: http://docs.python-requests.org/en/master/
[2]: https://github.com/certifi/python-certifi

[Ryan Sleevi]

But if you use the trust database without using NSS, you no longer fit into
any of the assumptions or security models with the discussions here on
m.d.s.p.

A good example of this would be EKU related misissuance. NSS, like
CryptoAPI and several other platforms, has for the past 15 or so years
enforced a constraint that EKUs in intermediates are subsets of their
issuer's, and can be used to reduce the scope of capabilities for issuance.

As a result, a certificate with an S/MIME EKU issued from an intermediate
that only has id-kp-serverAuth is not at risk of being trusted for S/MIME.

In many ways, and across the industry, the trust Store is a function of the
consuming and implementing libraries. As features change and are
implemented - for example, support for Certificate Transparency - that
naturally changes the risk calculus in the trust store.

That's not to say what you request is apriori unreasonable, simply that
it's unwise, which is why the FAQ covers this -
https://wiki.mozilla.org/CA:FAQ

There's also the reality that some changes are entirely appropriate for
browser clients, but since Mozilla themselves are not using NSS in
non-browser clients, but are aware that others are, they allow these other
organizations and clients to make the decisions appropriate for their
products and the risks and compatibility issues to their clients.

The historic process is generally that a change is first made to Firefox,
and then if it is generally desired by the ecosystem, trust status flags
are introduced to NSS and added to the root store and library code. For
example, the constraints for ANSSI followed this pattern.

Microsoft follows a similar pattern - all "less than trusted" statuses are
captured as extended attributes in the publicly available authroot.stl

However, for both NSS and CryptoAPI, unless you are using the library
itself to do verification, it's caveat emptor as the consumer. And even if
you are using the library, you still have to be responsible for the
security of your users as relevant to your products needs, and that's
something Mozilla doesn't necessarily have insight into and naturally can't
consider unless you participate here (ideally with commenting on proposals
or sharing what your product would do). Although I suspect since most
non-browser clients are more stable/less likely to update, and have less UI
affordances, the general answer would be biased conservatively towards
doing nothing than the steps necessary to protect browser users.

On Thu, May 11, 2017 at 7:33 AM Cory Benfield via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Thursday, May 11, 2017 at 3:21:41 PM UTC+1, Cory Benfield wrote:
>

> > While I’m very supportive of this kind of remediation, it is not a
> remediation that non-browser implementations can follow very easily. For
> example, I run a downstream non-browser HTTP client[1] that by default uses
> a processed version of the Mozilla CA database[2] to define its list of
> trusted roots. This is very convenient, as it allows me to delegate the job
> of running a CA program to Mozilla and MDSP, a collection of people much
> better equipped to handle the job. This is a common approach throughout the
> open source ecosystem: for example, curl also makes available a processed
> version of the Mozilla trust database.
>

> I find it's useful to actually provide the footnotes you say you will:
>
> [1]: http://docs.python-requests.org/en/master/
> [2]: https://github.com/certifi/python-certifi

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Alex Gaynor]

Ryan,

I think you've correctly highlighted that there's a problem -- the Mozilla
CA store is "designed" to be consumed from NSS, and CA-specific
remediations are a part of that (hash algorithms, maximum certificate
lifetimes, and any number of other important technical controls).

Unfortunately, we're currently in a position where near as I can tell, most
code (except Go code :P) making HTTPS requests are using a Mozilla-derived
CA store, and OpenSSL's verifier, which only provides a subset of the
technical controls browsers implement. This is unfortunate, particular
because these clients also do not check CT, so it's entirely possible to
serve them certs which are not publicly visible. In a large sense, browsers
currently act as canaries-in-the-coalmine, protecting non-browser clients.

Like Cory, I help maintain non-browser TLS clients. To that end, I think
it'd be outstanding if as a community we could find a way to get more of
these technical controls into non-browser clients -- some of this is just
things we need to do (e.g. add hash algorithm and lifetime checking to
OpenSSL or all consumers of it), other's need coordination with Mozilla's
root program, and I think Cory's proposal highlights one way of making that
happen.

Alex

> > > While I’m very supportive of this kind of remediation, it is not a
> > remediation that non-browser implementations can follow very easily. For
> > example, I run a downstream non-browser HTTP client[1] that by default
> uses
> > a processed version of the Mozilla CA database[2] to define its list of
> > trusted roots. This is very convenient, as it allows me to delegate the
> job
> > of running a CA program to Mozilla and MDSP, a collection of people much
> > better equipped to handle the job. This is a common approach throughout
> the
> > open source ecosystem: for example, curl also makes available a processed
> > version of the Mozilla trust database.
> >

[Ryan Sleevi]

On Thu, May 11, 2017 at 11:57 AM, Alex Gaynor via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Ryan,
>
> I think you've correctly highlighted that there's a problem -- the Mozilla
> CA store is "designed" to be consumed from NSS, and CA-specific
> remediations are a part of that (hash algorithms, maximum certificate
> lifetimes, and any number of other important technical controls).
>
> Unfortunately, we're currently in a position where near as I can tell, most
> code (except Go code :P) making HTTPS requests are using a Mozilla-derived
> CA store, and OpenSSL's verifier, which only provides a subset of the
> technical controls browsers implement. This is unfortunate, particular
> because these clients also do not check CT, so it's entirely possible to
> serve them certs which are not publicly visible. In a large sense, browsers
> currently act as canaries-in-the-coalmine, protecting non-browser clients.
>
> Like Cory, I help maintain non-browser TLS clients. To that end, I think
> it'd be outstanding if as a community we could find a way to get more of
> these technical controls into non-browser clients -- some of this is just
> things we need to do (e.g. add hash algorithm and lifetime checking to
> OpenSSL or all consumers of it),

Yes :) There's a significant amount that needs to happen in the third-party
verifiers to understand and appreciate the risk of certain behaviours ;)

> other's need coordination with Mozilla's
> root program, and I think Cory's proposal highlights one way of making that
> happen.

Right, but these already flow into the NSS trust store - when appropriate.
I'm sure you can understand when a piece of logic is _not_ implemented in
NSS (e.g. because it's not generic beyond the case of browsers), that it
seems weird to put it in/expose it in NSS :)

To be clear: I'm not trying to suggest it's an entirely unreasonable
request, merely an explanation of the constraints around it and why the
current approach is employed that tries to balance what's right for Mozilla
users and the overall NSS using community :)

[Gervase Markham]

Hi Cory,

On 11/05/17 15:21, Cory Benfield wrote:
> While I’m very supportive of this kind of remediation, it is not a remediation that non-browser implementations can follow very easily.

Unfortunately, this is not a good enough reason to remove graduate trust
proposals from our arsenal of possible remedies for issues. Because if
the choice is only "trust everything" or "do not trust anything" from a
particular root, we have no mitigations for the Too Big To Fail problem.

> If Mozilla is interested in doing a substantial public service, this situation could be improved by having Mozilla and MDSP define a static configuration format that expresses the graduated trust rules as data, not code.

The trouble with this is that the vocabulary of such a format is almost
unbounded. It effectively has to be code, rather than data, because we
could in the future make any number of rules about certificates based on
any number of criteria.

So we decided to use English instead, which is why this exists:
https://wiki.mozilla.org/CA/Additional_Trust_Changes

Gerv

[Alex Gaynor]

On Thu, May 11, 2017 at 1:03 PM, Gervase Markham via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Hi Cory,
>
> On 11/05/17 15:21, Cory Benfield wrote:

> > While I’m very supportive of this kind of remediation, it is not a
> remediation that non-browser implementations can follow very easily.
>

> Unfortunately, this is not a good enough reason to remove graduate trust
> proposals from our arsenal of possible remedies for issues. Because if
> the choice is only "trust everything" or "do not trust anything" from a
> particular root, we have no mitigations for the Too Big To Fail problem.
>

I don't think Cory's arguing against browsers making use of these types of
remediations, he just wants the non-browser clients to be able to
participate as well :-)

>
> > If Mozilla is interested in doing a substantial public service, this
> situation could be improved by having Mozilla and MDSP define a static
> configuration format that expresses the graduated trust rules as data, not
> code.
>

> The trouble with this is that the vocabulary of such a format is almost
> unbounded. It effectively has to be code, rather than data, because we
> could in the future make any number of rules about certificates based on
> any number of criteria.
>
> So we decided to use English instead, which is why this exists:
> https://wiki.mozilla.org/CA/Additional_Trust_Changes
>
> Gerv
>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

Alex

[Gervase Markham]

On 11/05/17 18:05, Alex Gaynor wrote:
> I don't think Cory's arguing against browsers making use of these types of
> remediations, he just wants the non-browser clients to be able to
> participate as well :-)

Sure. I'm just heading off that argument at the pass :-)

Gerv

[Cory Benfield]

> On 11 May 2017, at 19:27, Gervase Markham <ge...@mozilla.org> wrote:
>
> On 11/05/17 18:05, Alex Gaynor wrote:

>> I don't think Cory's arguing against browsers making use of these types of
>> remediations, he just wants the non-browser clients to be able to
>> participate as well :-)
>

> Sure. I'm just heading off that argument at the pass :-)

Yeah, Alex is right. I’m *extremely* supportive of the graduated trust proposals: indeed, I think MDSP’s behaviour and remedies have been exemplary. I was just feeling out the possibility of Mozilla turning into a force multiplier.

Cory

[Alex Gaynor]

I think you left this a bit implicit Cory, so I figured it's worth spelling
out: the strength of Mozilla's CA program, as a tool for making the web
stronger, comes from having people using it, that's the carrot that forces
people to meet our standards (also the fact that as a transparent, root
program, we serve as a model for the industry!). If we can get better at
including the non-browser clients, who are already using the "raw" trust
store, it only strengthens our ability to secure the web -- I think we can
all agree that's a good goal :-)

As you point out though, a huge challenge, is that historically CA-specific
remediations have been unique to the circumstances, which means any
remediaton we invent a syntax for may be used only once, and any new CA
misbehavior may necessitate a remediation we don't have a syntax for yet.

I'm not smart enough to come up with a solution for this, other than that
maybe if we repeat the process enough times, we'll eventually standardize
on a small set of core remediations -- hopefully we never get there though
:-)

Alex

On Thu, May 11, 2017 at 2:30 PM, Cory Benfield <co...@lukasa.co.uk> wrote:

>
> > On 11 May 2017, at 19:27, Gervase Markham <ge...@mozilla.org> wrote:
> >
> > On 11/05/17 18:05, Alex Gaynor wrote:

> >> I don't think Cory's arguing against browsers making use of these types
> of
> >> remediations, he just wants the non-browser clients to be able to
> >> participate as well :-)
> >

[Nick Lamb]

Cory, from your point of view is there interest in being able to tell Requests "I want the no-compromises trust store" and accept a reduced compatibility in exchange for knowing that you're a little safer ?

Right now, as a programmer I have three choices with Requests:

Verify=True: The default, the store you've described, based on NSS but lacking its nuance, will be used to perform verification of host certificates

Verify='/a/filename': I must maintain my own trust store, which is a huge pain in the backside.

Verify=False: All verification is switched off. Here be dragons.

In Firefox there is no interest in making users lives more complicated by introducing more decisions. But a programmer writing code with Requests and getting as far as reading the documentation for certifi already _does_ care about these decisions. I'm sure the same is true for programmers in other environments.

In contrast to the idea of trying to get other clients to implement all the nuances of Firefox's graduated trust, my idea here is to promote the option of deliberately distrusting CAs entirely in these clients, ahead of any such extreme sanction from Mozilla in Firefox. Mozilla could decide (or not) to add an advisory mark when putting in place a graduated trust and this would mean the maintenance burden to offer both an ordinary and a "no-compromise" trust store with something like Requests would be minimal, just verify=certifi.I_HATE_FUN or whatever.

[Kurt Roeckx]

On 2017-05-11 17:57, Alex Gaynor wrote:
> Ryan,
>
> I think you've correctly highlighted that there's a problem -- the Mozilla
> CA store is "designed" to be consumed from NSS, and CA-specific
> remediations are a part of that (hash algorithms, maximum certificate
> lifetimes, and any number of other important technical controls).
>
> Unfortunately, we're currently in a position where near as I can tell, most
> code (except Go code :P) making HTTPS requests are using a Mozilla-derived
> CA store, and OpenSSL's verifier, which only provides a subset of the
> technical controls browsers implement. This is unfortunate, particular
> because these clients also do not check CT, so it's entirely possible to
> serve them certs which are not publicly visible. In a large sense, browsers
> currently act as canaries-in-the-coalmine, protecting non-browser clients.
>
> Like Cory, I help maintain non-browser TLS clients. To that end, I think
> it'd be outstanding if as a community we could find a way to get more of
> these technical controls into non-browser clients -- some of this is just
> things we need to do (e.g. add hash algorithm and lifetime checking to
> OpenSSL or all consumers of it), other's need coordination with Mozilla's
> root program, and I think Cory's proposal highlights one way of making that
> happen.

From past discussion on the OpenSSL list, I understand that we want to
support a trust store that supports all such kind of attributes. Some
things like for what it's trusted are currently supported by using an
X509_AUX structure instead of an X509 structure but then OpenSSL is the
only thing that can read it, so this isn't really used.

What we need is a format that can be used by all libraries. It probably
needs to be extensible. It should probably support both all certificates
in 1 file and all in separate files.


Kurt

[Cory Benfield]

> On 11 May 2017, at 20:20, Nick Lamb via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> In contrast to the idea of trying to get other clients to implement all the nuances of Firefox's graduated trust, my idea here is to promote the option of deliberately distrusting CAs entirely in these clients, ahead of any such extreme sanction from Mozilla in Firefox. Mozilla could decide (or not) to add an advisory mark when putting in place a graduated trust and this would mean the maintenance burden to offer both an ordinary and a "no-compromise" trust store with something like Requests would be minimal, just verify=certifi.I_HATE_FUN or whatever.

I try not to decide whether there is interest in features like this: if they’re easy I’d just implement them and let users decide if they want it. That’s what I’d be inclined to do here. If Mozilla added such a flag, I’d definitely be open to adding an extra certifi bundle. Certifi currently already ships with two bundles (one labelled “weak”, which includes 1024-bit roots to work around problems with older OpenSSLs), so we could easily add a third called “strong” or “pedantic” or “I hate CAs” or something that removes any CA that is subject to graduated trust in Firefox.

So, yeah, if Mozilla was interested in adding such a flag, I’d be interested in using it to build alternative trust stores.

Cory

[Jakob Bohm]

Could something be derived from / based on the ASN.1 format apparently
used by Microsoft in it's root store, with OpenSSL/Mozilla OIDs added
for things that have no Microsoft notation yet.

Another starting point (if not the same) could be the "trusted
certificate" format that some openssl commands can generate.

Ideally in the future, code support for a new restriction type can be
implemented (in both NSS and other libraries) before the community
decision to enforce that restriction against a given CA comes into
effect. For example, some time has already passed since Google
proposed their set of Symantec restrictions, but the trigger has not
been pulled yet on any of those.

Just for clarity, could you confirm that the current (1.0.2 / 1.1.0)
OpenSSL verifiers do not check if issuing CA has a conflicting EKU list?


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

[Ryan Sleevi]

On Fri, May 12, 2017 at 1:50 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Could something be derived from / based on the ASN.1 format apparently
> used by Microsoft in it's root store, with OpenSSL/Mozilla OIDs added
> for things that have no Microsoft notation yet.
>

Why? It's a poor format.

> Another starting point (if not the same) could be the "trusted
> certificate" format that some openssl commands can generate.
>

Why? It's a poor format.

You missed that NSS already has these expressions in the form that is
appropriate for NSS. Why change?

[Kurt Roeckx]

On Fri, May 12, 2017 at 07:50:46PM +0200, Jakob Bohm via dev-security-policy wrote:
> On 12/05/2017 10:06, Kurt Roeckx wrote:

> > From past discussion on the OpenSSL list, I understand that we want to
> > support a trust store that supports all such kind of attributes. Some
> > things like for what it's trusted are currently supported by using an
> > X509_AUX structure instead of an X509 structure but then OpenSSL is the
> > only thing that can read it, so this isn't really used.
> >
> > What we need is a format that can be used by all libraries. It probably
> > needs to be extensible. It should probably support both all certificates
> > in 1 file and all in separate files.
> >
>

> Could something be derived from / based on the ASN.1 format apparently
> used by Microsoft in it's root store, with OpenSSL/Mozilla OIDs added
> for things that have no Microsoft notation yet.
>

> Another starting point (if not the same) could be the "trusted
> certificate" format that some openssl commands can generate.

That would be the X509_AUX. It's a combination of a normal X509
followed by an X509_CERT_AUX that looks like:
ASN1_SEQUENCE(X509_CERT_AUX) = {
ASN1_SEQUENCE_OF_OPT(X509_CERT_AUX, trust, ASN1_OBJECT),
ASN1_IMP_SEQUENCE_OF_OPT(X509_CERT_AUX, reject, ASN1_OBJECT, 0),
ASN1_OPT(X509_CERT_AUX, alias, ASN1_UTF8STRING),
ASN1_OPT(X509_CERT_AUX, keyid, ASN1_OCTET_STRING),
ASN1_IMP_SEQUENCE_OF_OPT(X509_CERT_AUX, other, X509_ALGOR, 1)
} ASN1_SEQUENCE_END(X509_CERT_AUX)

As far as I know, openssl supports reading such files as either
just a plain X509 ignoring everything after it or as an X509_AUX.
Other libraries don't.

> Ideally in the future, code support for a new restriction type can be
> implemented (in both NSS and other libraries) before the community
> decision to enforce that restriction against a given CA comes into
> effect. For example, some time has already passed since Google
> proposed their set of Symantec restrictions, but the trigger has not
> been pulled yet on any of those.
>
> Just for clarity, could you confirm that the current (1.0.2 / 1.1.0)
> OpenSSL verifiers do not check if issuing CA has a conflicting EKU list?

It only checks it when you tell it to check for a purpose, in
which case it checks that all certificates can be used for that
purpose. But I guess most applications don't use that.


Kurt

[Jakob Bohm]

The topic of this thread is to get the information in a format
appropriate for use in *other* libraries, such as OpenSSL or
BouncyCastle, both of which are used in Android.

[Ryan Sleevi]

On Fri, May 12, 2017 at 2:15 PM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 12/05/2017 20:43, Ryan Sleevi wrote:

> The topic of this thread is to get the information in a format
> appropriate for use in *other* libraries, such as OpenSSL or
> BouncyCastle, both of which are used in Android.

I'm afraid that may be misstating things. The topic is to get the
information at all - which, in cases, it is made available in the NSS trust
DB.

How that is exported is something better suited for those applications, not
this list or discussion. The discussion here is whether that information is
consistently made available in the NSS trust DB (which has its own format)
at all.

I can see how those may be confusing, but hopefully with that clarification
you can understand the difference between discussing format versus
discussing functionality.

>
>

[Jakob Bohm]

This SubThread (going back to Kurt Roeckx's post at 08:06 UTC) is about
suggesting a good format for sharing this info across libraries though.
Discussing that on a list dedicated to a single library (such as NSS or
OpenSSL) would be pointless.

I am trying not to be overly technical in my suggestions, using
descriptive names for the formats rather than going into bits bytes and
source code.

[Ryan Sleevi]

On Fri, May 12, 2017 at 6:02 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> This SubThread (going back to Kurt Roeckx's post at 08:06 UTC) is about
> suggesting a good format for sharing this info across libraries though.
> Discussing that on a list dedicated to a single library (such as NSS or
> OpenSSL) would be pointless.
>

And in the original message, what was requested was

"If Mozilla is interested in doing a substantial public service, this
situation could be improved by having Mozilla and MDSP define a static
configuration format that expresses the graduated trust rules as data, not
code."

Mozilla does express such graduated trust rules as data, not code, when
possible. This is available with in the certdata.txt module data as
expressive records using the NSS vendor attributes.

Not all such requirements can be expressed as code, not data, but when
possible, Mozilla does. That consuming applications do not make use of that
information is something that consuming applications should deal with.

[Peter Bowen]

> On May 12, 2017, at 3:48 PM, Ryan Sleevi via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

>
> On Fri, May 12, 2017 at 6:02 PM, Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>>
>> This SubThread (going back to Kurt Roeckx's post at 08:06 UTC) is about
>> suggesting a good format for sharing this info across libraries though.
>> Discussing that on a list dedicated to a single library (such as NSS or
>> OpenSSL) would be pointless.
>>
>
> And in the original message, what was requested was

> "If Mozilla is interested in doing a substantial public service, this
> situation could be improved by having Mozilla and MDSP define a static
> configuration format that expresses the graduated trust rules as data, not
> code."
>

> Mozilla does express such graduated trust rules as data, not code, when
> possible. This is available with in the certdata.txt module data as
> expressive records using the NSS vendor attributes.
>
> Not all such requirements can be expressed as code, not data, but when
> possible, Mozilla does. That consuming applications do not make use of that
> information is something that consuming applications should deal with.

One thing that doesn’t happen today but would likely be broadly compatible would be to replace certain self-signed root certs in the trust store with certs that appear to be cross-signed with restrictions. They could in reality have fixed values in the signature section, but this would allow adding constraints directly in certificate structure. Examples could include adding or modifying extensions such as extendedKeyUsage, nameConstraints, or private key usage period.

Thanks,
Peter

[Gervase Markham]

On 12/05/17 09:18, Cory Benfield wrote:
> I try not to decide whether there is interest in features like this:
> if they’re easy I’d just implement them and let users decide if they
> want it. That’s what I’d be inclined to do here. If Mozilla added
> such a flag, I’d definitely be open to adding an extra certifi
> bundle. Certifi currently already ships with two bundles (one
> labelled “weak”, which includes 1024-bit roots to work around
> problems with older OpenSSLs), so we could easily add a third called
> “strong” or “pedantic” or “I hate CAs” or something that removes any
> CA that is subject to graduated trust in Firefox.

If people actually care enough to make a root store choice, should we be
encouraging them instead to use a store containing only the CA they care
about for the connection they are making (and perhaps a backup)? In
other words, is some sort of easy-to-use root store filtering/splitting
tool a better solution to this issue?

Gerv

[Jakob Bohm]

That obviously wouldn't be any good where the intent is to accept
general third parties (just like the intent in a Browser).

It would also cause the specific problems with entities randomly stuck
at specific historic roots that are part of our current Symantec
dilemma.

[Alex Gaynor]

Once upon a time I would said "yes, we should totally encourage people to
lovingly craft their perfect trust store, to reduce their risk profile".
Now, not so much.

As we've seen in numerous discussions, customers of CAs, particularly large
enterprises and vendors (think payment terminals) love to pick out one or
two roots, ship them to a billion devices with no update capability, and
then use this as an argument against improvements to the WebPKI ecosystem
(e.g. SHA-1) or CA distrust (e.g. take a wild guess :-P). Hand crafted
trust stores are significantly less likely to have any hope of getting an
update than just shipping the whole Mozilla bundle. Further, with CT
enforcement, you can get basically the same security guarantee (only certs
I intend; +/- 24 hours) without burdening the ecosystem with your lack of
agility.

Cheers,
Alex

On Mon, May 15, 2017 at 9:19 AM, Gervase Markham via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 12/05/17 09:18, Cory Benfield wrote:

> > I try not to decide whether there is interest in features like this:
> > if they’re easy I’d just implement them and let users decide if they
> > want it. That’s what I’d be inclined to do here. If Mozilla added
> > such a flag, I’d definitely be open to adding an extra certifi
> > bundle. Certifi currently already ships with two bundles (one
> > labelled “weak”, which includes 1024-bit roots to work around
> > problems with older OpenSSLs), so we could easily add a third called
> > “strong” or “pedantic” or “I hate CAs” or something that removes any
> > CA that is subject to graduated trust in Firefox.
>

> If people actually care enough to make a root store choice, should we be
> encouraging them instead to use a store containing only the CA they care
> about for the connection they are making (and perhaps a backup)? In
> other words, is some sort of easy-to-use root store filtering/splitting
> tool a better solution to this issue?
>

[Ryan Sleevi]

On Mon, May 15, 2017 at 10:18 AM, Alex Gaynor via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Once upon a time I would said "yes, we should totally encourage people to
> lovingly craft their perfect trust store, to reduce their risk profile".
> Now, not so much.
>
> As we've seen in numerous discussions, customers of CAs, particularly large
> enterprises and vendors (think payment terminals) love to pick out one or
> two roots, ship them to a billion devices with no update capability, and
> then use this as an argument against improvements to the WebPKI ecosystem
> (e.g. SHA-1) or CA distrust (e.g. take a wild guess :-P). Hand crafted
> trust stores are significantly less likely to have any hope of getting an
> update than just shipping the whole Mozilla bundle. Further, with CT
> enforcement, you can get basically the same security guarantee (only certs
> I intend; +/- 24 hours) without burdening the ecosystem with your lack of
> agility.
>
> Cheers,
> Alex

An alternative solution to the ossification that Alex muses about is to
require that all CAs must generate (new) roots on some interval (e.g. 3
years) for inclusion. That is, the 'maximum' a root can be included in a
Mozilla product is 3 years (or less!)

What this does is it bounds the limit of badness (from these CAs) to 5
years. As a new CA is stood up for inclusion in Mozilla products, the
(existing) root can sign the (new) root. The third year the CA transitions
all new certificates to be issued from this (new) root, and starts the
inclusion process, so that by the fifth year, it can ubiquitously included
within Mozilla products.

That is, imagine you have the following scenario:

(old root) -> (old intermediate) -> (3 year leaf)

On Y3, you generate new root and new intermediate, and then cross-sign,
such that you have

(old root) -> (old intermediate) -> (old existing certs)
-> (new root) -> (new intermediate) -> (new leaf certs)

Sites can either rely on AIA (Ideal, but unfortunately, not yet supported
by Mozilla) or simply supply the full chain (less ideal, wasteful on
bandwidth and caching), of either

(site cert) -> (new intermediate) -> (new root) [the AIA path]
(site cert) -> (new intermediate) -> (new root) -> (old root) [the slow,
compatibility path]

The benefit here is that we can reasonably assume that the 'risk' profile
of a root is bounded to its 'acceptance within Mozilla' - here, at 3 years
of 'live' issuance, plus 2-3 years (depending on the max age of the cert)

For products that bake in roots, the CA can continue to support/maintain
them, as they essentially become 'private' PKI roots after some period of
time. Sites that need 'publicly trusted' certs, but also need to support
those old devices, can use the (new root) -> (old root) -> (older root) ->
(oldest root) [if we assume 12 year device lifecycle] - *provided* that the
new certs are supported on the old devices.

If the new certs aren't, then just cut a 'legacy' cert from the old device
- and know that Web clients cannot and should not be expected to support
these.

It forces agility into the system. The arguments against this is that it'd
be more work for the CAs (... for which I'm admittedly not sympathetic),
that it doesn't address cases where both old devices with old certs and new
devices/web users with new certs need to exist on the same endpoint (again,
I'm less sympathetic of this, in this modern age), and more work for
Mozilla (processing trust store changes). But this seems a good balance.

Most importantly, it systematically addresses the risk factors posed by
having 'ancient' roots included in modern clients - and all of those past
decisions affecting the security of up-to-date users. By ensuring agility
in the ecosystem, it substantially reduces that risk.

[Peter Gutmann]

Ryan Sleevi via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

>An alternative solution to the ossification that Alex muses about is to
>require that all CAs must generate (new) roots on some interval (e.g. 3
>years) for inclusion. That is, the 'maximum' a root can be included in a
>Mozilla product is 3 years (or less!)

Unless someone has a means of managing frequent updates of the root
infrastructure (and there isn't one, or at least none that work), this will
never fly. There's a reason why roots have 20-40 year lifetimes and why they
get on-sold endlessly across different owners rather than simply being
replaced when required.

Peter.

[Ryan Sleevi]

Mozilla updates every six to eight weeks. And that works. That's all that
matters for this discussion.

>
>

[Peter Gutmann]

Ryan Sleevi <ry...@sleevi.com> writes:

>Mozilla updates every six to eight weeks. And that works. That's all that
>matters for this discussion.

Do all the world's CAs know this?

Peter.

[Ryan Sleevi]

On Tue, May 16, 2017 at 7:19 AM, Peter Gutmann <pgu...@cs.auckland.ac.nz>
wrote:

Does that matter, if all participants in Mozilla's Root Program _could_
know this?

I can't help but feel you're raising concerns that aren't relevant. Perhaps
I didn't explain sufficiently why even if a client takes a single copy of
the Mozilla root store and *never updates after that*, things could still
work for 20+ years for those clients, and with reduced risk for Mozilla
users. I feel like if that point had been clearer, perhaps you would
understand why it could fly.

Perhaps you're confused and think the roots themselves have 5 year validity
(e.g. notBefore to notAfter). That's also not what I said - I said bound
the time for inclusion of that root in Mozilla products. They're very
different things, you see, and the latter doesn't prescribe the validity
period of the root - precisely so it can support such broken 'legacy' cases
without requiring too much of the world to adopt modern security practices.

That said, Mozilla's mission to ensure the Internet is a global public
resource that is safe would, among other things, entitle them to push this
particular vision, since it would help make users safe. However, I merely
proposed a smaller step in that.

Perhaps you could re-read the proposal with a fresh perspective, as I hope
it might become clearer how it could address many of these issues. As it
relates to the topic at hand, by limiting the lifetime of the roots
themselves, it reduces the risk/need to impose additional contraints -
there are fewer legacy roots, they're bounded in validity period, and
things move onward towards distrust much easier. That does seem a
net-positive for the ecosystem.

[Peter Gutmann]

Ryan Sleevi <ry...@sleevi.com> writes:

>I can't help but feel you're raising concerns that aren't relevant.

CAs issue roots with effectively infinite (20 to 40-year) lifetimes because
it's too painful to do otherwise. You're proposing instead:

require that all CAs must generate (new) roots on some interval (e.g. 3
years) for inclusion.

(that's quoted from the original message I replied to). How do you propose
that Mozilla is going to get every commercial CA on earth to do this?

Peter.

[Michael Casadevall]

Arguably, this would be a nice thing to fix since it could help reduce
issues with CA's changing owners. If we could update root stores
retroactively, it would make a lot of migrations simpler. For example,
if a device took the entire Mozilla root store before CNNIC was booted
out, those devices would still trust those certificates. Given the
glacier pace some things update at, having a type of root agility would
be rather desirable.

Just spitballing ideas here, but in Alex's case, part of me would be
tempted to see if X509 could be extended with a new "CanIssueUntil"
field. Basically, it would act as an off switch for CA:TRUE after a
given date, but certificates signed before that would still be valid for
that root, and then can be wound down beyond that point.

Maybe a bit out there, but an interesting thought none the less. It
would definitely go a good way at preventing one root certificate from
underpinning a large chunk of the internet. My thought here is if a
large "Too Big to Fail" CA's private key was
compromised/factored/physically stolen, our only recourse would be to
remove them from the root store, and deal with half the internet
breaking. Would be nice if that could not be a thing.
Michael

[Rob Stradling]

On 16/05/17 13:24, Michael Casadevall via dev-security-policy wrote:
<snip>

> Just spitballing ideas here, but in Alex's case, part of me would be
> tempted to see if X509 could be extended with a new "CanIssueUntil"
> field. Basically, it would act as an off switch for CA:TRUE after a
> given date, but certificates signed before that would still be valid for
> that root, and then can be wound down beyond that point.

That sounds like the "Private Key Usage Period" extension, which was
present in RFC3280 but removed in RFC5280.

https://tools.ietf.org/html/rfc3280#section-4.2.1.4

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

[Michael Casadevall]

On 05/16/2017 08:40 AM, Rob Stradling wrote:
> On 16/05/17 13:24, Michael Casadevall via dev-security-policy wrote:
> <snip>
>> Just spitballing ideas here, but in Alex's case, part of me would be
>> tempted to see if X509 could be extended with a new "CanIssueUntil"
>> field. Basically, it would act as an off switch for CA:TRUE after a
>> given date, but certificates signed before that would still be valid for
>> that root, and then can be wound down beyond that point.
>
> That sounds like the "Private Key Usage Period" extension, which was
> present in RFC3280 but removed in RFC5280.
>
> https://tools.ietf.org/html/rfc3280#section-4.2.1.4
>

I learned something new today. I'm about to run out the door right now
so I can't read the RFCs but do you know off the top of your head why
that was removed?
Michael

[Peter Gutmann]

Michael Casadevall via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

>I learned something new today. I'm about to run out the door right now so I
>can't read the RFCs but do you know off the top of your head why that was
>removed?

>From the PKIX RFC? There was never any coherent reason given, it just got
turned into a no-no.

(Note the qualifier "coherent". There were various reasons proposed for
removing it, but none that made any sense).

Peter.

[Jakob Bohm]

On 11/05/2017 18:42, Ryan Sleevi wrote:

> On Thu, May 11, 2017 at 11:57 AM, Alex Gaynor via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> Ryan,
>>
>> I think you've correctly highlighted that there's a problem -- the Mozilla
>> CA store is "designed" to be consumed from NSS, and CA-specific
>> remediations are a part of that (hash algorithms, maximum certificate
>> lifetimes, and any number of other important technical controls).
>>
>> Unfortunately, we're currently in a position where near as I can tell, most
>> code (except Go code :P) making HTTPS requests are using a Mozilla-derived
>> CA store, and OpenSSL's verifier, which only provides a subset of the
>> technical controls browsers implement. This is unfortunate, particular
>> because these clients also do not check CT, so it's entirely possible to
>> serve them certs which are not publicly visible. In a large sense, browsers
>> currently act as canaries-in-the-coalmine, protecting non-browser clients.
>>
>> Like Cory, I help maintain non-browser TLS clients. To that end, I think
>> it'd be outstanding if as a community we could find a way to get more of
>> these technical controls into non-browser clients -- some of this is just
>> things we need to do (e.g. add hash algorithm and lifetime checking to
>> OpenSSL or all consumers of it),
>
>

> Yes :) There's a significant amount that needs to happen in the third-party
> verifiers to understand and appreciate the risk of certain behaviours ;)

>
>
>> other's need coordination with Mozilla's
>> root program, and I think Cory's proposal highlights one way of making that
>> happen.
>
>

> Right, but these already flow into the NSS trust store - when appropriate.
> I'm sure you can understand when a piece of logic is _not_ implemented in
> NSS (e.g. because it's not generic beyond the case of browsers), that it
> seems weird to put it in/expose it in NSS :)
>
> To be clear: I'm not trying to suggest it's an entirely unreasonable
> request, merely an explanation of the constraints around it and why the
> current approach is employed that tries to balance what's right for Mozilla
> users and the overall NSS using community :)
>

Can you please get it into your thick skull that this thread is NOT
ABOUT NSS, IT IS ABOUT ALL THE OTHER X.509 LIBRARIES that can be
configured to use a copy of the Mozilla Root store!

[Alex Gaynor]

That's not an appropriate way to participate in a mailing list, please
communicate civilly.

Alex

[Doug Beattie]

Ryan,

If you look at the wide range of user agents accessing google.com today you'd see many legacy applications and older versions of browsers and custom browsers built from variants of the commercial browsers. By the time all/most users upgraded to new browsers, it would be time to change the roots out again and this will impact the ability for web site operators to enable TLS for all visitors.

Before we can implement a short Root usage policy we'd need to convince all browsers to follow a process for rapid updates of root stores. GlobalSign visitors use Nokia, NetFront, SeaMonkey, Amazon Silk, Blackberry and others, and assume ecommerce sites have even more legacy user agents (at percentages they cannot ignore). We'd need to be sure that these vendors change how they manage their root stores before we move to short use Roots (maybe some of them relay on the underlying operating system already and these are not all an issue).

Mobile devices will perhaps be the most challenging as their OS support lifetime is relatively short but users hang onto them for longer. For example, Android 4.1 and 4.2 account for about 7% of the Android market share:
https://developer.android.com/about/dashboards/index.html
Android browser has about 6% market share:
https://www.netmarketshare.com/browser-market-share.aspx?qprid=1&qpcustomb=1
but Android 4.1 and 4.2 are no longer supported:
https://www.extremetech.com/mobile/197346-google-throws-nearly-a-billion-android-users-under-the-bus-refuses-to-patch-os-vulnerability

Sure, 6% of 7% is around .5%, so in itself not a huge driver, but add up the other unsupported Android versions and those of all other mobile devices and this will become more meaningful.

Under your proposal, how would you see mobile device manufacturers as well as OS and browser vendors supporting the requirement to keep updating root stores even after the end of support?

Doug

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of Ryan
> Sleevi via dev-security-policy
> Sent: Tuesday, May 16, 2017 7:48 AM
> To: Peter Gutmann <pgu...@cs.auckland.ac.nz>
> Cc: Nick Lamb <tiala...@gmail.com>; MozPol <mozilla-dev-security-
> pol...@lists.mozilla.org>; Alex Gaynor <aga...@mozilla.com>; Cory Benfield
> <co...@lukasa.co.uk>; Ryan Sleevi <ry...@sleevi.com>; Gervase Markham
> <ge...@mozilla.org>
> Subject: Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser
> Consumption

[Jakob Bohm]

On 16/05/2017 15:23, Alex Gaynor wrote:
> That's not an appropriate way to participate in a mailing list, please
> communicate civilly.
>

Sorry about the flaming, but he was constantly derailing that
particular discussion with this misconception, and I was frankly
getting fed up.

[Ryan Sleevi]

On Tue, May 16, 2017 at 9:54 AM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 16/05/2017 15:23, Alex Gaynor wrote:
>

>> That's not an appropriate way to participate in a mailing list, please
>> communicate civilly.
>>
>>

> Sorry about the flaming, but he was constantly derailing that
> particular discussion with this misconception, and I was frankly
> getting fed up.

I'm not sure how best to help you understand that it's both extremely
relevant and germane to this conversation - both to the question of how
best to protect NSS users and how best to protect the ecosystem of clients
- both those who can update and those who cannot.

When faced with something challenging that you may not understand, or which
you may not see the relevance to the question, perhaps a more appropriate
and constructive way to participate in the mailing list is to ask
questions, rather than lob attacks.

I look forward to being able to work through any confusion you might have,
so you could understand how this proposal is entirely appropriate and
applicable.

[Ryan Sleevi]

On Tue, May 16, 2017 at 7:58 AM, Peter Gutmann <pgu...@cs.auckland.ac.nz>

wrote:

> Ryan Sleevi <ry...@sleevi.com> writes:
>
> >I can't help but feel you're raising concerns that aren't relevant.
>

> CAs issue roots with effectively infinite (20 to 40-year) lifetimes because
> it's too painful to do otherwise. You're proposing instead:
>

That's not an appropriate summary of the issues, but equally, as I already
described, and perhaps could work through with you if you had further
questions (rather than criticisms), that the 'too painful' scenario is
still meaningfully addressed.

>
> require that all CAs must generate (new) roots on some interval (e.g. 3
> years) for inclusion.
>
> (that's quoted from the original message I replied to). How do you propose
> that Mozilla is going to get every commercial CA on earth to do this?
>

The same way we in the Mozilla community have made progress for the past
decade -
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

It's fairly easy to submit PRs to https://github.com/mozilla/pkipolicy and
discuss. Perhaps we can discuss the substance of the proposal, and work
through any confusion or misunderstanding, rather than suggesting it's not
possible because it's hard (of which both are not correct)

[Alex Gaynor]

Hi Ryan,

I've lost the thread on how this addresses Cory's original problem
statement, if you could spell that out that'd be very helpful.

Alex

[Ryan Sleevi]

On Tue, May 16, 2017 at 9:45 AM, Doug Beattie <doug.b...@globalsign.com>
wrote:

> Ryan,
>
> If you look at the wide range of user agents accessing google.com today
> you'd see many legacy applications and older versions of browsers and
> custom browsers built from variants of the commercial browsers. By the
> time all/most users upgraded to new browsers, it would be time to change
> the roots out again and this will impact the ability for web site operators
> to enable TLS for all visitors.
>

No, it won't. Perhaps you missed the scenario where the old root (e.g. what
these legacy devices use) cross-signs the new root. From the perspective of
these old clients, there's always a contiguous path of trust.

You can see this, of course, simply by looking at Google.com - which
already shows this happening, because GIAG2 is signed by GeoTrust Global CA
(a root in new clients), which is signed by Equifax Secure Certificate
Authority (a root in older clients)

As you can see, this is the most commonly practiced form of deployment.
GlobalSign itself regularly does this - old roots sign new roots, new roots
are included for new clients, but the path to the old root is continued for
ubiquity. This is literally nothing new :)

The only thing that changes is that Mozilla could require that, on some
cadence (e.g. every 3 years), new roots are rolled. This allows another
cadence (e.g. 5 years) of removing the 'old' roots and only keeping the
'new' roots.

[Rob Stradling]

On 16/05/17 14:45, Doug Beattie via dev-security-policy wrote:
> Ryan,
>
> If you look at the wide range of user agents accessing google.com today you'd see many legacy applications and older versions of browsers and custom browsers built from variants of the commercial browsers. By the time all/most users upgraded to new browsers, it would be time to change the roots out again and this will impact the ability for web site operators to enable TLS for all visitors.
>

> Before we can implement a short Root usage policy we'd need to convince all browsers to follow a process for rapid updates of root stores.

Hi Doug.

Imagine a root cert A, valid for a short duration; and a root cert B,
valid for a long duration.

Under Ryan's proposal, Mozilla would put A (but not B) in NSS, whereas
other less agile root stores would contain B.

A doesn't have to be in every root store, because B can cross-certify A.
(Let's call the cross-certificate A').

A widely compatible cert chain would therefore look like this:
B -> A' -> Intermediate -> Leaf

If you're already cross-certifying from an older root C, then an even
more widely compatible cert chain would look like this:
C -> B' -> A' -> Intermediate -> Leaf

[Alex Gaynor]

While the internet is moderately good at handling a single cross-sign
(modulo the challenges we had with 1024-bit root deprecation due to a bug
in OpenSSL's path building -- now fixed), as we extend the chains, it seems
evident to me that server operators are unlikely to configure their servers
to serve a chain which works on all clients -- the likely result is clients
will need AIA chasing. Most (all?) non-browsers do not implement AIA
chasing. This isn't an objection, just a flag and a potential action item
on the "non-browser" side of this.

Alex

On Tue, May 16, 2017 at 10:27 AM, Rob Stradling <rob.st...@comodo.com>
wrote:

[Ryan Sleevi]

On Tue, May 16, 2017 at 10:24 AM, Alex Gaynor <aga...@mozilla.com> wrote:

> Hi Ryan,
>
> I've lost the thread on how this addresses Cory's original problem
> statement, if you could spell that out that'd be very helpful.
>

Sure, the original problem statement arises from the fact that CAs have
'limited trust' applied to them, and wanting to express this for use in
other applications which consume the Mozilla trust store.

First and foremost, in order for that limited trust to be
relevant/applicable, we must presume these clients are capable of being
updated. If they weren't, any expression of limited trust would be
irrelevant, since they wouldn't consume the update. At best, it would
simply ensure that, at a fixed point in time (e.g. when the application was
built), to the best of the app devs knowledge, all roots were constrained
appropriately.

As we've seen from CA issues - whether Symantec or the top 5 CAs
responsible for >90% of the Web's public trust - there's a whole host of
complex scenarios involved with distrusting. Cory's problem also
highlighted that there are a host of non-web consumers of the Mozilla trust
store, and their compatibility needs are different.

By posing the 'shorter lived root' scenario, we get to a scenario where a
device that is staying up to date (e.g. tracking the Mozilla store at a
frequency where 'limited trust' is applicable) is able to migrate off
'problematic' roots sooner, by providing a transition path that is
constantly moving forward. Thus, rather than needing to express 'limited
trust' for roots (which otherwise remain trusted), we provide a faster path
to distrusting the problematic roots, independent of whatever trust is
afforded the organization (which might have 'new' roots that are
less/unconstrained)

This is in conjunction with the expressions already found in certdata.txt
which applications can use (e.g. name constraints). It doesn't address
scenarios like whitelisting (e.g. CNNIC), since those are
application-specific anyways. The proposal is meant to, in parallel, reduce
the 'legacy compat risk' by providing a path to allow both 'legacy' and
'modern' clients to operate side-by-side, without indefinite expressions of
constraints on 'legacy' roots.

[Doug Beattie]

Thanks Rob and Ryan for pointing that out. Will the web servers need to send down a group of cross certs and then let the client use the ones they need in order to chain up to a root in their local trust store since the web server might not know which roots it has?

From: Alex Gaynor [mailto:aga...@mozilla.com]
Sent: Tuesday, May 16, 2017 10:31 AM
To: Rob Stradling <rob.st...@comodo.com>
Cc: Doug Beattie <doug.b...@globalsign.com>; ry...@sleevi.com; Peter Gutmann <pgu...@cs.auckland.ac.nz>; Gervase Markham <ge...@mozilla.org>; Nick Lamb <tiala...@gmail.com>; MozPol <mozilla-dev-s...@lists.mozilla.org>; Cory Benfield <co...@lukasa.co.uk>
Subject: Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

While the internet is moderately good at handling a single cross-sign (modulo the challenges we had with 1024-bit root deprecation due to a bug in OpenSSL's path building -- now fixed), as we extend the chains, it seems evident to me that server operators are unlikely to configure their servers to serve a chain which works on all clients -- the likely result is clients will need AIA chasing. Most (all?) non-browsers do not implement AIA chasing. This isn't an objection, just a flag and a potential action item on the "non-browser" side of this.
Alex

On Tue, May 16, 2017 at 10:27 AM, Rob Stradling <rob.st...@comodo.com<mailto:rob.st...@comodo.com>> wrote:
On 16/05/17 14:45, Doug Beattie via dev-security-policy wrote:
Ryan,

If you look at the wide range of user agents accessing google.com<http://google.com> today you'd see many legacy applications and older versions of browsers and custom browsers built from variants of the commercial browsers. By the time all/most users upgraded to new browsers, it would be time to change the roots out again and this will impact the ability for web site operators to enable TLS for all visitors.

[Ryan Sleevi]

On Tue, May 16, 2017 at 10:27 AM, Rob Stradling <rob.st...@comodo.com>

wrote:

> On 16/05/17 14:45, Doug Beattie via dev-security-policy wrote:
>
>> Ryan,
>>

>> If you look at the wide range of user agents accessing google.com today

>> you'd see many legacy applications and older versions of browsers and
>> custom browsers built from variants of the commercial browsers. By the
>> time all/most users upgraded to new browsers, it would be time to change
>> the roots out again and this will impact the ability for web site operators
>> to enable TLS for all visitors.
>>
>> Before we can implement a short Root usage policy we'd need to convince
>> all browsers to follow a process for rapid updates of root stores.
>>
>
> Hi Doug.
>
> Imagine a root cert A, valid for a short duration; and a root cert B,
> valid for a long duration.
>

Note: I was *not* proposing that the root's validity (e.g. expiration time)
be expressed. Merely it's duration/participation in the Mozilla store.

This purposefully allows 'never-updating' clients to continue to consume
the store (within the bounds of the root validity), while allowing
'frequently-updated' clients - e.g. what Mozilla actually ships - to
maintain a more agile basis of trust.

[Ryan Sleevi]

On Tue, May 16, 2017 at 10:31 AM, Alex Gaynor <aga...@mozilla.com> wrote:

> While the internet is moderately good at handling a single cross-sign
> (modulo the challenges we had with 1024-bit root deprecation due to a bug
> in OpenSSL's path building -- now fixed), as we extend the chains, it seems
> evident to me that server operators are unlikely to configure their servers
> to serve a chain which works on all clients -- the likely result is clients
> will need AIA chasing. Most (all?) non-browsers do not implement AIA
> chasing. This isn't an objection, just a flag and a potential action item
> on the "non-browser" side of this.
>

That's basically an argument of "assume we change nothing" :)

Yes, this proposal would impose some degree of change - either on server
operators (of which tools already exist, such as Cloudflare's excellent
cfssl - https://github.com/cloudflare/cfssl ) or on non-browser consumers
(to support AIA). My view of AIA is that it is decentralized, distributed
update mechanisms for the Web PKI. Either we presume these clients also
support revocation checking (in which case, the incremental cost of AIA is
negligible, regardless of whether it's OneCRL-style or OCSP/CRL style) or
we assume they do not (in which case, they're in a tricky spot re: security
anyways, and are not reasonable to consider "in scope")

[Ryan Sleevi]

On Tue, May 16, 2017 at 10:34 AM, Doug Beattie <doug.b...@globalsign.com>
wrote:

> Thanks Rob and Ryan for pointing that out. Will the web servers need to
> send down a group of cross certs and then let the client use the ones they
> need in order to chain up to a root in their local trust store since the
> web server might not know which roots it has?
>

Doug:

Yes, that was the substance of the original proposal, when it posed the
following:

On Y3, you generate new root and new intermediate, and then cross-sign,
> such that you have
> (old root) -> (old intermediate) -> (old existing certs)
> -> (new root) -> (new intermediate) -> (new leaf certs)
> Sites can either rely on AIA (Ideal, but unfortunately, not yet supported
> by Mozilla) or simply supply the full chain (less ideal, wasteful on
> bandwidth and caching), of either
> (site cert) -> (new intermediate) -> (new root) [the AIA path]
> (site cert) -> (new intermediate) -> (new root) -> (old root) [the slow,
> compatibility path]

The important point in this is that there should not be a non-linear path
of trust (which is implied, I think, by the reading of "group of
cross-certs"). But yes, there would be a linearized path.

Unquestionably, this means that performance gets worse for sites who
support clients that do not support AIA and who serve the extra
(potentially unnecessary) chains. This does put a certain pressure on these
clients _to_ support AIA, and the performance implications would only
become worse the longer the legacy clients exist. However, if/when 'enough'
clients support AIA (or automatic updates), the performance costs
evaporate. This helps create a virtuous cycle in which site operators are
incentivized to support clients that support AIA/automatic updates, and
software developers are incentivized to provide clients that support
AIA/automatic updates :)

[Jakob Bohm]

On 13/05/2017 00:48, Ryan Sleevi wrote:
> On Fri, May 12, 2017 at 6:02 PM, Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>>
>> This SubThread (going back to Kurt Roeckx's post at 08:06 UTC) is about
>> suggesting a good format for sharing this info across libraries though.
>> Discussing that on a list dedicated to a single library (such as NSS or
>> OpenSSL) would be pointless.
>>
>
> And in the original message, what was requested was
> "If Mozilla is interested in doing a substantial public service, this
> situation could be improved by having Mozilla and MDSP define a static
> configuration format that expresses the graduated trust rules as data, not
> code."
>
> Mozilla does express such graduated trust rules as data, not code, when
> possible. This is available with in the certdata.txt module data as
> expressive records using the NSS vendor attributes.
>
> Not all such requirements can be expressed as code, not data, but when
> possible, Mozilla does. That consuming applications do not make use of that
> information is something that consuming applications should deal with.
>

I suggest you read and understand the OP in this thread, which is
*entirely* about using the Mozilla Root Store outside Mozilla code.

Yet you keep posting noise about using the Mozilla store with Mozilla
code such as NSS, with Mozilla internal database formats, etc. etc.

Just above you commented "Not all such requirements can be expressed as
code", which is completely backwards thinking when the request is for
putting all additional conditions in an open database in a *stable*
data format that can be easily and fully consumed by non-Mozilla code.

[Rob Stradling]

On 16/05/17 15:41, Ryan Sleevi via dev-security-policy wrote:
<snip>

> The important point in this is that there should not be a non-linear path
> of trust (which is implied, I think, by the reading of "group of
> cross-certs"). But yes, there would be a linearized path.

If you *rely* on AIA, then why not set the AIA->caIssuers content to be
a PKCS#7 "group of cross-certs" ?

> Unquestionably, this means that performance gets worse for sites who
> support clients that do not support AIA and who serve the extra
> (potentially unnecessary) chains. This does put a certain pressure on these
> clients _to_ support AIA, and the performance implications would only
> become worse the longer the legacy clients exist. However, if/when 'enough'
> clients support AIA (or automatic updates), the performance costs
> evaporate. This helps create a virtuous cycle in which site operators are
> incentivized to support clients that support AIA/automatic updates, and
> software developers are incentivized to provide clients that support
> AIA/automatic updates :)

[Ryan Sleevi]

On Tue, May 16, 2017 at 10:42 AM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> I suggest you read and understand the OP in this thread, which is
> *entirely* about using the Mozilla Root Store outside Mozilla code.
>

Hi Jakob,

Could I echo Alex's request that you be more considerate in your replies?
I've attempted to remain positive in engaging with you, but I think both
your tone and your message continue to come off in a way that's not
conducive towards progress.

For example, here, you're implying I have not read the messages before
posting. That's not assuming good faith.

Yet you keep posting noise about using the Mozilla store with Mozilla
> code such as NSS, with Mozilla internal database formats, etc. etc.
>

This is also a rather insulting message, because here, you're entirely
disregarding the message on the basis that it's "noise". It's entirely
within the scope - as both a Mozilla module peer and as an NSS contributor
- to point out what is relevant and already expressed by Mozilla, so that
consumers of the Mozilla Root Store outside of Mozilla code can address.

Further, both the NSS and Mozilla Root Store have a policy regarding this,
that policy has been pointed out, and while certainly, good faith
engagement is being made to help Cory achieve his goals, it's also worth
reiterating that what is specifically being requested - e.g. what you
consider everything else but to be 'noise' - is out of scope.

> Just above you commented "Not all such requirements can be expressed as
> code", which is completely backwards thinking when the request is for
> putting all additional conditions in an open database in a *stable*
> data format that can be easily and fully consumed by non-Mozilla code.

I'm aware of what that request is. That request has been responded to -
several times - as out of scope. I would argue that continuing to belabor
that point - when it's been responded to in good faith - might arguably be
considered noise, but I'm trying to engage with you productively, rather
than being demeaning, insulting, and dismissive, as you are with me.

I realize you may feel it's backwards thinking. If that's the case, perhaps
your time is better spent on other projects that might be more aligned with
your thinking. That's the exciting joy of open-source - no one is forcing
you to use it or to participate in these discussions. If your goal is to
help convince others to your way of thinking, might I suggest that phrases
such as "noise", "backwards thinking", and "I suggest you read and
understand" are, as oratory techniques and as forms of debate, more likely
to get you written off than to win others to your way of thinking?

I think it's worth reiterating the responses here, perhaps in summary form,
so you can perhaps see what is being discussed.

1) NSS already exposes constraints via certdata.txt.
- This is the root store source of truth. This is what non-Mozilla code
is using to generate their application-specific stores. Applications
constructing their own root store _already_ use this format - for example,
https://curl.haxx.se/docs/mk-ca-bundle.html . It's up to those applications
- not Mozilla - to determine how to best coerce those expressions into a
form suitable for their application.
2) NSS does not expose/export its root store out of NSS.
- It's open source. You're free to take it and use it. You're free to
request that it is exposed. However, as noted in
https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F
, this is out of scope.
3) I proposed a path to reduce the need for such expressions of 'limited
trust'.
- This path works for both Mozilla and non-Mozilla applications. This
path works for applications that update and those that do not. The entire
purpose of this proposal is to reduce the need to maintain such expressions
of limited trust, by providing greater flexibility towards distrusting
problematic infrastructure, while still supporting existing and legacy
clients.

While your participation here in m.d.s.p. has been varied, and at many
times, technically and factually incorrect, I do hope you can find more
productive and constructive ways of expressing your feelings.

[Ryan Sleevi]

On Tue, May 16, 2017 at 11:00 AM, Rob Stradling via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 16/05/17 15:41, Ryan Sleevi via dev-security-policy wrote:
> <snip>
>
>> The important point in this is that there should not be a non-linear path
>> of trust (which is implied, I think, by the reading of "group of
>> cross-certs"). But yes, there would be a linearized path.
>>
>
> If you *rely* on AIA, then why not set the AIA->caIssuers content to be a
> PKCS#7 "group of cross-certs" ?

1) Clients don't widely support PKCS#7
2) LOL PKCS#7 is a tirefire
3) Because that's an added/unnecessarily complexity to the PKI which is
pretty detrimental compared to a linearized path.

I presume, but perhaps you can clarify, that the 'group of cross-certs' is
meant to cover the case where you have roots A, B, C, where A was created a
T-6, B at T-3, and C at T0, with an intermediate I issuing leaf L

I presume that your goal is that rather than expressing:
L -> I -> C -> B -> A

That you want to express

L -> I -> C
-> C2 (via AIA) -> B
-> C3 (via AIA) -> A

Is that correct? What is the advantage of that, given that PKCS#7 involves
BER, it introduces C/C2/C3, and you're still supplying the same number of
certs?

[Alex Gaynor]

Fewer round trips, if you can include everything in a single response.

Alex

[Peter Bowen]

> On May 16, 2017, at 7:42 AM, Jakob Bohm via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> On 13/05/2017 00:48, Ryan Sleevi wrote:
>>
>> And in the original message, what was requested was
>> "If Mozilla is interested in doing a substantial public service, this
>> situation could be improved by having Mozilla and MDSP define a static
>> configuration format that expresses the graduated trust rules as data, not
>> code."
>>
>> Mozilla does express such graduated trust rules as data, not code, when
>> possible. This is available with in the certdata.txt module data as
>> expressive records using the NSS vendor attributes.
>>

>> Not all such requirements can be expressed as data, not code, but when

>> possible, Mozilla does. That consuming applications do not make use of that
>> information is something that consuming applications should deal with.
>>
>

> I suggest you read and understand the OP in this thread, which is
> *entirely* about using the Mozilla Root Store outside Mozilla code.
>

> Yet you keep posting noise about using the Mozilla store with Mozilla
> code such as NSS, with Mozilla internal database formats, etc. etc.
>

> Just above you commented "Not all such requirements can be expressed as
> code", which is completely backwards thinking when the request is for
> putting all additional conditions in an open database in a *stable*
> data format that can be easily and fully consumed by non-Mozilla code.

Jakob,

What I think Ryan has been trying to express is his view that this request is not possible. A *stable* data format is unable to express future graduated trust rules.

To see why Ryan likely has this view, consider the authroot.stl file used by Microsoft Windows. The structure is essentially a certificate plus a set of properties. The properties are name value pairs. The challenge in using this file is that the list of properties keeps extending. New property names are added on a fairly routine basis. For example, the last update added NOT_BEFORE_FILETIME and NOT_BEFORE_ENHKEY_USAGE. This is great — we now know that certain roots have one or both of these properties with both represent some sort of restriction. However we have zero clue what they mean or how to process them.

Now consider certdata.txt, the Mozilla trust store format. It is similarly extensible, after all it is just a serialization of a PKCS#11 token. PKCS#11 has objects which each have attributes. Mozilla certdata.txt could take the exact same path as authroot.stl and just add attributes for each new rule. Imagine a new attribute on CKO_NSS_TRUST class objects called CKA_NAME_CONSTRAINTS. This is contains DER encoded NameConstraints. If this were suddenly added, what would existing libraries do? Probably just ignore it, because they don’t query for CKA_NAME_CONSTRAINTS. Taking this to an extreme, certain objects could even having attributes like CKA_CONSTRAINT_METHOD with a value that is the name of a function.

While this would be stable and would express all the rules, it isn’t clear that such is valuable to anyone because you need the matching code to query attributes and do something with the value. It also can lead to a false sense of security because using a new certdata.txt with an old library will not actually implement the trust changes.

Does this help explain the problem?

Thanks,
Peter

[Ryan Sleevi]

On Tue, May 16, 2017 at 11:12 AM, Alex Gaynor via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Fewer round trips, if you can include everything in a single response.
>

So fewer round-trips if same-size, or bigger data set if you're anything
newer than 6 years (potentially blowing INITCWND and back to same round
trips) :)

(I'm ignoring the other factors, such as that the HTTP cache would have it,
or Mozilla persisting observed intermediates to the NSS store, both of
which also would eliminate those gains :P)

[Jakob Bohm]

Your post above is the first response actually saying what is wrong
with the Microsoft format and the first post saying all the
restrictions are actually in the certdata.txt file, and not just in the
binary file used by the the NSS library.

This is much more constructive than anything Ryan posted in this thread.

Thanks for this.

[Peter Bowen]

On Tue, May 16, 2017 at 9:00 AM, Jakob Bohm via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
> Your post above is the first response actually saying what is wrong
> with the Microsoft format and the first post saying all the
> restrictions are actually in the certdata.txt file, and not just in the
> binary file used by the the NSS library.

What "binary file" are you referring to? NSS is distributed as source
and I'm unaware of any binary file used by the NSS library for trust
decisions.

Thanks,
Peter

[Ryan Sleevi]

On Tue, May 16, 2017 at 12:00 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> Your post above is the first response actually saying what is wrong
> with the Microsoft format and the first post saying all the
> restrictions are actually in the certdata.txt file, and not just in the
> binary file used by the the NSS library.
>

>From other threads you were engaged in:
https://groups.google.com/d/msg/mozilla.dev.security.policy/vqKFxHJF9Lo/bDgxoIGoAAAJ

>From this very thread, before you replied:
https://groups.google.com/d/msg/mozilla.dev.security.policy/NHW4JA6xoAY/6Owl86orAwAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/NHW4JA6xoAY/O6X3bAxuBgAJ


it appears to be that you did not realize "NSS trust DB" is certdata.txt,
but thankfully, I helpfully clarified for that for you earlier:
https://groups.google.com/d/msg/mozilla.dev.security.policy/NHW4JA6xoAY/TuObsXZxBgAJ

While you quoted that email at me, it appears you may have missed me
mentioning certdata.txt. I incorrectly assumed that you would have
sufficient information to look into it, but it appears a more careful
explanation was warranted to ensure it was understood. Hopefully, with the
new understanding, you can look back on these past messages and see that
the substance was already explained, just in a way that was misunderstood.

This is where asking questions, rather than assuming ill-intent or engaging
in ad hominems, can result in more fruitful and productive discussions.

This is much more constructive than anything Ryan posted in this thread.

Jakob, this remark was entirely unnecessary and inappropriate. Please
consider a more productive means in engaging.

[Jakob Bohm]

Source code for Mozilla products presumably includes some binary files
(such as PNG files), so why not a binary database file that becomes
that data that end users can view (and partially edit) in the Mozilla
product dialogs. Existence of a file named "generate_certdata.py",
which is not easily grokked also confused me into thinking that
certdata.txt was some kind of extracted subset.

Anyway, having now looked closer at the file contents (which does look
like computer output), I have been unable to find a line that actually
expresses any of the already established "gradual trusts".

Could you please point out where in certdata.txt the following are
expressed, as I couldn't find it in a quick scan:

1. The date restrictions on WoSign-issued certificates.

2. The EV trust bit for some CAs.

[Michael Casadevall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 05/16/2017 11:10 AM, Peter Bowen wrote:
> Jakob,
>
> What I think Ryan has been trying to express is his view that this
> request is not possible. A *stable* data format is unable to
> express future graduated trust rules.
>

I've been thinking on this and I'm starting to question this. The fact
of the matter is most of the graduated trust scenarios involve a
whitelist/blacklist, or putting restraints on the values of fields on
a certificate. If you simply have a way to express requirements for
ASN1 fields and such, that handles lot of the simple cases. For
example, wosign would need the following constraints:

"CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=C
N"
blacklist-leafs:
- NotBefore: > 2016-21-10
- Attributes: inclusive

For the case of ANSSI, it would look something like this

*ANSSI Distinished Name*
- blacklist-leafs
- whitelist-leafs:
- CommonName:
- ends-in .fr
- ends-in .gp
- ends-in .gf
- ends-in .mq
- ends-in .re
etc.

For knocking out the future certificates, and that this blacklist
should apply if this certificate appears anywhere in the chain of trust.

While that won't handle every single case, being able to specify that
a field must be present, or have this valid (or not have this valid)
in an extensiable way would handle a fair number of cases for
graduated trust.

Granted, it won't handle everything, but it's not let perfect be the
enemy of good here. Right now, if you naively imported the Mozilla
root store, you get a number of certificates you probably shouldn't be
trusting.

In the case we need to specify a new type of trust restrictions, then
we extend the format, and implement it. It's up to downstream authors
to actually parse the data and do something with it. If the graduated
trust data is in a standardized format, there's a decent chance other
libraries may be willing to support it.

If someone can prove me wrong and show a case where Mozilla proposed
or implemented graduated trust that couldn't be expressed as a
combination of a whitelist/blacklist, and attribute comparsions, I'd
very much like to know if it.
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCgAGBQJZGzGOAAoJEHM+GkLSJHY5dTEP/iLWY9Wgeb8gvt/dY/Bp0BCA
QLX+/i3rv/TOm/plxL/tKrHg8pM7YDVwBHRR51i5vmko2712yVPlXbSAnnqyL3bV
IzSNgKUiMjbeLhO98P9pXH5M586VzAPnLrxilrjrvXZJRmL+nTdguDRBAPO1+6qe
La7WOpPgxVfaf2u+8e+waqjDF517VaAy2PaZAm5VP5EB+i50QqyGHJfwuTvArBeY
c28ZHXso5t1qze2dmKCvg4lIARwvckwTdx0dqiedcZSIm++wd8K0Yq+I85R0SH6g
gUv6LLf4b4JlQER0KQ3ozdqRhNwRd+VwReuGDTeE6PH9/2UCpIkt44BDLlfC+Jt5
Y+4lw3FTGgHDLdVaeLZqGVaE/47aQgmU3gdfAPRe0q47GBb3uqwSsfg4LBO7+lFQ
BAIGNOi3v2Zr/aALmtBCo0zzn+wt67OF4uIAFhhNTyP6o7XsWXJwSSwW0eO41mOe
QuSYx6ETNOh5u01uAR5+GSaOwNxKZBSYMyXBv3yAV9ZSrSD1aA17oRJFlClYkHyM
uhLPpn5TZ5Q25gtQiS8MvxiHqo6+joV9hAw/b0nNqkFAFzHI1OaZzy0p8bOmKI+d
/auRC56g5mGdOIY8h0fFgoFAfh/adohubqiGqMt0Yn9c9yB51OjM+JJ9XKGuAI3+
2+gZjY9o4tH+qCmVD/Va
=JEMo
-----END PGP SIGNATURE-----

[Michael Casadevall]

On 05/16/2017 01:04 PM, Jakob Bohm wrote:
>
> Could you please point out where in certdata.txt the following are
> expressed, as I couldn't find it in a quick scan:
>
> 1. The date restrictions on WoSign-issued certificates.
>
> 2. The EV trust bit for some CAs.
>

Not the OP, but WoSign restrictions are hardcoded:
https://dxr.mozilla.org/mozilla-aurora/source/security/certverifier/NSSCertDBTrustDomain.cpp#741


EV OIDs live in PSM, and are hardcoded into the browser:
https://dxr.mozilla.org/mozilla-aurora/source/security/certverifier/ExtendedValidation.cpp

At least in the case of EV though, I'm not sure if anything beside the
browser itself actually cares EV vs. DV (or OV) in practice though.
Michael

[Peter Bowen]

On Tue, May 16, 2017 at 10:04 AM, Jakob Bohm via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
> On 16/05/2017 18:10, Peter Bowen wrote:
>>

> Source code for Mozilla products presumably includes some binary files
> (such as PNG files), so why not a binary database file that becomes
> that data that end users can view (and partially edit) in the Mozilla
> product dialogs. Existence of a file named "generate_certdata.py",
> which is not easily grokked also confused me into thinking that
> certdata.txt was some kind of extracted subset.
>
> Anyway, having now looked closer at the file contents (which does look
> like computer output), I have been unable to find a line that actually
> expresses any of the already established "gradual trusts".
>

> Could you please point out where in certdata.txt the following are
> expressed, as I couldn't find it in a quick scan:
>
> 1. The date restrictions on WoSign-issued certificates.
>
> 2. The EV trust bit for some CAs.

These are not included in certdata.txt for the reasons described
earlier -- they are application-only things, not Mozilla platform
things. I know it is non-obvious, but there are two parts of
processing certificates in many applications:

1) The certificate is passed to the platform library (along with some
other data, like name to validate) and a result is returned.
2) Then the application makes further decisions.

This is not only true for Chrome but also Firefox. EV information is
decided by the application. See
https://dxr.mozilla.org/mozilla-central/source/security/certverifier/ExtendedValidation.cpp
for information about deciding on EV. See
https://dxr.mozilla.org/mozilla-central/source/security/certverifier/NSSCertDBTrustDomain.cpp#898
for additional checks (outside NSS) added by Firefox.

This could be moved into NSS, but there hasn't been demand to do so at
this point. It could also be added as unused attributes in
certdata.txt (which is the master), but no one has volunteered
extended this to support the additional info and add the necessary
tests to ensure that it doesn't go stale.

My experience is that Mozilla is very open to taking patches and will
help contributors get things into acceptable form, so I'm sure they
would be happy to take patches if there is demand for such. It is
fairly important that someone who is going to use the attributes put
together the patch, otherwise it may prove to be useless. For
example, I could easily create a patch that add a CKA_TRUST_FILTER
attribute that is designed to be fed into a case statement to indicate
the filter to be applied. Based on the code, it looks like I probably
needs a "cnnic" case, a "wosign" case, and a "globalsignr2" case.
This meets my needs, but it might not need your needs.

Thanks,
Peter

[Jakob Bohm]

Ok, can you point me to any "graduated trust" actually present in
certdata.txt ?

[Peter Bowen]

On Tue, May 16, 2017 at 10:52 AM, Jakob Bohm via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
> On 16/05/2017 19:36, Peter Bowen wrote:
>>

>> My experience is that Mozilla is very open to taking patches and will
>> help contributors get things into acceptable form, so I'm sure they
>> would be happy to take patches if there is demand for such. It is
>> fairly important that someone who is going to use the attributes put
>> together the patch, otherwise it may prove to be useless. For
>> example, I could easily create a patch that add a CKA_TRUST_FILTER
>> attribute that is designed to be fed into a case statement to indicate
>> the filter to be applied. Based on the code, it looks like I probably
>> needs a "cnnic" case, a "wosign" case, and a "globalsignr2" case.
>> This meets my needs, but it might not need your needs.
>>
>

> Ok, can you point me to any "graduated trust" actually present in
> certdata.txt ?

See the CKA_TRUST_SERVER_AUTH, CKA_TRUST_EMAIL_PROTECTION,
CKA_TRUST_CODE_SIGNING, and CKA_TRUST_STEP_UP_APPROVED attributes in
CKO_NSS_TRUST class objects. They all represent non-binary trust of
roots, similar to that contained in the OpenSSL X509_AUX structure
mentioned much earlier in the thread.

Thanks,
Peter

[Rob Stradling]

On 16/05/17 16:11, Ryan Sleevi via dev-security-policy wrote:

> On Tue, May 16, 2017 at 11:00 AM, Rob Stradling via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> On 16/05/17 15:41, Ryan Sleevi via dev-security-policy wrote:
>> <snip>
>>
>>> The important point in this is that there should not be a non-linear path
>>> of trust (which is implied, I think, by the reading of "group of
>>> cross-certs"). But yes, there would be a linearized path.
>>>
>>
>> If you *rely* on AIA, then why not set the AIA->caIssuers content to be a
>> PKCS#7 "group of cross-certs" ?
>
>
> 1) Clients don't widely support PKCS#7

Regarding AIA->caIssuers, RFC5280 says:
'Conforming applications that support HTTP or FTP for accessing
certificates MUST be able to accept individual DER encoded
certificates and SHOULD be able to accept "certs-only" CMS messages.'

Out of interest, which particular clients chase AIA->caIssuers HTTP URLs
but ignore that "SHOULD"?
(I know CryptoAPI has accepted "certs-only" CMS messages since XP, but
I've not checked any other implementations).

> 2) LOL PKCS#7 is a tirefire
> 3) Because that's an added/unnecessarily complexity to the PKI which is
> pretty detrimental compared to a linearized path.

Sure, it's certainly added complexity.

> I presume, but perhaps you can clarify, that the 'group of cross-certs' is
> meant to cover the case where you have roots A, B, C, where A was created a
> T-6, B at T-3, and C at T0, with an intermediate I issuing leaf L
>
> I presume that your goal is that rather than expressing:
> L -> I -> C -> B -> A
>
> That you want to express
>
> L -> I -> C
> -> C2 (via AIA) -> B
> -> C3 (via AIA) -> A
> > Is that correct?

That's what my question was about, yes.

> What is the advantage of that, given that PKCS#7 involves
> BER, it introduces C/C2/C3, and you're still supplying the same number of
> certs?

I don't think there is any notable advantage.

I asked the question because I thought it would be useful to enumerate
the reasons why "there should not be a non-linear path" rather than just
assume it to be fact. ;-)

[Ryan Sleevi]

On Tue, May 16, 2017 at 1:59 PM, Peter Bowen via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Tue, May 16, 2017 at 10:52 AM, Jakob Bohm via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
> > On 16/05/2017 19:36, Peter Bowen wrote:
> >>

> >> My experience is that Mozilla is very open to taking patches and will
> >> help contributors get things into acceptable form, so I'm sure they
> >> would be happy to take patches if there is demand for such. It is
> >> fairly important that someone who is going to use the attributes put
> >> together the patch, otherwise it may prove to be useless. For
> >> example, I could easily create a patch that add a CKA_TRUST_FILTER
> >> attribute that is designed to be fed into a case statement to indicate
> >> the filter to be applied. Based on the code, it looks like I probably
> >> needs a "cnnic" case, a "wosign" case, and a "globalsignr2" case.
> >> This meets my needs, but it might not need your needs.
> >>
> >

> > Ok, can you point me to any "graduated trust" actually present in
> > certdata.txt ?
>
> See the CKA_TRUST_SERVER_AUTH, CKA_TRUST_EMAIL_PROTECTION,
> CKA_TRUST_CODE_SIGNING, and CKA_TRUST_STEP_UP_APPROVED attributes in
> CKO_NSS_TRUST class objects. They all represent non-binary trust of
> roots, similar to that contained in the OpenSSL X509_AUX structure
> mentioned much earlier in the thread.
>

And as for other forms of restriction, it has already been mentioned :
https://wiki.mozilla.org/CA:Root_Store_Trust_Mods

You can see an example of implementing this in
https://bugzilla.mozilla.org/show_bug.cgi?id=1349705

One aspect that is no doubt non-obvious, but important to note, is that
Mozilla NSS using applications are permitted to ship with alternative trust
stores, since the trust store is dynamically loaded (certdata.txt is fed to
certdata.c , which is then part of nssckbi.[dll/so], which is dynamically
loaded by NSS)

You can see this being used by applications such as p11-kit, which provide
alternative 'nssckbi's which then allow for more complex root store
management.

Because of this, when Mozilla responds to a security incident, or needs to
constrain something, they want to ensure that constraint is uniformly
applied - e.g. regardless of the (independent) root store update. Hence the
implementation within the application layer, which guarantees that
_regardless of the basis of trust_, the constraint is applied.

This is one way to do it. It's different than how Microsoft does it, which
expresses the constraints in authroot.stl, but the implementation of those
constraints in crypt32.dll (or related). In the Microsoft case, unless you
update *both* the root store and the crypt32, you don't get the security
update. Perhaps unsurprisingly, this is a common occurrence - in part,
because fetching authroot.stl can use a different network or application
code path than fetching the Windows Updates for crypt32.dll.

[Ryan Sleevi]

On Tue, May 16, 2017 at 2:12 PM, Rob Stradling <rob.st...@comodo.com>
wrote:

>
> Regarding AIA->caIssuers, RFC5280 says:
> 'Conforming applications that support HTTP or FTP for accessing
> certificates MUST be able to accept individual DER encoded
> certificates and SHOULD be able to accept "certs-only" CMS messages.'
>
> Out of interest, which particular clients chase AIA->caIssuers HTTP URLs
> but ignore that "SHOULD"?
> (I know CryptoAPI has accepted "certs-only" CMS messages since XP, but
> I've not checked any other implementations).

Selfishly, Chrome :)

Less selfishly, macOS (see tpIssuerCertViaNet, which just creates a
TPCertInfo with the response data, aka 'DER-encoded X.509v3 cert')

Even the NSS implementation (by way of libpkix's AIA mgr
calling CERT_DecodeCertPackage) doesn't "properly" implement the defined
bits :) Just enough to get you close enough ;)

> What is the advantage of that, given that PKCS#7 involves
>> BER, it introduces C/C2/C3, and you're still supplying the same number of
>> certs?
>>
> I don't think there is any notable advantage.
>
> I asked the question because I thought it would be useful to enumerate the
> reasons why "there should not be a non-linear path" rather than just assume
> it to be fact. ;-)

You mean I can't just spout opinion here without substantiating it? ;)

[Rob Stradling]

On 16/05/17 19:53, Ryan Sleevi via dev-security-policy wrote:
<snip>

>> What is the advantage of that, given that PKCS#7 involves
>>> BER, it introduces C/C2/C3, and you're still supplying the same number of
>>> certs?
>>>
>> I don't think there is any notable advantage.
>>
>> I asked the question because I thought it would be useful to enumerate the
>> reasons why "there should not be a non-linear path" rather than just assume
>> it to be fact. ;-)
>
> You mean I can't just spout opinion here without substantiating it? ;)

You can do that if you want, but I tend to find well-reasoned arguments
to be more persuasive. ;-)

[Kurt Roeckx]

On 2017-05-16 14:24, Michael Casadevall wrote:
> Maybe a bit out there, but an interesting thought none the less. It
> would definitely go a good way at preventing one root certificate from
> underpinning a large chunk of the internet. My thought here is if a
> large "Too Big to Fail" CA's private key was
> compromised/factored/physically stolen, our only recourse would be to
> remove them from the root store, and deal with half the internet
> breaking. Would be nice if that could not be a thing.

If the key is compromised, you can't rely on any date information
anymore, you need to revoke it completely and break things.


Kurt

[Michael Casadevall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 05/17/2017 05:04 AM, Kurt Roeckx wrote:
> If the key is compromised, you can't rely on any date information
> anymore, you need to revoke it completely and break things.
>

Won't that only be true in certificates without SCTs? Once you have a
SCT, you have an independent timestamp you can check beside the
NotBefore value, and can independently confirm since CT logs are
append-only.

(Granted, I realize nothing actually checks the SCT in this way to my
knowledge, but the idea itself may be on semi-solid ground).

Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCgAGBQJZHDLHAAoJEHM+GkLSJHY5rnAP/A7Y7x0B5yr/t3ft5Ua4k5BP
P1EKD/Oguwf2QqTiBYgvuKOvdc8aCkOCoVXcq9awyERUzxpW/Pcvz5bOfLLyYY8v
qLLFTAXylJSJvFCSlw8+M1aiFEcTzeVptOUl51yQbBxxooWh4Oc8BrhvBZsCZqO3
j5KEWKo7kGLN0pAfocXDHBktb3DVJBnQnyakrUFooz0BgoH+cfJ2te/dSSSNspvw
TfPfydWC/ANg7FBkvuc4cZrH3PSGEfpnR7kcvFTfD56Pg2Q90i46gS3ikGdqHaA0
F3GOQ456J0sFpM3wjmIVvLV6OKnQG0jBNicrkyYOydw+YHTVwyhJN12VT7kAlYdc
HUVdl18T+Fx2waf/J8sQLyrYoE8QQ0nEZ+8DC4/XXe7gkxwxSFfvD8fUTLnYRI8F
TNfq1D+DnIQIQsEDEX5PYfgRAgNohKhzy6L+btLeyqLsqI1Vxak3cCJ40Zl68Pj8
NpTSvPchlSiUZNPRDD6moRIJdsSIfEGPDn6jjOntw4Go3gwg67jPl8btePBM3VWD
9WRAy6KGdX5rRWsrvH1Zrrmeqjsqe8kQ6t3vGbuU0Qcd7hDT4EoDWWTRafy8Nsbc
BIag3UXSWtF27LLpw/0C+6wPDT9krdl01JMTPwc0li0tYYL8h7W3FfHe8jMvnOmT
Z0bUn1hiBjaFftVpdlM0
=RWD4
-----END PGP SIGNATURE-----

[Gervase Markham]

On 16/05/17 18:04, Jakob Bohm wrote:
> Could you please point out where in certdata.txt the following are
> expressed, as I couldn't find it in a quick scan:
>
> 1. The date restrictions on WoSign-issued certificates.
>
> 2. The EV trust bit for some CAs.

I am surprised you are engaging in a discussion on this topic without
being pretty familiar with:
https://wiki.mozilla.org/CA/Additional_Trust_Changes

Gerv

[Kurt Roeckx]

On 2017-05-17 13:23, Michael Casadevall wrote:
> On 05/17/2017 05:04 AM, Kurt Roeckx wrote:
>> If the key is compromised, you can't rely on any date information
>> anymore, you need to revoke it completely and break things.
>>
>
> Won't that only be true in certificates without SCTs? Once you have a
> SCT, you have an independent timestamp you can check beside the
> NotBefore value, and can independently confirm since CT logs are
> append-only.
>
> (Granted, I realize nothing actually checks the SCT in this way to my
> knowledge, but the idea itself may be on semi-solid ground).

Yes, and I guess that's the reason why with code signing they also use a
timestamp service. And I guess we could require either an SCT or a
timestamp if they want signatures to remain valid.


Kurt

[Jakob Bohm]

That is /human readable/ information, not /computer readable/ data that
can be imported by other libraries when those are used with the Mozilla
root program.

[Gervase Markham]

On 17/05/17 12:55, Jakob Bohm wrote:
> That is /human readable/ information, not /computer readable/ data that
> can be imported by other libraries when those are used with the Mozilla
> root program.

Yes, indeed. But you asked where in certdata.txt those things are, and
that page explains pretty clearly that they aren't in certdata.txt, and why.

Gerv