[cabfpub] FW: [Trans] Contributing to the issue tracker

Ryan Sleevi rsleevi at chromium.org
Thu Aug 7 17:07:12 UTC 2014


Rick,

The authoritative source as to what Chromium accepts from logs, and expects
of logs, is at
http://www.chromium.org/Home/chromium-security/certificate-transparency

This includes the Google Pilot and Aviator logs, as well as any other logs
that wish to be included in Chromium.

Changes to this policy - which currently requires RFC6962 - which does not
permit the privacy options of BIS, either via the PRIVATE extension or via
name-constrained intermediates - will be discussed on ctr
policy at chromium.org, and any changes to Chrome's policies will be discussed
there.

Ben is absolutely correct in characterizing that there is interest in that,
and exploring the technical feasibility, but I wanted to make sure to take
the opportunity on our call to prevent any additional confusion:
- There is a single policy for Chrome/Chromium, which all logs must follow.
- Discussions and changes to that policy will happen on
ct-policy at chromium.org, as the singularly authoritative list.

Unless and until the policy is changed, private names will not be
recognized by Chromium when validating SCTs, nor will Logs that use them.

Cheers!
On Aug 7, 2014 9:55 AM, "Rick Andrews" <Rick_Andrews at symantec.com> wrote:

> Ryan,
>
> Below, Ben said: "However, we are working towards supporting the private
> domain label extension as a retrofit to 6962, since we've heard from CAs
> that it is important to them." That's why I mentioned on the CABF call
> today that Google was supporting, and CAs could build, support for the
> domain name redaction.
>
> -Rick
>
> -----Original Message-----
> From: Ben Laurie [mailto:benl at google.com]
> Sent: Thursday, July 24, 2014 6:31 AM
> To: Rick Andrews
> Cc: Melinda Shore; trans at ietf.org
> Subject: Re: [Trans] Contributing to the issue tracker
>
> On 23 July 2014 21:27, Rick Andrews <Rick_Andrews at symantec.com> wrote:
> > Will the issues raised by Stephen Kent and Russ Housely will make it
> onto the issue tracker, and/or be considered for Google's initial rollout
> next January?
> >
> > At least one of the comments suggested changing the protocol to allow
> for easier algorithm agility in the future, and I don't see that on the
> tracker.
>
> We made at least one change towards that in -04 (the hash algorithm is now
> chosen from a registry).
>
> > Stephen also asked for a description of how CT would be incrementally
> deployed, and he doubted that a flag day would be viewed as credible.
> But we're marching towards a flag day now. He also suggested trying to
> simplify precertificates or come up with alternatives, and that's captured
> in Ticket #26, but that's unlikely to be done in time to help any CAs
> before January.
>
> I don't think it is correct to characterise what we're doing as a flag
> day. You can absolutely deploy CT before we switch it on in Chrome.
> What we're marching towards is a deadline, a completely different thing.
>
> On precertificates, one thing I should clarify is that Google will not be
> adopting 6962-bis before January, even if it is done by then, for the
> obvious reason that there's not going to be enough time.
>
> However, we are working towards supporting the private domain label
> extension as a retrofit to 6962, since we've heard from CAs that it is
> important to them.
>
> >
> > -Rick
> >
> > -----Original Message-----
> > From: Trans [mailto:trans-bounces at ietf.org] On Behalf Of Melinda Shore
> > Sent: Wednesday, July 23, 2014 6:20 AM
> > To: trans at ietf.org
> > Subject: [Trans] Contributing to the issue tracker
> >
> > I've been reminded to remind everybody that the issue tracker
> > (http://tools.ietf.org/wg/trans/trac/report/1) is currently open to
> additions from anybody who's got an IETF tools account.
> > Please review the open tickets, but also add tickets for issues you've
> identified that need to be resolved before 6962-bis will be ready for
> working group last call.  (It would be helpful to start a discussion on the
> mailing list before opening a ticket).
> >
> > In the event that the tracker is abused we'll restrict access, but for
> the time being we're keeping it open.  Note that Eran Messeri is the de
> facto issue tracker editor and can help with issue tracker questions, etc.
> >
> > Thanks,
> >
> > Melinda
> >
> > _______________________________________________
> > Trans mailing list
> > Trans at ietf.org
> > https://www.ietf.org/mailman/listinfo/trans
> >
> > _______________________________________________
> > Trans mailing list
> > Trans at ietf.org
> > https://www.ietf.org/mailman/listinfo/trans
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140807/ff24266c/attachment-0003.html>


More information about the Public mailing list