Subject: [Trans] Contributing to the issue tracker

From: Melinda Shore <[email-masked]>
Date: Wed, 23 Jul 2014 09:19:54 -0400

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

---

From: Rick Andrews <[email-masked]>
Date: Wed, 23 Jul 2014 13:27:43 -0700

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

-Rick

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Wednesday, July 23, 2014 6:20 AM
To: [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/trans

---

From: Melinda Shore <[email-masked]>
Date: Wed, 23 Jul 2014 16:52:52 -0400

On 7/23/14, 4:27 PM, Rick Andrews 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?

One of the things we'll be talking about on Friday and then
bringing back to the mailing list is working method, and
whether or not the issue tracker is going to be comprehensive.
Clearly there are some issues that have been raised and that
need to be addressed that haven't yet made it into the tracker
(frankly Steve's big blast of issues was almost certainly
challenging to break down).  Regardless of whether or not
there are tickets created for every issue raised, we'll be
making sure they're addressed on the mailing list and brought
to closure.

What makes it into Google's code is out of scope for the working
group.

Melinda

---

From: Eran Messeri <[email-masked]>
Date: Wed, 23 Jul 2014 21:57:07 +0100

On Wed, Jul 23, 2014 at 9:27 PM, Rick Andrews <[email-masked]>
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?
>
Yes - there were quite a few comments. Some of them were
<https://github.com/google/certificate-transparency-rfcs/pull/1> addressed
<https://github.com/google/certificate-transparency-rfcs/commit/2feaf95bb17e1d9d5e8336e62f6d2552c4070f58>,
some of them will be. We're working on putting together an organized
response. Melinda kindly reminded everyone that the issue tracker is open -
making the comments as specific issues in the tracker is a guaranteed way
to get a faster response from me, anyway (I'm terrible at reading long,
verbose emails).

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

I agree there should be more explanations about deployment - we should do
better on documenting the different aspects of CT. I think Chromium's CT/EV
plan
<http://dev.chromium.org/Home/chromium-security/certificate-transparency> and
log inclusion policy are some of these documents, though.

I simply think that deployment issues should not be in this RFC. My view is
that this RFC would be used by implementors of logs, monitors or clients,
so it should not discuss matters which could be considered operational.

> 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.
>
(1) I'd love to see a concrete proposal for simplifying Precertificates. My
understanding is that we're after a standardized data structure which
includes a signature and would be easy for CAs to use.
(2) I don't believe we'll be changing the Precertificates format before
January - Ben should provide more details on that.

> (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
>

---

From: Ben Laurie <[email-masked]>
Date: Thu, 24 Jul 2014 14:30:44 +0100

On 23 July 2014 21:27, Rick Andrews <[email-masked]> wrote:
> 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.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 24 Jul 2014 10:52:04 -0400

Ben,

> ...
> But we're marching towards a flag day now.
Google has chosen to adopt a flag day approach for its 6962 deployment.
This WG gets to make it's own decision on this topic. But, in any case, 
6962-bis
needs to state explicitly whether it assumes a flag day or incremental 
deployment.
> He also suggested trying to
Not an issue for this WG, because you're discussing a Google-centric 
activity, not
the standard that this WG is developing, right?
> What we're marching towards is a deadline, a completely different
What can be deployed before this WG is done is an implementation of an 
experimental
protocol, not the standards track protocol being developed. How is the 
deployment
of that experimental protocol relevant to the discussion of what is in the
standards track doc?
> the obvious reason that there's not going to be enough time.
again, I assume our ongoing discuss is about 6962-bis.
> extension as a retrofit to 6962, since we've heard from CAs that it is
Wouldn't this require CAs to reissue CA certs to the private domains?
have CAs said that they view it as feasible to perform such re-issuance
in the time frame you noted? Never mind, that another 6962 topic, not a
6962-bis topic.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Thu, 24 Jul 2014 16:04:46 +0100

On 24 July 2014 15:52, Stephen Kent <[email-masked]> wrote:
> Ben,
>
>> ...
>>
>>
>>> 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.
>>

Well, it looks like it might be a good idea to do it for -bis.

> of that experimental protocol relevant to the discussion of what is in the

What I mean is that the protocol as specified so far (in 6962-bis)
does not require a flag day. Is your point that this needs to be
explicitly stated?

> again, I assume our ongoing discuss is about 6962-bis.

Indeed, I am just clarifying what we're implementing.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 24 Jul 2014 12:39:14 -0400

Ben,

> Well, it looks like it might be a good idea to do it for -bis.
What is the "it" to which you refer? a different pre-cert model?
> does not require a flag day. Is your point that this needs to be
The protocol, as currently specified in 6962-bis, does not seem compatible
with incremental deployment, yet it also does not state that a flag day is
required. For example, if a TLS client MUST reject a cert with an 
accompanying
SCT, how does this work in an incremental deployment scenario?
> Indeed, I am just clarifying what we're implementing.
A discussion of what Google is implementing, based on an Experimental 
RFC, ought
not be construed as relevant to what a standards track RFC will mandate. 
Or, are
you saying that Google feels that browser vendors, CAs and log operators 
will be
reluctant to deploy a standard that deviates in significant ways from 
the Experimental
protocol?

Steve

---

From: Rick Andrews <[email-masked]>
Date: Thu, 24 Jul 2014 11:02:33 -0700

I'm relatively new to the ways of the IETF, so I apologize if this discussion is out of scope for this list.

Google began the CT process by producing an Experimental RFC within the IETF. Google then asked CAs to build what's specified in that Experimental RFC. Some issues were uncovered and discussed; issues and resolutions have been tracked in the IETF issues tracker for 6962-bis. I think that's how I got confused into thinking that we should be discussing deployment concerns in the Trans working group. Up until recently, I had thought that we were expected to build 6962-bis by January, not 6962.

I speak for a number of CAs when I say that many of us are confused about exactly how to build CT. We have no single reference spec to follow. Ben has said that we should follow 6962, but not 6962-bis except for Ticket #1 and the language in 6962-bis for that Ticket. But I guess we're supposed to ignore the other tickets and the rest of the -bis document.

Since what we're building for January seems to be out of scope for this working group, I think it would be extremely helpful if Google would produce a single document that we can all march to. Maybe that should be circulated through the CA/Browser Forum, although not all CAs are represented there, but there seem to be more there than in the Trans working group.

Finally, to paraphrase Steve, I would say I'm "reluctant to deploy an Experimental protocol that may deviate in significant ways from the eventual standard".

-Rick

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Thursday, July 24, 2014 9:39 AM
To: Ben Laurie
Cc: [email-masked]
Subject: Re: [Trans] Contributing to the issue tracker

Ben,

>> This WG gets to make it's own decision on this topic. But, in any 
>> case, 6962-bis needs to state explicitly whether it assumes a flag 
>> day or incremental deployment.
>>
>>> captured in Ticket #26, but that's unlikely to be done in time to 
>>> help any CAs before January.
>> activity, not the standard that this WG is developing, right?
>>> 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 can be deployed before this WG is done is an implementation of 
>> an experimental protocol, not the standards track protocol being 
>> developed. How is the deployment of that experimental protocol 
>> relevant to the discussion of what is in the standards track doc?
The protocol, as currently specified in 6962-bis, does not seem compatible with incremental deployment, yet it also does not state that a flag day is required. For example, if a TLS client MUST reject a cert with an accompanying SCT, how does this work in an incremental deployment scenario?
>>> 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.
A discussion of what Google is implementing, based on an Experimental RFC, ought not be construed as relevant to what a standards track RFC will mandate. 
Or, are
you saying that Google feels that browser vendors, CAs and log operators will be reluctant to deploy a standard that deviates in significant ways from the Experimental protocol?

Steve

---

From: Melinda Shore <[email-masked]>
Date: Thu, 24 Jul 2014 14:08:12 -0400

On 7/24/14, 2:02 PM, Rick Andrews wrote:
> Maybe that
> should be circulated through the CA/Browser Forum, although not all
> CAs are represented there, but there seem to be more there than in
> the Trans working group.
> Finally, to paraphrase Steve, I would say I'm "reluctant to deploy an
> Experimental protocol that may deviate in significant ways from the
> eventual standard".

If there's interest, we can use the working group wiki to
maintain deployment information (as well as deployment
reports).

Melinda

---

From: Ben Laurie <[email-masked]>
Date: Thu, 24 Jul 2014 20:00:46 +0100

> What is the "it" to which you refer? a different pre-cert model?

Yes.

> SCT, how does this work in an incremental deployment scenario?

I think you mean "without an accompanying SCT". And yes, that's a fair
point, there would need to be a period when that requirement was
relaxed.

> A discussion of what Google is implementing, based on an Experimental RFC,
> ought
> not be construed as relevant to what a standards track RFC will mandate. Or,
> are
> reluctant to deploy a standard that deviates in significant ways from the
> Experimental
> protocol?

No, I mentioned it only because it appears to be a point of confusion.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 24 Jul 2014 15:48:54 -0400

Ben,

>> What is the "it" to which you refer? a different pre-cert model?
Thanks for the clarification.
>>> ..
yes, I meant "without." Glad to see we agree that the doc will need to 
explain
how to deal with incremental deployment, and thus the "MUST have an SCT" 
is too
simple to deal with this deployment scenario.
>>> ..
Thanks for the clarification. So long as the folks (other than Google) 
deploying 6962
don't object to the fact that 6962-bis may have a number of differences, OK.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Thu, 24 Jul 2014 20:49:39 +0100

> I speak for a number of CAs when I say that many of us are confused about exactly how to build CT. We have no single reference spec to follow. Ben has said that we should follow 6962, but not 6962-…

This is a fair point, but you are right this is not the venue for it.

> Since what we're building for January seems to be out of scope for this working group, I think it would be extremely helpful if Google would produce a single document that we can all march to. Mayb…

I agree that it would be helpful to produce that document. It is not
for this WG, so clearly this is not the right venue. Like you, I am
not sure where we can actually reach all CAs - and, indeed, it is not
only of interest to CAs - but we'll obviously try to circulate it as
widely as possible.

> Finally, to paraphrase Steve, I would say I'm "reluctant to deploy an Experimental protocol that may deviate in significant ways from the eventual standard".

We (Google) are not going to derail our current plans to wait for a
standard that may or may not do what we need with an uncertain
delivery date.

---

From: Matt Palmer <[email-masked]>
Date: Fri, 25 Jul 2014 07:20:12 +1000

On Thu, Jul 24, 2014 at 03:48:54PM -0400, Stephen Kent wrote:
> >>RFC, ought not be construed as relevant to what a standards track RFC
> >>will mandate.  Or, are you saying that Google feels that browser
> >>vendors, CAs and log operators will be reluctant to deploy a standard
> >>that deviates in significant ways from the Experimental protocol?
> >
> deploying 6962 don't object to the fact that 6962-bis may have a number of
> differences, OK.

As someone who is planning on providing a public 6962-compatible log server
and monitor/auditor well in advance of the Google CT deadline, I do not
object to the fact that 6962-bis may have a number of differences.

- Matt