Hi,

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

   This document profiles certificate enrollment for clients using
   Certificate Management over CMS (CMC) messages over a secure
   transport.  This profile, called Enrollment over Secure Transport
   (EST), describes a simple yet functional certificate management
   protocol targeting Public Key Infrastructure (PKI) clients that need
   to acquire client certificates and associated Certification Authority
   (CA) certificate(s).  It also supports client-generated public/
   private key pairs as well as key pairs generated by the CA.

The document claims that trust anchor distribution is out of scope,
and continues on that authenticity cannot be inferred until an
out-of-band, non-specified mechinsm is used to verify.  This just
seems like it's kicking the can down the road to the next protocol
that would need to define how to securely distribute the
authentication information.  If you have to preconfigure then why not
just leverage that existing preconfiguration to distribute the
certificates?

Even section 2.2 continues with this; it assumes a pre-distributed
authentication credential (or leverages a user's existing credential).
For the user credential case there's still a missing trust link
between the user and the target of the new certificate.  For example,
if you're trying to issue a machine (device?) certificate based on a
user credential then all the EST server can intuit is that the user is
requesting it but there is no authentication tying that user to the
target device; you're still taking a leap of faith which would need to
be audited after the fact.

Certificate renewal, (e.g. leveraging an existing certificate) has
already been solved by e.g. SCEP and other protocols.

In 2.6, the additional CSR attributes are non-verifiable data.  E.g.,
if a client puts a MAC address into its CSR, there is no way for the
EST server or CA to validate that input.  The client can easily insert
any data it wants into that request, which can lead to MAC stealing or
other impersonation attacks.  The CA should never put any normative
information into the certificate that it cannot validate from a
trusted source.

In 3.3.2, if the EST client already has a certificate with which it
can athenticate then why would it need to enroll?  It's already
enrolled; the only interesting problem (IMHO) at that point is
renewal.

In short, I'm not sure I would call this "Enrollment" as opposed to a
way to leverage an existing authentication mechanism and turn it into
a certificate.  Perhaps that is your definition of enrollment?  In
essense it just feels like SCEP, redone using REST.

-derek

-- 
       Derek Atkins                 617-623-3745
       derek at ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant