Opened 7 years ago

Closed 7 years ago

#34 closed defect (wontfix)

use of RFC 5246 syntax to define the SCT

Reported by: kent@… Owned by: draft-ietf-trans-rfc6962-bis@…
Priority: major Milestone:
Component: rfc6962-bis Version:
Severity: - Keywords:


Section 3.3 defines the syntax of the SCT using the syntax developed in RFC 5246. That RFC states that the syntax in question is to be within TLS, exclusively. Since SCTs may be included in X.509 certs and
in OCSP responses, ASN.1 is a more appropriate syntax. Please justify the use of the 5246 syntax given these other means of conveying SCTs, or revise the syntax to use ASN.1, or ...

Change History (2)

comment:1 Changed 7 years ago by rob.stradling@…

Stephen, I presume you're referring to the following snippet from

"The purpose of this presentation language is to document TLS only; it has

no general application beyond that particular goal."

Firstly, I don't see any "MUST NOT" requirement there.

Secondly, I would say that RFC6962(-bis) documents a _specific_, not general, "application beyond that particular goal".

That said, I think it's a good idea to add text to explain why this syntax was chosen.

comment:2 Changed 7 years ago by benl@…

  • Resolution set to wontfix
  • Status changed from new to closed

TLS extensions are defined using RFC 5246 format, so clearly it is correct to use that format for the TLS extension.

There is no compelling reason to have multiple SCT formats, and good reasons to not do so (complexity, extra signing overhead).

So, closing this ticket without changing the format.

Note: See TracTickets for help on using tickets.