RFC 7030
Enrollment over Secure Transport
RFC 7030: Enrollment over Secure Transport 🎀
Okay bestie, the title block is giving IETF standards track, serious business 💅. Here's the tea:
- Document: RFC 7030, "Enrollment over Secure Transport" 🦋
- Published: October 2013 📅
- Category: Standards Track, ISSN 2070-1721 ✨
- Authors: M. Pritikin, Ed. (Cisco Systems, Inc.), P. Yee, Ed. (AKAYLA, Inc.), and D. Harkins, Ed. (Aruba Networks) 🫶
- Obsoletes / updates: nothing listed in the title block 🙈
Abstract
okay so this doc is all about certificate enrollment for clients, using CMC (Certificate Management over CMS) messages sent over a secure transport 🔐. It's called Enrollment over Secure Transport (EST), and it's a simple but still fully functional certificate management protocol 💖. It's built for PKI clients who need to grab their client certificates plus the CA certificates that go with them 🎀. It also covers both client-generated public/private key pairs and key pairs the CA generates itself 🔑.
Status of This Memo
this one is an Internet Standards Track document 🌈
it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 👑. If you want more on Internet Standards, check Section 2 of RFC 5741 🧚.
info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7030 🍓.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved ✨.
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date 📜. Please actually read those, bestie, because they spell out your rights and restrictions for this document 🙏. Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💜.
Table of Contents
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Operational Scenario Overviews ..................................5
2.1. Obtaining CA Certificates ..................................6
2.2. Initial Enrollment .........................................7
2.2.1. Certificate TLS Authentication ......................8
2.2.2. Certificate-Less TLS Authentication .................8
2.2.3. HTTP-Based Client Authentication ....................8
2.3. Client Certificate Reissuance ..............................8
2.4. Server Key Generation ......................................9
2.5. Full PKI Request Messages ..................................9
2.6. Certificate Signing Request (CSR) Attributes Request .......9
3. Protocol Design and Layering ...................................10
3.1. Application Layer .........................................13
3.2. HTTP Layer ................................................14
3.2.1. HTTP Headers for Control ...........................15
3.2.2. HTTP URIs for Control ..............................16
3.2.3. HTTP-Based Client Authentication ...................17
3.2.4. Message Types ......................................19
3.3. TLS Layer .................................................20
3.3.1. TLS-Based Server Authentication ....................20
3.3.2. TLS-Based Client Authentication ....................21
3.3.3. Certificate-Less TLS Mutual Authentication .........21
3.4. Proof-of-Possession .......................................22
3.5. Linking Identity and POP Information ......................22
3.6. Server Authorization ......................................23
3.6.1. Client Use of Explicit TA Database .................24
3.6.2. Client Use of Implicit TA Database .................24
3.7. Client Authorization ......................................24
4. Protocol Exchange Details ......................................25
4.1. Distribution of CA Certificates ...........................25
4.1.1. Bootstrap Distribution of CA Certificates ..........25
4.1.2. CA Certificates Request ............................26
4.1.3. CA Certificates Response ...........................26
4.2. Client Certificate Request Functions ......................27
4.2.1. Simple Enrollment of Clients .......................28
4.2.2. Simple Re-enrollment of Clients ....................29
4.2.3. Simple Enroll and Re-enroll Response ...............29
4.3. Full CMC ..................................................30
4.3.1. Full CMC Request ...................................30
4.3.2. Full CMC Response ..................................30
4.4. Server-Side Key Generation ................................31
4.4.1. Server-Side Key Generation Request .................32
4.4.1.1. Requests for Symmetric Key
Encryption of the Private Key .............32
4.4.1.2. Requests for Asymmetric Encryption
of the Private Key ........................33
4.4.2. Server-Side Key Generation Response ................33
4.5. CSR Attributes ............................................35
4.5.1. CSR Attributes Request .............................35
4.5.2. CSR Attributes Response ............................35
5. IANA Considerations ............................................37
6. Security Considerations ........................................39
7. References .....................................................41
7.1. Normative References ......................................41
7.2. Informative References ....................................43
Appendix A. Operational Scenario Example Messages .................45
A.1. Obtaining CA Certificates ..................................45
A.2. CSR Attributes .............................................47
A.3. Enroll/Re-enroll ...........................................47
A.4. Server Key Generation ......................................50
Appendix B. Contributors and Acknowledgements .....................521. Introduction ✨
okay so same as the abstract, this doc profiles certificate enrollment for clients using CMC [RFC5272] messages over a secure transport 🔐. EST is how you use Transport Layer Security (TLS) 1.1 [RFC4346], 1.2 [RFC5246], or any future version, together with Hypertext Transfer Protocol (HTTP) [RFC2616], to get an authenticated and authorized channel for Simple PKI Requests and Responses [RFC5272] 💖.
architecturally, the EST service sits between a Certification Authority (CA) and a client 🦋. It handles several jobs that usually belong to the Registration Authority (RA) role in a PKI 👑. How an EST server talks to a CA isn't described here, so that's a separate convo 🙈.
EST borrows the Certificate Management Protocol (CMP) [RFC4210] model for CA certificate rollover, but it does not use the CMP message syntax or protocol 🧚. EST servers are also extensible, so new functions can be defined for capabilities CMC [RFC5272] doesn't cover. This doc defines two of those extensions: one for requesting Certificate Signing Request attributes, and one for requesting server-generated keys 🎀.
EST specifies how to move messages securely over HTTP over TLS (HTTPS) [RFC2818], where the HTTP headers and media types get used together with TLS 🌸. HTTPS runs over TCP, and this document does not specify EST over HTTP/Datagram Transport Layer Security/User Datagram Protocol (HTTP/DTLS/UDP) 🙅. Still, if someone writes a suitable spec for combining HTTP, DTLS, and UDP, there are no EST requirements stopping it from working over that stack 🍓. Figure 1 shows how the layers stack on top of each other 💅.
EST Layering:
Protocols:
+--------------------------------------------+
| |
| EST request/response messages |
| |
+--------------------------------------------+
| |
| HTTP for message transfer and signaling |
| |
+--------------------------------------------+
| |
| TLS for transport security |
| |
+--------------------------------------------+
| |
| TCP for transport |
| |
+--------------------------------------------+
Figure 11.1. Terminology
okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read the way [RFC2119] explains 📖✨
we're assuming you already know the stuff in PKCS #10 [RFC2986], HTTPS [RFC2818], CMP [RFC4210], CMC [RFC5272][RFC5273][RFC5274], and TLS [RFC4346] 🧚
on top of the terms from the CMC terminology section [RFC5272], we're adding a few more so everyone's on the same page 💜
EST CA: for certificate issuing services, the EST CA is reached through the EST server. The CA could be logically "behind" the EST server or embedded within it. 🏰
Third-Party Trust Anchor: any trust anchor (TA) that isn't authoritative for the PKI hierarchy the EST server is serving. 🙅♀️
Explicit Trust Anchor: any TA that's explicitly configured on the client or server for use during EST TLS authentication. Like, a TA that's manually configured on the EST client, or bootstrapped as described in Section 4.1.1. (See more details in Sections 3.6 and 6.) 🎀
Implicit Trust Anchor: any third-party TA that's available on the client or server for use during TLS authentication but isn't specifically indicated for use during EST TLS authentication. Think TAs that web browsers use to check web servers, or TAs servers use to authenticate manufacturer-installed client credentials (like certificates loaded into cable modems or routers at the factory). The authorization model for these TAs is different from the one for Explicit Trust Anchors. (See more details in Sections 3.6.1, 3.6.2, and 6). 🌸
Certificate-Less TLS: certificate-less TLS cipher suites give you a way to do mutual authentication when neither the client nor the server has certificates, or they just don't want to use them. The credential is a word, phrase, code, or key shared between the client and server. It must be uniquely shared between them so that an individual client can be authenticated to an individual server. 🔑
2. Operational Scenario Overviews ✨
this section is an informative overview of the operational scenarios, to ease you into the protocol talk 🦋
both the EST clients and the server are configured with info that's the basis for mutual authentication and authorization. The specific initialization data depends on what methods the client and server have, but it can include shared secrets, network service names and locations (e.g., a Uniform Resource Identifier (URI) [RFC3986]), trust anchor info (e.g., a CA certificate or a hash of a TA's certificate), and enrollment keys and certificates. Depending on an enterprise's acquisition and network management practices, the vendor might do some initialization before the client hardware and software get delivered. In that case, the client vendor may hand over data, like trust anchors, to the enterprise through a secure procedure. How that initial info gets distributed is out of scope, bestie 🙈
distributing trust anchors and other certificates can happen through the EST server. However, nothing can be inferred about how authentic this data is until an out-of-band mechanism is used to verify it. 🕵️♀️
Sections 2.1-2.3 very closely mirror the text of the Scenarios Appendix of [RFC6403], with whatever changes make sense for this profile. Sections 2.1-2.6, below, list out the set of EST functions (see Figure 5) and give an informative overview of EST's capabilities. 💅
the general client/server interaction goes like this:
- the client starts a TLS-secured HTTP session with an EST server. 🔐
- a specific EST service gets requested based on a portion of the URI used for the session. 🎯
- the client and server authenticate each other. 🤝
- the client verifies that the server is authorized to serve this client. ✅
- the server verifies that the client is authorized to use this server and the request the client made. 👀
- the server acts on the client request. 👑
2.1. Obtaining CA Certificates
the EST client can ask the EST server for a copy of the current EST CA certificate(s). The EST client is assumed to do this before doing anything else. 🌈
throughout this document we assume the EST CA has a certificate that the client uses to verify signed objects the CA issues, e.g., certificates and certificate revocation lists (CRLs). We also assume that a different certificate from the one used to verify signatures on certificates and CRLs is used when EST protocol communication needs extra encryption. 🧁
the EST client authenticates and verifies the authorization scope of the EST server when requesting the current CA certificate(s). As detailed in Sections 3.3.1 and 3.3.3, the options are:
- verifying the EST server's HTTPS URI against the EST server's certificate using Implicit TAs (similar to a common HTTPS exchange). This lets the EST server and client lean on existing TAs that the EST client might already know. 🫶
- the client can use a previously distributed trust anchor specific to the EST server. This lets the EST client use an existing, possibly older, CA certificate to request a current CA certificate. ⏳
- for bootstrapping, the EST client can rely on manual authentication performed by the end-user, as detailed in Section 4.1.1. 🙋♀️
- the client can use the binding of a shared credential to a specific EST server with a certificate-less TLS cipher suite. 🔗
client authentication isn't required for this exchange, so the EST server trivially supports it. 😌
2.2. Initial Enrollment
after authenticating an EST server and verifying it's authorized to provide services to the client, an EST client can get a certificate for itself by submitting an enrollment request to that server. 📝
the EST server authenticates and authorizes the EST client as specified in Sections 3.3.2, 3.3.3, and 3.7. The methods described in the normative text that are discussed in this overview include:
- TLS with a previously issued client certificate (e.g., an existing certificate issued by the EST CA); 🪪
- TLS with a previously installed certificate (e.g., a manufacturer-installed certificate or a certificate issued by some other party); 🏭
- certificate-less TLS (e.g., with a shared credential distributed out-of-band); 🤫
- HTTP-based with a username/password distributed out-of-band. 🔐
2.2.1. Certificate TLS Authentication
if the EST client has a previously installed certificate issued by a third-party CA, that certificate can be used to authenticate the client's request for a certificate from the EST server (as long as that CA is recognized by the EST server). An EST client answers the EST server's TLS certificate request message with the existing certificate it already holds. The EST server will verify the client's existing certificate and authorize the client's request as described in Section 3.3.2. 🎟️
2.2.2. Certificate-Less TLS Authentication
the EST client and EST server can be mutually authenticated using a certificate-less TLS cipher suite (see Section 3.3.3). 🧩
2.2.3. HTTP-Based Client Authentication
the EST server can optionally also ask the EST client to submit a username/password using the HTTP Basic or Digest authentication methods (see Section 3.2.3). This approach is desirable if the EST client can't be authenticated during the TLS handshake (see Section 3.3.2), or if the EST server policy requires additional authentication info; see Section 3.2.3. In all cases, HTTP-based client authentication is only to be performed over a TLS-protected transport (see Section 3.3). 🛡️
2.3. Client Certificate Reissuance
an EST client can renew/rekey its existing client certificate by submitting a re-enrollment request to an EST server. 🔄
when the current EST client certificate can be used for TLS client authentication (Section 3.3.2), the client presents this certificate to the EST server for client authentication. When the to-be-reissued EST client certificate can't be used for TLS client authentication, any of the authentication methods used for initial enrollment can be used instead. 🪄
for example, if the client has an alternative certificate issued by the EST CA that can be used for TLS client authentication, then it can be used. 💡
the certificate request message includes the same Subject and SubjectAltName as the current certificate. Name changes are requested as specified in Section 4.2.2. ✍️
2.4. Server Key Generation
the EST client can request a server-generated certificate and key pair (see Section 4.4). 🗝️
2.5. Full PKI Request Messages
Full PKI Request [RFC5272] messages can be transported via EST using the Full CMC Request function. This gives access to functions the Simple Enrollment functions don't provide. Full PKI Request messages are defined in Sections 3.2 and 4.2 of [RFC5272]. See Section 4.3 for how EST provides a transport for these messages. 🚚
2.6. Certificate Signing Request (CSR) Attributes Request
before sending an enrollment request to an EST server, an EST client can ask the EST server for a set of additional attributes that the client is requested to use in a later enrollment request. 📋
these attributes can give extra descriptive info that the EST server can't get on its own, like the Media Access Control (MAC) address of an interface on the EST client. Or, these attributes can indicate the kind of enrollment request, like a specific elliptic curve or a specific hash function the client is expected to use when generating the CSR. 🧠✨
3. Protocol Design and Layering ✨
Okay bestie, Figure 2 is basically the zoomed-in version of Figure 1 🔍 It shows how each layer actually gets used, and every piece gets its own deeper dive in the sections that follow. Let's gooo 🚀
EST Layering:
Protocols and uses:
+----------------------------------------------------+
| |
| Message types: |
| - "Simple PKI" messages |
| (incorporates proof-of-possession) |
| - CA certificate retrieval |
| - "Full PKI" messages (OPTIONAL) |
| (incorporates proof-of-possession) |
| - CSR Attributes Request (OPTIONAL) |
| - Server-generated key request (OPTIONAL) |
| |
+----------------------------------------------------+
| |
| HTTP: |
| - HTTP headers and URIs for control |
| - Content-Type headers specify message type |
| - Headers for control/error messages |
| - URIs for selecting functions |
| - Basic or Digest authentication (OPTIONAL) |
| |
+----------------------------------------------------+
| |
| TLS for transport security: |
| - Authentication of the EST server |
| - Authentication of the EST client (OPTIONAL) |
| - Provides communications integrity |
| and confidentiality |
| - Supplies channel-binding [RFC5929] information |
| to link proof-of-identity with message-based |
| proof-of-possession (OPTIONAL) |
| |
+----------------------------------------------------+
Figure 2Specifying HTTPS as the secure transport for enrollment messages gives us two "layers" for the auth and control stuff: TLS and HTTP 💅
TLS handles integrity and confidentiality during transport 🔐 Proof-of-identity comes from the TLS handshake authentication, and optionally from the HTTP layer headers too. The message type and the control/error messages ride along in the HTTP headers 🎀
CMC ([RFC5272], Section 3.1) says that "the Simple PKI Request MUST NOT be used if a proof-of-identity needs to be included". So since TLS and HTTP can handle proof-of-identity for both EST clients and servers, we use the Simple PKI message types 🙈
The TLS layer certificate exchange is how we authorize enrollment requests using certs that already exist 🪪 Those certs might come from the CA the client is asking for a cert from, or from a totally separate PKI, like an IEEE 802.1AR Initial Device Identifier (IDevID) [IDevID] credential 🧚
Proof-of-possession (POP) is its own thing, separate from proof-of-identity 🦋 It goes in the Simple PKI message type, as described in Section 3.4. Linking proof-of-identity and proof-of-possession is covered in Section 3.5.
This doc also defines transport for CMC [RFC5272] that complies with the CMC Transport Protocols [RFC5273] 🌈 CMC has its own POP and proof-of-identity mechanisms, but the ones here can also be used alongside them in "Full PKI" messages.
Different certs can show up during protocol exchanges 📜 The tables below are an informative overview. End-entities can have one or more certs of each type in Figure 3, and use one or more trust anchor databases of each type in Figure 4.
Certificates and their corresponding uses:
+--------------+--------------------+-------------------------------+
| Certificate | Issuer | Use and section references |
+==============+====================+===============================+
| EST server | The CA served by | Presented by the EST server |
| certificate | the EST server | during the TLS handshake. |
| | | |
| | | Section 3.3.1 |
+--------------+--------------------+-------------------------------+
| EST server | A CA | Presented by the EST server |
| certificate | authenticatable by | during the TLS handshake. |
| | a third-party TA, | |
| | e.g., a web server | Section 3.3.1 and |
| | CA | Security Considerations |
+--------------+--------------------+-------------------------------+
| Third-party | A CA | Presented by the EST client |
| EST client | authenticatable by | to the EST server by clients |
| certificate | a third-party TA, | that have not yet enrolled. |
| | e.g., a device | |
| | manufacturer | Section 3.3.2 |
+--------------+--------------------+-------------------------------+
| EST client | The CA served by | Presented to the EST server |
| certificate | the EST server | during future EST operations. |
| | | |
| | | Section 3.3.2 |
+--------------+--------------------+-------------------------------+
| End-entity | The CA served by | Clients can obtain certs |
| certificate | the EST server | that are intended for |
| | | non-EST uses. This includes |
| | | certs that cannot be used |
| | | for EST operations. |
| | | |
| | | Section 4.2.3 |
+--------------+--------------------+-------------------------------+
Figure 3Trust anchor databases and their corresponding uses:
+--------------+----------------------------------------------------+
| TA database | Use and section references |
+==============+====================================================+
| EST server | EST servers use this TA database to authenticate |
| Explicit | certificates issued by the EST CA, including EST |
| TA database | client certificates during enroll/re-enroll |
| | operations. |
| | |
| | Section 3.3.2 |
+--------------+----------------------------------------------------+
| EST server | EST servers use this TA database to authenticate |
| Implicit | certificates issued by third-party TAs; |
| TA database | e.g., EST client certificates issued by a device |
| | manufacturer. |
| | An Implicit TA database can be disabled. |
| | |
| | Section 3.3.2 |
+--------------+----------------------------------------------------+
| EST client | EST clients use this TA database to authenticate |
| Explicit | certificates issued by the EST CA, including EST |
| TA database | server certificates. |
| | |
| | Sections 3.1, 3.3.1, 3.6.1, and 4.1.1 |
+--------------+----------------------------------------------------+
| EST client | EST clients use this TA database to |
| Implicit | authenticate an EST server that uses an externally |
| TA database | issued certificate. |
| | An Implicit TA database can be disabled. |
| | |
| | Sections 3.1, 3.3.1, 3.6.2, and |
| | Security Considerations |
+--------------+----------------------------------------------------+
Figure 43.1. Application Layer
The EST client MUST be capable of generating and parsing Simple PKI messages (see Section 4.2). Generating and parsing Full PKI messages is OPTIONAL (see Section 4.3). The client MUST also be able to request CA certificates from the EST server and parse the returned "bag" of certificates (see Section 4.1). Requesting CSR attributes and parsing the returned list of attributes is OPTIONAL (see Section 4.5). 🎀
Okay so the client app config is technically out of scope for the protocol talk, but it's still super important for knowing what you need before you start any operations 🧠
The EST client is RECOMMENDED to be set up with TA databases for Section 3.3.1 or with a secret key for Section 3.3.3. Implementations that follow this standard MUST let you designate Explicit TAs 👑 For human usability reasons, a "fingerprint" of an Explicit TA database entry can be configured for bootstrapping, as discussed in Section 4.1.1 🫶
Configuring an Implicit TA database (maybe by bundling it in the EST client distribution, or grabbing it from the operating system) gives you flexibility, but it comes with the caveats in Section 6 ⚠️ Implementations that follow this standard MUST let you disable use of any Implicit TA database 💀
The EST client gets enough info to build the EST server URI. That can be the full operation path segment, like https://www.example.com/.well-known/est/ or https://www.example.com/.well-known/est/arbitraryLabel1. Or the client can be configured with a tuple made of the authority portion of the URI plus the OPTIONAL label (like "www.example.com:80" and "arbitraryLabel1"), or with just the authority portion of the URI 🌸
3.2. HTTP Layer
HTTP is what carries EST messages around 🦋 URIs are defined for handling each media type (aka each message type), as described in Section 3.2.2. HTTP also handles client authentication when TLS client authentication isn't an option, because the client doesn't have a certificate that TLS can use (see Section 3.2.3). HTTP auth can also be layered on top of TLS client auth if the EST server wants extra auth info, as noted in Section 2.2.3. Registered media types are used to convey EST messages, as specified in Figure 6 💜
HTTP 1.1 [RFC2616] and above support persistent connections ✨ As described in Section 8.1 of RFC 2616, persistent connections may be used to cut down on the network and processing load from lots of HTTP requests. EST doesn't require persistent HTTP connections, and it doesn't rule them out either 🌈
3.2.1. HTTP Headers for Control
okay so the HTTP Status value is how everyone finds out if an EST function actually worked 💅✨. And HTTP authentication is what the client uses whenever the server asks for it 🔐.
The media type in the HTTP Content-Type header tells you which EST message is being sent 🎀. You can find the EST media types in Section 3.2.4 🦋.
Now redirects (3xx status codes) to the same web origin (see [RFC6454]) SHOULD be handled by the client without bugging the user 🙈, as long as every applicable security check (Sections 3.3 and 3.6) was already enforced on the first connection. The client opens a new TLS connection and runs all the applicable security checks when it gets redirected to other web origin servers 🔒. Redirects to other web origins are a different story: the EST client needs user input for any non-GET or HEAD requests, as specified in [RFC2616] 👀.
There's one more wrinkle 🧶. If the client already made a CSR that includes linking identity and POP information (Section 3.5), that CSR has to be recreated to bring in the tls-unique from the new, redirected session. The key pair doesn't need to be regenerated though, so that's a relief 💜. Still, these are processing and interface burdens on the client, so EST server admins are advised to keep that in mind 🫶.
3.2.2. HTTP URIs for Control
okay this part is so important 🥺. The EST server MUST support the path-prefix of /.well-known/ as defined in [RFC5785], with the registered name of est. So a valid EST server URI path starts with https://www.example.com/.well-known/est 🌸. Each EST operation gets its own path-suffix that says what it's for 🧚:
+------------------------+-----------------+-------------------+
| Operation |Operation path | Details |
+========================+=================+===================+
| Distribution of CA | /cacerts | Section 4.1 |
| Certificates (MUST) | | |
+------------------------+-----------------+-------------------+
| Enrollment of | /simpleenroll | Section 4.2 |
| Clients (MUST) | | |
+------------------------+-----------------+-------------------+
| Re-enrollment of | /simplereenroll | Section 4.2.2 |
| Clients (MUST) | | |
+------------------------+-----------------+-------------------+
| Full CMC (OPTIONAL) | /fullcmc | Section 4.3 |
+------------------------+-----------------+-------------------+
| Server-Side Key | /serverkeygen | Section 4.4 |
| Generation (OPTIONAL) | | |
+------------------------+-----------------+-------------------+
| CSR Attributes | /csrattrs | Section 4.5 |
| (OPTIONAL) | | |
+------------------------+-----------------+-------------------+Figure 5
So you take that operation path from Figure 5 and tack it onto the path-prefix to get the URI you use with HTTP GET or POST 🚀. For example, a valid URI absolute path for the /cacerts operation is /.well-known/est/cacerts. To grab the CA's certificates, the EST client sends this request-line:
GET /.well-known/est/cacerts HTTP/1.1And to request a new certificate in this example, the EST client uses this request-line:
POST /.well-known/est/simpleenroll HTTP/1.1Using distinct operation paths makes life easier for servers that don't do client authentication when they're handing out /cacerts responses 🧁.
Here's the multi-CA part 🌈. An EST server MAY serve multiple CAs, using an OPTIONAL extra path segment between the registered application name and the operation path. To avoid mix-ups, the CA label MUST NOT be the same as any defined operation path segment ⚠️. The EST server MUST provide services whether or not that extra path segment is there. Here are three valid example URIs:
https://www.example.com/.well-known/est/cacertshttps://www.example.com/.well-known/est/arbitraryLabel1/cacertshttps://www.example.com/.well-known/est/arbitraryLabel2/cacerts
In this spec, enroll and renew/rekey are told apart explicitly by the HTTP URI 🎯. When you make /fullcmc requests, CMC [RFC5272] uses the same messages for certificate renewal and certificate rekey 💜.
An EST server can also offer extra services at other URIs ✨.
3.2.3. HTTP-Based Client Authentication
the EST server MAY ask for HTTP-based client authentication 🙋♀️. This can happen on top of a successful TLS client authentication (Section 3.3.2), if the EST server policy needs extra authentication. (Like, the server might want the EST client to "know" a password and "have" an existing client certificate 🔑.) Or HTTP-based client authentication can be the fallback the server policy specifies, for when the EST client didn't manage to complete TLS client authentication 🫣. That might happen if the client is enrolling for the first time, or if the certificates it has can't be used for TLS client authentication.
Now the security stuff 🛡️, and it's serious. HTTP Basic and Digest authentication MUST only be performed over TLS 1.1 [RFC4346] or later versions. NULL and anon cipher suites MUST NOT be used, because they don't give confidentiality, or they don't support mutual certificate-based or certificate-less authentication, respectively 🚫. As [RFC5273] puts it in "Certificate Management over CMS (CMC): Transport Protocols", the server "MUST NOT assume client support for any type of HTTP authentication such as cookies, Basic authentication, or Digest authentication". Clients SHOULD support the Basic and Digest authentication mechanism 💅.
If a server wants to use Basic and Digest authentication, it rejects the HTTP request using the HTTP-defined WWW-Authenticate response-header ([RFC2616], Section 14.47) 🙅♀️. The client is expected to retry the request, with the right Authorization Request header ([RFC2617], Section 3.2.2), if it can do Basic or Digest authentication 🔁. If the client can't retry the request, or it can't do Basic or Digest authentication, then the client MUST terminate the connection 💀.
A client MAY set the username to the empty string ("") if it's presenting a password that isn't tied to a username 🤷♀️.
Heads up 🚨: supporting HTTP-based client authentication has security ramifications, which are discussed in Section 6. The client MUST NOT respond to the server's HTTP authentication request unless it has authorized the EST server (as per Section 3.6). No responding to strangers, bestie 🙅♀️.
3.2.4. Message Types
This document uses media types that already exist for its messages, as specified by FTP and HTTP [RFC2585], application/pkcs10 [RFC5967], and CMC [RFC5272] 📬. For consistency with [RFC5273], each distinct EST message type uses an HTTP Content-Type header with a specific media type 🎀. Here's the full lineup of EST messages and their media types for each operation 👑:
+--------------------+--------------------------+-------------------+
| Message type | Request media type | Request section(s)|
| | Response media type(s) | Response section |
| (per operation) | Source(s) of types | |
+====================+==========================+===================+
| Distribution of CA | N/A | Section 4.1 |
| Certificates | application/pkcs7-mime | Section 4.1.1 |
| | [RFC5751] | |
| /cacerts | | |
+--------------------+--------------------------+-------------------+
| Client Certificate | application/pkcs10 | Sections 4.2/4.2.1|
| Request Functions | application/pkcs7-mime | Section 4.2.2 |
| | [RFC5967] [RFC5751] | |
| /simpleenroll | | |
| /simplereenroll | | |
+--------------------+--------------------------+-------------------+
| Full CMC | application/pkcs7-mime | Section 4.3.1 |
| | application/pkcs7-mime | Section 4.3.2 |
| /fullcmc | [RFC5751] | |
+--------------------+--------------------------+-------------------+
| Server-Side Key | application/pkcs10 | Section 4.4.1 |
| Generation | multipart/mixed | Section 4.4.2 |
| | (application/pkcs7-mime &| |
| | application/pkcs8) | |
| | [RFC5967] [RFC5751] | |
| /serverkeygen | [RFC5958] | |
+--------------------+--------------------------+-------------------+
| CSR Attributes | N/A | Section 4.5.1 |
| | application/csrattrs | Section 4.5.2 |
| | (This document) | |
| /csrattrs | | |
+--------------------+--------------------------+-------------------+Figure 6
3.3. TLS Layer
okay TLS is the thing that gives you authentication, and authentication is what lets you make authorization decisions 🔐✨. The EST server and EST client both have to make sure an acceptable cipher suite gets negotiated and that mutual authentication actually happens 🤝. TLS authentication is mostly done with certificates [RFC5280]. But certificate-less TLS authentication, where neither the client nor the server presents a certificate, is also an acceptable way to do EST mutual authentication (Section 3.3.3) 🦋. The EST server MUST be authenticated during the TLS handshake, unless the client is requesting Bootstrap Distribution of CA certificates (Section 4.1.1) or Full CMC (Section 4.3) 🫶.
HTTPS [RFC2818] is how HTTP messages get carried over TLS 💖. HTTPS MUST be used. TLS 1.1 [RFC4346] (or a later version) MUST be used for all EST communications 🔒. TLS session resumption [RFC5077] SHOULD be supported 🌸.
TLS channel-binding information can go into a certificate request, as detailed in Section 3.5 🎀. That gives the EST server assurance that the authenticated TLS client really has access to the private key for the certificate being requested 🗝️. The EST server MUST implement Section 3.5 👑.
3.3.1. TLS-Based Server Authentication ✨
Okay so, TLS server authentication with certificates MUST be supported. No cap, this one is non-negotiable bestie 💅
The EST client authenticates the EST server as defined for the cipher suite negotiated. 🎀 The following text gives the details assuming a certificate-based cipher suite, like the TLS 1.1 [RFC4346] mandatory cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA).
Certificate validation MUST be performed as per [RFC5280]. 💖 The EST server certificate MUST conform to the [RFC5280] certificate profile. Slay the paperwork 📜
The client validates the TLS server certificate using the EST client Explicit and, if enabled, Implicit TA database(s). 🦋 The client MUST maintain a distinction between the use of Explicit and Implicit TA databases during authentication, so that proper authorization can happen. Main character energy for the trust stores 👑 The EST client MUST perform authorization checks as specified in Section 3.6.
If certificate validation fails, the client MAY follow the procedure outlined in Section 4.1.1 for Bootstrap Distribution of CA certificates. 🌸 Not me needing a backup plan, but it's allowed 🙈
3.3.2. TLS-Based Client Authentication 🧚
Okay this one is so iconic. TLS client authentication is the RECOMMENDED method for identifying EST clients. ✨ HTTP-based client authentication (Section 3.2.3) MAY be used too.
The EST server authenticates the EST client as defined for the cipher suite negotiated. Again, the text assumes a certificate-based cipher suite such as the TLS 1.1 [RFC4346] mandatory cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA). The EST server MUST support certificate-based client authentication. 🫶
Generally, the client uses an existing certificate for renew or rekey operations. If the certificate being renewed or rekeyed is appropriate for the negotiated cipher suite, then the client MUST use it for the TLS handshake. Otherwise the client SHOULD use an alternate certificate that is suitable for the cipher suite and contains the same subject identity information. 💅 When requesting an enroll operation, the client MAY use a client certificate issued by a third party to authenticate itself. Lowkey a power move 🔥
Certificate validation MUST be performed as per [RFC5280]. The EST client certificate MUST conform to the [RFC5280] certificate profile. 📜✨
The server validates the TLS client certificate using the EST server Explicit and, if enabled, Implicit TA database(s). 🌈 The server MUST maintain a distinction between the use of Explicit and Implicit TA databases during authentication, so proper authorization is possible. Keep those trust stores separated, periodt 💜
The EST server MUST perform authorization checks as specified in Section 3.7.
If a client does not support TLS client authentication, then it MUST support HTTP-based client authentication (Section 3.2.3) or certificate-less TLS authentication (Section 3.3.3). No exceptions, bestie 🙈
3.3.3. Certificate-Less TLS Mutual Authentication 🦋
Certificate-less TLS cipher suites give you a way to do mutual authentication when neither the client nor the server has certificates, when they don't want to use certificates, or when they don't have the trust anchors needed to verify one. 🌸 The client and server MAY negotiate a certificate-less cipher suite for mutual authentication. ✨
When using certificate-less mutual authentication in TLS for enrollment, the cipher suite MUST be based on a protocol that is resistant to dictionary attack, and MUST be based on a zero knowledge protocol. 🔥 The TLS-SRP cipher suites, meaning the ones with _SRP_ in the name listed in Section 2.7 of [RFC5054], are suitable for this purpose. Section 6 lists the characteristics of a cipher suite that are suitable for certificate-less mutual authentication for enrollment. 🧚
Successful authentication using a certificate-less cipher suite proves knowledge of a pre-shared secret, and that implicitly authorizes a peer in the exchange. 💖
3.4. Proof-of-Possession 💜
As defined in Section 2.1 of CMC [RFC5272], proof-of-possession (POP) "refers to a value that can be used to prove that the private key corresponding to the public key is in the possession of and can be used by an end-entity". 🔑 Very official, very dramatic, I love it 😭
The signed enrollment request provides a signature-based proof-of-possession. ✨ The mechanism described in Section 3.5 strengthens this by optionally including "Direct"-based proof-of-possession [RFC5272], which means putting TLS session-specific information inside the data covered by the enrollment request signature. That links the enrollment request to the authenticated endpoint of the TLS connection. Iykyk, and now you do too 🫶
3.5. Linking Identity and POP Information 🎀
Server policy decides whether clients are required to use the mechanism in this section. This spec gives a method for linking identity and proof-of-possession by including information specific to the current authenticated TLS session inside the signed certification request. 🦋 Clients can figure out whether the server requires this by looking at the CSR Attributes Response (see Section 4.5.2). Regardless of the CSR Attributes Response, clients SHOULD link identity and POP by embedding tls-unique information in the certification request. 💅 If the client includes tls-unique information, the server MUST verify it. The EST server MAY reject requests without tls-unique information, as indicated by server policy.
Linking identity and proof-of-possession proves to the server that the authenticated TLS client has possession of the private key associated with the certification request, and that the client was able to sign the certification request after the TLS session was established. 👑 This is an alternative to the "Linking Identity and POP Information" method defined by Section 6 of [RFC5272], and it's available when Full PKI messages are used. 🌈
The client generating the CSR gets the tls-unique value from the TLS subsystem, as described in Channel Bindings for TLS [RFC5929]. ✨ The EST client operations between obtaining the tls-unique value, through generating the CSR that contains the current tls-unique value, and the later verification of that value by the EST server are the "phases of the application protocol during which application-layer authentication occurs". These operations are protected by the synchronization interoperability mechanism described in the "Channel Bindings for TLS" interoperability notes in Section 3.1 of [RFC5929]. 🧚 Very detailed, very sis, very correct.
When performing renegotiation, TLS "secure_renegotiation" [RFC5746] MUST be used. 🔥
The tls-unique value is base64 encoded as specified in Section 4 of [RFC4648], and the resulting string goes in the certification request challenge-password field ([RFC2985], Section 5.4.1). The challenge-password field is limited to 255 bytes (Section 7.4.9 of [RFC5246] indicates that no existing cipher suite would cause an issue with this limit). 💖 If the challenge-password attribute is absent, the client did not include the optional channel-binding information. The presence of the challenge-password attribute is what signals that tls-unique information is included. 🌸
If the EST server uses a back-end infrastructure for processing, it is RECOMMENDED that the results of this verification be communicated. 🫶 For example, this communication might use the CMC [RFC5272] "RA POP Witness Control" in a CMC Full PKI Request message. Or an EST server might TLS-authenticate an EST client as being a trusted infrastructure element that doesn't forward invalid requests. A detailed discussion of back-end processing is out of scope. 🙈
When rejecting requests, the EST server response is as described for all enroll responses (Section 4.2.3). If a Full PKI Response is included, the CMCFailInfo MUST be set to popFailed. 💀 If a human-readable reject message is included, it SHOULD include an informative text message saying that linking identity and POP information is required. 🍓
3.6. Server Authorization 🌸
The client MUST check EST server authorization before accepting any server responses or responding to HTTP authentication requests. Non-negotiable, bestie 💅
The EST client's authorization method depends on which method was used to authenticate the server. When the Explicit TA database is used to authenticate the EST server, Section 3.6.1 applies. When the Implicit TA database is used to authenticate the EST server, Section 3.6.2 applies. Successful authentication using a certificate-less cipher suite implies authorization of the server. 🦋
The client MAY perform bootstrapping as specified in Section 4.1.1 even if these checks fail. 🧚
3.6.1. Client Use of Explicit TA Database ✨
When the EST client Explicit TA database is used to validate the EST server certificate, the client MUST check either the configured URI or the most recent HTTP redirection URI against the server's identity according to the rules in [RFC6125], Section 6.4. Alternatively, the EST server certificate MUST contain the id-kp-cmcRA [RFC6402] extended key usage extension. 👑
3.6.2. Client Use of Implicit TA Database 🌈
When the EST client Implicit TA database is used to validate the EST server certificate, the client MUST check the configured URI and each HTTP redirection URI according to the rules in [RFC6125], Section 6.4. The provisioned URI or the most recent HTTP redirection URI gives the basis for authorization, and the server's authenticated identity confirms it's the authorized server. 💜
3.7. Client Authorization 💖
The decision to issue a certificate to a client is always controlled by local CA policy. The EST server configuration reflects this CA policy. This document doesn't specify any constraints on that policy. 🫶 EST gives the EST server access to each client's authenticated identity (for example, the TLS client's certificate, in addition to any HTTP user authentication credentials) to help implement that policy. ✨
If the client's certificate was issued by the EST CA, and it includes the id-kp-cmcRA [RFC6402] extended key usage extension, then the client is a Registration Authority (RA) as described in [RFC5272] and [RFC6402]. 🔥 In this case, the EST server SHOULD apply authorization policy consistent with an RA client. For example, when handling /simpleenroll requests, the EST server could be configured to accept POP linking information that doesn't match the current TLS session. That's because the authenticated EST client RA has already verified this information when acting as an EST server (as specified in Section 3.5). 🧚 More specific RA mechanisms are available if the EST client uses /fullcmc methods. 🎀
4. Protocol Exchange Details 🦋
Before processing a request, an EST server determines whether the client is authorized to receive the requested services. Likewise, the client determines whether it will make requests to the EST server. 💅 These authorization decisions are described in the next two sections. Assuming both sides of the exchange are authorized, the actual operations are as described in the subsequent sections. ✨
4.1. Distribution of CA Certificates 👑
The EST client can request a copy of the current CA certificates. 🌸 This function is generally performed before other EST functions. Think of it as the warm-up before the main event 💖
4.1.1. Bootstrap Distribution of CA Certificates 🌸
Okay so, it's possible the client wasn't set up with an Implicit TA database that lets it bootstrap-install the Explicit TA database, which is described in Section 4.1.3. 🙈 This section is for minimally configured EST clients that still need a way to fill up their Explicit TA database. ✨
If the EST client application doesn't specify an Explicit TA database or an Implicit TA database, then the initial TLS server authentication and authorization is going to fail 💀. The client MAY provisionally continue the TLS handshake to completion so it can access the /cacerts or /fullcmc method. 🎀 If the EST client keeps going with an unauthenticated connection, the client MUST extract the HTTP content data from the response (Sections 4.1.3 or 4.3.2) and engage a human user to authorize the CA certificate using out-of-band data, like a CA certificate "fingerprint" (for example, a SHA-256 or SHA-512 [SHS] hash on the whole CA certificate). 🔐
In a /fullcmc response, it's the Publish Trust Anchors control (CMC [RFC5272], Section 6.15) inside the Full PKI Response that has to be accepted manually. It's totally on the user to properly verify the TA information, or to provide the "fingerprint" data during configuration that's needed to verify the TA information. No pressure, but this part is on them 🫶.
HTTP authentication requests MUST NOT be responded to if the server has not been authenticated as specified in Section 3.3.1, or if the optional certificate-less authentication is used as specified in Section 3.3.3. Do not skip this one, bestie 🚫
The EST client uses the /cacerts response to set up an Explicit Trust Anchor database for later TLS authentication of the EST server. 🦋 EST clients MUST NOT engage in any other protocol exchange until after the /cacerts response has been accepted and a new TLS session has been established (using TLS certificate-based authentication). Main character energy means waiting for the right moment 👑
4.1.2. CA Certificates Request 💌
EST clients ask for the EST CA TA database information of the CA (as certificates) with an HTTPS GET message using the operation path /cacerts. EST clients and servers MUST support the /cacerts function. 💖 Clients SHOULD request an up-to-date response before the stored info expires, so the EST CA TA database stays fresh ✨
The EST server SHOULD NOT require client authentication or authorization to reply to this request. Honestly this should be chill, it's just a read 🍓
The client MUST authenticate the EST server as specified in Section 3.3.1 if certificate-based authentication is used, or Section 3.3.3 if the optional certificate-less authentication is used. It also has to check the server's authorization as given in Section 3.6, or follow the procedure outlined in Section 4.1.1. 🔍
4.1.3. CA Certificates Response 📜
If it works, the server response MUST have an HTTP 200 response code. Any other response code means there's an error, and the client MUST abort the protocol. 🚨
A successful response MUST be a certs-only CMC Simple PKI Response, as defined in [RFC5272], containing the certificates described in the next paragraph. The HTTP content-type of application/pkcs7-mime is used. The Simple PKI Response is sent with a Content-Transfer-Encoding of base64 [RFC2045]. 🧚
The EST server MUST include the current root CA certificate in the response. The EST server MUST also include any additional certificates the client would need to build a chain from an EST CA-issued certificate to the current EST CA TA. For example, if the EST CA is a subordinate CA, then all the appropriate subordinate CA certificates needed to build a chain to the root EST CA are included in the response. 🌈
The EST server SHOULD include the three "Root CA Key Update" certificates, OldWithOld, OldWithNew, and NewWithOld, in the response chain. These are defined in Section 4.4 of CMP [RFC4210]. The EST client MUST be able to handle these certificates in the response. The EST CA's most recent self-signed certificate (for example, the NewWithNew certificate) is self-signed and has the latest NotAfter date. 📅
If the EST server doesn't include these in the response, then after the current EST CA certificate expires, the EST clients will need to be reinitialized with the PKI using the Bootstrap Distribution of CA certificates (Section 4.1.1) method, which involves user interaction. Ugh, nobody wants that 😭
After out-of-band validation happens, all the other certificates MUST be validated using normal [RFC5280] certificate path validation (using the most recent CA certificate as the TA) before they can be used to build certificate paths during certificate validation. 🔒
The EST client MUST store the extracted EST CA certificate as an Explicit TA database entry for later EST server authentication. 💾 The EST client SHOULD disable use of Implicit TA database entries for this EST server now that an Explicit TA database entry is available. If the client disables the Implicit TA database, and the EST server certificate was verified using an Implicit TA database entry, then the client MUST include the "Trusted CA Indication" extension in future TLS sessions [RFC6066]. This tells the server that only an EST server certificate that the Explicit TA database entry can authenticate is acceptable now. Otherwise, the EST server might keep using a server certificate that is only verifiable by a now-disabled Implicit TA 🙃
The EST client SHOULD also make the CA Certificate response information available to the end-entity software for use when validating peer certificates. 🫶
4.2. Client Certificate Request Functions 🎀
EST clients request a certificate from the EST server with an HTTPS POST using the operation path value /simpleenroll. EST clients request a renew/rekey of existing certificates with an HTTP POST using the operation path value /simplereenroll. EST servers MUST support the /simpleenroll and /simplereenroll functions. 💅
It is RECOMMENDED that a client obtain the current CA certificates, as described in Section 4.1, before performing certificate request functions. This makes sure the client can validate the EST server certificate. The client MUST authenticate the EST server as specified in Section 3.3.1 if certificate-based authentication is used, or Section 3.3.3 if the optional certificate-less authentication is used. The client MUST verify the authorization of the EST server as specified in Section 3.6. 🔐
The server MUST authenticate the client as specified in Section 3.3.2 if certificate-based authentication is used, or Section 3.3.3 if the optional certificate-less authentication is used. The server MUST verify client authorization as specified in Section 3.7. The EST server MUST check the tls-unique value, as described in Section 3.5, if the client submits one. 🕵️♀️
The server MAY accept a certificate request for manual authorization checking by an administrator. (Section 4.2.3 describes using an HTTP 202 response to the EST client when this happens.) 🧑💼
4.2.1. Simple Enrollment of Clients 🦋
When HTTPS POSTing to /simpleenroll, the client MUST include a Simple PKI Request as specified in CMC [RFC5272], Section 3.1 (that is, a PKCS #10 Certification Request [RFC2986]). 📝
The Certification Signing Request (CSR) signature gives the EST server proof-of-possession of the client-possessed private key. If the CSR KeyUsage extension says the private key can be used to generate digital signatures, then the client MUST generate the CSR signature using the private key. If the key can be used for digital signatures but the requested CSR KeyUsage extension prohibits generating them, then the CSR signature MAY still be generated using the private key, but the key MUST NOT be used for any other signature operations. This matches the recommendations about submitting proof-of-possession to an RA or CA, as described in [SP-800-57-Part-1]. ✨ Using /fullcmc operations gets you more advanced proof-of-possession methods for when the key pair can't be used for digital signature generation (see Section 4.3). 🔑
The HTTP content-type of application/pkcs10 is used here. The format of the message is as specified in [RFC5967], with a Content-Transfer-Encoding of base64 [RFC2045]. 📦
If the EST client authenticated using a previously installed certificate issued by a third-party CA (see Section 2.2.1), the client MAY include the ChangeSubjectName attribute, as defined in [RFC6402], in the CSR to ask for the subjectName and SubjectAltName to be changed in the new certificate. 🔄
The EST client MAY request additional certificates even when it uses an existing certificate in the TLS client authentication. For example, the client can use an existing certificate for TLS client authentication while requesting a certificate that can't be used for TLS client authentication. 💜
4.2.2. Simple Re-enrollment of Clients 🔁
EST clients renew/rekey certificates with an HTTPS POST using the operation path value /simplereenroll.
A certificate request uses the same format as the "simpleenroll" request, with the same HTTP content-type. The request Subject field and SubjectAltName extension MUST be identical to the corresponding fields in the certificate being renewed/rekeyed. The ChangeSubjectName attribute, as defined in [RFC6402], MAY be included in the CSR to ask for these fields to be changed in the new certificate. 🌸
If the Subject Public Key Info in the certification request is the same as the current client certificate, then the EST server renews the client certificate. If the public key information in the certification request is different from the current client certificate, then the EST server rekeys the client certificate. 🌟
4.2.3. Simple Enroll and Re-enroll Response ✨
okay so if the enrollment works, the server response MUST contain an HTTP 200 response code with a content-type of application/pkcs7-mime 🎉
A successful response MUST be a certs-only CMC Simple PKI Response, as defined in [RFC5272], and it should contain only the certificate that was issued 💅 The HTTP content-type is application/pkcs7-mime with an smime-type parameter of certs-only, as specified in [RFC5273] 🎀
The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616] error code when something goes wrong 🙈 A Simple PKI Response with an HTTP content-type of application/pkcs7-mime (see Section 4.3.2) MAY be included in the response data to carry an error response. If the content-type is not set, the response data MUST be a plaintext human-readable error message with explanatory information about why the request was rejected (for example, saying that the CSR attributes are incomplete) 😭
If the server responds with an HTTP [RFC2616] 202, that means the request was accepted for processing but a response isn't ready yet ⏳ The server MUST include a Retry-After header, the same way it's defined for HTTP 503 responses. The server also MAY include informative human-readable content 🌸 The client MUST wait at least the specified "retry-after" time before repeating the same request. So the client repeats the initial enrollment request once that interval has expired. The client SHOULD log or tell the end-user about this event 🧚 The server is responsible for keeping track of all the state it needs to recognize and handle retries, because the client is stateless here. It just keeps sending the same request until it gets a different response code, so it's giving patience 🫶 All other return codes are handled as specified in HTTP [RFC2616] 💜
If the client closes the TLS connection while it's waiting for the Retry-After time to run out, the client has to open a new TLS connection and run all the applicable security checks again 🔥 If the client already made a CSR that includes linking identity and POP information (Section 3.5), that CSR will need to be recreated so it picks up the tls-unique from the new, redirected session. Note: the key pair does not need to be regenerated 🦋 These are processing and interface burdens on the client, so EST server administrators are advised to keep that in mind 🙈
The EST client MAY also make the certificate response, and the associated private key, available to end-entity software for use as an end-entity certificate ✨
4.3. Full CMC
okay so an EST client can request a certificate from an EST server with an HTTPS POST using the operation path value /fullcmc 🌈 Support for the /fullcmc function is OPTIONAL for both clients and servers 🍓
4.3.1. Full CMC Request
If the HTTP POST to /fullcmc is not a valid Full PKI Request, the server MUST reject the message 💀 The HTTP content-type is application/pkcs7-mime with an smime-type parameter of CMC-request, as specified in [RFC5273]. The body of the message is the binary value of the encoding of the PKI Request, with a Content-Transfer-Encoding of base64 [RFC2045] 💖
4.3.2. Full CMC Response
If the enrollment is successful, the server response MUST include an HTTP 200 response code with a content-type of application/pkcs7-mime, as specified in [RFC5273] 👑 The response data includes either the Simple PKI Response with an smime-type parameter of certs-only, or the Full PKI Response with an smime-type parameter of CMC-response, as specified in Section 3.2.1 of [RFC5751] ✨ The body of the message is the binary value of the encoding of the PKI Response, with a Content-Transfer-Encoding of base64 [RFC2045] 🫶
When rejecting a request, the server MUST specify either an HTTP 4xx error or an HTTP 5xx error 🔥 A CMC response with the content-type of application/pkcs7-mime MUST be included in the response data for any CMC error response 🙈
All other return codes are handled as specified in Section 4.2.3 or HTTP [RFC2616] 🧚 For example, a client interprets an HTTP 404 or 501 response as meaning this service is not implemented 🦋
4.4. Server-Side Key Generation
An EST client may request a private key and an associated certificate from an EST server using an HTTPS POST with an operation path value of /serverkeygen 🔑 Support for the /serverkeygen function is OPTIONAL 🌸
A client MUST authenticate an EST server, as specified in Section 3.3.1 if certificate-based authentication is used, or Section 3.3.3 if the optional certificate-less authentication is used 🔒 It also has to check the server's authorization as given in Section 3.6 💅
The EST server MUST authenticate the client, as specified in Section 3.3.2 if certificate-based authenticated is used, or Section 3.3.3 if the optional certificate-less authentication is used 🛡️ It also checks the client's authorization as given in Section 3.7. The EST server applies whatever authorization or logic it chooses to decide whether the private key and certificate should be provided 👑
Cipher suites that have a NULL confidentiality algorithm MUST NOT be used, because they would disclose the contents of an unprotected private key 💀
Proper random number and key generation [RFC4086] is a server implementation responsibility, and whether the server archives generated keys is determined by CA policy 🎲 The key pair and certificate are transferred over the TLS session. The cipher suite used to return the private key and certificate MUST offer confidentiality commensurate with the private key being delivered to the client 🔐
The EST client MAY request additional certificates even when it's already using an existing certificate for TLS client authentication 💜 For example, the client can use an existing certificate for TLS client authentication while requesting a certificate that cannot be used for TLS client authentication 🧚
4.4.1. Server-Side Key Generation Request
The certificate request is sent with an HTTPS POST and is the same format as for the /simpleenroll and /simplereenroll path extensions, with the same content-type and transfer encoding 📝
In all respects, the server SHOULD treat the CSR the way it would treat any enroll or re-enroll CSR. The only difference here is that the server MUST ignore the public key values and signature in the CSR 🙈 These are only included in the request so existing codebases for generating and parsing such requests can be reused 🍓
If the client wants to receive the private key with encryption that sits outside of and in addition to the TLS transport used by EST, or if server policy requires the key to be delivered in that form, the client MUST include an attribute in the CSR indicating the encryption key to be used 🔐 Both symmetric and asymmetric encryption are supported, as described in the following subsections. The client MUST also include an SMIMECapabilities attribute ([RFC2633], Section 2.5) in the CSR to indicate the key encipherment algorithms the client is willing to use 🎀
It is strongly RECOMMENDED that clients request the returned private key be given the extra protection of Cryptographic Message Syntax (CMS) EnvelopedData on top of the TLS-provided security, to guard against unauthorized disclosure 🌈 this one is a must-do vibe, bestie 🫶
4.4.1.1. Requests for Symmetric Key Encryption of the Private Key
To specify a symmetric encryption key to encrypt the server-generated private key, the client MUST include a DecryptKeyIdentifier attribute (as defined in Section 2.2.5 of [RFC4108]) that specifies the identifier of the secret key the server should use to encrypt the private key 🗝️ That attribute was originally designed for specifying a firmware encryption key, but it exactly mirrors the requirements for specifying a secret key to encrypt a private key ✨ If the server does not have a secret key matching the identifier the client specified, the request MUST be terminated and an error returned to the client 💀 Distribution of the key specified by the DecryptKeyIdentifier to the key generator and the client is outside the scope of this document 🙈
4.4.1.2. Requests for Asymmetric Encryption of the Private Key
To specify an asymmetric encryption key to encrypt the server-generated private key, the client MUST include an AsymmetricDecryptKeyIdentifier attribute. The AsymmetricDecryptKeyIdentifier attribute is defined as:
id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= {
id-aa 54 }The asymmetric-decrypt-key-identifier attribute values have ASN.1 type AsymmetricDecryptKeyIdentifier (where ASN.1 is defined in [X.680])::
AsymmetricDecryptKeyIdentifier ::= OCTET STRINGIf the server does not have a public key matching the identifier the client specified, the request MUST be terminated and an error returned to the client 💀 Distribution of the key specified by the AsymmetricDecryptKeyIdentifier to the key generator and the client is outside the scope of this document 🙈 If the key identified is bound to an X.509 certificate, then the key MUST either explicitly support keyTransport or keyAgreement, or its use MUST be unrestricted 🔑
4.4.2. Server-Side Key Generation Response ✨
okay so if the request goes through, the server response MUST have an HTTP 200 response code with a content-type of "multipart/mixed" 💌 and it has to have exactly two parts: one holds the private key data and the other holds the certificate data 🎀
how the private key part gets returned depends on whether there's extra encryption on top of the TLS protection 🔐
if there's no extra encryption, the private key data MUST be placed in an "application/pkcs8" part. That part is the base64-encoded DER-encoded [X.690] PrivateKeyInfo with a Content-Transfer-Encoding of "base64" [RFC2045] 🦋
if there IS extra encryption, the private key goes inside a CMS SignedData 🖊️ The SignedData is signed by whoever generated the private key, and that could be the EST server, the EST CA, or someone else entirely 👀 Then the SignedData gets wrapped in a CMS EnvelopedData, as described in Section 4 of [RFC5958] 🎁 The list below shows how the EncryptedData gets used, depending on what kind of protection key the client picked 💅
- If the client specified a symmetric encryption key to protect the server-generated private key, the EnvelopedData content is encrypted using the secret key identified in the request. The EnvelopedData RecipientInfo field MUST indicate the key-encryption kekri key management technique. The values are as follows: version is set to 4, key-encryption key identifier (kekid) is set to the value of the DecryptKeyIdentifier from Section 4.4.1.1; keyEncryptionAlgorithm is set to one of the key wrap algorithms that the client included in the SMIMECapabilities accompanying the request; and encryptedKey is the encrypted key. 🔑
- If the client specified an asymmetric encryption key suitable for key transport operations to protect the server-generated private key, the EnvelopedData content is encrypted using a randomly generated symmetric encryption key. The cryptographic strength of the symmetric encryption key SHOULD be equivalent to the client-specified asymmetric key. The EnvelopedData RecipientInfo field MUST indicate the KeyTransRecipientInfo (ktri) key management technique. In KeyTransRecipientInfo, the RecipientIdentifier (rid) is either the subjectKeyIdentifier copied from the attribute defined in Section 4.4.1.2 or the server determines an associated issuerAndSerialNumber from the attribute; version is derived from the choice of rid [RFC5652], keyEncryptionAlgorithm is set to one of the key wrap algorithms that the client included in the SMIMECapabilities accompanying the request, and encryptedKey is the encrypted key. 🚚
- If the client specified an asymmetric encryption key suitable for key agreement operations to protect the server-generated private key, the EnvelopedData content is encrypted using a randomly generated symmetric encryption key. The cryptographic strength of the symmetric encryption key SHOULD be equivalent to the client-specified asymmetric key. The EnvelopedData RecipientInfo field MUST indicate the KeyAgreeRecipientInfo (kari) key management technique. In the KeyAgreeRecipientInfo type, version, originator, and user keying material (ukm) are as in [RFC5652], and keyEncryptionAlgorithm is set to one of the key wrap algorithms that the client included in the SMIMECapabilities accompanying the request. The recipient's key identifier is either copied from the attribute defined in Section 4.4.1.2 to subjectKeyIdentifier or the server determines an IssuerAndSerialNumber that corresponds to the value provided in the attribute. 🤝
In all three additional encryption cases, the EnvelopedData is returned in the response as an "application/pkcs7-mime" part with an smime-type parameter of "server-generated-key" and a Content-Transfer-Encoding of "base64" 🌸
The certificate data part is an "application/pkcs7-mime" and exactly matches the certificate response to /simpleenroll 📜
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. 🙅♀️ bestie, that second MUST is so important, no skipping it 💀
4.5. CSR Attributes 🌈
okay so CA policy may allow client-provided attributes to be included in the certificates it issues, and some of those attributes might describe stuff the CA has no way of knowing 🕵️♀️ Also, a CA may want to certify a certain type of public key and the client might not know that ahead of time 🙈 That's why clients SHOULD request a list of the attributes the CA needs or wants in an enrollment request, or when local policy says so 📋
The EST server SHOULD NOT require client authentication or authorization to reply to this request. 🫶 the vibe is open door for this one
Requesting CSR attributes is optional, but clients are advised that CAs may refuse enrollment requests that are not encoded according to the CA's policy. so basically, ask nicely or get rejected 😭
4.5.1. CSR Attributes Request 💌
The EST client requests a list of CA-desired CSR attributes from the CA by sending an HTTPS GET message to the EST server with an operations path of "/csrattrs" ✨
4.5.2. CSR Attributes Response 🧚
If locally configured policy for an authenticated EST client says a CSR Attributes Response is supposed to be provided, the server response MUST include an HTTP 200 response code. An HTTP response code of 204 or 404 means a CSR Attributes Response is not available. Regardless of the response code, the EST server and CA MAY reject any subsequent enrollment requests for any reason, e.g., incomplete CSR attributes in the request. 🙃
Responses to attribute request messages MUST be encoded as the content-type of "application/csrattrs" with a Content-Transfer-Encoding of "base64" [RFC2045]. The syntax for the application/csrattrs body is as follows: 🎀
CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }
Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
type ATTRIBUTE.&id({IOSet}),
values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }An EST server includes zero or more OIDs or attributes [RFC2986] that it requests the client to use in the certification request. The client MUST ignore any OID or attribute it does not recognize. When the server encodes CSR Attributes as an empty SEQUENCE, it means the server has no specific additional information it wants in a client certification request (this is functionally equivalent to an HTTP response code of 204 or 404). 🫠
If the CA requires a particular crypto system or use of a particular signature scheme (e.g., certification of a public key based on a certain elliptic curve, or signing using a certain hash algorithm) it MUST provide that information in the CSR Attribute Response. If an EST server requires the linking of identity and POP information (see Section 3.5), it MUST include the challengePassword OID in the CSR Attributes Response. 🔗
The structure of the CSR Attributes Response SHOULD, to the greatest extent possible, reflect the structure of the CSR it is requesting. Requests to use a particular signature scheme (e.g. using a particular hash function) are represented as an OID to be reflected in the SignatureAlgorithm of the CSR. Requests to use a particular crypto system (e.g., certification of a public key based on a certain elliptic curve) are represented as an attribute, to be reflected as the AlgorithmIdentifier of the SubjectPublicKeyInfo, with a type indicating the algorithm and the values indicating the particular parameters specific to the algorithm. Requests for descriptive information from the client are made by an attribute, to be represented as Attributes of the CSR, with a type indicating the [RFC2985] extensionRequest and the values indicating the particular attributes desired to be included in the resulting certificate's extensions. 🧩
The sequence is Distinguished Encoding Rules (DER) encoded [X.690] and then base64 encoded (Section 4 of [RFC4648]). The resulting text forms the application/csrattr body, without headers. 🍓
For example, if a CA requests a client to submit a certification request containing the challengePassword (indicating that linking of identity and POP information is requested; see Section 3.5), an extensionRequest with the Media Access Control (MAC) address ([RFC2307]) of the client, and to use the secp384r1 elliptic curve and to sign with the SHA384 hash function. Then, it takes the following: 👑
OID: challengePassword (1.2.840.113549.1.9.7)
Attribute: type = extensionRequest (1.2.840.113549.1.9.14)
value = macAddress (1.3.6.1.1.1.1.22)
Attribute: type = id-ecPublicKey (1.2.840.10045.2.1)
value = secp384r1 (1.3.132.0.34)
OID: ecdsaWithSHA384 (1.2.840.10045.4.3.3)and encodes them into an ASN.1 SEQUENCE to produce:
30 41 06 09 2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d
02 01 31 07 06 05 2b 81 04 00 22 30 16 06 09 2a 86 48 86 f7 0d 01
09 0e 31 09 06 07 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03
03and then base64 encodes the resulting ASN.1 SEQUENCE to produce:
MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ
BgcrBgEBAQEWBggqhkjOPQQDAw==5. IANA Considerations 🦋
Section 4.4.1.2 defines an OID that has been registered in an arc delegated by the IANA to the PKIX working group. 🌷
IANA has registered the following: 📝
IANA updated the well-known URI registry with the following filled-in template from [RFC5785]:
URI suffix: est
Change controller: IETFIANA has updated the "Application Media Types" registry with the following filled-in templates from [RFC6838]. 🎀
The media subtype for CSR attributes in a CSR Attributes Response is application/csrattrs.
Type name: application
Subtype name: csrattrs
Required parameters: None
Optional parameters: None
Encoding considerations: binary;
Security Considerations:
Clients request a list of attributes that servers wish to be in
certification requests. The request/response is normally done
in a TLS-protected tunnel.
Interoperability considerations: None
Published specification: This memo.
Applications which use this media type: Enrollment over Secure
Transport (EST)
Additional information:
Magic number(s): None
File extension: .csrattrs
Person & email address to contact for further information:
Dan Harkins <dharkins@arubanetworks.com>
Restrictions on usage: None
Author: Dan Harkins <dharkins@arubanetworks.com>
Intended usage: COMMON
Change controller: The IESG <iesg@ietf.org>The application/pkcs7-mime content-type defines the optional "smime-type" parameter [RFC5751] with a set of specific values. This document adds another value, "server-generated-key", as the parameter value for Server-side Key Generation Response. 🔥
6. Security Considerations 🔐✨
Okay bestie, this is the serious section 😭 but it's SO important, so let's go. 💅
Basic authentication, from [RFC2617], lets the server see a client's cleartext password 💀. That's how legacy username/password databases keep working, but it also means the plaintext password gets exposed to the EST server. A PIN or one-time password can help cut that exposure down. Still, it is RECOMMENDED that EST clients use such credentials only once, to get a client certificate, and then use that certificate for future interactions with the EST server. 🎀
Now the Implicit TA database. When a client uses it for certificate validation (see Section 3), authorization goes ahead as specified in Section 3.6.2. The client has checked that the server is a responder certified by a third party for the URI it's configured with, but it can't verify that the responder is actually authorized to act as an RA for the PKI where the client is trying to enroll. Yikes 🙈 so clients using an Implicit Trust Anchor database are RECOMMENDED to use only TLS-based client authentication, so HTTP-based client authentication info doesn't get exposed. It is also RECOMMENDED that such clients include "Linking Identity and POP Information" (Section 3.5) in their requests, so a man in the middle can't just forward those requests to a real EST server. 🦋
Another big one: it is RECOMMENDED that the Implicit Trust Anchor database used for EST server authentication be carefully managed, so a third-party CA with poor certification practices doesn't end up trusted. ✨ Disabling the Implicit Trust Anchor database after you've successfully received the Distribution of CA certificates response (Section 4.1.3) limits any vulnerability to the first TLS exchange. Smart, right? 🧚
Certificate-less TLS cipher suites that keep security up and do the mutual authentication enrollment needs have these properties:
- the only information leaked by an active attack is whether or not a single guess of the secret is correct.
- any advantage an adversary gains is through interaction and not computation.
- it is possible to perform countermeasures, such as exponential backoff after a certain number of failed attempts, to frustrate repeated active attacks.
Using a certificate-less cipher suite that doesn't have these properties would make the results of enrollment void 😭 and could lead to certificates being issued to unauthenticated and/or unauthorized entities. Not it. 🚫
When you're using a certificate-less TLS cipher suite, the shared secret used for authentication and authorization can't be shared with anyone who isn't a party to the exchange (so, someone other than the client and the server). Any extra sharing of secrets voids the security that the cipher suite gives you. Exposing that secret to a third party enables client impersonation, which can corrupt a client's trust anchor database. Literally the worst. 💀
TLS cipher suites with _EXPORT_ or _DES_ in their names MUST NOT be used. These ciphers don't offer enough protection: 40-bit crypto in 2013 doesn't offer acceptable protection, and DES is deprecated. ⛔
As CMC, Section 6.7 of [RFC5272], puts it: "For keys that can be used as signature keys, signing the certification request with the private key serves as a POP on that key pair". Including tls-unique in the certification request links the proof-of-possession to the TLS proof-of-identity, because it makes sure the POP operation happened while the TLS session was active. That tells the server the authenticated client currently has access to the private key. If the client is known to have specific capabilities, like hardware protection for authentication credentials and key storage, that implication gets stronger, but it still isn't proven. 🔥
The server-side key generation method lets keys travel over the TLS connection to the client with no application-layer protection on top. Distributing private key material is inherently risky, and private key distribution uses the encryption mode of the negotiated TLS cipher suite. Keys aren't protected by preferred key wrapping methods like AES Key Wrap [RFC3394] or the ones specified in [RFC5958], because encrypting the private key beyond what TLS provides is optional. It is RECOMMENDED that EST servers not support this operation by default. It is RECOMMENDED that clients not request this service unless there's a compelling operational benefit. Using an Implicit Trust Anchor database is NOT RECOMMENDED when server-side key generation is employed. And the use of an encrypted CMS Server-Side Key Generation Response is RECOMMENDED. 🫶
Now the CSR attributes. The CA may list attributes for inclusion in an enrollment request. There are no real inherent security issues with the content being conveyed, BUT an adversary who can interpose herself into the conversation could exclude attributes a server may want, include attributes a server may not want, and render other attributes that a server may want meaningless. Sneaky 🙈
Last one, and it's a big deal: ASN.1 encoding rules (e.g., DER and BER) have a type-length-value structure, and it's easy to build malicious content with invalid length fields that can cause buffer overrun conditions. ASN.1 encoding rules also allow arbitrary levels of nesting, which may make it possible to build malicious content that causes a stack overflow. Interpreters of ASN.1 structures should be aware of these issues and should take appropriate measures to guard against buffer overflows and stack overruns in particular, and against malicious content in general. Stay safe out there, babe 🌈💜
7. References ⭐
7.1. Normative References
- [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999.
- [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
- [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
- [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
- [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000.
- [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
- [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
- [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, August 2005.
- [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005.
- [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
- [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
- [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
- [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
- [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
- [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC): Transport Protocols", RFC 5273, June 2008.
- [RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages over CMS (CMC): Compliance Requirements", RFC 5274, June 2008.
- [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
- [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
- [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010.
- [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
- [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010.
- [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, July 2010.
- [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010.
- [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
- [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
- [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) Updates", RFC 6402, November 2011.
- [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 2011.
- [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.
- [X.680] ITU-T Recommendation X.680 (2008) | ISO/IEC 8824-1:2008, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", November 2008,
<http://www.itu.int/rec/T-REC-X.680-200811-I/en>. - [X.690] ITU-T Recommendation X.690 (2008) | ISO/IEC 8825-1:2008, "ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", November 2008,
<http://www.itu.int/rec/T-REC-X.690-200811-I/en>.
7.2. Informative References
Okay bestie, these are the "extra reading" sources. Not required to build the thing, but super useful for the full picture 📚✨
- [IDevID] IEEE Standards Association, "IEEE 802.1AR Secure Device Identifier", December 2009,
<http://standards.ieee.org/findstds/standard/802.1AR-2009.html>. 🆔 - [RFC2307] Howard, L., "An Approach for Using LDAP as a Network Information Service", RFC 2307, March 1998. 🗂️
- [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 🔐
- [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, November 2000. 🧾
- [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002. 🗝️
- [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication", RFC 5054, November 2007. 🦋
- [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, August 2010. 📮
- [RFC6403] Zieglar, L., Turner, S., and M. Peck, "Suite B Profile of Certificate Management over CMS", RFC 6403, November 2011. 💎
- [SHS] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", Federal Information Processing Standard Publication 180-4, March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf>. 🧮 - [SP-800-57-Part-1] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1: General (Revision 3)", July 2012,
<http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf>. 🔑
Appendix A. Operational Scenario Example Messages ✨
(Informative) 🎀
Okay so this part is the receipts! 🧾💅 It takes the Operational Scenario Overviews and shows you real example messages at each TLS layer, so you can see exactly what goes over the wire. Main character energy 🌸
A.1. Obtaining CA Certificates
Here's a valid /cacerts exchange, bestie 🦋
During the initial TLS handshake, the client is allowed to skip the optional server-generated "certificate request" and just go straight to the HTTP GET request:
GET /.well-known/est/cacerts HTTP/1.1
User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS
SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Host: 192.0.2.1:8085
Accept: */*And the server replies with the current CA certificates, serving it 🍓
HTTP/1.1 200 OK
Status: 200 OK
Content-Type: application/pkcs7-mime
Content-Transfer-Encoding: base64
Content-Length: 4246
MIIMOQYJKoZIhvcNAQcCoIIMKjCCDCYCAQExADALBgkqhkiG9w0BBwGgggwMMIIC
+zCCAeOgAwIBAgIJAJpY3nUZO3qcMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMT
EGVzdEV4YW1wbGVDQSBPd08wHhcNMTMwNTA5MDM1MzMxWhcNMTQwNTA5MDM1MzMx
WjAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgT3dPMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAwDqpiHopaICubpRqbpEN7LqTIqWELFIA9qDDheHIKuyO
HW/ZAP7Rl4S5ZU6gaLW/ksseBUxdmox3KNyvtyjehIofTu28eZWhgy6/LCEGWR3P
K+fgPBA0l0JfJR/8oeXZa70oLVQc3hI4kCeqjFMs+biYH0vp/RluhftyZ5kzQyH1
EGsRkw1/qUKkTZ8PCF8VFlYfqmUoqsaRTyZbjII4J+Y6/jEG+p7QreW9zcz4sPe8
3c/uhwMLOWQkZtKsQtgo5CpfYMjuAmk4Q2joQq2vcxlc+WNKHf+wbrDb11ORZril
9ISlI94oumcRz3uBG1Yg7z83hdDfasmdfbp8gOSNFQIDAQABo0IwQDAPBgNVHRMB
Af8EBTADAQH/MB0GA1UdDgQWBBQITTKxMqATXrfc4ffpCIbt6Gsz0jAOBgNVHQ8B
Af8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBACPnQPu5WReUGuCMS0nBOGa2tXh6
uZP4mS3J1qEfDePam/IiU9ssyYdcDwhVvKMoP4gI/yu4XFqhdpIoy/PyD4T15MT7
KADCxXkh5rM1IqMui7FvBKLWYGdy9sjEf90wAkBjHBe/TMO1NNw3uELyONSkHIvo
X0pu6aPmm/moIMyGi46niFse1iWlXXldGLkOQsh0e7U+wpBX07QpOr2KB2+Yf+uA
KY1SWzEG23bUxXlvcbUMgANDGj5r6z+niKL0VlApip/iCuVEEOcZ91UlmJjVLQWA
x6ie+v84oM+pIojiGM0C4XWcVlKKEgcMOsN3S4lvm8Ptpq0GLoIJY8NTD20wggMD
MIIB66ADAgECAgEBMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMTEGVzdEV4YW1w
bGVDQSBPd08wHhcNMTMwNTA5MDM1MzMyWhcNMTQwNTA5MDM1MzMyWjAbMRkwFwYD
VQQDExBlc3RFeGFtcGxlQ0EgTndPMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAnn3rZ3rMJHwf7MD9K4mubxHAvtdnrsQf5OfgtMhRIL4aePNhAdgPyj8C
loxOgD3UTV+dQ1ViOzVxPN7acikoOnkIdRpjpOpkyMo+KkvHMQXGnQTbsMAv1qWt
9S12DMpo0GOA1e4Ge3ud5YPOTR/q6PvjN51IEwYKksG7CglwZwB+5JbwhYr2D/0u
btGltriRVixPWrvt+wz/ITp5rcjh/8RS3LE8tQy3kTNhJF3Y/esR2sSgOiPNgIto
CATysbaINEPr4MemqML4tDpR/aG9y+8Qe7s1LyMFvDletp2mmBykAC/7nOat/pwU
lB0sN524D1XAgz8ZKvWrkh+ZaOr3hwIDAQABo1IwUDAOBgNVHQ8BAf8EBAMCBLAw
HQYDVR0OBBYEFLHEaeZbowSn2Jejizu/uWqyMkI8MB8GA1UdIwQYMBaAFAhNMrEy
oBNet9zh9+kIhu3oazPSMA0GCSqGSIb3DQEBBQUAA4IBAQCLDkL7aLNV6hSOkIqH
q+shV9YLO56/tj00vY/jV5skgDHk5d0B+OGortKVuGa57+v0avTrlJns3bNW8Ntv
zkDEhmd00Ak02aPsi4wRHLFgttUf9HdEHAuTkAESPTU43DiptjkfHhtBMfsFrCkd
sxWzCz+prDOMHYfUEkhRVV++1zyGEX6ov1Ap2IU2p3E+ASihL/amxTEQAsbwjUTI
R52zoL6nMPzpbKeZi2M0eEBVF8sDueA9Hjo6woLjgJqV0/yc5vC2HAxUOhx0cWTY
GcRBgL/yOyQLKiY5TKBH951OjQ4vhF2HmcoO7DkcNLYJOge16ssx4ogBHul20VgF
XJJjMIIDAzCCAeugAwIBAgIBAjANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBl
c3RFeGFtcGxlQ0EgTndOMB4XDTEzMDUwOTAzNTMzMloXDTE0MDUwOTAzNTMzMlow
GzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE93TjCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAMA6qYh6KWiArm6Uam6RDey6kyKlhCxSAPagw4XhyCrsjh1v
2QD+0ZeEuWVOoGi1v5LLHgVMXZqMdyjcr7co3oSKH07tvHmVoYMuvywhBlkdzyvn
4DwQNJdCXyUf/KHl2Wu9KC1UHN4SOJAnqoxTLPm4mB9L6f0ZboX7cmeZM0Mh9RBr
EZMNf6lCpE2fDwhfFRZWH6plKKrGkU8mW4yCOCfmOv4xBvqe0K3lvc3M+LD3vN3P
7ocDCzlkJGbSrELYKOQqX2DI7gJpOENo6EKtr3MZXPljSh3/sG6w29dTkWa4pfSE
pSPeKLpnEc97gRtWIO8/N4XQ32rJnX26fIDkjRUCAwEAAaNSMFAwDgYDVR0PAQH/
BAQDAgSwMB0GA1UdDgQWBBQITTKxMqATXrfc4ffpCIbt6Gsz0jAfBgNVHSMEGDAW
gBSxxGnmW6MEp9iXo4s7v7lqsjJCPDANBgkqhkiG9w0BAQUFAAOCAQEALhDaE6Mp
BINBsJozdbXlijrWxL1CSv8f4GwpUFk3CgZjibt/qW9UoaNR4E58yRopuEhjwFZK
2w8YtRqx8IZoFhcoLkpBDfgLLwhoztzbYvOVKQMidjBlkBEVNR5MWdrs7F/AxWuy
iZ2+8AnR8GwqEIbCD0A7xIghmWEMh/BVI9C7GLqd6PxKrTAjuDfEpfdWhU/uYKmK
cL3XDbSwr30j2EQyaTV/3W0Tn2UfuxdwDQ4ZJs9G+Mw50s7AG6CpISyOIFmX6/bU
DpJXGLiLwfJ9C/aum9nylYuGCJ68BuTrCs9567KGfXEXI0mdFFCL7TaVR43kjsg3
c43kZ7369MeEZzCCAvswggHjoAMCAQICCQDprp3DmjOyETANBgkqhkiG9w0BAQUF
ADAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgTndOMB4XDTEzMDUwOTAzNTMzMloX
DTE0MDUwOTAzNTMzMlowGzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE53TjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ5962d6zCR8H+zA/SuJrm8RwL7X
Z67EH+Tn4LTIUSC+GnjzYQHYD8o/ApaMToA91E1fnUNVYjs1cTze2nIpKDp5CHUa
Y6TqZMjKPipLxzEFxp0E27DAL9alrfUtdgzKaNBjgNXuBnt7neWDzk0f6uj74zed
SBMGCpLBuwoJcGcAfuSW8IWK9g/9Lm7Rpba4kVYsT1q77fsM/yE6ea3I4f/EUtyx
PLUMt5EzYSRd2P3rEdrEoDojzYCLaAgE8rG2iDRD6+DHpqjC+LQ6Uf2hvcvvEHu7
NS8jBbw5XradppgcpAAv+5zmrf6cFJQdLDeduA9VwIM/GSr1q5IfmWjq94cCAwEA
AaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUscRp5lujBKfYl6OLO7+5
arIyQjwwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBCz/CWdYvn
GM/SdCdEiom5A1VxaW8nKgCWg/EyWtAIiaHQuViB+jTUAE9lona2MbJoFHW8U5e8
9dCP0rJpA9UYXXhWvFQzd5ZWpms4wUYt1j3gqqd36KorJIAuPigVng13yKytxM7c
VmxQnh0aux3aEnEyRGAhGalHp0RaKdgPRzUaGtipJTNBkSV5S4kD4yDCPHMNbBu+
OcluerwEpbz6GvE7CpXl2jrTBZSqBsFelq0iz4kk9++9CnwZwrVgdzklhRfJ1Z4j
NkLruwbQ+o4NvBZsXiKxNfn3K2o3SK8AuaEyDWkq18+5rjcfprRO8x4YTW+6mXPq
jM0MAGNDEW+1oQAxAA==A.2. CSR Attributes
Now the /csrattrs exchange 💜 Here the EST client proves who it is using an existing certificate issued by the CA that the EST server provides services for. Iconic security vibes 🔐
The initial TLS handshake is identical to the enrollment example handshake. The HTTP GET request:
GET /.well-known/est/csrattrs HTTP/1.1
User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS
SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Host: 192.0.2.1:8085
Accept: */*In response, the server hands back suggested attributes that fit the authenticated client, perfectly tailored 👑 The example also throws in two extra attributes that the client just ignores unless it actually knows that attribute type. Ignoring the stuff you don't recognize? Very mature of it 🙈
HTTP/1.1 200 OK
Status: 200 OK
Content-Type: application/csrattrs
Content-Transfer-Encoding: base64
Content-Length: 171
MHwGBysGAQEBARYwIgYDiDcBMRsTGVBhcnNlIFNFVCBhcyAyLjk5OS4xIGRhdGEG
CSqGSIb3DQEJBzAsBgOINwIxJQYDiDcDBgOINwQTGVBhcnNlIFNFVCBhcyAyLjk5
OS4yIGRhdGEGCSskAwMCCAEBCwYJYIZIAWUDBAICA.3. Enroll/Re-enroll 💌
okay so this is the example of a valid /simpleenroll exchange 🎀 the data messages for /simplereenroll are basically similar, no cap ✨
during this exchange the EST client uses an out-of-band distributed username/password to authenticate itself to the EST server 🔐 this is the normal HTTP WWW-Authenticate behavior and it's included here for informative purposes 🧚 when an existing TLS client certificate is used, the server might skip requesting the HTTP WWW-Authenticate header, such as during a /simplereenroll operation 🦋
during the initial TLS handshake, the client can ignore the optional server-generated "certificate request" and can instead proceed with the HTTP POST request 💅 in response to the initial HTTP POST attempt, the server requests WWW-Authenticate from the client (this might occur even if the client used a client certificate, as detailed in the normative text above) 🙈
HTTP/1.1 401 Unauthorized
Content-Length: 0
WWW-Authenticate: Digest qop="auth", realm="estrealm",
nonce="1368141352"in the subsequent HTTP POST, the username/password is included, along with the complete application/pkcs10 content 🫶
POST /.well-known/est/simpleenroll HTTP/1.1
Authorization: Digest username="estuser", realm="estrealm", nonc
e="1368141352", uri="/.well-known/est/simpleenroll", cnonce="M
TYwMzg3", nc=00000001, qop="auth", response="144cc27f96046f1d70e
b16db20f75f22"
Host: 192.0.2.1:8085
Accept: */*
Content-Type: application/pkcs10
Content-Transfer-Encoding: base64
Content-Length: 882
MIIChTCCAW0CAQAwHzEdMBsGA1UEAxMUZGVtb3N0ZXA0IDEzNjgxNDEzNTIwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClNp+kdz+Nj8XpEp9kaumWxDZ3
eFYJpQKz9ddD5e5OzUeCm103ZIXQIxc0eVtMCatnRr3dnZRCAxGjwbqoB3eKt29/
XSQffVv+odbyw0WdkQOIbntCQry8YdcBZ+8LjI/N7M2krmjmoSLmLwU2V4aNKf0Y
MLR5Krmah3Ik31jmYCSvwTnv6mx6pr2pTJ82JavhTEIIt/fAYq1RYhkM1CXoBL+y
hEoDanN7TzC94skfS3VV+f53J9SkUxTYcy1Rw0k3VXfxWwy+cSKEPREl7I6k0YeK
tDEVAgBIEYM/L1S69RXTLujirwnqSRjOquzkAkD31BE961KZCxeYGrhxaR4PAgMB
AAGgITAfBgkqhkiG9w0BCQcxEhMQK3JyQ2lyLzcrRVl1NTBUNDANBgkqhkiG9w0B
AQUFAAOCAQEARBv0AJeXaHpl1MFIdzWqoi1dOCf6U+qaYWcBzpLADvJrPK1qx5pq
wXM830A1O+7RvrFv+nyd6VF2rl/MrNp+IsKuA9LYWIBjVe/LXoBO8dB/KxrYl16c
VUS+Yydi1m/a+DaftYSRGolMLtWeiqbc2SDBr2kHXW1TR130hIcpwmr29kC2Kzur
5thsuj276FGL1vPu0dRfGQfx4WWa9uAHBgz6tW37CepZsrUKe/0pfVhr2oHxApYh
cHGBQDQHVTFVjHccdUjAXicrtbsVhU5o1lPv7f4lEApv3SBQmJcaq5O832BzHw7n
PyMFcM15E9gtUVee5C62bVwuk/tbnGsbwQ==the EST server uses the username/password to perform authentication/authorization and responds with the issued certificate 🌸
HTTP/1.1 200 OK
Status: 200 OK
Content-Type: application/pkcs7-mime; smime-type=certs-only
Content-Transfer-Encoding: base64
Content-Length: 1122
MIIDOAYJKoZIhvcNAQcCoIIDKTCCAyUCAQExADALBgkqhkiG9w0BBwGgggMLMIID
BzCCAe+gAwIBAgIBFTANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFt
cGxlQ0EgTndOMB4XDTEzMDUwOTIzMTU1M1oXDTE0MDUwOTIzMTU1M1owHzEdMBsG
A1UEAxMUZGVtb3N0ZXA0IDEzNjgxNDEzNTIwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQClNp+kdz+Nj8XpEp9kaumWxDZ3eFYJpQKz9ddD5e5OzUeCm103
ZIXQIxc0eVtMCatnRr3dnZRCAxGjwbqoB3eKt29/XSQffVv+odbyw0WdkQOIbntC
Qry8YdcBZ+8LjI/N7M2krmjmoSLmLwU2V4aNKf0YMLR5Krmah3Ik31jmYCSvwTnv
6mx6pr2pTJ82JavhTEIIt/fAYq1RYhkM1CXoBL+yhEoDanN7TzC94skfS3VV+f53
J9SkUxTYcy1Rw0k3VXfxWwy+cSKEPREl7I6k0YeKtDEVAgBIEYM/L1S69RXTLuji
rwnqSRjOquzkAkD31BE961KZCxeYGrhxaR4PAgMBAAGjUjBQMA4GA1UdDwEB/wQE
AwIEsDAdBgNVHQ4EFgQU/qDdB6ii6icQ8wGMXvy1jfE4xtUwHwYDVR0jBBgwFoAU
scRp5lujBKfYl6OLO7+5arIyQjwwDQYJKoZIhvcNAQEFBQADggEBACmxg1hvL6+7
a+lFTARoxainBx5gxdZ9omSb0L+qL+4PDvg/+KHzKsDnMCrcU6M4YP5n0EDKmGa6
4lY8fbET4tt7juJg6ixb95/760Th0vuctwkGr6+D6ETTfqyHnrbhX3lAhnB+0Ja7
o1gv4CWxh1I8aRaTXdpOHORvN0SMXdcrlCys2vrtOl+LjR2a3kajJO6eQ5leOdzF
QlZfOPhaLWen0e2BLNJI0vsC2Fa+2LMCnfC38XfGALa5A8e7fNHXWZBjXZLBCza3
rEs9Mlh2CjA/ocSC/WxmMvd+Eqnt/FpggRy+F8IZSRvBaRUCtGE1lgDmu6AFUxce
R4POrT2xz8ChADEAA.4. Server Key Generation 🔑
okay so this is the example of a valid /serverkeygen exchange 💖 during this exchange the EST client authenticates itself using an existing certificate issued by the CA the EST server provides services for 🫶
the initial TLS handshake is identical to the enrollment example handshake 🌈 an example HTTP POSTed message is:
POST /.well-known/est/serverkeygen HTTP/1.1
Host: 192.0.2.1:8085
Accept: */*
Expect: 100-continue
Content-Type: application/pkcs10
Content-Transfer-Encoding: base64
Content-Length: 963
MIICwTCCAakCAQAwWzE+MDwGA1UEAxM1c2VydmVyS2V5R2VuIHJlcSBieSBjbGll
bnQgaW4gZGVtbyBzdGVwIDEyIDEzNjgxNDE5NTUxGTAXBgNVBAUTEFBJRDpXaWRn
ZXQgU046MTAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvE1/6m4A/
3/L32Suyzbf28LM9y8CQfp0aepa7o20BSfluvm8HXR44mlV+wpieM8H5n3Ub3RIo
RUun/FllIzK9uV7UrkqJ3Yzmq2NOoTd4C+OPsV/RPTu873dhFrssDk3P4NIphlSS
sSIkt5rhz7wYbCqCFR5Aphe/30Jx7D+xBI5Rs8e6vRS8IpuImh71BHiLfhq9AFhz
4ZJsOUSVpUmqUogFsM7SOQ6XI4dl+djhpjT+YTJ6hQ2PXrqdch3KsTQ8c6aKs+e2
5QJxh7O8JHVlPHo4YIxXtAYSutcbbTN5TXWFCWSrWDJ+zuMmk2yU+dio1oW7YR7V
ftAvazJ3laQbAgMBAAGgITAfBgkqhkiG9w0BCQcxEhMQZEZzQVhtSm5qb2tCdER2
cjANBgkqhkiG9w0BAQUFAAOCAQEAR+I0EQB+hSjrLCAjnVH6bZdHUNGszIdwx1iu
L4n+0XK3SfEzeOMkC4T74yFGKj3redS1Ht9atYUPb0D1Qi9Jf9Co8eLblo1l19A6
GaS798ofxIF0Pl0Dr6/GqjheqJEIbcDTAJq+kvDihyQ4GQnhosygIZHvKppQlebA
gvp2RJSnMroPCe6RgTU9E2fmI9rin/9PyXeWFF1namp+lYbTGwjv1aE1ikhjCLlH
veHhCdgOExPw+fqhKhHjp+0ZKBlo2bC3pqRWvDTiZuwt9UpFFfGtuxvpTp44oS/j
M/965hWIw/5dshY/wQjIfYs07bbq2ERbpJiw9bAQY34gyoVmEQ==because the DecryptKeyIdentifier attribute is not included in this request, the response does not include additional encryption beyond the TLS session 🙈 the EST server response is:
HTTP/1.1 200 OK
Status: 200 OK
Content-Type: multipart/mixed ; boundary=estServerExampleBoundary
Content-Length: 3219
This is the preamble. It is to be ignored, though it
is a handy place for estServer to include an explanatory note,
including contact or support information.
--estServerExampleBoundary
Content-Type: application/pkcs8
Content-Transfer-Encoding: base64
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDPwKtwJ7TjMgA+
Poj64V909ryql0foP1hU4Yq5y8/bOP5ZTe6ArgVhUye099Ac+dfdwpyP/DESiujU
F/dS62Vck3UWNbnw+4O38FUp0enLbbjSTud48KpEW6+FzkeuAanPGZMA1wKyrYy9
rD5tQOOJU/CBVhUrITyYLZNYUe4agbpcR0wMtrRr2E58Mu8wQ80ryk6nkL7COk5Z
IQdNRxldk7DFvpA85Yn1stumoGRtVLW51iXeTS1LtXwhuUb/j6Lds3vvAiJ2SiZ0
Y3rxPlnJVyFmR8Mf2TBOjzuFqva/VLD2ayQjgaGEjq2ZWHXelQAOZ6N3lrChojEK
FGq93yOhAgMBAAECggEBALQ5az/nYjd5x9Y3f7NMUffwl+jRRfMHCMTRx/u4AEAo
KBYm0hFVZZtxfM+z7xlD8G0Th6gs2hFA6gwcIlUPmiX+UaOLxht0xWaLGgYmcNAm
BiCDjLBQ7xRQCWtlcK9WCA5+HBWtcEy6244rXxh+IyWd6NT6bXC165AEcX87y/e3
JFJ7XFNeDP656s2DmxSCci+iDte6SaEm7sJvYGu16qevJeMThcQcC9/rJjXkvpGL
IKK2px5idad4Pb6+QHpqj3d4oM8djO6wYUvrH8XQLqAaF8Hd5lFWVU57nSYY+H79
GaNDTfRTUL6AXr7kmMsKVFOJ0JjZExUCVMZtGiqhB6UCgYEA639OtdWLZCzyZFMe
p7VlRddoz0VAtrU2dxnEb4cWD8Gerg8uNvp8OG84gH+6MbPwz4ZYWKCgDFqyrAlw
SF02n9Sovh93eoJ5latSbfeYUkLtB8L/HVk5/CBGEsV9MUkdMF0+B43YlhyEDyKW
fX2+0UeHLFgRrfpSzP2cXduEieMCgYEA4db/SIrwN2+g1Gjo3oE09kd89VGjVRer
srbcqc7DcPXP6Lw42sx96h4jVWWqHVo3DfwFBdUb1LH2cnVXQjgDUHdNdpl01cf/
BFYCFINi2qKMqiJYswkhYxZ1BLz/zuQTDbPFL2PgLniKFG2aFLrTS3S/tgeB5QwI
RPigH3kfI6sCgYAPqsCJyFMlrvfRRNZdQewi4VnPsEPF4/hjpAs1gD8vfSoZWlkw
vylUd9HCerzgYaA7rixieQ0sxTvtxhL6PXlM2NEBFQbV16hPFL6/IiG4F0u9oHNo
eG8rHtqKlSjnBn4yoYFm70Dhe7QtbZelcaAoPCH6CUHj2St5B8ZHWDtREQKBgHNp
wER+XIy4C2UByCANv9csaXulIOdXlXNbaCGPfOm5dWrm5ddLMf33MO9vaSRe+ku3
Q4nbgsGLwPp1ZQZ+QZNZpMi7W6306yp4GdAJ5Pb+oww/ST0VqW5OB7dILyK4A9S4
zkiNrf+Rsl8GM/vsDhc9rsuDwqofIAq/VHVBHNzJAoGBAOHQof5L6iGHOHcxLazx
4MGvRTpmzU/PX6Q3QxqpetEGFEDZAaL58L67SSS3fFBnKrVAidF6llC1bAH1aoRa
fYHUDi45xBoroy0hBwrnTKRxppua4UK75FUH5PPJfR6cCvw5stRkzIevTZHhozkX
pM7PYH/x4BiBmgQ3bhOqTp4H
--estServerExampleBoundary
Content-Type: application/pkcs7-mime; smime-type=certs-only
Content-Transfer-Encoding: base64
MIIDRQYJKoZIhvcNAQcCoIIDNjCCAzICAQExADALBgkqhkiG9w0BBwGgggMYMIID
FDCCAfygAwIBAgIBFjANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFt
cGxlQ0EgTndOMB4XDTEzMDUwOTIzMjU1NloXDTE0MDUwOTIzMjU1NlowLDEqMCgG
A1UEAxMhc2VydmVyc2lkZSBrZXkgZ2VuZXJhdGVkIHJlc3BvbnNlMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz8CrcCe04zIAPj6I+uFfdPa8qpdH6D9Y
VOGKucvP2zj+WU3ugK4FYVMntPfQHPnX3cKcj/wxEoro1Bf3UutlXJN1FjW58PuD
t/BVKdHpy2240k7nePCqRFuvhc5HrgGpzxmTANcCsq2Mvaw+bUDjiVPwgVYVKyE8
mC2TWFHuGoG6XEdMDLa0a9hOfDLvMEPNK8pOp5C+wjpOWSEHTUcZXZOwxb6QPOWJ
9bLbpqBkbVS1udYl3k0tS7V8IblG/4+i3bN77wIidkomdGN68T5ZyVchZkfDH9kw
To87har2v1Sw9mskI4GhhI6tmVh13pUADmejd5awoaIxChRqvd8joQIDAQABo1Iw
UDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0OBBYEFKeZixu9F+appDX2SS5HaxmV6Jr4
MB8GA1UdIwQYMBaAFLHEaeZbowSn2Jejizu/uWqyMkI8MA0GCSqGSIb3DQEBBQUA
A4IBAQBHhLmRAKrnTapqqBObDM9IQDQPuwW+fW1gYwZKlSm/IWIwHEZL1igXhpjj
rf4xqpIkiJMmkaOeoXA8PFniX0/lZM9FQSM/j89CUf5dMoAqWj8s17xuXu9L/hVe
XjjXHsL40WuDG6tMPN9vcT8tE3ruor608MKSHFX/NEM6+AaNVSUPTmB33BgYB1Wa
E7pn3JMN6pjIxsHnF4pKi8qvoTSVVjaCEwUe8Q/fw1yvjoHoYJtyMn4v5Kb3Rt+m
s8Yie1tcfVQrjQutqr34/IJsKdPziZwi92KZa+1958A6M9O/p5OI0up9ZXKg2DEC
1O9qT0GyYJ6sxAyKiGTOxk6jMddDoQAxAA==
--estServerExampleBoundary--this is the epilogue, it is also to be ignored 🧚
Appendix B. Contributors and Acknowledgements 🌷
the editors would like to thank Stephen Kent, Vinod Arjun, Jan Vilhuber, Sean Turner, Russ Housley, and others for their feedback and prototypes of early versions of this document 💜 our thanks also go the authors of [RFC6403], around whose document we structured part of this specification 🥰
Authors' Addresses 📮
Max Pritikin (editor) Cisco Systems, Inc. 510 McCarthy Drive Milpitas, CA 95035 USA
EMail: pritikin@cisco.com
Peter E. Yee (editor) AKAYLA, Inc. 7150 Moorland Drive Clarksville, MD 21029 USA
EMail: peter@akayla.com
Dan Harkins (editor) Aruba Networks 1322 Crossman Avenue Sunnyvale, CA 94089-1113 USA
EMail: dharkins@arubanetworks.com
📦 where this page comes from
- ietf: rfc7030 2013-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms