Re: [Trans] Comments on RFC6962

[Rob Stradling <[e-mail]>]

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

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

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