Subject: [Trans] Comments on RFC6962

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 10 Mar 2014 15:25:12 -0400

I am currently working on entering RFC6962 into my protocol compiler. This
has 'certain ideas' about regularity and conformance which is of course the
point of the exercise.

Some issues arising:

[Page 17]
      extensions:  An opaque type for future expansion.  It is likely
         that not all participants will need to understand data in this
         field.  Logs should set this to the empty string.  Clients
         should decode the base64-encoded data and include it in the
         SCT.

I have no idea why this would be needed. JSON allows any object to be
extended with arbitrary additional tags. I have no idea how this would be
used as well. There isn't a mechanism to tell the receiver what type of
data to expect.

If we did need to extend a message the way to do it would be to extend the
object with a new tag. JSON rules require the tag be ignored.

There is an open question on how to manage JSON extensibility. Some folk
are proposing going the XML route and an equivalent of the xmlns tag.
Reserved words are yucky and unnecessary though. If we want to use URIs as
a mechanism for describing an extension we can do that by using the URI as
a tag:

If the original message looks something like:

{ "a" : 1,
  "b" : 2 }

We can add a new tag for the FOO extension with unique identifier
urn:iana:someregistry:FOO as follows:

{ "a" : 1,
  "b" : 2,
 }

-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 10 Mar 2014 15:28:57 -0400

Sorry, gmail is behaving oddly today, it sent that message as I was typing.
The second odd thing it has done today.

I'll fix up that comment and put the rest in another message:

Some issues arising:

[Page 17]

{ "a" : 1,
  "b" : 2 }

{ "a" : 1,
  "b" : 2,
  "urn:iana:someregistry:FOO ": { ... new object or data item here ...}
 }

This does not require us to do anything at the moment. It is a property of
JSON we can use if needed.

---

From: Bill Frantz <[email-masked]>
Date: Mon, 10 Mar 2014 17:14:28 -0700

On 3/10/14 at 12:25 PM, [email-masked] (Phillip Hallam-Baker) wrote:

>There is an open question on how to manage JSON extensibility.

There's no problem here. JSON will not be extended. Doug 
Crockford, the inventor of JSON is adamant that there is only 
one version. Forever.

Now someone may make a new serialization format that shares many 
features with JSON, but it won't be JSON.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Concurrency is hard. 12 out  | Periwinkle
(408)356-8506      | 10 programmers get it wrong. | 16345 
Englewood Ave
www.pwpconsult.com |                - Jeff Frantz | Los Gatos, 
CA 95032

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 10 Mar 2014 20:18:11 -0400

On Mon, Mar 10, 2014 at 8:14 PM, Bill Frantz <[email-masked]> wrote:

> There's no problem here. JSON will not be extended. Doug Crockford, the
> inventor of JSON is adamant that there is only one version. Forever.
>
> Now someone may make a new serialization format that shares many features
> with JSON, but it won't be JSON.
>

You are misunderstanding me.

The 'JSON extensibility' issue is not how to extend JSON encoding, the
issue is how to handle extensibility of the TRANS protocol that is encoded
in JSON.

Adding tags in JSON is straightforward and existing applications SHOULD
simply ignore them. But we should probably make some sort of explicit
statement.

---

From: Rob Stradling <[email-masked]>
Date: Tue, 11 Mar 2014 12:28:11 +0000

On 10/03/14 19:25, Phillip Hallam-Baker wrote:
> I am currently working on entering RFC6962 into my protocol compiler.
> This has 'certain ideas' about regularity and conformance which is of
> course the point of the exercise.
>
> Some issues arising:
>
> [Page 17]
> extended with arbitrary additional tags. I have no idea how this would
> be used as well. There isn't a mechanism to tell the receiver what type
> of data to expect.

Phill,

Page 17 says:
"Clients should decode the base64-encoded data and include it in the SCT."

JSON is used for the Client<->Server request and response.  The SCT 
format uses "TLS encoding", _not_ JSON.  Pages 12 and 13 define the SCT 
v1 format.

"extensions" from the JSON response needs to be encoded by the Client as 
the "CtExtensions extensions;" field in the "struct {...} 
SignedCertificateTimestamp;"

As for why "extensions" would be needed...

Here's where the idea of having "extensions" first came up:
https://groups.google.com/forum/#!topic/certificate-transparency/Dbs9y1SVPgU/overview

In the "Question about PRIVATE option" thread today, I noted that we 
might need an SCT extension to explicitly carry the "entry_type".

It's all about future-proofing.  If we want to add features to SCTs in a 
backwards-compatible manner, we'll define "extensions".  If we want to 
add features to SCTs in a backwards-incompatible manner, we'll change 
the SCT version number.

> If we did need to extend a message the way to do it would be to extend
> the object with a new tag. JSON rules require the tag be ignored.
>
> Reserved words are yucky and unnecessary though. If we want to use URIs
> as a mechanism for describing an extension we can do that by using the
> URI as a tag:
>

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

---

From: Bill Frantz <[email-masked]>
Date: Tue, 11 Mar 2014 12:48:12 -0700

> issue is how to handle extensibility of the TRANS protocol that is encoded

Oops - Sorry

> simply ignore them. But we should probably make some sort of explicit

Indeed, being explicit is always best when writing standards.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        |Security, like correctness, is| Periwinkle
(408)356-8506      |not an add-on feature. - Attr-| 16345 Englewood Ave
www.pwpconsult.com |ibuted to Andrew Tanenbaum    | Los Gatos, CA 95032