On 22 January 2013 23:07, Trevor Perrin <[email protected]> wrote: > Hi, > > Some questions, based on draft-05: > > (1) Is there going to be a DNS-based protocol for retrieving audit proofs?
Yes. Not in this I-D. > (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? (RFC 5878 is an Experimental-track TLS > Extension; CT adds a new extension value to it to signal that an SCT > is included in an RFC 4680 SupplementalData handshake message; this > seems more complex than just putting the SCT directly in a 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. > > (3) Some things about "precertificates" are unclear to me, in draft-05: > - If the precert is signed by the "CA certificate that will sign the > final certificate", as described in the second bullet in 3.1, does > this CA cert also need to contain the "Certificate Transparency" EKU > extension from the first bullet? > - In the SCT for a precertificate, what exactly does the log sign? > Is it the TBSCertificate including the poison extension, or is the log > expected to remove the poison extension prior to signing? This is more clearly explained in the next revision. > - How exactly does a TLS client verify an SCT for a precert? Does > the client need to remove the SCTs and recalculate the original > TBSCertificate's ASN.1 to verify? Yes. > - 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. > (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, i.e. browsers > could retrieve and check audit paths for certs regardless of whether > the TLS server had presented an SCT. Perhaps CT doesn't envision that > use case, but it seems potentially useful. So I'm wondering if it > might be worth decoupling the SCTs from the merkle trees to provide > more deployment flexibility. I think there are two semi-separate issues here: 1. The log must be held to a promise to include a cert within a certain time, which is why it signs an SCT. I think it is correct that you could construct a working system that then built a Merkle tree on the cert alone (I may have missed an attack, though[1]), but I don't think this actually has any advantage over a tree built on the SCT (see point 2), given that you have to make an SCT anyway. 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 (which can later be shown if the log fails to include the cert). So why not just always attempt to log it? If its already there you'll (probably) get an SCT in the past. Otherwise, monitors can pick it up and take appropriate action. BTW, I am not against logs providing a way (e.g. via DNS) to pre-check whether a cert exists in the log before attempting to log it, but I don't think that needs to be part of the CT spec. In any case, we are not primarily attempting to build a system that solves a half-way problem - we want full deployment of CT. [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. > > > Trevor > _______________________________________________ > therightkey mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/therightkey _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
