Re: DRAFT September 2018 CA Communication

[Wayne Thayer via dev-security-policy]

Thanks for the suggestion Jakob. I will pass it on to the engineering team.

On Fri, Sep 7, 2018 at 8:04 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 07/09/2018 15:55, Bruce 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=a051J3rMGLL
> >> <
> https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3mogw7
> >
> >>
> >> 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.
> >
> > Thanks, Bruce.
> >
>
> The CRLite document linked from the draft is an old scientific article
> that contains some factually wrong assumptions, which will hopefully be
> fixed in Mozilla's implementation anyway.
>
> Would it be useful for Mozilla's CRLite implementation to accept lists
> of certificates from a source much shorter than the Google CT logs, for
> example a CRL-like file (signed by the CA) containing only the minimum
> number of attributes (serial number only for now) for each issued
> certificate?
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT September 2018 CA Communication

[Wayne Thayer via dev-security-policy]

Thanks for the response Bruce.

On Fri, Sep 7, 2018 at 6: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=a051J3rMGLL
> > <
> https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3mogw7
> >
> >
> > 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.
>
> >
We're of the opinion that this adds more complexity and risk that it's
worth. We're not planning to preload revoked intermediates, and in the case
you've described, it sounds like revocation is a viable option.
>

> 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.
>
> >
I've updated the response options to include both redaction and opting
specific certificates out of logging. Please let me know if there are more
choices that aren't covered.
>

> Thanks, Bruce.
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT September 2018 CA Communication

[Ryan Sleevi via dev-security-policy]

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=a051J3rMGLL
> > <
> https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3mogw7
> >
> >
> > 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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT September 2018 CA Communication

[Jakob Bohm via dev-security-policy]

On 07/09/2018 15:55, Bruce 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=a051J3rMGLL


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.

Thanks, Bruce.



The CRLite document linked from the draft is an old scientific article
that contains some factually wrong assumptions, which will hopefully be
fixed in Mozilla's implementation anyway.

Would it be useful for Mozilla's CRLite implementation to accept lists
of certificates from a source much shorter than the Google CT logs, for
example a CRL-like file (signed by the CA) containing only the minimum
number of attributes (serial number only for now) for each issued
certificate?


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT September 2018 CA Communication

[Bruce via dev-security-policy]

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=a051J3rMGLL
> 
> 
> 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.

Thanks, Bruce.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy