On Tue, Jan 22, 2013 at 4:19 PM, Ben Laurie <[email protected]> wrote:
> On 22 January 2013 23:07, Trevor Perrin <[email protected]> wrote:
>
>> (2) Why are the RFC 5878 / RFC 4680 Authorization Extension and
>> SupplementalData mechanisms used to convey the SCT, instead of
>> defining a new TLS Extension?
[...]
>
> At the time the mechanism was defined, Experimental track was more
> standardised than what we were defining. We could indeed contemplate
> defining our own extension if we go beyond Experimental ourselves.
Defining your own TLS Extension seems simpler, why not do it from the start?
I'd be curious if potential implementors have an opinion. The
difference is roughly:
WITH A CT TLS EXTENSION:
- ClientHello contains a TLS extension to indicate CT support
- ServerHello contains a TLS extension with:
- 2 byte length of SignedCertificateTimestampList
- sequence of:
- 2 byte length of SCT
- SCT
WITH THE 5878 TLS EXTENSION:
- ClientHello contains a TLS extension with a list of single-byte
values, one of which indicates CT support
- ServerHello contains a TLS extension with a list of single-byte
values, one of which indicates SCTs are present
- Following ServerHello is an RFC 4680 SupplementalData message:
- 3 byte length
- sequence of SupplementalDataEntry, each with:
- 2 byte type
- 2 byte length
- (if type = "authz_data", then the body of this entry is):
- 2 byte length
- sequence of AuthorizationDataEntry, each with:
- 1 byte type (which may indicate an SCT is present)
- (length field for SCT? unclear in draft-05)
- SCT
(I think this is right but the structures in 5878 section 3 don't
actually match 4680 (errata?), nor does draft-05 define the encoding
of an SCT into an AuthorizationDataEntry, so I'm not sure.)
Anyways, 5878/4680 seem like unnecessary layers of parsing.
>> - Related to previous: why is it necessary for SCTs and
>> MerkleTreeLeafs to have different cases for precerts and certs? Could
>> the signature be calculated on a "normalized" form of the
>> TBSCertificate which is the same for certs and precerts (i.e. the
>> TBSCertificate with poison and SCT extensions removed?)
>
> We did consider that, but it is not what the code does currently.
> There's no particular reason it could not be done that way, as far as
> I currently know.
It would seem simpler, since clients would not need separate code
paths for precerts and "fully-logged" certs. Also, this would
simplify the data structures since you could eliminate the
"entry_type" from the LogEntry, SCT, and MerkleTreeLeaf.
Related comment: There should probably be Security Considerations
about logging TBSCertificates, since I think there are some subtle
issues that arise from logging TBSCertificates if you're using
revocation systems based on the full certificate (like OCSP, CRLsets,
etc.).
For example, a rogue CA could potentially issue a rogue sub CA with
the same name as some existing CA, and this rogue sub CA could issue
rogue certs with TBSCertificates that match existing certificates. If
such a rogue certificate was issued that matched a revoked cert for
which an attacker had compromised the private key, the rogue cert
could be used with the revoked cert's SCT, but might not itself be
revoked (since revocation methods like OCSP and CRLsets scope
revocations to the issuer's key hash).
So, revocation systems would need to be cognizant of this risk and
revoke the TBSCertificate, it seems?
>> (4) Why is the SCT's timestamp and CtExtensions included in the
>> MerkleTreeLeaf? If the Merkle Tree was built directly on hash(cert)
>> leaves instead of hash(SCT fields), then the audit path mechanism
>> could be deployed earlier / independently from SCTs,
[...]
> 2. If you built a Merkle tree based on the cert alone, what would the
> correct action of a client which saw a cert with no SCT be? Sure, it
> could check the log and see it was not in it - but then what? It can't
> reject it, perhaps it is the first CT-enabled client to see the cert
> (or one of the first). The fact it lacks an SCT shows it hasn't
> participated in voluntary logging. So the correct action is to log it,
> and obtain an SCT for it
Or just report it to someone you trust who logs it for you - the
browser doesn't need the SCT in this case.
> So why not just always attempt to log it?
It's more efficient if the browser could fetch an audit proof without
also needing an SCT, and it would be simpler if Merkle Tree Leaves
were just defined like:
struct {
Version version;
opaque tbscertificate<1...65535>;
}
} MerkleTreeLeaf;
I guess these aren't the strongest arguments, but I don't see that
this simplication loses anything important.
> In any case, we are not primarily attempting to build a system that
> solves a half-way problem - we want full deployment of CT.
Sure, but if it's going to take awhile to get SCTs universally
deployed, it would be nice to get some of the benefits of CT earlier.
That's why I like the idea of using scanning and online checks to
populate logs until SCTs are ubiquitous (at which point the CAs and
TLS servers will have assumed the responsibility of populating logs).
> [1] There are, of course, distinct weaknesses compared to a system
> built on SCTs - for example, the tree is no longer self-timestamping
> and so claims about timing become more difficult to substantiate.
I don't see the weakness - the log is ordered, periodically signed
with a timestamp (TreeHeadSignature), and monitored, so won't you have
good timing data for log entries regardless?
Trevor
_______________________________________________
therightkey mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/therightkey
