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

[Rob Stradling <[e-mail]>]

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:
> 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
>
>
> _______________________________________________
> Trans mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trans
>

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