Re: New undisclosed intermediates

[Jakob Bohm via dev-security-policy]

On 09/06/2017 04:09, Jonathan Rudenberg wrote:



On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy 
 wrote:

I don't believe that disclosure of root certificates is the responsibility
of a CA that has cross-certified a key.  For instance, the CCADB interface
talks in terms of "Intermediate CAs".  Root CAs are the responsibility of
browsers to upload.  I don't even have access to upload a "root"
certificate.


I think the Mozilla Root Store policy is pretty clear on this point:


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


The self-signed certificates in the present set are all in scope for the 
disclosure policy because they are capable of being used to issue new 
certificates and chain to a certificate included in Mozilla’s CA Certificate 
Program. From the perspective of the Mozilla root store they look like 
intermediates because they can be used as intermediates in a valid path to a 
root certificate trusted by Mozilla.



This is getting awfully confusing.

What exactly about which specific certificates makes them both "self-
signed" and "part of a chain to a root in the Mozilla root store" ?

This seems to be a direct logical contradiction.

Here is how I see it:

If you are talking about two different certificates with the same public
key, then each such certificate needs to be considered separately.

If you are talking about two different certificates with the same
Subject Distinguished Name and optional id, but with different contents,
then again they need to be considered separately, as there is nothing
guaranteeing uniqueness of those fields.

If you are talking about two different certificates that differ only in 
the Issuer and Signature fields (and maybe in the serial number too), 
then again they need to be considered separately.


Chaining is defined by the tuple [Public Key, Subject, Optional Key ID],
deviating in either public key or subject certainly makes them unrelated
entities for chain building (except that sending irrelevant certificates
to the Browser can cause it to waste time comparing them).  Deviating in
the key ID may or may not cause certificates to not chain together
depending on the certificate checking library used (NSS being most
important for Mozilla, BouncyCastle and BoringSSL being of additional
interest for Chrome).

Certificates (not keys or names) that actually chain (as defined above)
to a root certificate in the CCADB are in scope for CCADB policy,
others are not.

Certificates that are in scope and have CA:TRUE in basic constraints
and/or CertificateSigning in Extended Key Usage or (maybe) have an
equivalent bit set in the historic Netscape/Mozilla key usage attribute
belong in CCADB.

Certificates that are in scope but lack all of these CA-usage flags are
end entity certificates that must satisfy Mozilla policy on correct
issuance (such as ownership checks, no RFC1918 addresses as SANs etc.).

Certificates that are not in scope are not in scope.

For example if a virus-scanning middle box has a locally generated root
CA trusted by the local clients (via configuration), and that virus
scanning middle box generates on-the fly certificates matching the names
(but not the keys) in the real public certificates it sees, then those
on-the fly certificates may have the same Subject as the real
certificates, but don't become in scope that way, even if they leak back
out through various forms of "telemetry".  Because there is no actual
way in which they would be trusted by a Mozilla browser that hasn't been
locally reconfigured to trust that local root CA.



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: New undisclosed intermediates

[Ben Wilson via dev-security-policy]

That's right, Peter.  They should be out of scope unless browsers want to trust 
them and/or they are submitted to browsers for that purpose, in which case 
browsers should be responsible for inputting them into the CCADB.  

Aside from treating these as "intermediates" or "subordinates", there are two 
other ways to look at a self-signed root certificate.  First and more commonly, 
it is a certificate that someone created for submission as a trust anchor (and 
it is usually created prior to submitting the public key for 
cross-certification),  and, second, it is basically a stub branch--because it 
is signing itself--that is one way that these kinds of certificates appear in 
the CCADB.  I've gone ahead and uploaded these two root CA certificates as 
"intermediates" 
(https://crt.sh/?sha256=29d8ac29f9007a6ad7923fdade32ef814ba3c6751551cf765416e8dbd8ff7619
 and 
https://crt.sh/?sha256=c02739e63880368967bb27fedf0a5749aeaf62a2328c09a7a33e876b4f27adca),
 but I don't think that that is the right approach, IMO, and it would be nice 
if a policy existed that recognized my concerns.  

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Thursday, June 8, 2017 8:17 PM
To: Jonathan Rudenberg 
Cc: Ben Wilson ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: New undisclosed intermediates

On Thu, Jun 8, 2017 at 7:09 PM, Jonathan Rudenberg via dev-security-policy 
 wrote:
>
>> On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy 
>>  wrote:
>>
>> I don't believe that disclosure of root certificates is the 
>> responsibility of a CA that has cross-certified a key.  For instance, 
>> the CCADB interface talks in terms of "Intermediate CAs".  Root CAs 
>> are the responsibility of browsers to upload.  I don't even have access to 
>> upload a "root"
>> certificate.
>
> I think the Mozilla Root Store policy is pretty clear on this point:
>
>> All certificates that are capable of being used to issue new certificates, 
>> and which directly or transitively chain to a certificate included in 
>> Mozilla’s CA Certificate Program, MUST be operated in accordance with this 
>> policy and MUST either be technically constrained or be publicly disclosed 
>> and audited.
>
> The self-signed certificates in the present set are all in scope for the 
> disclosure policy because they are capable of being used to issue new 
> certificates and chain to a certificate included in Mozilla’s CA Certificate 
> Program. From the perspective of the Mozilla root store they look like 
> intermediates because they can be used as intermediates in a valid path to a 
> root certificate trusted by Mozilla.

There are two important things about self-issued certificates:

1) They cannot expand the scope of what is allowed.
Cross-certificates can create alternative paths with different restrictions.  
Self-issued certificates do not provide alternative paths that may have fewer 
constraints.

2) There is no way for a "parent" CA to prevent them from existing.
Even if the only cross-sign has a path length constraint of zero, the "child" 
CA can issue self-issued certificates all day long.  If they are self-signed 
there is no real value in disclosing them, given #1.

I think that it is reasonable to say that self-signed certificates are out of 
scope.

Thanks,
Peter


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New undisclosed intermediates

[Peter Bowen via dev-security-policy]

On Thu, Jun 8, 2017 at 7:09 PM, Jonathan Rudenberg via
dev-security-policy  wrote:
>
>> On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy 
>>  wrote:
>>
>> I don't believe that disclosure of root certificates is the responsibility
>> of a CA that has cross-certified a key.  For instance, the CCADB interface
>> talks in terms of "Intermediate CAs".  Root CAs are the responsibility of
>> browsers to upload.  I don't even have access to upload a "root"
>> certificate.
>
> I think the Mozilla Root Store policy is pretty clear on this point:
>
>> All certificates that are capable of being used to issue new certificates, 
>> and which directly or transitively chain to a certificate included in 
>> Mozilla’s CA Certificate Program, MUST be operated in accordance with this 
>> policy and MUST either be technically constrained or be publicly disclosed 
>> and audited.
>
> The self-signed certificates in the present set are all in scope for the 
> disclosure policy because they are capable of being used to issue new 
> certificates and chain to a certificate included in Mozilla’s CA Certificate 
> Program. From the perspective of the Mozilla root store they look like 
> intermediates because they can be used as intermediates in a valid path to a 
> root certificate trusted by Mozilla.

There are two important things about self-issued certificates:

1) They cannot expand the scope of what is allowed.
Cross-certificates can create alternative paths with different
restrictions.  Self-issued certificates do not provide alternative
paths that may have fewer constraints.

2) There is no way for a "parent" CA to prevent them from existing.
Even if the only cross-sign has a path length constraint of zero, the
"child" CA can issue self-issued certificates all day long.  If they
are self-signed there is no real value in disclosing them, given #1.

I think that it is reasonable to say that self-signed certificates are
out of scope.

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

Re: New undisclosed intermediates

[Jonathan Rudenberg via dev-security-policy]

> On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy 
>  wrote:
> 
> I don't believe that disclosure of root certificates is the responsibility
> of a CA that has cross-certified a key.  For instance, the CCADB interface
> talks in terms of "Intermediate CAs".  Root CAs are the responsibility of
> browsers to upload.  I don't even have access to upload a "root"
> certificate.  

I think the Mozilla Root Store policy is pretty clear on this point:

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

The self-signed certificates in the present set are all in scope for the 
disclosure policy because they are capable of being used to issue new 
certificates and chain to a certificate included in Mozilla’s CA Certificate 
Program. From the perspective of the Mozilla root store they look like 
intermediates because they can be used as intermediates in a valid path to a 
root certificate trusted by Mozilla.

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

Re: New undisclosed intermediates

[Peter Bowen via dev-security-policy]

On Thu, Jun 8, 2017 at 7:02 PM, Matthew Hardeman via
dev-security-policy  wrote:
> On Thursday, June 8, 2017 at 7:44:08 PM UTC-5, Ben Wilson wrote:
>> I don't believe that disclosure of root certificates is the responsibility
>> of a CA that has cross-certified a key.  For instance, the CCADB interface
>> talks in terms of "Intermediate CAs".  Root CAs are the responsibility of
>> browsers to upload.  I don't even have access to upload a "root"
>> certificate.
>
> At least in terms of intention of disclosing the intermediates, I don't think 
> you've made a fair assessment of the situation.
>
> The responsibility to disclose must fall upon the signer.  Not the one who 
> was signed.
>
> Cross-signature certificates are, effectively, intermediates granting an 
> alternate / enhanced validation path to trust to a distinct, separate 
> hierarchy.
>
> While IdenTrust signs Let's Encrypt's intermediates rather than a cross-sign 
> of their root, the principle is ultimately the same.  The browser programs 
> clearly wish to have those who are positioned to grant trust accountable for 
> any such trust that they grant.
>
> It's one question if the other root is already in the trust store, but 
> imagine it's some large enterprise root that's been running, perhaps under 
> appropriate audits but maybe not, cross-signed by a widely trusted program 
> participant.
>
> Perhaps the text needs clarifying, but I find it hard to believe that any of 
> the browser programs is of the opinion that you can cross-sign someone else's 
> root cert and not disclose that.

I don't think that is the question at hand.  I think Ben means
"self-signed" or "self-issued" when he says "root" certificate.

I agree with Ben that self-signed certificates should be out of scope.
Self-issued certificates that are not self-signed probably should be
in scope.

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

Re: New undisclosed intermediates

[Matthew Hardeman via dev-security-policy]

On Thursday, June 8, 2017 at 7:44:08 PM UTC-5, Ben Wilson wrote:
> I don't believe that disclosure of root certificates is the responsibility
> of a CA that has cross-certified a key.  For instance, the CCADB interface
> talks in terms of "Intermediate CAs".  Root CAs are the responsibility of
> browsers to upload.  I don't even have access to upload a "root"
> certificate.  

At least in terms of intention of disclosing the intermediates, I don't think 
you've made a fair assessment of the situation.

The responsibility to disclose must fall upon the signer.  Not the one who was 
signed.

Cross-signature certificates are, effectively, intermediates granting an 
alternate / enhanced validation path to trust to a distinct, separate hierarchy.

While IdenTrust signs Let's Encrypt's intermediates rather than a cross-sign of 
their root, the principle is ultimately the same.  The browser programs clearly 
wish to have those who are positioned to grant trust accountable for any such 
trust that they grant.

It's one question if the other root is already in the trust store, but imagine 
it's some large enterprise root that's been running, perhaps under appropriate 
audits but maybe not, cross-signed by a widely trusted program participant.

Perhaps the text needs clarifying, but I find it hard to believe that any of 
the browser programs is of the opinion that you can cross-sign someone else's 
root cert and not disclose that.

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

RE: New undisclosed intermediates

[Ben Wilson via dev-security-policy]

I don't believe that disclosure of root certificates is the responsibility
of a CA that has cross-certified a key.  For instance, the CCADB interface
talks in terms of "Intermediate CAs".  Root CAs are the responsibility of
browsers to upload.  I don't even have access to upload a "root"
certificate.  

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Kurt Roeckx via dev-security-policy
Sent: Thursday, June 8, 2017 6:40 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: New undisclosed intermediates

On 2017-06-08 14:09, wiz...@ida.net wrote:
> But Censys lists it as a trusted intermediate chaining to a root (
ebc5570c29018c4d67b1aa127baf12f703b4611ebc17b7dab5573894179b93fa ) in NSS:
> 
> https://censys.io/certificates/b82210cde9ddea0e14be29af647e4b32f96ed2a
> 9ef1aa5baa9cc64b38b6c01ca/validation

I got confused by crt.sh, it's not obvious if a certificate is in some root
store or not. They have an other certificate
(https://crt.sh/?q=ebc5570c29018c4d67b1aa127baf12f703b4611ebc17b7dab55738941
79b93fa)
for the same CA that is in the root store.

I have no idea what common implementations do when trying to validate a
chain with such certificate in the middle.

> With respect to Gerv's question: given the ample time to disclose
intermediates, and given all CAs in the program indicated that they had,
seems reasonable to immediately add undisclosed ones that are discovered to
OneCRL. Other than some breakage, as already noted, main downside would seem
to be potentially large growth in OneCRL.

I think there are 2 solutions: OneCRL or a whitelist. OneCRL is probably
easier to do, no new code would need to be written in the browser or NSS. A
whitelist would mean that that list would need to get updated regularly and
that list is probably larger.


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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

[Jakob Bohm via dev-security-policy]

On 08/06/2017 18:47, David E. Ross wrote:

On 6/8/2017 2:38 AM, Gervase Markham wrote:

On 02/06/17 11:28, Gervase Markham wrote:

Proposal: add a bullet to section 2.3, where we define BR exceptions:

"Insofar as the Baseline Requirements attempt to define their own scope,
the scope of this policy (section 1.1) overrides that. Mozilla expects
CA operations relating to issuance of all SSL certificates in the scope
of this policy to conform to the Baseline Requirements."


Implemented as specced.

Gerv



This seems self-contradictory.

How about adding only 2 words ("Nevertheless" and "also") to the second
sentence:

Insofar as the Baseline Requirements attempt to define their own scope,
the scope of this policy (section 1.1) overrides that. Nevertheless,
Mozilla expects CA operations relating to issuance of all SSL
certificates in the scope of this policy to conform also to the Baseline
Requirements.



How about the following, which seems more correct

Insofar as the Baseline Requirements attempt to define their own scope,
the scope of this policy (section 1.1) overrides that. Mozilla
thus requires CA operations relating to issuance of all SSL certificates
in the scope of this policy to conform to the Baseline Requirements.


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: Mozilla requirements of Symantec

[Jakob Bohm via dev-security-policy]

On 08/06/2017 18:52, Peter Bowen wrote:

On Thu, Jun 8, 2017 at 9:38 AM, Jakob Bohm via dev-security-policy
 wrote:


As the linked proposal was worded (I am not on Blink mailing lists), it
seemed obvious that the original timeline was:

   Later: Once the new roots are generally accepted, Symantec can actually
issue from the new SubCAs.

   Long term: CRL and OCSP management for the managed SubCAs remain with the
third party CAs.  This continues until the managed SubCAs expire or are
revoked.


I don't see this last part in the proposal.  Instead the proposal
appears to specifically contemplate the SubCAs being transferred to
Symantec once the new roots are accepted in the required trust stores.



That last part was derived purely from the logistical difficulty of
moving private keys compared to just keeping CRL and OCSP running in an
infrastructure that would keep running anyway (for the hosting CAs own
CA certificates).




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: Mozilla requirements of Symantec

[Peter Bowen via dev-security-policy]

On Thu, Jun 8, 2017 at 9:38 AM, Jakob Bohm via dev-security-policy
 wrote:
>
> As the linked proposal was worded (I am not on Blink mailing lists), it
> seemed obvious that the original timeline was:
>
>   Later: Once the new roots are generally accepted, Symantec can actually
> issue from the new SubCAs.
>
>   Long term: CRL and OCSP management for the managed SubCAs remain with the
> third party CAs.  This continues until the managed SubCAs expire or are
> revoked.

I don't see this last part in the proposal.  Instead the proposal
appears to specifically contemplate the SubCAs being transferred to
Symantec once the new roots are accepted in the required trust stores.

Additionally, there is no policy, as far as I know, that governs
transfer of non-Root CAs.  This is possibly a gap, but an existing
one.

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

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

[David E. Ross via dev-security-policy]

On 6/8/2017 2:38 AM, Gervase Markham wrote:
> On 02/06/17 11:28, Gervase Markham wrote:
>> Proposal: add a bullet to section 2.3, where we define BR exceptions:
>>
>> "Insofar as the Baseline Requirements attempt to define their own scope,
>> the scope of this policy (section 1.1) overrides that. Mozilla expects
>> CA operations relating to issuance of all SSL certificates in the scope
>> of this policy to conform to the Baseline Requirements."
> 
> Implemented as specced.
> 
> Gerv
> 

This seems self-contradictory.

How about adding only 2 words ("Nevertheless" and "also") to the second
sentence:

Insofar as the Baseline Requirements attempt to define their own scope,
the scope of this policy (section 1.1) overrides that. Nevertheless,
Mozilla expects CA operations relating to issuance of all SSL
certificates in the scope of this policy to conform also to the Baseline
Requirements.

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

Re: Mozilla requirements of Symantec

[Jakob Bohm via dev-security-policy]

On 08/06/2017 11:09, Gervase Markham wrote:

On 07/06/17 22:30, Jakob Bohm wrote:

Potential clarification: By "New PKI", Mozilla apparently refers to the
"Managed CAs", "Transition to a New Symantec PKI" and related parts of
the plan, not to the "new roots" for the "modernized platform" / "new
infrastructure".


I expect those things to be interlinked; by "New PKI" I was referring to
them both.

Symantec has not yet stated how they plan to structure their new
arrangements, but I would expect that the intermediate certs run by the
managed CAs would in some way become part of Symantec's new PKI,
operated by them, once it was up and running. Ryan laid out a way
Symantec could structure this on blink-dev, I believe, but the final
structure is up to them.



As the linked proposal was worded (I am not on Blink mailing lists), it 
seemed obvious that the original timeline was:


  August 2017: All new certs issued by Managed SubCAs that chain to the 
old Symantec roots.  Private keys for these SubCAs reside an the third 
party CAs in secure hardware which will presumable prevent sharing them 
with Symantec.


  Much later: The new infrastructure passes all readiness audits.

  Then: A signing ceremony creates the new roots and their first set of 
SubCAs.  Cross signatures are created from the old roots to the new 
roots.   Maybe/Maybe not cross signatures are also created from the new 
roots to the managed SubCAs.


  Next: Symantec reapplies for inclusion with the new roots.

  Later: Once the new roots are generally accepted, Symantec can 
actually issue from the new SubCAs.


  Long term: CRL and OCSP management for the managed SubCAs remain with 
the third party CAs.  This continues until the managed SubCAs expire or 
are revoked.



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: New undisclosed intermediates

[Jeremy Rowley via dev-security-policy]

If you added them automatically to OneCRL, how would you create new
intermediates? Would it be anything over X days old and undisclosed is
automatically added? If so, +1 from us.  I'm pretty sure the two CAs listed
from the Baltimore root don't believe these are publicly trusted
intermediates. 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Gervase Markham via dev-security-policy
Sent: Thursday, June 8, 2017 3:17 AM
To: Jonathan Rudenberg ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: New undisclosed intermediates

On 08/06/17 00:42, Jonathan Rudenberg wrote:
> Yet another batch of undisclosed intermediates has shown up in CT:

Like, seriously?

Every CA in our program indicated that they would disclose all their
intermediates by June 30th, 2016:

https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesO
nlyReport?CommunicationId=a05o00iHdtx=Q4

I don't really want to switch to an intermediate whitelist because that
requires coding.

My patience is expiring. What CA can't keep track of the intermediates it
issues? How hard is that, really?

What downsides would there be, other than the obvious "some sites might
break", to us just adding any such intermediate certs directly to OneCRL?

Gerv

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New undisclosed intermediates

[Kurt Roeckx via dev-security-policy]

On 2017-06-08 14:09, wiz...@ida.net wrote:

But Censys lists it as a trusted intermediate chaining to a root ( 
ebc5570c29018c4d67b1aa127baf12f703b4611ebc17b7dab5573894179b93fa ) in NSS:

https://censys.io/certificates/b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca/validation


I got confused by crt.sh, it's not obvious if a certificate is in some 
root store or not. They have an other certificate 
(https://crt.sh/?q=ebc5570c29018c4d67b1aa127baf12f703b4611ebc17b7dab5573894179b93fa) 
for the same CA that is in the root store.


I have no idea what common implementations do when trying to validate a 
chain with such certificate in the middle.



With respect to Gerv's question: given the ample time to disclose 
intermediates, and given all CAs in the program indicated that they had, seems 
reasonable to immediately add undisclosed ones that are discovered to OneCRL. 
Other than some breakage, as already noted, main downside would seem to be 
potentially large growth in OneCRL.


I think there are 2 solutions: OneCRL or a whitelist. OneCRL is probably 
easier to do, no new code would need to be written in the browser or 
NSS. A whitelist would mean that that list would need to get updated 
regularly and that list is probably larger.



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

Re: New undisclosed intermediates

[Kurt Roeckx via dev-security-policy]

On 2017-06-08 14:16, Rob Stradling wrote:
crt.sh collates revocation information from all known CRL Distribution 
Point URLs for each CA.  The CDP URLs listed at 
https://crt.sh/?id=12729173 were observed in other certs issued by the  > same CA:


That shows:
http://www.cert.fnmt.es/crls/ARLFNMTRCM.crl

But tries to use:
http://www.cert.fnmt.es.testa.eu/crls/ARLFNMTRCMEU.crl


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

Re: Symantec response to Google proposal

[wizard--- via dev-security-policy]

On Tuesday, June 6, 2017 at 10:03:29 AM UTC-4, Gervase Markham wrote:
> On 02/06/17 15:53, Gervase Markham wrote:
> > https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal
> 
> I'm slightly surprised to see no engagement here. 

I think many of us are worn out with the poor responses from Symantec, who seem 
to treat this as a matter easily resolved with negotiation rather than actually 
addressing the underlying technical and procedural concerns. 

Symantec's slow responsiveness, attempt to limit community input by hosting 
responses outside the natural conversation threads (PDFs, blog posts that don't 
load on locked down browsers, etc), and apparent attempts to shield was should 
be a transparent process under the guise of "commercial secrets" would be cause 
for full loss of trust by any other CA. They have now had multiple chances to 
respond in an appropriate fashion and have failed to do so, so I don't see why 
the response here should be any different. Thus, at this point, if I were 
mozilla and Google, I would:

1) set a sunset date of 06/01/2018 for the ban to take effect. 
2) immediately (next firefox/chrome release) add a small banner message (or 
similar) any time a Symantec certificate is found stating "Symantec 
certificates will soon be distrusted; if you are the site owner,  to 
read more" Where go here goes to this and the intent thread @ Google. Site 
owners will get the message -- either directly by their own browsing, or from 
their customers. Note that this direct-to-user messages, while should be used 
sparingly, is the ~only mechanism available to browsers to make sure 
appropriate eyeballs see that a certificate change is needed by the site owner. 
I suspect it would greatly have helped with the Wosign distrust, for example.

Of course the above does not preclude Symantec from getting a separate/new 
managed PKI (from another CA) to be able to replace certificates for customers 
immediately, nor does it preclude the possibility of this new PKI transitioning 
back to symantec control once they demonstrate they have resolved the 
underlying issues. 

But what the above does do is shift the risks from the relying parties (who are 
the ones with almost all the risk as symantec drags their feet), to Symantec 
(they either get their act together or exit the CA business).

So I, for one, have no particular interest in continuing to engage in a 
discussion with an uncooperative party. The time for softball has ended.


> Perhaps it would be
> help to break it down. Symantec's specific requests for modification are
> as follows (my interpretation):
> 
> 1) Scope of Distrust
> 
> Google proposal: existing CT-logged certificates issued after 1st June
> 2016 would continue to be trusted until expiry.
> Symantec proposal: all CT-logged certificates should continue to be
> trusted until expiry.
> Rationale for change: if transparency is enough to engender trust, that
> principle should be applied consistently. This also significantly
> reduces the revalidation burden.
> 
> 2) Timeline
> 
> Google proposal: a set of dates by which certain milestones must be
> achieved.
> Symantec proposal: no specific alternative dates (more info by the end
> of June), but the Google dates are too aggressive.
> Rationale: need to establish business relationships; capacity issues at
> Managed CAs; international requirements further complicate things; the
> revalidation burden is very large; writing solid code takes time.
> 
> 3) SubCA Audit Type
> 
> Google proposal: SubCAs are audited with the standard audits.
> Symantec proposal: treat SubCAs as Delegated Third Parties and so give
> them BR section 8 audits (an audit by the CA not an auditor; 3% sampling).
> Rationale: none given.
> 
> 4) Validation Task Ownership
> 
> Google proposal: Symantec and its affiliates must not participate in any
> of the information verification roles permitted under the Baseline
> Requirements. They may, however, collect and aggregate information.
> Symantec proposal: Symantec currently uses a 2-step process - validation
> and review. Symantec should be allowed to do the first, with the SubCA
> doing the second (with 100% review, not samplingh).
> Rationale: reducing the burden on the SubCA, reducing the time for them
> to ramp up, and (presumably) to allow the Symantec personnel to continue
> to have jobs.
> 
> 5) Use of DTPs by SubCA
> 
> Google proposal: SubCAs may not use Delegated Third Parties in the
> validation process for domain names or IP addresses.
> Symantec proposal: SubCAs should be allowed to continue to use them in
> situations where they already do.
> Rationale: SubCAs should not be required to rejig their processes to
> work with Symantec.
> 
> 6) SubCA Audit Timing
> 
> Google proposal: SubCAs are audited at 3 month intervals in the 1st
> year, 6 months intervals in the 2nd year, and then yearly.
> Symantec proposal: after the initial audit, only yearly audits should be
> required.
> 

Re: New undisclosed intermediates

[Rob Stradling via dev-security-policy]

On 08/06/17 12:57, Kurt Roeckx via dev-security-policy wrote:

On 2017-06-08 13:31, richmoor...@gmail.com wrote:
This one is interesting since the domain name of the CRL resolves to 
an RFC 1918 IP address. Surely that is a violation of the baseline 
requirements.


https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca 



That seems to be a root CA. It does not mention any CRL. I don't expect 
a root CA to have a CRL. I'm not sure from where crt.sh is getting the 
CRL URL.


crt.sh collates revocation information from all known CRL Distribution 
Point URLs for each CA.  The CDP URLs listed at 
https://crt.sh/?id=12729173 were observed in other certs issued by the 
same CA:


https://crt.sh/?Identity=%25=241

--
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: New undisclosed intermediates

[wizard--- via dev-security-policy]

But Censys lists it as a trusted intermediate chaining to a root ( 
ebc5570c29018c4d67b1aa127baf12f703b4611ebc17b7dab5573894179b93fa ) in NSS: 

https://censys.io/certificates/b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca/validation

With respect to Gerv's question: given the ample time to disclose 
intermediates, and given all CAs in the program indicated that they had, seems 
reasonable to immediately add undisclosed ones that are discovered to OneCRL. 
Other than some breakage, as already noted, main downside would seem to be 
potentially large growth in OneCRL.

On Thursday, June 8, 2017 at 7:58:51 AM UTC-4, Kurt Roeckx wrote:
> On 2017-06-08 13:31, richmoor...@gmail.com wrote:
> > This one is interesting since the domain name of the CRL resolves to an RFC 
> > 1918 IP address. Surely that is a violation of the baseline requirements.
> > 
> > https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca
> 
> That seems to be a root CA. It does not mention any CRL. I don't expect 
> a root CA to have a CRL. I'm not sure from where crt.sh is getting the 
> CRL URL.
> 
> 
> Kurt

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

Re: New undisclosed intermediates

[Kurt Roeckx via dev-security-policy]

On 2017-06-08 13:31, richmoor...@gmail.com wrote:

This one is interesting since the domain name of the CRL resolves to an RFC 
1918 IP address. Surely that is a violation of the baseline requirements.

https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca


That seems to be a root CA. It does not mention any CRL. I don't expect 
a root CA to have a CRL. I'm not sure from where crt.sh is getting the 
CRL URL.



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

Re: New undisclosed intermediates

[richmoore44--- via dev-security-policy]

This one is interesting since the domain name of the CRL resolves to an RFC 
1918 IP address. Surely that is a violation of the baseline requirements.

https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca

Regards

Rich.


On Thursday, June 8, 2017 at 12:45:25 AM UTC+1, Jonathan Rudenberg wrote:
> > On Jun 5, 2017, at 09:29, Alex Gaynor via dev-security-policy 
> >  wrote:
> > 
> > Happy Monday!
> > 
> > Another week, another set of intermediate certs that have shown up in CT
> > without having been properly disclosed:
> > https://crt.sh/mozilla-disclosures#undisclosed
> 
> Yet another batch of undisclosed intermediates has shown up in CT:
> 
> - 
> https://crt.sh/?sha256=f01c1aca392882af152e9f01ecccd0afddd8aa35bf895b003198b1e8c752ddb8
> - 
> https://crt.sh/?sha256=29d8ac29f9007a6ad7923fdade32ef814ba3c6751551cf765416e8dbd8ff7619
> - 
> https://crt.sh/?sha256=c02739e63880368967bb27fedf0a5749aeaf62a2328c09a7a33e876b4f27adca
> - 
> https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca
> - 
> https://crt.sh/?sha256=8e8c6ebf77dc73db3e38e93f4803e62b6b5933beb51ee4152f68d7aa14426b31
> - 
> https://crt.sh/?sha256=48db8801874e0e36b1b864603b31648b74e2322a8f9e4967a8f54bd1b8f594de
> - 
> https://crt.sh/?sha256=1bc400808ab07b775c811c631d75ab38fe7be7df6967f5b384bfe8dc9ef807c6
> - 
> https://crt.sh/?sha256=f1f072c64d69e573725533e83a601bb8b068f6699e59ba70eda2aecb28e06bfb

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

Root Store Policy 2.5: Call For Review and Phase-In Periods

[Gervase Markham via dev-security-policy]

Hi everyone,

I've made the last change I currently intend to make for version 2.5 of
Mozilla's Root Store Policy. The last task before shipping it is to
assess whether any of the changes require a phase-in period, i.e. for
some reason, they can't be applicable immediately.

CAs and others are requested to comment, with rationale, as to why
particular changes will need a phase-in period and what period they are
proposing as appropriate. This is also an opportunity for interested
parties to do a general final review.

I hope to ship the policy immediately after the CAB Forum meeting in
Berlin, which is happening from the 20th to the 22nd of June.

You can see the differences between version 2.4.1 and version 2.5 here
in diff format (click "Files Changed" and then "Load Diff"):
https://github.com/mozilla/pkipolicy/compare/2.4.1...master

or here in a more rich format:
https://github.com/mozilla/pkipolicy/compare/2.4.1...master?short_path=b7447c8
(click "Files Changed" and scroll down).

The CCADB Policy changes are trivial and can be ignored.

Here is my summary of what's changed that's significant (with section
numbers in brackets), although you should not rely on it to be complete:


1) Certificates with anyEKU have been added to the scope. (1.1)

2) CAs are required to "follow industry best practice for securing their
networks, for example by conforming to the CAB Forum Network Security
Guidelines or a successor document". (2.1)

3) Accounts which perform "Registration Authority or Delegated Third
Party functions" are now also required to have multi-factor auth. (2.1)

4) CAs are required to follow, but not required to contribute to,
mozilla.dev.security.policy. (2.1)

5) CAs are required to use only the 10 Blessed Methods for domain
validation. (2.2) This requirement has already had a deadline set for it
in the most recent CA Communication; that deadline is 21st July 2017.

6) WebTrust BR audits must now use version 2.2 or later of the audit
criteria. (3.1.1)

7) The ETSI audit criteria requirements have been updated to be
accurate. (3.1.2.2). ETSI TS 102 042 and TS 101 456 audits will only be
accepted for audit periods ending in July 2017 or earlier.

8) There are further requirements on the information that needs to be
contained in publicly-available audit information. (3.1.3)

9) Mozilla now requires that auditors be qualified in the scheme they
are using, unless agreed in writing beforehand. (3.2)

10) When CAs do their BR-required yearly update of their CPs and CPSes,
they MUST indicate this by incrementing the version number and adding a
dated changelog entry. (3.3)

11) The Mozilla CCADB Policy has been merged into the Root Store Policy,
but the requirements have not changed. (4.1/4.2)

12) CA are required at all times to operate in accordance with the
applicable CP and CPS. (5.2)

13) The requirements for what constitutes a TCSC for email have been
reformed to actually make some sense - the cert now has to have
meaningful technical constraints on rfc822Name. (5.3.1)

14) New intermediates must be disclosed in the CCADB within a week. (5.3.2)

15) Requirements for revocation are now delegated to the BRs rather than
being explicitly enumerated. (6)

16) Section 7.4 ("Transfers") has been replaced by a new section 8 which
requires CAs to notify of various operational changes. This is a
merge-in of text equivalent to the existing Root Transfer Policy which
was documented on our wiki. (8)


Gerv

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

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

[Gervase Markham via dev-security-policy]

On 02/06/17 11:28, Gervase Markham wrote:
> Proposal: add a bullet to section 2.3, where we define BR exceptions:
> 
> "Insofar as the Baseline Requirements attempt to define their own scope,
> the scope of this policy (section 1.1) overrides that. Mozilla expects
> CA operations relating to issuance of all SSL certificates in the scope
> of this policy to conform to the Baseline Requirements."

Implemented as specced.

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

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

[Gervase Markham via dev-security-policy]

On 04/06/17 03:03, Matt Palmer wrote:
> For whatever it is worth, I am a fan of this way of defining "misissuance".

This is an "enumerating badness" vs. "enumerating goodness" question. My
original draft attempted to (without limitation) enumerate some badness,
and you and Ryan are suggesting that it would be better instead to
enumerate goodness.

I agree. However, enumerating goodness is a bit harder because you need
to make sure you get all the goodness, so as not to accidentally ban
something you want. This we could do, but I feel it would require
consultation with CAs.

Therefore, I will add the non-limiting enumerating badness version to
the policy, as an improvement on the current wording which also
enumerates badness, but I've filed these two issues:

https://github.com/mozilla/pkipolicy/issues/86
https://github.com/mozilla/pkipolicy/issues/85

on improving this further in the future.

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

Re: New undisclosed intermediates

[Gervase Markham via dev-security-policy]

On 08/06/17 10:17, Gervase Markham wrote:
> What downsides would there be, other than the obvious "some sites might
> break", to us just adding any such intermediate certs directly to OneCRL?

We provide reports which allow CAs to download the stored intermediate
cert data:

https://ccadb-public.secure.force.com/mozilla/PublicAllIntermediateCertsCSV

So if they don't want this to happen to them, all they need to do is
write a script to download the data daily, compare it with their
internal records, and send out an alert when it finds a discrepancy.

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

Re: New undisclosed intermediates

[Gervase Markham via dev-security-policy]

On 08/06/17 00:42, Jonathan Rudenberg wrote:
> Yet another batch of undisclosed intermediates has shown up in CT:

Like, seriously?

Every CA in our program indicated that they would disclose all their
intermediates by June 30th, 2016:

https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o00iHdtx=Q4

I don't really want to switch to an intermediate whitelist because that
requires coding.

My patience is expiring. What CA can't keep track of the intermediates
it issues? How hard is that, really?

What downsides would there be, other than the obvious "some sites might
break", to us just adding any such intermediate certs directly to OneCRL?

Gerv

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

Re: Mozilla requirements of Symantec

[Gervase Markham via dev-security-policy]

On 07/06/17 22:30, Jakob Bohm wrote:
> Potential clarification: By "New PKI", Mozilla apparently refers to the
> "Managed CAs", "Transition to a New Symantec PKI" and related parts of
> the plan, not to the "new roots" for the "modernized platform" / "new
> infrastructure".

I expect those things to be interlinked; by "New PKI" I was referring to
them both.

Symantec has not yet stated how they plan to structure their new
arrangements, but I would expect that the intermediate certs run by the
managed CAs would in some way become part of Symantec's new PKI,
operated by them, once it was up and running. Ryan laid out a way
Symantec could structure this on blink-dev, I believe, but the final
structure is up to them.

> Potential clarification: Mozilla's #3 requirement applies to both the
> "new PKI" and the "new roots" for the "new infrastructure".

Yes, I suppose so, although I would expect such an extra-detailed audit
to be done on the new infrastructure rather than on the Managed CA
infrastructure which is owned by another CA.

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

Re: An alternate perspective on Symantec

[Gervase Markham via dev-security-policy]

On 07/06/17 06:14, userwithuid wrote:
> 2. Having Symantec inform their subscribers, as David mentions, is a great 
> idea.

I believe Ryan has pointed out, here or elsewhere, why "must notify
customers" requirements are problematic.

Gerv


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

Re: Symantec response to Google proposal

[Gervase Markham via dev-security-policy]

On 06/06/17 19:59, Jakob Bohm wrote:
> I don't see a problem in access to this being subject to a reasonable
> NDA that allows Mozilla to show it to their choice of up to 50 external
> experts (I don't expect to be one of those 50).

The problem with an NDA is that if the audit reports significant holes
in Symantec's security story, we can't talk about them here.

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