Hi Emilia, I'll comment on 5878 separately, to your other points:
On Thu, Jan 24, 2013 at 4:10 AM, Emilia Kasper <[email protected]> wrote: >> >> >> - 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. > > > Not strongly opposed to it, though it would leverage the re-signing attack > you describe below to existing certificates, too. I guess, though a rogue CA #2 could submit precerts for existing certs, thus exposing them to this attack from other rogue CAs... even more far-fetched, I admit, but I tentatively think there should be a better solution to that attack in general, as opposed to just partly limiting who is exposed to it. >> 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? > > > A little far-fetched as an attack - but yes. CAs can include an Authority > KeyID extension in new (TBS)Certificates logged by CT, to protect against > this. I think the Authority Key Identifier is matched against whatever Subject Key Identifier is declared in the issuing CA cert. So, I *think* it can be chosen by an attacker to match a target TBSCertificate, and doesn't help here? Maybe there should be some other X.509v3 critical extension, allowing the TBSCertificate to contain a reference to the issuer's public key? That might be easier than modifying revocation systems? >> 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. > > > We don't know what the CT extensions will be yet but I imagine we'll want to > have them included in the tree, so that monitors can examine them. > > Also, the SCT timestamps serve as a hint for the location of the entry in > the tree - makes it easier to design efficient privacy-friendly client > protocols (briefly mentioned in Sect. 7.3 of the current draft version). Hmm. You could always define a new leaf type if you need extensibility, and having clients lookup entries based on time ranges (or leaf_index ranges) doesn't seem to require actually hashing the SCT's timestamp into the leaf. So I'm not convinced you're gaining anything worth the loss in simplicity and flexibility of a simpler leaf based directly on certificates. But it's a design decision, there's arguments both ways... Trevor _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
