On Thu 2016-05-05 09:04:09 -0400, Ben Laurie wrote:
>> 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.
>
> Likely? Isn't it certain (if the EE cert validates, that is)?
well, there are always cases like:
* web browser not configured with certificate chain (aka transvalid
certs), and
* user has clicked "accept" on the scary warning page for the cert in
question
I'd argue that even in that case, CT is still useful -- for example, a
browser could consider make the clickthrough less
scary/cumbersome/difficult if it had a valid SCT. But it won't be able
to validate the SCT, so that's not an option.
>> 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?
>
> That seems like a good idea. Presumably we'd need to add a new
> TransItem type to carry this information.
Is there a transaction in CT itself where you expect that to happen?
Can you propose a change to the draft that would make that clear?
Is the clumsiness of needing the issuer key in addition to the cert and
SCT in order to validate the SCT worth the 32 octets in size it shaves
off?
--dkg
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans