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 <jeremy.row...@digicert.com>; 
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 <jeremy.row...@digicert.com>; 
> 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
>> <dev-security-policy@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.

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 <jeremy.row...@digicert.com>; 
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
<dev-security-policy@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://w

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

[Jeremy Rowley via dev-security-policy]

Thanks Nick.  I'm missing something on this, so I appreciate the help so
far. I replied to each section.

Perhaps you have confused transitivity with commutativity or one of the
other simple properties. Transitivity is the property whereby if F(A,B) and
F(B,C) then F(A,C), for example the "greater than" binary relation is
transitive.
[JR] No confusion on what the arithmetic property, but I am having trouble
seeing how the transitive
trust applies to a self-signed and self-issued root with a publicly trusted
root.  Can you explain this more? 

The previously undisclosed certificate chains to a certificate which chains
to another certificate and so on until you reach one that is included in the
programme.  The Mozilla policy isn't trying to do anything very fancy here,
it's just spelling out how chains actually work, which is why it was a
concern that you seem so surprised this policy applies.
[JR] Well yeah - but this one is self-signed and self-issued, so how does it
chain? 

It seems _especially_ strange to object for this certificate that you had
never imagined it was necessary to disclose it, while perhaps half a dozen
similar certificates in the same family were previously disclosed. I would
suggest that rather than demonstrating DigiCert had no idea it was supposed
to disclose them, it instead indicates that DigiCert's processes for
actually ensuring this gets done are inadequate and so some random
proportion of sub-CAs may go undisclosed entirely by accident. That's not
good news.

[JR] No. We have a process for disclosing. We didn't issue the cert...
directly. This was issued by the Belgium government, who is obligated to
follow the policy themselves for all cross-signed certs.  However, this
isn't a cross-signed cert since it's self-signed.  We've never encountered
transitive trust as we don't reuse keys in our certs.  This is a unique
situation for us as it's a program that's long been deprecated that we
haven't been able to force migration from. 


___
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

[Nick Lamb via dev-security-policy]

On Monday, 3 July 2017 23:05:53 UTC+1, Jeremy Rowley  wrote:
> And it's hardly fair to deride my lack of understanding on what transitive
> trust entails in the digital certificate space considering it's outside of
> the usual trust paths, not defined in the standard RFCs, and not the same as
> the mathematical expression.

Perhaps you have confused transitivity with commutativity or one of the other 
simple properties. Transitivity is the property whereby if F(A,B) and F(B,C) 
then F(A,C), for example the "greater than" binary relation is transitive.

The previously undisclosed certificate chains to a certificate which chains to 
another certificate and so on until you reach one that is included in the 
programme.  The Mozilla policy isn't trying to do anything very fancy here, 
it's just spelling out how chains actually work, which is why it was a concern 
that you seem so surprised this policy applies.

It seems _especially_ strange to object for this certificate that you had never 
imagined it was necessary to disclose it, while perhaps half a dozen similar 
certificates in the same family were previously disclosed. I would suggest that 
rather than demonstrating DigiCert had no idea it was supposed to disclose 
them, it instead indicates that DigiCert's processes for actually ensuring this 
gets done are inadequate and so some random proportion of sub-CAs may go 
undisclosed entirely by accident. That's not good news.
___
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

[Ben Wilson via dev-security-policy]

We've now uploaded the self-signed root into the CCADB as a subordinate CA
to the same self-signed root, if that makes sense.


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Jeremy Rowley via dev-security-policy
Sent: Monday, July 3, 2017 4:05 PM
To: Nick Lamb <tialara...@gmail.com>;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: DigiCert policy violation - non-disclosure of
https://crt.sh/?id=160110886

"Previously accepted without comment" is hardly accurate. There's lots of
comments on the Mozilla policy (including Ben's comment on this very term).
And it's hardly fair to deride my lack of understanding on what transitive
trust entails in the digital certificate space considering it's outside of
the usual trust paths, not defined in the standard RFCs, and not the same as
the mathematical expression.  Instead, you're substituting one signed object
with another.  I'd figure two-way cross-signed objects would be more akin to
transitive trust than this scenario. After all, they are substitute trust
anchors instead of here where one isn't intended for trust in Mozilla.  It'd
be more helpful to provide additional educational resources rather than
snide comments.  I'd rather understand how it works than argue about what it
means. 

Yes - we pass all policy without comment on to the Sub CA.  

-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: Monday, July 3, 2017 3:22 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert policy violation - non-disclosure of
https://crt.sh/?id=160110886

On Monday, 3 July 2017 22:00:00 UTC+1, 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.

You're asking for a "formal definition" of the word transitively. A word
which was in a policy you have previously accepted without comment, but NOW
you assert you aren't sure what it means. Transitivity is a normal concept
of mathematics and logic, its meaning here seems pretty transparent to me,
it's something we introduce (albeit not with trying to process cyclic
graphs) to secondary school children as part of their normal background in
arithmetic.

Was this policy, which you apparently didn't understand, passed without
comment to the affected Sub CA? Or did you figure that despite not
understanding what it meant you'd be able to somehow implement it?
___
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

[Jeremy Rowley via dev-security-policy]

"Previously accepted without comment" is hardly accurate. There's lots of
comments on the Mozilla policy (including Ben's comment on this very term).
And it's hardly fair to deride my lack of understanding on what transitive
trust entails in the digital certificate space considering it's outside of
the usual trust paths, not defined in the standard RFCs, and not the same as
the mathematical expression.  Instead, you're substituting one signed object
with another.  I'd figure two-way cross-signed objects would be more akin to
transitive trust than this scenario. After all, they are substitute trust
anchors instead of here where one isn't intended for trust in Mozilla.  It'd
be more helpful to provide additional educational resources rather than
snide comments.  I'd rather understand how it works than argue about what it
means. 

Yes - we pass all policy without comment on to the Sub CA.  

-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: Monday, July 3, 2017 3:22 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert policy violation - non-disclosure of
https://crt.sh/?id=160110886

On Monday, 3 July 2017 22:00:00 UTC+1, 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.

You're asking for a "formal definition" of the word transitively. A word
which was in a policy you have previously accepted without comment, but NOW
you assert you aren't sure what it means. Transitivity is a normal concept
of mathematics and logic, its meaning here seems pretty transparent to me,
it's something we introduce (albeit not with trying to process cyclic
graphs) to secondary school children as part of their normal background in
arithmetic.

Was this policy, which you apparently didn't understand, passed without
comment to the affected Sub CA? Or did you figure that despite not
understanding what it meant you'd be able to somehow implement it?
___
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

[Nick Lamb via dev-security-policy]

On Monday, 3 July 2017 22:00:00 UTC+1, 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.

You're asking for a "formal definition" of the word transitively. A word which 
was in a policy you have previously accepted without comment, but NOW you 
assert you aren't sure what it means. Transitivity is a normal concept of 
mathematics and logic, its meaning here seems pretty transparent to me, it's 
something we introduce (albeit not with trying to process cyclic graphs) to 
secondary school children as part of their normal background in arithmetic.

Was this policy, which you apparently didn't understand, passed without comment 
to the affected Sub CA? Or did you figure that despite not understanding what 
it meant you'd be able to somehow implement it?
___
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]

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

--
Rob St

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

[Rob Stradling via dev-security-policy]

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@lists.mozilla.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/



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



--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

___
dev-security-policy mailing list

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

[Jeremy Rowley via dev-security-policy]

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. 

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

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@lists.mozilla.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 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


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