On Fri, 2010-09-17 at 00:34 +0200, Martin Rex wrote: > Cleanup of my prior message: > > > Matt McCutchen wrote: > > > > On Thu, 2010-09-16 at 07:27 +0200, Martin Rex wrote: > > > Clearly unsafe operations: > > > > > > - building a reference identifier from the result of a > > > DNS CNAME lookup > > > > > > (the use of DNSSEC does not make this safe) > > > > Why not? I'm not saying it's good practice, but I don't see an actual > > vulnerability. > > You need two characteristics: > > (1) _trustworty_ information source for a name transformation > (2) _protected_access_ to the information source > > DNSSEC meets (2) but not (1)
Why not (1)? It should go without saying that by DNSSEC I meant "DNSSEC with a set of trustworthy trust anchors that will get us to the desired signed zone". From there, the DNS admin has full authority to say what certificates a client trying to connect to a host in her zone should accept. We could have a record, CERTNAME or something, that specifies the hostname for which the certificate should be valid (via keyassure or PKIX + server-id-check). I realize now that it would be dangerous to reinterpret CNAME for this purpose, just as it is dangerous to reinterpret CERT as making an assurance, but that is a separate issue. I still wouldn't advise doing it unless we come up with a compelling use case. -- Matt _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
