Skip to main content

Shepherd writeup

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Is this
    type of RFC indicated in the title page header?

   Proposed Standard is being requested.  This draft extends a protocol that is
   a Proposed Standard, hence the requested status.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such
    a Document Announcement Write-Up. Recent examples can be found in the
    "Action" announcements for approved documents. The approval announcement
    contains the following sections:

Technical Summary

   The EST (Enrollment over Secure Transport) protocol defined a Well-
   Known URI (Uniform Resource Identifier): /.well-known/est.  EST also
   defined several path components that clients use for PKI (Public Key
   Infrastructure) services, namely certificate enrollment (e.g.,
   /simpleenroll).  In some sense, the services provided by the path
   components can be thought of as PKI management-related packages.
   There are additional PKI-related packages a client might need as well
   as other security-related packages, such as firmware, trust anchors,
   and symmetric, asymmetric, and encrypted keys.  This document also
   specifies the PAL (Package Availability List), which is an XML
   (Extensible Markup Language) file or JSON (Javascript Object
   Notation) object that clients use to retrieve packages available and
   authorized for them.  This document extends the EST server path
   components to provide these additional services.

Working Group Summary

  This document was discussed in the LAMPS WG at the IETF 97  [0] at
  the request of a former AD (Stephen Farrell).  However, the WG chair
  did not request WG adoption only that comments be directed to the


Document Quality

Are there existing implementations of the protocol? Have a significant number
of vendors indicated their plan to implement the specification? Are there any
reviewers that merit special mention as having done a thorough review, e.g.,
one that resulted in important changes or a conclusion that the document had no
substantive issues? If there was a MIB Doctor, Media Type or other expert
review, what was its course (briefly)? In the case of a Media Type review, on
what date was the request posted? Personnel Who is the Document Shepherd? Who
is the Responsible Area Director?

   There are a few implementations.  It is not that hard to implement some
   parts of this draft and there are no dependencies on the added path
   components so they can be implemented independently as needed; the Shepherd
   implemented the PAL extension and the /symmetrickeys path component as
   extensions to his existing EST implementation (both client and server).

   Panos Kampanakis reviewed the draft and particularly liked the delivery
   of PKCS#12 packages.  Panos as well as a number of LAMPS WG
   members wanted the PAL formatted in JSON.  Alexey Melnikov and
   Mark Nottingham pointed out that using the HTTP Accept header the
   client can indicate whether it supports XML or JSON allowing both to
   be supported.

   There is however absolutely no expectation that implementations of this
   draft will storm the Internet.  But all of services/packages are based
   on existing RFCs and a community does exist that relies on
   CMS-protected objects (CMS protects most of the packages).

   Dan Harkins has agreed to be the draft Shepherd.
   Kathleen Moriarty has agreed to be the RAD.

(3) Briefly describe the review of this document that was performed by the
Document Shepherd.
   If this version of the document is not ready for publication, please explain
   why the document is being forwarded to the IESG.

  The Document Shepherd read the document and implemented a portion of it. The
  document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

  No, PKIX-knowlegable individuals have provided a good depth of review of
  message contents. The LAMPS WG provided valuable feedback with a good breadth
  of the overall protocol.

(5) Do portions of the document need review from a particular or from broader
   e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
   internationalization? If so, describe the review that took place.

   The XML version of the PAL is somewhat detailed and having an XML expert
   review it for completeness and correctness would be good.

(6) Describe any specific concerns or issues that the Document Shepherd has
with this document
   that the Responsible Area Director and/or the IESG should be aware of? For
   example, perhaps he or she is uncomfortable with certain parts of the
   document, or has concerns whether there really is a need for it. In any
   event, if the interested community has discussed those issues and has
   indicated that it still wishes to advance the document, detail those
   concerns here.


(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full
   conformance with the provisions of BCP 78 and BCP 79 have already been
   filed. If not, explain why.

  Yes - all relevant provisions of BCP 78 and BCP 79 have been filed.

(8) Has an IPR disclosure been filed that references this document? If so,
summarize any discussion
   and conclusion regarding the IPR disclosures.

   No IPR has been filed.

(9) How solid is the consensus of the interested community behind this
document? Does it represent
    the strong concurrence of a few individuals, with others being silent, or
    does the interested community as a whole understand and agree with it?

  Concurrence of a few individuals.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please
    summarise the areas of conflict in separate email messages to the
    Responsible Area Director. (It should be in a separate email because this
    questionnaire is publicly available.)

   There has been no threat of appeal or indication of discontent.

(11) Identify any ID nits the Document Shepherd has found in this document.
     (See and the Internet-Drafts Checklist).
     Boilerplate checks are not enough; this check needs to be thorough.

   ID Nits complains about a few downrefs, see below. RFC 4627 is obseleted and
   should probably not be included as a normative reference, references to RFC
   4627 should be replaced by references to RFC 7159.

(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor,
    media type, and URI type reviews.


(13) Have all references within this document been identified as either
normative or informative?

   Yes the references are identified as either normative or informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise
   in an unclear state? If such normative references exist, what is the plan
   for their completion?


(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward
    references to support the Area Director in the Last Call procedure.

   There are multiple DOWNREFs: 2818, 2985, 3394, 5649,
   5753, 5967, 6268, 7193, and 7292.  All but 6268, 7193, and
   7292 already appear in the DOWNREF registry.  Examining
   the other three it appears that two should already have
   been included in the DOWNREF registry:

   - RFC 6268 was included as a DOWNREF for RFC 7191:

   - RFC 7193 (draft-turner-application-cms-media-type) was
   included in as DOWNREF for RFC 7191:

  RFC 7292 (aka PKCS#12) needs to be included the IETF LC
  as a DOWNREF.  Note that if it’s not included in this IETC LC
  it might appear in one of the other two drafts that normatively
  refer to it.

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed
  on the title page header, listed in the abstract, and discussed in the
  introduction? If the RFCs are not listed in the Abstract and Introduction,
  explain why, and point to the part of the document where the relationship of
  this document to the other RFCs is discussed. If this information is not in
  the document, explain why the interested community considers it unnecessary.

   No other RFCs' status will change. This was by design. THis draft
   specifically does not “update” RFC 7030 (aka EST) because there is no intent
   that existing EST implementations MUST be updated to support all of the
   “services”. Implementations are free to pick which ones they want to support.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with
  regard to its consistency with the body of the document. Confirm that all
  protocol extensions that the document makes are associated with the
  appropriate reservations in IANA registries. Confirm that any referenced IANA
  registries have been clearly identified. Confirm that newly created IANA
  registries include a detailed specification of the initial contents for the
  registry, that allocations procedures for future registrations are defined,
  and a reasonable name for the new registry has been suggested (see RFC 5226).

  IANA is requested to register an XML namespace, a schema. It is also request
  to establish a Expert Review registry for PAL Package Types. An expert won’t
  be too hard to come by but will nonetheless have to be identified.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public
   guidance that the IESG would find useful in selecting the IANA Experts for
   these new registries.

  The only required guidance is that the Package Types be coupled with a media

(19) Describe reviews and automated checks performed by to validate sections of
the document written
   in a formal language, such as XML code, BNF rules, MIB definitions, etc.