Subject: Re: [Trans] #70 (rfc6962-bis): STH spec needs to define top-level extension syntax

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Jul 2015 10:35:41 -0400

As promised, here is some proposed text for the required additional 
syntax for SCT extensions.

Add to Section 3.3:

          uint16 CtExtensionId;

          opaque CtExtensionValue<0..2^16-1>;

          struct {
              CtExtensionId id;
              CtExtensionValue value;
          } CtExtension;

          CtExtension CtExtensions<0..2^16-1>;

    The "id" field identifies a single extension from the IANA registry 
in Section 7.3. The interpretation of the "value" field is determined 
solely by the value of the id field, and each document that registers a 
new extension ID must describe how to interpret the corresponding 
extension value.

    The "CtExtensions" type is a vector of 0 or more extensions.
This vector MUST NOT include more than one extension with the same ID. 
All of the extensions in the vector MUST appear in order of increasing IDs.

Change the last paragraph of Section 3.3 to:

    "extensions" are future extensions to SignedCertificateTimestamp v2. 
Currently, no extensions are specified. If an implementation sees an 
extension that it does not understand, it SHOULD ignore that extension. 
Furthermore, an implementation MAY choose to ignore any extension(s) 
that it does understand.

Add a new Section, "7.3.  CT Extension IDs":

    IANA is asked to establish a registry of CT extension IDs, initially
    consisting of:

          +-------+-----------+
          | ID    | Extension |
          +-------+-----------+
          | 65535 | reserved  |
          +-------+-----------+

    TBD: policy for adding to the registry

---

From: Rob Stradling <[email-masked]>
Date: Tue, 14 Jul 2015 22:31:51 +0100

Steve, though I disagree with the thing you want to use an extension 
for, I completely agree that we need to define the top-level extension 
syntax.  Your proposed text mostly looks good to me.  Just a few 
nits/questions...

'The "CtExtensions" type is a vector of 0 or more extensions'
   - Isn't that clear from the "CtExtension CtExtensions<0..2^16-1>;" 
definition?  Why restate it?

'All of the extensions in the vector MUST appear in order of increasing 
IDs.'
   - Why?  And what would a CT client do if it encountered a violation 
of this proposed MUST?

'If an implementation sees an extension that it does not understand, it 
SHOULD ignore that extension.'
   - Wouldn't it be better to include a "critical" flag that has the 
same semantics as the "critical" flag for X.509v3 extensions?

Are you planning to submit a pull request on GitHub for your proposed 
text?  Or shall I?

On 14/07/15 15:35, Stephen Kent wrote:
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Jul 2015 11:31:04 -0400

Rob,

Thanks for the feedback and questions.

> definition?  Why restate it?
I find the syntax here a bit confusing, which I why I included that text.
>
> 'All of the extensions in the vector MUST appear in order of 
> increasing IDs.'
I was looking for two things: a simple canonicalization to be applied at 
this level, and a way
to make it easier for an RP to compare a set of extensions against a 
list it might have locally.
> 'If an implementation sees an extension that it does not understand, 
> it SHOULD ignore that extension.'
I thought about adding a critical flag, ala X,509v3, but was worried 
that it might
seem overkill. I defer to the judgement of others here.
> Are you planning to submit a pull request on GitHub for your proposed 

I'm a believe that details of IETF WG discussions belong on IETF WG 
lists, so I have
no plans to push this to GitHub, but thanks for the offer.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Thu, 16 Jul 2015 22:31:41 +0100

> Thanks for the feedback and questions.

Thanks Steve.  Further comments inline.

> I find the syntax here a bit confusing, which I why I included that text.

OK.

> this level, and a way to make it easier for an RP to compare a set of
> extensions against a list it might have locally.

OK, as long as the client-behavior doc considers what a client will do 
if the extensions are in the wrong order.

> that it might seem overkill. I defer to the judgement of others here.

OK, on reflection, I think you're right.  If there's ever a need to 
define an SCT "extension" that clients MUST understand and process, we 
can accommodate that by bumping the SCT version and changing the SCT 
structure.  So there's no need for a per-extension critical flag.

> lists, so I have no plans to push this to GitHub

I don't follow.  We are having this discussion on an IETF WG list.

> but thanks for the  offer.

You're welcome.  However, I'm not clear if you've declined or accepted 
my offer.  Could you clarify?

---

From: Stephen Kent <[email-masked]>
Date: Fri, 17 Jul 2015 09:35:38 -0400

Rob,

> ...
good point.
> structure.  So there's no need for a per-extension critical flag.
agreed.
> I don't follow.  We are having this discussion on an IETF WG list.
You wanted to know if I planned to post the proposed syntax to GitHub.
My answer (perhaps not clearly stated) was no.
> my offer.  Could you clarify?
If you believe that there are folks who don't track this list and who 
rely on GitHub to
track CT stuff, then feel free to post there.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Sat, 18 Jul 2015 00:40:30 +0100

On 17/07/15 14:35, Stephen Kent wrote:
<snip>
> rely on GitHub to track CT stuff, then feel free to post there.

GitHub is what the 6962-bis authors are using to collaboratively edit 
the document.  A GitHub pull request must be created for any proposed 
text before that proposed text is reviewed and incorporated into the 
document.  We welcome pull requests from anyone (it's the most 
convenient way for us to accept proposed text), but posting proposed 
text to this WG mailing list is also fine.

I've created a pull request and kicked off the review here:
https://github.com/google/certificate-transparency-rfcs/pull/70

(BTW, the fact that the TRAC ticket and the pull request are both 
numbered 70 is purely coincidental).

---

From: Melinda Shore <[email-masked]>
Date: Fri, 17 Jul 2015 15:55:19 -0800

On 7/17/15 3:40 PM, Rob Stradling wrote:
> document. 

I think it's not a great idea to restrict document input from people
who aren't familiar with a particular tool.  Any commit will show up
in the document history so I don't think that text really does
need to come in the form of a pull request.  That said, if people
have text and aren't comfortable with git (or with xml2rfc), I can
submit the pull request for them.

Melinda

---

From: Rob Stradling <[email-masked]>
Date: Mon, 20 Jul 2015 16:07:53 +0100

> https://github.com/google/certificate-transparency-rfcs/pull/70

Steve, I made some changes to your proposed text to align the syntax 
with the TLS Hello Extensions syntax from RFC5246, and I've merged the 
text into rfc6962-bis.xml in the GitHub repo.

If you want to review the changes, please browse to the GitHub URLs 
quoted in the TRAC ticket.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 22 Jul 2015 09:25:51 +0000

> submit the pull request for them.

To be clear, Rob said in the following text you redacted that posting text
here (or in trac, in fact) would be fine.

The point is that we (the editors) are using github to coordinate, so if
people want they can directly propose changes to the text in the form of a
pull request. Entirely optional.