Re: [Trans] Comments on RFC6962

Rob Stradling <> Tue, 11 March 2014 12:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 017211A066C for <>; Tue, 11 Mar 2014 05:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KcbFtbaR0Eo8 for <>; Tue, 11 Mar 2014 05:28:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6B93E1A0421 for <>; Tue, 11 Mar 2014 05:28:17 -0700 (PDT)
Received: (qmail 14506 invoked by uid 1000); 11 Mar 2014 12:28:11 -0000
Received: from (HELO []) ( (smtp-auth username rob, mechanism plain) by (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 11 Mar 2014 12:28:11 +0000
Message-ID: <>
Date: Tue, 11 Mar 2014 12:28:11 +0000
From: Rob Stradling <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Phillip Hallam-Baker <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [Trans] Comments on RFC6962
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Mar 2014 12:28:22 -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]
>        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.


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

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

Here's where the idea of having "extensions" first came up:!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