EST (Enrollment over Secure Transport) Extensions
draft-turner-est-extensions-11

[Ballot discuss]
Thanks for addressing my previous DISCUSS and comments. Unfortunately, the new text contains a mismatch between specification and example, which is a common source of incompatibilities -- this leads to a different blocking issue.

The specification says:

      [ | 'iasn'] includes both [ | 'issuer']
      and [ | 'serial'] as a complexType in XML and an object
      in JSON.  [ | 'issuer'] is a DN encoded as a string with
      the format defined in [RFC4514];  is a positiveInteger
      and 'serial' is a number.

An excerpt from the relevant example:

      "info":
        {
        "iasn":
          {
          "issuer": "CN=Sean Turner,O=sn3rd,C=US",
          "sn": 0
          }
        }

Note the difference between "serial" (spec) and "sn" (example).

[Ballot discuss]
[NOTE -- While I did not have time to review this document prior to last week's telechat, the author reached out to me to specifically request that I review it and enter a ballot]

The way JSON is defined in this document is ambiguous and/or incomplete to such a degree that I doubt interoperability can be achieved. There are two major issues.

The first issue is that the "info" field is described as containing one of four variations (dn, ski, iasn, and url), but there's no instruction about how to indicate which variation is being used; and, for DistinguishedName, it's not clear how one encodes the issuer and serial elements.

There are a handful of ways you could address this. I think the one that makes the most sense is to specify your JSON such that the objects relate to each other in the same way as they do in XML. This means that the "info" value would be an object containing one key (selected from "dn", "ski", "iasn", and "uri"), and the value of this key would be a string (for dn, ski, and uri) or an object containing an issuer and a serial key (for iasn). An example JSON PAL under this scheme would look like:

[
  {
    "Type": 3,
    "Date": "2016-12-29T09:28:00Z",
    "Size": 1234,
    "Info": {
      "url": "https://www.example.com/.well-known/est/eecerts/1234"
    }
  },
  {
    "Type": 3,
    "Date": "2016-12-29T09:28:00Z",
    "Size": 1234,
    "Info": {
      "iasn": {
        "issuer": "CN = TrustID Server CA A52, OU = TrustID Server, O = IdenTrust, C = US",
        "serial": 1
      }
    }
  }
]


The second issue with JSON handling is that the implied syntax is in violation of RFC 7159, section 6 ("Leading zeros are not allowed."). For example, if you take the example given in the document and run it through a JSON parser, you get:

{ "Type": 0003, "Date": "2016-12-29T09:28:00Z", "Size": 1234, "Info": "https://www.example.com/.well-known/est/eecerts/1234" }
          ^
SyntaxError: Unexpected number in JSON at position 11

So, if you keep the fixed-width, zero-padded format for PAL identifiers (and I don't see why you should -- see my comments below), you'll need to encode them as strings rather than integers in JSON.

[Ballot discuss]
The way JSON is defined in this document is ambiguous and/or incomplete to such a degree that I doubt interoperability can be achieved. There are two major issues.

The first issue is that the "info" field is described as containing one of four variations (dn, ski, iasn, and url), but there's no instruction about how to indicate which variation is being used; and, for DistinguishedName, it's not clear how one encodes the issuer and serial elements.

There are a handful of ways you could address this. I think the one that makes the most sense is to specify your JSON such that the objects relate to each other in the same way as they do in XML. This means that the "info" value would be an object containing one key (selected from "dn", "ski", "iasn", and "uri"), and the value of this key would be a string (for dn, ski, and uri) or an object containing an issuer and a serial key (for iasn). An example JSON PAL under this scheme would look like:

[
  {
    "Type": 3,
    "Date": "2016-12-29T09:28:00Z",
    "Size": 1234,
    "Info": {
      "url": "https://www.example.com/.well-known/est/eecerts/1234"
    }
  },
  {
    "Type": 3,
    "Date": "2016-12-29T09:28:00Z",
    "Size": 1234,
    "Info": {
      "iasn": {
        "issuer": "CN = TrustID Server CA A52, OU = TrustID Server, O = IdenTrust, C = US",
        "serial": 1
      }
    }
  }
]


The second issue with JSON handling is that the implied syntax is in violation of RFC 7159, section 6 ("Leading zeros are not allowed."). For example, if you take the example given in the document and run it through a JSON parser, you get:

{ "Type": 0003, "Date": "2016-12-29T09:28:00Z", "Size": 1234, "Info": "https://www.example.com/.well-known/est/eecerts/1234" }
          ^
SyntaxError: Unexpected number in JSON at position 11

So, if you keep the fixed-width, zero-padded format for PAL identifiers (and I don't see why you should -- see my comments below), you'll need to encode them as strings rather than integers in JSON.

[Ballot comment]
The specification of  codes being 4-digits long seems artificial. It's also the source of the issues regarding JSON leading zeros (in my DISCUSS) and XML format ambiguity (below). You also artificially constrain the space available for registration (and, while I concede that 10,000 codepoints is probably sufficient, the constraint seems unnecessary). Simply making this an integer seems much cleaner. If a zero-padded four-digit representation is needed for some reason, please add an explanation of that reason to the document.

Section 2.1 indicates that servers can limit the size of the PAL to meet client constraints. This document should specify how the server knows what these constraints might be (reading the document, I assume this is provisioned information? If so, that should be stated explicitly).

In the list of PAL packages, 0018 says "see 0011", which in turn says "see 0008". Is there some reason 0018 doesn't shortcut this by simply saying "see 0008?" (There's a congruent situation with 0019, 0012, and 0009).

The prose implies (but does not specify) that only one of the four representations of  can appear in a single PAL entry. I would expect some normative restriction in the prose and/or a restriction in the XML schema (e.g., ).

Similarly, the XML schema allows for PackageType to be an integer containing one to four digits -- but everywhere PAL packages are mentioned, they're showed with leading zeros. It seems that, without a  restriction, you'll end up with likely interop issues (e.g., a server sending a single-digit type, and a client choking on it because it's not four-characters wide).

The matching pattern for GeneralizedTimeType is curious. If you're trying to enforce zulu timezone, I would expect it to simply be ".*Z". If you want to enforce the rest of the string for some reason, I'd expect more of the datetime formulation than the last two digits.

It would be nice to include an example XML-format PAL object.

The row in the table in section 1.6 talking about PCKS#12 key generation indicates that the content-type can be either pkcs10 or pkcs12. Is that intentional?

Ben already touched on this lightly, but I'll state it more concretely: for the PAL, you either need an MTI (JSON or XML) for both clients and servers, or you need to specify that one is required to do both. I suggest that servers (at least, servers that *do* support PAL) are required to do both, and clients can do either.

Tiny nits:

Please expand TAMP on first use (in section 1)

The citation at the top of section 1.6 ("FTP and HTTP [RFC2585]") is confusing, as you're not citing either FTP or HTTP, but a document that discusses their use. Suggest rephrasing to make clear what you're referring to.

Is there some rationale for having a minimum date specified in the XML schema? If so, please include it.

[Ballot discuss]
I am generally fine with publishing this document, but there are several issues (mostly related to HTTP use) which need to be addressed before the document goes forward:

1)  Every time you say in the document "HTTP 200 response code with no content" you should reference HTTP 204 response code , as it means no content.

(We discussed this and proposed text work for me.)

2) As far as I know Content-Transfer-Encoding header field is not used in HTTP. You can use transfer coding or content coding instead (See ). But either way "base64" encoding is not defined in HTTP, so you can't use it.

Mark Nottingham wrote about this:

-------
CTE escapes into HTTP sometimes because of gateways to other protocols, or because of wrong-headed developers, but it has *NO* HTTP semantics. They can send the header all they want (after all, new headers can be introduced by anyone), but it's not interoperable.

This was widely known enough that we took advice about it out of HTTPbis; see:
  https://tools.ietf.org/html/rfc2616#section-19.4.5

Looks like 7030 needs an errata, at a minimum. They don't want content-encoding (it's not terribly useful to introduce a base64 encoding on a binary-clean transport; they probably want to be using a content-type that dictates base64 encoding. Or just send the binary.
-------

3) In the IANA considerations:

  Package types MUST be paired with a media type.

How? Does the list in Section 2.1.1 provide MIME types (it doesn't seem to)?

(We discussed this and proposed text work for me.)

[Ballot comment]
Please add normative references for the following (on first mention):

DN (Distinguished Name) - I would probably use one of LDAP RFCs for string syntax or maybe RFC 5280.


2.  Locate Available Packages

  To get the /pal PC, the client and server need to mutually
  authenticate each other with TLS and authorize each other.  Clients
  retrieve their PAL and processes it to determine the packages
  available for it.  Clients include the HTTP Accept header [RFC2616]

You should be pointing to [RFC7231] here.

2.1.3.  PAL JSON Object

  The following is an example PAL JSON object.  The fields in the
  object were discussed earlier in Sections 2.1 and 2.1.1.

  [
    {
      "Type": 0003,
      "Date": "2016-12-29T09:28:00Z",
      "Size": 1234,
      "Info": "https://www.example.com/.well-known/est/eecerts/1234"
    }

I know this is a nit, but the above line is missing "," after "}"

    {
      "Type": 0003,
      "Date": "2016-12-29T09:28:00Z",
      "Size": 1234,
      "Info": "https://www.example.com/.well-known/est/eecerts/9876"
    }
  ]


8.3.2.  Server-Side Key Generation Response

  When rejecting a request, the server MUST specify either an HTTP 4xx
  error or an HTTP 5xx error.  If the content-type is not set, the
  response data MUST be a plaintext human-readable error message.

Why not just require use "Content-Type: text/plain"?

Also, you might want to have a look at RFC 7807 and see if this is something you want to use.

[Ballot comment]

The above would have been less annoying if the XML had been wrapped in a / tag.

I'd encourage the author to look at the OpsDir review (https://datatracker.ietf.org/doc/review-turner-est-extensions-08-opsdir-telechat-wu-2017-06-19/) , which has some good comments, especially:
# 3: while I don't think that quotes would help, I *do* find the forward slash in (S1) "simple enrollment with /simpleenroll, rekey/renew with /simplereenroll, etc." to be jarring - suggest "rekey or renew" instead.
(some of the comments in the OpsDir review have already been addressed).


Questions:
Section 1.1.  Definitions
"clients that have a non-electronic air gap" -- I see that the "non-electronic" bit was added in a recent version, but I'm confused as to what it is trying to convey. What is an electronic vs non-electronic airgap? Was this to somehow address concerns about things like bypassing airgaps using audio or something? I'm sure that there was a reason for adding it, but it simply confused me.


Nits:
Section 1. Introduction.
/firmware -- "... a mechanism for the infrastructure to inform the client that a firmware and software updates..." -- s/a//

Section 4.  Distribute CRLs and ARLs
"Providing CRLs at the time of bootstrap would obviate the need for..." -- I'd suggest  "Providing CRLs at the time of bootstrap obviates the need for..."


Note: I previously had a DISCUSS position because the XML seemed to be incorrect. This appears to be a rendering artifact in different PDF viewers - for example, in the OS X Preview app, the opening  after the  doesn't render. This **seems** to be related to this specific document (but is sufficiently weird that I'm not sure), so it may be worth checking the final RFC Ed version for this issue.

[Ballot discuss]
1. The following requirement doesn't seem to do much on its own

  If a symmetric key package (which might be signed) or an encrypted
  key package (which might be signed before and after encryption) is
  digitally signed, the client MUST reject it if the digital signature
  does not validate back to an authorized TA. [S 5.1]

The reason is that an attacker might just strip the signature and then
it would be acceptable. So, I think it needs to somehow be paired
with a way of knowing when things ought to be signed. There is another
instance of this under asymmetric keys.




2. S 1.1.
  Package: An object that contains one or more content types.  There
  are numerous types of packages: Asymmetric Keys, Symmetric Keys,
  Encrypted Keys, CRLs, Public Key Certificate Management, Firmware,
  Public Key Certificates, and TAMP packages.  All of these packages
  are digitally signed and encapsulated in a CMS signed data
  [RFC5652][RFC6268] (except the public key certificates and CRLs that
  are already digitally signed);

Signed using what key?


3. The reasoning for why some things need client auth and others do
not is opaque to me. Like, why does firmware need client auth?

[Ballot comment]
The abstract is kind of hard to follow. It would be useful to have a
more straightforward presentation. E.g.,

  The EST (Enrollment over Secure Transport) protocol defined a Well-
  Known URI (Uniform Resource Identifier): /.well-known/est along with
  a number of other path components that clients use for PKI (Public Key
  Infrastructure) services, namely certificate enrollment (e.g.,
  /simpleenroll).  This document defines a number of other PKI services
  as additional path components, specifically....


The presentation of the PAL model is kind of hard to follow. In
particular, how am I supposed to know that I should provide a return
receipt for some operation. Do I:

(1) see the path in the PAL where I first discover the operation
(2) poll the PAL to see if it shows up with a receipt.

In general, I think a section on overall PAL usage would be helpful,
including covering polling, how to use date and time, etc. It would
also be helpful to indicate where the Info field can have an
indirection and where it cannot, as well as how to use the additional
PAL field (/pal).



S 1.
      /tamp - To control the TAs in client TA databases, servers use
      the /tamp PC to request that clients retrieve a TAMP query,
      update, and adjust packages and clients use the /tamp/return PC
      to return response, confirm, and error. The /tamp and
      /tamp/return PCs are defined in Section 7.

Please provide a ref to TAMP.


S 1.6.
  | Locate Available  | N/A                      | Section 2.2      |
  | Packages          | application/xml or      | Section 2.3      |
  |                    | application/json        |                  |
  |                    | [RFC7303][RFC7159]      |                  |

NIT: You should probably attach these citations to the relevant format.


The whole formatting of this table is pretty crazy, especially the TAMP
sections.





S 3.
  The server need not authenticate or authorize the client for
  distributing an EE certificate because the package contents is

NIT: "contents are"

S 5.1.
  strength with the symmetric key being delivered to the client.  The
  cipher suite use MUST NOT have NULL encryption algorithm as this will

NIT: "suite used"

S 7.2.1.
  As specified in [RFC5934], these content types should be signed.  If
  signed, a signed data encapsulates the TAMP content.

Is this a 2119 SHOULD?


S 8.3.1.
If you use pBE, how does the client know the password

[Ballot discuss]
The XML doesn't seem to validate, and seems to have multiple errors (but it's possible I missed something):
The  tag on line 17 doesn't seem to be terminated (there is a closing tag on line 66, but it is out of place), there is an extra , etc etc.

I finally made it lint clean by doing the following:
diff -Naur orig-schema.xml schema.xml
--- orig-schema.xml 2017-08-01 18:17:34.000000000 -0400
+++ schema.xml 2017-08-01 18:21:09.000000000 -0400
@@ -20,10 +20,10 @@
    Subject Key Identifier, Issuer and Serial Number tuple,
    or URI.
 
-

 
 
+
 
   
      This type defines the Package Availability List (PAL).
@@ -60,10 +60,10 @@
 


- 
+ 
         
         
-     
+
     
     
       


NOTE: I have NO idea if this still means the same thing, all I know is it satisfied the linter :-P

[Ballot comment]
The above would have been less annoying if the XML had been wrapped in a / tag.

I'd encourage the author to look at the OpsDir review (https://datatracker.ietf.org/doc/review-turner-est-extensions-08-opsdir-telechat-wu-2017-06-19/) , which has some good comments, especially:
# 3: while I don't think that quotes would help, I *do* find the forward slash in (S1) "simple enrollment with /simpleenroll, rekey/renew with /simplereenroll, etc." to be jarring - suggest "rekey or renew" instead.
(some of the comments in the OpsDir review have already been addressed).


Questions:
Section 1.1.  Definitions
"clients that have a non-electronic air gap" -- I see that the "non-electronic" bit was added in a recent version, but I'm confused as to what it is trying to convey. What is an electronic vs non-electronic airgap? Was this to somehow address concerns about things like bypassing airgaps using audio or something? I'm sure that there was a reason for adding it, but it simply confused me.


Nits:
Section 1. Introduction.
/firmware -- "... a mechanism for the infrastructure to inform the client that a firmware and software updates..." -- s/a//

Section 4.  Distribute CRLs and ARLs
"Providing CRLs at the time of bootstrap would obviate the need for..." -- I'd suggest  "Providing CRLs at the time of bootstrap obviates the need for..."

[Ballot discuss]
I am planning to refine my DISCUSS/comments, but for now the following major points (they should be easy to address though):

1)  Every time you say in the document "HTTP 200 response code with no content" you should reference HTTP 204 response code , as it means no content.

2) As far as I know Content-Transfer-Encoding header field is not used in HTTP. You can use transfer coding or content coding instead (See ). But either way "base64" encoding is not defined in HTTP, so you can't use it.

3) In the IANA considerations:

  Package types MUST be paired with a media type.

How? Does the list in Section 2.1.1 provide MIME types (it doesn't seem to)?

[Ballot comment]


Please add normative references for the following (on first mention):

application/xml and application/json media types

DN (Distinguished Name) - I would probably use one of LDAP RFCs for string syntax.


2.  Locate Available Packages

  To get the /pal PC, the client and server need to mutually
  authenticate each other with TLS and authorize each other.  Clients
  retrieve their PAL and processes it to determine the packages
  available for it.  Clients include the HTTP Accept header [RFC2616]

You should be pointing to [RFC7231] here.

2.1.3.  PAL JSON Object

  The following is an example PAL JSON object.  The fields in the
  object were discussed earlier in Sections 2.1 and 2.1.1.

  [
    {
      "Type": 0003,
      "Date": "2016-12-29T09:28:00Z",
      "Size": 1234,
      "Info": "https://www.example.com/.well-known/est/eecerts/1234"
    }

I know this is a nit, but the above line is missing "," after "}"

    {
      "Type": 0003,
      "Date": "2016-12-29T09:28:00Z",
      "Size": 1234,
      "Info": "https://www.example.com/.well-known/est/eecerts/9876"
    }
  ]


8.3.2.  Server-Side Key Generation Response

  When rejecting a request, the server MUST specify either an HTTP 4xx
  error or an HTTP 5xx error.  If the content-type is not set, the
  response data MUST be a plaintext human-readable error message.

Why not just require use "Content-Type: text/plain"?

Also, you might want to have a look at RFC 7807 and see if this is something you want to use.

[Ballot discuss]
I am planning to refine my DISCUSS/comments, but for now the following major points (they should be easy to address though):

1)  Every time you say in the document "HTTP 200 response code with no content" you should reference HTTP 204 response code

2) Content-Transfer-Encoding header field is not used in HTTP. base64 encoding is not defined, so you can't use it.

3) In the IANA considerations:

  Package types MUST be paired with a media type.

How? Does the list in Section 2.1.1 provide MIME types (it doesn't seem to)?

[Ballot discuss]
I am planning to refine my DISCUSS/comments, but for now the two major points:

1)  Every time you say in the document "HTTP 200 response code with no content" you should reference HTTP 204 response code

2) Content-Transfer-Encoding header field is not used in HTTP. base64 encoding is not defined, so you can't use it.

3) In the IANA considerations:

  Package types MUST be paired with a media type.

How? Does the list in Section 2.1.1 provide MIME types (it doesn't seem to)?

[Ballot comment]
One high level comment:
The introduction of "/serverkeygen/return" actually seems to warrent an update of RFC7030 to me.

One question:
The shepherd write-up says it was presented in lamps but the chairs did not asks for adoption. Why?

Questions on the IANA section:
- Shouldn't pal be registered in the well-know URI registry?
- Section 11.3 could be clearer. What's the name of the new registry and what fields are needed for registration? Should the media types be listed or how can this requirement be assessed: "Package types MUST be paired with a media type."?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-turner-est-extensions-08.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are three actions which we must complete.

First, section 11.1 requests the registration of a new XML namespace. However, the namespace does not appear to be provided in the text of section 11.1. The text suggests: "This section registers a new XML namespace [XMLNS], "urn:ietf:params:xml:ns:TBD" per the guidelines in [RFC3688]" IANA suspects that the authors did not intend "TBD" to be the name of the namespace.

IANA Question --> Should section 11.1 be revised to reflect a different name for the namespace?

Second, in the schema section of the IETF XML Registry located at:

https://www.iana.org/assignments/xml-registry/

a single schema will be registered as follows:

ID: pal
URI: urn:ietf:params:xml:schema:pal
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

Because this registry requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

Third, a new registry is to be created called the PAL Package Types registry.

IANA QUESTION -> Where should this new registry be located? Is it a new registry on the list of all IANA maintained protocol parameter registries or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained?

The new registry will be maintained via Expert Review as defined by RFC 5226.

There are initial registrations in the new registry as follows:

Package Package Description
Number Reference
-------- --------------------------------------------------- ---------------------
0000: Reserved [ RFC-to-be ]
0001: Additional PAL value present [ RFC-to-be ]
0002: X.509 CA certificate [ RFC-to-be ]
0003: X.509 EE certificate [ RFC-to-be ]
0004: X.509 ARL [ RFC-to-be ]
0005: X.509 CRL [ RFC-to-be ]
0006: Start DS certificate enrollment with CSR attribute [ RFC-to-be ]
0007: Start DS certificate enrollment [ RFC-to-be ]
0008: DS certificate enrollment (success) [ RFC-to-be ]
0009: DS certificate enrollment (failure) [ RFC-to-be ]
0010: Start DS certificate re-enrollment [ RFC-to-be ]
0011: DS certificate re-enrollment (success) [ RFC-to-be ]
0012: DS certificate re-enrollment (failure) [ RFC-to-be ]
0013: Start KE certificate enrollment with CSR attribute [ RFC-to-be ]
0014: Start KE certificate enrollment [ RFC-to-be ]
0015: KE certificate enrollment (success) [ RFC-to-be ]
0016: KE certificate enrollment (failure) [ RFC-to-be ]
0017: Start KE certificate re-enrollment [ RFC-to-be ]
0018: KE certificate re-enrollment (success) [ RFC-to-be ]
0019: KE certificate re-enrollment (failure) [ RFC-to-be ]
0020: Asymmetric Key Package (PKCS#8) [ RFC-to-be ]
0021: Asymmetric Key Package (CMS) [ RFC-to-be ]
0022: Asymmetric Key Package (PKCS#12) [ RFC-to-be ]
0023: Asymmetric Key Package Receipt or Error [ RFC-to-be ]
0024: Symmetric Key Package [ RFC-to-be ]
0025: Symmetric Key Package Receipt or Error [ RFC-to-be ]
0026: Firmware Package [ RFC-to-be ]
0027: Firmware Package Receipt or Error [ RFC-to-be ]
0028: TAMP Status Query [ RFC-to-be ]
0029: TAMP Status Query Response or Error [ RFC-to-be ]
0030: Trust Anchor Update [ RFC-to-be ]
0031: Trust Anchor Update Confirm or Error [ RFC-to-be ]
0032: Apex Trust Anchor Update [ RFC-to-be ]
0033: Apex Trust Anchor Update Confirm or Error [ RFC-to-be ]
0034: Community Update [ RFC-to-be ]
0035: Community Update Confirm or Error [ RFC-to-be ]
0036: Sequence Number Adjust [ RFC-to-be ]
0037: Sequence Number Adjust Confirm or Error [ RFC-to-be ]

The IANA Services Operator understands that these three actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: Kathleen.Moriarty.ietf@gmail.com, draft-turner-est-extensions@ietf.org, dharkins@lounge.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (EST Extensions) to Proposed Standard


The IESG has received a request from an individual submitter to consider the
following document: - 'EST Extensions'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-07-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-turner-est-extensions/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-turner-est-extensions/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7193: The application/cms Media Type (Informational - IETF stream)
    rfc6268: Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX) (Informational - IETF stream)
    rfc7292: PKCS #12: Personal Information Exchange Syntax v1.1 (Informational - IETF stream)
    rfc5967: The application/pkcs10 Media Type (Informational - IETF stream)