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
[email protected]
https://www.ietf.org/mailman/listinfo/trans


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

_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans

Reply via email to