Opened 8 years ago

Closed 7 years ago

#47 closed defect (fixed)

Clarify how to deal with (minor) DER violations when manipulating a TBSCertificate

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

Description

Section 3.1 says:

"Logs MAY accept certificates that...are otherwise not

fully valid according to X.509 verification rules in order to
accommodate quirks of CA certificate-issuing software."

A couple of examples of such quirks:

  • Use of ASN.1 indefinite length (permitted by BER but not by DER).
  • DEFAULT values encoded explicitly (when they should be omitted).

When generating a Precertificate SCT, a Log extracts the Precertificate's TBSCertificate and adds the critical poison extension. When verifying a Precertificate SCT, a Client reconstructs the Precertificate by extracting the certificate's TBSCertificate, removing the SCT List extension and adding the critical poison extension.

6962-bis should explicitly state whether these ASN.1 manipulations should preserve any (minor) DER violations, or correct them. (If the behaviour across implementations is not consistent, some Clients will be unable to verify SCTs generated by some Logs).

Chromium and https://github.com/google/certificate-transparency both decode the cert (into OpenSSL's/NSS's internal format), add/delete the extension(s), then re-encode the TBSCertificate. I'm fairly certain this corrects any DER violations.

I propose that 6962-bis should say:

  • When generating/verifying a Precertificate SCT, Logs and Clients MUST make a best effort attempt to correct DER violations.
  • When generating/verifying a Certificate SCT, Logs and Clients MUST NOT correct DER violations - i.e. treat the certificate as an opaque blob.

Change History (5)

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

I got a little bit muddled.

Replying to rob.stradling@…:
<snip>

When generating a Precertificate SCT, a Log extracts the Precertificate's TBSCertificate and adds the critical poison extension.

Correction: the critical poison extension is already present in the Precertificate. The Log needs to delete it (not add it) before generating the Precertificate SCT.

When verifying a Precertificate SCT, a Client reconstructs the Precertificate by extracting the certificate's TBSCertificate, removing the SCT List extension and adding the critical poison extension.

Correction: the critical poison extension is omitted when signing/verifying a Precertificate SCT, so the Client doesn't add it.

Section 3.3 says:

"tbs_certificate" is the DER-encoded TBSCertificate (see [RFC5280]) component of the Precertificate -- that is, without the signature and the poison extension...Note that it is also possible to reconstruct this TBSCertificate from the final certificate by extracting the TBSCertificate from it and deleting the SCT extension."

comment:2 Changed 8 years ago by eranm@…

In a follow-up discussion Rob suggested the following, which I find more sensible:
"[...] add-chain/add-pre-chain SHOULD return an error (rather than generate and return an SCT) if there are any DER violations, but that even when this happens the Log SHOULD add the (pre)cert to the Merkle tree if it is able to do so?"

I think it's the right thing to do because allowing Precertificates with DER violations into the log would put a burden on clients in one of the following ways:

  • Clients are forced to preserve DER violations when manipulating the certificate: It is extremely difficult (in Java) or outright impossible (in Go) to parse such a certificate with the standard libraries available. And reconstructing the precertificate using the original DER data would be a painful effort of "stitching together" valid and invalid DER.
  • Clients make "best efforts" to fix DER violations: since this is not well defined, it is likely to vary between platforms/languages, so the signature may not validate over the resulting Precertificate.

Either way, this would mean writing CT-compliant TLS clients is going to be very difficult.

So requiring logs to refuse issuing SCTs for such certificates would rid of the problem entirely. I will come up with metrics on how many certificates with DER violations currently exist in our logs.

comment:3 Changed 8 years ago by benl@…

I'd note that detecting DER violations is hard with many packages (our Python does it, but OpenSSL presumably does not, or we would not have DER-violating certs in the log).

So, probably what we're really asking for here in practice, at least in some case, is that if a certificate validates but its reconstruction in DER does not match its original form, then we should log it but return an error.

When this occurs, it may be a bug in the log or in whatever chain of software created the cert.

Note that some DER errors may cause the certificate not to validate (because the validation s/w cannot understand the cert well enough to parse it), so this is necessarily a somewhat soft requirement. And thus needs to be phrased appropriately, such as

"When a certificate validates but has detectable DER violations (for example, valid BER encodings that are not valid DER encodings), the log SHOULD..."

Also, there are two classes of DER violation:

  1. Correct encoding according to BER, but not according to DER.
  1. Just plain wrong.

Logs should probably only try to deal with errors in the first class!

comment:4 Changed 7 years ago by eranm@…

Seems to me that this issue is still present after the Precertificate changes as clients would still have to manipulate the final X.509 certificate to extract the TBSCertificate part, remove extensions and reconstruct the redacted TBSCertificate if there are redactions.
It would be exacerbated if we accept ticket #4 (Signing the TBSCertificate part for certificates as well).

Ben, are you suggesting the log does not provide SCTs for such certificates but does include them in the tree?

comment:5 Changed 7 years ago by benl@…

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