Re: Configuring Graduated Trust for Non-Browser Consumption
On Fri, May 12, 2017 at 6:02 PM, Jakob Bohm via dev-security-policy < dev-security-policy@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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Configuring Graduated Trust for Non-Browser Consumption
On 12/05/2017 23:45, Ryan Sleevi wrote: On Fri, May 12, 2017 at 2:15 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 12/05/2017 20:43, Ryan Sleevi wrote: On Fri, May 12, 2017 at 1:50 PM, Jakob Bohm via dev-security-policy < dev-security-policy@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? 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. 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. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Configuring Graduated Trust for Non-Browser Consumption
On Fri, May 12, 2017 at 2:15 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 12/05/2017 20:43, Ryan Sleevi wrote: > > On Fri, May 12, 2017 at 1:50 PM, Jakob Bohm via dev-security-policy < > > dev-security-policy@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? > > > > 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. > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Configuring Graduated Trust for Non-Browser Consumption
On 12/05/2017 20:43, Ryan Sleevi wrote: On Fri, May 12, 2017 at 1:50 PM, Jakob Bohm via dev-security-policy < dev-security-policy@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? 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. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Configuring Graduated Trust for Non-Browser Consumption
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Configuring Graduated Trust for Non-Browser Consumption
On Fri, May 12, 2017 at 1:50 PM, Jakob Bohm via dev-security-policy < dev-security-policy@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? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Require CAs to operate in accordance with their CPs and CPSes
On 12/05/2017 15:21, Gervase Markham wrote:
Mozilla policy requires that certificates issued in contravention of a
CA's CP/CPS should be revoked. Other than that, Mozilla policy does not
directly require that a CA operate in accordance with its CP and CPS. We
require this indirectly because the audits that we require, require it.
This perhaps surprising omission was brought to light by the Let's
Encrypt blocklist incident. Discussion:
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/_pSjsrZrTWY
The proposal is to have Mozilla policy directly require that CAs operate
in accordance with the appropriate CP/CPS for the root(s) in our store
on an ongoing basis.
Specifically, we could add text to the top of section 5.2 ("Forbidden
and Required Practices"):
"CA operations MUST at all times be in accordance with the applicable CP
and CPS."
Perhaps tweak the wording to make the document submitted to the CCADB
binding, rather than any CP/CPS published elsewhere.
This is: https://github.com/mozilla/pkipolicy/issues/43
---
This is a proposed update to Mozilla's root store policy for version
2.5. Please keep discussion in this group rather than on Github. Silence
is consent.
Policy 2.4.1 (current version):
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Configuring Graduated Trust for Non-Browser Consumption
On 12/05/2017 10:06, Kurt Roeckx wrote: 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. 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Hunting for intermediates that still haven't been disclosed to CCADB
On 2017-05-11 19:05, Gervase Markham wrote: On 11/05/17 12:46, Rob Stradling wrote: There's a "Created by" field (Username, Timestamp) and a "Last Modified By" field (Username, Timestamp) in the CCADB, but neither of these fields are currently provided in the public CSV reports that Mozilla publishes. Rob: do you think you could enhance https://crt.sh/mozilla-disclosures#undisclosed to give the number of days a certificate has been on the list? Rob, Could you also split the "Technically Constrained", into those that are really technically constrained, and those that are out of scope for the CCADB? For instance https://crt.sh/?id=12729339 is out of scope because it's code signing. https://crt.sh/?id=8951039 because it's client / email. Or maybe it just needs to be renamed? Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Add anyEKU to scope
On 2017-05-12 17:31, Kurt Roeckx wrote: On 2017-05-12 15:00, Gervase Markham wrote: Because the Mozilla root store is used by more people than Mozilla, Kathleen would like to put anyEKU in scope even though Firefox ignores it. I think the CCADB document needs to be updated too. It might already be correct. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Add anyEKU to scope
On 2017-05-12 15:00, Gervase Markham wrote: Because the Mozilla root store is used by more people than Mozilla, Kathleen would like to put anyEKU in scope even though Firefox ignores it. I think the CCADB document needs to be updated too. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Policy 2.5 Proposal: Require CAs to operate in accordance with their CPs and CPSes
Mozilla policy requires that certificates issued in contravention of a
CA's CP/CPS should be revoked. Other than that, Mozilla policy does not
directly require that a CA operate in accordance with its CP and CPS. We
require this indirectly because the audits that we require, require it.
This perhaps surprising omission was brought to light by the Let's
Encrypt blocklist incident. Discussion:
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/_pSjsrZrTWY
The proposal is to have Mozilla policy directly require that CAs operate
in accordance with the appropriate CP/CPS for the root(s) in our store
on an ongoing basis.
Specifically, we could add text to the top of section 5.2 ("Forbidden
and Required Practices"):
"CA operations MUST at all times be in accordance with the applicable CP
and CPS."
This is: https://github.com/mozilla/pkipolicy/issues/43
---
This is a proposed update to Mozilla's root store policy for version
2.5. Please keep discussion in this group rather than on Github. Silence
is consent.
Policy 2.4.1 (current version):
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Policy 2.5 Proposal: Clarify requirements for reporting of security failures/policy violations
Mozilla's Enforcement Policy indicates what to do when a serious security concern is noticed, but does not indicate what to do when a lesser security concern is noticed. The current text is now in section 7, and says: "Changes that are motivated by a serious security concern such as a major root compromise SHOULD be treated as a security-sensitive bug, and the Mozilla Policy for Handling Security Bugs SHOULD be followed." However, the Mozilla Policy for Handling Security Bugs is really an internal Mozilla document, and no longer describes (if it ever did) the bug filing process. Also, those SHOULDs should be MUSTs. I propose instead: "Changes that are motivated by a security concern such as certificate misissuance or a root or intermediate compromise MUST be treated as a security-sensitive, and a secure bug filed in Bugzilla. The link would be directly to the bug filing page, to file a bug in our shiny new component for such things: https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Mis-Issuance&groups=crypto-core-security We should also update the other instance of that old link in this way (in section 4.1). This is: https://github.com/mozilla/pkipolicy/issues/17 --- This is a proposed update to Mozilla's root store policy for version 2.5. Please keep discussion in this group rather than on Github. Silence is consent. Policy 2.4.1 (current version): https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md Update process: https://wiki.mozilla.org/CA:CertPolicyUpdates ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Policy 2.5 Proposal: Add anyEKU to scope
Because the Mozilla root store is used by more people than Mozilla, Kathleen would like to put anyEKU in scope even though Firefox ignores it. That would involve updating Section 1.1, as follows. Change item 2 to read: “2. Intermediate certificates which have at least one valid, unrevoked chain up to such a CA certificate and which are not technically constrained to prevent issuance of working server or email certificates. Such technical constraints could consist of either: an Extended Key Usage (EKU) extension which does not contain any of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, id-kp-emailProtection; or: name constraints which do not allow Subject Alternative Names (SANs) of any of the following types: dNSName, iPAddress, SRVName, rfc822Name Change the first bullet point in item 3 to: “an Extended Key Usage (EKU) extension which contains one or more of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, id-kp-emailProtection; or:” This is: https://github.com/mozilla/pkipolicy/issues/79 --- This is a proposed update to Mozilla's root store policy for version 2.5. Please keep discussion in this group rather than on Github. Silence is consent. Policy 2.4.1 (current version): https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md Update process: https://wiki.mozilla.org/CA:CertPolicyUpdates ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Configuring Graduated Trust for Non-Browser Consumption
> On 11 May 2017, at 20:20, Nick Lamb via dev-security-policy > 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Configuring Graduated Trust for Non-Browser Consumption
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
