Opened 8 years ago

Closed 7 years ago

#14 closed defect (needs-review)

Clarify ASN.1 encoding

Reported by: rob.stradling@… Owned by: rob.stradling@…
Priority: major Milestone:
Component: rfc6962-bis Version:
Severity: - Keywords:


RFC6962 talks of...

"...encoding the SignedCertificateTimestampList?

structure as an ASN.1 OCTET STRING and inserting the resulting data
in the TBSCertificate as an X.509v3 certificate extension"

Some folks have found this description to be unclear.

In order to arrive at the correct interpretation, you have to look at the definition of an Extension in RFC5280 and take note of the comment...

"Extension ::= SEQUENCE {


-- contains the DER encoding of an ASN.1 value
-- corresponding to the extension type identified
-- by extnID


"contains the DER encoding of an ASN.1 value" means that you need an OCTET STRING inside an OCTET STRING. (Read in isolation, RFC6962 could be wrongly taken to mean that only one OCTET STRING is required).

RFC6962-bis should define, clearly and unambiguously, how to encode an SCTList extension in Precertificates and OCSP Responses.

Examples of correctly encoded SCTList extensions should be provided. (See RFC5280 Appendix C for inspiration).

Change History (2)

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

  • Owner changed from draft-ietf-trans-rfc6962-bis@… to rob.stradling@…
  • Status changed from new to assigned

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

  • Resolution set to needs-review
  • Status changed from assigned to closed

Whilst tackling this ticket, I took the opportunity to revamp the whole of section 3.4. It's quite a big diff, but much of it is just moving sentences around.

Since this is the only change between -06 and -07, you can view it here:

P.S. Does anyone know why xml2rfc has not added sections and to the table of contents?

Note: See TracTickets for help on using tickets.