hey folks-- Why aren't we explicitly including the issuer_hash in the SignedCertificateTimestampDataV2 object?
i notice that someone who has only: a) an X.509 end-entity certificate and b) what appears to be a corresponding SCT Can't actually evaluate the validity of the log signature on the SCT over the certificate. This missing data is the hash of the issuer's public key, which is included in the signed material but isn't otherwise available from either (a) or (b). (i'm assuming here that (b) is a TransItem with versioned_type set to either x509_sct_v2(3) or precert_sct_v2(4), with data set to a SignedCertificateTimestampDataV2) I understand that adding the issuer_hash will increase the size of the SCT by 32 octets, but without that information, someone evaluating the SCT has no way of knowing whether it is legitimate. In the TLS handshake case, it's likely that the TLS client can compute the issuer_hash by extracting the SPKI from the next cert in the offered x.509 chain. But in other cases (e.g. auditing, gossiping), there's no guarantee that the issuer cert (or issuer public key) is going to be passed alongside the SCT. Do we want to require people to pass the issuer cert (or issuer public key?) alongside the cert in order to be able to verify the signature on an SCT? If so, where is the best place to document that concern? Or have i misunderstood the data structures? I'm working from https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-14 the issuer key hash was re-introduced here, i think: https://trac.tools.ietf.org/wg/trans/trac/ticket/80 but there's no consideration there for how validators are expected to function in the absence of the full chain. Any thoughts? --dkg
signature.asc
Description: PGP signature
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
