Thanks everyone for your feedback. The September 2018 CA Communication has just been sent to all primary points-of-contact for CAs in our program. CAs have been asked to respond by 30-September. I will also be adding a post to https://blog.mozilla.org/security/ announcing the survey,
- Wayne On Thu, Sep 13, 2018 at 2:24 PM Wayne Thayer <wtha...@mozilla.com> wrote: > 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
