Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of May 2017 Audit Reminder Emails
Date: Tue, 16 May 2017 19:00:29 + (GMT)

Mozilla: Audit Reminder
Root Certificates:
   Autoridad de Certificacion Firmaprofesional CIF A62634068
Standard Audit: https://cert.webtrust.org/SealFile?seal=2032=pdf
Audit Statement Date: 2016-04-11
BR Audit: https://bug521439.bmoattachments.org/attachment.cgi?id=8809981
BR Audit Statement Date: 2016-08-05
EV Audit: https://bug521439.bmoattachments.org/attachment.cgi?id=8809982
EV Audit Statement Date: 2016-08-05
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   COMODO RSA Certification Authority
   USERTrust ECC Certification Authority
   AAA Certificate Services
   AddTrust Class 1 CA Root
   AddTrust External CA Root
   AddTrust Public CA Root
   AddTrust Qualified CA Root
   COMODO Certification Authority
   COMODO ECC Certification Authority
   Secure Certificate Services
   Trusted Certificate Services
   UTN-USERFirst-Client Authentication and Email
   UTN-USERFirst-Hardware
   UTN-USERFirst-Object
   USERTrust RSA Certification Authority
Standard Audit: https://cert.webtrust.org/SealFile?seal=2058=pdf
Audit Statement Date: 2016-06-03
BR Audit: https://cert.webtrust.org/SealFile?seal=2060=pdf
BR Audit Statement Date: 2016-06-03
BR Audit:
BR Audit Statement Date:
EV Audit: https://cert.webtrust.org/SealFile?seal=2059=pdf
EV Audit Statement Date: 2016-06-03
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   ComSign CA
   ComSign Secured CA
Standard Audit: https://bug1269275.bmoattachments.org/attachment.cgi?id=8778667
Audit Statement Date: 2016-04-26
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   EC-ACC
Standard Audit: https://cert.webtrust.org/SealFile?seal=2043=pdf
Audit Statement Date: 2016-05-30
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8815404
BR Audit Statement Date: 2016-05-30
CA Comments: Per CA: ETSI-EIDAS audits to be released by the 1st of June 2017.



Mozilla: Audit Reminder
Root Certificates:
   S-TRUST Universal Root CA
   TC TrustCenter Class 3 CA II
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/6778UE_s.pdf
Audit Statement Date: 2016-05-31
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Entrust Root Certification Authority - EC1
   Entrust Root Certification Authority - G2
   Entrust Root Certification Authority
   Entrust.net Certification Authority (2048)
Standard Audit: https://cert.webtrust.org/SealFile?seal=328=pdf
Audit Statement Date: 2016-05-18
BR Audit: 
https://www.entrust.com/wp-content/uploads/2016/06/2104-01-WebTrust-for-CA-SSL-Baseline-with-Network-Security-Report-002.pdf
BR Audit Statement Date: 2016-05-18
EV Audit: https://cert.webtrust.org/SealFile?seal=328=pdf
EV Audit Statement Date: 2016-05-18
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   GlobalSign ECC Root CA - R5
   GlobalSign Root CA - R3
   GlobalSign Root CA
   GlobalSign Extended Validation CA - SHA256 - G2 - intermediate cert being 
treated as root during transition
Standard Audit: https://cert.webtrust.org/SealFile?seal=2056=pdf
Audit Statement Date: 2016-06-10
BR Audit: https://cert.webtrust.org/SealFile?seal=2054=pdf
BR Audit Statement Date: 2016-06-10
EV Audit: https://cert.webtrust.org/SealFile?seal=2055=pdf
EV Audit Statement Date: 2016-06-10
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   GeoTrust Global CA 2
Standard Audit: 
https://www.symantec.com/content/en/us/about/media/repository/3_symantec_geotrust_wtca_6-15-2016.pdf
Audit Statement Date: 2016-05-13
BR Audit: 
https://www.symantec.com/content/en/us/about/media/repository/6_symantec_geotrust_wtbr_6-15-2016.pdf
BR Audit Statement Date: 2016-05-13
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Trustis Limited - Trustis FPS Root CA
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8745582
Audit Statement Date: 2016-02-03
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8745582
BR Audit Statement Date: 2016-02-03
CA Comments: 2017 audit submitted via CCADB Audit Case is under review



Mozilla: Audit Reminder
Root Certificates:
   Certum Trusted Network CA 2
   Certum CA
   Certum Trusted Network CA
Standard Audit: https://cert.webtrust.org/SealFile?seal=2064=pdf
Audit Statement Date: 2016-06-10
BR Audit: https://cert.webtrust.org/SealFile?seal=2066=pdf
BR Audit Statement Date: 2016-06-10
EV Audit: https://cert.webtrust.org/SealFile?seal=2065=pdf
EV Audit Statement Date: 2016-06-10
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   FNMT-RCM - SHA256
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8766584
Audit Statement Date: 2016-05-18
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8766583
BR Audit Statement Date: 2016-05-18
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   GlobalSign ECC Root CA - R4
   GlobalSign 

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Rob Stradling via dev-security-policy]

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


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.  ;-)


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Ryan Sleevi via dev-security-policy]

On Tue, May 16, 2017 at 2:12 PM, Rob Stradling 
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? ;)
___
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

[Ryan Sleevi via dev-security-policy]

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

> On Tue, May 16, 2017 at 10:52 AM, Jakob Bohm via dev-security-policy
>  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Rob Stradling via dev-security-policy]

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-security-policy@lists.mozilla.org> wrote:


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



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.  ;-)


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Configuring Graduated Trust for Non-Browser Consumption

[Peter Bowen via dev-security-policy]

On Tue, May 16, 2017 at 10:52 AM, Jakob Bohm via dev-security-policy
 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
___
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

[Peter Bowen via dev-security-policy]

On Tue, May 16, 2017 at 10:04 AM, Jakob Bohm via dev-security-policy
 wrote:
> On 16/05/2017 18:10, Peter Bowen wrote:
>>
>> On Tue, May 16, 2017 at 9:00 AM, Jakob Bohm via dev-security-policy
>>  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.
>>
>
> 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
___
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

[Michael Casadevall via dev-security-policy]

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
___
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

[Michael Casadevall via dev-security-policy]

-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-
___
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

[Jakob Bohm via dev-security-policy]

On 16/05/2017 18:10, Peter Bowen wrote:

On Tue, May 16, 2017 at 9:00 AM, Jakob Bohm via dev-security-policy
 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.



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.




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

[Ryan Sleevi via dev-security-policy]

On Tue, May 16, 2017 at 12:00 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@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.
___
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

[Peter Bowen via dev-security-policy]

On Tue, May 16, 2017 at 9:00 AM, Jakob Bohm via dev-security-policy
 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
___
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

[Jakob Bohm via dev-security-policy]

On 16/05/2017 17:10, Peter Bowen wrote:



On May 16, 2017, at 7:42 AM, Jakob Bohm via dev-security-policy 
 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?



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.


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: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Ryan Sleevi via dev-security-policy]

On Tue, May 16, 2017 at 11:12 AM, Alex Gaynor via dev-security-policy <
dev-security-policy@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)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Alex Gaynor via dev-security-policy]

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

Alex

On Tue, May 16, 2017 at 11:11 AM, Ryan Sleevi  wrote:

>
>
> On Tue, May 16, 2017 at 11:00 AM, Rob Stradling via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On 16/05/17 15:41, Ryan Sleevi via dev-security-policy wrote:
>> 
>>
>>> 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?
>
___
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

[Peter Bowen via dev-security-policy]

> On May 16, 2017, at 7:42 AM, Jakob Bohm via dev-security-policy 
>  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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Ryan Sleevi via dev-security-policy]

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

> On 16/05/17 15:41, Ryan Sleevi via dev-security-policy wrote:
> 
>
>> 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?
___
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

[Ryan Sleevi via dev-security-policy]

On Tue, May 16, 2017 at 10:42 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Rob Stradling via dev-security-policy]

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


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 :)


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Configuring Graduated Trust for Non-Browser Consumption

[Jakob Bohm via dev-security-policy]

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



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.


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: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Ryan Sleevi via dev-security-policy]

On Tue, May 16, 2017 at 10:34 AM, Doug Beattie 
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 :)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Ryan Sleevi via dev-security-policy]

On Tue, May 16, 2017 at 10:27 AM, Rob Stradling 
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.


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

RE: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Doug Beattie via dev-security-policy]

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:agay...@mozilla.com]
Sent: Tuesday, May 16, 2017 10:31 AM
To: Rob Stradling 
Cc: Doug Beattie ; r...@sleevi.com; Peter Gutmann 
; Gervase Markham ; Nick Lamb 
; MozPol ; 
Cory Benfield 
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 
> 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.

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


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

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Ryan Sleevi via dev-security-policy]

On Tue, May 16, 2017 at 10:24 AM, Alex Gaynor  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Alex Gaynor via dev-security-policy]

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 
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.
>
> 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
>
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Rob Stradling via dev-security-policy]

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

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Ryan Sleevi via dev-security-policy]

On Tue, May 16, 2017 at 9:45 AM, Doug Beattie 
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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Alex Gaynor via dev-security-policy]

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

On Tue, May 16, 2017 at 10:22 AM, Ryan Sleevi  wrote:

>
>
> On Tue, May 16, 2017 at 7:58 AM, Peter Gutmann 
> wrote:
>
>> Ryan Sleevi  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)
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Ryan Sleevi via dev-security-policy]

On Tue, May 16, 2017 at 7:58 AM, Peter Gutmann 
wrote:

> Ryan Sleevi  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)
___
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

[Ryan Sleevi via dev-security-policy]

On Tue, May 16, 2017 at 9:54 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@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.
___
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

[Jakob Bohm via dev-security-policy]

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.




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: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Doug Beattie via dev-security-policy]

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=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=globalsign@lists.mozilla.org] On Behalf Of Ryan
> Sleevi via dev-security-policy
> Sent: Tuesday, May 16, 2017 7:48 AM
> To: Peter Gutmann 
> Cc: Nick Lamb ; MozPol  pol...@lists.mozilla.org>; Alex Gaynor ; Cory Benfield
> ; Ryan Sleevi ; Gervase Markham
> 
> Subject: Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser
> Consumption
> 
> On Tue, May 16, 2017 at 7:19 AM, Peter Gutmann
> 
> wrote:
> 
> > Ryan Sleevi  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?
> 
> 
> 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.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
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

[Alex Gaynor via dev-security-policy]

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

Alex

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

> 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-security-policy@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!
>
>
> 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
>
___
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

[Jakob Bohm via dev-security-policy]

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-security-policy@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!


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: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Peter Gutmann via dev-security-policy]

Michael Casadevall via dev-security-policy 
 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.

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Michael Casadevall via dev-security-policy]

On 05/16/2017 08:40 AM, Rob Stradling wrote:
> On 16/05/17 13:24, Michael Casadevall via dev-security-policy wrote:
> 
>> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Rob Stradling via dev-security-policy]

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


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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Michael Casadevall via dev-security-policy]

On 05/16/2017 06:05 AM, Peter Gutmann wrote:
> Ryan Sleevi via dev-security-policy  
> writes:
> 
> 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.
> 

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Peter Gutmann via dev-security-policy]

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Ryan Sleevi via dev-security-policy]

On Tue, May 16, 2017 at 7:19 AM, Peter Gutmann 
wrote:

> Ryan Sleevi  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?


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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Peter Gutmann via dev-security-policy]

Ryan Sleevi  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.

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Ryan Sleevi via dev-security-policy]

On Tue, May 16, 2017 at 6:05 AM Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Ryan Sleevi via dev-security-policy 
> 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.


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

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

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

[wangsn1206--- via dev-security-policy]

在 2017年5月16日星期二 UTC+8上午5:19:14，Patrick Tronnier写道：
> Greetings, I have reviewed your second BR self-assessment 
> (https://bugzilla.mozilla.org/attachment.cgi?id=8860627) against your updated 
> CP/CPS (CP V1.6, CPS V4.5, EV CP V1.4, and EV CPS V1.5) and provided the 
> following comments and/or recommendations.
> 
> 
> 1. BR Section 3.2.2.5 Authentication for an IP: Per your comments please make 
> sure your CPS states “GDCA does not issue EV certificate for an IP address.”
> 
> 2. BR Section 3.2.2.7 Data Source Accuracy: I recommend adding the specific 
> length of time data is relied upon (i.e. 39 months or 825 days per BRs) to 
> section 3.2.11 of your CPS.   
> 
> 3. BR Section 3.2.2.7 Data Source Accuracy: I recommend adding the specific 
> length of time data is relied upon (i.e. 39 months or 825 days per BRs) to 
> section 3.2.7 of your EV CPS.   
> 
> 4. BR Section 3.2.3 Authentication of Individual Identity: I do not see in 
> the CPS/CP where the differences in authentication of individuals is backed 
> up by the appropriate technical constraining of the type of certificate 
> issued. 
>4.1.   Your comments for Type I and Type II Individual Certificates 
> state they “are only for ordinary signing certificates, not for SSL 
> certificates and code signing certificates” but I can’t find in the CPS where 
> this is substantiated. I recommend clearly documenting in the CPS how each 
> type of certificate is technically constrained (i.e. Key Usage, Enhanced Key 
> Usage, etc.) and in CPS section 1.3.7.1 removing the words “but not limited 
> to”. 
>4.2.   For Type III certificates change the word “can” to “must”. 
> (i.e. This must be validated by ID card, officer card or other valid document 
> issued by government agency.”
> 
> 5. BR Section 3.2.5 Validation of Authority: Per your comments please make 
> sure this is clearly defined in the next version of your CPS.
> 
> 6. BR Section 3.2.6 Criteria for Interoperation or Certification. Per your 
> comments please make sure the next version of your CPS states you do not 
> issue any cross certificates. 
> 
> 7. BR Section 4.2.1 Performing Identification and Authentication Functions. 
> Per your comments please make sure the next version of your CPS states you do 
> not rely on data older than 27 months (or 39 months or 825 days per BRs).
> 
> 8. BR Section 4.2.2 Approval or Rejection of Certificate Applications: Per 
> your comments please make sure the next version of your CPS states GDCA does 
> not issue certificates containing a new gTLD under consideration by ICANN.
> 
> 9. BR Section 4.3.1 CA Actions during Certificate Issuance: Per your comments 
> please make sure the next version of your CPS states “Certificate issuance by 
> the Root CA SHALL require an individual authorized by the CA (i.e. the CA 
> system operator, system officer, or PKI administrator) to deliberately issue 
> a direct command in order for the Root CA to perform a certificate signing 
> operation.”
> 
> 10. BR Section 4.5.1 Subscriber private key and certificate usage: Per your 
> comments please make sure the next version of your CPS details the use of SSL 
> certificates per #4 (Use of Certificate) as described in BR Section 9.6.3. 
> Subscriber Representations and Warranties.
> 
> 11. BR Section 4.9.13 Circumstances for Suspension: Per your comments please 
> make sure the next version of your CPS states certificate suspension is not 
> allowed.
> 
> 12. BR Section 4.10.1 Operational Characteristics: Per your comments please 
> make sure the next version of your CPS states “Revocation entries on a CRL or 
> OCSP Response will not be removed until after the Expiry Date of the revoked 
> Certificate”.
> 
> 13. BR Section 4.10.2 Service Availability: Per your comments please make 
> sure the next version of your CPS states “the service response time shall be 
> less than 10 seconds”.
> 
> 14. Based on your self assessment comments in BR sections 1 – 4, I submit it 
> would be useful for you to revisit your assessment of BR sections 5 
> (MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS) through section 9 (OTHER 
> BUSINESS AND LEGAL MATTERS) and update your BR Assessment.

Hi Patrick, 

Thanks for the comments and recommendations, which will be duly considered as 
necessary in the next version of our CP/CPS to be published on around May 25, 
2017.
Thanks. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: April CA Communication: Results

[Peter Gutmann via dev-security-policy]

Jakob Bohm via dev-security-policy  
writes:

>Indeed, I strongly suspect Microsoft *customers* combined with Microsoft
>untrustworthiness (they officially closed their Trustworthy Computing
>initiative!) may be the major hold out, specifically:
>
>1. [...]

5. Microsoft has SHA-1 deeply hardcoded into their cert-management
   infrastructure, and in some places it can't be replaced.  For example their
   NDES cert management server replies to a SHA-2 request with a SHA-1
   response that can't be decrypted, implying that it's never even been tested
   with SHA-2.  If you submit an MD5 request then everything works as expected
   (as does SHA-1).
   
   That's MD5, in 2017.

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

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

[Peter Gutmann via dev-security-policy]

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

Re: Symantec: Update

[Michael Casadevall via dev-security-policy]

On 05/16/2017 03:50 AM, Michael Casadevall wrote:
> On 05/15/2017 06:05 PM, Jakob Bohm wrote:
>>
> 
>  - A three-day grace period shall be in place from the issuance date of
> a certificate to when it must be in the CT logs for validation reasons
> (this is in line with other proposals here).
> 
>  - All server authentication certificates shall be submitted to at least
> two public CT logs.
> 

Just realized I had a brainfart when writing this. Don't believe I can
supersede on this list to fix it so sorry for the chatter.

This should say that certificates must be issued with an embedded SCT
which Symantec can get from their own log, and then upload the
certificate to other logs as part of the issuance.

As part of the CT validation, there would be a three day grace period
from the issuance date, to when the certificate can start failing due to
CT failure which should leave a nice bit of padding for the maximum
merge delay on the current public logs.
Michael
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Update

[Michael Casadevall via dev-security-policy]

On 05/15/2017 06:05 PM, Jakob Bohm wrote:
>
> Ok, that's much better.
> 

Yay for reasonable courses of action. We'll see if it goes into the next
proposal.

>> I can see the point here, but I'm not sure I agree. Every time we keep
>> digging, we keep finding more and more problems with these roots.
>> WebPKI depends on all certificates in the root store being
>> trustworthy, and Symantec as a whole has not exactly shown themselves
>> to be responsive or willing to communicate publicly on the various
>> issues brought up on the list.
>>
> 
> Yes, that seems to be the trend.  But it has nothing to do with if the
> "9 month" rule or some other measures are the best remedy.
> 

There might be a reasonable compromise here, see below.

> RAs (external companies that can decide if Symantec itself should issue
> a cert) are completely different from external SubCAs (external
> companies that have their own CA and a certificate chain back to a
> Symantec root), which are different from internal SubCAs (CA
> certificates for Symantec controlled keys, such as the SubCA that
> signed normal OV certificates issued in January 2017).
> 
> External and Internal SubCAs can be blocked by simple technical means
> via TrustDB and OneCRL manipulations.  RAs are indistinguishable from
> Symantec itself when checking certificates, because the certificates
> were in fact signed by Symantec itself.
> 

I thought the RAs were being issued off their own intermediate branches
and not off Symantec ones. Rechecking crt.sh "C=KR, O=CrossCert,
OU=AccreditedCA, CN=CrossCert Class 1 Server CA" is a separate
intermediate chaining to KISA so I done goofed here. Oops.

Re-reading the issues, I think I got crossed between subCAs missing
audits, and RA issuance.

> The standard way this is done is that the old roots (which are trusted
> by old browsers) cross-sign the new roots or the subCAs of the new
> roots.  People buying new certs get (as always) a new cert chain for
> their new cert, which contains enough data to pass in browsers that
> trust new root, trust the old root, or trust both roots.
> 
> Servers with old certs still return the old certificate chain that
> leads to the old roots.
> 
> Other measures (such as browser embedded SubCA/cross certs) can be used
> to reduce how much of the old CA tree Firefox/Thunderbird trust during
> the transition.
> 

Thanks for clearing this up.

> I think we will need to look separately at two very different issues:
> 
> 1. Symantec's PKI and the location of the EV trust bit unfortunately
>   allows non-EV SubCAs to issue EV certs that Firefox marks as green.
>This same issue applies to most Mozilla trusted roots, because
>   Mozilla implemented the EV trust at the root CA level rather than at
>   a SubCA level.
> 
>This can be fixed technically by restricting the EV trust to the
>   SubCAs that are supposed to issue EV certs, rather than to whatever
>   general WebPKI root cert resides above it (in order for legitimate EV
>   certs to be trusted as normal certs by old browsers).
> 

This is a start.

We'd need confirmation from Symantec which subCAs are supposed to be
able to sign EV as I don't believe we have a complete list. That's also
assuming that things are that nice and organized (which is far from a
given). If we can successfully cut a good chunk of the crud away, it
would at least help in mind keeping EV being a reasonable option.

> 2. If there were any significant failures in the validation of EV
>   certs signed directly by the dedicated EV SubCAs at Symantec (other
>   than the one test cert that got some Symantec people fired some time
>   ago).
> 

Can we reasonably determine we're good here beyond a reasonable doubt?

The current responses to the last question found new parts of the fPKI
that are chaining via the Issue Y intermediates that appear that they
would be trusted by Mozilla. We also have confirmation that some of the
RAs could issue EVs and could validate certificates.

Symantec said that they independently checked the non-expired EV
certificates, but I think I have (IMHO) justified concerns there might
be additional ones here we don't know about.

Given the number of unknown knows with the EV situation right now, I
think I'm going to wait for more information before pushing any one
specific option, but at a minimium, we need to cut down the parts of the
tree that can sign for EV.

There's also a third issue is "what is the correct response to the
severity of Symantec's trust issues". We're fairly close to CNNIC
territory here, since we've got multiple intermediates that chain to the
Mozilla roots and can issue certificates which are either not BR
compliant, or out of scope of an audit.

In an attempt to try and get this thread to a point where the powers
that be might choose to include it in their proposal, let's try the
following in the addition to what is under PKI concerns in the gdoc:

---
 - For any Symantec-owned root certificate in the Mozilla trust