On Thu, Jan 24, 2013 at 10:18 PM, Trevor Perrin <tr...@trevp.net> wrote:
> Hi Emilia,
>
> I'll comment on 5878 separately, to your other points:
>
> On Thu, Jan 24, 2013 at 4:10 AM, Emilia Kasper <ekas...@google.com> 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?
>
>
Right...
> 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?
>
What we could do, I think, is stick the TBSCertificate issuer's public key
under the SCT signature. Keep in mind the goal, for us, is to bind the
TBSCertificate that appears in the log to the certificate the TLS client
sees.
>
>
> >> 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,
The extensions, as we proposed them, are meant to maintain backwards
compatibility with old TLS-CT clients.
> 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...
>
Sure.
Cheers,
Emilia
>
>
> Trevor
>
_______________________________________________
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey
