Re: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886
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
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
RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886
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&A 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
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/pol
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&A 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
RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886
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
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
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 ; 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
"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
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
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/ > > > > ___ > 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 COMO
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@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 dev-security-policy@lists.mozilla.org https://lists.m
RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886
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