Opened 8 years ago

Closed 7 years ago

#4 closed defect (fixed)

Should we sign TBS for Certificates?

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


Reported by benl:
"As suggested by Trevor Perrin, should we, for consistency, always sign the TBS rather than the whole cert for certificates and the TBS for precertificates?"

Change History (6)

comment:1 follow-up: Changed 7 years ago by eranm@…

IIRC Rob Stradling suggested this is a good idea to avoid the issue of logs being susceptible to spamming by varying the signature algorithm specifier in the signature part of the X.509 certificate (so it does not match the one in the TBSCertificate part).

comment:2 in reply to: ↑ 1 Changed 7 years ago by rob.stradling@…

Yes. There are an unlimited number of ways that a spammer could incorrectly re-encode the signature algorithm parameters in the signature part of a single certificate, so I think we definitely need to address this.
We could address it by saying that logs MUST check that the signature parameters are encoded identically in a cert's signature part and TBSCertificate part, but I think this ticket's suggestion (to always sign TBS) is the more elegant solution.

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

There seems to be a consensus among the authors that this is a good idea. As Emilia Kasper put it:
"I can see only strong benefits in this: 1) unifying the handling of precertificates and certificates and 2) avoiding all sorts of library slack and brokenness in handling the unsigned component of the certificates."
That implies that the signature in the SCT will not cover the signature in the X.509 certificate itself, so it would validate for different certificates that are the same TBSCertificate, signed with the same key multiple times (potentially yielding different signatures).
To allow auditing of the original submission, I propose adding a field to the PrecertChainEntryV2/X509ChainEntry struct (which will be unified) to include the original submission.

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

Eran, don't the existing PrecertChainEntryV2/X509ChainEntry structs already hold the original submission?

Can't we resolve this ticket just by changing SignedCertificateTimestamp.signed_entry and TimestampedEntry.signed_entry from...

select(entry_type) {

case x509_entry: ASN.1Cert;
case precert_entry_V2: TBSCertificate;

} signed_entry;

select(entry_type) {

case x509_entry: TBSCertificate;
case precert_entry_V2: TBSCertificate;

} signed_entry;

I think it makes sense to retain a different struct for each LogEntryType, rather than try to unify them. New LogEntryType values might be defined in future that aren't unifiable with the existing two.

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

  • Milestone set to review
  • Owner changed from benl@… to rob.stradling@…
  • Status changed from new to assigned

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

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