Enrollment over Secure Transport
RFC 7030

Balloting No Objection after a light skim and trusting the Security ADs to get this right

Not sure I've seen any answer to Nevil's OPS DIR review:


I have reviewed this draft.  It "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)."

I'm certainly not a security expert, and this is a fine-detailed
document that's clearly intended for people who have a good understanding of public key infrastructure, in particular RFC 5274
(Certificate Management Messages over CMS).  Nonetheless, it's
well-written, and I had no difficulty understanding how an EST server
is intended to work.

When it comes to deploying an EST server, an organisation will obviously
need to understand how pkix works in considerable detail, and to make
sure that its various components will have to interwork properly with
each other.  That said, this draft document documents a new service -
as far as I can see - so anyone deploying it will need to be sure that
their existing pki infrastructure will support it properly.

I note that in several places (e.g. section 3.32.3) there's a reference
to "TLS 1.1 [RFC4346] or later versions."  That seems like a good idea,
allowing for newer versions of TLS to work with an EST server,  however
it does mean that EST implementors will need to check that their servers
continue to work properly with such newer versions.

Question: in section 1.1, Terminology, 'Implicit Trust Anchor:' gives
an example that includes "used by server's to authenticate
manufacturing installed client credentials."  Can you make it a bit
clearer just what that really means?


A few small typos:

section 3.4: s/the possesion and/the possesion of and/  ?

section 3.4  s/cipher suite pose such/cipher suite poses such/

section 3.7  /simpleenroll is split over a line break, leaving
             a lone / at the end of a line

section 4.2  s/verify the authorization the/
               verify the authorization of the/

section 4.2.1  s/used to for/used for/

sections 4.2.3 and 4.3.2  s/informative information/information/ ?

section 4.5.2  s/Csrattrs/csrattrs/  (why the uc C here?)

Cheers, Nevil

This seems both explicit and wierdly non-specific.

  TLS cipher suites that include "_EXPORT_" and "_DES_" in their names
   MUST NOT be used.  These ciphers do not offer a sufficient level of
   protection; 40-bit crypto in 2013 doesn't offer acceptable protection
   and the use of DES is deprecated.

This document is just mad for 2119 language. There are some places where I think they are used excessively, but I am trying to be on board with Stephen's philosophy of "if it's not going to mess up an implementation, ignore incorrect uses". There are no technical worries that I see. So, I will only mention two silly, more editorial points:

Section 2:

   This section does not include RFC 2119 key words.

Really? :-) I suggest deleting the sentence.

Section 3.1:

   The EST client is RECOMMENDED to be configured with...

I'm worried what the answer might be, but why didn't you say "The EST client SHOULD be configured with..." instead of contorting the adjective into a place perfectly suited for an auxiliary verb? (You've got similar things throughout the document: "It is RECOMMENDED that clients..." instead of "Clients SHOULD...".) Is there anything other than just a weird writing style that is making you use these strange passive sentences? It's not that you think SHOULD and RECOMMENDED mean two different things, right?

These comments are for the editors. Please consider them as your document moves through the process.

In 3.2.  HTTP Layer

   HTTP 1.1 [RFC2616] and above support persistent connections.  As
   described in Section 8.1 of that RFC, persistent connections may be
   used to reduce network and processing load associated with multiple
   HTTP requests.  EST does not require or preclude persistent HTTP
   connections and their use is out of scope of this specification.

If I understand the final sentence correctly, EST works fine whether you use persistent HTTP connections or not. If that's so, and I suspect it is, that's not "out of scope", that's "good news! we've looked at it, and there's no problem". Please consider removing "and their use is out of scope of this specification".

In 4.4.1.  Server-side Key Generation Request

   The server needs to know a priori about the algorithms supported by
   the client.

I don't know whether this requirement is typical or not, but I wonder - is there some way this might be signaled?