Intended Status: Proposed Standard
Technical Summary
This document profiles certificate enrollment for clients using CMC (RFC
5272) defined ³simple² PKI messages over a secure transport. In addition
to supporting certificate enrollment and renewal functions, EST also
provides a means to obtain copies of a Certificate Authority¹s
certificates, have a public key pair generated on behalf of the client,
and query the EST server on the attributes required in a certificate
request. Where this reduced set of management functionality is
inadequate, EST also allows the conveyance of full CMC (RFC 5272)
messages. EST is designed to be a standards-track profile of CMC
appropriate for solutions currently leveraging the widely implemented
but never fully standardized Simple Certificate Enrollment Protocol
(SCEP). It improves on that protocol by supporting a wider range of
algorithms as well as using TLS for added authentication, encryption,
and data integrity and aligning with existing CMC.
Working Group Summary
This draft is a product of the PKIX WG. It has gone through several
revisions within the WG, incorporating input from several major reviews
by Steve Kent and Russ Housley as well as reviews from outside sources.
The draft has not elicited much in the way of controversy, reflecting
only specialized interest in certificate enrollment protocols.
Document Quality
The document does require a fair bit of background in X.509, ASN.1, and
the re-used technologies in order to understand and implement the
protocol. However, implementations have been created by two of the
authors and one non-author implementor using disparate code bases.
Members of the Wi-Fi Alliance (WFA) have also implemented EST as part of
the WFA¹s Hotspot 2.0 efforts. Thus it is believed that EST
implementations can be created from its specification.
Personnel
Stefan Santesson (stefan at aaa-sec.com) is the document shepherd.
Sean Turner (turners at ieca.com) is the responsible Area Director.
I have reviewed this document and find it well written and consistent
with the WG consensus process. The protocol is technically sound has
Independent interoperable implementations and should be ready for
publication.
I have no concerns about the reviews done on this document. Steve Kent
has reviewed nearly every version of the document, while Russ Housley
gave a review to the last major revision before the WGLC version.
Several outside reviewers with expertise in certificate management
protocols have contributed reviews to the document and have expressed
satisfaction with the current state of the document.
The document also received an early review from Mark Nottingham on
behalf of the APPS area. Feedback from that review was incorporated
into the URL structure that EST uses. The media-types registration
requests have been sent by the responsible AD.
I have no specific concerns or issues with the document that I'm raising
to the responsible AD or the IESG.
I don¹t know of any BCP 78 and BCP 79 IPR issues that would require
filing disclosures.
I am not aware of any IPR disclosures filed that reference this document.
The draft didn¹t generate a large amount of discussion in the WG as it
has a limited scope of interest. That said, however, there were no
technical objections raised against this version of the draft.
No one has threatened an appeal or otherwise indicated extreme
discontent with the draft.
There are several ID nits that remain. None of them are serious. The
tool has mistaken some examples for code. There¹s a downref normative
reference to RFC 2986 because EST relies on CMC which also references
2986 (aka PKCS#10). A reference to the ³obsolete² TLS 1.1 (RFC 4346) is
intentional.
All references in the document have been noted as normative or
informative. None of the normative references are to documents that
have not already advanced or are in an unclear state.
The document currently makes normative references to 6 Informational
RFCs. These references are to RFCs 1321, 2818, 2985, 2986, 5054, and
5967. It also references 4 obsolete RFCs. These references are RFCs
2314, 4288, 4346, and 4366.
Publication of this document will not change the status of any existing
RFCs.
My review of the IANA Considerations section shows that it covers the
two required requests. There are no new IANA registries introduced by
this document. Media type registrations and well-known requests have been sent to
media-types@iana.org by the responsible AD.
I have not performed any automated checks on the ASN.1 found in the
document or the resultant Base 64-encoded examples, but the ASN.1 has
been used in at least three independent, interoperable implementations
and is therefore believed to be valid.