Re: [Trans] [trans] #80 (rfc6962-bis): Re-introduce the issuer key hash into the Precertificate

[Stephen Kent <[e-mail]>]

Rob,

I agree with your conclusoon that inclusion of the issuer public key hash
will enable a browser to verify the correspondence between an SCT without
interacting with a log. Even though we don't yet have a browser behavior
spec, I agree that this is a good candidate behavior to enable.

Do you propose this as an extension to the current SCT format, or a change
to the format?  If you propose a change, then I'll argue that my proposed
cert type declaration and checks performed fields also should be included,
since we'll be making a not backward compatible change to the SCT. If this
is an (optional) extension, then I guess my proposed fields can be the 
second
and third extensions defined.

Steve
> #80: Re-introduce the issuer key hash into the Precertificate
>
>
> Comment (by [e-mail]):
>
>   This problem affects browser clients and any other client that wants to
>   verify that an SCT corresponds to a particular cert.  A browser has the
>   full cert chain (from the TLS handshake) and the corresponding SCTs, but
>   it is _not_ expected to have the full log entries (i.e. extra_data, etc).
>
>   In the current text, the SCT is bound to the Issuer Name (because that's
>   in the TBSCertificate), but not to the Issuer Key (because that's not in
>   the TBSCertificate).
>
>   There could exist two or more publicly-trusted intermediate CA certs with
>   the same Name but different Keys.  One of those intermediates might be
>   logged, while the other(s) are not logged.  Each of them could issue leaf
>   certs that have an identical TBSCertificate.  Only one of those leaf certs
>   needs to be logged for there to exist SCT(s) that are valid for all of
>   those leaf certs.
>
>   The logged leaf cert might get revoked, but the other(s) might not get
>   revoked.  However, the SCT(s) would still work for all of those certs,
>   including the non-logged ones.
>
>   Therefore, we need to fix SCTs so that they're bound to the Issuer Key
>   Hash as well as the Issuer Name.
>