(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
author.
[0]
https://www.ietf.org/proceedings/97/slides/slides-97-lamps-est-extensions-00.pdf
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
perspective,
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.
None.
(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 http://www.ietf.org/tools/idnits/ 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.
N/A
(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?
No.
(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:
https://datatracker.ietf.org/doc/rfc7191/history/
- RFC 7193 (draft-turner-application-cms-media-type) was
included in as DOWNREF for RFC 7191:
https://datatracker.ietf.org/doc/rfc7191/history/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
type.
(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.
None.