Skip to main content

Last Call Review of draft-ietf-pkix-est-07

Request Review of draft-ietf-pkix-est
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-06-24
Requested 2013-06-13
Authors Max Pritikin , Peter E. Yee , Dan Harkins
I-D last updated 2013-06-20
Completed reviews Genart Last Call review of -07 by Roni Even (diff)
Secdir Last Call review of -07 by Derek Atkins (diff)
Assignment Reviewer Derek Atkins
State Completed
Review review-ietf-pkix-est-07-secdir-lc-atkins-2013-06-20
Reviewed revision 07 (document currently at 09)
Result Has Issues
Completed 2013-06-20

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

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

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 Atkins                 617-623-3745
       derek at   
       Computer and Internet Security Consultant