Opened 5 years ago

Closed 5 years ago

#179 closed defect (duplicate)

Indicate certificate / precertificate in Entry and SCT

Reported by: rlb@… Owned by: eranm@…
Priority: major Milestone: review
Component: rfc6962-bis Version:
Severity: - Keywords:
Cc:

Description

Right now, a client in possession of a certificate and an SCT does not have
enough information to validate the SCT over the certificate, because he does not
know whether the entry is a precertificate entry. You could require that this
be inferred from the SCT being in the certificate, but it seems better to add an
explicit indication of whether the submission is a precert in the SCT.

This would also remove the need to have separate VersionedTransType values for
certificate vs. precert structs. That's also an improvement, since it avoids
mixing semantics with the enacapsulation.

Change History (6)

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

  • Component changed from client-behavior to to-be-decided

comment:2 Changed 5 years ago by eranm@…

  • Component changed from to-be-decided to rfc6962-bis

From in-person clarification:
The idea here that rather have the indication about the type of SCT in the TransItem? (precert_sct_v2 / x509_sct_v2) that indication would live in the SCT itself, SignedCertificateTimestampDataV2, and so it would also have to be in TimestampedCertificateEntryDataV2.

That would reduce the number items in the TransType? enum. Also, in the implementation, it'd be easier to pass around the concrete SignedCertificateTimestampDataV2 / TimestampedCertificateEntryDataV2 since it will contain all the information necessary, without haing to pass around a TransItem? and assert that it's of the right type everywhere.

comment:3 follow-up: Changed 5 years ago by eranm@…

Corollary:

  • SCTs *are* defined as TransItems? of type x509_sct_v2 or precert_sct_v2.
  • This is a non-trivial change to the data structures, which may require a stronger justification than the one we currently have (at least two structures I've identified, and signature scheme may change).
  • Other fields may have to move into the SignedCertificateTimestampDataV2 to contain all the necessary information to be passed around without the TransItem? (see previous point).
  • This would undo the work to unify several "type" indicators in 6962 into a single one in -bis.

Overall I agree with the sentiment that some data structures in 6962-bis need to be renamed to clarify what role they play.

comment:4 in reply to: ↑ 3 Changed 5 years ago by rob.stradling@…

Replying to eranm@…:
<snip>

Overall I agree with the sentiment that some data structures in 6962-bis need to be renamed to clarify what role they play.

I agree. How about opening a new ticket to discuss structure renaming?

comment:5 Changed 5 years ago by eranm@…

  • Milestone set to review
  • Owner changed from draft-ietf-trans-rfc6962-bis@… to eranm@…
  • Status changed from new to assigned

Suggest closing this ticket as a duplicate of https://trac.ietf.org/trac/trans/ticket/190.

comment:6 Changed 5 years ago by melinda.shore@…

  • Resolution set to duplicate
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.