On Fri, Sep 7, 2018 at 9:55 AM Bruce via dev-security-policy < [email protected]> 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? _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
