draft-sun-handle-system-def

[Russ Housley <housley@vigilsec.com>]

I have five comments on draft-sun-handle-system-def-07.

1.  Does <AdminRef> rely on [13]?  I do not believe that anyone is making 
updates to this registry as new algorithms come into widespread 
use.  Perhaps a registry that is being maintained can be referenced.

2.  Can <PublicKeyRecord> can contain an X.509 certificate?  If so, how is 
key type employed?  Does the client parse the certificate to determine the 
type of public key that is inside, or does the key type provide a hint?

3.  Section 5.2 says:

      ... To be authenticated as the administrator, the
      client has to return a challenge-response, a message that
      demonstrates procession of the administrator's secret. The secret
      may be the private key (or the secret key) of the administrator. If
      secret key authentication is used, the challenge-response will
      consist of the Message Authentication Code (MAC) over the server's
      challenge, generated using the administrator's secret key. If
      public key authentication is used, the challenge-response will
      contain the digital signature over the challenge, generated using
      the administrator's private key. This challenge-response allows the
      server to authenticate the client as the handle administrator. ...

This is a very bad idea.  The signer should always include a locally 
generated random value in the response.  Otherwise, the challenge generator 
could construct the challenge (perhaps with great effort, employing lots of 
precomputation) that matches the hash value of a contract.  In this way, 
the admin is tricked into signing a contract thinking that simple 
authentication was being performed.  The locally-generated random value 
completely thwarts such an attack.

4.  Section 5.3 also says:

      ... The MAC is
      generated by applying the standard MD5 hashing over the block of
      data that is made of the server's challenge concatenated with the
      secret key. ...

HMAC is a much more robust data integrity mechanism.  Why isn't it being 
used here?

5.  I prefer that [10] refer to RFC 3280.

Russ