Subject: [keyassure] draft-ietf-dane-protocol-00

From: "Carl Wallace" <[email-masked]>
Date: Tue, 14 Dec 2010 10:35:53 -0500

Here are a few comments on the new draft:

Section 1.1 should be clear that the hash covers the binary DER encoded
certificate.  

It may be worth including a length check to avoid potential issues with
appended data (i.e., ensure the client calculated hash does not cover
junk appended to a binary certificate).  A security or implementation
consideration would suffice too.

In 2.1, the current text allows an intermediate CA certificate to match
the hash when it is in the certificate bundle but seems to require a
trust anchor match when no match is found in the bundle.  Was this
intentional?  If I build a path to a trust anchor using a certificate
not in the bundle that matches the hash that should be OK too.  

The reliance on a hash of a trust anchor creates a need to install the
trust anchor in your browser store, which should probably be mentioned
in the security considerations.  Ideally usage of this spec would not
result in even more cluttered TA stores.  This mechanism creates a
potential scenario where one could build a path to a self-signed
certificate retrieved from an AIA pointer that is not in your trust
anchor store provided the certificate matches the Type 3 hash (though
the current text precludes this).  

In 2.1, do "valid up to" and "chains to" mean full RFC 5280 path
processing including revocation status checking?

Section 3.1.2 might benefit from the addition of a SHOULD NOT cautioning
against including domain names in shared certificates, just to avoid
confusion.