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
<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 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.mozilla.org/listinfo/dev-security-policy
