Re: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

[Nick Lamb via dev-security-policy]

On Tuesday, 4 July 2017 10:50:43 UTC+1, Jeremy Rowley  wrote:
> I'm an idiot. The discussion wasn't meant to be a red herring.  Just a
> momentary lapse in intelligence...
> 
> It really looks like this from a validation perspective, right? EE ->
> Self-signed -> Issuing CA (as it has the same key) -> Digicert Root
> 
> Yeah - I agree it should have been disclosed. Apologies for the confusion. 

No problem Jeremy, thanks for owning up to that. Yes, I believe this is the 
validation chain everybody is picturing.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

[Jeremy Rowley via dev-security-policy]

Thanks Rob.  Appreciate the links. 

-Original Message-
From: Rob Stradling [mailto:rob.stradl...@comodo.com] 
Sent: Tuesday, July 4, 2017 3:50 AM
To: Jeremy Rowley ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert policy violation - non-disclosure of 
https://crt.sh/?id=160110886

Hi Jeremy.  I'm not aware of any formal definition in any RFC of the phrase 
"transitively chains".

My recollection (and Hanno's [1]) is that this terminology dates back to the 
2010 write-up of the EFF SSL Observatory [2], in which the word "transvalid" 
was coined.


[1]
https://blog.hboeck.de/archives/847-Incomplete-Certificate-Chains-and-Transvalid-Certificates.html

[2]
https://events.ccc.de/congress/2010/Fahrplan/attachments/1777_is-the-SSLiverse-a-safe-place.pdf
Slide 29

On 03/07/17 21:59, Jeremy Rowley wrote:
> Link please to a formal definition? As your email alleges a policy violation 
> by one a cross-signed CAs, we take the investigation and response very 
> seriously. I'd like to know the basis for the definition before formulating 
> an official report and potentially penalizing the Sub CA for non-compliance.
> 
> -Original Message-
> From: Rob Stradling [mailto:rob.stradl...@comodo.com]
> Sent: Monday, July 3, 2017 2:14 PM
> To: Jeremy Rowley ; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: DigiCert policy violation - non-disclosure of 
> https://crt.sh/?id=160110886
> 
> On 03/07/17 16:10, Jeremy Rowley via dev-security-policy wrote:
>> I am surprised you decided to fork the thread from here 
>> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/sNDN6q26_uM
>>  where this was already being discussed. Seems unnecessary.
> 
> Hi Jeremy.  That thread discusses a collection of intermediate certs 
> that Tavis Ormandy found (when "crawling the pkcs7 blobs in public pdf
> files") that were not at the time known to any CT logs.  Most of those 
> intermediates did not need to be disclosed to Mozilla.
> 
> https://crt.sh/?id=160110886 was not in Tavis's collection and has not AFAICT 
> been previously discussed on this list.
> 
>> I don't agree this is a policy violation, and I doubt any CA not involved in 
>> the previously mentioned thread would even register that Mozilla may be 
>> requiring disclosure of self-signed CAs.
> 
> See this post (from another recent thread) in which Ryan Sleevi explained why 
> it makes sense to require disclosure of self-signed CA certs (for which the 
> subject public key also exists in one or more trusted cross-certificates):
> https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg
> 07049.html
> 
>> The only disclosure requirement this root may fall under is the weird 
>> "transitive" trust phrase in the policy. Note, this phrase is not defined in 
>> 5280 or the Mozilla policy. Can you please link me to the definition in an 
>> RFC? If there isn't one, until Mozilla clarifies what this means, the 
>> definition of transitive trust is vague, meaning any third interpretation is 
>> as good as the one you propose.
> 
> I think the meaning of "transitive" trust is actually quite simple.
> 
> A leaf cert (L) or intermediate cert (IC1) "transitively chains" to a root 
> (R) if it is issued by an intermediate CA whose cert (IC2) chains to R.  The 
> trust for L / IC1 is "transitive" because a relying party will only be able 
> to verify that trust under certain circumstances - i.e., the RP needs to have 
> been made aware of, and received a copy of, the IC2 cert.
> 
> If IC1 is issued directly by R, trust is "direct".  The RP is able to verify 
> that trust under all circumstances, because R is built into the application / 
> shipped with the trust store that the RP is using.
> 
>> Regardless, we will log the cert in the database pending resolution of the 
>> dispute on what this means in the Mozilla policy to avoid the debate over 
>> this particular root.
>>
>> Jeremy
>>
>> -Original Message-
>> From: dev-security-policy
>> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.
>> m ozilla.org] On Behalf Of Rob Stradling via dev-security-policy
>> Sent: Monday, July 3, 2017 5:32 AM
>> To: mozilla-dev-security-pol...@lists.mozilla.org
>> 
>> Subject: DigiCert policy violation - non-disclosure of
>> https://crt.sh/?id=160110886
>>
>> https://crt.sh/mozilla-disclosures#undisclosed has listed
>> https://crt.sh/?id=160110886 for over 1 week.
>>
>> This is a violation of section 5.3.2 of the Mozilla Root Store Policy
>> v2.5 [1], which says (emphasis mine):
>> "All certificates that are capable of being used to issue new certificates, 
>> that are not technically constrained, and that directly or transitively 
>> chain to a certificate included in Mozilla’s root program MUST be audited in 
>> accordance with Mozilla’s Root Store Policy and MUST be publicly disclosed 
>> in the CCADB by the CA 

RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

[Jeremy Rowley via dev-security-policy]

I'm an idiot. The discussion wasn't meant to be a red herring.  Just a
momentary lapse in intelligence...

It really looks like this from a validation perspective, right? EE ->
Self-signed -> Issuing CA (as it has the same key) -> Digicert Root

Yeah - I agree it should have been disclosed. Apologies for the confusion. 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Nick Lamb via dev-security-policy
Sent: Tuesday, July 4, 2017 2:05 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert policy violation - non-disclosure of
https://crt.sh/?id=160110886

On Tuesday, 4 July 2017 02:37:36 UTC+1, Jeremy Rowley  wrote:
> [JR] Well yeah - but this one is self-signed and self-issued, so how 
> does it chain?

This seems to be a source of confusion for a lot of people, several people
have posted queries about it to Stack Overflow or its sister Q systems
over the years too. It chains because the Issuer is also the Subject of a
(different) trusted, certificate. To decide whether a certificate chains we
don't need to look at its Subject at all, even if the Subject is itself.

The self-signed, self-issued certificate is a loop in the PKI graph. But
just because it's a loop very much does NOT mean that it isn't connected to
the rest of the graph, nor does it mean that client software trying to make
a chain should give up and decide it's a root. In fact some systems (I
believe including in the Web PKI) already rely on being able to get pst the
loop if it's presented as an intermediate.

I'm glad that transitivity was a red herring and in fact your understanding
of what is to be disclosed lines up with everybody else's except for this
blind spot about self-signed certificates.

The Belgian government seems to have understood that this certificate was to
be treated like any other trusted certificate, it was for example listed in
their audit documents, the only oversight was that it wasn't disclosed to
Mozilla via the common database. As I said, I believe this is a process
shortcoming, and I grasp that you don't feel this is directly DigiCert's
responsibility, but of course the Belgian government is not a root programme
member, so DigiCert ends up answering for what they do here on m.d.s.policy.
___
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: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

[Rob Stradling via dev-security-policy]

Hi Jeremy.  I'm not aware of any formal definition in any RFC of the 
phrase "transitively chains".


My recollection (and Hanno's [1]) is that this terminology dates back to 
the 2010 write-up of the EFF SSL Observatory [2], in which the word 
"transvalid" was coined.



[1] 
https://blog.hboeck.de/archives/847-Incomplete-Certificate-Chains-and-Transvalid-Certificates.html


[2] 
https://events.ccc.de/congress/2010/Fahrplan/attachments/1777_is-the-SSLiverse-a-safe-place.pdf

Slide 29

On 03/07/17 21:59, Jeremy Rowley wrote:

Link please to a formal definition? As your email alleges a policy violation by 
one a cross-signed CAs, we take the investigation and response very seriously. 
I'd like to know the basis for the definition before formulating an official 
report and potentially penalizing the Sub CA for non-compliance.

-Original Message-
From: Rob Stradling [mailto:rob.stradl...@comodo.com]
Sent: Monday, July 3, 2017 2:14 PM
To: Jeremy Rowley ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert policy violation - non-disclosure of 
https://crt.sh/?id=160110886

On 03/07/17 16:10, Jeremy Rowley via dev-security-policy wrote:

I am surprised you decided to fork the thread from here 
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/sNDN6q26_uM 
where this was already being discussed. Seems unnecessary.


Hi Jeremy.  That thread discusses a collection of intermediate certs that Tavis 
Ormandy found (when "crawling the pkcs7 blobs in public pdf
files") that were not at the time known to any CT logs.  Most of those 
intermediates did not need to be disclosed to Mozilla.

https://crt.sh/?id=160110886 was not in Tavis's collection and has not AFAICT 
been previously discussed on this list.


I don't agree this is a policy violation, and I doubt any CA not involved in 
the previously mentioned thread would even register that Mozilla may be 
requiring disclosure of self-signed CAs.


See this post (from another recent thread) in which Ryan Sleevi explained why 
it makes sense to require disclosure of self-signed CA certs (for which the 
subject public key also exists in one or more trusted cross-certificates):
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg07049.html


The only disclosure requirement this root may fall under is the weird 
"transitive" trust phrase in the policy. Note, this phrase is not defined in 
5280 or the Mozilla policy. Can you please link me to the definition in an RFC? If there 
isn't one, until Mozilla clarifies what this means, the definition of transitive trust is 
vague, meaning any third interpretation is as good as the one you propose.


I think the meaning of "transitive" trust is actually quite simple.

A leaf cert (L) or intermediate cert (IC1) "transitively chains" to a root (R) if it is 
issued by an intermediate CA whose cert (IC2) chains to R.  The trust for L / IC1 is 
"transitive" because a relying party will only be able to verify that trust under certain 
circumstances - i.e., the RP needs to have been made aware of, and received a copy of, the IC2 cert.

If IC1 is issued directly by R, trust is "direct".  The RP is able to verify 
that trust under all circumstances, because R is built into the application / shipped 
with the trust store that the RP is using.


Regardless, we will log the cert in the database pending resolution of the 
dispute on what this means in the Mozilla policy to avoid the debate over this 
particular root.

Jeremy

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.m
ozilla.org] On Behalf Of Rob Stradling via dev-security-policy
Sent: Monday, July 3, 2017 5:32 AM
To: mozilla-dev-security-pol...@lists.mozilla.org

Subject: DigiCert policy violation - non-disclosure of
https://crt.sh/?id=160110886

https://crt.sh/mozilla-disclosures#undisclosed has listed
https://crt.sh/?id=160110886 for over 1 week.

This is a violation of section 5.3.2 of the Mozilla Root Store Policy
v2.5 [1], which says (emphasis mine):
"All certificates that are capable of being used to issue new certificates, that are 
not technically constrained, and that directly or transitively chain to a certificate 
included in Mozilla’s root program MUST be audited in accordance with Mozilla’s Root 
Store Policy and MUST be publicly disclosed in the CCADB by the CA that has their 
certificate included in Mozilla’s root program. The CA with a certificate included in 
Mozilla’s root program MUST disclose this information *within a week* of certificate 
creation, and before any such subordinate CA is allowed to issue certificates."

It's a self-signed root certificate, but nonetheless there exists a signature 
chain up to an included root and so disclosure is required.


[1]
https://www.mozilla.org/en-US/about/governance/policies/security-group
/certs/policy/


--
Rob Stradling
Senior