On Fri, Sep 7, 2018 at 8:22 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On Fri, Sep 7, 2018 at 9:55 AM Bruce via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On Thursday, September 6, 2018 at 7:44:15 PM UTC-4, Wayne Thayer wrote: > > > All, > > > > > > I've drafted a new email and survey that I hope to send to all CAs in > the > > > Mozilla program next week. it focuses on compliance with the new > (2.6.1) > > > version of our Root Store Policy. I would appreciate your feedback on > the > > > draft: > > > > > > > > > https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J00003rMGLL > > > < > > > https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J00003mogw7 > > > > > > > > > Thanks, > > > > > > Wayne > > > > With regard to the actions. > > > > ACTION 6 - Can we select CA certificates which we do not want pre-loaded? > > In some cases the CA certificate is no longer used and does not need > > pre-loading. > > > > ACTION 7 - Although we support the Chrome CT requirement, we do have a > > process to allow customers to choose not to CT log their certain SSL > > certificates. We do not redact names, but I suppose we allow a customer > to > > redact certificates. As such, I don't think the responses listed in > action > > 7 covers this model. > > > > Correct. Chrome does not require 100% disclosure of certificates - however, > it does not trust undisclosed certificates. However, as Certificate > Transparency (RFC 6962) also supports non-embedding methods - such as TLS > or OCSP - it should also not be presumed that disclosure occurs at the time > of issuance. In particular, a site operator may choose not to have the CA > embed SCTs through the disclosure of precertificates, and instead disclose > them at a time prior to making those certificates operational. As a > concrete example, Google does this for some of its certificates. > > If Mozilla is pursuing a 100% disclosure rule, while permitting > non-preloaded intermediates, then it seems this suggests that Mozilla's > desired configuration is that customers that opt-out of disclosure are done > so via a dedicated intermediate. > > That is, one can imagine you, today, have > Root > Intermediate > (Disclosed Leaf) (Disclosed Leaf) (Non-Disclosed Leaf) > > In a model "tomorrow", you would have > Root > Standard Intermediate > (Disclosed Leaf) (Disclosed Leaf) > > Private Intermediate > (Non-Disclosed Leaf) > > That is, the choice of a customer to not affirmatively disclose would seem > to necessitate dedicated hierarchy in order to meet Mozilla's objectives. > Wayne, is that the intent? Is there a phase-in time for CAs to establish > such a hierarchy? > > The intent of this survey question is only to gain a better understanding of the CT logging behavior of CAs to inform our decisions about how best to handle unlogged (and possibly redacted) certificates in our CRLite implementation. There is no plan at this time to require the kind of hierarchy described above. Please let me know if anyone has further suggestions for action 7 or any other parts of the survey. I would like to get it sent out in the next few days. You can view the current version of the survey at: https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J00003rMGLL - Wayne _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
