# drafts

name: draft-serafin-lake-ta-hint
rev: 00
title: Trust Anchor Hints in Ephemeral Diffie-Hellman Over COSE (EDHOC)
time: 2025-04-24T07:05:45Z
group_uri: /api/v1/group/group/1027/
expires: 2025-04-24T11:08:44Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:13.081927+00:00
source: ietf
abstract:
  This document defines a format for transport of hints about Trust
     Anchors of trusted third parties when using the lightweight
     authenticated key exchange protocol Ephemeral Diffie-Hellman Over
     COSE (EDHOC).

full_text:
  Lightweight Authenticated Key Exchange                        M. Serafin
  Internet-Draft                                                ASSA ABLOY
  Intended status: Standards Track                             G. Selander
  Expires: 23 April 2025                                          Ericsson
                                                           20 October 2024


      Trust Anchor Hints in Ephemeral Diffie-Hellman Over COSE (EDHOC)
                       draft-serafin-lake-ta-hint-00

  Abstract

     This document defines a format for transport of hints about Trust
     Anchors of trusted third parties when using the lightweight
     authenticated key exchange protocol Ephemeral Diffie-Hellman Over
     COSE (EDHOC).

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at
     https://gselander.github.io/lake-ta-hint/draft-serafin-lake-ta-
     hint.html.  Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-serafin-lake-ta-hint/.

     Discussion of this document takes place on the Lightweight
     Authenticated Key Exchange Working Group mailing list
     (mailto:lake@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/lake/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/lake/.

     Source for this draft and an issue tracker can be found at
     https://github.com/gselander/lake-ta-hint.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.







  Serafin & Selander        Expires 23 April 2025                 [Page 1]


  Internet-Draft              TA Hints in EDHOC               October 2024


     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 23 April 2025.

  Copyright Notice

     Copyright (c) 2024 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Trust Anchor Hints  . . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Trust Anchor Purpose  . . . . . . . . . . . . . . . . . .   4
       2.2.  EAD Item  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Authentication Processing . . . . . . . . . . . . . . . . . .   6
       3.1.  Example 1 . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.2.  Example 2 . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.3.  Example 3 . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
       5.1.  EDHOC External Authorization Data Registry  . . . . . . .   7
       5.2.  EDHOC Trust Anchor Hint Registry  . . . . . . . . . . . .   7
     6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
       6.2.  Informative References  . . . . . . . . . . . . . . . . .   9
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

  1.  Introduction

     Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528] is a lightweight
     security handshake protocol with low processing and message overhead,
     especially suited for constrained devices and low-power networking.




  Serafin & Selander        Expires 23 April 2025                 [Page 2]


  Internet-Draft              TA Hints in EDHOC               October 2024


     Authentication and authorization, in addition to excuting a security
     handshake protocol, typically involves the validation of certificates
     or assertions using Trust Anchors (TAs).  For this machinery to work,
     the endpoints need to use credentials issued by a TA of the other
     endpoint.  Moreover, the validation of credentials against TAs can be
     a significant contribution to processing or time for completion, for
     example in embedded devices.  Performance can be improved by
     providing the other endpoint with hints about which TAs are
     supported, or which TAs should be used to verify specific
     credentials.  This document specifies how to transport hints of TAs
     between EDHOC peers.

     EDHOC allows authorization-related information in the External
     Authorization Data (EAD) message fields, see Section 3.8 of
     [RFC9528].  EAD can be included in any of the three mandatory and
     fourth optional EDHOC messages, providing flexibility and
     extensibility to the protocol.  Its main purpose is to embed
     authorization-related information directly into the key exchange
     process, reducing the need for additional message exchanges and
     optimizing the overall protocol flow.  Information about TAs is
     explicitly mentioned as one example of such authorization-related
     information, see Appendix E of [RFC9528].

     The primary motivation for this specification is to provide hints of
     TAs for authentication, typically related to Certificate Authorities
     (CAs), where the TA includes the public key of the CA.  The hint is a
     COSE header parameter intended to facilitate the retrieval of the TA,
     for example a key identifier (kid) or a hash of an X.509 certificate
     containing the CA root public key (x5t), see Section 2.2.  However,
     the same scheme can be applied to hints about other trusted third
     parties, such as Verifiers of remote attestation evidence [RFC9334]
     or Time Servers for network time synchronization [RFC5905].  This
     document defines an EDHOC EAD item containing hints about certain
     type of TAs, and enables the extension to other kind of hints and TAs
     through the registration of the appropriate IANA parameters.

  1.1.  Terminology

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  2.  Trust Anchor Hints






  Serafin & Selander        Expires 23 April 2025                 [Page 3]


  Internet-Draft              TA Hints in EDHOC               October 2024


  2.1.  Trust Anchor Purpose

     The EAD item defined in Section 2.2 provides hints to trust anchors
     for different purposes.  Table 1 provides the currently defined list
     of purposes, which is extensible through the IANA registry defined in
     Section 5.

              +=======+===========================+============+
              | Label | Purpose                   | Reference  |
              +=======+===========================+============+
              | 1     | Trust anchor of EDHOC     | [RFC-XXXX] |
              |       | authentication credential |            |
              +-------+---------------------------+------------+
              | 2     | Trust anchor of remote    | [RFC-XXXX] |
              |       | attestation verifier      |            |
              +-------+---------------------------+------------+
              | 3     | Trust anchor of time      | [RFC-XXXX] |
              |       | server                    |            |
              +-------+---------------------------+------------+

                     Table 1: EDHOC Trust Anchor purposes

     *  EDHOC authentication credential: This parameter hints at which TA
        to use for authentication credentials in EDHOC.  The positive of
        the CBOR label (+1) in the EAD item indicates trust anchor to use
        for verifying the authentication credentials from the sender.  The
        negative of the CBOR label (-1) indicates what trust anchors are
        supported by the sender and SHOULD be used in authentication
        credentials sent to the sender.

     *  Remote attestation verifier: TODO

     *  Time server: TODO

  2.2.  EAD Item

     This section defines the EAD item ead_ta_hint used to carry TA hints.

     Like all EAD items, ead_ta_hint consists of the ead_label, a
     predefined constant that identifies this particular EAD structure;
     and the ead_value, which in this case is a byte string containing a
     CBOR map with the CBOR-encoded TA hints.

     The following CDDL defines the EAD item, where header_map is defined
     in Section 3 of [RFC9052], and contain one or more COSE header
     parameters.





  Serafin & Selander        Expires 23 April 2025                 [Page 4]


  Internet-Draft              TA Hints in EDHOC               October 2024


     ead_ta_hint = (
         ead_label: TBD1,
         ead_value: bstr .cbor ta_hint_map,
     ),

     ta_hint_map = {
       * int => header_map
     }

                               Figure 1: EAD item

     Table 2 provides examples of COSE header_maps used as TA hint types.

      +=========+=======+===============+==============+===============+
      | TA hint | CBOR  | CBOR type     | Description  | Reference     |
      | type    | label |               |              |               |
      +=========+=======+===============+==============+===============+
      | kid     | 4     | bstr          | Key          | [RFC-9052]    |
      |         |       |               | identifier   |               |
      +---------+-------+---------------+--------------+---------------+
      | c5t     | 22    | COSE_CertHash | C509         | [draft-ietf-  |
      |         |       |               | certificate  | cose-cbor-    |
      |         |       |               | thumbprint   | encoded-cert] |
      +---------+-------+---------------+--------------+---------------+
      | c5u     | 23    | uri           | C509         | [draft-ietf-  |
      |         |       |               | certificate  | cose-cbor-    |
      |         |       |               | URI          | encoded-cert] |
      +---------+-------+---------------+--------------+---------------+
      | x5t     | 34    | COSE_CertHash | X.509        | [RFC-9360]    |
      |         |       |               | certificate  |               |
      |         |       |               | thumbprint   |               |
      +---------+-------+---------------+--------------+---------------+
      | x5u     | 35    | uri           | X.509        | [RFC-9360]    |
      |         |       |               | certificate  |               |
      |         |       |               | URI          |               |
      +---------+-------+---------------+--------------+---------------+
      | uuid    | TBD2  | #6.37(bstr)   | Binary CBOR- | [RFC-9562]    |
      |         |       |               | encoded UUID |               |
      +---------+-------+---------------+--------------+---------------+

                    Table 2: EDHOC Trust Anchor hint types










  Serafin & Selander        Expires 23 April 2025                 [Page 5]


  Internet-Draft              TA Hints in EDHOC               October 2024


  3.  Authentication Processing

     In EDHOC message_2, the ta_hint_map with label 1 is used in the EAD_2
     field to include hints about authentication TAs, i.e. TAs of the
     Responder's authentication credential AUTH_CRED_R.  This hint informs
     the Initiator about which TAs to prioritize when validating
     AUTH_CRED_R.  For example, if the Initiator’s trust store contains
     multiple CA/intermediate CA certificates, the Responder can include a
     hint indicating that the credentials should be validated using a
     specific TA identified by kid, x5t, x5u, c5t, c5u or UUID.

     Similarly for EDHOC message_3 and the TAs of the Initiator's
     authentication credential AUTH_CRED_I.

  3.1.  Example 1

     Consider a scenario where the Initiator trusts five CA/intermediate
     certificates.  The Responder, when sending message_2, knows that the
     Initiator should use the TA identified by kid=edhoc-noc-ica-2 for
     verification.  The Responder includes the following EAD item in
     EAD_2:

     TBD1, << { 1: { 4: h'6564686F632D6E6F632D6963612D32'}} >>

     When the Initiator receives message_2, it will prioritize validating
     the Responder’s credentials using the TA associated with the provided
     kid.

     If the validation against the TAs specified with the EAD item defined
     in this specification fails or is not recognized, then the receiver
     SHOULD fall back to the default validation process using available
     TAs.  If all validation against TAs fail, then an error SHOULD be
     sent.

  3.2.  Example 2

     An EDHOC peer may include hints about its supported TAs for
     authentication by including a ta_hint_map with label -1 in an
     appropriate EAD field: EAD_1 related to the AUTH_CRED_R and EAD_2 for
     AUTH_CRED_I.  This informs the other peer about what TAs to use in
     its credentials in the next EDHOC message.  In the example below the
     TA is identified by its SHA-256/64 hash (-15) and the URI from which
     the root certificate can be retrieved.  The EAD item ead_ta_hint
     could look like this:

     TBD1, << { -1: { 34: [-15, h'79f2a41b510c1f9b'],
                      35: "http://certs.tech.com"}} >>




  Serafin & Selander        Expires 23 April 2025                 [Page 6]


  Internet-Draft              TA Hints in EDHOC               October 2024


  3.3.  Example 3

     In EAD_2, the Responder can include both the information about TAs to
     use for validating the AUTH_CRED_R (Example 1) and recommended TAs to
     use for AUTH_CRED_I by the Initiator (Example 2).  The EAD item
     ead_ta_hint could look like this:

     TBD1, << { 1: { 4: h'6564686F632D6E6F632D6963612D32'}
               -1: { 34: [-15, h'79f2a41b510c1f9b'],
                      35: "http://certs.tech.com"}} >>

     Editor's note: Add examples using intermediate CAs

  4.  Security Considerations

     TODO

  5.  IANA Considerations

  5.1.  EDHOC External Authorization Data Registry

     IANA is requested to register the following entry to the "EDHOC
     External Authorization Data" registry defined in Section 10.5 of
     [RFC9528].

     The ead_label = TBD1 and the ead_value define TA hints transferred in
     an EAD item of an EDHOC message, with processing specified in
     Section 3.

     Name: Trust Anchor Hint

     Label: TBD1 (from the unsigned range)

     Description: A hint for determination of Trust Anchors used for
     verifying authentication credentials in EDHOC [RFC9528] or of other
     assertions used with External Authorization Data of EDHOC.

     Reference: [RFC-XXXX]

  5.2.  EDHOC Trust Anchor Hint Registry

     IANA has created a new registry entitled "EDHOC Trust Anchor Hint
     Registry".  The registration procedure depends on the range of CBOR
     label values, following [RFC8126].  Guidelines for the experts are
     provided in TODO.

     The columns of the registry are:




  Serafin & Selander        Expires 23 April 2025                 [Page 7]


  Internet-Draft              TA Hints in EDHOC               October 2024


     Label: The value to be used to identify this type of authority.  Map
     key labels MUST be unique.  The registry contains only positive
     integers, but negative integers MAY be used in the EAD item for the
     same type of authority but with separate semantics.  Integer values
     between 1 and 23 are designated as Standards Track document required.
     Integer values from 24 to 255 are designated as Specification
     Required.  Integer values from 256 to 65535 are designated as Expert
     Review.  Integer values greater than 65535 are marked as Private Use.

     Purpose: This field contains a brief description for the field.

     Reference: This contains a pointer to the public specification for
     the field, if one exists.

     This registry has been initially populated by the values in Table 1.
     The Reference column for all of these entries is this document.

  6.  References

  6.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
                "Network Time Protocol Version 4: Protocol and Algorithms
                Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
                <https://www.rfc-editor.org/rfc/rfc5905>.

     [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                Writing an IANA Considerations Section in RFCs", BCP 26,
                RFC 8126, DOI 10.17487/RFC8126, June 2017,
                <https://www.rfc-editor.org/rfc/rfc8126>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Structures and Process", STD 96, RFC 9052,
                DOI 10.17487/RFC9052, August 2022,
                <https://www.rfc-editor.org/rfc/rfc9052>.







  Serafin & Selander        Expires 23 April 2025                 [Page 8]


  Internet-Draft              TA Hints in EDHOC               October 2024


     [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
                W. Pan, "Remote ATtestation procedureS (RATS)
                Architecture", RFC 9334, DOI 10.17487/RFC9334, January
                2023, <https://www.rfc-editor.org/rfc/rfc9334>.

     [RFC9360]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Header Parameters for Carrying and Referencing X.509
                Certificates", RFC 9360, DOI 10.17487/RFC9360, February
                2023, <https://www.rfc-editor.org/rfc/rfc9360>.

     [RFC9528]  Selander, G., Preuß Mattsson, J., and F. Palombini,
                "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528,
                DOI 10.17487/RFC9528, March 2024,
                <https://www.rfc-editor.org/rfc/rfc9528>.

     [RFC9562]  Davis, K., Peabody, B., and P. Leach, "Universally Unique
                IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
                2024, <https://www.rfc-editor.org/rfc/rfc9562>.

  6.2.  Informative References

     [I-D.ietf-cose-cbor-encoded-cert]
                Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and
                M. Furuhed, "CBOR Encoded X.509 Certificates (C509
                Certificates)", Work in Progress, Internet-Draft, draft-
                ietf-cose-cbor-encoded-cert-11, 8 July 2024,
                <https://datatracker.ietf.org/doc/html/draft-ietf-cose-
                cbor-encoded-cert-11>.

  Acknowledgments

     TODO

  Authors' Addresses

     Marek Serafin
     ASSA ABLOY
     Email: marek.serafin@assaabloy.com


     Göran Selander
     Ericsson
     Email: goran.selander@ericsson.com








  Serafin & Selander        Expires 23 April 2025                 [Page 9]


name: draft-ietf-core-oscore-edhoc
rev: 11
time: 2024-11-18T22:45:17Z
group_uri: /api/v1/group/group/1789/
expires: 2024-10-11T08:22:31Z
ad: /api/v1/person/person/112723/
shepherd: /api/v1/person/email/cabo@tzi.org/
categories: []
tags: []
fetched_at: 2026-03-07T06:55:13.081931+00:00
source: ietf
title:
  Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained Application Protocol (CoAP) and Object Security for Constrained RESTful Environments (OSCORE)

abstract:
  The lightweight authenticated key exchange protocol Ephemeral Diffie-
     Hellman Over COSE (EDHOC) can be run over the Constrained Application
     Protocol (CoAP) and used by two peers to establish a Security Context
     for the security protocol Object Security for Constrained RESTful
     Environments (OSCORE).  This document details this use of the EDHOC
     protocol, by specifying a number of additional and optional
     mechanisms.  These especially include an optimization approach for
     combining the execution of EDHOC with the first OSCORE transaction.
     This combination reduces the number of round trips required to set up
     an OSCORE Security Context and to complete an OSCORE transaction
     using that Security Context.

states:
  ["/api/v1/doc/state/3/", "/api/v1/doc/state/108/", "/api/v1/doc/state/154/", "/api/v1/doc/state/112/", "/api/v1/doc/state/7/", "/api/v1/doc/state/44/"]

full_text:
  CoRE Working Group                                          F. Palombini
  Internet-Draft                                                  Ericsson
  Intended status: Standards Track                               M. Tiloca
  Expires: 11 October 2024                                      R. Höglund
                                                                   RISE AB
                                                              S. Hristozov
                                                          Fraunhofer AISEC
                                                               G. Selander
                                                                  Ericsson
                                                              9 April 2024


   Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained
  Application Protocol (CoAP) and Object Security for Constrained RESTful
                           Environments (OSCORE)
                      draft-ietf-core-oscore-edhoc-11

  Abstract

     The lightweight authenticated key exchange protocol Ephemeral Diffie-
     Hellman Over COSE (EDHOC) can be run over the Constrained Application
     Protocol (CoAP) and used by two peers to establish a Security Context
     for the security protocol Object Security for Constrained RESTful
     Environments (OSCORE).  This document details this use of the EDHOC
     protocol, by specifying a number of additional and optional
     mechanisms.  These especially include an optimization approach for
     combining the execution of EDHOC with the first OSCORE transaction.
     This combination reduces the number of round trips required to set up
     an OSCORE Security Context and to complete an OSCORE transaction
     using that Security Context.

  Discussion Venues

     This note is to be removed before publishing as an RFC.

     Discussion of this document takes place on the Constrained RESTful
     Environments Working Group mailing list (core@ietf.org), which is
     archived at https://mailarchive.ietf.org/arch/browse/core/.

     Source for this draft and an issue tracker can be found at
     https://github.com/core-wg/oscore-edhoc.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.





  Palombini, et al.        Expires 11 October 2024                [Page 1]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 11 October 2024.

  Copyright Notice

     Copyright (c) 2024 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  EDHOC Overview  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  EDHOC Combined with OSCORE  . . . . . . . . . . . . . . . . .   8
       3.1.  EDHOC Option  . . . . . . . . . . . . . . . . . . . . . .  10
       3.2.  Client Processing . . . . . . . . . . . . . . . . . . . .  11
         3.2.1.  Processing of the EDHOC + OSCORE Request  . . . . . .  11
         3.2.2.  Supporting Block-wise . . . . . . . . . . . . . . . .  13
       3.3.  Server Processing . . . . . . . . . . . . . . . . . . . .  13
         3.3.1.  Processing of the EDHOC + OSCORE Request  . . . . . .  13
         3.3.2.  Supporting Block-wise . . . . . . . . . . . . . . . .  15
       3.4.  Example of EDHOC + OSCORE Request . . . . . . . . . . . .  15
     4.  Use of EDHOC Connection Identifiers with OSCORE . . . . . . .  16
       4.1.  Additional Processing of EDHOC Messages . . . . . . . . .  17
         4.1.1.  Initiator Processing of Message 1 . . . . . . . . . .  17
         4.1.2.  Responder Processing of Message 2 . . . . . . . . . .  17
         4.1.3.  Initiator Processing of Message 2 . . . . . . . . . .  18
     5.  Extension and Consistency of Application Profiles . . . . . .  18
     6.  Web Linking . . . . . . . . . . . . . . . . . . . . . . . . .  18
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  21



  Palombini, et al.        Expires 11 October 2024                [Page 2]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
       8.1.  CoAP Option Numbers Registry  . . . . . . . . . . . . . .  22
       8.2.  Target Attributes Registry  . . . . . . . . . . . . . . .  23
       8.3.  EDHOC Authentication Credential Types Registry  . . . . .  24
       8.4.  Expert Review Instructions  . . . . . . . . . . . . . . .  25
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  26
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  26
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  28
     Appendix A.  Document Updates . . . . . . . . . . . . . . . . . .  28
       A.1.  Version -10 to -11  . . . . . . . . . . . . . . . . . . .  28
       A.2.  Version -09 to -10  . . . . . . . . . . . . . . . . . . .  29
       A.3.  Version -08 to -09  . . . . . . . . . . . . . . . . . . .  29
       A.4.  Version -07 to -08  . . . . . . . . . . . . . . . . . . .  29
       A.5.  Version -06 to -07  . . . . . . . . . . . . . . . . . . .  29
       A.6.  Version -05 to -06  . . . . . . . . . . . . . . . . . . .  30
       A.7.  Version -04 to -05  . . . . . . . . . . . . . . . . . . .  30
       A.8.  Version -03 to -04  . . . . . . . . . . . . . . . . . . .  31
       A.9.  Version -02 to -03  . . . . . . . . . . . . . . . . . . .  31
       A.10. Version -01 to -02  . . . . . . . . . . . . . . . . . . .  32
       A.11. Version -00 to -01  . . . . . . . . . . . . . . . . . . .  32
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  32
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32

  1.  Introduction

     Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528] is a lightweight
     authenticated key exchange protocol, especially intended for use in
     constrained scenarios.  In particular, EDHOC messages can be
     transported over the Constrained Application Protocol (CoAP)
     [RFC7252] and used for establishing a Security Context for Object
     Security for Constrained RESTful Environments (OSCORE) [RFC8613].

     This document details the use of the EDHOC protocol with CoAP and
     OSCORE, and specifies a number of additional and optional mechanisms.
     These especially include an optimization approach that combines the
     EDHOC execution with the first OSCORE transaction (see Section 3).
     This allows for a minimum number of two round trips necessary to
     setup the OSCORE Security Context and complete an OSCORE transaction,
     e.g., when an IoT device gets configured in a network for the first
     time.

     This optimization is desirable, since the number of message exchanges
     can have a substantial impact on the latency of conveying the first
     OSCORE request, when using certain radio technologies.







  Palombini, et al.        Expires 11 October 2024                [Page 3]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


     Without this optimization, it is not possible to achieve the minimum
     number of two round trips.  This optimization makes it possible,
     since the message_3 of the EDHOC protocol can be made relatively
     small (see Section 1.2 of [RFC9528]), thus allowing additional
     OSCORE-protected CoAP data within target MTU sizes.

     The minimum number of two round trips can be achieved only if the
     default, forward message flow of EDHOC is used, i.e., when a CoAP
     client acts as EDHOC Initiator and a CoAP server acts as EDHOC
     Responder.  The performance advantage of using this optimization can
     be lost when used in combination with Block-wise transfers [RFC7959]
     that rely on specific parameter values and block sizes.

     Furthermore, this document defines a number of parameters
     corresponding to different information elements of an EDHOC
     application profile (see Section 6).  These can be specified as
     target attributes in the link to an EDHOC resource associated with
     that application profile, thus enabling an enhanced discovery of such
     a resource for CoAP clients.

  1.1.  Terminology

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

     The reader is expected to be familiar with terms and concepts defined
     in CoAP [RFC7252], CBOR [RFC8949], OSCORE [RFC8613], and EDHOC
     [RFC9528].

  2.  EDHOC Overview

     This section is not normative and summarizes what is specified in
     [RFC9528], in particular its Appendix A.2.  Thus, it provides a
     baseline for the enhancements in the subsequent sections.

     The EDHOC protocol specified in [RFC9528] allows two peers to agree
     on a cryptographic secret, in a mutually-authenticated way and by
     using Diffie-Hellman ephemeral keys to achieve forward secrecy.  The
     two peers are denoted as Initiator and Responder, as the one sending
     or receiving the initial EDHOC message_1, respectively.








  Palombini, et al.        Expires 11 October 2024                [Page 4]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


     After successful processing of EDHOC message_3, both peers agree on a
     cryptographic secret that can be used to derive further security
     material, and especially to establish an OSCORE Security Context
     [RFC8613].  The Responder can also send an optional EDHOC message_4
     to achieve key confirmation, e.g., in deployments where no protected
     application message is sent from the Responder to the Initiator.

     Appendix A.2 of [RFC9528] specifies how to transfer EDHOC over CoAP.
     That is, the EDHOC data (i.e., the EDHOC message possibly with a
     prepended connection identifier) are transported in the payload of
     CoAP requests and responses.  The default, forward message flow of
     EDHOC consists in the CoAP client acting as Initiator and the CoAP
     server acting as Responder (see Appendix A.2.1 of [RFC9528]).
     Alternatively, the two roles can be reversed, as per the reverse
     message flow of EDHOC (see Appendix A.2.2 of [RFC9528]).  In the rest
     of this document, EDHOC messages are considered to be transferred
     over CoAP.

     Figure 1 shows a successful execution of EDHOC, with a CoAP client
     and a CoAP server running EDHOC as Initiator and Responder,
     respectively.  In particular, it extends Figure 10 from
     Appendix A.2.1 of [RFC9528], by highlighting when the two peers
     perform EDHOC verification and establish the OSCORE Security Context,
     and by adding an exchange of OSCORE-protected CoAP messages after
     completing the EDHOC execution.

     That is, the client sends a POST request to a reserved _EDHOC
     resource_ at the server, by default at the Uri-Path "/.well-known/
     edhoc".  The request payload consists of the CBOR simple value true
     (0xf5) concatenated with EDHOC message_1, which also includes the
     EDHOC connection identifier C_I of the client encoded as per
     Section 3.3 of [RFC9528].  The request has Content-Format
     application/cid-edhoc+cbor-seq.

     This triggers the EDHOC execution at the server, which replies with a
     2.04 (Changed) response.  The response payload consists of EDHOC
     message_2, which also includes the EDHOC connection identifier C_R of
     the server encoded as per Section 3.3 of [RFC9528].  The response has
     Content-Format application/edhoc+cbor-seq.

     Finally, the client sends a POST request to the same EDHOC resource
     used earlier when it sent EDHOC message_1.  The request payload
     consists of the EDHOC connection identifier C_R encoded as per
     Section 3.3 of [RFC9528], concatenated with EDHOC message_3.  The
     request has Content-Format application/cid-edhoc+cbor-seq.






  Palombini, et al.        Expires 11 October 2024                [Page 5]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


     After this exchange takes place, and after successful verifications
     as specified in the EDHOC protocol, the client and server can derive
     an OSCORE Security Context, as defined in Appendix A.1 of [RFC9528].
     After that, they can use OSCORE to protect their communications as
     per [RFC8613].  Note that the EDHOC Connection Identifier C_R is used
     as the OSCORE Sender ID of the client (see Appendix A.1 of
     [RFC9528]).  Therefore, C_R is transported in the 'kid' field of the
     OSCORE Option of the OSCORE Request (see Section 6.1 of [RFC8613]).

     The client and server are required to agree in advance on certain
     information and parameters describing how they should use EDHOC.
     These are specified in an application profile associated with the
     EDHOC resource addressed (see Section 3.9 of [RFC9528].






































  Palombini, et al.        Expires 11 October 2024                [Page 6]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


        CoAP client                                         CoAP server
      (EDHOC Initiator)                                 (EDHOC Responder)
             |                                                    |
             |                                                    |
             | ----------------- EDHOC Request -----------------> |
             |   Header: 0.02 (POST)                              |
             |   Uri-Path: "/.well-known/edhoc"                   |
             |   Content-Format: application/cid-edhoc+cbor-seq   |
             |   Payload: true, EDHOC message_1                   |
             |                                                    |
             | <---------------- EDHOC Response------------------ |
             |       Header: 2.04 (Changed)                       |
             |       Content-Format: application/edhoc+cbor-seq   |
             |       Payload: EDHOC message_2                     |
             |                                                    |
      EDHOC verification                                          |
             |                                                    |
             | ----------------- EDHOC Request -----------------> |
             |   Header: 0.02 (POST)                              |
             |   Uri-Path: "/.well-known/edhoc"                   |
             |   Content-Format: application/cid-edhoc+cbor-seq   |
             |   Payload: C_R, EDHOC message_3                    |
             |                                                    |
             |                                         EDHOC verification
             |                                                    +
             |                                            OSCORE Sec Ctx
             |                                             Derivation
             |                                                    |
             | <---------------- EDHOC Response------------------ |
             |       Header: 2.04 (Changed)                       |
             |       Content-Format: application/edhoc+cbor-seq   |
             |       Payload: EDHOC message_4                     |
             |                                                    |
      OSCORE Sec Ctx                                              |
       Derivation                                                 |
             |                                                    |
             | ---------------- OSCORE Request -----------------> |
             |   Header: 0.02 (POST)                              |
             |   OSCORE: { ... ; kid: C_R }                       |
             |   Payload: OSCORE-protected data                   |
             |                                                    |
             | <--------------- OSCORE Response ----------------- |
             |                 Header: 2.04 (Changed)             |
             |                 OSCORE: { ... }                    |
             |                 Payload: OSCORE-protected data     |
             |                                                    |





  Palombini, et al.        Expires 11 October 2024                [Page 7]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


           Figure 1: EDHOC and OSCORE run sequentially.  The optional
                     message_4 is included in this example.

     As shown in Figure 1, this sequential flow where EDHOC is run first
     and then OSCORE is used takes three round trips to complete.

     Section 3 defines an optimization for combining EDHOC with the first
     OSCORE transaction.  This reduces the number of round trips required
     to set up an OSCORE Security Context and to complete an OSCORE
     transaction using that Security Context.

  3.  EDHOC Combined with OSCORE

     This section defines an optimization for combining the EDHOC message
     exchange with the first OSCORE transaction, thus minimizing the
     number of round trips between the two peers to the absolute possible
     minimum of two round trips.

     To this end, this approach can be used only if the default, forward
     message flow of EDHOC is used, i.e., when the client acts as
     Initiator and the server acts as Responder.  The same is not possible
     in the case with reversed roles as per the reverse message flow of
     EDHOC.

     When running the sequential flow of Section 2, the client has all the
     information to derive the OSCORE Security Context already after
     receiving EDHOC message_2 and before sending EDHOC message_3.

     Hence, the client can potentially send both EDHOC message_3 and the
     subsequent OSCORE Request at the same time.  On a semantic level,
     this requires sending two REST requests at once, as in Figure 2.




















  Palombini, et al.        Expires 11 October 2024                [Page 8]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


       CoAP client                                          CoAP server
     (EDHOC Initiator)                                  (EDHOC Responder)
            |                                                     |
            | ------------------ EDHOC Request -----------------> |
            |   Header: 0.02 (POST)                               |
            |   Uri-Path: "/.well-known/edhoc"                    |
            |   Content-Format: application/cid-edhoc+cbor-seq    |
            |   Payload: true, EDHOC message_1                    |
            |                                                     |
            | <----------------- EDHOC Response------------------ |
            |        Header: Changed (2.04)                       |
            |        Content-Format: application/edhoc+cbor-seq   |
            |        Payload: EDHOC message_2                     |
            |                                                     |
     EDHOC verification                                           |
            +                                                     |
      OSCORE Sec Ctx                                              |
        Derivation                                                |
            |                                                     |
            | -------------- EDHOC + OSCORE Request ------------> |
            |   Header: 0.02 (POST)                               |
            |   OSCORE: { ... ; kid: C_R }                        |
            |   Payload: EDHOC message_3 + OSCORE-protected data  |
            |                                                     |
            |                                          EDHOC verification
            |                                                     +
            |                                            OSCORE Sec Ctx
            |                                               Derivation
            |                                                     |
            | <--------------- OSCORE Response ------------------ |
            |                    Header: 2.04 (Changed)           |
            |                    OSCORE: { ... }                  |
            |                    Payload: OSCORE-protected data   |
            |                                                     |

                      Figure 2: EDHOC and OSCORE combined.

     To this end, the specific approach defined in this section consists
     of sending a single EDHOC + OSCORE request, which conveys the pair
     (C_R, EDHOC message_3) within an OSCORE-protected CoAP message.

     That is, the EDHOC + OSCORE request is composed of the following two
     parts combined together in a single CoAP message.  The steps for
     processing the EDHOC + OSCORE request and the two parts combined in
     there are defined in Section 3.2.1 and Section 3.3.1.






  Palombini, et al.        Expires 11 October 2024                [Page 9]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


     *  The OSCORE Request from Figure 1, which is also in this case sent
        to a protected resource, with the correct CoAP method and options
        intended for accessing that resource.

     *  EDHOC data consisting of the pair (C_R, EDHOC message_3) required
        for completing the EDHOC session, transported as follows:

        -  C_R is the OSCORE Sender ID of the client and hence transported
           in the 'kid' field of the OSCORE Option (see Section 6.1 of
           [RFC8613]).  Unlike in the sequential workflow shown in
           Figure 1, C_R is thus not transported in the payload of the
           EDHOC + OSCORE request.

        -  EDHOC message_3 is transported in the payload of the EDHOC +
           OSCORE request, prepended to the payload of the OSCORE Request.
           This is because EDHOC message_3 may be too large to be included
           in a CoAP Option, e.g., when conveying a large public key
           certificate chain as ID_CRED_I (see Section 3.5.3 of [RFC9528])
           or when conveying large External Authorization Data as EAD_3
           (see Section 3.8 of [RFC9528]).

     The rest of this section specifies how to transport the data in the
     EDHOC + OSCORE request and their processing order.  In particular,
     the use of this approach is explicitly signalled by including an
     EDHOC Option (see Section 3.1) in the EDHOC + OSCORE request.  The
     processing of the EDHOC + OSCORE request is specified in Section 3.2
     for the client side and in Section 3.3 for the server side.

  3.1.  EDHOC Option

     This section defines the EDHOC Option.  The option is used in a CoAP
     request, to signal that the request payload conveys both an EDHOC
     message_3 and OSCORE-protected data, combined together.

     The EDHOC Option has the properties summarized in Table 1, which
     extends Table 4 of [RFC7252].  The option is Critical, Safe-to-
     Forward, and part of the Cache-Key. The option MUST occur at most
     once and MUST be empty.  If any value is sent, the recipient MUST
     ignore it.  (Future documents may update the definition of the
     option, by expanding its semantics and specifying admitted values.)
     The option is intended only for CoAP requests and is of Class U for
     OSCORE [RFC8613].









  Palombini, et al.        Expires 11 October 2024               [Page 10]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


          +=====+===+===+===+===+=======+========+========+=========+
          | No. | C | U | N | R | Name  | Format | Length | Default |
          +=====+===+===+===+===+=======+========+========+=========+
          | 21  | x |   |   |   | EDHOC | Empty  | 0      | (none)  |
          +-----+---+---+---+---+-------+--------+--------+---------+

               Table 1: The EDHOC Option.  C=Critical, U=Unsafe,
                           N=NoCacheKey, R=Repeatable

     The presence of this option means that the message payload also
     contains EDHOC data, which must be extracted and processed as defined
     in Section 3.3, before the rest of the message can be processed.

     Figure 3 shows an example of a CoAP message transported over UDP and
     containing both the EDHOC data and the OSCORE ciphertext, using the
     newly defined EDHOC option for signalling.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Ver| T |  TKL  |      Code     |          Message ID           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Token (if any, TKL bytes) ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Observe Option| OSCORE Option ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | EDHOC Option  | Other Options (if any) ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1 1 1 1 1 1 1 1| Payload ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 3: Example of CoAP message transported over UDP, combining
         EDHOC data and OSCORE data as signalled with the EDHOC Option.

  3.2.  Client Processing

     This section describes the processing on the client side.

  3.2.1.  Processing of the EDHOC + OSCORE Request

     The client prepares an EDHOC + OSCORE request as follows.

     1.  Compose EDHOC message_3 into EDHOC_MSG_3, as per Section 5.4.2 of
         [RFC9528].

     2.  Establish the new OSCORE Security Context and use it to encrypt
         the original CoAP request as per Section 8.1 of [RFC8613].




  Palombini, et al.        Expires 11 October 2024               [Page 11]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


         Note that the OSCORE ciphertext is not computed over EDHOC
         message_3, which is not protected by OSCORE.  That is, the result
         of this step is the OSCORE Request as in Figure 1.

     3.  Build COMB_PAYLOAD as the concatenation of EDHOC_MSG_3 and
         OSCORE_PAYLOAD in this order: COMB_PAYLOAD = EDHOC_MSG_3 |
         OSCORE_PAYLOAD, where | denotes byte string concatenation and:

         *  EDHOC_MSG_3 is the binary encoding of EDHOC message_3
            resulting from step 1.  As per Section 5.4.1 of [RFC9528],
            EDHOC message_3 consists of one CBOR data item CIPHERTEXT_3,
            which is a CBOR byte string.  Therefore, EDHOC_MSG_3 is the
            binary encoding of CIPHERTEXT_3.

         *  OSCORE_PAYLOAD is the OSCORE ciphertext of the OSCORE-
            protected CoAP request resulting from step 2.

     4.  Compose the EDHOC + OSCORE request, as the OSCORE-protected CoAP
         request resulting from step 2, where the payload is replaced with
         COMB_PAYLOAD built at step 3.

         Note that the new payload includes EDHOC message_3, but it does
         not include the EDHOC connection identifier C_R.  As the client
         is the EDHOC Initiator, C_R is the OSCORE Sender ID of the
         client, which is already specified as 'kid' in the OSCORE Option
         of the request from step 2, hence of the EDHOC + OSCORE request.

     5.  Include the new EDHOC Option defined in Section 3.1 into the
         EDHOC + OSCORE request.

         The application/cid-edhoc+cbor-seq media type does not apply to
         this message, whose media type is unnamed.

     6.  Send the EDHOC + OSCORE request to the server.

     With the same server, the client SHOULD NOT have multiple
     simultaneous outstanding interactions (see Section 4.7 of [RFC7252])
     such that: they consist of an EDHOC + OSCORE request; and their EDHOC
     data pertain to the EDHOC session with the same connection identifier
     C_R.

     (An exception might apply for clients that operate under particular
     time constraints over particularly unreliable networks, thus raising
     the chances to promptly complete the EDHOC execution with the server
     through multiple, simultaneous EDHOC + OSCORE requests.  As discussed
     in Section 7, this does not have any impact in terms of security.)





  Palombini, et al.        Expires 11 October 2024               [Page 12]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


  3.2.2.  Supporting Block-wise

     If Block-wise [RFC7959] is supported, the client may fragment the
     first application CoAP request before protecting it as an original
     message with OSCORE, as defined in Section 4.1.3.4.1 of [RFC8613].

     In such a case, the OSCORE processing in step 2 of Section 3.2.1 is
     performed on each inner block of the first application CoAP request,
     and the following also applies.

     *  The client takes the additional following step between steps 2 and
        3 of Section 3.2.1.

        A.  If the OSCORE-protected request from step 2 conveys a non-
        first inner block of the first application CoAP request (i.e., the
        Block1 Option processed at step 2 had NUM different than 0), then
        the client skips the following steps and sends the OSCORE-
        protected request to the server.  In particular, the client MUST
        NOT include the EDHOC Option in the OSCORE-protected request.

     *  The client takes the additional following step between steps 3 and
        4 of Section 3.2.1.

        B.  If the size of COMB_PAYLOAD exceeds MAX_UNFRAGMENTED_SIZE (see
        Section 4.1.3.4.2 of [RFC8613]), the client MUST stop processing
        the request and MUST abandon the Block-wise transfer.  Then, the
        client can continue by switching to the sequential workflow shown
        in Figure 1.  That is, the client first sends EDHOC message_3
        prepended by the EDHOC Connection Identifier C_R encoded as per
        Section 3.3 of [RFC9528], and then sends the OSCORE-protected CoAP
        request once the EDHOC execution is completed.

     The performance advantage of using the EDHOC + OSCORE request can be
     lost when used in combination with Block-wise transfers that rely on
     specific parameter values and block sizes.  Application policies at
     the CoAP client can define when and how to detect whether the
     performance advantage is lost, and, if that is the case, whether to
     appropriately adjust the parameter values and block sizes, or instead
     to fall back on the sequential workflow of EDHOC.

  3.3.  Server Processing

     This section describes the processing on the server side.

  3.3.1.  Processing of the EDHOC + OSCORE Request

     In order to process a request containing the EDHOC option, i.e., an
     EDHOC + OSCORE request, the server MUST perform the following steps.



  Palombini, et al.        Expires 11 October 2024               [Page 13]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


     1.  Check that the EDHOC + OSCORE request includes the OSCORE option
         and that the request payload has the format defined at step 3 of
         Section 3.2.1 for COMB_PAYLOAD.  If this is not the case, the
         server MUST stop processing the request and MUST reply with a
         4.00 (Bad Request) error response.

     2.  Extract EDHOC message_3 from the payload COMB_PAYLOAD of the
         EDHOC + OSCORE request, as the first element EDHOC_MSG_3 (see
         step 3 of Section 3.2.1).

     3.  Take the value of 'kid' from the OSCORE option of the EDHOC +
         OSCORE request (i.e., the OSCORE Sender ID of the client), and
         use it as the EDHOC connection identifier C_R.

     4.  Retrieve the correct EDHOC session by using the connection
         identifier C_R from step 3.

         If the application profile used in the EDHOC session specifies
         that EDHOC message_4 shall be sent, the server MUST stop the
         EDHOC processing and consider it failed, as due to a client
         error.

         Otherwise, perform the EDHOC processing on the EDHOC message_3
         extracted at step 2 as per Section 5.4.3 of [RFC9528], based on
         the protocol state of the retrieved EDHOC session.

         The application profile used in the EDHOC session is the same one
         associated with the EDHOC resource where the server received the
         request conveying EDHOC message_1 that started the session.  This
         is relevant in case the server provides multiple EDHOC resources,
         which may generally refer to different application profiles.

     5.  Establish a new OSCORE Security Context associated with the
         client as per Appendix A.1 of [RFC9528], using the EDHOC output
         from step 4.

     6.  Extract the OSCORE ciphertext from the payload COMB_PAYLOAD of
         the EDHOC + OSCORE request, as the second element OSCORE_PAYLOAD
         (see step 3 of Section 3.2.1).

     7.  Rebuild the OSCORE-protected CoAP request, as the EDHOC + OSCORE
         request where the payload is replaced with the OSCORE ciphertext
         extracted at step 6.  Then, remove the EDHOC option.

     8.  Decrypt and verify the OSCORE-protected CoAP request rebuilt at
         step 7, as per Section 8.2 of [RFC8613], by using the OSCORE
         Security Context established at step 5.




  Palombini, et al.        Expires 11 October 2024               [Page 14]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


         When the decrypted request is checked for any critical CoAP
         options (as it is during regular CoAP processing), the presence
         of an EDHOC option MUST be regarded as an unprocessed critical
         option, unless it is processed by some further mechanism.

     9.  Deliver the CoAP request resulting from step 8 to the
         application.

     If steps 4 (EDHOC processing) and 8 (OSCORE processing) are both
     successfully completed, the server MUST reply with an OSCORE-
     protected response (see Section 5.4.3 of [RFC9528]).  The usage of
     EDHOC message_4 as defined in Section 5.5 of [RFC9528] is not
     applicable to the approach defined in this document.

     If step 4 (EDHOC processing) fails, the server aborts the session as
     per Section 5.4.3 of [RFC9528] and responds with an EDHOC error
     message with error code 1, formatted as defined in Section 6.2 of
     [RFC9528].  The server MUST NOT establish a new OSCORE Security
     Context from the present EDHOC session with the client.  The CoAP
     response conveying the EDHOC error message is not protected with
     OSCORE.  As per Section 9.5 of [RFC9528], the server has to make sure
     that the error message does not reveal sensitive information.  The
     CoAP response conveying the EDHOC error message MUST have Content-
     Format set to application/edhoc+cbor-seq registered in Section 10.9
     of [RFC9528].

     If step 4 (EDHOC processing) is successfully completed but step 8
     (OSCORE processing) fails, the same OSCORE error handling as defined
     in Section 8.2 of [RFC8613] applies.

  3.3.2.  Supporting Block-wise

     If Block-wise [RFC7959] is supported, the server takes the additional
     following step before any other in Section 3.3.1.

     A.  If Block-wise is present in the request, then process the Outer
     Block options according to [RFC7959], until all blocks of the request
     have been received (see Section 4.1.3.4 of [RFC8613]).

  3.4.  Example of EDHOC + OSCORE Request

     Figure 4 shows an example of EDHOC + OSCORE Request transported over
     UDP.  In particular, the example assumes that:

     *  The OSCORE Partial IV in use is 0, consistently with the first
        request protected with the new OSCORE Security Context.

     *  The OSCORE Sender ID of the client is 0x01.



  Palombini, et al.        Expires 11 October 2024               [Page 15]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


        As per Section 3.3.3 of [RFC9528], this straightforwardly
        corresponds to the EDHOC connection identifier C_R 0x01.

        As per Section 3.3.2 of [RFC9528], when using the sequential flow
        shown in Figure 1, the same C_R with value 0x01 would be encoded
        on the wire as the CBOR integer 1 (0x01 in CBOR encoding), and
        prepended to EDHOC message_3 in the payload of the second EDHOC
        request.

     *  The EDHOC option is registered with CoAP option number 21.

     Note to RFC Editor: Please delete the last bullet point in the
     previous list, since, at the time of publication, the CoAP option
     number will be in fact registered.

     This results in the following components shown in Figure 4:

     *  OSCORE option value: 0x090001 (3 bytes)

     *  EDHOC option value: - (0 bytes)

     *  EDHOC message_3: 0x52d5535f3147e85f1cfacd9e78abf9e0a81bbf (19
        bytes)

     *  OSCORE ciphertext: 0x612f1092f1776f1c1668b3825e (13 bytes)

               Protected CoAP request (OSCORE message):

                  0x44025d1f               ; CoAP 4-byte header
                    00003974               ; Token
                    93 090001              ; OSCORE Option
                    c0                     ; EDHOC Option
                    ff 52d5535f3147e85f1cfacd9e78abf9e0a81bbf
                       612f1092f1776f1c1668b3825e
                  (46 bytes)

       Figure 4: Example of CoAP message transported over UDP, combining
         EDHOC data and OSCORE data as signalled with the EDHOC Option.

  4.  Use of EDHOC Connection Identifiers with OSCORE

     The OSCORE Sender/Recipient IDs are the EDHOC connection identifiers
     (see Section 3.3.3 of [RFC9528]).  This applies also to the optimized
     workflow defined in Section 3 of this document.







  Palombini, et al.        Expires 11 October 2024               [Page 16]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


     Note that, at step 3 of Section 3.3.1, the value of 'kid' in the
     OSCORE Option of the EDHOC + OSCORE request is both the server's
     Recipient ID (i.e., the client's Sender ID) and the EDHOC Connection
     Identifier C_R of the server.

  4.1.  Additional Processing of EDHOC Messages

     When using EDHOC to establish an OSCORE Security Context, the client
     and server MUST perform the following additional steps during an
     EDHOC execution, thus extending Section 5 of [RFC9528].

  4.1.1.  Initiator Processing of Message 1

     The Initiator selects an EDHOC Connection Identifier C_I as follows.

     The Initiator MUST choose a C_I that is neither used in any current
     EDHOC session as this peer's EDHOC Connection Identifier, nor the
     Recipient ID in a current OSCORE Security Context where the ID
     Context is not present.

     The chosen C_I SHOULD NOT be the Recipient ID of any current OSCORE
     Security Context.  Note that, unless the two peers concurrently use
     alternative methods to establish OSCORE Security Contexts, this
     allows the Responder to always omit the 'kid context' in the OSCORE
     Option of its messages sent to the Initiator, when protecting those
     with an OSCORE Security Context where C_I is the Responder's OSCORE
     Sender ID (see Section 6.1 of [RFC8613]).

  4.1.2.  Responder Processing of Message 2

     The Responder selects an EDHOC Connection Identifier C_R as follows.

     The Responder MUST choose a C_R that is neither used in any current
     EDHOC session as this peer's EDHOC Connection Identifier, nor is
     equal to the EDHOC Connection Identifier C_I specified in the EDHOC
     message_1 of the present EDHOC session, nor is the Recipient ID in a
     current OSCORE Security Context where the ID Context is not present.

     The chosen C_R SHOULD NOT be the Recipient ID of any current OSCORE
     Security Context.  Note that, for a reason analogous to the one given
     above with C_I, this allows the Initiator to always omit the 'kid
     context' in the OSCORE Option of its messages sent to the Responder,
     when protecting those with an OSCORE Security Context where C_R is
     the Initiator's OSCORE Sender ID (see Section 6.1 of [RFC8613]).







  Palombini, et al.        Expires 11 October 2024               [Page 17]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


  4.1.3.  Initiator Processing of Message 2

     If the EDHOC Connection Identifier C_I is equal to the EDHOC
     Connection Identifier C_R specified in EDHOC message_2, then the
     Initiator MUST abort the session and reply with an EDHOC error
     message with error code 1, formatted as defined in Section 6.2 of
     [RFC9528].

  5.  Extension and Consistency of Application Profiles

     It is possible to include the information below in the application
     profile referred by the client and server, according to the specified
     consistency rules.

     If the server supports the EDHOC + OSCORE request within an EDHOC
     execution started at a certain EDHOC resource, then the application
     profile associated with that resource SHOULD explicitly specify
     support for the EDHOC + OSCORE request.

     In case the application profile indicates that the server supports
     the optional EDHOC message_4 (see Section 5.5 of [RFC9528]), it is
     still possible to use the optimized workflow based on the EDHOC +
     OSCORE request.  However, this means the server is not going to send
     EDHOC message_4, since it is not applicable to the optimized workflow
     (see Section 3.3.1).

     Also, in case the application profile indicates that the server shall
     send EDHOC message_4, then the application profile MUST NOT specify
     support for the EDHOC + OSCORE request, and there is no point for the
     client to use the optimized workflow, which is bound to fail (see
     Section 3.3.1).

  6.  Web Linking

     Section 10.10 of [RFC9528] registers the resource type "core.edhoc",
     which can be used as target attribute in a web link [RFC8288] to an
     EDHOC resource, e.g., using a link-format document [RFC6690].  This
     enables clients to discover the presence of EDHOC resources at a
     server, possibly using the resource type as filter criterion.












  Palombini, et al.        Expires 11 October 2024               [Page 18]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


     At the same time, the application profile associated with an EDHOC
     resource provides information describing how the EDHOC protocol can
     be used through that resource.  A client may become aware of the
     application profile, e.g., by obtaining its information elements upon
     discovering the EDHOC resources at the server.  This allows the
     client to discover especially the EDHOC resources whose associated
     application profile denotes a way of using EDHOC which is most
     suitable to the client, e.g., with EDHOC cipher suites or
     authentication methods that the client also supports or prefers.

     That is, while discovering an EDHOC resource, a client can
     contextually obtain relevant pieces of information from the
     application profile associated with that resource.  The resource
     discovery can occur by means of a direct interaction with the server,
     or instead by means of the CoRE Resource Directory [RFC9176], where
     the server may have registered the links to its resources.

     In order to enable the above, this section defines a number of
     parameters, each of which can be optionally specified as a target
     attribute with the same name in the link to the respective EDHOC
     resource, or as filter criteria in a discovery request from the
     client.  When specifying these parameters in a link to an EDHOC
     resource, the target attribute rt="core.edhoc" MUST be included, and
     the same consistency rules defined in Section 5 for the corresponding
     information elements of an application profile MUST be followed.

     The following parameters are defined.

     *  'ed-i', specifying, if present, that the server supports the EDHOC
        Initiator role, hence the reverse message flow of EDHOC.  A value
        MUST NOT be given to this parameter and any present value MUST be
        ignored by the recipient.

     *  'ed-r', specifying, if present, that the server supports the EDHOC
        Responder role, hence the forward message flow of EDHOC.  A value
        MUST NOT be given to this parameter and any present value MUST be
        ignored by the recipient.

     *  'ed-method', specifying an authentication method supported by the
        server.  This parameter MUST specify a single value, which is
        taken from the 'Value' column of the "EDHOC Method Type" registry
        defined in Section 10.3 of [RFC9528].  This parameter MAY occur
        multiple times, with each occurrence specifying an authentication
        method.

     *  'ed-csuite', specifying an EDHOC cipher suite supported by the
        server.  This parameter MUST specify a single value, which is
        taken from the 'Value' column of the "EDHOC Cipher Suites"



  Palombini, et al.        Expires 11 October 2024               [Page 19]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


        registry defined in Section 10.2 of [RFC9528].  This parameter MAY
        occur multiple times, with each occurrence specifying a cipher
        suite.

     *  'ed-cred-t', specifying a type of authentication credential
        supported by the server.  This parameter MUST specify a single
        value, which is taken from the 'Value' column of the "EDHOC
        Authentication Credential Types" Registry defined in Section 8.3
        of this document.  This parameter MAY occur multiple times, with
        each occurrence specifying a type of authentication credential.

     *  'ed-idcred-t', specifying a type of identifier supported by the
        server for identifying authentication credentials.  This parameter
        MUST specify a single value, which is taken from the 'Label'
        column of the "COSE Header Parameters" registry
        [COSE.Header.Parameters].  This parameter MAY occur multiple
        times, with each occurrence specifying a type of identifier for
        authentication credentials.

        Note that the values in the 'Label' column of the "COSE Header
        Parameters" registry are strongly typed.  On the contrary, Link
        Format is weakly typed and thus does not distinguish between, for
        instance, the string value "-10" and the integer value -10.  Thus,
        if responses in Link Format are returned, string values which look
        like an integer are not supported.  Therefore, such values MUST
        NOT be used in the 'ed-idcred-t' parameter.

     *  'ed-ead', specifying the support of the server for an External
        Authorization Data (EAD) item (see Section 3.8 of [RFC9528]).
        This parameter MUST specify a single value, which is taken from
        the 'Label' column of the "EDHOC External Authorization Data"
        registry defined in Section 10.5 of [RFC9528].  This parameter MAY
        occur multiple times, with each occurrence specifying the
        ead_label of an EAD item that the server supports.

     *  'ed-comb-req', specifying, if present, that the server supports
        the EDHOC + OSCORE request defined in Section 3.  A value MUST NOT
        be given to this parameter and any present value MUST be ignored
        by the recipient.

     (Future documents may update the definition of the parameters 'ed-i',
     'ed-r', and 'ed-comb-req', by expanding their semantics and
     specifying what they can take as value.)

     The example in Figure 5 shows how a client discovers one EDHOC
     resource at a server, obtaining information elements from the
     respective application profile.  The Link Format notation from
     Section 5 of [RFC6690] is used.



  Palombini, et al.        Expires 11 October 2024               [Page 20]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


        REQ: GET /.well-known/core

        RES: 2.05 Content
            </sensors/temp>;osc,
            </sensors/light>;if=sensor,
            </.well-known/edhoc>;rt=core.edhoc;ed-csuite=0;ed-csuite=2;
                ed-method=0;ed-cred-t=1;ed-cred-t=3;ed-idcred-t=4;
                ed-i;ed-r;ed-comb-req

                            Figure 5: The Web Link.

  7.  Security Considerations

     The same security considerations from OSCORE [RFC8613] and EDHOC
     [RFC9528] hold for this document.  In addition, the following
     considerations also apply.

     Section 3.2.1 specifies that a client SHOULD NOT have multiple
     outstanding EDHOC + OSCORE requests pertaining to the same EDHOC
     session.  Even if a client did not fulfill this requirement, it would
     not have any impact in terms of security.  That is, the server would
     still not process different instances of the same EDHOC message_3
     more than once in the same EDHOC session (see Section 5.1 of
     [RFC9528]), and would still enforce replay protection of the OSCORE-
     protected request (see Sections 7.4 and 8.2 of [RFC8613]).

     When using the optimized workflow in Figure 2, a minimum of 128-bit
     security against online brute force attacks is achieved after the
     client receives and successfully verifies the first OSCORE-protected
     response (see Sections 9.1 and 9.4 of [RFC9528]).  As an example, if
     EDHOC is used with method 3 (see Section 3.2 of [RFC9528]) and cipher
     suite 2 (see Section 3.6 of [RFC9528]), then the following holds.

     *  The Initiator is authenticated with 128-bit security against
        online attacks.  As per Section 9.1 of [RFC9528], this results
        from the combination of the strength of the 64-bit MAC in EDHOC
        message_3 and of the 64-bit MAC in the AEAD of the first OSCORE-
        protected CoAP request, as rebuilt at step 7 of Section 3.3.1.

     *  The Responder is authenticated with 128-bit security against
        online attacks.  As per Section 9.1 of [RFC9528], this results
        from the combination of the strength of the 64-bit MAC in EDHOC
        message_2 and of the 64-bit MAC in the AEAD of the first OSCORE-
        protected CoAP response.







  Palombini, et al.        Expires 11 October 2024               [Page 21]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


     With reference to the sequential workflow in Figure 1, the OSCORE
     request might have to undergo access control checks at the server,
     before being actually executed for accessing the target protected
     resource.  The same MUST hold when the optimized workflow in Figure 2
     is used, i.e., when using the EDHOC + OSCORE request.

     That is, the rebuilt OSCORE-protected application request from step 7
     in Section 3.3.1 MUST undergo the same access control checks that
     would be performed on a traditional OSCORE-protected application
     request sent individually as shown in Figure 1.

     To this end, validated information to perform access control checks
     (e.g., an access token issued by a trusted party) has to be available
     at the server before starting to process the rebuilt OSCORE-protected
     application request.  Such information may have been provided to the
     server separately before starting the EDHOC execution altogether, or
     instead as External Authorization Data during the EDHOC execution
     (see Section 3.8 of [RFC9528]).

     Thus, a successful completion of the EDHOC protocol and the following
     derivation of the OSCORE Security Context at the server do not play a
     role in determining whether the rebuilt OSCORE-protected request is
     authorized to access the target protected resource at the server.

  8.  IANA Considerations

     This document has the following actions for IANA.

     Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]"
     with the RFC number of this specification and delete this paragraph.

  8.1.  CoAP Option Numbers Registry

     IANA is asked to enter the following option number to the "CoAP
     Option Numbers" registry within the "CoRE Parameters" registry group.

                        +========+=======+============+
                        | Number | Name  | Reference  |
                        +========+=======+============+
                        | 21     | EDHOC | [RFC-XXXX] |
                        +--------+-------+------------+

                           Table 2: Registrations in
                              CoAP Option Numbers
                                    Registry

     Note to RFC Editor: Please delete this paragraph and all the
     following text within the present Section 8.1.



  Palombini, et al.        Expires 11 October 2024               [Page 22]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


     [

     The CoAP option number 21 is consistent with the properties of the
     EDHOC Option defined in Section 3.1, and it allows the EDHOC Option
     to always result in an overall size of 1 byte.  This is because:

     *  The EDHOC option is always empty, i.e., with zero-length value;
        and

     *  Since the OSCORE Option with option number 9 is always present in
        the EDHOC + OSCORE request, the EDHOC Option is encoded with a
        delta equal to at most 12.

     Although the currently unassigned option number 13 would also work
     well for the same reasons in the use case in question, different use
     cases or protocols may make a better use of the option number 13.
     Hence the preference for the option number 21, and why it is _not_
     necessary to register additional option numbers than 21.

     ]

  8.2.  Target Attributes Registry

     IANA is asked to register the following entries in the "Target
     Attributes" registry [CORE.Target.Attributes] within the "Constrained
     RESTful Environments (CoRE) Parameters" registry group, as per
     [I-D.ietf-core-target-attr].  For all entries, the Change Controller
     is IETF, and the reference is [RFC-XXXX].























  Palombini, et al.        Expires 11 October 2024               [Page 23]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


       +=================+=============================================+
       | Attribute Name: | Brief Description:                          |
       +=================+=============================================+
       | ed-i            | Hint: support for the EDHOC Initiator role  |
       +-----------------+---------------------------------------------+
       | ed-r            | Hint: support for the EDHOC Responder role  |
       +-----------------+---------------------------------------------+
       | ed-method       | A supported authentication method for EDHOC |
       +-----------------+---------------------------------------------+
       | ed-csuite       | A supported cipher suite for EDHOC          |
       +-----------------+---------------------------------------------+
       | ed-cred-t       | A supported type of authentication          |
       |                 | credential for EDHOC                        |
       +-----------------+---------------------------------------------+
       | ed-idcred-t     | A supported type of authentication          |
       |                 | credential identifier for EDHOC             |
       +-----------------+---------------------------------------------+
       | ed-ead          | A supported External Authorization Data     |
       |                 | (EAD) item for EDHOC                        |
       +-----------------+---------------------------------------------+
       | ed-comb-req     | Hint: support for the EDHOC+OSCORE request  |
       +-----------------+---------------------------------------------+

              Table 3: Registrations in Target Attributes Registry

  8.3.  EDHOC Authentication Credential Types Registry

     IANA is requested to create a new "EDHOC Authentication Credential
     Types" registry within the "Ephemeral Diffie-Hellman Over COSE
     (EDHOC)" registry group defined in [RFC9528].

     As registration policy, the registry uses either "Standards Action
     with Expert Review", or "Specification Required" per Section 4.6 of
     [RFC8126].  Expert Review guidelines are provided in Section 8.4.

     All assignments according to "Standards Action with Expert Review"
     are made on a "Standards Action" basis per Section 4.9 of [RFC8126],
     with Expert Review additionally required per Section 4.5 of
     [RFC8126].  The procedure for early IANA allocation of Standards
     Track code points defined in [RFC7120] also applies.  When such a
     procedure is used, review and approval by the designated expert are
     also required, in order for the WG chairs to determine that the
     conditions for early allocation are met (see step 2 in Section 3.1 of
     [RFC7120]).

     The columns of this registry are:





  Palombini, et al.        Expires 11 October 2024               [Page 24]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


     *  Value: This field contains the value used to identify the type of
        authentication credential.  These values MUST be unique.  The
        value can be an unsigned integer or a negative integer, in the
        range from -65536 to 65535.  Different ranges of values use
        different registration policies [RFC8126]:

        -  Integer values from -24 to 23 are designated as "Standards
           Action With Expert Review".

        -  Integer values from -65536 to -25 and from 24 to 65535 are
           designated as "Specification Required".

        -  Integer values smaller than -65536 and greater than 65535 are
           marked as "Private Use".

     *  Description: This field contains a short description of the type
        of authentication credential.

     *  Reference: This field contains a pointer to the public
        specification for the type of authentication credential.

     Initial entries in this registry are as listed in Table 4.

      +=======+============================================+===========+
      | Value | Description                                | Reference |
      +=======+============================================+===========+
      | 0     | CBOR Web Token (CWT) containing a COSE_Key | [RFC8392] |
      |       | in a 'cnf' claim and possibly other        |           |
      |       | claims.  CWT is defined in RFC 8392.       |           |
      +-------+--------------------------------------------+-----------+
      | 1     | CWT Claims Set (CCS) containing a COSE_Key | [RFC8392] |
      |       | in a 'cnf' claim and possibly other        |           |
      |       | claims.  CCS is defined in RFC 8392.       |           |
      +-------+--------------------------------------------+-----------+
      | 2     | X.509 certificate                          | [RFC5280] |
      +-------+--------------------------------------------+-----------+

            Table 4: Initial Entries in the "EDHOC Authentication
                          Credential Types" Registry

  8.4.  Expert Review Instructions

     The IANA registry established in this document is defined as
     "Standards Action with Expert Review" or "Specification Required",
     depending on the range of values for which an assignment is
     requested.  This section gives some general guidelines for what the
     experts should be looking for; but they are being designated as
     experts for a reason, so they should be given substantial latitude.



  Palombini, et al.        Expires 11 October 2024               [Page 25]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


     Expert reviewers should take into consideration the following points:

     *  Clarity and correctness of registrations.  Experts are expected to
        check the clarity of purpose and use of the requested entries.
        Experts need to make sure that registered identifiers indicate a
        type of authentication credential whose format and encoding is
        clearly defined in the corresponding specification.  Identifiers
        of types of authentication credentials that do not meet these
        objective of clarity and completeness must not be registered.

     *  Point squatting should be discouraged.  Reviewers are encouraged
        to get sufficient information for registration requests to ensure
        that the usage is not going to duplicate one that is already
        registered and that the point is likely to be used in deployments.
        The zones tagged as "Private Use" are intended for testing
        purposes and closed environments.  Code points in other ranges
        should not be assigned for testing.

     *  Specifications are required for the "Standards Action With Expert
        Review" range of point assignment.  Specifications should exist
        for "Specification Required" ranges, but early assignment before a
        specification is available is considered to be permissible.  When
        specifications are not provided, the description provided needs to
        have sufficient information to identify what the point is being
        used for.

     *  Experts should take into account the expected usage of fields when
        approving point assignment.  The fact that there is a range for
        Standards Track documents does not mean that a Standards Track
        document cannot have points assigned outside of that range.  The
        length of the encoded value should be weighed against how many
        code points of that length are left, the size of device it will be
        used on, and the number of code points left that encode to that
        size.

  9.  References

  9.1.  Normative References

     [CORE.Target.Attributes]
                IANA, "Target Attributes",
                <https://www.iana.org/assignments/core-parameters/core-
                parameters.xhtml#target-attributes>.

     [COSE.Header.Parameters]
                IANA, "COSE Header Parameters",
                <https://www.iana.org/assignments/cose/cose.xhtml#header-
                parameters>.



  Palombini, et al.        Expires 11 October 2024               [Page 26]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [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, DOI 10.17487/RFC5280, May 2008,
                <https://www.rfc-editor.org/rfc/rfc5280>.

     [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
                Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
                <https://www.rfc-editor.org/rfc/rfc6690>.

     [RFC7120]  Cotton, M., "Early IANA Allocation of Standards Track Code
                Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
                2014, <https://www.rfc-editor.org/rfc/rfc7120>.

     [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
                Application Protocol (CoAP)", RFC 7252,
                DOI 10.17487/RFC7252, June 2014,
                <https://www.rfc-editor.org/rfc/rfc7252>.

     [RFC7959]  Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
                the Constrained Application Protocol (CoAP)", RFC 7959,
                DOI 10.17487/RFC7959, August 2016,
                <https://www.rfc-editor.org/rfc/rfc7959>.

     [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                Writing an IANA Considerations Section in RFCs", BCP 26,
                RFC 8126, DOI 10.17487/RFC8126, June 2017,
                <https://www.rfc-editor.org/rfc/rfc8126>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC8288]  Nottingham, M., "Web Linking", RFC 8288,
                DOI 10.17487/RFC8288, October 2017,
                <https://www.rfc-editor.org/rfc/rfc8288>.

     [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
                "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
                May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.






  Palombini, et al.        Expires 11 October 2024               [Page 27]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


     [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
                "Object Security for Constrained RESTful Environments
                (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
                <https://www.rfc-editor.org/rfc/rfc8613>.

     [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
                Representation (CBOR)", STD 94, RFC 8949,
                DOI 10.17487/RFC8949, December 2020,
                <https://www.rfc-editor.org/rfc/rfc8949>.

     [RFC9176]  Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and
                P. van der Stok, "Constrained RESTful Environments (CoRE)
                Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April
                2022, <https://www.rfc-editor.org/rfc/rfc9176>.

     [RFC9528]  Selander, G., Preuß Mattsson, J., and F. Palombini,
                "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528,
                DOI 10.17487/RFC9528, March 2024,
                <https://www.rfc-editor.org/rfc/rfc9528>.

  9.2.  Informative References

     [I-D.ietf-core-target-attr]
                Bormann, C., "CoRE Target Attributes Registry", Work in
                Progress, Internet-Draft, draft-ietf-core-target-attr-06,
                11 October 2023, <https://datatracker.ietf.org/doc/html/
                draft-ietf-core-target-attr-06>.

  Appendix A.  Document Updates

     This section is to be removed before publishing as an RFC.

  A.1.  Version -10 to -11

     *  Avoid using quotation marks for CBOR Simple Values.

     *  Early mentioning of the optimization properties.

     *  Less entries of new IANA registry; made their references
        normative.

     *  Clarified meaning of "Standards Action with Expert Review" policy.

     *  Clarifications, simplified phrasing, and editorial improvements.

     *  Updated references.





  Palombini, et al.        Expires 11 October 2024               [Page 28]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


  A.2.  Version -09 to -10

     *  Expanded acronyms in the document title.

     *  Clarified transport of EDHOC C_R and EDHOC message_3.

     *  Simplified text on the use of EDHOC Connection Identifiers as
        OSCORE Identifiers.

     *  Added the CoAP OSCORE Option in the figures of the EDHOC message
        flows.

     *  Added more pointers to the message processing, now defined in
        dedicated subsections.

     *  Detecting and preventing a loss of performance advantage when
        using Block-wise transfers is for application policies to
        specifiy.

     *  Clarified use of EDHOC application profiles.

     *  Clarified security considerations on the achieved security level.

     *  Fixes and editorial improvements.

  A.3.  Version -08 to -09

     *  Clarified meaning of "EDHOC data".

     *  Improved description of entries for the new IANA registry.

     *  Change Controller changed from "IESG" to "IETF".

     *  Editorial: EDHOC Option number denoted as "21" instead of "TBD21".

     *  Fixed references to sections of draft-ietf-lake-edhoc

     *  Clarifications and editorial improvements.

  A.4.  Version -07 to -08

     *  Fixes and clarifications from the Shepherd's review.

  A.5.  Version -06 to -07

     *  Changed document title.





  Palombini, et al.        Expires 11 October 2024               [Page 29]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


     *  The client creates the OSCORE Security Context after creating
        EDHOC message_3.

     *  Revised selection of EDHOC connection identifiers.

     *  Use of "forward message flow" and "reverse message flow".

     *  The payload of the combined request is not a CBOR sequence
        anymore.

     *  EDHOC error messages from the server are not protected with
        OSCORE.

     *  More future-proof error handling on the server side.

     *  Target attribute names prefixed by "ed-".

     *  Defined new target attributes "ed-i" and "ed-r".

     *  Defined single target attribute "ed-ead" signaling supported EAD
        items.

     *  Security consideration on the minimally achieved 128-bit security.

     *  Defined and used the "EDHOC Authentication Credential Types"
        Registry.

     *  High-level sentence replacing the appendix on Block-wise
        performance.

     *  Revised examples.

     *  Editorial improvements.

  A.6.  Version -05 to -06

     *  Extended figure on EDHOC sequential workflow.

     *  Revised naming of target attributes.

     *  Clarified semantics of target attributes 'eadx'.

     *  Registration of target attributes.

  A.7.  Version -04 to -05

     *  Clarifications on Web Linking parameters.




  Palombini, et al.        Expires 11 October 2024               [Page 30]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


     *  Added security considerations.

     *  Revised IANA considerations to focus on the CoAP option number 21.

     *  Guidelines on using Block-wise moved to an appendix.

     *  Editorial improvements.

  A.8.  Version -03 to -04

     *  Renamed "applicability statement" to "application profile".

     *  Use the latest Content-Formats.

     *  Use of SHOULD NOT for multiple simultaneous outstanding
        interactions.

     *  No more special conversion from OSCORE ID to EDHOC ID.

     *  Considerations on using Block-wise.

     *  Wed Linking signaling of multiple supported EAD labels.

     *  Added security considerations.

     *  Editorial improvements.

  A.9.  Version -02 to -03

     *  Clarifications on transporting EDHOC message_3 in the CoAP
        payload.

     *  At most one simultaneous outstanding interaction as an EDHOC +
        OSCORE request with the same server for the same session with
        connection identifier C_R.

     *  The EDHOC option is removed from the EDHOC + OSCORE request after
        processing the EDHOC data.

     *  Added explicit constraints when selecting a Recipient ID as C_X.

     *  Added processing steps for when Block-wise is used.

     *  Improved error handling on the server.

     *  Improved section on Web Linking.

     *  Updated figures; editorial improvements.



  Palombini, et al.        Expires 11 October 2024               [Page 31]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


  A.10.  Version -01 to -02

     *  New title, abstract and introduction.

     *  Restructured table of content.

     *  Alignment with latest format of EDHOC messages.

     *  Guideline on ID conversions based on application profile.

     *  Clarifications, extension and consistency on application profile.

     *  Section on web-linking.

     *  RFC8126 terminology in IANA considerations.

     *  Revised Appendix "Checking CBOR Encoding of Numeric Values".

  A.11.  Version -00 to -01

     *  Improved background overview of EDHOC.

     *  Added explicit rules for converting OSCORE Sender/Recipient IDs to
        EDHOC connection identifiers following the removal of
        bstr_identifier from EDHOC.

     *  Revised section organization.

     *  Recommended number for EDHOC option changed to 21.

     *  Editorial improvements.

  Acknowledgments

     The authors sincerely thank Christian Amsüss, Emmanuel Baccelli,
     Carsten Bormann, Roman Danyliw, Esko Dijk, Joel Halpern, Wes
     Hardaker, Klaus Hartke, John Preuß Mattsson, David Navarro, Shuping
     Peng, Jim Schaad, Jürgen Schönwälder, John Scudder, Orie Steele,
     Gunter Van de Velde, Mališa Vučinić, and Paul Wouters for their
     feedback and comments.

     The work on this document has been partly supported by VINNOVA and
     the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home
     (Grant agreement 952652).

  Authors' Addresses





  Palombini, et al.        Expires 11 October 2024               [Page 32]


  Internet-Draft      Using EDHOC with CoAP and OSCORE          April 2024


     Francesca Palombini
     Ericsson
     Email: francesca.palombini@ericsson.com


     Marco Tiloca
     RISE AB
     Isafjordsgatan 22
     SE-16440 Stockholm Kista
     Sweden
     Email: marco.tiloca@ri.se


     Rikard Höglund
     RISE AB
     Isafjordsgatan 22
     SE-16440 Stockholm Kista
     Sweden
     Email: rikard.hoglund@ri.se


     Stefan Hristozov
     Fraunhofer AISEC
     Email: stefan.hristozov@eriptic.com


     Göran Selander
     Ericsson
     Email: goran.selander@ericsson.com






















  Palombini, et al.        Expires 11 October 2024               [Page 33]


name: draft-housley-lamps-private-key-attest-attr
rev: 01
title: An Attribute for Statement of Possession of a Private Key
time: 2025-01-09T18:23:37Z
group_uri: /api/v1/group/group/1027/
expires: 2025-07-13T18:23:37Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:13.081936+00:00
source: ietf
abstract:
  This document specifies an attribute for a statement of possession of
     a private key by a certificate subject.  As part of X.509 certificate
     enrollment, a Certification Authority (CA) typically demands proof
     that the subject possesses of the private key that corresponds to the
     to-be-certified public key.  In some cases, a CA might accept a
     signed statement from the certificate subject.  For example, when a
     certificate subject needs separate certificates for signature and key
     establishment, a statement that can be validated with the previously
     issued signature certificate for the same subject might be adequate
     for subsequent issuance of the key establishment certificate.

full_text:
  Network Working Group                                         R. Housley
  Internet-Draft                                            Vigil Security
  Intended status: Standards Track                          9 January 2025
  Expires: 13 July 2025


         An Attribute for Statement of Possession of a Private Key
               draft-housley-lamps-private-key-attest-attr-01

  Abstract

     This document specifies an attribute for a statement of possession of
     a private key by a certificate subject.  As part of X.509 certificate
     enrollment, a Certification Authority (CA) typically demands proof
     that the subject possesses of the private key that corresponds to the
     to-be-certified public key.  In some cases, a CA might accept a
     signed statement from the certificate subject.  For example, when a
     certificate subject needs separate certificates for signature and key
     establishment, a statement that can be validated with the previously
     issued signature certificate for the same subject might be adequate
     for subsequent issuance of the key establishment certificate.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 13 July 2025.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights



  Housley                   Expires 13 July 2025                  [Page 1]


  Internet-Draft     Statement of Private Key Possession      January 2025


     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Attribute for Statement of Possession of a Private Key  . . .   4
     3.  Conventions for PKCS#10 . . . . . . . . . . . . . . . . . . .   5
     4.  Conventions for CRMF  . . . . . . . . . . . . . . . . . . . .   6
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
       7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
     Appendix A.  ASN.1 Module . . . . . . . . . . . . . . . . . . . .   8
     Appendix B.  Appendix: Example use of the privateKeyStatement
             Attribute . . . . . . . . . . . . . . . . . . . . . . . .  10
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  18
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  18

  1.  Introduction

     This document specifies an attribute for a statement of possession of
     a private key by a certificate subject.  As part of X.509 certificate
     [RFC5280] enrollment, a Certification Authority (CA) typically
     demands proof that the subject possesses the private key that
     corresponds to the to-be-certified public key.  In some cases, a CA
     might accept a signed statement from the certificate subject.  For
     example, when a certificate subject needs separate certificates for
     signature and key establishment, a signed statement that can be
     validated with the previously issued signature certificate for the
     same subject might be adequate for subsequent issuance of the key
     establishment certificate.  Note that [RFC6955] offers some
     algorithms to provide proof of possession for Diffie-Hellman private
     keys.  However, these algorithms are not suitable for use with
     PKCS#10 [RFC2986].  On the other hand, the the attribute specified in
     this document is suitable for use with PKCS#10.










  Housley                   Expires 13 July 2025                  [Page 2]


  Internet-Draft     Statement of Private Key Possession      January 2025


     In many situations a subject needs two certificates, one for digiatal
     signatures, and a separate one for key establishment.  For example, a
     subject may need a signature certificate that contains a ML-DSA
     public key and a key establishment certificate that contains a ML-KEM
     public key.  For another example, a subject may need a signature
     certificate that contains a ECDSA public key and a key establishment
     certificate that contains a ECDH public key.

     In this situation, a CA might accept a signed statement that can be
     validated with the previously issued signature certificate as
     adequate for subsequent issuance of the key establishment
     certificate.

     When using the attribute defined in this document make a statement
     about the possession of the key establishment private key, the
     process for a subject to obtain two certificates is:

     1.  The subject generates the signature key pair.

     2.  The subject composes a PKCS#10 Certificate Signing Request (CSR)
         in the usual manner.  It includes a signature that is produced
         with the private key from step 1.

     3.  The subject sends the CSR to the CA, and it gets back a signature
         certificate.  The signature certificate includes a key usage of
         digitalSignature, nonRepudiation, or both Section 4.2.1.3 of
         [RFC5280].

     4.  The subject generates the key establishment key pair.

     5.  The subject composes a PKCS#10 CSR containing the key
         establishment public key.  The CSR attributes include the
         attribute specified in Section 2 of this document.  The subject
         name matches the one from step 2.  The CSR includes a signature
         that is produced with the private key from step 1.

     6.  The subject sends the CSR to the CA, and it gets back a key
         establishment certificate.  The key establishment certificate
         includes a key usage of keyEncipherment or keyAgreement
         Section 4.2.1.3 of [RFC5280].

  1.1.  ASN.1

     The attestation attribute is generated using ASN.1 [X680], using the
     Distinguished Encoding Rules (DER) [X690].






  Housley                   Expires 13 July 2025                  [Page 3]


  Internet-Draft     Statement of Private Key Possession      January 2025


  1.2.  Terminology

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  2.  Attribute for Statement of Possession of a Private Key

     The attribute for statement of possession of a private key is
     included in a certificate request to make the following statement:

        "The subject of the signature certificate that is used to validate
        the signature on this certificate request also has possession of
        the private key that corresponds to the public key in the
        certificate request."

     The CA MUST perform certification path validation for the signature
     certificate as specified in Section 6 of [RFC5280].  If the
     certification path is not valid, then the CA MUST reject the
     certificate request.

     The CA MUST validate the signature on the certificate request using
     the public key from the signature certificate.  If the signature is
     not valid, then the CA MUST reject the certificate request.

     The subject in the signature certificate SHOULD be the same as the
     subject name in the certificate request.  If they are different, the
     certificate policy MUST describe how the CA can determine that the
     two subject names identify the same entity.  If the CA is unable to
     determine that the two subject names identify the same entity, then
     the CA MUST reject the certificate request.

     If subject alternative names are present in the certificate request,
     they SHOULD match subject alternative names in the signature
     certificate.  If the CA is unable to determine that each of subject
     alternative names identifies the same entity as is named in the
     signature certificate, then the CA MUST reject the certificate
     request.

     The attribute for statement of possession of a private key has the
     following structure:








  Housley                   Expires 13 July 2025                  [Page 4]


  Internet-Draft     Statement of Private Key Possession      January 2025


        id-at-privateKeyStatement OBJECT IDENTIFIER ::=
          { 1 3 6 1 4 1 22112 2 1 }

        privateKeyStatement ATTRIBUTE ::= {
          TYPE PrivateKeyStatement
          IDENTIFIED BY id-at-privateKeyStatement }

        PrivateKeyStatement ::= SEQUENCE {
          signer  IssuerAndSerialNumber,
          cert    Certificate OPTIONAL }

     The components of the PrivateKeyStatement SEQUENCE have the following
     semantics:

        signer:  the issuer name and certificate serial number of the
           signature certificate.

        cert:  the signature certificate.  If the issuer of the key
           establishment certificate will be the same as the issuer of the
           signature certificate, then this component MAY be omitted.
           When the signature certificate is omitted, the signer is
           assuming that the CA has a mechanism to obtain all valid
           certificates that it issued.

  3.  Conventions for PKCS#10

     This section specifies the conventions for using the attribute for
     statement of possession of a private key with PKCS#10 [RFC2986] when
     requesting a key establishment certificate.

     The PKCS#10 CertificationRequest always has three components, as
     follows:

        certificationRequestInfo:  the subject name SHOULD be the same as
           the subject name in the signature certificate, the
           subjectPKInfo MUST contain the public key for the key
           establishment algorithm, and the attributes MUST include
           privateKeyStatement attribute as specified in Section 2 of this
           document.

        signatureAlgorithm:  the signature algorithm MUST be one that can
           be validated with the public key in the signature certificate.

        signature:  the signature over certificationRequestInfo MUST
           validate with the public key in the signature certificate, and
           certification path validation for the signature certificate
           MUST be successful as specified in Section 6 of [RFC5280].




  Housley                   Expires 13 July 2025                  [Page 5]


  Internet-Draft     Statement of Private Key Possession      January 2025


  4.  Conventions for CRMF

     This section specifies the conventions for using the attribute for
     statement of possession of a private key with the Certificate Request
     Message Format (CRMF) [RFC4211] when requesting a key establisment
     certificate.

     The following ASN.1 types are defined for use with CRMF.  They have
     exactly the same semantics and syntax as the attribute discussed
     above, but they offer a similar naming convention to the Registration
     Controls in [RFC4211].

       regCtrl-privateKeyStatement ATTRIBUTE ::= privateKeyStatement

       id-regCtrl-privateKeyStatement OBJECT IDENTIFIER ::=
         id-at-privateKeyStatement

     The CRMF CertificationRequest always has three components, as
     follows:

        certReq:  the certTemplate MUST include the subject and the
           publicKey components.  The same subject name SHOULD match the
           subject name in the signature certificate, and publicKey MUST
           contain the public key for the key establishment algorithm.

        popo:  the ProofOfPossession MUST use the signature CHOICE, the
           poposkInput MUST be present, POPOSigningKeyInput.authInfo MUST
           use the sender CHOICE, the sender MUST set to the subject name
           that appears in the signature certificate, the publicKey MUST
           contain a copy of the public key from the certTemplate, the
           algorithmIdentifier MUST identify a signture algorithm that can
           be validated with the public key in the signature certificate,
           signature over the poposkInput MUST validate with the public
           key in the signature certificate, and certification path
           validation for the signature certificate MUST be successful as
           specified in Section 6 of [RFC5280].

        regInfo:  the attributes MUST include privateKeyStatement
           attribute as specified in Section 2 of this document.

  5.  Security Considerations

     The subject is signing privateKeyStatement attribute to tell the CA
     that it has possession of the key establishment private key.  This is
     being done instead of providing some other form of proof of
     possession.  If the subject has lost control of the signature private
     key, then the signed privateKeyStatement attribute could be generated
     by some other party.  Timely revocation of the compromised signature



  Housley                   Expires 13 July 2025                  [Page 6]


  Internet-Draft     Statement of Private Key Possession      January 2025


     certificate is the only protection against such loss of control.

     The signature key pair and the key establishment key pair are
     expected to have roughly the same security strength.  To ensure that
     the signature on the attestation is not the weak part of the
     certificate enrollment, the signature key pair SHOULD be at least as
     strong as the key establishment key pair.

     If a CA allows subject in the key establishment certificate to be
     different than the subject name in the signature certificate, then
     certificate policy MUST describe how to determine that the two
     subject names identify the same entity.  Likewise, if a CA allows
     subject alternative names in the key establishment certificate that
     are not present in the signature certificate, then certificate policy
     MUST describe how to determine that the subject alternative names
     identify the same entity as is named in the signature certificate.

  6.  IANA Considerations

     For the ASN.1 Module in the Appendix A of this document, IANA is
     requested to assign an object identifier (OID) for the module
     identifier (TBD0) with a Description of "id-mod-private-key-stmt-
     2025".  The OID for the module should be allocated in the "SMI
     Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0).

  7.  References

  7.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
                Request Syntax Specification Version 1.7", RFC 2986,
                DOI 10.17487/RFC2986, November 2000,
                <https://www.rfc-editor.org/rfc/rfc2986>.

     [RFC4211]  Schaad, J., "Internet X.509 Public Key Infrastructure
                Certificate Request Message Format (CRMF)", RFC 4211,
                DOI 10.17487/RFC4211, September 2005,
                <https://www.rfc-editor.org/rfc/rfc4211>.








  Housley                   Expires 13 July 2025                  [Page 7]


  Internet-Draft     Statement of Private Key Possession      January 2025


     [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, DOI 10.17487/RFC5280, May 2008,
                <https://www.rfc-editor.org/rfc/rfc5280>.

     [RFC5912]  Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
                Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
                DOI 10.17487/RFC5912, June 2010,
                <https://www.rfc-editor.org/rfc/rfc5912>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [X680]     ITU-T, "Information technology -- Abstract Syntax Notation
                One (ASN.1): Specification of basic notation", ITU-T
                Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
                <https://www.itu.int/rec/T-REC-X.680>.

     [X690]     ITU-T, "Information technology -- ASN.1 encoding rules:
                Specification of Basic Encoding Rules (BER), Canonical
                Encoding Rules (CER) and Distinguished Encoding Rules
                (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1-2021,
                February 2021, <https://www.itu.int/rec/T-REC-X.690>.

  7.2.  Informative References

     [RFC6955]  Schaad, J. and H. Prafullchandra, "Diffie-Hellman Proof-
                of-Possession Algorithms", RFC 6955, DOI 10.17487/RFC6955,
                May 2013, <https://www.rfc-editor.org/rfc/rfc6955>.

  Appendix A.  ASN.1 Module

     This ASN.1 Module builds upon the conventions established in
     [RFC5912].

     <CODE STARTS>

     PrivateKeyStatement-2025
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-private-key-stmt-2025(TBD0) }

     DEFINITIONS IMPLICIT TAGS ::= BEGIN

     EXPORTS ALL;




  Housley                   Expires 13 July 2025                  [Page 8]


  Internet-Draft     Statement of Private Key Possession      January 2025


     IMPORTS
       ATTRIBUTE
       FROM PKIX-CommonTypes-2009 -- in [RFC5912]
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) id-mod(0)
           id-mod-pkixCommon-02(57) }

       Certificate
       FROM PKIX1Explicit-2009 -- in [RFC5912]
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) id-mod(0)
           id-mod-pkix1-explicit-02(51) }

       IssuerAndSerialNumber
       FROM CryptographicMessageSyntax-2010 -- [RFC6268]
         { iso(1) member-body(2) us(840) rsadsi(113549)
            pkcs(1) pkcs-9(9) smime(16) modules(0)
            id-mod-cms-2009(58) } ;

     --
     -- Private Key Statement Attribute
     --

     id-at-privateKeyStatement OBJECT IDENTIFIER ::=
       { 1 3 6 1 4 1 22112 2 1 }

     privateKeyStatement ATTRIBUTE ::= {
       TYPE PrivateKeyStatement
       IDENTIFIED BY id-at-privateKeyStatement }

     PrivateKeyStatement ::= SEQUENCE {
       signer  IssuerAndSerialNumber,
       cert    Certificate OPTIONAL }

     --
     -- Registration Control Support
     --

     RegControlSet ATTRIBUTE ::= { regCtrl-privateKeStatement, ... }

     regCtrl-privateKeyStatement ATTRIBUTE ::= privateKeyStatement

     id-regCtrl-privateKeyStatement OBJECT IDENTIFIER ::=
       id-at-privateKeyStatement

     END

     <CODE ENDS>



  Housley                   Expires 13 July 2025                  [Page 9]


  Internet-Draft     Statement of Private Key Possession      January 2025


  Appendix B.  Appendix: Example use of the privateKeyStatement Attribute

     In this example, the self-signed certificate for the CA is:

     -----BEGIN CERTIFICATE-----
     MIIB7DCCAXKgAwIBAgIUL149AUxHunELBZMELEQm+isgKCQwCgYIKoZIzj0EAwMw
     NzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNh
     LmV4YW1wbGUwHhcNMjUwMTAzMjAyNzA5WhcNMzUwMTAzMjAyNzA5WjA3MQswCQYD
     VQQGEwJVUzETMBEGA1UEChMKRXhhbXBsZSBDQTETMBEGA1UEAxMKY2EuZXhhbXBs
     ZTB2MBAGByqGSM49AgEGBSuBBAAiA2IABDxZdB/Glcxdk1p6Jf1j5en6QfliY9OS
     fjZbtje/w6M58PN8Sb3VFln1rPdvD17UXeazSG9Hr/Dq3enbsHHO0pPntcFOgb8n
     r8R8LUGhxRzjlxkaEJN+pa6Nf7qk49JDeaM/MD0wDwYDVR0TAQH/BAUwAwEB/zAL
     BgNVHQ8EBAMCAgQwHQYDVR0OBBYEFD6YvLLv3DQbvnGS0qP6bbzyZkCqMAoGCCqG
     SM49BAMDA2gAMGUCMGfb61IigoJ3QDnlsRdoktREHe0Dpm6DKw3qOyLL6A0cFK9Z
     g8m11xIwvptlran52gIxAK1VrOjzRsFiHRptO+gFXstTXnQkKBb2/3WQz2SqcIS/
     BWEp+siJ19OXOlz6APDB7w==
     -----END CERTIFICATE-----

     Alice generates her ECDSA signature key pair.  Then, Alice composes a
     PKCS#10 Certificate Signing Request (CSR) in the usual manner as
     specified in [RFC2986].  The CSR includes a signature that is
     produced with her ECDSA private key.  The CSR is:

     -----BEGIN CERTIFICATE REQUEST-----
     MIIBhTCCAQsCAQAwPDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlZBMRAwDgYDVQQH
     EwdIZXJuZG9uMQ4wDAYDVQQDEwVBbGljZTB2MBAGByqGSM49AgEGBSuBBAAiA2IA
     BIAc+6lXN1MIM/82QeWNb55H0zr+lVgWVeF0bf4jzxCb5MCjVaM0eFEvcjXMV5p4
     kzqiJTHC0V2JAoqYMX/DMFIcwZ7xP9uQd9ep6KZ+RXut211L8+W1QI1QJSDNxANR
     saBQME4GCSqGSIb3DQEJDjFBMD8wDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCB4Aw
     IgYDVR0RBBswGYEXYWxpY2VAZW1haWwuZXhhbXBsZS5jb20wCgYIKoZIzj0EAwMD
     aAAwZQIwPa2rOCe60edAF43C/t57IW8liyy+69FE04hMAFgw3Ga+nR+8zDuUsVLw
     xXGAHtcDAjEA6LbvNkZjo6j2z5xRIjrHzEbGgiV4MF4xtnpfSSRI4dB0zT52bWkj
     TZsuS1YWIkjt
     -----END CERTIFICATE REQUEST-----

     The CA issues a signature certificate to Alice:















  Housley                   Expires 13 July 2025                 [Page 10]


  Internet-Draft     Statement of Private Key Possession      January 2025


     -----BEGIN CERTIFICATE-----
     MIICJzCCAa6gAwIBAgIUf3Sj/ANs4hR4XFlhTm+N8kxHqHkwCgYIKoZIzj0EAwMw
     NzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNh
     LmV4YW1wbGUwHhcNMjUwMTA5MTcwMzQ4WhcNMjYwMTA5MTcwMzQ4WjA8MQswCQYD
     VQQGEwJVUzELMAkGA1UECBMCVkExEDAOBgNVBAcTB0hlcm5kb24xDjAMBgNVBAMT
     BUFsaWNlMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEgBz7qVc3Uwgz/zZB5Y1vnkfT
     Ov6VWBZV4XRt/iPPEJvkwKNVozR4US9yNcxXmniTOqIlMcLRXYkCipgxf8MwUhzB
     nvE/25B316nopn5Fe63bXUvz5bVAjVAlIM3EA1Gxo3YwdDAMBgNVHRMBAf8EAjAA
     MAsGA1UdDwQEAwIHgDAdBgNVHQ4EFgQUIx0A0f7tCzkQEZgYzH3NcM2L05IwHwYD
     VR0jBBgwFoAUPpi8su/cNBu+cZLSo/ptvPJmQKowFwYDVR0gBBAwDjAMBgpghkgB
     ZQMCATAwMAoGCCqGSM49BAMDA2cAMGQCMGu/Uypd7BaVnUjB36UtX9m5ZmPi78y5
     1RA8WhbOv0KQVrcYtj4qOdiMVKBcoVceyAIwRJ6U91048NAb3nicHcrGFf1UYrhb
     DlytK4tCa5HBxD/qAgy4/eUzA5NZwVaLK78u
     -----END CERTIFICATE-----

     Alice generates her ECDH key establishment key pair.  Then, Alice
     composes a PKCS#10 CSR.  The CSR attributes include the
     privateKeyStatement attribute, which points to her ECDSA signature
     certificate.  The CSR includes her ECDH public key and a signature
     that is produced with her ECDSA private key.  The CSR is:

     -----BEGIN CERTIFICATE REQUEST-----
     MIIEMTCCA7gCAQAwPDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlZBMRAwDgYDVQQH
     EwdIZXJuZG9uMQ4wDAYDVQQDEwVBbGljZTB0MA4GBSuBBAEMBgUrgQQAIgNiAAQB
     RyQTH+cq1s5F94uFqFe7l1LqGdEC8Tm+e5VYBCfKAC8MJySQMj1GixEEXL+1Wjtg
     23XvnJouCDoxSpDCSMqf3kvp5+naM37uxa3ZYgD6DPY3me5EZvyZPvSRJTFl/Bag
     ggL9MGcGCSqGSIb3DQEJDjFaMFgwDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCAwgw
     IgYDVR0RBBswGYEXYWxpY2VAZW1haWwuZXhhbXBsZS5jb20wFwYDVR0gBBAwDjAM
     BgpghkgBZQMCATAwMIICkAYKKwYBBAGBrGACATGCAoAwggJ8ME8wNzELMAkGA1UE
     BhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNhLmV4YW1wbGUC
     FH90o/wDbOIUeFxZYU5vjfJMR6h5MIICJzCCAa6gAwIBAgIUf3Sj/ANs4hR4XFlh
     Tm+N8kxHqHkwCgYIKoZIzj0EAwMwNzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4
     YW1wbGUgQ0ExEzARBgNVBAMTCmNhLmV4YW1wbGUwHhcNMjUwMTA5MTcwMzQ4WhcN
     MjYwMTA5MTcwMzQ4WjA8MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVkExEDAOBgNV
     BAcTB0hlcm5kb24xDjAMBgNVBAMTBUFsaWNlMHYwEAYHKoZIzj0CAQYFK4EEACID
     YgAEgBz7qVc3Uwgz/zZB5Y1vnkfTOv6VWBZV4XRt/iPPEJvkwKNVozR4US9yNcxX
     mniTOqIlMcLRXYkCipgxf8MwUhzBnvE/25B316nopn5Fe63bXUvz5bVAjVAlIM3E
     A1Gxo3YwdDAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIHgDAdBgNVHQ4EFgQUIx0A
     0f7tCzkQEZgYzH3NcM2L05IwHwYDVR0jBBgwFoAUPpi8su/cNBu+cZLSo/ptvPJm
     QKowFwYDVR0gBBAwDjAMBgpghkgBZQMCATAwMAoGCCqGSM49BAMDA2cAMGQCMGu/
     Uypd7BaVnUjB36UtX9m5ZmPi78y51RA8WhbOv0KQVrcYtj4qOdiMVKBcoVceyAIw
     RJ6U91048NAb3nicHcrGFf1UYrhbDlytK4tCa5HBxD/qAgy4/eUzA5NZwVaLK78u
     MAoGCCqGSM49BAMDA2cAMGQCL2TNHPULWcCS2DqZCCiQeSwx2JPLMI14Vi977bzy
     rImq5p0H3Bel6fAS8BnQ00WNAjEAhHDAlcbRuHhqdW6mOgDd5kWEGGqgixIuvEEc
     fVbnNCEyEE4n0mQ99PHURnXoHwqF
     -----END CERTIFICATE REQUEST-----

     The CSR decodes to:



  Housley                   Expires 13 July 2025                 [Page 11]


  Internet-Draft     Statement of Private Key Possession      January 2025


        0 1073: SEQUENCE {
        4  952:  SEQUENCE {
        8    1:   INTEGER 0
       11   60:   SEQUENCE {
       13   11:    SET {
       15    9:     SEQUENCE {
       17    3:      OBJECT IDENTIFIER countryName (2 5 4 6)
       22    2:      PrintableString 'US'
              :       }
              :      }
       26   11:    SET {
       28    9:     SEQUENCE {
       30    3:      OBJECT IDENTIFIER stateOrProvinceName (2 5 4 8)
       35    2:      PrintableString 'VA'
              :       }
              :      }
       39   16:    SET {
       41   14:     SEQUENCE {
       43    3:      OBJECT IDENTIFIER localityName (2 5 4 7)
       48    7:      PrintableString 'Herndon'
              :       }
              :      }
       57   14:    SET {
       59   12:     SEQUENCE {
       61    3:      OBJECT IDENTIFIER commonName (2 5 4 3)
       66    5:      PrintableString 'Alice'
              :       }
              :      }
              :     }
       73  116:   SEQUENCE {
       75   14:    SEQUENCE {
       77    5:     OBJECT IDENTIFIER ECDH (1 3 132 1 12)
       84    5:     OBJECT IDENTIFIER secp384r1 (1 3 132 0 34)
              :      }
       91   98:    BIT STRING
              :     04 01 47 24 13 1F E7 2A D6 CE 45 F7 8B 85 A8 57
              :     BB 97 52 EA 19 D1 02 F1 39 BE 7B 95 58 04 27 CA
              :     00 2F 0C 27 24 90 32 3D 46 8B 11 04 5C BF B5 5A
              :     3B 60 DB 75 EF 9C 9A 2E 08 3A 31 4A 90 C2 48 CA
              :     9F DE 4B E9 E7 E9 DA 33 7E EE C5 AD D9 62 00 FA
              :     0C F6 37 99 EE 44 66 FC 99 3E F4 91 25 31 65 FC
              :     16
              :     }
      191  765:   [0] {
      195  103:    SEQUENCE {
      197    9:     OBJECT IDENTIFIER
              :      extensionRequest (1 2 840 113549 1 9 14)
      208   90:     SET {



  Housley                   Expires 13 July 2025                 [Page 12]


  Internet-Draft     Statement of Private Key Possession      January 2025


      210   88:      SEQUENCE {
      212   12:       SEQUENCE {
      214    3:        OBJECT IDENTIFIER
              :         basicConstraints (2 5 29 19)
      219    1:        BOOLEAN TRUE
      222    2:        OCTET STRING, encapsulates {
      224    0:         SEQUENCE {}
              :          }
              :         }
      226   11:       SEQUENCE {
      228    3:        OBJECT IDENTIFIER keyUsage (2 5 29 15)
      233    4:        OCTET STRING, encapsulates {
      235    2:         BIT STRING 3 unused bits
              :          '10000'B (bit 4)
              :          }
              :         }
      239   34:       SEQUENCE {
      241    3:        OBJECT IDENTIFIER subjectAltName (2 5 29 17)
      246   27:        OCTET STRING, encapsulates {
      248   25:         SEQUENCE {
      250   23:          [1] 'alice@email.example.com'
              :           }
              :          }
              :         }
      275   23:       SEQUENCE {
      277    3:        OBJECT IDENTIFIER
              :         certificatePolicies (2 5 29 32)
      282   16:        OCTET STRING, encapsulates {
      284   14:         SEQUENCE {
      286   12:          SEQUENCE {
      288   10:           OBJECT IDENTIFIER
              :            testCertPolicy (2 16 840 1 101 3 2 1 48 48)
              :            }
              :           }
              :          }
              :         }
              :        }
              :       }
              :      }
      300  656:    SEQUENCE {
      304   10:     OBJECT IDENTIFIER
              :      privateKeyAttest (1 3 6 1 4 1 22112 2 1)
      316  640:     SET {
      320  636:      SEQUENCE {
      324   79:       SEQUENCE {
      326   55:        SEQUENCE {
      328   11:         SET {
      330    9:          SEQUENCE {



  Housley                   Expires 13 July 2025                 [Page 13]


  Internet-Draft     Statement of Private Key Possession      January 2025


      332    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
      337    2:           PrintableString 'US'
              :            }
              :           }
      341   19:         SET {
      343   17:          SEQUENCE {
      345    3:           OBJECT IDENTIFIER
              :            organizationName (2 5 4 10)
      350   10:           PrintableString 'Example CA'
              :            }
              :           }
      362   19:         SET {
      364   17:          SEQUENCE {
      366    3:           OBJECT IDENTIFIER commonName (2 5 4 3)
      371   10:           PrintableString 'ca.example'
              :            }
              :           }
              :          }
      383   20:        INTEGER
              :      7F 74 A3 FC 03 6C E2 14 78 5C 59 61 4E 6F 8D F2
              :      4C 47 A8 79
              :         }
      405  551:       SEQUENCE {
      409  430:        SEQUENCE {
      413    3:         [0] {
      415    1:          INTEGER 2
              :           }
      418   20:         INTEGER
              :      7F 74 A3 FC 03 6C E2 14 78 5C 59 61 4E 6F 8D F2
              :      4C 47 A8 79
      440   10:         SEQUENCE {
      442    8:          OBJECT IDENTIFIER
              :           ecdsaWithSHA384 (1 2 840 10045 4 3 3)
              :           }
      452   55:         SEQUENCE {
      454   11:          SET {
      456    9:           SEQUENCE {
      458    3:            OBJECT IDENTIFIER
              :             countryName (2 5 4 6)
      463    2:            PrintableString 'US'
              :             }
              :            }
      467   19:          SET {
      469   17:           SEQUENCE {
      471    3:            OBJECT IDENTIFIER
              :             organizationName (2 5 4 10)
      476   10:            PrintableString 'Example CA'
              :             }



  Housley                   Expires 13 July 2025                 [Page 14]


  Internet-Draft     Statement of Private Key Possession      January 2025


              :            }
      488   19:          SET {
      490   17:           SEQUENCE {
      492    3:            OBJECT IDENTIFIER
              :             commonName (2 5 4 3)
      497   10:            PrintableString 'ca.example'
              :             }
              :            }
              :           }
      509   30:         SEQUENCE {
      511   13:          UTCTime 09/01/2025 17:03:48 GMT
      526   13:          UTCTime 09/01/2026 17:03:48 GMT
              :           }
      541   60:         SEQUENCE {
      543   11:          SET {
      545    9:           SEQUENCE {
      547    3:            OBJECT IDENTIFIER
              :             countryName (2 5 4 6)
      552    2:            PrintableString 'US'
              :             }
              :            }
      556   11:          SET {
      558    9:           SEQUENCE {
      560    3:            OBJECT IDENTIFIER
              :             stateOrProvinceName (2 5 4 8)
      565    2:            PrintableString 'VA'
              :             }
              :            }
      569   16:          SET {
      571   14:           SEQUENCE {
      573    3:            OBJECT IDENTIFIER
              :             localityName (2 5 4 7)
      578    7:            PrintableString 'Herndon'
              :             }
              :            }
      587   14:          SET {
      589   12:           SEQUENCE {
      591    3:            OBJECT IDENTIFIER
              :             commonName (2 5 4 3)
      596    5:            PrintableString 'Alice'
              :             }
              :            }
              :           }
      603  118:         SEQUENCE {
      605   16:          SEQUENCE {
      607    7:           OBJECT IDENTIFIER
              :            ecPublicKey (1 2 840 10045 2 1)
      616    5:           OBJECT IDENTIFIER



  Housley                   Expires 13 July 2025                 [Page 15]


  Internet-Draft     Statement of Private Key Possession      January 2025


              :            secp384r1 (1 3 132 0 34)
              :            }
      623   98:          BIT STRING
              :      04 80 1C FB A9 57 37 53 08 33 FF 36 41 E5 8D 6F
              :      9E 47 D3 3A FE 95 58 16 55 E1 74 6D FE 23 CF 10
              :      9B E4 C0 A3 55 A3 34 78 51 2F 72 35 CC 57 9A 78
              :      93 3A A2 25 31 C2 D1 5D 89 02 8A 98 31 7F C3 30
              :      52 1C C1 9E F1 3F DB 90 77 D7 A9 E8 A6 7E 45 7B
              :      AD DB 5D 4B F3 E5 B5 40 8D 50 25 20 CD C4 03 51
              :      B1
              :           }
      723  118:         [3] {
      725  116:          SEQUENCE {
      727   12:           SEQUENCE {
      729    3:            OBJECT IDENTIFIER
              :             basicConstraints (2 5 29 19)
      734    1:            BOOLEAN TRUE
      737    2:            OCTET STRING, encapsulates {
      739    0:             SEQUENCE {}
              :              }
              :             }
      741   11:           SEQUENCE {
      743    3:            OBJECT IDENTIFIER
              :             keyUsage (2 5 29 15)
      748    4:            OCTET STRING, encapsulates {
      750    2:             BIT STRING 7 unused bits
              :              '1'B (bit 0)
              :              }
              :             }
      754   29:           SEQUENCE {
      756    3:            OBJECT IDENTIFIER
              :             subjectKeyIdentifier (2 5 29 14)
      761   22:            OCTET STRING, encapsulates {
      763   20:             OCTET STRING
              :      23 1D 00 D1 FE ED 0B 39 10 11 98 18 CC 7D CD 70
              :      CD 8B D3 92
              :              }
              :             }
      785   31:           SEQUENCE {
      787    3:            OBJECT IDENTIFIER
              :             authorityKeyIdentifier (2 5 29 35)
      792   24:            OCTET STRING, encapsulates {
      794   22:             SEQUENCE {
      796   20:              [0]
              :      3E 98 BC B2 EF DC 34 1B BE 71 92 D2 A3 FA 6D BC
              :      F2 66 40 AA
              :               }
              :              }



  Housley                   Expires 13 July 2025                 [Page 16]


  Internet-Draft     Statement of Private Key Possession      January 2025


              :             }
      818   23:           SEQUENCE {
      820    3:            OBJECT IDENTIFIER
              :             certificatePolicies (2 5 29 32)
      825   16:            OCTET STRING, encapsulates {
      827   14:             SEQUENCE {
      829   12:              SEQUENCE {
      831   10:               OBJECT IDENTIFIER
              :                testCertPolicy (2 16 840 1 101 3 2 1 48 48)
              :                }
              :               }
              :              }
              :             }
              :            }
              :           }
              :          }
      843   10:        SEQUENCE {
      845    8:         OBJECT IDENTIFIER
              :          ecdsaWithSHA384 (1 2 840 10045 4 3 3)
              :          }
      855  103:        BIT STRING, encapsulates {
      858  100:         SEQUENCE {
      860   48:          INTEGER
              :      6B BF 53 2A 5D EC 16 95 9D 48 C1 DF A5 2D 5F D9
              :      B9 66 63 E2 EF CC B9 D5 10 3C 5A 16 CE BF 42 90
              :      56 B7 18 B6 3E 2A 39 D8 8C 54 A0 5C A1 57 1E C8
      910   48:          INTEGER
              :      44 9E 94 F7 5D 38 F0 D0 1B DE 78 9C 1D CA C6 15
              :      FD 54 62 B8 5B 0E 5C AD 2B 8B 42 6B 91 C1 C4 3F
              :      EA 02 0C B8 FD E5 33 03 93 59 C1 56 8B 2B BF 2E
              :           }
              :          }
              :         }
              :        }
              :       }
              :      }
              :     }
              :    }
      960   10:  SEQUENCE {
      962    8:   OBJECT IDENTIFIER ecdsaWithSHA384 (1 2 840 10045 4 3 3)
              :    }
      972  103:  BIT STRING, encapsulates {
      975  100:   SEQUENCE {
      977   47:    INTEGER
              :     64 CD 1C F5 0B 59 C0 92 D8 3A 99 08 28 90 79 2C
              :     31 D8 93 CB 30 8D 78 56 2F 7B ED BC F2 AC 89 AA
              :     E6 9D 07 DC 17 A5 E9 F0 12 F0 19 D0 D3 45 8D
     1026   49:    INTEGER



  Housley                   Expires 13 July 2025                 [Page 17]


  Internet-Draft     Statement of Private Key Possession      January 2025


              :     00 84 70 C0 95 C6 D1 B8 78 6A 75 6E A6 3A 00 DD
              :     E6 45 84 18 6A A0 8B 12 2E BC 41 1C 7D 56 E7 34
              :     21 32 10 4E 27 D2 64 3D F4 F1 D4 46 75 E8 1F 0A
              :     85
              :     }
              :    }
              :   }

     The CA issues a key establishment certificate to Alice:

     -----BEGIN CERTIFICATE-----
     MIICJTCCAaygAwIBAgIUf3Sj/ANs4hR4XFlhTm+N8kxHqHowCgYIKoZIzj0EAwMw
     NzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNh
     LmV4YW1wbGUwHhcNMjUwMTA5MTcwNTAwWhcNMjYwMTA5MTcwNTAwWjA8MQswCQYD
     VQQGEwJVUzELMAkGA1UECBMCVkExEDAOBgNVBAcTB0hlcm5kb24xDjAMBgNVBAMT
     BUFsaWNlMHQwDgYFK4EEAQwGBSuBBAAiA2IABAFHJBMf5yrWzkX3i4WoV7uXUuoZ
     0QLxOb57lVgEJ8oALwwnJJAyPUaLEQRcv7VaO2Dbde+cmi4IOjFKkMJIyp/eS+nn
     6dozfu7FrdliAPoM9jeZ7kRm/Jk+9JElMWX8FqN2MHQwDAYDVR0TAQH/BAIwADAL
     BgNVHQ8EBAMCAwgwHQYDVR0OBBYEFAnLfJvnEUcvLXaPUDZMZlQ/zZ3WMB8GA1Ud
     IwQYMBaAFD6YvLLv3DQbvnGS0qP6bbzyZkCqMBcGA1UdIAQQMA4wDAYKYIZIAWUD
     AgEwMDAKBggqhkjOPQQDAwNnADBkAjARQ5LuV6yz8A5DZCll1S/gfxZ+QSJl/pKc
     cTL6Sdr1IS18U/zY8VUJeB2H0nBamLwCMBRQ6sEWpNoeeR8Bonpoot/zYD2luQ1V
     2jevmYsnBihKF0debgfhGvh8WIgBR69DZg==
     -----END CERTIFICATE-----

  Acknowledgements

     Thanks to Sean Turner, Joe Mandel, Mike StJohns, Mike Ounsworth, Carl
     Wallace, and Corey Bonnell for their constructive comments.

  Author's Address

     Russ Housley
     Vigil Security, LLC
     Herndon, VA,
     United States of America
     Email: housley@vigilsec.com














  Housley                   Expires 13 July 2025                 [Page 18]


name: draft-ietf-anima-brski-ae
rev: 13
title: BRSKI-AE: Alternative Enrollment Protocols in BRSKI
time: 2025-03-03T23:33:09Z
group_uri: /api/v1/group/group/1956/
expires: 2025-03-21T11:19:04Z
ad: /api/v1/person/person/107859/
shepherd: /api/v1/person/email/tte@cs.fau.de/
categories: []
tags: []
fetched_at: 2026-03-07T06:55:13.081940+00:00
source: ietf
abstract:
  This document defines enhancements to the Bootstrapping Remote Secure
     Key Infrastructure (BRSKI) protocol, known as BRSKI-AE (Alternative
     Enrollment).
     BRSKI-AE extends BRSKI to support certificate enrollment mechanisms
     instead of the originally specified use of EST.  It supports
     certificate enrollment protocols, such as CMP, that use authenticated
     self-contained signed objects for certification messages, allowing
     for flexibility in network device onboarding scenarios.
     The enhancements address use cases where the existing enrollment
     mechanism may not be feasible or optimal, providing a framework for
     integrating suitable alternative enrollment protocols.
     This document also updates the BRSKI reference architecture to
     accommodate these alternative methods, ensuring secure and scalable
     deployment across a range of network environments.

states:
  ["/api/v1/doc/state/3/", "/api/v1/doc/state/108/", "/api/v1/doc/state/112/", "/api/v1/doc/state/7/", "/api/v1/doc/state/44/"]

full_text:
  ANIMA WG                                              D. von Oheimb, Ed.
  Internet-Draft                                                  S. Fries
  Intended status: Standards Track                            H. Brockhaus
  Expires: 21 March 2025                                           Siemens
                                                         17 September 2024


            BRSKI-AE: Alternative Enrollment Protocols in BRSKI
                        draft-ietf-anima-brski-ae-13

  Abstract

     This document defines enhancements to the Bootstrapping Remote Secure
     Key Infrastructure (BRSKI) protocol, known as BRSKI-AE (Alternative
     Enrollment).
     BRSKI-AE extends BRSKI to support certificate enrollment mechanisms
     instead of the originally specified use of EST.  It supports
     certificate enrollment protocols, such as CMP, that use authenticated
     self-contained signed objects for certification messages, allowing
     for flexibility in network device onboarding scenarios.
     The enhancements address use cases where the existing enrollment
     mechanism may not be feasible or optimal, providing a framework for
     integrating suitable alternative enrollment protocols.
     This document also updates the BRSKI reference architecture to
     accommodate these alternative methods, ensuring secure and scalable
     deployment across a range of network environments.

  About This Document

     This note is to be removed before publishing as an RFC.

     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-ietf-anima-brski-ae/.

     Discussion of this document takes place on the anima Working Group
     mailing list (mailto:anima@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/anima/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/anima/.

     Source for this draft and an issue tracker can be found at
     https://github.com/anima-wg/anima-brski-ae.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.





  von Oheimb, et al.        Expires 21 March 2025                 [Page 1]


  Internet-Draft                  BRSKI-AE                  September 2024


     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 21 March 2025.

  Copyright Notice

     Copyright (c) 2024 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Supported Scenarios . . . . . . . . . . . . . . . . . . .   5
     2.  Terminology and abbreviations . . . . . . . . . . . . . . . .   6
     3.  Basic Requirements and Mapping to Solutions . . . . . . . . .   8
       3.1.  Solution Options for Proof of Possession  . . . . . . . .   9
       3.2.  Solution Options for Proof of Identity  . . . . . . . . .   9
     4.  Adaptations to BRSKI  . . . . . . . . . . . . . . . . . . . .  11
       4.1.  Architecture  . . . . . . . . . . . . . . . . . . . . . .  11
       4.2.  Message Exchange  . . . . . . . . . . . . . . . . . . . .  15
         4.2.1.  Pledge - Registrar Discovery  . . . . . . . . . . . .  15
         4.2.2.  Pledge - Registrar - MASA Voucher Exchange  . . . . .  15
         4.2.3.  Pledge - Registrar - MASA Voucher Status Telemetry  .  15
         4.2.4.  Pledge - Registrar - RA/CA Certificate Enrollment . .  16
         4.2.5.  Pledge - Registrar Enrollment Status Telemetry  . . .  19
       4.3.  Enhancements to the Endpoint Addressing Scheme of
             BRSKI . . . . . . . . . . . . . . . . . . . . . . . . . .  20
     5.  Instantiation with Existing Enrollment Protocols  . . . . . .  21
       5.1.  BRSKI-CMP: BRSKI-AE instantiated with CMP . . . . . . . .  21
       5.2.  Support of Other Enrollment Protocols . . . . . . . . . .  23
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23



  von Oheimb, et al.        Expires 21 March 2025                 [Page 2]


  Internet-Draft                  BRSKI-AE                  September 2024


     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  24
     8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  25
     9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  25
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  25
       10.2.  Informative References . . . . . . . . . . . . . . . . .  26
     Appendix A.  Application Examples . . . . . . . . . . . . . . . .  29
       A.1.  Rolling Stock . . . . . . . . . . . . . . . . . . . . . .  29
       A.2.  Building Automation . . . . . . . . . . . . . . . . . . .  29
       A.3.  Substation Automation . . . . . . . . . . . . . . . . . .  30
       A.4.  Electric Vehicle Charging Infrastructure  . . . . . . . .  30
       A.5.  Infrastructure Isolation Policy . . . . . . . . . . . . .  31
       A.6.  Sites with Insufficient Level of Operational Security . .  31
     Appendix B.  History of Changes TBD RFC Editor: please delete . .  31
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  42
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  42

  1.  Introduction

     BRSKI [RFC8995] is typically used with Enrollment over Secure
     Transport (EST, [RFC7030]) as the enrollment protocol for operator-
     specific device certificates, employing HTTP over TLS for secure
     message transfer.  BRSKI-AE is a variant using alternative enrollment
     protocols with authenticated self-contained objects for the device
     certificate enrollment.

     This approach offers several distinct advantages.  It allows for the
     authentication of the origin of requests and responses independently
     of message transfer mechanisms.  This capability facilitates end-to-
     end authentication (i.e., end-to-end proof of origin) across multiple
     transport hops and supports the asynchronous operation of certificate
     enrollment.  Consequently, this provides architectural flexibility in
     determining the location and timing for the ultimate authentication
     and authorization of certification requests, while ensuring that the
     integrity and authenticity of the enrollment messages is maintained
     with full cryptographic strength.

     This specification carries over the main characteristics of BRSKI,
     namely:

     *  The pledge is assumed to have received its Initial Device
        IDentifier (IDevID, [IEEE_802.1AR-2018]) credentials during its
        manufacturing.  It uses them to authenticate itself to the
        Manufacturer Authorized Signing Authority (MASA, [RFC8995]), and
        to the registrar, which is the access point of the target domain,
        and to possibly further components of the domain where it will be
        operated.




  von Oheimb, et al.        Expires 21 March 2025                 [Page 3]


  Internet-Draft                  BRSKI-AE                  September 2024


     *  The pledge first obtains via the voucher [RFC8366] exchange a
        trust anchor for authenticating entities in the domain such as the
        domain registrar.

     *  The pledge then obtains its Locally significant Device IDentifier
        (IDevID, [IEEE_802.1AR-2018]).  To this end, the pledge generates
        a private key, called LDevID secret, and requests via the domain
        registrar from the PKI of its new domain a domain-specific device
        certificate, called LDevID certificate.  On success, it receives
        the LDevID certificate along with its certificate chain.

     The objectives of BRSKI-AE are to enhance BRSKI by enabling LDevID
     certificate enrollment through the use of an alternative protocol to
     EST that:

     *  Supports end-to-end authentication over multiple transport hops.

     *  Facilitates secure message exchange over any type of transfer
        mechanism, including asynchronous delivery.

     It may be observed that the BRSKI voucher exchange between the
     pledge, registrar, and MASA involves the use of authenticated self-
     contained objects, which inherently possess these properties.

     The existing well-known URI structure used for BRSKI and EST messages
     is extended by introducing an additional path element that specifies
     the enrollment protocol being employed.

     This specification allows the registrar to offer multiple enrollment
     protocols, enabling pledges and their developers to select the most
     appropriate one based on the defined overall approach and specific
     endpoints.

     It may be important to note that BRSKI (RFC 8995) specifies the use
     of HTTP over TLS, but variations such as Constrained BRSKI
     [I-D.ietf-anima-constrained-voucher] which uses CoAP over DTLS, are
     possible as well.  In this context, 'HTTP' and 'TLS' are used as
     references to the most common implementation, though variants using
     CoAP and/or DTLS are implied where applicable, as the distinctions
     are not pertinent here.











  von Oheimb, et al.        Expires 21 March 2025                 [Page 4]


  Internet-Draft                  BRSKI-AE                  September 2024


     This specification, together with its referenced documents, is
     sufficient to support BRSKI with the Certificate Management Protocol
     (CMP, [RFC9480]) as profiled in the Lightweight CMP Profile (LCMPP,
     [RFC9483]).  Integrating BRSKI with an enrollment protocol or profile
     other than LCMPP will necessitate additional IANA registrations, as
     detailed in this document.  Furthermore, additional specifications
     may be required for the details of the protocol or profile, which
     fall outside the scope of this document.

  1.1.  Supported Scenarios

     BRSKI-AE is designed for use in scenarios such as the following:

     *  Pledges and/or the target domain leverage an existing certificate
        enrollment protocol other than EST, such as CMP.

     *  The application context precludes the use of EST for certificate
        enrollment due to factors such as:

        -  The Registration Authority (RA) is not co-located with the
           registrar and requires end-to-end authentication of requesters,
           which EST does not support over multiple transport hops.

        -  The RA or Certification Authority (CA) operator mandates
           auditable proof of origin for Certificate Signing Requests
           (CSRs), which cannot be provided by TLS as it only offers
           transient source authentication.

        -  Certificates are requested for key types, such as Key
           Encapsulation Mechanism (KEM) keys, that do not support signing
           or other single-shot proof-of-possession methods, as those
           described in [RFC6955].  EST, which relies on CSRs in PKCS #10
           [RFC2986] format, does not accommodate these key types because
           it necessitates proof-of-possession methods that operate within
           a single message, whereas proof of possession for KEM keys
           requires prior receipt of a fresh challenge value.

        -  The pledge implementation employs security libraries that do
           not support EST or uses a TLS library lacking support for the
           "tls-unique" value [RFC5929], which EST requires for the strong
           binding of source authentication.

     *  Full RA functionality is not available on-site within the target
        domain, and connectivity to an off-site RA may be intermittent or
        entirely offline.






  von Oheimb, et al.        Expires 21 March 2025                 [Page 5]


  Internet-Draft                  BRSKI-AE                  September 2024


     *  Authoritative actions by a local RA at the registrar are
        insufficient for fully and reliably authorizing pledge
        certification requests, potentially due to a lack of access to
        necessary data or inadequate security measures, such as the local
        storage of private keys.

     Bootstrapping may be managed in various ways depending on the
     application domain.  Appendix A provides illustrative examples from
     different industrial control system environments and operational
     contexts that motivate the support of alternative enrollment
     protocols.

  2.  Terminology and abbreviations

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

     This document relies on the terminology defined in [RFC8995],
     [RFC5280], and [IEEE_802.1AR-2018], partly repeated here.  Also
     several further terms are described here.

     To be independent of the terminology of a specific enrollment
     protocol, this document utilizes generic terminology regarding PKI
     management operations.

     asynchronous:  time-wise interrupted delivery of messages,
        here between a pledge and some backend system (e.g., an RA)

     attribute request:  message requesting content to be included in the
        certification request

     attribute response:  message providing the answer to the attribute
        request

     authenticated self-contained object:  a data structure that is
        cryptographically bound to the identity of its originator by an
        attached digital signature on the actual object, using a private
        key of the originator such as the IDevID secret.

     backend:  placement of a domain component separately from the domain
        registrar; may be on-site or off-site

     BRSKI:  Bootstrapping Remote Secure Key Infrastructure [RFC8995]

     BRSKI-AE:  BRSKI with *A*lternative *E*nrollment, a variation of



  von Oheimb, et al.        Expires 21 March 2025                 [Page 6]


  Internet-Draft                  BRSKI-AE                  September 2024


        BRSKI [RFC8995] in which BRSKI-EST, the enrollment protocol
        between pledge and the registrar, is replaced by enrollment
        protocols that support end-to-end authentication of the pledge to
        the RA, such as Lightweight CMP (see LCMPP).

     CA certs request:  message requesting CA certificates

     CA certs response:  message providing the answer to a CA certs
        request

     certificate confirm:  message stating to the backend PKI that the
        requester of a certificate received the new certificate and
        accepted it

     certification request:  message requesting a certificate with proof
        of identity

     certification response:  message providing the answer to a
        certification request

     CMP:  Certificate Management Protocol [RFC4210] [RFC9480]

     CSR:  Certificate Signing Request

     EST:  Enrollment over Secure Transport [RFC7030]

     IDevID:  Initial Device IDentifier of a pledge, provided by the
        manufacturer and comprising a private key and the related X.509
        certificate with its chain

     LCMPP:  Lightweight CMP Profile [RFC9483]

     LDevID:  Locally significant Device IDentifier of a pledge, provided
        by its target domain and comprising a private key and the related
        X.509 certificate with its chain

     local RA (LRA):  a subordinate RA that is close to entities being
        enrolled and separate from a subsequent RA.  In BRSKI-AE it is
        needed if a backend RA is used, and in this case, the LRA is co-
        located with the registrar.

     MASA:  Manufacturer Authorized Signing Authority, provides vouchers

     off-site:  locality of component or service or functionality, such as
        RA or CA, not at the site of the registrar.  This may be a central
        site or a cloud service, to which connection may be intermittent.

     on-site:  locality of a component or service or functionality at the



  von Oheimb, et al.        Expires 21 March 2025                 [Page 7]


  Internet-Draft                  BRSKI-AE                  September 2024


        site of the registrar

     PKI/registrar confirm:  acknowledgment of the PKI on the certificate
        confirm

     pledge:  device that is to be bootstrapped into a target domain.  It
        requests an LDevID using IDevID credentials installed by its
        manufacturer.

     RA:  Registration Authority, the PKI component to which a CA
        typically delegates certificate management functions such as
        authenticating pledges and performing authorization checks on
        certification requests

     registrar:  short for domain registrar

     site:  the locality where an entity, such as a pledge, registrar, or
        PKI component is deployed.  The target domain may have multiple
        sites.

     synchronous:  time-wise uninterrupted delivery of messages, here
        between a pledge and a registrar or backend system (e.g., the
        MASA)

     target domain:  the domain that a pledge is going to be bootstrapped
        into

  3.  Basic Requirements and Mapping to Solutions

     Based on the intended target scenarios described in Section 1.1 and
     the application examples described in Appendix A, the following
     requirements are derived to support authenticated self-contained
     objects as containers carrying certification requests.

     The following properties are required for a certification request:

     *  Proof of possession: demonstrates access to the private key
        corresponding to the public key contained in a certification
        request.  This is typically achieved by a self-signature using the
        corresponding private key but can also be achieved indirectly, see
        [RFC4210], Section 4.3.

     *  Proof of identity, also called proof of origin: provides data
        origin authentication of the certification request.  Typically,
        this is achieved by a signature using the pledge IDevID secret
        over some data, which needs to include a sufficiently strong
        identifier of the pledge, such as the device serial number
        typically included in the subject of the IDevID certificate.



  von Oheimb, et al.        Expires 21 March 2025                 [Page 8]


  Internet-Draft                  BRSKI-AE                  September 2024


     The remainder of this section gives a non-exhaustive list of solution
     examples, based on existing technology described in IETF documents.

  3.1.  Solution Options for Proof of Possession

     Certificate signing request (CSR) objects: CSRs are data structures
     protecting only the integrity of the contained data and providing
     proof of possession for a (locally generated) private key.  Important
     types of CSR data structures are:

     *  PKCS #10 [RFC2986].  This very common form of CSR is self-signed
        to protect its integrity and to prove possession of the private
        key that corresponds to the public key included in the request.

     *  Certificate Request Message Format (CRMF, [RFC4211]).  This less
        common but more general CSR format supports several ways of
        integrity protection and proof of possession.  Typically a self-
        signature is used, which is generated over (part of) the structure
        with the private key corresponding to the included public key.
        CRMF also supports further proof-of-possession methods for types
        of keys that do not have signing capability.  For details see
        [RFC4211], Section 4.

     It should be noted that the integrity protection of CSRs includes the
     public key because it is part of the data signed by the corresponding
     private key.  Yet this signature does not provide data origin
     authentication, i.e., proof of identity of the requester because the
     key pair involved is new and therefore does not yet have a confirmed
     identity associated with it.

  3.2.  Solution Options for Proof of Identity

     Binding a certificate signing request (CSR) to an existing
     authenticated credential (the BRSKI context, the IDevID certificate)
     enables proof of origin, which in turn supports an authorization
     decision on the CSR.

     The binding of data origin authentication to the CSR is typically
     delegated to the protocol used for certificate management.  This
     binding may be achieved through security options in an underlying
     transport protocol such as TLS if the authorization of the
     certification request is (sufficiently) done at the next
     communication hop.  Depending on the key type, the binding can also
     be done in a stronger, transport-independent way by wrapping the CSR
     with a signature.

     This requirement is addressed by existing enrollment protocols in
     various ways, such as:



  von Oheimb, et al.        Expires 21 March 2025                 [Page 9]


  Internet-Draft                  BRSKI-AE                  September 2024


     *  EST [RFC7030], also its variant EST-coaps [RFC9148], utilizes PKCS
        #10 to encode Certificate Signing Requests (CSRs).  While such a
        CSR has not been designed to include proof of origin, there is a
        limited, indirect way of binding it to the source authentication
        of the underlying TLS session.  This is achieved by including in
        the CSR the tls-unique value [RFC5929] resulting from the TLS
        handshake.  As this is optionally supported by the EST
        "/simpleenroll" endpoint used in BRSKI and the TLS handshake
        employed in BRSKI includes certificate-based client authentication
        of the pledge with its IDevID credentials, the proof of pledge
        identity being an authenticated TLS client can be bound to the
        CSR.

        Yet this binding is only valid in the context of the TLS session
        established with the registrar acting as the EST server and
        typically also as an RA.  So even such a cryptographic binding of
        the authenticated pledge identity to the CSR is not visible nor
        verifiable to authorization points outside the registrar, such as
        a (second) RA in the backend.  What the registrar needs to do is
        to authenticate and pre-authorize the pledge and to indicate this
        to the (second) RA by signing the forwarded certification request
        with its private key and a related certificate that has the id-kp-
        cmcRA extended key usage attribute.

        [RFC7030], Section 2.5 sketches wrapping PKCS #10-formatted CSRs
        with a Full PKI Request message sent to the "/fullcmc" endpoint.
        This would allow for source authentication at the message level,
        such that the registrar could forward it to external RAs in a
        meaningful way.  This approach is so far not sufficiently
        described and likely has not been implemented.

     *  SCEP [RFC8894] supports using a shared secret (passphrase) or an
        existing certificate to protect CSRs based on SCEP Secure Message
        Objects using CMS wrapping ([RFC5652]).  Note that the wrapping
        using an existing IDevID in SCEP is referred to as 'renewal'.
        This way SCEP does not rely on the security of the underlying
        message transfer.

     *  CMP [RFC4210] [RFC9480] supports using a shared secret
        (passphrase) or an existing certificate, which may be an IDevID
        credential, to authenticate certification requests via the
        PKIProtection structure in a PKIMessage.  The certification
        request is typically encoded utilizing CRMF, while PKCS #10 is
        supported as an alternative.  Thus, CMP does not rely on the
        security of the underlying message transfer.






  von Oheimb, et al.        Expires 21 March 2025                [Page 10]


  Internet-Draft                  BRSKI-AE                  September 2024


     *  CMC [RFC5272] also supports utilizing a shared secret (passphrase)
        or an existing certificate to protect certification requests,
        which can be either in CRMF or PKCS #10 structure.  The proof of
        identity can be provided as part of a FullCMCRequest, based on CMS
        [RFC5652] and signed with an existing IDevID secret.  Thus, CMC
        does not rely on the security of the underlying message transfer.

     To sum up, EST does not meet the requirements for authenticated self-
     contained objects, but SCEP, CMP, and CMC do.  This document
     primarily focuses on CMP as it has more industry adoption than CMC
     and SCEP has issues not detailed here.

  4.  Adaptations to BRSKI

     To enable using alternative certificate enrollment protocols
     supporting end-to-end authentication, asynchronous enrollment, and
     more general system architectures, BRSKI-AE provides some
     generalizations on BRSKI [RFC8995].  This way, authenticated self-
     contained objects such as those described in Section 3 above can be
     used for certificate enrollment, and RA functionality can be deployed
     freely in the target domain.  Parts of the RA functionality can even
     be distributed over several nodes.

     The enhancements are kept to a minimum to ensure the reuse of already
     defined architecture elements and interactions.  In general, the
     communication follows the BRSKI model and utilizes the existing BRSKI
     architecture elements.  In particular, the pledge initiates
     communication with the domain registrar and interacts with the MASA
     as usual for voucher request and response processing.

  4.1.  Architecture

     The key element of BRSKI-AE is that the authorization of a
     certification request MUST be performed based on an authenticated
     self-contained object.  The certification request is bound in a self-
     contained way to a proof of origin based on the IDevID credentials.
     Consequently, the certification request MAY be transferred using any
     mechanism or protocol.  Authentication and authorization of the
     certification request can be done by the domain registrar and/or by
     backend domain components.  As mentioned in Section 1.1, these
     components may be offline or off-site.  The registrar and other on-
     site domain components may have no or only temporary (intermittent)
     connectivity to them.

     This leads to generalizations in the placement and enhancements of
     the logical elements as shown in Figure 1.





  von Oheimb, et al.        Expires 21 March 2025                [Page 11]


  Internet-Draft                  BRSKI-AE                  September 2024


                                              +------------------------+
        +--------------Drop-Ship--------------| Vendor Service         |
        |                                     +------------------------+
        |                                     | M anufacturer|         |
        |                                     | A uthorized  |Ownership|
        |                                     | S igning     |Tracker  |
        |                                     | A uthority   |         |
        |                                     +--------------+---------+
        |                                                      ^
        |                                                      |
        V                                                      | BRSKI-
     +--------+     .........................................  | MASA
     |        |     .                                       .  |
     |        |     .  +-------+          +--------------+  .  |
     | Pledge |     .  | Join  |          | Domain       |<----+
     |        |<------>| Proxy |<-------->| Registrar    |  .
     |        |     .  |       |          | w/ LRA or RA |  .
     | IDevID |     .  +-------+          +--------------+  .
     |        |   BRSKI-AE over TLS                ^        .
     +--------+   using, e.g., LCMPP               |        .
                    .                              |        .
                    ...............................|.........
                 on-site (local) domain components |
                                                   |
                                                   | e.g., LCMPP
                                                   |
      .............................................|...............
      . Public-Key Infrastructure                  v              .
      . +---------+     +---------------------------------------+ .
      . |         |<----+   Registration Authority RA           | .
      . |    CA   +---->|   (unless part of Domain Registrar)   | .
      . +---------+     +---------------------------------------+ .
      .............................................................
              backend (central or off-site) domain components

          Figure 1: Architecture Overview Using Backend PKI Components

     The architecture overview in Figure 1 has the same logical elements
     as BRSKI, but with a more flexible placement of the authentication
     and authorization checks on certification requests.  Depending on the
     application scenario, the registrar MAY still do all of these checks
     (as is the case in BRSKI), or part of them.

     The following list describes the on-site components in the target
     domain of the pledge shown in Figure 1.

     *  Join Proxy: same requirements as in BRSKI, see [RFC8995],
        Section 4



  von Oheimb, et al.        Expires 21 March 2025                [Page 12]


  Internet-Draft                  BRSKI-AE                  September 2024


     *  Domain Registrar including LRA or RA functionality: in BRSKI-AE,
        the domain registrar has mostly the same functionality as in
        BRSKI, namely to act as the gatekeeper of the domain for
        onboarding new devices and to facilitate the communication of
        pledges with their MASA and the domain PKI.  Yet there are some
        generalizations and specific requirements:

        1.  The registrar MUST support at least one certificate enrollment
            protocol with authenticated self-contained objects for
            certification requests.  To this end, the URI scheme for
            addressing endpoints at the registrar is generalized (see
            Section 4.3).

        2.  Rather than having full RA functionality, the registrar MAY
            act as a local registration authority (LRA) and delegate part
            of its involvement in certificate enrollment to a backend RA.
            In such scenarios, the registrar optionally checks
            certification requests it receives from pledges and forwards
            them to the backend RA, which performs the remaining parts of
            the enrollment request validation and authorization.  Note
            that to this end the backend RA may need information regarding
            the authorization of pledges from the registrar or from other
            sources.  On the way back, the registrar forwards responses by
            the PKI to the pledge on the same channel.

            To support end-to-end authentication of the pledge across the
            registrar to the backend RA, the certification request signed
            by the pledge needs to be upheld and forwarded by the
            registrar.  Therefore, the registrar cannot use for its
            communication with the PKI an enrollment protocol that is
            different from the enrollment protocol used between the pledge
            and the registrar.

        3.  The use of a certificate enrollment protocol with
            authenticated self-contained objects gives freedom how to
            transfer enrollment messages between the pledge and an RA.
            BRSKI demands that the RA accept certification requests for
            LDevIDs only with the consent of the registrar.  BRSKI-AE
            guarantees this also in case that the RA is not part of the
            registrar, even if the message exchange with backend systems
            is unprotected and involves further transport hops.  See
            Section 7 for details on how this can be achieved.

     Despite the above generalizations to the enrollment phase, the final
     step of BRSKI, namely the enrollment status telemetry, is kept as it
     is.





  von Oheimb, et al.        Expires 21 March 2025                [Page 13]


  Internet-Draft                  BRSKI-AE                  September 2024


     The following list describes the components provided by the vendor or
     manufacturer outside the target domain.

     *  MASA: functionality as described in BRSKI [RFC8995].  The voucher
        exchange with the MASA via the domain registrar is performed as
        described in BRSKI.

        Note: From the definition of the interaction with the MASA in
        [RFC8995], Section 5 follows that it may be synchronous (using
        voucher request with nonces) or asynchronous (using nonceless
        voucher requests).

     *  Ownership tracker: as defined in BRSKI.

     The following list describes backend target domain components, which
     may be located on-site or off-site in the target domain.

     *  RA: performs centralized certificate management functions as a
        public-key infrastructure for the domain operator.  As far as not
        already done by the domain registrar, it performs the final
        validation and authorization of certification requests.
        Otherwise, the RA co-located with the domain registrar directly
        connects to the CA.

     *  CA, also called domain CA: generates domain-specific certificates
        according to certification requests that have been authenticated
        and authorized by the registrar and/or an extra RA.

     Based on the diagram in BRSKI [RFC8995], Section 2.1 and the
     architectural changes, the original protocol flow is divided into
     several phases showing commonalities and differences to the original
     approach as follows.

     *  Discovery phase: mostly as in BRSKI step (1).  For details see
        Section 4.2.1.

     *  Identification phase: same as in BRSKI step (2).

     *  Voucher exchange phase: same as in BRSKI steps (3) and (4).

     *  Voucher status telemetry: same as in BRSKI directly after step
        (4).

     *  Certificate enrollment phase: the use of EST in step (5) is
        changed to employing a certificate enrollment protocol that uses
        an authenticated self-contained object for requesting the LDevID
        certificate.




  von Oheimb, et al.        Expires 21 March 2025                [Page 14]


  Internet-Draft                  BRSKI-AE                  September 2024


        For transporting the certificate enrollment request and response
        messages, the (D)TLS channel established between pledge and
        registrar is REQUIRED to use.  To this end, the enrollment
        protocol, the pledge, and the registrar need to support the use of
        this existing channel for certificate enrollment.  Due to this
        architecture, the pledge does not need to establish additional
        connections for certificate enrollment and the registrar retains
        full control over the certificate enrollment traffic.

     *  Enrollment status telemetry: the final exchange of BRSKI step (5).

  4.2.  Message Exchange

     The behavior of a pledge described in BRSKI [RFC8995], Section 2.1 is
     kept, with one major exception.  After finishing the Imprint step
     (4), the Enroll step (5) MUST be performed with an enrollment
     protocol utilizing authenticated self-contained objects, as explained
     in Section 3.  Section 5 discusses selected suitable enrollment
     protocols and options applicable.

     An abstract overview of the BRSKI-AE protocol can be found at
     [BRSKI-AE-overview].

  4.2.1.  Pledge - Registrar Discovery

     Discovery as specified in BRSKI [RFC8995], Section 4 does not support
     the discovery of registrars with enhanced feature sets.  A pledge can
     not find out in this way whether discovered registrars support the
     certificate enrollment protocol it expects, such as CMP.

     As a more general solution, the BRSKI discovery mechanism can be
     extended to provide up-front information on the capabilities of
     registrars.  For further discussion, see
     [I-D.ietf-anima-brski-discovery].

     In the absence of such a generally applicable solution, BRSKI-AE
     deployments may use their particular way of doing discovery.
     Section 5.1 defines a minimalist approach that MAY be used for CMP.

  4.2.2.  Pledge - Registrar - MASA Voucher Exchange

     The voucher exchange is performed as specified in [RFC8995].

  4.2.3.  Pledge - Registrar - MASA Voucher Status Telemetry

     The voucher status telemetry is performed as specified in [RFC8995],
     Section 5.7.




  von Oheimb, et al.        Expires 21 March 2025                [Page 15]


  Internet-Draft                  BRSKI-AE                  September 2024


  4.2.4.  Pledge - Registrar - RA/CA Certificate Enrollment

     This replaces the EST integration for PKI bootstrapping described in
     [RFC8995], Section 5.9 (while [RFC8995], Section 5.9.4 remains as the
     final phase, see below).

     The certificate enrollment phase may involve the transmission of
     several messages.  Details can depend on the application scenario,
     the employed enrollment protocol, and other factors.

     The only message exchange REQUIRED is for the actual certification
     request and response.  Further message exchanges MAY be performed as
     needed.

     Note: The message exchanges marked OPTIONAL in the below Figure 2
     cover all those supported by the use of EST in BRSKI.  The last
     OPTIONAL one, namely certificate confirmation, is not supported by
     EST, but by CMP and other enrollment protocols.

































  von Oheimb, et al.        Expires 21 March 2025                [Page 16]


  Internet-Draft                  BRSKI-AE                  September 2024


     +------+                          +---------+              +--------+
     |Pledge|                          |Domain   |              |Operator|
     |      |                          |Registrar|              |RA/CA   |
     |      |                          |(JRC)    |              |(PKI)   |
     +------+                          +---------+              +--------+
      |                                     |                           |
      |[OPTIONAL request of CA certificates]|                           |
      |------- CA Certs Request (1) ------->|                           |
      |                                     | [OPTIONAL forwarding]     |
      |                                     |--- CA Certs Request ----->|
      |                                     |<-- CA Certs Response -----|
      |<------ CA Certs Response (2) -------|                           |
      |                                     |                           |
      |[OPTIONAL request of attributes      |                           |
      | to include in Certification Request]|                           |
      |------- Attribute Request (3) ------>|                           |
      |                                     | [OPTIONAL forwarding]     |
      |                                     |--- Attribute Request ---->|
      |                                     |<-- Attribute Response ----|
      |<------ Attribute Response (4) ------|                           |
      |                                     |                           |
      |[REQUIRED certification request]     |                           |
      |------- Certification Request (5) -->|                           |
      |                                     | [OPTIONAL forwarding]     |
      |                                     |---Certification Request-->|
      |                                     |<--Certification Resp.  ---|
      |<----- Certification Response (6) ---|                           |
      |                                     |                           |
      |[OPTIONAL certificate confirmation]  |                           |
      |------- Certificate Confirm (7) ---->|                           |
      |                                     | [OPTIONAL forwarding]     |
      |                                     |--- Certificate Confirm--->|
      |                                     |<-- PKI Confirm -----------|
      |<------ PKI/Registrar Confirm (8) ---|                           |

                 Figure 2: Certificate Enrollment Message Flow

     It may be noted that connections between the registrar and the PKI
     components of the operator (RA, CA, etc.) may be intermittent or off-
     line.  Messages should be sent as soon as sufficient transfer
     capacity is available.










  von Oheimb, et al.        Expires 21 March 2025                [Page 17]


  Internet-Draft                  BRSKI-AE                  September 2024


     The label [OPTIONAL forwarding] in Figure 2 means that on receiving
     from a pledge a request message of the given type, the registrar MAY
     answer the request directly.  In this case, it MUST authenticate its
     responses with the same credentials as used for authenticating itself
     at the TLS level for the voucher exchange.  Otherwise, the registrar
     MUST forward the request to the RA and forward any resulting response
     back to the pledge.

     The decision of whether to forward a request or to answer it directly
     can depend on various static and dynamic factors.  They include the
     application scenario, the capabilities of the registrar and of the
     local RA possibly co-located with the registrar, the enrollment
     protocol being used, and the specific contents of the request.

     Note that there are several options for how the registrar could be
     able to directly answer requests for CA certificates or for
     certification request attributes.  It could cache responses obtained
     from the domain PKI and later use their contents for responding to
     requests asking for the same data.  The contents could also be
     explicitly provisioned at the registrar.

     Further note that certification requests typically need to be handled
     by the backend PKI, but the registrar can answer them directly with
     an error response in case it determines that such a request should be
     rejected, for instance, because is not properly authenticated or not
     authorized.Also, certificate confirmation messages will usually be
     forwarded to the backend PKI, but if the registrar knows that they
     are not needed or wanted there it can acknowledge such messages
     directly.

     The following list provides an abstract description of the flow
     depicted in Figure 2.

     *  CA Certs Request (1): The pledge optionally requests the latest
        relevant CA certificates.  This ensures that the pledge has the
        complete set of current CA certificates beyond the pinned-domain-
        cert (which is contained in the voucher and which may be just the
        domain registrar certificate).

     *  CA Certs Response (2): This MUST contain any intermediate CA
        certificates that the pledge may need to validate certificates and
        MAY contain the LDevID trust anchor.









  von Oheimb, et al.        Expires 21 March 2025                [Page 18]


  Internet-Draft                  BRSKI-AE                  September 2024


     *  Attribute Request (3): Typically, the automated bootstrapping
        occurs without local administrative configuration of the pledge.
        Nevertheless, there are cases in which the pledge may also include
        in the Certification Request (5) additional attributes that are
        specific to the target domain.  To get these attributes in
        advance, the attribute request may be used.

     *  Attribute Response (4): This MUST contain the attributes requested
        in (3) to be included in the subsequent Certification Request (5).

        For example, [RFC8994], Section 6.11.7.2 specifies how the
        attribute request is used to signal to the pledge the acp-node-
        name field required for enrollment into an ACP domain.

     *  Certification Request (5): This MUST contain the authenticated
        self-contained object ensuring both the proof of possession of the
        corresponding private key and the proof of identity of the
        requester.

     *  Certification Response (6): This MUST contain on success the
        requested certificate and MAY include further information, like
        certificates of intermediate CAs and any additional trust anchors.

     *  Certificate Confirm (7): An optional confirmation sent after the
        requested certificate has been received and validated.  If sent,
        it MUST contain a positive or negative confirmation by the pledge
        to the PKI whether the certificate was successfully enrolled and
        fits its needs.

     *  PKI/Registrar Confirm (8): An acknowledgment by the PKI that MUST
        be sent on reception of the Certificate Confirm.

     The generic messages described above may be implemented using any
     certificate enrollment protocol that supports authenticated self-
     contained objects for the certification request as described in
     Section 3.  Examples are available in Section 5.

     Note that the optional certificate confirmation by the pledge to the
     PKI described above is independent of the mandatory enrollment status
     telemetry done between the pledge and the registrar in the final
     phase of BRSKI-AE, described next.

  4.2.5.  Pledge - Registrar Enrollment Status Telemetry

     The enrollment status telemetry is performed as specified in
     [RFC8995], Section 5.9.4.





  von Oheimb, et al.        Expires 21 March 2025                [Page 19]


  Internet-Draft                  BRSKI-AE                  September 2024


     In BRSKI this is described as part of the certificate enrollment
     step, but due to the generalization on the enrollment protocol
     described in this document it is regarded as a separate phase here.

  4.3.  Enhancements to the Endpoint Addressing Scheme of BRSKI

     BRSKI-AE extends the addressing scheme outlined in [RFC8995],
     Section 5, to support alternative enrollment protocols that utilize
     authenticated, self-contained objects for certification requests --
     see also Section 5).  These extensions are designed to be compatible
     with existing Registration Authorities (RAs) and Certification
     Authorities (CAs) that already support such enrollment protocols,
     enabling their use without requiring any modifications.

     The addressing scheme in BRSKI for certification requests and the
     related CA certificates and CSR attributes retrieval functions uses
     the definition from EST [RFC7030].  Here is the example of simple
     enrollment: "/.well-known/est/simpleenroll".  This approach is
     generalized to the following notation: "/.well-known/<enrollment-
     protocol>/<request>" in which <enrollment-protocol> refers to a
     certificate enrollment protocol.  Note that enrollment is considered
     here a message sequence that contains at least a certification
     request and a certification response.  The following conventions are
     used to provide maximal compatibility with BRSKI:

     *  <enrollment-protocol>: MUST reference the protocol being used.
        Existing values include 'est' [RFC7030] as in BRSKI and 'cmp' as
        in [RFC9483] and Section 5.1 below.  Values for other existing
        protocols such as CMC and SCEP, as well as for newly defined
        protocols are outside the scope of this document.  For use of the
        <enrollment-protocol> and <request> URI components, they would
        need to be specified in a suitable RFC and placed into the Well-
        Known URIs registry, just as EST in [RFC7030].

     *  <request>: if present, this path component MUST describe,
        depending on the enrollment protocol being used, the operation
        requested.  Enrollment protocols are expected to define their
        request endpoints, as done by existing protocols (see also
        Section 5).

     Well-known URIs for various endpoints on the domain registrar are
     already defined as part of the base BRSKI specification or indirectly
     by EST.  In addition, alternative enrollment endpoints MAY be
     supported by the registrar.

     A pledge SHOULD use the endpoints defined for the enrollment
     protocol(s) that it can use.  It will recognize whether the protocol
     it uses and the specific request it wants to perform are understood



  von Oheimb, et al.        Expires 21 March 2025                [Page 20]


  Internet-Draft                  BRSKI-AE                  September 2024


     and supported by the domain registrar by sending the request to the
     respective endpoint according to the above addressing scheme and then
     evaluating the HTTP status code of the response.  If the pledge uses
     endpoints that are not standardized, it risks that the registrar does
     not recognize a request and thus may reject it, even if the registrar
     supports the intended protocol and operation.

     The following list of endpoints provides an illustrative example of a
     domain registrar supporting several options for EST as well as for
     CMP to be used in BRSKI-AE.  The listing contains the supported
     endpoints to which the pledge may connect for bootstrapping.  This
     includes the voucher handling as well as the enrollment endpoints.
     The CMP-related enrollment endpoints are defined as well-known URIs
     in CMP Updates [RFC9480] and the Lightweight CMP Profile [RFC9483].

       /.well-known/brski/voucherrequest
       /.well-known/brski/voucher_status
       /.well-known/brski/enrollstatus
       /.well-known/est/cacerts
       /.well-known/est/csrattrs
       /.well-known/est/fullcmc
       /.well-known/cmp/getcacerts
       /.well-known/cmp/getcertreqtemplate
       /.well-known/cmp/initialization
       /.well-known/cmp/pkcs10

  5.  Instantiation with Existing Enrollment Protocols

     This section maps the generic requirements to support proof of
     possession and proof of identity to selected existing certificate
     enrollment protocols and specifies further aspects of using such
     enrollment protocols in BRSKI-AE.

  5.1.  BRSKI-CMP: BRSKI-AE instantiated with CMP

     In this document, references to CMP follow the Lightweight CMP
     Profile (LCMPP) [RFC9483] rather than [RFC4210] and [RFC9480], as the
     subset of CMP defined in LCMPP sufficiently meets the required
     functionality.

     Adherence to the LCMPP [RFC9483] is REQUIRED when using CMP.  The
     following specific requirements apply (refer to Figure 2):

     *  The validation of server response messages performed by the CMP
        client within the pledge MUST be based on the trust anchor
        established beforehand via the BRSKI voucher, i.e., on the pinned-
        domain-cert.




  von Oheimb, et al.        Expires 21 March 2025                [Page 21]


  Internet-Draft                  BRSKI-AE                  September 2024


        Note that the integrity and authenticity checks on the RA/CA by
        the CMP client can be stronger than for EST because they do not
        need to be performed hop-by-hop, but are usually end-to-end.

     *  CA Certs Request (1) and Response (2):
        Requesting CA certificates is OPTIONAL.
        If supported, it SHALL be implemented as specified in [RFC9483],
        Section 4.3.1.

     *  Attribute Request (3) and Response (4):
        Requesting certification request attributes is OPTIONAL.
        If supported, it SHALL be implemented as specified in [RFC9483],
        Section 4.3.3.

        Alternatively, the registrar MAY modify the requested certificate
        contents as specified in [RFC9483], Section 5.2.3.2.

     *  Certification Request (5) and Response (6):
        Certificates SHALL be requested and provided as specified in LCMPP
        [RFC9483], Section 4.1.1 (based on CRMF) or [RFC9483],
        Section 4.1.4 (based on PKCS #10).

        Proof of possession SHALL be provided in a manner suitable for the
        key type.  Proof of identity SHALL be provided by signature-based
        protection of the certification request message as outlined in
        [RFC9483], Section 3.2, using the IDevID secret.

        When the registrar forwards a certification request from the
        pledge to a backend RA/CA, it is RECOMMENDED that the registrar
        wraps the original certification request in a nested message
        signed with its own credentials, as described in [RFC9483],
        Section 5.2.2.1.  This approach explicitly conveys the registrar's
        consent to the RA while retaining the original certification
        request with the proof of origin provided by the pledge's
        signature.

        If additional trust anchors, beyond the pinned-domain-cert, need
        to be conveyed to the pledge, this SHOULD be done in the caPubs
        field of the certification response rather than through a CA Certs
        Response.

     *  Certificate Confirm (7) and PKI/Registrar Confirm (8):
        Explicit confirmation of new certificates to the RA/CA MAY be used
        as specified in [RFC9483], Section 4.1.1.

        Note that independent of the certificate confirmation within CMP,
        enrollment status telemetry with the registrar at the BRSKI level
        will be performed as described in [RFC8995], Section 5.9.4.



  von Oheimb, et al.        Expires 21 March 2025                [Page 22]


  Internet-Draft                  BRSKI-AE                  September 2024


     *  If delayed delivery of CMP messages is needed (e.g., to support
        enrollment over an asynchronous channel), it SHALL be performed as
        specified in Section 4.4 and Section 5.1.2 of [RFC9483].

     The mechanisms for exchanging messages between the registrar and
     backend PKI components (i.e., RA and/or CA) are outside the scope of
     this document.  CMP's independence from the message transfer
     mechanism allows for flexibility in choosing the appropriate exchange
     method based on the application scenario.  For the applicable
     security and privacy considerations, refer to Section 7 and
     Section 8.  Further guidance can be found in [RFC9483], Section 6.

     BRSKI-AE with CMP can also be combined with Constrained BRSKI
     [I-D.ietf-anima-constrained-voucher], using CoAP for enrollment
     message transport as described by CoAP Transport for CMP [RFC9482].
     In such scenarios, the EST-specific parts of
     [I-D.ietf-anima-constrained-voucher] do not apply.

     For BRSKI-AE scenarios where a general solution for discovering
     registrars with CMP support is not available (cf.  Section 4.2.1),
     the following minimalist approach MAY be used: perform discovery as
     defined in BRSKI [RFC8995], Appendix B, but use the service name
     "brski-reg-cmp" (as defined in Section 6) instead of "brski-
     registrar" (as defined in [RFC8995], Section 8.6).  Note that this
     approach does not support join proxies.

  5.2.  Support of Other Enrollment Protocols

     Further instantiations of BRSKI-AE can be done.  They are left for
     future work.

     In particular, CMC [RFC5272] (using its in-band source authentication
     options) and SCEP [RFC8894] (using its 'renewal' option) could be
     used.

     The fullCMC variant of EST sketched in [RFC7030], Section 2.5 might
     also be used here.  For EST-fullCMC further specification is
     necessary.

  6.  IANA Considerations

     This document requires one IANA action: register in the Service Name
     and Transport Protocol Port Number Registry
     (https://www.iana.org/assignments/service-names-port-numbers/service-
     names-port-numbers.xhtml) the following service name.






  von Oheimb, et al.        Expires 21 March 2025                [Page 23]


  Internet-Draft                  BRSKI-AE                  September 2024


     *Service Name:* brski-reg-cmp
     *Transport Protocol(s):* tcp
     *Assignee:* IESG iesg@ietf.org (mailto:iesg@ietf.org)
     *Contact:* IETF chair@ietf.org (mailto:chair@ietf.org)
     *Description:* Bootstrapping Remote Secure Key Infrastructure
     registrar with CMP capabilities according to the Lightweight CMP
     Profile (LCMPP, [RFC9483])
     *Reference:* [THISRFC]

     Note: We chose here the suffix "cmp" rather than some other
     abbreviation like "lcmpp" mainly because this document defines the
     normative CMP instantiation of BRSKI-AE, which implies adherence to
     LCMPP is necessary and sufficient.

  7.  Security Considerations

     The security considerations laid out in BRSKI [RFC8995], Section 11
     apply to the discovery and voucher exchange as well as for the status
     exchange information.

     In particular, even if the registrar delegates part or all of its RA
     role during certificate enrollment to a separate system, it still
     must be made sure that the registrar takes part in the decision on
     accepting or declining a request to join the domain, as required in
     [RFC8995], Section 5.3.  As this pertains also to obtaining a valid
     domain-specific certificate, it must be made sure that a pledge can
     not circumvent the registrar in the decision of whether it is granted
     an LDevID certificate by the CA.  There are various ways how to
     fulfill this, including:

     *  implicit consent

     *  the registrar signals its consent to the RA out-of-band before or
        during the enrollment phase, for instance by entering the pledge
        identity in a database.

     *  the registrar provides its consent using an extra message that is
        transferred on the same channel as the enrollment messages,
        possibly in a TLS tunnel.

     *  the registrar explicitly states its consent by signing, in
        addition to the pledge, the authenticated self-contained
        certificate enrollment request message.

     Note: If EST was used, the registrar could give implicit consent on a
     certification request by forwarding the request to a PKI entity using
     a connection authenticated with a certificate containing an id-kp-
     cmcRA extension.



  von Oheimb, et al.        Expires 21 March 2025                [Page 24]


  Internet-Draft                  BRSKI-AE                  September 2024


     When CMP is used, the security considerations laid out in the LCMPP
     [RFC9483] apply.

  8.  Privacy Considerations

     The privacy considerations laid out in BRSKI [RFC8995], Section 10
     apply as well.

     Note that CMP messages themselves are not encrypted.  This may give
     eavesdroppers insight into which devices are bootstrapped into the
     domain.  This in turn might also be used to selectively block the
     enrollment of certain devices.

     To prevent such issues, the underlying message transport channel can
     be encrypted.  This is already provided by TLS between the pledge and
     the registrar, and for the onward exchange with backend systems,
     encryption may need to be added.

  9.  Acknowledgments

     We thank Eliot Lear for his contributions as a co-author at an
     earlier draft stage.

     We thank Brian E.  Carpenter, Michael Richardson, and Giorgio
     Romanenghi for their input and discussion on use cases and call
     flows.

     Moreover, we thank Toerless Eckert (document shepherd), Barry Leiba
     (SECdir review), Mahesh Jethanandani (IETF area director), Meral
     Shirazipour (Gen-ART reviewer), Reshad Rahman (YANGDOCTORS reviewer),
     Deb Cooley, Gunter Van de Velde, John Scudder, Murray Kucherawy,
     Roman Danyliw, and Éric Vyncke (IESG reviewers), Michael Richardson
     (ANIMA design team member), as well as Rajeev Ranjan, Rufus Buschart,
     Andreas Reiter, and Szofia Fazekas-Zisch (Siemens colleagues) for
     their reviews with suggestions for improvements.

  10.  References

  10.1.  Normative References

     [IEEE_802.1AR-2018]
                IEEE, "IEEE Standard for Local and Metropolitan Area
                Networks - Secure Device Identity", IEEE 802.1AR-2018,
                DOI 10.1109/IEEESTD.2018.8423794, August 2018,
                <https://ieeexplore.ieee.org/document/8423794>.






  von Oheimb, et al.        Expires 21 March 2025                [Page 25]


  Internet-Draft                  BRSKI-AE                  September 2024


     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [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, DOI 10.17487/RFC5280, May 2008,
                <https://www.rfc-editor.org/rfc/rfc5280>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
                and K. Watsen, "Bootstrapping Remote Secure Key
                Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
                May 2021, <https://www.rfc-editor.org/rfc/rfc8995>.

     [RFC9483]  Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight
                Certificate Management Protocol (CMP) Profile", RFC 9483,
                DOI 10.17487/RFC9483, November 2023,
                <https://www.rfc-editor.org/rfc/rfc9483>.

  10.2.  Informative References

     [BRSKI-AE-overview]
                S. Fries and D. von Oheimb, "BRSKI-AE Protocol Overview",
                March 2023,
                <https://datatracker.ietf.org/meeting/116/materials/
                slides-116-anima-update-on-brski-ae-alternative-
                enrollment-protocols-in-brski-00>.  Graphics on slide 4 of
                the status update on the BRSKI-AE draft 04 at IETF 116.

     [I-D.ietf-anima-brski-discovery]
                Eckert, T. T. and E. Dijk, "Discovery for BRSKI
                variations", Work in Progress, Internet-Draft, draft-ietf-
                anima-brski-discovery-04, 25 July 2024,
                <https://datatracker.ietf.org/doc/html/draft-ietf-anima-
                brski-discovery-04>.










  von Oheimb, et al.        Expires 21 March 2025                [Page 26]


  Internet-Draft                  BRSKI-AE                  September 2024


     [I-D.ietf-anima-constrained-voucher]
                Richardson, M., Van der Stok, P., Kampanakis, P., and E.
                Dijk, "Constrained Bootstrapping Remote Secure Key
                Infrastructure (cBRSKI)", Work in Progress, Internet-
                Draft, draft-ietf-anima-constrained-voucher-25, 8 July
                2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
                anima-constrained-voucher-25>.

     [IEC-62351-9]
                International Electrotechnical Commission, "IEC 62351 -
                Power systems management and associated information
                exchange - Data and communications security - Part 9:
                Cyber security key management for power system equipment",
                IEC 62351-9, May 2017.

     [ISO-IEC-15118-2]
                International Standardization Organization / International
                Electrotechnical Commission, "ISO/IEC 15118-2 Road
                vehicles - Vehicle-to-Grid Communication Interface - Part
                2: Network and application protocol requirements", ISO/
                IEC 15118-2, April 2014.

     [NERC-CIP-005-5]
                North American Reliability Council, "Cyber Security -
                Electronic Security Perimeter", CIP 005-5, December 2013.

     [OCPP]     Open Charge Alliance, "Open Charge Point Protocol 2.0.1
                (Draft)", December 2019.

     [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
                Request Syntax Specification Version 1.7", RFC 2986,
                DOI 10.17487/RFC2986, November 2000,
                <https://www.rfc-editor.org/rfc/rfc2986>.

     [RFC4210]  Adams, C., Farrell, S., Kause, T., and T. Mononen,
                "Internet X.509 Public Key Infrastructure Certificate
                Management Protocol (CMP)", RFC 4210,
                DOI 10.17487/RFC4210, September 2005,
                <https://www.rfc-editor.org/rfc/rfc4210>.

     [RFC4211]  Schaad, J., "Internet X.509 Public Key Infrastructure
                Certificate Request Message Format (CRMF)", RFC 4211,
                DOI 10.17487/RFC4211, September 2005,
                <https://www.rfc-editor.org/rfc/rfc4211>.

     [RFC5272]  Schaad, J. and M. Myers, "Certificate Management over CMS
                (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
                <https://www.rfc-editor.org/rfc/rfc5272>.



  von Oheimb, et al.        Expires 21 March 2025                [Page 27]


  Internet-Draft                  BRSKI-AE                  September 2024


     [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
                RFC 5652, DOI 10.17487/RFC5652, September 2009,
                <https://www.rfc-editor.org/rfc/rfc5652>.

     [RFC5929]  Altman, J., Williams, N., and L. Zhu, "Channel Bindings
                for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
                <https://www.rfc-editor.org/rfc/rfc5929>.

     [RFC6955]  Schaad, J. and H. Prafullchandra, "Diffie-Hellman Proof-
                of-Possession Algorithms", RFC 6955, DOI 10.17487/RFC6955,
                May 2013, <https://www.rfc-editor.org/rfc/rfc6955>.

     [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
                "Enrollment over Secure Transport", RFC 7030,
                DOI 10.17487/RFC7030, October 2013,
                <https://www.rfc-editor.org/rfc/rfc7030>.

     [RFC8366]  Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
                "A Voucher Artifact for Bootstrapping Protocols",
                RFC 8366, DOI 10.17487/RFC8366, May 2018,
                <https://www.rfc-editor.org/rfc/rfc8366>.

     [RFC8894]  Gutmann, P., "Simple Certificate Enrolment Protocol",
                RFC 8894, DOI 10.17487/RFC8894, September 2020,
                <https://www.rfc-editor.org/rfc/rfc8894>.

     [RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
                Autonomic Control Plane (ACP)", RFC 8994,
                DOI 10.17487/RFC8994, May 2021,
                <https://www.rfc-editor.org/rfc/rfc8994>.

     [RFC9148]  van der Stok, P., Kampanakis, P., Richardson, M., and S.
                Raza, "EST-coaps: Enrollment over Secure Transport with
                the Secure Constrained Application Protocol", RFC 9148,
                DOI 10.17487/RFC9148, April 2022,
                <https://www.rfc-editor.org/rfc/rfc9148>.

     [RFC9480]  Brockhaus, H., von Oheimb, D., and J. Gray, "Certificate
                Management Protocol (CMP) Updates", RFC 9480,
                DOI 10.17487/RFC9480, November 2023,
                <https://www.rfc-editor.org/rfc/rfc9480>.

     [RFC9482]  Sahni, M., Ed. and S. Tripathi, Ed., "Constrained
                Application Protocol (CoAP) Transfer for the Certificate
                Management Protocol", RFC 9482, DOI 10.17487/RFC9482,
                November 2023, <https://www.rfc-editor.org/rfc/rfc9482>.





  von Oheimb, et al.        Expires 21 March 2025                [Page 28]


  Internet-Draft                  BRSKI-AE                  September 2024


     [UNISIG-Subset-137]
                UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management
                FFFIS; V1.0.0", December 2015,
                <https://www.era.europa.eu/sites/default/files/filesystem/
                ertms/ccs_tsi_annex_a_-_mandatory_specifications/
                set_of_specifications_3_etcs_b3_r2_gsm-r_b1/index083_-
                _subset-137_v100.pdf>.
                http://www.kmc-subset137.eu/index.php/download/

  Appendix A.  Application Examples

     This informative annex provides some detail about application
     examples.

  A.1.  Rolling Stock

     Rolling stock or railroad cars contain a variety of sensors,
     actuators, and controllers, which communicate within the railroad car
     but also exchange information between railroad cars forming a train,
     with track-side equipment, and/or possibly with backend systems.
     These devices are typically unaware of backend system connectivity.
     Enrolling certificates may be done during maintenance cycles of the
     railroad car, but can already be prepared during operation.  Such
     asynchronous enrollment will include generating certification
     requests, which are collected and later forwarded for processing
     whenever the railroad car gets connectivity with the backend PKI of
     the operator.  The authorization of the certification request is then
     done based on the operator's asset/inventory information in the
     backend.

     UNISIG has included a CMP profile for the enrollment of TLS client
     and server X.509 certificates of on-board and track-side components
     in the Subset-137 specifying the ETRAM/ETCS online key management for
     train control systems [UNISIG-Subset-137].

  A.2.  Building Automation

     In building automation scenarios, a detached building or the basement
     of a building may be equipped with sensors, actuators, and
     controllers that are connected to each other in a local network but
     with only limited or no connectivity to a central building management
     system.  This problem may occur during installation time but also
     during operation.  In such a situation a service technician collects
     the necessary data and transfers it between the local network and the
     central building management system, e.g., using a laptop or a mobile
     phone.  This data may comprise parameters and settings required in
     the operational phase of the sensors/actuators, like a component
     certificate issued by the operator to authenticate against other



  von Oheimb, et al.        Expires 21 March 2025                [Page 29]


  Internet-Draft                  BRSKI-AE                  September 2024


     components and services.

     The collected data may be provided by a domain registrar already
     existing in the local network.  In this case connectivity to the
     backend PKI may be facilitated by the service technician's laptop.
     Alternatively, the data can also be collected from the pledges
     directly and provided to a domain registrar deployed in a different
     network in preparation for the operational phase.  In this case,
     connectivity to the domain registrar may also be facilitated by the
     service technician's laptop.

  A.3.  Substation Automation

     In electrical substation automation scenarios, a control center
     typically hosts PKI services to issue certificates for Intelligent
     Electronic Devices operated in a substation.  Communication between
     the substation and control center is performed through a
     proxy/gateway/DMZ, which terminates protocol flows.  Note that
     [NERC-CIP-005-5] requires inspection of protocols at the boundary of
     a security perimeter (the substation in this case).  In addition,
     security management in substation automation assumes central support
     of several enrollment protocols to support the various capabilities
     of IEDs from different vendors.  The IEC standard IEC62351-9
     [IEC-62351-9] specifies for the infrastructure side mandatory support
     of two enrollment protocols: SCEP [RFC8894] and EST [RFC7030], while
     an Intelligent Electronic Device may support only one of them.

  A.4.  Electric Vehicle Charging Infrastructure

     For electric vehicle charging infrastructure, protocols have been
     defined for the interaction between the electric vehicle and the
     charging point (e.g., ISO 15118-2 [ISO-IEC-15118-2]) as well as
     between the charging point and the charging point operator (e.g.
     OCPP [OCPP]).  Depending on the authentication model, unilateral or
     mutual authentication is required.  In both cases, the charging point
     uses an X.509 certificate to authenticate itself in TLS channels
     between the electric vehicle and the charging point.  The management
     of this certificate depends, among others, on the selected backend
     connectivity protocol.  In the case of OCPP, this protocol is meant
     to be the only communication protocol between the charging point and
     the backend, carrying all information to control the charging
     operations and maintain the charging point itself.  This means that
     the certificate management needs to be handled in-band of OCPP.  This
     requires the ability to encapsulate the certificate management
     messages in a transport-independent way.  Authenticated self-
     containment will support this by allowing the transport without a
     separate enrollment protocol, binding the messages to the identity of
     the communicating endpoints.



  von Oheimb, et al.        Expires 21 March 2025                [Page 30]


  Internet-Draft                  BRSKI-AE                  September 2024


  A.5.  Infrastructure Isolation Policy

     This refers to any case in which network infrastructure is normally
     isolated from the Internet as a matter of policy, most likely for
     security reasons.  In such a case, limited access to external PKI
     services will be allowed in carefully controlled short periods of
     time, for example when a batch of new devices is deployed, and
     forbidden or prevented at other times.

  A.6.  Sites with Insufficient Level of Operational Security

     The RA performing (at least part of) the authorization of a
     certification request is a critical PKI component and therefore
     requires higher operational security than components utilizing the
     issued certificates for their security features.  CAs may also demand
     higher security in the registration procedures from RAs, which domain
     registrars with co-located RAs may not be able to fulfill.
     Especially the CA/Browser forum currently increases the security
     requirements in the certificate issuance procedures for publicly
     trusted certificates, i.e., those placed in trust stores of browsers,
     which may be used to connect with devices in the domain.  In case the
     on-site components of the target domain can not be operated securely
     enough for the needs of an RA, this service should be transferred to
     an off-site backend component that has a sufficient level of
     security.

  Appendix B.  History of Changes TBD RFC Editor: please delete

     List of reviewers:

     *  Toerless Eckert (document shepherd)

     *  Barry Leiba (SECdir)

     *  Mahesh Jethanandani (IETF area director)

     *  Meral Shirazipour (Gen-ART reviewer)

     *  Deb Cooley, Gunter Van de Velde, John Scudder, Murray Kucherawy,
        Roman Danyliw, and Éric Vyncke (IESG reviewers)

     *  Michael Richardson (ANIMA design team)

     *  Rajeev Ranjan, Rufus Buschart, Szofia Fazekas-Zisch, etc.
        (Siemens)






  von Oheimb, et al.        Expires 21 March 2025                [Page 31]


  Internet-Draft                  BRSKI-AE                  September 2024


     *  Reshad Rahman (YANGDOCTORS reviewer).  Note that YANGDOCTORS Early
        review of 2021-08-15 (https://datatracker.ietf.org/doc/review-
        ietf-anima-brski-async-enroll-03-yangdoctors-early-rahman-
        2021-08-15/) referred to the PRM aspect of draft-ietf-anima-brski-
        async-enroll-03 (https://datatracker.ietf.org/doc/draft-ietf-
        anima-brski-async-enroll/03/).  This has been carved out of the
        draft to a different one and thus is no more applicable here.

     IETF draft ae-12 -> ae-13:

     *  Due to IANA requirement, shorten service name "brski-registrar-
        cmp" to "brski-reg-cmp"
        and change contact for service name registration from IESG to IETF

     *  Address Deb Cooley's DISCUSS by adding an item to the requirements
        list Section 5.1 making the source of the initial trust anchor
        explicit.
        Including the vouchers in Figure 2 would not fit because the
        figure has a different scope (namely, certificate enrollment) and
        would get overloaded.

     *  Address Gunter Van de Velde's comments by taking over essentially
        all his rewrites of text to help the structure and simplify
        reading the content, while keeping the original message, as it
        helps improve document quality

     *  Address John Scudder's comments by tweaking Section 2, fully
        alphabetizing terms

     *  Address Murray Kucherawy's comment by adapting terminology
        entries, leaving out 'communication' from 'asynchronous
        communication' and 'synchronous communication'

     *  Address Roman Danyliw's comments by updating reference
        I-D.eckert-anima-brski-discovery to I-D.ietf-anima-brski-discovery
        and adding Section 8, which refers to the BRSKI privacy
        considerations.

     *  Address Éric Vyncke's comment by replacing 'production' by
        'manufacturing'

     IETF draft ae-11 -> ae-12:

     *  Fix minor issues introduced during authors' response to the AD
        review,
        including nits spotted in the Gen-ART review by Meral Shirazipour

     IETF draft ae-10 -> ae-11:



  von Oheimb, et al.        Expires 21 March 2025                [Page 32]


  Internet-Draft                  BRSKI-AE                  September 2024


     *  In response to AD review by Mahesh Jethanandani,

        -  replace most occurrences of 'Note:' by 'Note that' or the like

        -  move 2nd paragraph of abstract to the introduction

        -  remove section 1.2 and merge its first paragraph with the
           preceding section

        -  reconsider normative language, replacing one 'may' by 'MAY' in
           section 4.1

        -  fix several ambiguities and hard-to-read sentences by re-
           phrasing them

        -  make wording more consistent, in particular: 'certification
           request'

        -  fix a number of (mostly grammar) nits

     *  Improve item on limitations of PKCS#10 regarding keys that cannot
        sign

     IETF draft ae-09 -> ae-10:

     *  Add reference to RFC 8633 at first occurrence of 'voucher' (fixes
        #37)

     *  Update reference of CoAP Transfer for CMP from I-D to RFC 9482

     *  Move RFC 4210 and RFC 9480 references from normative to
        informative

     *  Fix p10 vs. pkcs10 entry in list of example endpoints in
        Section 4.3

     *  Minor fix in Figure 1 and few text tweaks due to Siemens-internal
        review

     *  Extend the list of reviewers and acknowledgments by two Siemens
        colleagues

     IETF draft ae-08 -> ae-09:

     *  In response to review by Toerless,

        -  tweak abstract to make meaning of 'alternative enrollment' more
           clear



  von Oheimb, et al.        Expires 21 March 2025                [Page 33]


  Internet-Draft                  BRSKI-AE                  September 2024


        -  expand on first use not "well-known" abbreviations, such as
           'EST',
           adding also a references on their first use

        -  add summary and reason for choosing CMP at end of Section 3.2

        -  remove paragraph on optimistic discovery in controlled
           environments

        -  mention role of reviewers also in acknowledgments section

     *  A couple of grammar and spelling fixes

     IETF draft ae-07 -> ae-08:

     *  Update references to service names in Section 5.1

     IETF draft ae-06 -> ae-07:

     *  Update subsections on discovery according to discussion in the
        design team

     *  In Section 5.1, replace 'mandatory' by 'REQUIRED' regarding
        adherence to LCMPP,
        in response to SECDIR Last Call Review of ae-06 by Barry Leiba

     IETF draft ae-05 -> ae-06:

     *  Extend section on discovery according to discussion in the design
        team

     *  Make explicit that MASA voucher status telemetry is as in BRSKI

     *  Add note that on delegation, RA may need info on pledge
        authorization

     IETF draft ae-04 -> ae-05:

     *  Remove entries from the terminology section that should be clear
        from BRSKI

     *  Tweak use of the terms IDevID and LDevID and replace PKI RA/CA by
        RA/CA

     *  Add the abbreviation 'LCMPP' for Lightweight CMP Profile to the
        terminology section





  von Oheimb, et al.        Expires 21 March 2025                [Page 34]


  Internet-Draft                  BRSKI-AE                  September 2024


     *  State clearly in Section 5.1 that LCMPP is mandatory when using
        CMP

     *  Change URL of BRSKI-AE-overview graphics to slide on IETF 116
        meeting material

     IETF draft ae-03 -> ae-04:

     *  In response to SECDIR Early Review of ae-03 by Barry Leiba,

        -  replace 'end-to-end security' by the more clear 'end-to-end
           authentication'

        -  restrict the meaning of the abbreviation 'AE' to 'Alternative
           Enrollment'

        -  replace 'MAY' by 'may' in requirement on delegated registrar
           actions

        -  re-phrase requirement on certification request exchange,
           avoiding MANDATORY

        -  mention that further protocol names need be put in Well-Known
           URIs registry

        -  explain consequence of using non-standard endpoints, not
           following SHOULD

        -  remove requirement that 'caPubs' field in CMP responses SHOULD
           NOT be used

        -  add paragraph in security considerations on additional use of
           TLS for CMP

     *  In response to further internal reviews and suggestions for
        generalization,

        -  significantly cut down the introduction because the original
           motivations and most explanations are no more needed and would
           just make it lengthy to read

        -  sort out asynchronous vs. offline transfer, off-site vs.
           backend components

        -  improve description of CSRs and proof of possession vs. proof
           of origin





  von Oheimb, et al.        Expires 21 March 2025                [Page 35]


  Internet-Draft                  BRSKI-AE                  September 2024


        -  clarify that the channel between pledge and registrar is not
           restricted to TLS, but in connection with constrained BRSKI may
           also be DTLS.  Also move the references to Constrained BRSKI
           and CoAPS to better contexts.

        -  clarify that the registrar must not be circumvented in the
           decision to grant and LDevID, and give hints and
           recommendations how to make sure this

        -  clarify that the cert enrollment phase may involve additional
           messages and that BRSKI-AE replaces [RFC8995], Section 5.9
           (except Section 5.9.4)

        -  the certificate enrollment protocol needs to support transport
           over (D)TLS only as far as its messages are transported between
           pledge and registrar.

        -  the certificate enrollment protocol chosen between pledge and
           registrar needs to be used also for the upstream enrollment
           exchange with the PKI only if end-to-end authentication shall
           be achieved across the registrar to the PKI.

        -  add that with CMP, further trust anchors SHOULD be transported
           via caPubs

        -  remove the former Appendix A: "Using EST for Certificate
           Enrollment", moving relevant points to the list of scenarios in
           Section 1.1: "Supported Scenarios",

        -  streamline the item on EST in Section 3.2: "Solution Options
           for Proof of Identity",

        -  various minor editorial improvements like making the wording
           more consistent

     IETF draft ae-02 -> ae-03:

     *  In response to review by Toerless Eckert,

        -  many editorial improvements and clarifications as suggested,
           such as the comparison to plain BRSKI, the description of
           offline vs. synchronous message transfer and enrollment, and
           better differentiation of RA flavors.

        -  clarify that for transporting certificate enrollment messages
           between pledge and registrar, the TLS channel established
           between these two (via the join proxy) is used and the
           enrollment protocol MUST support this.



  von Oheimb, et al.        Expires 21 March 2025                [Page 36]


  Internet-Draft                  BRSKI-AE                  September 2024


        -  clarify that the enrollment protocol chosen between pledge and
           registrar MUST also be used for the upstream enrollment
           exchange with the PKI.

        -  extend the description and requirements on how during the
           certificate enrollment phase the registrar MAY handle requests
           by the pledge itself and otherwise MUST forward them to the PKI
           and forward responses to the pledge.

     *  Change "The registrar MAY offer different enrollment protocols" to
        "The registrar MUST support at least one certificate enrollment
        protocol ..."

     *  In response to review by Michael Richardson,

        -  slightly improve the structuring of the Message Exchange
           Section 4.2 and add some detail on the request/response
           exchanges for the enrollment phase

        -  merge the 'Enhancements to the Addressing Scheme' Section 4.3
           with the subsequent one: 'Domain Registrar Support of
           Alternative Enrollment Protocols'

        -  add reference to SZTP (RFC 8572)

        -  extend venue information

        -  convert output of ASCII-art figures to SVG format

        -  various small other text improvements as suggested/provided

     *  Remove the tentative informative application to EST-fullCMC

     *  Move Eliot Lear from co-author to contributor, add Eliot to the
        acknowledgments

     *  Add explanations for terms such as 'target domain' and 'caPubs'

     *  Fix minor editorial issues and update some external references

     IETF draft ae-01 -> ae-02:

     *  Architecture: clarify registrar role including RA/LRA/enrollment
        proxy

     *  CMP: add reference to CoAP Transport for CMPV2 and Constrained
        BRSKI




  von Oheimb, et al.        Expires 21 March 2025                [Page 37]


  Internet-Draft                  BRSKI-AE                  September 2024


     *  Include venue information

     From IETF draft 05 -> IETF draft ae-01:

     *  Renamed the repo and files from 'anima-brski-async-enroll' to
        'anima-brski-ae'

     *  Added graphics for abstract protocol overview as suggested by
        Toerless Eckert

     *  Balanced (sub-)sections and their headers

     *  Added details on CMP instance, now called BRSKI-CMP

     From IETF draft 04 -> IETF draft 05:

     *  David von Oheimb became the editor.

     *  Streamline wording, consolidate terminology, improve grammar, etc.

     *  Shift the emphasis towards supporting alternative enrollment
        protocols.

     *  Update the title accordingly - preliminary change to be approved.

     *  Move comments on EST and detailed application examples to
        informative annex.

     *  Move the remaining text of section 3 as two new sub-sections of
        section 1.

     From IETF draft 03 -> IETF draft 04:

     *  Moved UC2-related parts defining the pledge in responder mode to a
        separate document.  This required changes and adaptations in
        several sections.  Main changes concerned the removal of the
        subsection for UC2 as well as the removal of the YANG model
        related text as it is not applicable in UC1.

     *  Updated references to the Lightweight CMP Profile (LCMPP).

     *  Added David von Oheimb as co-author.

     From IETF draft 02 -> IETF draft 03:

     *  Housekeeping, deleted open issue regarding YANG voucher-request in
        UC2 as voucher-request was enhanced with additional leaf.




  von Oheimb, et al.        Expires 21 March 2025                [Page 38]


  Internet-Draft                  BRSKI-AE                  September 2024


     *  Included open issues in YANG model in UC2 regarding assertion
        value agent-proximity and CSR encapsulation using SZTP sub
        module).

     From IETF draft 01 -> IETF draft 02:

     *  Defined call flow and objects for interactions in UC2.  Object
        format based on draft for JOSE signed voucher artifacts and
        aligned the remaining objects with this approach in UC2 .

     *  Terminology change: issue #2 pledge-agent -> registrar-agent to
        better underline agent relation.

     *  Terminology change: issue #3 PULL/PUSH -> pledge-initiator-mode
        and pledge-responder-mode to better address the pledge operation.

     *  Communication approach between pledge and registrar-agent changed
        by removing TLS-PSK (former section TLS establishment) and
        associated references to other drafts in favor of relying on
        higher layer exchange of signed data objects.  These data objects
        are included also in the pledge-voucher-request and lead to an
        extension of the YANG module for the voucher-request (issue #12).

     *  Details on trust relationship between registrar-agent and
        registrar (issue #4, #5, #9) included in UC2.

     *  Recommendation regarding short-lived certificates for registrar-
        agent authentication towards registrar (issue #7) in the security
        considerations.

     *  Introduction of reference to agent signing certificate using SKID
        in agent signed data (issue #11).

     *  Enhanced objects in exchanges between pledge and registrar-agent
        to allow the registrar to verify agent-proximity to the pledge
        (issue #1) in UC2.

     *  Details on trust relationship between registrar-agent and pledge
        (issue #5) included in UC2.

     *  Split of use case 2 call flow into sub sections in UC2.

     From IETF draft 00 -> IETF draft 01:

     *  Update of scope in Section 1.1 to include in which the pledge acts
        as a server.  This is one main motivation for use case 2.





  von Oheimb, et al.        Expires 21 March 2025                [Page 39]


  Internet-Draft                  BRSKI-AE                  September 2024


     *  Rework of use case 2 to consider the transport between the pledge
        and the pledge-agent.  Addressed is the TLS channel establishment
        between the pledge-agent and the pledge as well as the endpoint
        definition on the pledge.

     *  First description of exchanged object types (needs more work)

     *  Clarification in discovery options for enrollment endpoints at the
        domain registrar based on well-known endpoints in Section 4.3 do
        not result in additional /.well-known URIs.  Update of the
        illustrative example.  Note that the change to /brski for the
        voucher-related endpoints has been taken over in the BRSKI main
        document.

     *  Updated references.

     *  Included Thomas Werner as additional author for the document.

     From individual version 03 -> IETF draft 00:

     *  Inclusion of discovery options of enrollment endpoints at the
        domain registrar based on well-known endpoints in Section 4.3 as
        replacement of section 5.1.3 in the individual draft.  This is
        intended to support both use cases in the document.  An
        illustrative example is provided.

     *  Missing details provided for the description and call flow in
        pledge-agent use case UC2, e.g. to accommodate distribution of CA
        certificates.

     *  Updated CMP example in Section 5 to use Lightweight CMP instead of
        CMP, as the draft already provides the necessary /.well-known
        endpoints.

     *  Requirements discussion moved to separate section in Section 3.
        Shortened description of proof-of-identity binding and mapping to
        existing protocols.

     *  Removal of copied call flows for voucher exchange and registrar
        discovery flow from [RFC8995] in Section 4 to avoid doubling or
        text or inconsistencies.

     *  Reworked abstract and introduction to be more crisp regarding the
        targeted solution.  Several structural changes in the document to
        have a better distinction between requirements, use case
        description, and solution description as separate sections.
        History moved to appendix.




  von Oheimb, et al.        Expires 21 March 2025                [Page 40]


  Internet-Draft                  BRSKI-AE                  September 2024


     From individual version 02 -> 03:

     *  Update of terminology from self-contained to authenticated self-
        contained object to be consistent in the wording and to underline
        the protection of the object with an existing credential.  Note
        that the naming of this object may be discussed.  An alternative
        name may be attestation object.

     *  Simplification of the architecture approach for the initial use
        case having an off-site PKI.

     *  Introduction of a new use case utilizing authenticated self-
        contain objects to onboard a pledge using a commissioning tool
        containing a pledge-agent.  This requires additional changes in
        the BRSKI call flow sequence and led to changes in the
        introduction, the application example,and also in the related
        BRSKI-AE call flow.

     *  Update of provided examples of the addressing approach used in
        BRSKI to allow for support of multiple enrollment protocols in
        Section 4.3.

     From individual version 01 -> 02:

     *  Update of introduction text to clearly relate to the usage of
        IDevID and LDevID.

     *  Definition of the addressing approach used in BRSKI to allow for
        support of multiple enrollment protocols in Section 4.3.  This
        section also contains a first discussion of an optional discovery
        mechanism to address situations in which the registrar supports
        more than one enrollment approach.  Discovery should avoid that
        the pledge performs a trial and error of enrollment protocols.

     *  Update of description of architecture elements and changes to
        BRSKI in Section 4.1.

     *  Enhanced consideration of existing enrollment protocols in the
        context of mapping the requirements to existing solutions in
        Section 3 and in Section 5.

     From individual version 00 -> 01:

     *  Update of examples, specifically for building automation as well
        as two new application use cases in Appendix A.






  von Oheimb, et al.        Expires 21 March 2025                [Page 41]


  Internet-Draft                  BRSKI-AE                  September 2024


     *  Deletion of asynchronous interaction with MASA to not complicate
        the use case.  Note that the voucher exchange can already be
        handled in an asynchronous manner and is therefore not considered
        further.  This resulted in removal of the alternative path the
        MASA in Figure 1 and the associated description in Section 4.1.

     *  Enhancement of description of architecture elements and changes to
        BRSKI in Section 4.1.

     *  Consideration of existing enrollment protocols in the context of
        mapping the requirements to existing solutions in Section 3.

     *  New section starting Section 5 with the mapping to existing
        enrollment protocols by collecting boundary conditions.

  Contributors

     Eliot Lear
     Cisco Systems
     Richtistrasse 7
     CH-8304 Wallisellen
     Switzerland
     Phone: +41 44 878 9200
     Email: lear@cisco.com


  Authors' Addresses

     David von Oheimb (editor)
     Siemens AG
     Otto-Hahn-Ring 6
     81739 Munich
     Germany
     Email: david.von.oheimb@siemens.com
     URI:   https://www.siemens.com/


     Steffen Fries
     Siemens AG
     Otto-Hahn-Ring 6
     81739 Munich
     Germany
     Email: steffen.fries@siemens.com
     URI:   https://www.siemens.com/







  von Oheimb, et al.        Expires 21 March 2025                [Page 42]


  Internet-Draft                  BRSKI-AE                  September 2024


     Hendrik Brockhaus
     Siemens AG
     Otto-Hahn-Ring 6
     81739 Munich
     Germany
     Email: hendrik.brockhaus@siemens.com
     URI:   https://www.siemens.com/












































  von Oheimb, et al.        Expires 21 March 2025                [Page 43]


name: draft-nourse-scep
rev: 23
title: Simple Certificate Enrollment Protocol
time: 2025-05-01T21:42:54Z
group_uri: /api/v1/group/group/1260/
expires: 2012-03-11T01:13:22Z
ad: /api/v1/person/person/104851/
shepherd: /api/v1/person/email/carl@redhoundsoftware.com/
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:13.081949+00:00
source: ietf
abstract:
  This document specifies the Simple Certificate Enrollment Protocol
     (SCEP), a Public Key Infrastructure (PKI) communication protocol
     which leverages existing technology by using PKCS#7 and PKCS#10 over
     HTTP.  SCEP is the evolution of the enrollment protocol developed by
     VeriSign, Inc. for Cisco Systems, Inc. It now enjoys wide support in
     both client and a Certification Authority implementations.

full_text:
  Internet Engineering Task Force                         M. Pritikin, Ed.
  Internet-Draft                                                 A. Nourse
  Intended status: Historic                                    J. Vilhuber
  Expires: March 10, 2012                               Cisco Systems, Inc
                                                         September 7, 2011


                   Simple Certificate Enrollment Protocol
                            draft-nourse-scep-23

  Abstract

     This document specifies the Simple Certificate Enrollment Protocol
     (SCEP), a Public Key Infrastructure (PKI) communication protocol
     which leverages existing technology by using PKCS#7 and PKCS#10 over
     HTTP.  SCEP is the evolution of the enrollment protocol developed by
     VeriSign, Inc. for Cisco Systems, Inc. It now enjoys wide support in
     both client and a Certification Authority implementations.

  Status of this Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at http://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on March 10, 2012.

  Copyright Notice

     Copyright (c) 2011 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents
     (http://trustee.ietf.org/license-info) in effect on the date of
     publication of this document.  Please review these documents
     carefully, as they describe your rights and restrictions with respect
     to this document.  Code Components extracted from this document must
     include Simplified BSD License text as described in Section 4.e of



  Pritikin, et al.         Expires March 10, 2012                 [Page 1]


  Internet-Draft                    SCEP                    September 2011


     the Trust Legal Provisions and are provided without warranty as
     described in the Simplified BSD License.

     This document may contain material from IETF Documents or IETF
     Contributions published or made publicly available before November
     10, 2008.  The person(s) controlling the copyright in some of this
     material may not have granted the IETF Trust the right to allow
     modifications of such material outside the IETF Standards Process.
     Without obtaining an adequate license from the person(s) controlling
     the copyright in such materials, this document may not be modified
     outside the IETF Standards Process, and derivative works of it may
     not be created outside the IETF Standards Process, except to format
     it for publication as an RFC or to translate it into languages other
     than English.


  Table of Contents

     1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
       1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  6
     2.  SCEP Overview  . . . . . . . . . . . . . . . . . . . . . . . .  6
       2.1.  SCEP Entities  . . . . . . . . . . . . . . . . . . . . . .  6
         2.1.1.  Requester  . . . . . . . . . . . . . . . . . . . . . .  6
         2.1.2.  Certification Authority  . . . . . . . . . . . . . . .  7
         2.1.3.  Registration Authority . . . . . . . . . . . . . . . .  8
       2.2.  Requester authentication . . . . . . . . . . . . . . . . .  8
       2.3.  Enrollment authorization . . . . . . . . . . . . . . . . .  9
       2.4.  CA/RA Certificate Distribution . . . . . . . . . . . . . . 11
       2.5.  Certificate Enrollment . . . . . . . . . . . . . . . . . . 11
         2.5.1.  Client State Transitions . . . . . . . . . . . . . . . 12
       2.6.  Certificate Access . . . . . . . . . . . . . . . . . . . . 14
       2.7.  CRL Access . . . . . . . . . . . . . . . . . . . . . . . . 14
       2.8.  Certificate Revocation . . . . . . . . . . . . . . . . . . 15
     3.  SCEP Secure Message Objects  . . . . . . . . . . . . . . . . . 16
       3.1.  SCEP pkiMessage  . . . . . . . . . . . . . . . . . . . . . 17
         3.1.1.  Signed Transaction Attributes  . . . . . . . . . . . . 18
           3.1.1.1.  transactionID  . . . . . . . . . . . . . . . . . . 18
           3.1.1.2.  messageType  . . . . . . . . . . . . . . . . . . . 19
           3.1.1.3.  pkiStatus  . . . . . . . . . . . . . . . . . . . . 19
           3.1.1.4.  failInfo . . . . . . . . . . . . . . . . . . . . . 19
           3.1.1.5.  senderNonce and recipientNonce . . . . . . . . . . 20
           3.1.1.6.  signingTime Attribute  . . . . . . . . . . . . . . 20
         3.1.2.  SCEP pkcsPKIEnvelope . . . . . . . . . . . . . . . . . 20
       3.2.  SCEP pkiMessage types  . . . . . . . . . . . . . . . . . . 21
         3.2.1.  PKCSReq  . . . . . . . . . . . . . . . . . . . . . . . 21
         3.2.2.  CertRep  . . . . . . . . . . . . . . . . . . . . . . . 21
           3.2.2.1.  CertRep SUCCESS  . . . . . . . . . . . . . . . . . 22
           3.2.2.2.  CertRep FAILURE  . . . . . . . . . . . . . . . . . 23



  Pritikin, et al.         Expires March 10, 2012                 [Page 2]


  Internet-Draft                    SCEP                    September 2011


           3.2.2.3.  CertRep PENDING  . . . . . . . . . . . . . . . . . 23
         3.2.3.  GetCertInitial . . . . . . . . . . . . . . . . . . . . 23
           3.2.3.1.  IssuerAndSubject . . . . . . . . . . . . . . . . . 23
         3.2.4.  GetCert  . . . . . . . . . . . . . . . . . . . . . . . 24
         3.2.5.  GetCRL . . . . . . . . . . . . . . . . . . . . . . . . 24
       3.3.  Degenerate certificates-only PKCS#7 Signed-data  . . . . . 25
     4.  SCEP Transactions  . . . . . . . . . . . . . . . . . . . . . . 25
       4.1.  Get CA Certificate . . . . . . . . . . . . . . . . . . . . 25
         4.1.1.  Get CA Certificate Response Message Format . . . . . . 25
           4.1.1.1.  CA Certificate Response Message Format . . . . . . 26
           4.1.1.2.  CA/RA Certificate Response Message Format  . . . . 26
       4.2.  Certificate Enrollment . . . . . . . . . . . . . . . . . . 26
         4.2.1.  Certificate Enrollment Response Message  . . . . . . . 26
       4.3.  Poll for Requester Initial Certificate . . . . . . . . . . 26
         4.3.1.  Polling Response Message Format  . . . . . . . . . . . 27
       4.4.  Certificate Access . . . . . . . . . . . . . . . . . . . . 27
         4.4.1.  Certificate Access Response Message Format . . . . . . 28
       4.5.  CRL Access . . . . . . . . . . . . . . . . . . . . . . . . 28
         4.5.1.  CRL Access Response Message Format . . . . . . . . . . 28
       4.6.  Get Next Certification Authority Certificate . . . . . . . 28
         4.6.1.  Get Next CA Response Message Format  . . . . . . . . . 28
     5.  SCEP Transport . . . . . . . . . . . . . . . . . . . . . . . . 29
       5.1.  HTTP "GET" Message Format  . . . . . . . . . . . . . . . . 29
         5.1.1.  Response Message Format  . . . . . . . . . . . . . . . 29
       5.2.  SCEP HTTP Messages . . . . . . . . . . . . . . . . . . . . 29
         5.2.1.  GetCACert  . . . . . . . . . . . . . . . . . . . . . . 30
           5.2.1.1.  GetCACert Response . . . . . . . . . . . . . . . . 30
         5.2.2.  PKCSReq  . . . . . . . . . . . . . . . . . . . . . . . 30
           5.2.2.1.  PKCSReq Response . . . . . . . . . . . . . . . . . 31
         5.2.3.  GetCertInitial . . . . . . . . . . . . . . . . . . . . 31
           5.2.3.1.  GetCertInitial Response  . . . . . . . . . . . . . 31
         5.2.4.  GetCert  . . . . . . . . . . . . . . . . . . . . . . . 31
           5.2.4.1.  GetCert Response . . . . . . . . . . . . . . . . . 31
         5.2.5.  GetCRL . . . . . . . . . . . . . . . . . . . . . . . . 31
           5.2.5.1.  GetCRL Response  . . . . . . . . . . . . . . . . . 32
         5.2.6.  GetNextCACert  . . . . . . . . . . . . . . . . . . . . 32
           5.2.6.1.  GetNextCACert Response . . . . . . . . . . . . . . 32
     6.  Contributors/Acknowledgements  . . . . . . . . . . . . . . . . 32
     7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 32
     8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 32
       8.1.  General Security . . . . . . . . . . . . . . . . . . . . . 33
       8.2.  Use of the CA keypair  . . . . . . . . . . . . . . . . . . 34
       8.3.  ChallengePassword  . . . . . . . . . . . . . . . . . . . . 34
       8.4.  transactionID  . . . . . . . . . . . . . . . . . . . . . . 35
       8.5.  Nonces and Replay  . . . . . . . . . . . . . . . . . . . . 35
       8.6.  Key Usage Issues . . . . . . . . . . . . . . . . . . . . . 35
       8.7.  GetCACaps Issues . . . . . . . . . . . . . . . . . . . . . 35
       8.8.  Unnecessary cryptography . . . . . . . . . . . . . . . . . 35



  Pritikin, et al.         Expires March 10, 2012                 [Page 3]


  Internet-Draft                    SCEP                    September 2011


       8.9.  GetNextCACert  . . . . . . . . . . . . . . . . . . . . . . 36
     9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
       9.1.  Normative References . . . . . . . . . . . . . . . . . . . 36
       9.2.  Informative References . . . . . . . . . . . . . . . . . . 37
     Appendix A.  Private OID Definitions . . . . . . . . . . . . . . . 37
     Appendix B.  SCEP State Transitions  . . . . . . . . . . . . . . . 38
     Appendix C.  CA Capabilities . . . . . . . . . . . . . . . . . . . 40
       C.1.  GetCACaps HTTP Message Format  . . . . . . . . . . . . . . 40
       C.2.  CA Capabilities Response Format  . . . . . . . . . . . . . 40
     Appendix D.  Client Certificate Renewal  . . . . . . . . . . . . . 41
     Appendix E.  CA Key Rollover . . . . . . . . . . . . . . . . . . . 42
     Appendix F.  PKIOperation via HTTP POST Message  . . . . . . . . . 43
     Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43






































  Pritikin, et al.         Expires March 10, 2012                 [Page 4]


  Internet-Draft                    SCEP                    September 2011


  1.  Introduction

     Public key technology is widely available and increasingly widely
     deployed.  X.509 certificates serve as the basis for several
     standards-based security protocols in the IETF, such as The Internet
     Key Exchange (IKE) [RFC2409] and IKEv2 [RFC4306], and The Transport
     Layer Security Protocol (TLS) [RFC4346].  When an X.509 certificate
     is issued by other than the certificate subject (a self-issued
     certificate), there typically is a need for a certificate management
     protocol.  Such a protocol enables a PKI client to request a
     certificate, certificate renewal, or certificate revocation from a
     Certification Authority (CA).  Often there also is a need for
     protocols to request certificate revocation status information,
     although these functions are often provided by distinct mechanisms,
     e.g.  Certificaet Revocation Lists (CRLs) [RFC4523] or Online
     Certificate Status Protocol (OCSP) [RFC2560].

     This specification defines a protocol, Simple Certificate Enrollment
     Protocol (SCEP), for certificate management and certificate and CRL
     queries in a closed environment.  While widely deployed, this
     protocol omits some certificate management features, e.g. in-band
     certificate revocation transactions, which can significantly enhance
     the security achieved in a PKI.  The IETF protocol suite currently
     includes two certificate management protocols with more comprehensive
     functionality: Certificate Management Protocol (CMP) [RFC4210] and
     Certificate Management over CMS (CMC) [RFC5272].  Environments that
     do not require interoperability with SCEP implementations SHOULD use
     the above-mentioned, PKIX-standard certificate management protocols.
     In light of the functionality gap between this specification and the
     two IETF standards track protocols, this specification is being
     published as Historic.  Even when interoperability with the installed
     base of SCEP implementations is needed, implementers are encouraged
     to support one of these comprehensive standards track certificate
     management protocols in addition to the protocol defined in this
     specification.  This implementation strategy balances near-term
     requirements for interoperability with longer term security goals.

     As a reflection of the history of SCEP implementations some of the
     operations described in this document are indicated as 'SHOULD' or
     'MAY' where a stricter protocol specification might have indicated a
     'MUST'.

     The protocol supports the following general operations:

     o  CA and Registration Authority (RA) public key distribution

     o  Certificate enrollment




  Pritikin, et al.         Expires March 10, 2012                 [Page 5]


  Internet-Draft                    SCEP                    September 2011


     o  Certificate query

     o  CRLquery

     SCEP makes extensive use of PKCS#7 [RFC2315] and PKCS#10 [RFC2986].

  1.1.  Requirements Language

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in [RFC2119].


  2.  SCEP Overview

     This section provides a high level overview of the functionality of
     SCEP.

  2.1.  SCEP Entities

     The entity types defined in SCEP are

     o  the Requester (Section 2.1.1) (e.g., IPSEC clients)

     o  the Server, which may be either a Certification Authority (CA)
        (Section 2.1.2) or a Registration Authority (RA) (Section 2.1.3)

  2.1.1.  Requester

     The requester is sometimes called a "client" in this document.  It is
     the client of the SCEP exchange.

     The requester MAY submit SCEP messages for itself or it MAY submit
     SCEP messages on behalf of peers as described in Registration
     Authority (Section 2.1.3).  This section focuses on the requester
     that is obtaining certificates for its own use.

     Before a requester can start a PKI transaction, it MUST have at least
     one appropriate key pair (e.g.  RSA) for use when signing the SCEP
     pkiMessage (Section 3.1).

     The message types, being based on PKCS#7 [RFC2315] and PKCS#10
     [RFC2986], fully support algorithm agility but the requester has to
     use a key type that is supported by the server.  RSA is the only
     algorithm supported by current implementations.

     A requester MUST have the following information locally configured:




  Pritikin, et al.         Expires March 10, 2012                 [Page 6]


  Internet-Draft                    SCEP                    September 2011


     1.  The Certification Authority IP address or fully qualified domain
         name

     2.  The Certification Authority HTTP CGI script path

     3.  The identifying information that is used for authentication of
         the Certification Authority in Section 4.1.1.  This information
         MAY be obtained from the user, or presented to the end user for
         manual authorization during the protocol exchange (e.g. the user
         indicates acceptance of a fingerprint via a user-interface
         element).

     The requester MUST have MESSAGE information configured if the
     Certification Authority requires it (see Section 5.1).

     The requester MAY maintain multiple independent configurations
     appropriate for multiple Certification Authorities.  Doing so does
     not effect the protocol operation and is not in scope of this
     document.

     Certificate requests for certificates whose purpose is a specific
     solution are encouraged to conform to the solution's profile, e.g.
     [RFC4945] Section 5 for IKE/IPsec certificates.

  2.1.2.  Certification Authority

     An SCEP Certification Authority (CA) is the entity that signs client
     certificates.  The CAs name appears in the issuer field of resulting
     certificates.

     Before any PKI operations can occur, the SCEP CA server obtains a
     'CA' certificate that is compliant with the profile in [RFC5280].
     This MAY be a CA certificate that was issued by a higher level CA.

     The SCEP server CA certificate MUST be provided out-of-band to the
     SCEP requester.  The CA certificate fingerprint MAY be used to
     authenticate a CA Certificate distributed by the GetCACert response
     (Section 4.1.1).  The fingerprint is created by calculating a SHA-1,
     SHA-256, SHA-512, or MD5 hash on the whole CA certificate.

     The certification authority MUST either include a
     cRLDistributionPoint extension in every certificate it issues or
     answer CRL queries itself, in which case it SHOULD be online at all
     times.  The certification authority SHOULD either answer certificate
     queries or make certificates available via LDAP.

     A certification authority may enforce any arbitrary policies,
     including name uniqueness policies, and apply them to certification



  Pritikin, et al.         Expires March 10, 2012                 [Page 7]


  Internet-Draft                    SCEP                    September 2011


     requests.  The certification authority MAY reject any request.  If
     the client has already been issued a certificate for this keypair the
     server MAY return the previously created certificate.  The requester
     MUST NOT assume any of the fields in the certification request,
     except for the public key, will be the same in the certificate
     issued.

     If a client times out from polling for a pending request it can
     resynchronize by reissuing the original request with the original
     subject name, key, and transaction ID.  The CA SHOULD return the
     status of the original transaction, including the certificate if it
     was granted.  The CA SHOULD NOT create a new transaction unless the
     original certificate has been revoked, or the transaction arrives
     more than halfway through the validity period of the original
     certificate.

  2.1.3.  Registration Authority

     An SCEP Registration Authority (RA) is an SCEP server that performs
     validation and authorization checks of the SCEP requester but
     forwards the certification requests to the CA.  The RAs name does not
     appear in the issuer field of resulting certificates.

     The RA MUST return the RA certificate, in addition to the CA
     certificate, in the GetCACert Response (see Section 5.2.1.1.2).  The
     existence of an RA certificate in this response indicates to the
     client that an RA is in use.  In order to securely communicate with
     an RA using SCEP Secure Message Objects (Section 3) the client
     specifies the RA as the recipient of subsequent SCEP pkiMessages (see
     Section 3.1.2).

     In order to service certification requests the RA must pass the
     requests to the CA server for signing.  The RA MAY use SCEP to
     communicate with the CA, in which case the RA acts as both an SCEP
     server (between the client and the RA) and an SCEP requester (between
     the RA and the CA).  The RA MAY respond to client certificate
     requests with a PENDING response while communicating with the CA; for
     example if the CA must manually authorize a certification request and
     thus returns PENDING to the RA the RA may respond with PENDING to the
     client while polling the CA.

     Communication between the RA and the CA MAY be over other protocols
     such as Certificate Management over CMS [RFC5272].

  2.2.  Requester authentication

     As with every protocol that uses public-key cryptography, the
     association between the public keys used in the protocol and the



  Pritikin, et al.         Expires March 10, 2012                 [Page 8]


  Internet-Draft                    SCEP                    September 2011


     identities with which they are associated must be authenticated in a
     cryptographically secure manner.  This requirement is needed to
     prevent a "man-in-the-middle" attack, in which an adversary can
     manipulate the data as it travels between the protocol participants
     and subvert the security of the protocol.

     The communication between the requester and the certification
     authority are secured using SCEP Secure Message Objects (Section 3)
     which specifies how PKCS#7 [RFC2315] is used to encrypt and sign the
     data.  In order to perform the signing operation the client uses an
     appropriate local certificate:

     1.  If the requesting system already has a certificate issued by the
         SCEP server, and the server supports renewal (see Appendix C),
         that certificate SHOULD be used.

     2.  If the requesting system has no certificate issued by the new CA,
         but has credentials from an alternate CA the certificate issued
         by the alternate CA MAY be used.  Policy settings on the new CA
         will determine if the request can be accepted or not.  This is
         useful when enrolling with a new administrative domain; by using
         a certificate from the old domain as credentials.

     3.  If the requester does not have an appropriate existing
         certificate, then a locally generated self-signed certificate
         MUST be used instead.  The self-signed certificate MUST use the
         same subject name as in the PKCS#10 request.

     During the certificate enrollment, the requester MUST use the
     selected certificate's keypair when signing the PKCS#7 [RFC2315] (see
     Section 3).  The server CertResp uses this signing certificate's
     public key when encrypting the response (see Section 3.2.2).

     When the certification authority creates the PKCS#7 [RFC2315]
     envelope on the issued certificate, it SHOULD use the public key,
     issuer name, and serial number conveyed in the above included
     certificate.  This will inform the end entity of which private key is
     needed to open the envelope.  Note that when a client enrolls for
     separate encryption and signature certificates, it MAY use the
     signature certificate to sign both requests, and then expect its
     signature key to be used to encrypt both responses.  In any case, the
     RecipientInfo on the envelope MUST reflect the key used to encrypt
     the request.

  2.3.  Enrollment authorization

     There are two mechanisms for automated enrollment authorization.




  Pritikin, et al.         Expires March 10, 2012                 [Page 9]


  Internet-Draft                    SCEP                    September 2011


     When the client uses a keypair that is associated with a certificate
     which is not self-signed to sign SCEP messages the server MAY use
     this certificate to authenticate the client and determine the
     appropriate authorization.  The SCEP server SHOULD implement
     appropriate logic to support client authentication and automated
     enrollment using existing client credentials that were issued by an
     alternate PKI hierarchy, in addition to the policy requirements
     implied by optional support of renewal (see Appendix D).  The SCEP
     server MUST NOT attempt to authenticate a client based on a self-
     signed certificate.

     PKCS#10 [RFC2986] specifies a PKCS#9 [RFC2985] challengePassword
     attribute to be sent as part of the enrollment request.  Inclusion of
     the challengePassword by the SCEP client is OPTIONAL and allows for
     unauthenticated authorization of enrollment requests.  The PKCS#7
     [RFC2315] envelope protects the privacy of the challenge password.

     When utilizing the challengePassword, the server distributes a shared
     secret to the requester which will uniquely associate the enrollment
     request with the requester.  The distribution of the secret must be
     private: only the end entity should know this secret.  The actual
     binding mechanism between the requester and the secret is subject to
     the server policy and implementation.

     A client that is performing certificate renewal as per Appendix D
     SHOULD send an empty challenge password (i.e. use the empty string as
     the challenge password) but MAY send the originally distributed
     challenge password in the challengePassword attribute.  In the former
     case the SCEP CA MUST authenticate the request based on the
     certificate used to sign the renewal request.  In the latter case the
     SCEP CA MAY use either the challengePassword or the previously issued
     certificate (or both) to authenticate the request.

     In the manual mode the requester's messages are placed in the PENDING
     state until the CA operator authorizes or rejects them.  Manual
     authorization is used when the client has only a self-signed
     certificate and/or a challengePassword is not available.  The SCEP
     server MAY either reject unauthorized certification requests or mark
     them for manual authorization according to server configuration.

     The requester generates a SHA-1, SHA-256, SHA-512, or MD5
     'fingerprint' of the PKCS#10 [RFC2986] (before PKCS#7 [RFC2315]
     enveloping and signing).  This fingerprint is sent to the CA operator
     using an out-of-band method.  The CA operator MUST compared this
     fingerprint to a locally generated fingerprint based on the message
     received during the SCEP exchange.

     SCEP clients and CAs (or RAs, if appropriate) MUST support display of



  Pritikin, et al.         Expires March 10, 2012                [Page 10]


  Internet-Draft                    SCEP                    September 2011


     this fingerprint to the operator to enable this authorization method.
     The out-of-band distribution and comparison of fingerprints is not
     covered by this document.

  2.4.  CA/RA Certificate Distribution

     If the CA and/or RA certificates have not previously been acquired by
     the requester in some other means, the requester MUST retrieve the
     CA/RA certificates before any PKI operation (Section 3) can be
     started.

     Since no public key has yet been exchanged between the requester and
     the CA/RA, the messages cannot be secured using PKCS#7 [RFC2315], and
     the data is instead transferred in the clear.

     If an RA is in use, a certificates-only PKCS#7 [RFC2315] SignedData
     with a certificate chain consisting of both RA and CA certificates is
     returned.  Otherwise the CA certificate itself is returned.  The
     transport protocol (Section 5) MUST indicate which one is returned.

     After the requester gets the CA certificate, it MUST authenticate the
     CA certificate by comparing the CA certificate fingerprint (see
     Section 2.1.2) with the locally configured, out-of-band distributed,
     identifying information.  RA certificates, if any, are signed by the
     CA so there is no need to authenticate them against the out-of-band
     data.  Clients MUST verify the RA certificate signatures before use
     during protocol exchanges.

     Clients MUST verify the authorization of the RA certificates.  The
     authorization mechanism is specified by the CA administrator and is
     out of scope for this document.

     Because a long time can pass between queries from a requester to a
     CA/RA and because RA certificates can change at any time, it is
     recommended that a requester not store RA certificates.  Instead, the
     requester SHOULD retrieve the CA/RA certificates before each
     operation.

  2.5.  Certificate Enrollment

     A requester starts an enrollment (Section 3.2.1) transaction by
     creating a certificate request using PKCS#10 [RFC2986] and sends it
     to the CA/RA enveloped using the PKCS#7 (Section 3).

     It is up to local CA policy (and CA implementation) as to whether a
     certificate is granted automatically, or whether it is manually
     granted by the administrator.  The challengePassword MAY be used to
     automatically authorize the request.



  Pritikin, et al.         Expires March 10, 2012                [Page 11]


  Internet-Draft                    SCEP                    September 2011


     If the CA/RA returns a CertRep (Section 3.2.2) message with status
     set to PENDING, the requester enters into polling mode by
     periodically sending a GetCertInitial (Section 3.2.3) PKI message to
     the CA/RA, until the CA/RA operator completes the manual
     authentication (approving or denying the request).

     In general, the requester will send a single PKCSReq (Section 3.2.1)
     message, followed by 0 or more GetCertInitial (Section 3.2.3)
     messages, if polling mode is entered.

     In general, the CA/RA will send 0 or more CertRep (Section 3.2.2)
     messages with status set to PENDING, followed by a single CertRep
     (Section 3.2.2) with status set to either SUCCESS or FAILURE.

  2.5.1.  Client State Transitions

     The requester state transitions during enrollment operation are
     indicated in Figure 1.


                           GetCertInitial
                             +----<---+
                             |        | CertRep(PENDING),
                             |        | GetCertInitial send-timeout,
                             |        | new-poll timer
                             |        |
     [CERT-NONEXISTANT] -----+---> [CERT-REQ-PENDING]      [CERT-ISSUED]
           ^             PKCSReq      |          |               ^
           |                          |          |               |
           |                          |          +---------------+
           |                          |           CertRep(SUCCESS)
           +--------------------------+
           CertRep(FAILURE),
           PKCSReq send-timeout,
           max-time/max-polls exceeded

                      Figure 1: State Transition Diagram

     Certificate enrollment starts at the state CERT-NONEXISTANT.

     Sending a PKCSReq message changes the state to CERT-REQ-PENDING.  If
     there is no response, or sending is not possible, the state reverts
     back to CERT-NONEXISTANT.

     Receiving a CertRep message with pkiStatus set to SUCCESS changes the
     state to CERT-ISSUED.

     Receiving a CertRep message with pkiStatus set to FAILURE changes the



  Pritikin, et al.         Expires March 10, 2012                [Page 12]


  Internet-Draft                    SCEP                    September 2011


     state to CERT-NONEXISTANT.

     If the server sends back a CertRep message with pkiStatus set to
     PENDING, the requester will keep polling by sending a GetCertInitial
     message to the server, until either a CertRep message with status set
     to SUCCESS or FAILURE is received, or the maximum number of polls has
     been exceeded.

     If the maximum number of polls has been exceeded or a CertRep message
     with pkiStatus set to FAILURE is received while in the CERT-REQ-
     PENDING state, the end entity will transition to the CERT-NONEXISTANT
     state, and the SCEP client can eventually initiate another enrollment
     request.  It is important to note that, as long as the requester does
     not change its subject name or keys, the same transaction ID will be
     used in the "new" transaction.  This is important because based on
     this transaction ID, the certification authority can recognize this
     as an existing transaction instead of a new one.


     A successful transaction in automatic mode:
              REQUESTER                           CA SERVER

          PKCSReq: PKI cert. enrollment msg
          --------------------------------> CertRep: pkiStatus = SUCCESS
                                            certificate attached
                                           <------------------------------
          Receive issued certificate.

                     Figure 2: Automatic mode transaction






















  Pritikin, et al.         Expires March 10, 2012                [Page 13]


  Internet-Draft                    SCEP                    September 2011


     A successful transaction in manual mode:
             REQUESTER                           CA SERVER
         PKCSReq: PKI cert. enrollment msg
         --------------------------------> CertRep: pkiStatus = PENDING
                                           <------------------------------
         GetCertInitial: polling msg
         --------------------------------> CertRep: pkiStatus = PENDING
                                           <------------------------------
         ................ <manual identity authentication>...............

         GetCertInitial: polling msg
         --------------------------------> CertRep: pkiStatus = SUCCESS
                                           certificate attached
                                           <------------------------------
         Receive issued certificate.

                       Figure 3: Manual mode transaction

  2.6.  Certificate Access

     A certificate query message is defined for clients to retrieve a copy
     of their own certificates from the CA.  It allows clients that do not
     store their certificate locally to obtain a copy when needed.  This
     functionality is not intended to provide a general purpose
     certificate directory service.

     To query a certificate from the certification authority, a requester
     sends a request consisting of the certificate's issuer name and
     serial number.  This assumes that the requester has saved the issuer
     name and the serial number of the issued certificate from the
     previous enrollment transaction.  The transaction to query a
     certificate consists of one GetCert (Section 3.2.4) message and one
     CertRep (Section 3.2.2) message, as shown in Figure 4.

             REQUESTER                           CA SERVER
          GetCert: PKI certificate query msg
          -------------------------------> CertRep:  pkiStatus = SUCCESS
                                           certificate attached
                                           <-----------------------------
          Receive the certificate.

                         Figure 4: GetCert Transaction

  2.7.  CRL Access

     SCEP clients request a CRL via one of two methods:





  Pritikin, et al.         Expires March 10, 2012                [Page 14]


  Internet-Draft                    SCEP                    September 2011


     1.  If the CA supports CRL Distribution Points (CDPs) [RFC5280]
         (Section 4.2.1.13), then the CRL MUST be retrieved via the
         mechanism specified in the CDP.

     2.  If the CA does not support CDP's, a CRL query is composed by
         creating a GetCRL message consisting of the issuer name and
         serial number from a certificate within the scope of the CRL to
         be retrieved (e.g. from a certificate to be validated).

     The server SHOULD NOT support the GetCRL method because:

     o  it does not scale well due to the unnecessary cryptography (see,
        Section 8.8)

     o  it requires the CA to be a high-availability service

     o  only limited information to determine the CRL scope is provided
        (see [RFC5280] Section 5).

     The message is sent to the SCEP server in the same way as the other
     SCEP requests: The transaction to retrieve a CRL consists of one
     GetCRL PKI message and one CertRep PKI message, which contains only
     the CRL (no certificates), as shown in Figure 5.

     On receipt of this message, the SCEP server MAY use the
     IssuerAndSerial information to return an appropriate CRL.


              REQUESTER                           CA SERVER
          GetCRL: PKI CRL query msg
       ---------------------------------->
                                         CertRep:  CRL attached
                                      <--------------------------------

                         Figure 5: GetCRL Transaction

  2.8.  Certificate Revocation

     SCEP does not specify a method to request certificate revocation.

     In order to revoke a certificate, the requester must contact the CA
     server operator using a non-SCEP defined mechanism.  Although the
     PKCS#10 [RFC2986] challengePassword is used by SCEP for enrollment
     authorization (see Enrollment authorization (Section 2.3)) this does
     not inhibit the CA server from maintaining a record of the
     challengePassword to use during subsequent revocation operations as
     implied by [RFC2985].




  Pritikin, et al.         Expires March 10, 2012                [Page 15]


  Internet-Draft                    SCEP                    September 2011


  3.  SCEP Secure Message Objects

     PKCS#7 [RFC2315] is a general enveloping mechanism that enables both
     signed and encrypted transmission of arbitrary data.

     All messages MUST be valid PKCS#7 [RFC2315] structures, unless
     otherwise noted.

     SCEP messages that require confidentiality use two layers of PKCS#7,
     as shown in Figure 6.  By applying both enveloping and signing
     transformations, the SCEP message is protected both for the integrity
     of its end-to-end transaction information and the confidentiality of
     its information portion.  The advantage of this technique over the
     conventional transaction message format is that the signed
     transaction type information and the status of the transaction can be
     determined prior to invoking security handling procedures specific to
     the information portion being processed.

     Some messages do not require enveloping, in which case the
     EnvelopedData in Figure 6 is omitted.


     ContentType = SignedData (called pkiMessage)
       SignerInfo
          Signature
          authenticatedAttributes
             transactionID
             messageType
             pkiStatus
             failInfo
             senderNonce
             recipientNonce
             etc
       ContentInfo type = EnvelopedData (called pkcsPKIEnvelope; optional)
          RecipientInfo
          ContentInfo type = Data
             messageData

                           Figure 6: PKCS#7 Layering

     Description:

     o  The outer PKCS#7 is a pkiMessage (Section 3.1).

     o  The SignedData ContentInfo, if present (e.g.  FAILURE and PENDING
        CertRep messages will lack any signed content), MUST be a
        pkcsPKIEnvelope (Section 3.1.2).




  Pritikin, et al.         Expires March 10, 2012                [Page 16]


  Internet-Draft                    SCEP                    September 2011


     When a particular SCEP message carries data, this data is carried in
     the messageData.

     Note: The remainder of this document will refer only to
     'messageData', but it is understood to always be encapsulated in the
     pkcsPKIEnvelope (Section 3.1.2).  The format of the data in the
     messageData is defined by the messageType attribute (see
     Section 3.1.1) of the SignedData.  If there is no messageData to be
     transmitted, the entire pkcsPKIEnvelope MUST be omitted.

  3.1.  SCEP pkiMessage

     The basic building block of all secured SCEP messages is the SCEP
     pkiMessage.  It consists of an PKCS#7 signed-data content type, as
     defined in PKCS#7 [RFC2315] Section 9.  The following restrictions
     apply:

     o  version MUST be 1

     o  the contentType in contentInfo MUST be data ({pkcs-7 1}) as
        defined in PKCS#7 [RFC2315] Section 8.

     o  The signed content, if present (e.g.  FAILURE and PENDING CertRep
        messages will lack any signed content), MUST be a pkcsPKIEnvelope
        (Section 3.1.2), and MUST match the messageType attribute.

     o  The SignerInfo MUST contain a set of authenticatedAttributes (see
        PKCS#7 [RFC2315] Section 9.2 as well as Section 3.1.1 in this
        document).  All messages MUST contain

        *  an SCEP transactionID attribute

        *  an SCEP messageType attribute

        *  an SCEP senderNonce attribute

        *  any attributes required by PKCS#7 [RFC2315] Section 9.2

        If the message is a response, it MUST also include

        *  an SCEP pkiStatus attribute

        *  an SCEP recipientNonce attribute








  Pritikin, et al.         Expires March 10, 2012                [Page 17]


  Internet-Draft                    SCEP                    September 2011


  3.1.1.  Signed Transaction Attributes

     The following transaction attributes are encoded as authenticated
     attributes, and are carried, as specified in PKCS#7 [RFC2315] Section
     9.2, in the SignerInfo for this signedData.

     Please refer to Appendix A for the OID definitions.

       +----------------+-----------------+---------------------------+
       | Attribute      | Encoding        | Comment                   |
       +----------------+-----------------+---------------------------+
       | transactionID  | PrintableString | Hash value as a string    |
       | messageType    | PrintableString | Decimal value as a string |
       | pkiStatus      | PrintableString | Decimal value as a string |
       | failInfo       | PrintableString | Decimal value as a string |
       | senderNonce    | OCTET STRING    |                           |
       | recipientNonce | OCTET STRING    |                           |
       +----------------+-----------------+---------------------------+

                            Transaction Attributes

     The attributes are detailed in the following sections.

  3.1.1.1.  transactionID

     A PKI operation is a transaction consisting of the messages exchanged
     between a requester and the server.  The transaction identifier is a
     string generated by the client when starting a transaction.  The
     client MUST generate a unique string as the transaction identifier,
     which MUST be used for all PKI messages exchanged for a given
     enrollment, encoded as a PrintableString.

     The transactionID SHOULD be generated as a SHA-1, SHA-256, SHA-512 or
     MD5 hash on the public key value for which the enrollment request is
     made.  This allows the SCEP client to automatically generate the same
     transactionID for any given keypair.  The SCEP protocol requires that
     transactionIDs be unique, so that subsequent polling queries can be
     matched with previous transactions.  When separate signing and
     encryption certificates are requested by the client, using distinct
     keypairs ensures that distinct transactionIDs are also used.

     When using the certificate query and CRL query messages defined in
     this protocol, the transactionID is required so that the requester
     can match the response message with the outstanding request message.
     When using LDAP to query the certificate and the CRL, the behavior is
     specified by the LDAP protocol.  For a non-enrollment message (for
     example GetCert and GetCRL), the transactionID SHOULD be a number
     unique to the client.



  Pritikin, et al.         Expires March 10, 2012                [Page 18]


  Internet-Draft                    SCEP                    September 2011


  3.1.1.2.  messageType

     The messageType attribute specifies the type of operation performed
     by the transaction.  This attribute MUST be included in all PKI
     messages.  The following message types are defined:

     o  PKCSReq (19) -- PKCS#10 [RFC2986] certificate request

     o  CertRep (3) -- Response to certificate or CRL request

     o  GetCertInitial (20) -- Certificate polling in manual enrollment

     o  GetCert (21) -- Retrieve a certificate

     o  GetCRL (22) -- Retrieve a CRL

     Undefined message types are treated as an error.

  3.1.1.3.  pkiStatus

     All response messages MUST include transaction status information,
     which is defined as pkiStatus attribute:

     o  SUCCESS (0) -- request granted

     o  FAILURE (2) -- request rejected.  When pkiStatus is FAILURE, the
        failInfo attribute, as defined in Section 3.1.1.4, MUST also be
        present.

     o  PENDING (3) -- request pending for manual approval

     Undefined pkiStatus attributes are treated as an error.

  3.1.1.4.  failInfo

     The failInfo attribute MUST contain one of the following failure
     reasons:

     o  badAlg (0) -- Unrecognized or unsupported algorithm identifier

     o  badMessageCheck (1) -- integrity check failed

     o  badRequest (2) -- transaction not permitted or supported

     o  badTime (3) -- The signingTime attribute from the PKCS#7
        authenticatedAttributes was not sufficiently close to the system
        time (see Section 3.1.1.6).




  Pritikin, et al.         Expires March 10, 2012                [Page 19]


  Internet-Draft                    SCEP                    September 2011


     o  badCertId (4) -- No certificate could be identified matching the
        provided criteria

     Undefined failInfo attributes are treated as an error.

  3.1.1.5.  senderNonce and recipientNonce

     The attributes of senderNonce and recipientNonce are a 16 byte random
     number generated for each transaction.  These are intended to prevent
     replay attacks.

     When a requester sends a PKI message to the server, a senderNonce
     MUST be included in the message.

     The recipient SHOULD copy the senderNonce into the recipientNonce of
     the reply as a proof of liveliness.

     The requester SHOULD verify that the recipientNonce of the reply
     matches the senderNonce it sent in the request.

  3.1.1.6.  signingTime Attribute

     The signingTime attribute is defined in [RFC2985] Section 5.3.3, and
     is carried as specified in [RFC2315] Section 9.2.  This attribute is
     OPTIONAL.

  3.1.2.  SCEP pkcsPKIEnvelope

     The information portion of a SCEP message is carried inside an
     enveloped-data content type, as defined in PKCS#7 [RFC2315] Section
     10, with the following restrictions:

     o  version MUST be 0

     o  contentType in encryptedContentInfo MUST be data ({pkcs-7 1}) as
        defined in PKCS#7 [RFC2315] Section 8.

     o  encryptedContent MUST be the SCEP message being transported (see
        Section 4), and must match the messageType authenticated Attribute
        in the pkiMessage.

     The PKCS#7 [RFC2315] content-encryption key (see Section 10, step 2)
     is encrypted using the public key of the recipient of the message,
     i.e. the RA or the CA public key (if sent from the requester), or the
     requester public key (if sent as a reply to the requester).






  Pritikin, et al.         Expires March 10, 2012                [Page 20]


  Internet-Draft                    SCEP                    September 2011


  3.2.  SCEP pkiMessage types

     All of the messages in this section are pkiMessages (Section 3.1),
     where the type of the message MUST be specified in the 'messageType'
     authenticated Attribute.  Each section defines a valid message type,
     the corresponding messageData formats, and mandatory authenticated
     attributes for that type.

  3.2.1.  PKCSReq

     The messageData for this type consists of a PKCS#10 Certification
     Request [RFC2986].  The certification request MAY contain any fields
     defined in PKCS#10 [RFC2986], and MUST contain at least the following
     items:

     o  the subject Distinguished Name

     o  the subject public key

     o  a challengePassword attribute.  The Challenge Password may be used
        to (out-of-band) authenticate the enrollment request itself, or in
        an out-of-band revocation request for the issued certificate.

     In addition to the authenticatedAttributes required for a valid
     PKCS#7 [RFC2315], this pkiMessage MUST include the following
     attributes:

     o  a transactionID (Section 3.1.1.1) attribute

     o  a messageType (Section 3.1.1.2) attribute set to PKCSReq

     o  a senderNonce (Section 3.1.1.5) attribute

     The pkcsPKIEnvelope for this message type is protected using the
     public key of the recipient as detailed in Section 3.1.2, e.g. either
     the CA or RA public key.

  3.2.2.  CertRep

     The messageData for this type consists of a degenerate certificates-
     only PKCS#7 Signed-data (Section 3.3).  The exact content required
     for the reply depends on the type of request this message is a reply
     to.  They are detailed in Table 1 and in Section 4.

     In addition to the authenticatedAttributes required for a valid
     PKCS#7 [RFC2315], this pkiMessage MUST include the following
     attributes:




  Pritikin, et al.         Expires March 10, 2012                [Page 21]


  Internet-Draft                    SCEP                    September 2011


     o  the transactionID (Section 3.1.1.1) attribute copied from the
        request we are responding to

     o  a messageType (Section 3.1.1.2) attribute set to CertRep

     o  a senderNonce (Section 3.1.1.5) attribute

     o  a recipientNonce attribute (Section 3.1.1.5) copied from the
        senderNonce from the request we are responding to.

     o  a pkiStatus (Section 3.1.1.3) set to the status of the reply.

     The pkcsPKIEnvelope for this message type is protected using the
     public key of the recipient as detailed in Section 3.1.2.  For
     example if a self-signed certificate was used to send the original
     request then this self-signed certificate's public key is used to
     encrypt the content-encryption key of the SUCCESS response's
     pkcsPKIEnvelope.

  3.2.2.1.  CertRep SUCCESS

     When the pkiStatus attribute is set to SUCCESS, the messageData for
     this message consists of a degenerate certificates-only PKCS#7
     Signed-data (Section 3.3).  The content of this degenerate
     certificates-only Signed-Data depends on what the original request
     was, as outlined in Table 1.

     +----------------+--------------------------------------------------+
     | Request-type   | Reply-contents                                   |
     +----------------+--------------------------------------------------+
     | PKCSReq        | the reply MUST contain at least the issued       |
     |                | certificate in the certificates field of the     |
     |                | Signed-Data.  The reply MAY contain additional   |
     |                | certificates, but the issued certificate MUST be |
     |                | the first in the list.  The reply MUST NOT       |
     |                | contain a CRL.  All returned certificates MUST   |
     |                | conform to [RFC5280].                            |
     | GetCertInitial | same as PKCSReq                                  |
     | GetCert        | the reply MUST contain at least the requested    |
     |                | certificate in the certificates field of the     |
     |                | Signed-Data.  The reply MAY contain additional   |
     |                | certificates, but the requested certificate MUST |
     |                | be the first in the list.  The reply MUST NOT    |
     |                | contain a CRL.  All returned certificates MUST   |
     |                | conform to [RFC5280].                            |






  Pritikin, et al.         Expires March 10, 2012                [Page 22]


  Internet-Draft                    SCEP                    September 2011


     | GetCRL         | the reply MUST contain the CRL in the crls field |
     |                | of the Signed-Data.  The reply MUST NOT contain  |
     |                | a certificate.  The CRL MUST be a valid CRL      |
     |                | according to [RFC5280].                          |
     +----------------+--------------------------------------------------+

                            Table 1: CertRep Types

  3.2.2.2.  CertRep FAILURE

     When the pkiStatus attribute is set to FAILURE, the reply MUST also
     contain a failInfo (Section 3.1.1.4) attribute set to the appropriate
     error condition describing the failure.  The pkcsPKIEnvelope
     (Section 3.1.2) MUST be omitted.

  3.2.2.3.  CertRep PENDING

     When the pkiStatus attribute is set to PENDING, the pkcsPKIEnvelope
     (Section 3.1.2) MUST be omitted.

  3.2.3.  GetCertInitial

     The messageData for this type consists of a IssuerAndSubject
     (Section 3.2.3.1).  The issuer is set to the issuerName from the
     certification authority from which we are issued certificates.  The
     Subject is set to the SubjectName we used when requesting the
     certificate.

     In addition to the authenticatedAttributes required for a valid
     PKCS#7 [RFC2315], this pkiMessage MUST include the following
     attributes:

     o  the same transactionID (Section 3.1.1.1) attribute from original
        PKCSReq message

     o  a messageType (Section 3.1.1.2) attribute set to GetCertInitial

     o  a senderNonce (Section 3.1.1.5) attribute

  3.2.3.1.  IssuerAndSubject

     Similar to the IssuerAndSerial defined in PKCS#7 [RFC2315] Section
     6.7, we need to define an IssuerAndSubject ASN.1 type (Figure 7).








  Pritikin, et al.         Expires March 10, 2012                [Page 23]


  Internet-Draft                    SCEP                    September 2011


     The ASN.1 definition of the issuerAndSubject type is as follows:
     issuerAndSubject ::= SEQUENCE {
         issuer Name,
         subject Name
     }

                       Figure 7: IssuerAndSubject ASN.1

  3.2.4.  GetCert

     The messageData for this type consists of a IssuerAndSerial as
     defined in PKCS#7 [RFC2315] Section 6.7 containing the "distinguished
     name of the certificate issuer and an issuer-specific certificate
     serial number" which uniquely identifies the certificate being
     requested.

     In addition to the authenticatedAttributes required for a valid
     PKCS#7 [RFC2315], this pkiMessage MUST include the following
     attributes:

     o  a transactionID (Section 3.1.1.1) attribute

     o  a messageType (Section 3.1.1.2) attribute set to GetCert

     o  a senderNonce (Section 3.1.1.5) attribute

     A self-signed certificate MAY be used in the signed envelope.  This
     enables the requester to request their own certificate if they were
     unable to store it previously.

  3.2.5.  GetCRL

     The messageData for this type consists of a IssuerAndSerial as
     defined in PKCS#7 [RFC2315] Section 6.7 along with the issuer name
     and serial number from the certificate to be validated.

     In addition to the authenticatedAttributes required for a valid
     PKCS#7 [RFC2315], this pkiMessage MUST include the following
     attributes:

     o  a transactionID (Section 3.1.1.1) attribute

     o  a messageType (Section 3.1.1.2) attribute set to GetCRL

     o  a senderNonce (Section 3.1.1.5) attribute






  Pritikin, et al.         Expires March 10, 2012                [Page 24]


  Internet-Draft                    SCEP                    September 2011


  3.3.  Degenerate certificates-only PKCS#7 Signed-data

     [RFC2315] Section 9 includes a degenerate case of the PKCS#7 Signed-
     data content type, in which there are no signers.  The use of such a
     degenerate case is to disseminate certificates and certificate-
     revocation lists.  For SCEP the content field of the ContentInfo
     value of a degenerate certificates-only Signed-Data MUST be omitted.

     When carrying certificates, the certificates are included in the
     'certificates' field of the Signed-Data.  When carrying a CRL, the
     CRL will be included in the 'crls' field of the Signed-Data.


  4.  SCEP Transactions

     This section describes the SCEP Transactions, without explaining the
     transport.  The transport of each message is discussed in Section 5.
     Some of the transaction-requests have no data to send, i.e. the only
     data is the message-type itself (e.g. a GetCACert message has no
     additional data).  The use of such messages will become clearer in
     Section 5.

     In this section, each SCEP transaction is specified in terms of the
     complete messages exchanged during the transaction.

     The order of the transactions in this section is mirrored in
     Section 5.2 for better organization and readability.

  4.1.  Get CA Certificate

     To get the CA certificate(s), the requester sends a GetCACert message
     to the server.  There is no request data associated with this message
     (see Section 5.2.1).

  4.1.1.  Get CA Certificate Response Message Format

     The response depends on whether the responding server has RA
     certificates or only a single CA certificate.  The server MUST
     indicate which response it is sending via the transport protocol used
     (see Section 5.2.1).

     All returned certificates MUST conform to [RFC5280].

     A fingerprint is generated using the SHA-1, SHA-256, SHA-512 or MD5
     hash algorithm on the whole CA certificate received by the requester
     (regardless of the presence of RA certificates).  If the requester
     does not have a certificate path to a trust anchor certificate, this
     fingerprint may be used to verify the certificate, by some positive



  Pritikin, et al.         Expires March 10, 2012                [Page 25]


  Internet-Draft                    SCEP                    September 2011


     out-of-band means, such as a phone call or prior configuration.

  4.1.1.1.  CA Certificate Response Message Format

     If the server is a certification authority and does not have any RA
     Certificates, the response consists of a single X.509 CA certificate.

  4.1.1.2.  CA/RA Certificate Response Message Format

     If the server has RA Certificates, the response consists of a
     degenerate certificates-only PKCS#7 Signed-data (Section 3.3)
     containing the CA certificate and RA certificates.

  4.2.  Certificate Enrollment

     A PKCSReq (Section 3.2.1) message is used to perform a certificate
     enrollment transaction.

     The reply MUST be a CertRep (Section 3.2.2) message sent back from
     the server, indicating SUCCESS, FAILURE, or PENDING.

     Precondition: Both the requester and the certification authority have
     completed their initialization process.  The requester has already
     been configured with the CA/RA certificate.

     Postcondition: The requester receives the certificate, the request is
     rejected, or the request is pending.  A pending response might
     indicate that manual authentication is necessary.

  4.2.1.  Certificate Enrollment Response Message

     If the request is granted, a CertRep (Section 3.2.2) message with
     pkiStatus set to SUCCESS is returned.  The reply MUST also contain
     the certificate (and MAY contain any other certificates needed by the
     requester).  The issued certificate MUST be the first in the list.

     If the request is rejected, a CertRep (Section 3.2.2) message with
     pkiStatus set to FAILURE is returned.  The reply MUST also contain a
     failInfo attribute.

     If the the CA is configured to manually authenticate the requester, a
     CertRep (Section 3.2.2) message with pkiStatus set to PENDING MAY be
     returned.  The CA MAY return a PENDING for other reasons.

  4.3.  Poll for Requester Initial Certificate

     Triggered by a CertRep (Section 3.2.2) with pkiStatus set to PENDING,
     a requester will enter the polling state by periodically sending



  Pritikin, et al.         Expires March 10, 2012                [Page 26]


  Internet-Draft                    SCEP                    September 2011


     GetCertInitial (Section 3.2.3) to the server, until either the
     request is granted and the certificate is sent back, or the request
     is rejected, or the configured time limit for polling (or maximum
     number of polls) is exceeded.

     Since GetCertInitial is part of the enrollment, the messages
     exchanged during the polling period MUST carry the same transactionID
     attribute as the previous PKCSReq.  A server receiving a
     GetCertInitial for which it does not have a matching PKCSReq MUST
     ignore this request.

     Since at this time the certificate has not been issued, the requester
     can only use its own subject name (which was contained in the
     original PKCS#10 sent via PKCSReq) to identify the polled certificate
     request.  Since there can be multiple outstanding requests from one
     requester (for example, if different keys and different key-usages
     were used to request multiple certificates), the transaction ID must
     also be included, to disambiguate between multiple requests.

     PreCondition: The requester has received a CertRep with pkiStatus set
     to PENDING.

     PostCondition: The requester has either received a valid response,
     which could be either a valid certificate (pkiStatus = SUCCESS), or a
     FAILURE message, or the polling period times out.

  4.3.1.  Polling Response Message Format

     The response messages for GetCertInitial are the same as in
     Section 4.2.1.

  4.4.  Certificate Access

     A requester can query an issued certificate from the SCEP server, as
     long as the requester knows the issuer name and the issuer assigned
     certificate serial number.  This transaction is not intended to
     provide a generic certificate directory service.

     This transaction consists of one GetCert (Section 3.2.4) message sent
     to the server by a requester, and one CertRep (Section 3.2.2) message
     sent back from the server.

     PreCondition: The certification authority has issued the queried
     certificate and the issuer assigned serial number is known.

     PostCondition: Either the certificate is sent back or the request is
     rejected.




  Pritikin, et al.         Expires March 10, 2012                [Page 27]


  Internet-Draft                    SCEP                    September 2011


  4.4.1.  Certificate Access Response Message Format

     In this case, the CertRep from the server is same as in
     Section 4.2.1, except that the server will only either grant the
     request (SUCCESS) or reject the request (FAILURE).

  4.5.  CRL Access

     Clients MAY request a CRL from the SCEP server as described in
     Section 2.7.

     PreCondition: The certification authority certificate has been
     downloaded to the end entity.

     PostCondition: CRL sent back to the requester.

  4.5.1.  CRL Access Response Message Format

     The CRL is sent back to the requester in a CertRep (Section 3.2.2)
     message.  The information portion of this message is a degenerate
     certificates-only Signed-data (Section 3.3) that contains only the
     most recent CRL in the crls field of the Signed-Data.

     The server MAY return any appropriate CRL.

  4.6.  Get Next Certification Authority Certificate

     When a CA certificate is about to expire, clients need to retrieve
     the CA's next CA certificate (i.e. the Rollover Certificate).  This
     is done via the GetNextCACert message.  There is no request data
     associated with this message (see Section 5.2.6).

  4.6.1.  Get Next CA Response Message Format

     The response consists of a SignedData PKCS#7 [RFC2315], signed by the
     current CA (or RA) signing key.

     Clients MUST validate the signature on the the SignedData PKCS#7
     [RFC2315] before accepting any of its contents.

     The content of the SignedData PKCS#7 [RFC2315] is a degenerate
     certificates-only Signed-data (Section 3.3) message containing the
     new CA certificate and any new RA certificates, as defined in
     Section 5.2.1.1.2, to be used when the current CA certificate
     expires.

     If the CA (or RA) does not have the Rollover certificate(s) it MUST
     reject the request.  It SHOULD also remove the GetNextCACert setting



  Pritikin, et al.         Expires March 10, 2012                [Page 28]


  Internet-Draft                    SCEP                    September 2011


     from the capabilities until it does have rollover certificates.

     If there are any RA certificates in this response, clients MUST check
     that these RA certificates are signed by the CA, and MUST check
     authorization of these RA certificates (see Section 2.1.3).


  5.  SCEP Transport

     HTTP [RFC2616] is used as the transport protocol for SCEP Message
     Objects.

  5.1.  HTTP "GET" Message Format

     SCEP uses the HTTP "GET" messages to request information from the CA.
     The following defines the syntax of a HTTP GET message sent from a
     requester to a certification authority server:
     "GET" CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE

     where:

     o  CGI-PATH defines the actual CGI path to invoke the CGI program
        that parses the request.

     o  CGI-PROG is set to be the string "pkiclient.exe".  This is
        intended to be the program that the CA will use to handle the SCEP
        transactions, though the CA may ignore CGI-PROG and use only the
        CGI-PATH.

     o  OPERATION depends on the SCEP transaction and is defined in the
        following sections.

     o  MESSAGE depends on the SCEP transaction and is defined in the
        following sections.

     If the CA supports it, requests SHOULD be done via an HTTP POST.
     This is described in Appendix F.

  5.1.1.  Response Message Format

     For each GET operation, the CA/RA server MUST return a Content-Type
     and appropriate response data, if any.

  5.2.  SCEP HTTP Messages

     This section describes the OPERATION and MESSAGE values for SCEP
     exchanges.




  Pritikin, et al.         Expires March 10, 2012                [Page 29]


  Internet-Draft                    SCEP                    September 2011


  5.2.1.  GetCACert

     The OPERATION MUST be set to "GetCACert".

     The MESSAGE MAY be omitted, or it MAY be a string that represents the
     certification authority issuer identifier.  A CA Administrator
     defined string allows for multiple CAs supported by one SCEP server.

  5.2.1.1.  GetCACert Response

     The response for GetCACert is different between the case where the CA
     directly communicates with the requester during the enrollment, and
     the case where a RA exists and the requester communicates with the RA
     during the enrollment.

  5.2.1.1.1.  CA Certificate Only Response

     The response will have a Content-Type of "application/
     x-x509-ca-cert".

     The body of this response consists of an X.509 CA certificate, as
     defined in Section 4.1.1.1.
     "Content-Type:application/x-x509-ca-cert\n\n"<binary X.509>

  5.2.1.1.2.  CA and RA Certificates Response

     The response will have a Content-Type of "application/
     x-x509-ca-ra-cert".

     The body of this response consists of a degenerate certificates-only
     PKCS#7 Signed-data (Section 3.3) containing both CA and RA
     certificates, as defined in Section 4.1.1.2.
     "Content-Type:application/x-x509-ca-ra-cert\n\n"<binary PKCS#7>

  5.2.2.  PKCSReq

     The OPERATION MUST be set to "PKIOperation".

     The MESSAGE consists of a PKCSReq SCEP message.  The message is
     "base64" encoded as specified in [RFC4648] Section 4.  The "base64"
     encoded data is distinct from "base64url" and may contain URI
     reserved characters, thus it MUST be escaped as specified in
     [RFC2396].

     An example PKIOperation request might look as follows:
   GET /cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIAGCSqGSIb3D
   QEHA6CAMIACAQAxgDCBzAIBADB2MGIxETAPBgNVBAcTCE ......AAAAAA== HTTP/1.0




  Pritikin, et al.         Expires March 10, 2012                [Page 30]


  Internet-Draft                    SCEP                    September 2011


  5.2.2.1.  PKCSReq Response

     The response will have a Content-Type of "application/x-pki-message".

     The body of this response consists of a CertRep SCEP message defined
     in Section 4.2.1.  The following is an example of the response:
     "Content-Type:application/x-pki-message\n\n"<binary CertRep msg>

  5.2.3.  GetCertInitial

     The OPERATION MUST be set to "PKIOperation".

     The MESSAGE consists of a GetCertInitial SCEP message.  The message
     is "base64" encoded as specified in [RFC4648] Section 4.  The
     "base64" encoded data is distinct from "base64url" and may contain
     URI reserved characters, thus it MUST be escaped as specified in
     [RFC2396].

  5.2.3.1.  GetCertInitial Response

     The body of this response consists of a CertRep SCEP message defined
     in Section 4.3.1.

  5.2.4.  GetCert

     The OPERATION MUST be set to "PKIOperation".

     The MESSAGE consists of a GetCert SCEP message.  The message is
     "base64" encoded as specified in [RFC4648] Section 4.  The "base64"
     encoded data is distinct from "base64url" and may contain URI
     reserved characters, thus it MUST be escaped as specified in
     [RFC2396].

  5.2.4.1.  GetCert Response

     The body of this response consists of a CertRep SCEP message defined
     in Section 4.4.1.

  5.2.5.  GetCRL

     The OPERATION MUST be set to "PKIOperation".

     The MESSAGE consists of a GetCRL SCEP message.  The message is
     "base64" encoded as specified in [RFC4648] Section 4.  The "base64"
     encoded data is distinct from "base64url" and may contain URI
     reserved characters, thus it MUST be escaped as specified in
     [RFC2396].




  Pritikin, et al.         Expires March 10, 2012                [Page 31]


  Internet-Draft                    SCEP                    September 2011


  5.2.5.1.  GetCRL Response

     The body of this response consists of a CertRep SCEP message defined
     in Section 4.5.1.

  5.2.6.  GetNextCACert

     The OPERATION MUST be set to "GetNextCACert".

     The MESSAGE MAY be ommitted, or it MAY be a string that represents
     the certification authority issuer identifier, if such has been set
     by the CA Administrator.

  5.2.6.1.  GetNextCACert Response

     The response will have a Content-Type of "application/
     x-x509-next-ca-cert".

     The body of this response consists of a SignedData PKCS#7 [RFC2315],
     as defined in Section 4.6.1.  (This is similar to the GetCert
     response but does not include any of the attributes defined in
     Section 3.1.1.)
     "Content-Type:application/x-x509-next-ca-cert\n\n"
     <binary PKCS#7>


  6.  Contributors/Acknowledgements

     The editor would like to thank all the previous editors, authors and
     contributors: Cheryl Madson, Xiaoyi Liu, David McGrew, David Cooper,
     Andy Nourse etc for their work maintaining the draft over the years.
     Numerous other people have contributed during the long life cycle of
     the draft and all deserve thanks.

     The authors would like to thank Peter William of ValiCert, Inc.
     (formerly of VeriSign, Inc.) and Alex Deacon of VeriSign, Inc. and
     Christopher Welles of IRE, Inc. for their contributions to early
     versions of this protocol and this document.


  7.  IANA Considerations

     This memo includes no request to IANA.


  8.  Security Considerations

     The security goals of SCEP are that no adversary can:



  Pritikin, et al.         Expires March 10, 2012                [Page 32]


  Internet-Draft                    SCEP                    September 2011


     o  subvert the public key/identity binding from that intended,

     o  discover the identity information in the enrollment requests and
        issued certificates,

     o  cause the revocation of certificates with any non-negligible
        probability.

     Here an adversary is any entity other than the requester and the CA
     (and optionally the RA) participating in the protocol.  The adversary
     is computationally limited, but that can manipulate data during
     transmission (that is, can act as a man-in-the-middle).  The precise
     meaning of 'computationally limited' depends on the implementer's
     choice of one-way hash functions and cryptographic algorithms.
     Reflecting the historical nature of this document the mandatory to
     implement algorithms are RSA, DES and MD5.  Depending on the CA
     capabilities, Triple-DES [TripleDES] SHOULD be used instead of DES,
     and SHA-1, SHA-256, or SHA-512 SHOULD be used instead of MD5 (see
     Appendix C).

     The first and second goals are met through the use of PKCS#7
     [RFC2315] and PKCS#10 [RFC2986] encryption and digital signatures
     using authenticated public keys.  The CA's public key is
     authenticated via the checking of the CA fingerprint, as specified in
     Section 2.1.2, and the SCEP client's public key is authenticated
     through the manual authentication or pre-shared secret
     authentication, as specified in Section 2.2.  The third goal is met
     through the use of a challenge password for revocation, which is
     chosen by the SCEP client and communicated to the CA protected by the
     PKCS#7 [RFC2315] encryptedData, as specified in Section 2.8.

     The motivation of the first security goal is straightforward.  The
     motivation for the second security goal is to protect the identity
     information in the enrollment requests and issued certificates.
     Subsequent protocols can use the certificate in ways that either
     expose the identity information, or protect it, depending on the
     security requirements of those protocols.  The motivation for the
     third security goal is to protect the SCEP clients from denial of
     service attacks.

  8.1.  General Security

     Common key-management considerations such as keeping private keys
     truly private and using adequate lengths for symmetric and asymmetric
     keys must be followed in order to maintain the security of this
     protocol.

     This is especially true for CA keys, which, when compromised,



  Pritikin, et al.         Expires March 10, 2012                [Page 33]


  Internet-Draft                    SCEP                    September 2011


     compromise the security of all relying parties.

  8.2.  Use of the CA keypair

     A CA key pair is generally meant for (and is usually flagged as)
     certificate signing ("keyCertSign") exclusively, rather than data
     signing ("digitalSignature") or data encryption
     ("dataEnchipherment").  The SCEP protocol, however, uses the CA
     private key to both encrypt and sign PKCS#7 [RFC2315] transport
     messages.  This is generally considered undesirable, as it widens the
     possibility of an implementation weakness, and provides

     o  another place that the private key must be used (and hence is
        slightly more vulnerable to exposure),

     o  another place where a side channel attack (say, timing or power
        analysis) might be used,

     o  another place that the attacker might somehow insert his own text,
        and get it signed by the private key.

     While the CA key pair can be generated with the data encryption and
     data signing flags set, this is operationally not encouraged.  It
     would make using the key as a PKCS#7 [RFC2315] transport key 'legal',
     but the discussion from the previous paragraph still applies.

     A solution is to use RA keys to secure the SCEP transport (i.e.
     message signing and encrypting), which allows the CA keys to be used
     only for their intended purpose of certificate signing.

     An RA can be implemented in two ways: physically separate or
     implicit.  In the implicit case, the CA simply creates an extra key
     pair.  A physically separate RA allows the CA to be inside the secure
     network, not accessible to hackers at all.

  8.3.  ChallengePassword

     The challengePassword sent in the PKCS#10 enrollment request is
     signed and encrypted by way of being encapsulated in a pkiMessage.
     When saved by the CA, care should be taken to protect this password.

     If the challengePassword is used to automatically authenticate an
     enrollment request, it is recommended that some form of one-time
     password be used to minimize damage in the event the data is
     compromised.






  Pritikin, et al.         Expires March 10, 2012                [Page 34]


  Internet-Draft                    SCEP                    September 2011


  8.4.  transactionID

     A well-written CA/RA SHOULD NOT rely on the transactionID to be
     correct or as specified in this document.  Requesters with buggy
     software might add additional undetected duplicate requests to the
     CA's queue (or worse).  A well-written CA/RA should never assume the
     data from a requester is well-formed.

  8.5.  Nonces and Replay

     In order to detect replay attacks, both sides need to maintain state
     information sufficient to detect an unexpected nonce value.

     Since existing implementations do not copy the senderNonce from a
     CertRep into subsequent GetCertinitial requests, the server will
     never see its own nonce reflected back to it.  The transactionID can
     be used to link together the GetCertInitial and PKCSReq messages.

  8.6.  Key Usage Issues

     Key pairs may be intended for particular purposes, such as encryption
     only or signing only.  The usage of any associated certificate can be
     restricted by adding key usage and extended key usage attributes to
     the PKCS#10 [RFC2986].  If key usage is not present, the public key
     is assumed to be a general purpose key that may be used for all
     purposes.

     When building a pkiMessage, clients MUST have a certificate to sign
     the PKCS#7 [RFC2315] signed-data (because PKCS#7 [RFC2315] requires
     it).  Clients MUST either use an existing certificate, or create a
     self-signed certificate (see Section 2.3).  If the certificate has a
     key usage extension in it, then both the SCEP client and SCEP server
     MUST ignore the key usage for the duration of the transaction (the
     key will be used for signing during the creation of the PKCSReq
     message, and for encryption during the creation of the CertRep
     message).

  8.7.  GetCACaps Issues

     The GetCACaps response is not signed.  This allows an attacker to use
     downgrade attacks (as well as "upgrade attacks") on the cryptographic
     capabilities of the CA.

  8.8.  Unnecessary cryptography

     Some of the SCEP exchanges use signing and encryption operations that
     are not necessary.  In particular the GetCert and GetCRL exchanges
     are encrypted and signed in both directions.  The information



  Pritikin, et al.         Expires March 10, 2012                [Page 35]


  Internet-Draft                    SCEP                    September 2011


     requested is public and thus signing the requests is of questionable
     value but also CRLs and Certificates, i.e. the respective responses,
     are already signed by the CA and can be verified by the recipient
     without requiring additional signing and encryption.

     This may affect performance and scalability of the CA and could be
     used as an attack vector on the CA (though not an anonymous one).
     The use of CDPs is recommended for CRL access, as well as other ways
     of retrieving certificates (LDAP, direct HTTP access, etc.).

  8.9.  GetNextCACert

     Servers implementing early versions of the SCEP draft might return an
     unsigned GetNextCACert response by erroneously mirroring the
     (unsigned) functionality of GetCACert.  Client receiving such
     responses MUST ignored them.

     GetNextCACert depends on a 'flag moment' at which every client in the
     PKI infrastructure switches from the current CA certificate (and
     client certificate) to the new CA certificate and client
     certificates.  Proper monitoring of the network infrastructure can
     ensure that this will proceed as expected but any errors in
     processing or implementation can result in a failure of the PKI
     infrastructure.


  9.  References

  9.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

     [RFC2315]  Kaliski, B., "PKCS #7: Cryptographic Message Syntax
                Version 1.5", RFC 2315, March 1998.

     [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
                Resource Identifiers (URI): Generic Syntax", RFC 2396,
                August 1998.

     [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.

     [RFC2985]  Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
                Classes and Attribute Types Version 2.0", RFC 2985,
                November 2000.




  Pritikin, et al.         Expires March 10, 2012                [Page 36]


  Internet-Draft                    SCEP                    September 2011


     [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
                Request Syntax Specification Version 1.7", RFC 2986,
                November 2000.

     [RFC4210]  Adams, C., Farrell, S., Kause, T., and T. Mononen,
                "Internet X.509 Public Key Infrastructure Certificate
                Management Protocol (CMP)", RFC 4210, September 2005.

     [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
                Encodings", RFC 4648, October 2006.

     [RFC5272]  Schaad, J. and M. Myers, "Certificate Management over CMS
                (CMC)", RFC 5272, 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.

     [TripleDES]
                "ANSI X9.52-1998, Triple Data Encryption Algorithm Modes
                of Operation", 1998.

  9.2.  Informative References

     [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
                (IKE)", RFC 2409, November 1998.

     [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
                RFC 4306, December 2005.

     [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
                (TLS) Protocol Version 1.1", RFC 4346, April 2006.

     [RFC4945]  Korver, B., "The Internet IP Security PKI Profile of
                IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.


  Appendix A.  Private OID Definitions

     The OIDs used in SCEP are VeriSign self-maintained OIDs.










  Pritikin, et al.         Expires March 10, 2012                [Page 37]


  Internet-Draft                    SCEP                    September 2011


     +-------------------+-----------------------------------------------+
     | Name              | ASN.1 Definition                              |
     +-------------------+-----------------------------------------------+
     | id-VeriSign       | OBJECT_IDENTIFIER ::= {2 16 US(840) 1         |
     |                   | VeriSign(113733)}                             |
     | id-pki            | OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)}    |
     | id-attributes     | OBJECT_IDENTIFIER ::= {id-pki attributes(9)}  |
     | id-messageType    | OBJECT_IDENTIFIER ::= {id-attributes          |
     |                   | messageType(2)}                               |
     | id-pkiStatus      | OBJECT_IDENTIFIER ::= {id-attributes          |
     |                   | pkiStatus(3)}                                 |
     | id-failInfo       | OBJECT_IDENTIFIER ::= {id-attributes          |
     |                   | failInfo(4)}                                  |
     | id-senderNonce    | OBJECT_IDENTIFIER ::= {id-attributes          |
     |                   | senderNonce(5)}                               |
     | id-recipientNonce | OBJECT_IDENTIFIER ::= {id-attributes          |
     |                   | recipientNonce(6)}                            |
     | id-transId        | OBJECT_IDENTIFIER ::= {id-attributes          |
     |                   | transId(7)}                                   |
     | id-extensionReq   | OBJECT_IDENTIFIER ::= {id-attributes          |
     |                   | extensionReq(8)}                              |
     +-------------------+-----------------------------------------------+


  Appendix B.  SCEP State Transitions

     SCEP state transitions are indexed by the transactionID attribute.
     The design goal is to ensure the synchronization between the CA and
     the requester under various error situations.

     Each enrollment transaction is uniquely associated with a transaction
     identifier (carried in the transactionID signed attribute (see
     Section 3.1.1.1).  Because the enrollment transaction could be
     interrupted by various errors, including network connection errors or
     client reboot, the SCEP client generates a transaction identifier by
     calculating a hash on the public key value for which the enrollment
     is requested.  The requester generates the transaction identifier
     which is included in PKCSReq.  If the CA returns a response of
     PENDING, the requester will poll by periodically sending out
     GetCertInitial with the same transaction identifier until either a
     response other than PENDING is obtained, or the configured maximum
     time has elapsed.  This mechanism retains the same transaction
     identifier throughout the enrollment transaction.

     If the client times out or the client reboots, the client
     administrator will start another enrollment transaction with the same
     key pair.  The second enrollment will have the same transaction
     identifier.  At the server side, instead of accepting the PKCSReq as



  Pritikin, et al.         Expires March 10, 2012                [Page 38]


  Internet-Draft                    SCEP                    September 2011


     a new enrollment request, it can respond as if another GetCertInitial
     message had been sent with that transaction ID.  The second PKCSReq
     should be taken as a resynchronization message to allow the
     enrollment to resume as the same transaction.

     The following gives several examples of client to CA transactions.

     Client actions are indicated in the left column, CA actions are
     indicated in the right column.  A blank action signifies that no
     message was received.

     The first transaction, for example, would read like this:

     "Client Sends PKCSReq message with transaction ID 1 to the CA.  The
     CA signs the certificate and constructs a CertRep Message containing
     the signed certificate with a transaction ID 1.  The client receives
     the message and installs the certificate locally."

     Successful Enrollment Case: no manual authentication
     PKCSReq (1)             ----------> CA Signs Cert
     Client Installs Cert    <---------- CertRep (1) SIGNED CERT

     Successful Enrollment Case: manual authentication required
     PKCSReq (10)            ----------> Cert Request goes into Queue
     Client Polls            <---------- CertRep (10) PENDING
     GetCertInitial (10)     ----------> Still pending
     Client Polls            <---------- CertRep (10) PENDING
     GetCertInitial (10)     ----------> Still pending
     Client Polls            <---------- CertRep (10) PENDING
     GetCertInitial (10)     ----------> Still pending
     Client Polls            <---------- CertRep (10) PENDING
     GetCertInitial (10)     ----------> Cert has been signed
                             <---------- CertRep (10) SIGNED CERT
     Client Installs Cert

     Resync Case 1 - CA Receives PKCSReq, sends PENDING, eventually grants
     the certificate and returns SUCCESS, with the certificate.  The
     SUCCESS gets lost:
     PKCSReq (3)           ----------> Cert Request goes into queue
                           <---------- CertRep (3) PENDING
     GetCertInitial (3)    ----------> Still pending
                           <---------- CertRep (3) PENDING
     GetCertInitial (3)    -----------> Cert has been signed
                             X-------- CertRep(3) SIGNED CERT
     (Time Out)
     PKCSReq (3)           ----------> Cert already granted
                           <---------- CertRep (3) SIGNED CERT
     Client Installs Cert



  Pritikin, et al.         Expires March 10, 2012                [Page 39]


  Internet-Draft                    SCEP                    September 2011


     Resync Case 2 - CA Receives PKCSReq, sends PENDING, PENDING reply
     gets lost:
     PKCSReq (3)           ----------> Cert Request goes into queue
                             X-------- CertRep (3) PENDING
     (Time Out)
     PKCSReq (3)           ---------->
                           <---------- CertRep (3) PENDING
     etc...

     Case when the Certificate is lost, the CA arbitrarily refuses to sign
     a replacement (enforcing name-uniqueness) until the original
     certificate has been revoked (there is no change of name
     information):
     PKCSReq (4)           ----------> CA Signs Cert
                           <---------- CertRep (4) SIGNED CERT
     Client Installs Cert
     (Client looses Cert)
     PKCSReq (5)           ----------> There is already a valid cert with
                                       this DN.
                           <---------- CertRep (5) BAD REQUEST
                                       Admin Revokes
     PKCSReq (5)           ----------> CA Signs Cert
                           <---------- CertRep (5) SIGNED CERT
     Client Installs Cert


  Appendix C.  CA Capabilities

  C.1.  GetCACaps HTTP Message Format

     "GET" CGI-PATH CGI-PROG "?operation=GetCACaps" "&message=" CA-IDENT

     This message requests capabilities from CA.  The response is a list
     of text capabilities, as defined in Appendix C.2.  CA servers SHOULD
     support the GetCACaps message and MUST support it when they support
     certificate renewal using the method described in Appendix D.

  C.2.  CA Capabilities Response Format

     The response for a GetCACaps message is a list of CA capabilities, in
     plain text, separated by <LF> characters, as follows (quotation marks
     are NOT sent):









  Pritikin, et al.         Expires March 10, 2012                [Page 40]


  Internet-Draft                    SCEP                    September 2011


     +--------------------+----------------------------------------------+
     | Keyword            | Description                                  |
     +--------------------+----------------------------------------------+
     | "GetNextCACert"    | CA Supports the GetNextCACert message.       |
     | "POSTPKIOperation" | PKIOPeration messages may be sent via HTTP   |
     |                    | POST.                                        |
     | "Renewal"          | Clients may use current certificate and key  |
     |                    | to authenticate an enrollment request for a  |
     |                    | new certificate.                             |
     | "SHA-512"          | CA Supports the SHA-512 hashing algorithm.   |
     | "SHA-256"          | CA Supports the SHA-256 hashing algorithm.   |
     | "SHA-1"            | CA Supports the SHA-1 hashing algorithm.     |
     | "DES3"             | CA Supports the Triple-DES encryption        |
     |                    | algorithm.                                   |
     +--------------------+----------------------------------------------+

     The client SHOULD use SHA-1, SHA-256, or SHA-512 in preference to MD5
     hashing if it is supported by the CA.

     The server MUST use the texual case specified here, but clients
     SHOULD ignore the textual case when processing this message.  A
     client MUST be able to accept and ignore any unknown keywords that
     might be sent back by a CA.

     If the CA supports none of the above capabilities the SCEP server
     SHOULD return an empty message.  A server MAY simply return an HTTP
     Error.  A client that receives an empty message or an HTTP error
     SHOULD interpret the response as if none of the requested
     capabilities are supported by the CA.

     The Content-type of the reply SHOULD be "text/plain".  Clients SHOULD
     ignore the Content-type, as older server implementations of SCEP may
     send various Content-types.

     Example:
     GET /cgi-bin/pkiclient.exe?operation=GetCACaps&message=myca

     might return:
     GetNextCACert<LF>POSTPKIOperation

     This means that the CA supports the GetNextCACert message and allows
     PKIOperation messages (PKCSreq, GetCert, GetCertInitial, ...) to be
     sent using HTTP POST.


  Appendix D.  Client Certificate Renewal

     An enrollment request that occurs more than halfway through the



  Pritikin, et al.         Expires March 10, 2012                [Page 41]


  Internet-Draft                    SCEP                    September 2011


     validity period of an existing certificate for the same subject name
     and key usage MAY be interpreted as a re-enrollment or renewal
     request and be accepted.  A new certificate with new validity dates
     can be issued, even though the old one is still valid, if the CA
     policy permits.  The server MAY automatically revoke the old client
     certificate.  Clients MUST use GetCACaps (see Appendix C) to
     determine if the CA supports renewal.  Clients MUST support servers
     that do not implement renewal, or that reject renewal requests.

     To renew a client certificate, the client uses the PKCSreq message
     and signs it with the existing client certificate.  The client SHOULD
     use a new keypair when requesting a new certificate.  The client MAY
     request a new certicate using the old keypair.


  Appendix E.  CA Key Rollover

     When the CA certificate expires all certificates that have been
     signed by it are no longer valid.  CA key rollover provides a
     mechanism by which the server MAY distribute a new CA certificate
     which is valid in the future; when the current certificate has
     expired.  Clients MUST use GetCACaps (see Appendix C) to determine if
     the CA supports GetNextCACert.

     To obtain the new CA certificate prior to the expiration of the
     current one, the client uses the GetNextCACert message.

     To obtain a new client certificate signed by the new CA certificate,
     use the new CA or RA certificate in the PKCSreq message envelope.

     Clients MUST store the not-yet-valid CA certificate, and any not-yet-
     valid client certificates obitained, until such time that they are
     valid.  At which point clients switch over to using the newly valid
     certificates.

     Example:

  GetNextCACert           ---------->
                          <---------- New CA certificate

  PKCSReq*                ----------> CA Signs certificate with NEW key
  Client Stores Cert      <---------- CertRep - Certificate issued
  for installation when               from NEW CA certificate and key pair
  existing cert expires.

  *enveloped for new CA or RA cert and key pair.  The CA will use the
  envelope to determine which key and certificate to use to issue the
  client certificate.



  Pritikin, et al.         Expires March 10, 2012                [Page 42]


  Internet-Draft                    SCEP                    September 2011


  Appendix F.  PKIOperation via HTTP POST Message

     If the remote CA supports it, any of the PKCS#7 [RFC2315]-encoded
     SCEP messages may be sent via HTTP POST instead of HTTP GET.  This is
     allowed for any SCEP message except GetCACert, GetNextCACert, or
     GetCACaps.  In this form of the message, base64 encoding is not used.
     POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.0
     Content-Length: <length of data>

     <binary PKCS#7 data>

                              General POST Syntax

     The client can verify that the CA supports SCEP messages via POST by
     looking for the "POSTPKIOperation" capability (See Appendix C).


  Authors' Addresses

     Max Pritikin (editor)
     Cisco Systems, Inc

     Email: pritikin@cisco.com


     Andrew Nourse
     Cisco Systems, Inc

     Email: nourse@cisco.com


     Jan Vilhuber
     Cisco Systems, Inc

     Email: vilhuber@cisco.com
















  Pritikin, et al.         Expires March 10, 2012                [Page 43]



name: draft-barnes-hpke-hpke
rev: 00
title: Hybrid Public Key Encryption
time: 2025-05-11T23:00:57Z
group_uri: /api/v1/group/group/2448/
expires: 2025-09-21T10:15:19Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/35/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:13.081955+00:00
source: ietf
abstract:
  This document describes a scheme for hybrid public key encryption
     (HPKE).  This scheme provides a variant of public key encryption of
     arbitrary-sized plaintexts for a recipient public key.  It also
     includes three authenticated variants, including one that
     authenticates possession of a pre-shared key and two optional ones
     that authenticate possession of a key encapsulation mechanism (KEM)
     private key.  HPKE works for any combination of an asymmetric KEM,
     key derivation function (KDF), and authenticated encryption with
     additional data (AEAD) encryption function.  Some authenticated
     variants may not be supported by all KEMs.  We provide instantiations
     of the scheme using widely used and efficient primitives, such as
     Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key
     derivation function (HKDF), and SHA2.

     This document is a product of the Crypto Forum Research Group (CFRG)
     in the IRTF.

full_text:
  HPKE                                                           R. Barnes
  Internet-Draft                                                     Cisco
  Intended status: Standards Track                            K. Bhargavan
  Expires: 21 September 2025                                       B. Lipp
                                                                     Inria
                                                                   C. Wood
                                                                     Apple
                                                             20 March 2025


                        Hybrid Public Key Encryption
                         draft-barnes-hpke-hpke-00

  Abstract

     This document describes a scheme for hybrid public key encryption
     (HPKE).  This scheme provides a variant of public key encryption of
     arbitrary-sized plaintexts for a recipient public key.  It also
     includes three authenticated variants, including one that
     authenticates possession of a pre-shared key and two optional ones
     that authenticate possession of a key encapsulation mechanism (KEM)
     private key.  HPKE works for any combination of an asymmetric KEM,
     key derivation function (KDF), and authenticated encryption with
     additional data (AEAD) encryption function.  Some authenticated
     variants may not be supported by all KEMs.  We provide instantiations
     of the scheme using widely used and efficient primitives, such as
     Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key
     derivation function (HKDF), and SHA2.

     This document is a product of the Crypto Forum Research Group (CFRG)
     in the IRTF.

  Discussion Venues

     This note is to be removed before publishing as an RFC.

     Source for this draft and an issue tracker can be found at
     https://github.com/hpkewg/hpke.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.



  Barnes, et al.          Expires 21 September 2025               [Page 1]


  Internet-Draft                    HPKE                        March 2025


     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 21 September 2025.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   5
     3.  Notation  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Cryptographic Dependencies  . . . . . . . . . . . . . . . . .   6
       4.1.  DH-Based KEM (DHKEM)  . . . . . . . . . . . . . . . . . .   8
     5.  Hybrid Public Key Encryption  . . . . . . . . . . . . . . . .  11
       5.1.  Creating the Encryption Context . . . . . . . . . . . . .  12
         5.1.1.  Encryption to a Public Key  . . . . . . . . . . . . .  15
         5.1.2.  Authentication Using a Pre-Shared Key . . . . . . . .  15
         5.1.3.  Authentication Using an Asymmetric Key  . . . . . . .  16
         5.1.4.  Authentication Using Both a PSK and an Asymmetric
                 Key . . . . . . . . . . . . . . . . . . . . . . . . .  16
       5.2.  Encryption and Decryption . . . . . . . . . . . . . . . .  17
       5.3.  Secret Export . . . . . . . . . . . . . . . . . . . . . .  19
     6.  Single-Shot APIs  . . . . . . . . . . . . . . . . . . . . . .  19
       6.1.  Encryption and Decryption . . . . . . . . . . . . . . . .  19
       6.2.  Secret Export . . . . . . . . . . . . . . . . . . . . . .  20
     7.  Algorithm Identifiers . . . . . . . . . . . . . . . . . . . .  21
       7.1.  Key Encapsulation Mechanisms (KEMs) . . . . . . . . . . .  21
         7.1.1.  SerializePublicKey and DeserializePublicKey . . . . .  21
         7.1.2.  SerializePrivateKey and DeserializePrivateKey . . . .  22
         7.1.3.  DeriveKeyPair . . . . . . . . . . . . . . . . . . . .  22
         7.1.4.  Validation of Inputs and Outputs  . . . . . . . . . .  24
         7.1.5.  Future KEMs . . . . . . . . . . . . . . . . . . . . .  24
       7.2.  Key Derivation Functions (KDFs) . . . . . . . . . . . . .  24



  Barnes, et al.          Expires 21 September 2025               [Page 2]


  Internet-Draft                    HPKE                        March 2025


         7.2.1.  Input Length Restrictions . . . . . . . . . . . . . .  25
       7.3.  Authenticated Encryption with Associated Data (AEAD)
             Functions . . . . . . . . . . . . . . . . . . . . . . . .  26
     8.  API Considerations  . . . . . . . . . . . . . . . . . . . . .  26
       8.1.  Auxiliary Authenticated Application Information . . . . .  27
       8.2.  Errors  . . . . . . . . . . . . . . . . . . . . . . . . .  27
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  28
       9.1.  Security Properties . . . . . . . . . . . . . . . . . . .  28
         9.1.1.  Key-Compromise Impersonation  . . . . . . . . . . . .  29
         9.1.2.  Computational Analysis  . . . . . . . . . . . . . . .  30
         9.1.3.  Post-Quantum Security . . . . . . . . . . . . . . . .  32
       9.2.  Security Requirements on a KEM Used within HPKE . . . . .  33
         9.2.1.  Encap/Decap Interface . . . . . . . . . . . . . . . .  33
         9.2.2.  AuthEncap/AuthDecap Interface . . . . . . . . . . . .  33
         9.2.3.  KEM Key Reuse . . . . . . . . . . . . . . . . . . . .  34
       9.3.  Security Requirements on a KDF  . . . . . . . . . . . . .  34
       9.4.  Security Requirements on an AEAD  . . . . . . . . . . . .  34
       9.5.  Pre-Shared Key Recommendations  . . . . . . . . . . . . .  34
       9.6.  Domain Separation . . . . . . . . . . . . . . . . . . . .  35
       9.7.  Application Embedding and Non-Goals . . . . . . . . . . .  36
         9.7.1.  Message Order and Message Loss  . . . . . . . . . . .  36
         9.7.2.  Downgrade Prevention  . . . . . . . . . . . . . . . .  37
         9.7.3.  Replay Protection . . . . . . . . . . . . . . . . . .  37
         9.7.4.  Forward Secrecy . . . . . . . . . . . . . . . . . . .  37
         9.7.5.  Bad Ephemeral Randomness  . . . . . . . . . . . . . .  37
         9.7.6.  Hiding Plaintext Length . . . . . . . . . . . . . . .  38
       9.8.  Bidirectional Encryption  . . . . . . . . . . . . . . . .  38
       9.9.  Metadata Protection . . . . . . . . . . . . . . . . . . .  38
     10. Message Encoding  . . . . . . . . . . . . . . . . . . . . . .  39
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  39
       11.1.  KEM Identifiers  . . . . . . . . . . . . . . . . . . . .  40
       11.2.  KDF Identifiers  . . . . . . . . . . . . . . . . . . . .  40
       11.3.  AEAD Identifiers . . . . . . . . . . . . . . . . . . . .  41
     12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  41
       12.1.  Normative References . . . . . . . . . . . . . . . . . .  41
       12.2.  Informative References . . . . . . . . . . . . . . . . .  42
     Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  45
     Appendix B.  Test Vectors . . . . . . . . . . . . . . . . . . . .  45
       B.1.  DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, AES-128-GCM  . .  46
         B.1.1.  Base Setup Information  . . . . . . . . . . . . . . .  46
         B.1.2.  PSK Setup Information . . . . . . . . . . . . . . . .  49
         B.1.3.  Auth Setup Information  . . . . . . . . . . . . . . .  52
         B.1.4.  AuthPSK Setup Information . . . . . . . . . . . . . .  55
       B.2.  DHKEM(X25519, HKDF-SHA256), HKDF-SHA256,
             ChaCha20Poly1305  . . . . . . . . . . . . . . . . . . . .  58
         B.2.1.  Base Setup Information  . . . . . . . . . . . . . . .  58
         B.2.2.  PSK Setup Information . . . . . . . . . . . . . . . .  61
         B.2.3.  Auth Setup Information  . . . . . . . . . . . . . . .  64



  Barnes, et al.          Expires 21 September 2025               [Page 3]


  Internet-Draft                    HPKE                        March 2025


         B.2.4.  AuthPSK Setup Information . . . . . . . . . . . . . .  67
       B.3.  DHKEM(P-256, HKDF-SHA256), HKDF-SHA256, AES-128-GCM . . .  70
         B.3.1.  Base Setup Information  . . . . . . . . . . . . . . .  70
         B.3.2.  PSK Setup Information . . . . . . . . . . . . . . . .  73
         B.3.3.  Auth Setup Information  . . . . . . . . . . . . . . .  76
         B.3.4.  AuthPSK Setup Information . . . . . . . . . . . . . .  79
       B.4.  DHKEM(P-256, HKDF-SHA256), HKDF-SHA512, AES-128-GCM . . .  82
         B.4.1.  Base Setup Information  . . . . . . . . . . . . . . .  82
         B.4.2.  PSK Setup Information . . . . . . . . . . . . . . . .  85
         B.4.3.  Auth Setup Information  . . . . . . . . . . . . . . .  88
         B.4.4.  AuthPSK Setup Information . . . . . . . . . . . . . .  91
       B.5.  DHKEM(P-256, HKDF-SHA256), HKDF-SHA256,
             ChaCha20Poly1305  . . . . . . . . . . . . . . . . . . . .  94
         B.5.1.  Base Setup Information  . . . . . . . . . . . . . . .  94
         B.5.2.  PSK Setup Information . . . . . . . . . . . . . . . .  97
         B.5.3.  Auth Setup Information  . . . . . . . . . . . . . . . 100
         B.5.4.  AuthPSK Setup Information . . . . . . . . . . . . . . 103
       B.6.  DHKEM(P-521, HKDF-SHA512), HKDF-SHA512, AES-256-GCM . . . 106
         B.6.1.  Base Setup Information  . . . . . . . . . . . . . . . 106
         B.6.2.  PSK Setup Information . . . . . . . . . . . . . . . . 109
         B.6.3.  Auth Setup Information  . . . . . . . . . . . . . . . 112
         B.6.4.  AuthPSK Setup Information . . . . . . . . . . . . . . 115
       B.7.  DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, Export-Only
             AEAD  . . . . . . . . . . . . . . . . . . . . . . . . . . 118
         B.7.1.  Base Setup Information  . . . . . . . . . . . . . . . 118
         B.7.2.  PSK Setup Information . . . . . . . . . . . . . . . . 120
         B.7.3.  Auth Setup Information  . . . . . . . . . . . . . . . 121
         B.7.4.  AuthPSK Setup Information . . . . . . . . . . . . . . 123
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 125

  1.  Introduction

     Encryption schemes that combine asymmetric and symmetric algorithms
     have been specified and practiced since the early days of public key
     cryptography, e.g., [RFC1421].  Combining the two yields the key
     management advantages of asymmetric cryptography and the performance
     benefits of symmetric cryptography.  The traditional combination has
     been "encrypt the symmetric key with the public key."  "Hybrid"
     public key encryption (HPKE) schemes, specified here, take a
     different approach: "generate the symmetric key and its encapsulation
     with the public key."  Specifically, encrypted messages convey an
     encryption key encapsulated with a public key scheme, along with one
     or more arbitrary-sized ciphertexts encrypted using that key.  This
     type of public key encryption has many applications in practice,
     including Messaging Layer Security [I-D.ietf-mls-protocol] and TLS
     Encrypted ClientHello [I-D.ietf-tls-esni].





  Barnes, et al.          Expires 21 September 2025               [Page 4]


  Internet-Draft                    HPKE                        March 2025


     Currently, there are numerous competing and non-interoperable
     standards and variants for hybrid encryption, mostly variants on the
     Elliptic Curve Integrated Encryption Scheme (ECIES), including ANSI
     X9.63 (ECIES) [ANSI], IEEE 1363a [IEEE1363], ISO/IEC 18033-2 [ISO],
     and SECG SEC 1 [SECG].  See [MAEA10] for a thorough comparison.  All
     these existing schemes have problems, e.g., because they rely on
     outdated primitives, lack proofs of indistinguishable (adaptive)
     chosen-ciphertext attack (IND-CCA2) security, or fail to provide test
     vectors.

     This document defines an HPKE scheme that provides a subset of the
     functions provided by the collection of schemes above but specified
     with sufficient clarity that they can be interoperably implemented.
     The HPKE construction defined herein is secure against (adaptive)
     chosen ciphertext attacks (IND-CCA2-secure) under classical
     assumptions about the underlying primitives [HPKEAnalysis]
     [ABHKLR20].  A summary of these analyses is in Section 9.1.

     This document represents the consensus of the Crypto Forum Research
     Group (CFRG).

  2.  Requirements Notation

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  3.  Notation

     The following terms are used throughout this document to describe the
     operations, roles, and behaviors of HPKE:

     *  (skX, pkX): A key encapsulation mechanism (KEM) key pair used in
        role X, where X is one of S, R, or E as sender, recipient, and
        ephemeral, respectively; skX is the private key and pkX is the
        public key.

     *  pk(skX): The KEM public key corresponding to the KEM private key
        skX.

     *  Sender (S): Role of entity that sends an encrypted message.

     *  Recipient (R): Role of entity that receives an encrypted message.

     *  Ephemeral (E): Role of a fresh random value meant for one-time
        use.



  Barnes, et al.          Expires 21 September 2025               [Page 5]


  Internet-Draft                    HPKE                        March 2025


     *  I2OSP(n, w): Convert non-negative integer n to a w-length, big-
        endian byte string, as described in [RFC8017].

     *  OS2IP(x): Convert byte string x to a non-negative integer, as
        described in [RFC8017], assuming big-endian byte order.

     *  concat(x0, ..., xN): Concatenation of byte strings. concat(0x01,
        0x0203, 0x040506) = 0x010203040506.

     *  random(n): A pseudorandom byte string of length n bytes

     *  xor(a,b): XOR of byte strings; xor(0xF0F0, 0x1234) = 0xE2C4.  It
        is an error to call this function with two arguments of unequal
        length.

  4.  Cryptographic Dependencies

     HPKE variants rely on the following primitives:

     *  A key encapsulation mechanism (KEM):

        -  GenerateKeyPair(): Randomized algorithm to generate a key pair
           (skX, pkX).

        -  DeriveKeyPair(ikm): Deterministic algorithm to derive a key
           pair (skX, pkX) from the byte string ikm, where ikm SHOULD have
           at least Nsk bytes of entropy (see Section 7.1.3 for
           discussion).

        -  SerializePublicKey(pkX): Produce a byte string of length Npk
           encoding the public key pkX.

        -  DeserializePublicKey(pkXm): Parse a byte string of length Npk
           to recover a public key.  This function can raise a
           DeserializeError error upon pkXm deserialization failure.

        -  Encap(pkR): Randomized algorithm to generate an ephemeral,
           fixed-length symmetric key (the KEM shared secret) and a fixed-
           length encapsulation of that key that can be decapsulated by
           the holder of the private key corresponding to pkR.  This
           function can raise an EncapError on encapsulation failure.

        -  Decap(enc, skR): Deterministic algorithm using the private key
           skR to recover the ephemeral symmetric key (the KEM shared
           secret) from its encapsulated representation enc.  This
           function can raise a DecapError on decapsulation failure.





  Barnes, et al.          Expires 21 September 2025               [Page 6]


  Internet-Draft                    HPKE                        March 2025


        -  AuthEncap(pkR, skS) (optional): Same as Encap(), and the
           outputs encode an assurance that the KEM shared secret was
           generated by the holder of the private key skS.

        -  AuthDecap(enc, skR, pkS) (optional): Same as Decap(), and the
           recipient is assured that the KEM shared secret was generated
           by the holder of the private key skS.

        -  Nsecret: The length in bytes of a KEM shared secret produced by
           this KEM.

        -  Nenc: The length in bytes of an encapsulated key produced by
           this KEM.

        -  Npk: The length in bytes of an encoded public key for this KEM.

        -  Nsk: The length in bytes of an encoded private key for this
           KEM.

     *  A key derivation function (KDF):

        -  Extract(salt, ikm): Extract a pseudorandom key of fixed length
           Nh bytes from input keying material ikm and an optional byte
           string salt.

        -  Expand(prk, info, L): Expand a pseudorandom key prk using
           optional string info into L bytes of output keying material.

        -  Nh: The output size of the Extract() function in bytes.

     *  An AEAD encryption algorithm [RFC5116]:

        -  Seal(key, nonce, aad, pt): Encrypt and authenticate plaintext
           pt with associated data aad using symmetric key key and nonce
           nonce, yielding ciphertext and tag ct.  This function can raise
           a MessageLimitReachedError upon failure.

        -  Open(key, nonce, aad, ct): Decrypt ciphertext and tag ct using
           associated data aad with symmetric key key and nonce nonce,
           returning plaintext message pt.  This function can raise an
           OpenError or MessageLimitReachedError upon failure.

        -  Nk: The length in bytes of a key for this algorithm.

        -  Nn: The length in bytes of a nonce for this algorithm.

        -  Nt: The length in bytes of the authentication tag for this
           algorithm.



  Barnes, et al.          Expires 21 September 2025               [Page 7]


  Internet-Draft                    HPKE                        March 2025


     Beyond the above, a KEM MAY also expose the following functions,
     whose behavior is detailed in Section 7.1.2:

     *  SerializePrivateKey(skX): Produce a byte string of length Nsk
        encoding the private key skX.

     *  DeserializePrivateKey(skXm): Parse a byte string of length Nsk to
        recover a private key.  This function can raise a DeserializeError
        error upon skXm deserialization failure.

     A _ciphersuite_ is a triple (KEM, KDF, AEAD) containing a choice of
     algorithm for each primitive.

     A set of algorithm identifiers for concrete instantiations of these
     primitives is provided in Section 7.  Algorithm identifier values are
     two bytes long.

     Note that GenerateKeyPair can be implemented as
     DeriveKeyPair(random(Nsk)).

     The notation pk(skX), depending on its use and the KEM and its
     implementation, is either the computation of the public key using the
     private key, or just syntax expressing the retrieval of the public
     key, assuming it is stored along with the private key object.

     The following two functions are defined to facilitate domain
     separation of KDF calls as well as context binding:

     def LabeledExtract(salt, label, ikm):
       labeled_ikm = concat("HPKE-v1", suite_id, label, ikm)
       return Extract(salt, labeled_ikm)

     def LabeledExpand(prk, label, info, L):
       labeled_info = concat(I2OSP(L, 2), "HPKE-v1", suite_id,
                             label, info)
       return Expand(prk, labeled_info, L)

     The value of suite_id depends on where the KDF is used; it is assumed
     implicit from the implementation and not passed as a parameter.  If
     used inside a KEM algorithm, suite_id MUST start with "KEM" and
     identify this KEM algorithm; if used in the remainder of HPKE, it
     MUST start with "HPKE" and identify the entire ciphersuite in use.
     See sections Section 4.1 and Section 5.1 for details.

  4.1.  DH-Based KEM (DHKEM)

     Suppose we are given a KDF, and a Diffie-Hellman (DH) group providing
     the following operations:



  Barnes, et al.          Expires 21 September 2025               [Page 8]


  Internet-Draft                    HPKE                        March 2025


     *  DH(skX, pkY): Perform a non-interactive Diffie-Hellman exchange
        using the private key skX and public key pkY to produce a Diffie-
        Hellman shared secret of length Ndh. This function can raise a
        ValidationError as described in Section 7.1.4.

     *  Ndh: The length in bytes of a Diffie-Hellman shared secret
        produced by DH().

     *  Nsk: The length in bytes of a Diffie-Hellman private key.

     Then we can construct a KEM that implements the interface defined in
     Section 4 called DHKEM(Group, KDF) in the following way, where Group
     denotes the Diffie-Hellman group and KDF denotes the KDF.  The
     function parameters pkR and pkS are deserialized public keys, and enc
     is a serialized public key.  Since encapsulated keys are Diffie-
     Hellman public keys in this KEM algorithm, we use
     SerializePublicKey() and DeserializePublicKey() to encode and decode
     them, respectively.  Npk equals Nenc.  GenerateKeyPair() produces a
     key pair for the Diffie-Hellman group in use.  Section 7.1.3 contains
     the DeriveKeyPair() function specification for DHKEMs defined in this
     document.

     def ExtractAndExpand(dh, kem_context):
       eae_prk = LabeledExtract("", "eae_prk", dh)
       shared_secret = LabeledExpand(eae_prk, "shared_secret",
                                     kem_context, Nsecret)
       return shared_secret

     def Encap(pkR):
       skE, pkE = GenerateKeyPair()
       dh = DH(skE, pkR)
       enc = SerializePublicKey(pkE)

       pkRm = SerializePublicKey(pkR)
       kem_context = concat(enc, pkRm)

       shared_secret = ExtractAndExpand(dh, kem_context)
       return shared_secret, enc

     def Decap(enc, skR):
       pkE = DeserializePublicKey(enc)
       dh = DH(skR, pkE)

       pkRm = SerializePublicKey(pk(skR))
       kem_context = concat(enc, pkRm)

       shared_secret = ExtractAndExpand(dh, kem_context)
       return shared_secret



  Barnes, et al.          Expires 21 September 2025               [Page 9]


  Internet-Draft                    HPKE                        March 2025


     def AuthEncap(pkR, skS):
       skE, pkE = GenerateKeyPair()
       dh = concat(DH(skE, pkR), DH(skS, pkR))
       enc = SerializePublicKey(pkE)

       pkRm = SerializePublicKey(pkR)
       pkSm = SerializePublicKey(pk(skS))
       kem_context = concat(enc, pkRm, pkSm)

       shared_secret = ExtractAndExpand(dh, kem_context)
       return shared_secret, enc

     def AuthDecap(enc, skR, pkS):
       pkE = DeserializePublicKey(enc)
       dh = concat(DH(skR, pkE), DH(skR, pkS))

       pkRm = SerializePublicKey(pk(skR))
       pkSm = SerializePublicKey(pkS)
       kem_context = concat(enc, pkRm, pkSm)

       shared_secret = ExtractAndExpand(dh, kem_context)
       return shared_secret

     The implicit suite_id value used within LabeledExtract and
     LabeledExpand is defined as follows, where kem_id is defined in
     Section 7.1:

     suite_id = concat("KEM", I2OSP(kem_id, 2))

     The KDF used in DHKEM can be equal to or different from the KDF used
     in the remainder of HPKE, depending on the chosen variant.
     Implementations MUST make sure to use the constants (Nh) and function
     calls (LabeledExtract and LabeledExpand) of the appropriate KDF when
     implementing DHKEM.  See Section 9.3 for a comment on the choice of a
     KDF for the remainder of HPKE, and Section 9.6 for the rationale of
     the labels.

     For the variants of DHKEM defined in this document, the size Nsecret
     of the KEM shared secret is equal to the output length of the hash
     function underlying the KDF.  For P-256, P-384, and P-521, the size
     Ndh of the Diffie-Hellman shared secret is equal to 32, 48, and 66,
     respectively, corresponding to the x-coordinate of the resulting
     elliptic curve point [IEEE1363].  For X25519 and X448, the size Ndh
     is equal to 32 and 56, respectively (see [RFC7748], Section 5).

     It is important to note that the AuthEncap() and AuthDecap()
     functions of the DHKEM variants defined in this document are
     vulnerable to key-compromise impersonation (KCI).  This means the



  Barnes, et al.          Expires 21 September 2025              [Page 10]


  Internet-Draft                    HPKE                        March 2025


     assurance that the KEM shared secret was generated by the holder of
     the private key skS does not hold if the recipient private key skR is
     compromised.  See Section 9.1 for more details.

     Senders and recipients MUST validate KEM inputs and outputs as
     described in Section 7.1.

  5.  Hybrid Public Key Encryption

     In this section, we define a few HPKE variants.  All variants take a
     recipient public key and a sequence of plaintexts pt and produce an
     encapsulated key enc and a sequence of ciphertexts ct.  These outputs
     are constructed so that only the holder of skR can decapsulate the
     key from enc and decrypt the ciphertexts.  All the algorithms also
     take an info parameter that can be used to influence the generation
     of keys (e.g., to fold in identity information) and an aad parameter
     that provides additional authenticated data to the AEAD algorithm in
     use.

     In addition to the base case of encrypting to a public key, we
     include three authenticated variants: one that authenticates
     possession of a pre-shared key, one that authenticates possession of
     a KEM private key, and one that authenticates possession of both a
     pre-shared key and a KEM private key.  All authenticated variants
     contribute additional keying material to the encryption operation.
     The following one-byte values will be used to distinguish between
     modes:

                           +===============+=======+
                           | Mode          | Value |
                           +===============+=======+
                           | mode_base     | 0x00  |
                           +---------------+-------+
                           | mode_psk      | 0x01  |
                           +---------------+-------+
                           | mode_auth     | 0x02  |
                           +---------------+-------+
                           | mode_auth_psk | 0x03  |
                           +---------------+-------+

                              Table 1: HPKE Modes

     All these cases follow the same basic two-step pattern:

     1.  Set up an encryption context that is shared between the sender
         and the recipient.

     2.  Use that context to encrypt or decrypt content.



  Barnes, et al.          Expires 21 September 2025              [Page 11]


  Internet-Draft                    HPKE                        March 2025


     A _context_ is an implementation-specific structure that encodes the
     AEAD algorithm and key in use, and manages the nonces used so that
     the same nonce is not used with multiple plaintexts.  It also has an
     interface for exporting secret values, as described in Section 5.3.
     See Section 5.2 for a description of this structure and its
     interfaces.  HPKE decryption fails when the underlying AEAD
     decryption fails.

     The constructions described here presume that the relevant non-
     private parameters (enc, psk_id, etc.) are transported between the
     sender and the recipient by some application making use of HPKE.
     Moreover, a recipient with more than one public key needs some way of
     determining which of its public keys was used for the encapsulation
     operation.  As an example, applications may send this information
     alongside a ciphertext from the sender to the recipient.
     Specification of such a mechanism is left to the application.  See
     Section 10 for more details.

     Note that some KEMs may not support AuthEncap() or AuthDecap().  For
     such KEMs, only mode_base or mode_psk are supported.  Future
     specifications which define new KEMs MUST indicate whether these
     modes are supported.  See Section 7.1.5 for more details.

     The procedures described in this section are laid out in a Python-
     like pseudocode.  The algorithms in use are left implicit.

  5.1.  Creating the Encryption Context

     The variants of HPKE defined in this document share a common key
     schedule that translates the protocol inputs into an encryption
     context.  The key schedule inputs are as follows:

     *  mode - A one-byte value indicating the HPKE mode, defined in
        Table 1.

     *  shared_secret - A KEM shared secret generated for this
        transaction.

     *  info - Application-supplied information (optional; default value
        "").

     *  psk - A pre-shared key (PSK) held by both the sender and the
        recipient (optional; default value "").

     *  psk_id - An identifier for the PSK (optional; default value "").

     Senders and recipients MUST validate KEM inputs and outputs as
     described in Section 7.1.



  Barnes, et al.          Expires 21 September 2025              [Page 12]


  Internet-Draft                    HPKE                        March 2025


     The psk and psk_id fields MUST appear together or not at all.  That
     is, if a non-default value is provided for one of them, then the
     other MUST be set to a non-default value.  This requirement is
     encoded in VerifyPSKInputs() below.

     The psk, psk_id, and info fields have maximum lengths that depend on
     the KDF itself, on the definition of LabeledExtract(), and on the
     constant labels used together with them.  See Section 7.2.1 for
     precise limits on these lengths.

     The key, base_nonce, and exporter_secret computed by the key schedule
     have the property that they are only known to the holder of the
     recipient private key, and the entity that used the KEM to generate
     shared_secret and enc.

     In the Auth and AuthPSK modes, the recipient is assured that the
     sender held the private key skS.  This assurance is limited for the
     DHKEM variants defined in this document because of key-compromise
     impersonation, as described in Section 4.1 and Section 9.1.  If in
     the PSK and AuthPSK modes, the psk and psk_id arguments are provided
     as required, then the recipient is assured that the sender held the
     corresponding pre-shared key.  See Section 9.1 for more details.

     The HPKE algorithm identifiers, i.e., the KEM kem_id, KDF kdf_id, and
     AEAD aead_id 2-byte code points, as defined in Table 2, Table 3, and
     Table 5, respectively, are assumed implicit from the implementation
     and not passed as parameters.  The implicit suite_id value used
     within LabeledExtract and LabeledExpand is defined based on them as
     follows:

     suite_id = concat(
       "HPKE",
       I2OSP(kem_id, 2),
       I2OSP(kdf_id, 2),
       I2OSP(aead_id, 2)
     )















  Barnes, et al.          Expires 21 September 2025              [Page 13]


  Internet-Draft                    HPKE                        March 2025


     default_psk = ""
     default_psk_id = ""

     def VerifyPSKInputs(mode, psk, psk_id):
       got_psk = (psk != default_psk)
       got_psk_id = (psk_id != default_psk_id)
       if got_psk != got_psk_id:
         raise Exception("Inconsistent PSK inputs")

       if got_psk and (mode in [mode_base, mode_auth]):
         raise Exception("PSK input provided when not needed")
       if (not got_psk) and (mode in [mode_psk, mode_auth_psk]):
         raise Exception("Missing required PSK input")

     def KeySchedule<ROLE>(mode, shared_secret, info, psk, psk_id):
       VerifyPSKInputs(mode, psk, psk_id)

       psk_id_hash = LabeledExtract("", "psk_id_hash", psk_id)
       info_hash = LabeledExtract("", "info_hash", info)
       key_schedule_context = concat(mode, psk_id_hash, info_hash)

       secret = LabeledExtract(shared_secret, "secret", psk)

       key = LabeledExpand(secret, "key", key_schedule_context, Nk)
       base_nonce = LabeledExpand(secret, "base_nonce",
                                  key_schedule_context, Nn)
       exporter_secret = LabeledExpand(secret, "exp",
                                       key_schedule_context, Nh)

       return Context<ROLE>(key, base_nonce, 0, exporter_secret)

     The ROLE template parameter is either S or R, depending on the role
     of sender or recipient, respectively.  See Section 5.2 for a
     discussion of the key schedule output, including the role-specific
     Context structure and its API.

     Note that the key_schedule_context construction in KeySchedule() is
     equivalent to serializing a structure of the following form in the
     TLS presentation syntax:

     struct {
         uint8 mode;
         opaque psk_id_hash[Nh];
         opaque info_hash[Nh];
     } KeyScheduleContext;






  Barnes, et al.          Expires 21 September 2025              [Page 14]


  Internet-Draft                    HPKE                        March 2025


  5.1.1.  Encryption to a Public Key

     The most basic function of an HPKE scheme is to enable encryption to
     the holder of a given KEM private key.  The SetupBaseS() and
     SetupBaseR() procedures establish contexts that can be used to
     encrypt and decrypt, respectively, for a given private key.

     The KEM shared secret is combined via the KDF with information
     describing the key exchange, as well as the explicit info parameter
     provided by the caller.

     The parameter pkR is a public key, and enc is an encapsulated KEM
     shared secret.

     def SetupBaseS(pkR, info):
       shared_secret, enc = Encap(pkR)
       return enc, KeyScheduleS(mode_base, shared_secret, info,
                                default_psk, default_psk_id)

     def SetupBaseR(enc, skR, info):
       shared_secret = Decap(enc, skR)
       return KeyScheduleR(mode_base, shared_secret, info,
                           default_psk, default_psk_id)

  5.1.2.  Authentication Using a Pre-Shared Key

     This variant extends the base mechanism by allowing the recipient to
     authenticate that the sender possessed a given PSK.  The PSK also
     improves confidentiality guarantees in certain adversary models, as
     described in more detail in Section 9.1.  We assume that both parties
     have been provisioned with both the PSK value psk and another byte
     string psk_id that is used to identify which PSK should be used.

     The primary difference from the base case is that the psk and psk_id
     values are used as ikm inputs to the KDF (instead of using the empty
     string).

     The PSK MUST have at least 32 bytes of entropy and SHOULD be of
     length Nh bytes or longer.  See Section 9.5 for a more detailed
     discussion.

    def SetupPSKS(pkR, info, psk, psk_id):
      shared_secret, enc = Encap(pkR)
      return enc, KeyScheduleS(mode_psk, shared_secret, info, psk, psk_id)

    def SetupPSKR(enc, skR, info, psk, psk_id):
      shared_secret = Decap(enc, skR)
      return KeyScheduleR(mode_psk, shared_secret, info, psk, psk_id)



  Barnes, et al.          Expires 21 September 2025              [Page 15]


  Internet-Draft                    HPKE                        March 2025


  5.1.3.  Authentication Using an Asymmetric Key

     This variant extends the base mechanism by allowing the recipient to
     authenticate that the sender possessed a given KEM private key.  This
     is because AuthDecap(enc, skR, pkS) produces the correct KEM shared
     secret only if the encapsulated value enc was produced by
     AuthEncap(pkR, skS), where skS is the private key corresponding to
     pkS.  In other words, at most two entities (precisely two, in the
     case of DHKEM) could have produced this secret, so if the recipient
     is at most one, then the sender is the other with overwhelming
     probability.

     The primary difference from the base case is that the calls to
     Encap() and Decap() are replaced with calls to AuthEncap() and
     AuthDecap(), which add the sender public key to their internal
     context string.  The function parameters pkR and pkS are public keys,
     and enc is an encapsulated KEM shared secret.

     Obviously, this variant can only be used with a KEM that provides
     AuthEncap() and AuthDecap() procedures.

     This mechanism authenticates only the key pair of the sender, not any
     other identifier.  If an application wishes to bind HPKE ciphertexts
     or exported secrets to another identity for the sender (e.g., an
     email address or domain name), then this identifier should be
     included in the info parameter to avoid identity misbinding issues
     [IMB].

     def SetupAuthS(pkR, info, skS):
       shared_secret, enc = AuthEncap(pkR, skS)
       return enc, KeyScheduleS(mode_auth, shared_secret, info,
                                default_psk, default_psk_id)

     def SetupAuthR(enc, skR, info, pkS):
       shared_secret = AuthDecap(enc, skR, pkS)
       return KeyScheduleR(mode_auth, shared_secret, info,
                           default_psk, default_psk_id)

  5.1.4.  Authentication Using Both a PSK and an Asymmetric Key

     This mode is a straightforward combination of the PSK and
     authenticated modes.  Like the PSK mode, a PSK is provided as input
     to the key schedule, and like the authenticated mode, authenticated
     KEM variants are used.







  Barnes, et al.          Expires 21 September 2025              [Page 16]


  Internet-Draft                    HPKE                        March 2025


     def SetupAuthPSKS(pkR, info, psk, psk_id, skS):
       shared_secret, enc = AuthEncap(pkR, skS)
       return enc, KeyScheduleS(mode_auth_psk, shared_secret, info,
                                psk, psk_id)

     def SetupAuthPSKR(enc, skR, info, psk, psk_id, pkS):
       shared_secret = AuthDecap(enc, skR, pkS)
       return KeyScheduleR(mode_auth_psk, shared_secret, info,
                           psk, psk_id)

     The PSK MUST have at least 32 bytes of entropy and SHOULD be of
     length Nh bytes or longer.  See Section 9.5 for a more detailed
     discussion.

  5.2.  Encryption and Decryption

     HPKE allows multiple encryption operations to be done based on a
     given setup transaction.  Since the public key operations involved in
     setup are typically more expensive than symmetric encryption or
     decryption, this allows applications to amortize the cost of the
     public key operations, reducing the overall overhead.

     In order to avoid nonce reuse, however, this encryption must be
     stateful.  Each of the setup procedures above produces a role-
     specific context object that stores the AEAD and secret export
     parameters.  The AEAD parameters consist of:

     *  The AEAD algorithm in use

     *  A secret key

     *  A base nonce base_nonce

     *  A sequence number (initially 0)

     The secret export parameters consist of:

     *  The HPKE ciphersuite in use and

     *  An exporter_secret used for the secret export interface (see
        Section 5.3)

     All these parameters except the AEAD sequence number are constant.
     The sequence number provides nonce uniqueness: The nonce used for
     each encryption or decryption operation is the result of XORing
     base_nonce with the current sequence number, encoded as a big-endian
     integer of the same length as base_nonce.  Implementations MAY use a
     sequence number that is shorter than the nonce length (padding on the



  Barnes, et al.          Expires 21 September 2025              [Page 17]


  Internet-Draft                    HPKE                        March 2025


     left with zero), but MUST raise an error if the sequence number
     overflows.  The AEAD algorithm produces ciphertext that is Nt bytes
     longer than the plaintext.  Nt = 16 for AEAD algorithms defined in
     this document.

     Encryption is unidirectional from sender to recipient.  The sender's
     context can encrypt a plaintext pt with associated data aad as
     follows:

     def ContextS.Seal(aad, pt):
       ct = Seal(self.key, self.ComputeNonce(self.seq), aad, pt)
       self.IncrementSeq()
       return ct

     The recipient's context can decrypt a ciphertext ct with associated
     data aad as follows:

     def ContextR.Open(aad, ct):
       pt = Open(self.key, self.ComputeNonce(self.seq), aad, ct)
       if pt == OpenError:
         raise OpenError
       self.IncrementSeq()
       return pt

     Each encryption or decryption operation increments the sequence
     number for the context in use.  The per-message nonce and sequence
     number increment details are as follows:

     def Context<ROLE>.ComputeNonce(seq):
       seq_bytes = I2OSP(seq, Nn)
       return xor(self.base_nonce, seq_bytes)

     def Context<ROLE>.IncrementSeq():
       if self.seq >= (1 << (8*Nn)) - 1:
         raise MessageLimitReachedError
       self.seq += 1

     The sender's context MUST NOT be used for decryption.  Similarly, the
     recipient's context MUST NOT be used for encryption.  Higher-level
     protocols reusing the HPKE key exchange for more general purposes can
     derive separate keying material as needed using use the secret export
     interface; see Section 5.3 and Section 9.8 for more details.

     It is up to the application to ensure that encryptions and
     decryptions are done in the proper sequence, so that encryption and
     decryption nonces align.  If ContextS.Seal() or ContextR.Open() would
     cause the seq field to overflow, then the implementation MUST fail
     with an error.  (In the pseudocode below,



  Barnes, et al.          Expires 21 September 2025              [Page 18]


  Internet-Draft                    HPKE                        March 2025


     Context<ROLE>.IncrementSeq() fails with an error when seq overflows,
     which causes ContextS.Seal() and ContextR.Open() to fail
     accordingly.)  Note that the internal Seal() and Open() calls inside
     correspond to the context's AEAD algorithm.

  5.3.  Secret Export

     HPKE provides an interface for exporting secrets from the encryption
     context using a variable-length pseudorandom function (PRF), similar
     to the TLS 1.3 exporter interface (see [RFC8446], Section 7.5).  This
     interface takes as input a context string exporter_context and a
     desired length L in bytes, and produces a secret derived from the
     internal exporter secret using the corresponding KDF Expand function.
     For the KDFs defined in this specification, L has a maximum value of
     255*Nh.  Future specifications that define new KDFs MUST specify a
     bound for L.

     The exporter_context field has a maximum length that depends on the
     KDF itself, on the definition of LabeledExpand(), and on the constant
     labels used together with them.  See Section 7.2.1 for precise limits
     on this length.

     def Context.Export(exporter_context, L):
       return LabeledExpand(self.exporter_secret, "sec",
                            exporter_context, L)

     Applications that do not use the encryption API in Section 5.2 can
     use the export-only AEAD ID 0xFFFF when computing the key schedule.
     Such applications can avoid computing the key and base_nonce values
     in the key schedule, as they are not used by the Export interface
     described above.

  6.  Single-Shot APIs

  6.1.  Encryption and Decryption

     In many cases, applications encrypt only a single message to a
     recipient's public key.  This section provides templates for HPKE
     APIs that implement stateless "single-shot" encryption and decryption
     using APIs specified in Section 5.1.1 and Section 5.2:











  Barnes, et al.          Expires 21 September 2025              [Page 19]


  Internet-Draft                    HPKE                        March 2025


     def Seal<MODE>(pkR, info, aad, pt, ...):
       enc, ctx = Setup<MODE>S(pkR, info, ...)
       ct = ctx.Seal(aad, pt)
       return enc, ct

     def Open<MODE>(enc, skR, info, aad, ct, ...):
       ctx = Setup<MODE>R(enc, skR, info, ...)
       return ctx.Open(aad, ct)

     The MODE template parameter is one of Base, PSK, Auth, or AuthPSK.
     The optional parameters indicated by "..." depend on MODE and may be
     empty.  For example, SetupBase() has no additional parameters.
     SealAuthPSK() and OpenAuthPSK() would be implemented as follows:

     def SealAuthPSK(pkR, info, aad, pt, psk, psk_id, skS):
       enc, ctx = SetupAuthPSKS(pkR, info, psk, psk_id, skS)
       ct = ctx.Seal(aad, pt)
       return enc, ct

     def OpenAuthPSK(enc, skR, info, aad, ct, psk, psk_id, pkS):
       ctx = SetupAuthPSKR(enc, skR, info, psk, psk_id, pkS)
       return ctx.Open(aad, ct)

  6.2.  Secret Export

     Applications may also want to derive a secret known only to a given
     recipient.  This section provides templates for HPKE APIs that
     implement stateless "single-shot" secret export using APIs specified
     in Section 5.3:

     def SendExport<MODE>(pkR, info, exporter_context, L, ...):
       enc, ctx = Setup<MODE>S(pkR, info, ...)
       exported = ctx.Export(exporter_context, L)
       return enc, exported

     def ReceiveExport<MODE>(enc, skR, info, exporter_context, L, ...):
       ctx = Setup<MODE>R(enc, skR, info, ...)
       return ctx.Export(exporter_context, L)

     As in Section 6.1, the MODE template parameter is one of Base, PSK,
     Auth, or AuthPSK.  The optional parameters indicated by "..." depend
     on MODE and may be empty.









  Barnes, et al.          Expires 21 September 2025              [Page 20]


  Internet-Draft                    HPKE                        March 2025


  7.  Algorithm Identifiers

     This section lists algorithm identifiers suitable for different HPKE
     configurations.  Future specifications may introduce new KEM, KDF,
     and AEAD algorithm identifiers and retain the security guarantees
     presented in this document provided they adhere to the security
     requirements in Section 9.2, Section 9.3, and Section 9.4,
     respectively.

  7.1.  Key Encapsulation Mechanisms (KEMs)

     +======+===============+=========+====+===+===+====+===============+
     |Value | KEM           | Nsecret |Nenc|Npk|Nsk|Auth| Reference     |
     +======+===============+=========+====+===+===+====+===============+
     |0x0000| Reserved      | N/A     |N/A |N/A|N/A|yes | RFC 9180      |
     +------+---------------+---------+----+---+---+----+---------------+
     |0x0010| DHKEM(P-256,  | 32      |65  |65 |32 |yes | [NISTCurves], |
     |      | HKDF-SHA256)  |         |    |   |   |    | [RFC5869]     |
     +------+---------------+---------+----+---+---+----+---------------+
     |0x0011| DHKEM(P-384,  | 48      |97  |97 |48 |yes | [NISTCurves], |
     |      | HKDF-SHA384)  |         |    |   |   |    | [RFC5869]     |
     +------+---------------+---------+----+---+---+----+---------------+
     |0x0012| DHKEM(P-521,  | 64      |133 |133|66 |yes | [NISTCurves], |
     |      | HKDF-SHA512)  |         |    |   |   |    | [RFC5869]     |
     +------+---------------+---------+----+---+---+----+---------------+
     |0x0020| DHKEM(X25519, | 32      |32  |32 |32 |yes | [RFC7748],    |
     |      | HKDF-SHA256)  |         |    |   |   |    | [RFC5869]     |
     +------+---------------+---------+----+---+---+----+---------------+
     |0x0021| DHKEM(X448,   | 64      |56  |56 |56 |yes | [RFC7748],    |
     |      | HKDF-SHA512)  |         |    |   |   |    | [RFC5869]     |
     +------+---------------+---------+----+---+---+----+---------------+

                               Table 2: KEM IDs

     The Auth column indicates if the KEM algorithm provides the
     AuthEncap()/AuthDecap() interface and is therefore suitable for the
     Auth and AuthPSK modes.  The meaning of all other columns is
     explained in Section 11.1.  All algorithms are suitable for the PSK
     mode.

  7.1.1.  SerializePublicKey and DeserializePublicKey

     For P-256, P-384, and P-521, the SerializePublicKey() function of the
     KEM performs the uncompressed Elliptic-Curve-Point-to-Octet-String
     conversion according to [SECG].  DeserializePublicKey() performs the
     uncompressed Octet-String-to-Elliptic-Curve-Point conversion.





  Barnes, et al.          Expires 21 September 2025              [Page 21]


  Internet-Draft                    HPKE                        March 2025


     For X25519 and X448, the SerializePublicKey() and
     DeserializePublicKey() functions are the identity function, since
     these curves already use fixed-length byte strings for public keys.

     Some deserialized public keys MUST be validated before they can be
     used.  See Section 7.1.4 for specifics.

  7.1.2.  SerializePrivateKey and DeserializePrivateKey

     As per [SECG], P-256, P-384, and P-521 private keys are field
     elements in the scalar field of the curve being used.  For this
     section, and for Section 7.1.3, it is assumed that implementors of
     ECDH over these curves use an integer representation of private keys
     that is compatible with the OS2IP() function.

     For P-256, P-384, and P-521, the SerializePrivateKey() function of
     the KEM performs the Field-Element-to-Octet-String conversion
     according to [SECG].  If the private key is an integer outside the
     range [0, order-1], where order is the order of the curve being used,
     the private key MUST be reduced to its representative in [0, order-1]
     before being serialized.  DeserializePrivateKey() performs the Octet-
     String-to-Field-Element conversion according to [SECG].

     For X25519 and X448, private keys are identical to their byte string
     representation, so little processing has to be done.  The
     SerializePrivateKey() function MUST clamp its output and the
     DeserializePrivateKey() function MUST clamp its input, where
     _clamping_ refers to the bitwise operations performed on k in the
     decodeScalar25519() and decodeScalar448() functions defined in
     Section 5 of [RFC7748].

     To catch invalid keys early on, implementors of DHKEMs SHOULD check
     that deserialized private keys are not equivalent to 0 (mod order),
     where order is the order of the DH group.  Note that this property is
     trivially true for X25519 and X448 groups, since clamped values can
     never be 0 (mod order).

  7.1.3.  DeriveKeyPair

     The keys that DeriveKeyPair() produces have only as much entropy as
     the provided input keying material.  For a given KEM, the ikm
     parameter given to DeriveKeyPair() SHOULD have length at least Nsk,
     and SHOULD have at least Nsk bytes of entropy.

     All invocations of KDF functions (such as LabeledExtract or
     LabeledExpand) in any DHKEM's DeriveKeyPair() function use the
     DHKEM's associated KDF (as opposed to the ciphersuite's KDF).




  Barnes, et al.          Expires 21 September 2025              [Page 22]


  Internet-Draft                    HPKE                        March 2025


     For P-256, P-384, and P-521, the DeriveKeyPair() function of the KEM
     performs rejection sampling over field elements:

     def DeriveKeyPair(ikm):
       dkp_prk = LabeledExtract("", "dkp_prk", ikm)
       sk = 0
       counter = 0
       while sk == 0 or sk >= order:
         if counter > 255:
           raise DeriveKeyPairError
         bytes = LabeledExpand(dkp_prk, "candidate",
                               I2OSP(counter, 1), Nsk)
         bytes[0] = bytes[0] & bitmask
         sk = OS2IP(bytes)
         counter = counter + 1
       return (sk, pk(sk))

     order is the order of the curve being used (see Section D.1.2 of
     [NISTCurves]), and is listed below for completeness.

     P-256:
     0xffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551

     P-384:
     0xffffffffffffffffffffffffffffffffffffffffffffffffc7634d81f4372ddf
       581a0db248b0a77aecec196accc52973

     P-521:
     0x01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
       fa51868783bf2f966b7fcc0148f709a5d03bb5c9b8899c47aebb6fb71e91386409

     bitmask is defined to be 0xFF for P-256 and P-384, and 0x01 for
     P-521.  The precise likelihood of DeriveKeyPair() failing with
     DeriveKeyPairError depends on the group being used, but it is
     negligibly small in all cases.  See Section 8.2 for information about
     dealing with such failures.

     For X25519 and X448, the DeriveKeyPair() function applies a KDF to
     the input:

     def DeriveKeyPair(ikm):
       dkp_prk = LabeledExtract("", "dkp_prk", ikm)
       sk = LabeledExpand(dkp_prk, "sk", "", Nsk)
       return (sk, pk(sk))







  Barnes, et al.          Expires 21 September 2025              [Page 23]


  Internet-Draft                    HPKE                        March 2025


  7.1.4.  Validation of Inputs and Outputs

     The following public keys are subject to validation if the group
     requires public key validation: the sender MUST validate the
     recipient's public key pkR; the recipient MUST validate the ephemeral
     public key pkE; in authenticated modes, the recipient MUST validate
     the sender's static public key pkS.  Validation failure yields a
     ValidationError.

     For P-256, P-384 and P-521, senders and recipients MUST perform
     partial public key validation on all public key inputs, as defined in
     Section 5.6.2.3.4 of [keyagreement].  This includes checking that the
     coordinates are in the correct range, that the point is on the curve,
     and that the point is not the point at infinity.  Additionally,
     senders and recipients MUST ensure the Diffie-Hellman shared secret
     is not the point at infinity.

     For X25519 and X448, public keys and Diffie-Hellman outputs MUST be
     validated as described in [RFC7748].  In particular, recipients MUST
     check whether the Diffie-Hellman shared secret is the all-zero value
     and abort if so.

  7.1.5.  Future KEMs

     Section 9.2 lists security requirements on a KEM used within HPKE.

     The AuthEncap() and AuthDecap() functions are OPTIONAL.  If a KEM
     algorithm does not provide them, only the Base and PSK modes of HPKE
     are supported.  Future specifications that define new KEMs MUST
     indicate whether or not Auth and AuthPSK modes are supported.

     A KEM algorithm may support different encoding algorithms, with
     different output lengths, for KEM public keys.  Such KEM algorithms
     MUST specify only one encoding algorithm whose output length is Npk.

  7.2.  Key Derivation Functions (KDFs)

                  +========+=============+=====+===========+
                  | Value  | KDF         | Nh  | Reference |
                  +========+=============+=====+===========+
                  | 0x0000 | Reserved    | N/A | RFC 9180  |
                  +--------+-------------+-----+-----------+
                  | 0x0001 | HKDF-SHA256 | 32  | [RFC5869] |
                  +--------+-------------+-----+-----------+
                  | 0x0002 | HKDF-SHA384 | 48  | [RFC5869] |
                  +--------+-------------+-----+-----------+
                  | 0x0003 | HKDF-SHA512 | 64  | [RFC5869] |
                  +--------+-------------+-----+-----------+



  Barnes, et al.          Expires 21 September 2025              [Page 24]


  Internet-Draft                    HPKE                        March 2025


                               Table 3: KDF IDs

  7.2.1.  Input Length Restrictions

     This document defines LabeledExtract() and LabeledExpand() based on
     the KDFs listed above.  These functions add prefixes to their
     respective inputs ikm and info before calling the KDF's Extract() and
     Expand() functions.  This leads to a reduction of the maximum input
     length that is available for the inputs psk, psk_id, info,
     exporter_context, ikm, i.e., the variable-length parameters provided
     by HPKE applications.  The following table lists the maximum allowed
     lengths of these fields for the KDFs defined in this document, as
     inclusive bounds in bytes:

      +==================+==============+===============+===============+
      | Input            | HKDF-SHA256  | HKDF-SHA384   | HKDF-SHA512   |
      +==================+==============+===============+===============+
      | psk              | 2^{61} - 88  | 2^{125} - 152 | 2^{125} - 152 |
      +------------------+--------------+---------------+---------------+
      | psk_id           | 2^{61} - 93  | 2^{125} - 157 | 2^{125} - 157 |
      +------------------+--------------+---------------+---------------+
      | info             | 2^{61} - 91  | 2^{125} - 155 | 2^{125} - 155 |
      +------------------+--------------+---------------+---------------+
      | exporter_context | 2^{61} - 120 | 2^{125} - 200 | 2^{125} - 216 |
      +------------------+--------------+---------------+---------------+
      | ikm              | 2^{61} - 84  | 2^{125} - 148 | 2^{125} - 148 |
      | (DeriveKeyPair)  |              |               |               |
      +------------------+--------------+---------------+---------------+

                       Table 4: Application Input Limits

     This shows that the limits are only marginally smaller than the
     maximum input length of the underlying hash function; these limits
     are large and unlikely to be reached in practical applications.
     Future specifications that define new KDFs MUST specify bounds for
     these variable-length parameters.

     The RECOMMENDED limit for these values is 64 bytes.  This would
     enable interoperability with implementations that statically allocate
     memory for these inputs to avoid memory allocations.

     The values for psk, psk_id, info, and ikm, which are inputs to
     LabeledExtract(), were computed with the following expression:

     max_size_hash_input - Nb - size_version_label -
         size_suite_id - size_input_label





  Barnes, et al.          Expires 21 September 2025              [Page 25]


  Internet-Draft                    HPKE                        March 2025


     The value for exporter_context, which is an input to LabeledExpand(),
     was computed with the following expression:

     max_size_hash_input - Nb - Nh - size_version_label -
         size_suite_id - size_input_label - 2 - 1

     In these equations, max_size_hash_input is the maximum input length
     of the underlying hash function in bytes, Nb is the block size of the
     underlying hash function in bytes, size_version_label is the size of
     "HPKE-v1" in bytes and equals 7, size_suite_id is the size of the
     suite_id in bytes and equals 5 for DHKEM (relevant for ikm) and 10
     for the remainder of HPKE (relevant for psk, psk_id, info, and
     exporter_context), and size_input_label is the size in bytes of the
     label used as parameter to LabeledExtract() or LabeledExpand(), the
     maximum of which is 13 across all labels in this document.

  7.3.  Authenticated Encryption with Associated Data (AEAD) Functions

          +========+==================+=====+=====+=====+===========+
          | Value  | AEAD             | Nk  | Nn  | Nt  | Reference |
          +========+==================+=====+=====+=====+===========+
          | 0x0000 | Reserved         | N/A | N/A | N/A | RFC 9180  |
          +--------+------------------+-----+-----+-----+-----------+
          | 0x0001 | AES-128-GCM      | 16  | 12  | 16  | [GCM]     |
          +--------+------------------+-----+-----+-----+-----------+
          | 0x0002 | AES-256-GCM      | 32  | 12  | 16  | [GCM]     |
          +--------+------------------+-----+-----+-----+-----------+
          | 0x0003 | ChaCha20Poly1305 | 32  | 12  | 16  | [RFC8439] |
          +--------+------------------+-----+-----+-----+-----------+
          | 0xFFFF | Export-only      | N/A | N/A | N/A | RFC 9180  |
          +--------+------------------+-----+-----+-----+-----------+

                               Table 5: AEAD IDs

     The 0xFFFF AEAD ID is reserved for applications that only use the
     Export interface; see Section 5.3 for more details.

  8.  API Considerations

     This section documents considerations for interfaces to
     implementations of HPKE.  This includes error handling considerations
     and recommendations that improve interoperability when HPKE is used
     in applications.








  Barnes, et al.          Expires 21 September 2025              [Page 26]


  Internet-Draft                    HPKE                        March 2025


  8.1.  Auxiliary Authenticated Application Information

     HPKE has two places at which applications can specify auxiliary
     authenticated information: (1) during context construction via the
     Setup info parameter, and (2) during Context operations, i.e., with
     the aad parameter for Open() and Seal(), and the exporter_context
     parameter for Export().  Application information applicable to
     multiple operations on a single Context should use the Setup info
     parameter.  This avoids redundantly processing this information for
     each Context operation.  In contrast, application information that
     varies on a per-message basis should be specified via the Context
     APIs (Seal(), Open(), or Export()).

     Applications that only use the single-shot APIs described in
     Section 6 should use the Setup info parameter for specifying
     auxiliary authenticated information.  Implementations which only
     expose single-shot APIs should not allow applications to use both
     Setup info and Context aad or exporter_context auxiliary information
     parameters.

  8.2.  Errors

     The high-level, public HPKE APIs specified in this document are all
     fallible.  These include the Setup functions and all encryption
     context functions.  For example, Decap() can fail if the encapsulated
     key enc is invalid, and Open() may fail if ciphertext decryption
     fails.  The explicit errors generated throughout this specification,
     along with the conditions that lead to each error, are as follows:

     *  ValidationError: KEM input or output validation failure;
        Section 4.1.

     *  DeserializeError: Public or private key deserialization failure;
        Section 4.

     *  EncapError: Encap() failure; Section 4.

     *  DecapError: Decap() failure; Section 4.

     *  OpenError: Context AEAD Open() failure; Section 4 and Section 5.2.

     *  MessageLimitReachedError: Context AEAD sequence number overflow;
        Section 4 and Section 5.2.

     *  DeriveKeyPairError: Key pair derivation failure; Section 7.1.3.






  Barnes, et al.          Expires 21 September 2025              [Page 27]


  Internet-Draft                    HPKE                        March 2025


     Implicit errors may also occur.  As an example, certain classes of
     failures, e.g., malformed recipient public keys, may not yield
     explicit errors.  For example, for the DHKEM variant described in
     this specification, the Encap() algorithm fails when given an invalid
     recipient public key.  However, other KEM algorithms may not have an
     efficient algorithm for verifying the validity of public keys.  As a
     result, an equivalent error may not manifest until AEAD decryption at
     the recipient.  As another example, DHKEM's AuthDecap() function will
     produce invalid output if given the wrong sender public key.  This
     error is not detectable until subsequent AEAD decryption.

     The errors in this document are meant as a guide for implementors.
     They are not an exhaustive list of all the errors an implementation
     might emit.  For example, future KEMs might have internal failure
     cases, or an implementation might run out of memory.

     How these errors are expressed in an API or handled by applications
     is an implementation-specific detail.  For example, some
     implementations may abort or panic upon a DeriveKeyPairError failure
     given that it only occurs with negligible probability, whereas other
     implementations may retry the failed DeriveKeyPair operation.  See
     Section 7.1.3 for more information.  As another example, some
     implementations of the DHKEM specified in this document may choose to
     transform ValidationError from DH() into an EncapError or DecapError
     from Encap() or Decap(), respectively, whereas others may choose to
     raise ValidationError unmodified.

     Applications using HPKE APIs should not assume that the errors here
     are complete, nor should they assume certain classes of errors will
     always manifest the same way for all ciphersuites.  For example, the
     DHKEM specified in this document will emit a DeserializationError or
     ValidationError if a KEM public key is invalid.  However, a new KEM
     might not have an efficient algorithm for determining whether or not
     a public key is valid.  In this case, an invalid public key might
     instead yield an OpenError when trying to decrypt a ciphertext.

  9.  Security Considerations

  9.1.  Security Properties

     HPKE has several security goals, depending on the mode of operation,
     against active and adaptive attackers that can compromise partial
     secrets of senders and recipients.  The desired security goals are
     detailed below:

     *  Message secrecy: Confidentiality of the sender's messages against
        chosen ciphertext attacks




  Barnes, et al.          Expires 21 September 2025              [Page 28]


  Internet-Draft                    HPKE                        March 2025


     *  Export key secrecy: Indistinguishability of each export secret
        from a uniformly random bitstring of equal length, i.e.,
        Context.Export is a variable-length PRF

     *  Sender authentication: Proof of sender origin for PSK, Auth, and
        AuthPSK modes

     These security goals are expected to hold for any honest sender and
     honest recipient keys, as well as if the honest sender and honest
     recipient keys are the same.

     HPKE mitigates malleability problems (called benign malleability
     [SECG]) in prior public key encryption standards based on ECIES by
     including all public keys in the context of the key schedule.

     HPKE does not provide forward secrecy with respect to recipient
     compromise.  In the Base and Auth modes, the secrecy properties are
     only expected to hold if the recipient private key skR is not
     compromised at any point in time.  In the PSK and AuthPSK modes, the
     secrecy properties are expected to hold if the recipient private key
     skR and the pre-shared key are not both compromised at any point in
     time.  See Section 9.7 for more details.

     In the Auth mode, sender authentication is generally expected to hold
     if the sender private key skS is not compromised at the time of
     message reception.  In the AuthPSK mode, sender authentication is
     generally expected to hold if, at the time of message reception, the
     sender private key skS and the pre-shared key are not both
     compromised.

     Besides forward secrecy and key-compromise impersonation, which are
     highlighted in this section because of their particular cryptographic
     importance, HPKE has other non-goals that are described in
     Section 9.7: no tolerance of message reordering or loss, no downgrade
     or replay prevention, no hiding of the plaintext length, and no
     protection against bad ephemeral randomness.  Section 9.7 suggests
     application-level mitigations for some of them.

  9.1.1.  Key-Compromise Impersonation

     The DHKEM variants defined in this document are vulnerable to key-
     compromise impersonation attacks [BJM97], which means that sender
     authentication cannot be expected to hold in the Auth mode if the
     recipient private key skR is compromised, and in the AuthPSK mode if
     the pre-shared key and the recipient private key skR are both
     compromised.  NaCl's box interface [NaCl] has the same issue.  At the
     same time, this enables repudiability.




  Barnes, et al.          Expires 21 September 2025              [Page 29]


  Internet-Draft                    HPKE                        March 2025


     As shown by [ABHKLR20], key-compromise impersonation attacks are
     generally possible on HPKE because KEM ciphertexts are not bound to
     HPKE messages.  An adversary who knows a recipient's private key can
     decapsulate an observed KEM ciphertext, compute the key schedule, and
     encrypt an arbitrary message that the recipient will accept as coming
     from the original sender.  Importantly, this is possible even with a
     KEM that is resistant to key-compromise impersonation attacks.  As a
     result, mitigating this issue requires fundamental changes that are
     out of scope of this specification.

     Applications that require resistance against key-compromise
     impersonation SHOULD take extra steps to prevent this attack.  One
     possibility is to produce a digital signature over (enc, ct) tuples
     using a sender's private key -- where ct is an AEAD ciphertext
     produced by the single-shot or multi-shot API and enc is the
     corresponding KEM encapsulated key.

     Given these properties, pre-shared keys strengthen both the
     authentication and the secrecy properties in certain adversary
     models.  One particular example in which this can be useful is a
     hybrid quantum setting: if a non-quantum-resistant KEM used with HPKE
     is broken by a quantum computer, the security properties are
     preserved through the use of a pre-shared key.  As described in
     Section 7 of [RFC8696] this assumes that the pre-shared key has not
     been compromised.

  9.1.2.  Computational Analysis

     It is shown in [CS01] that a hybrid public key encryption scheme of
     essentially the same form as the Base mode described here is IND-
     CCA2-secure as long as the underlying KEM and AEAD schemes are IND-
     CCA2-secure.  Moreover, it is shown in [HHK06] that IND-CCA2 security
     of the KEM and the data encapsulation mechanism are necessary
     conditions to achieve IND-CCA2 security for hybrid public key
     encryption.  The main difference between the scheme proposed in
     [CS01] and the Base mode in this document (both named HPKE) is that
     we interpose some KDF calls between the KEM and the AEAD.  Analyzing
     the HPKE Base mode instantiation in this document therefore requires
     verifying that the additional KDF calls do not cause the IND-CCA2
     property to fail, as well as verifying the additional export key
     secrecy property.










  Barnes, et al.          Expires 21 September 2025              [Page 30]


  Internet-Draft                    HPKE                        March 2025


     Analysis of the PSK, Auth, and AuthPSK modes defined in this document
     additionally requires verifying the sender authentication property.
     While the PSK mode just adds supplementary keying material to the key
     schedule, the Auth and AuthPSK modes make use of a non-standard
     authenticated KEM construction.  Generally, the authenticated modes
     of HPKE can be viewed and analyzed as flavors of signcryption
     [SigncryptionDZ10].

     A preliminary computational analysis of all HPKE modes has been done
     in [HPKEAnalysis], indicating asymptotic security for the case where
     the KEM is DHKEM, the AEAD is any IND-CPA-secure and INT-CTXT-secure
     scheme, and the DH group and KDF satisfy the following conditions:

     *  DH group: The gap Diffie-Hellman (GDH) problem is hard in the
        appropriate subgroup [GAP].

     *  Extract() and Expand(): Extract() can be modeled as a random
        oracle.  Expand() can be modeled as a pseudorandom function,
        wherein the first argument is the key.

     In particular, the KDFs and DH groups defined in this document (see
     Section 7.2 and Section 7.1) satisfy these properties when used as
     specified.  The analysis in [HPKEAnalysis] demonstrates that under
     these constraints, HPKE continues to provide IND-CCA2 security, and
     provides the additional properties noted above.  Also, the analysis
     confirms the expected properties hold under the different key
     compromise cases mentioned above.  The analysis considers a sender
     that sends one message using the encryption context, and additionally
     exports two independent secrets using the secret export interface.

     The table below summarizes the main results from [HPKEAnalysis].  N/A
     means that a property does not apply for the given mode, whereas Y
     means the given mode satisfies the property.

            +=========+==============+=============+==============+
            | Variant | Message Sec. | Export Sec. | Sender Auth. |
            +=========+==============+=============+==============+
            | Base    |      Y       |      Y      |     N/A      |
            +---------+--------------+-------------+--------------+
            | PSK     |      Y       |      Y      |      Y       |
            +---------+--------------+-------------+--------------+
            | Auth    |      Y       |      Y      |      Y       |
            +---------+--------------+-------------+--------------+
            | AuthPSK |      Y       |      Y      |      Y       |
            +---------+--------------+-------------+--------------+

                                    Table 6




  Barnes, et al.          Expires 21 September 2025              [Page 31]


  Internet-Draft                    HPKE                        March 2025


     If non-DH-based KEMs are to be used with HPKE, further analysis will
     be necessary to prove their security.  The results from [CS01]
     provide some indication that any IND-CCA2-secure KEM will suffice
     here, but are not conclusive given the differences in the schemes.

     A detailed computational analysis of HPKE's Auth mode single-shot
     encryption API has been done in [ABHKLR20].  The paper defines
     security notions for authenticated KEMs and for authenticated public
     key encryption, using the outsider and insider security terminology
     known from signcryption [SigncryptionDZ10].  The analysis proves that
     DHKEM's AuthEncap()/AuthDecap() interface fulfills these notions for
     all Diffie-Hellman groups specified in this document.  The analysis
     also provides exact security bounds, under the assumptions that the
     gap Diffie-Hellman (GDH) problem is hard in the appropriate subgroup
     [GAP], and that HKDF can be modeled as a random oracle.

     Further, [ABHKLR20] proves composition theorems, showing that HPKE's
     Auth mode fulfills the security notions of authenticated public key
     encryption for all KDFs and AEAD schemes specified in this document,
     given any authenticated KEM satisfying the previously defined
     security notions for authenticated KEMs.  The theorems assume that
     the KEM is perfectly correct; they could easily be adapted to work
     with KEMs that have a nonzero but negligible probability for
     decryption failure.  The assumptions on the KDF are that Extract()
     and Expand() can be modeled as pseudorandom functions wherein the
     first argument is the key, respectively.  The assumption for the AEAD
     is IND-CPA and IND-CTXT security.

     In summary, the analysis in [ABHKLR20] proves that the single-shot
     encryption API of HPKE's Auth mode satisfies the desired message
     confidentiality and sender authentication properties listed at the
     beginning of this section; it does not consider multiple messages,
     nor the secret export API.

  9.1.3.  Post-Quantum Security

     All of [CS01], [HPKEAnalysis], and [ABHKLR20] are premised on
     classical security models and assumptions, and do not consider
     adversaries capable of quantum computation.  A full proof of post-
     quantum security would need to take appropriate security models and
     assumptions into account, in addition to simply using a post-quantum
     KEM.  However, the composition theorems from [ABHKLR20] for HPKE's
     Auth mode only make standard assumptions (i.e., no random oracle
     assumption) that are expected to hold against quantum adversaries
     (although with slightly worse bounds).  Thus, these composition
     theorems, in combination with a post-quantum-secure authenticated
     KEM, guarantee the post-quantum security of HPKE's Auth mode.




  Barnes, et al.          Expires 21 September 2025              [Page 32]


  Internet-Draft                    HPKE                        March 2025


     In future work, the analysis from [ABHKLR20] can be extended to cover
     HPKE's other modes and desired security properties.  The hybrid
     quantum-resistance property described above, which is achieved by
     using the PSK or AuthPSK mode, is not proven in [HPKEAnalysis]
     because this analysis requires the random oracle model; in a quantum
     setting, this model needs adaption to, for example, the quantum
     random oracle model.

  9.2.  Security Requirements on a KEM Used within HPKE

     A KEM used within HPKE MUST allow HPKE to satisfy its desired
     security properties described in Section 9.1.  Section 9.6 lists
     requirements concerning domain separation.

     In particular, the KEM shared secret MUST be a uniformly random byte
     string of length Nsecret.  This means, for instance, that it would
     not be sufficient if the KEM shared secret is only uniformly random
     as an element of some set prior to its encoding as a byte string.

  9.2.1.  Encap/Decap Interface

     As mentioned in Section 9, [CS01] provides some indications that if
     the KEM's Encap()/Decap() interface (which is used in the Base and
     PSK modes) is IND-CCA2-secure, HPKE is able to satisfy its desired
     security properties.  An appropriate definition of IND-CCA2 security
     for KEMs can be found in [CS01] and [BHK09].

  9.2.2.  AuthEncap/AuthDecap Interface

     The analysis of HPKE's Auth mode single-shot encryption API in
     [ABHKLR20] provides composition theorems that guarantee that HPKE's
     Auth mode achieves its desired security properties if the KEM's
     AuthEncap()/AuthDecap() interface satisfies multi-user Outsider-CCA,
     Outsider-Auth, and Insider-CCA security, as defined in the same
     paper.

     Intuitively, Outsider-CCA security formalizes confidentiality, and
     Outsider-Auth security formalizes authentication of the KEM shared
     secret in case none of the sender or recipient private keys are
     compromised.  Insider-CCA security formalizes confidentiality of the
     KEM shared secret in case the sender private key is known or chosen
     by the adversary.  (If the recipient private key is known or chosen
     by the adversary, confidentiality is trivially broken, because then
     the adversary knows all secrets on the recipient's side).

     An Insider-Auth security notion would formalize authentication of the
     KEM shared secret in case the recipient private key is known or
     chosen by the adversary.  (If the sender private key is known or



  Barnes, et al.          Expires 21 September 2025              [Page 33]


  Internet-Draft                    HPKE                        March 2025


     chosen by the adversary, it can create KEM ciphertexts in the name of
     the sender).  Because of the generic attack on an analogous Insider-
     Auth security notion of HPKE described in Section 9.1, a definition
     of Insider-Auth security for KEMs used within HPKE is not useful.

  9.2.3.  KEM Key Reuse

     An ikm input to DeriveKeyPair() (Section 7.1.3) MUST NOT be reused
     elsewhere, in particular not with DeriveKeyPair() of a different KEM.

     The randomness used in Encap() and AuthEncap() to generate the KEM
     shared secret or its encapsulation MUST NOT be reused elsewhere.

     Since a KEM key pair belonging to a sender or recipient works with
     all modes, it can be used with multiple modes in parallel.  HPKE is
     constructed to be secure in such settings due to domain separation
     using the suite_id variable.  However, there is no formal proof of
     security at the time of writing for using multiple modes in parallel;
     [HPKEAnalysis] and [ABHKLR20] only analyze isolated modes.

  9.3.  Security Requirements on a KDF

     The choice of the KDF for HPKE SHOULD be made based on the security
     level provided by the KEM and, if applicable, by the PSK.  The KDF
     SHOULD at least have the security level of the KEM and SHOULD at
     least have the security level provided by the PSK.

  9.4.  Security Requirements on an AEAD

     All AEADs MUST be IND-CCA2-secure, as is currently true for all AEADs
     listed in Section 7.3.

  9.5.  Pre-Shared Key Recommendations

     In the PSK and AuthPSK modes, the PSK MUST have at least 32 bytes of
     entropy and SHOULD be of length Nh bytes or longer.  Using a PSK
     longer than 32 bytes but shorter than Nh bytes is permitted.














  Barnes, et al.          Expires 21 September 2025              [Page 34]


  Internet-Draft                    HPKE                        March 2025


     HPKE is specified to use HKDF as its key derivation function.  HKDF
     is not designed to slow down dictionary attacks (see [RFC5869]).
     Thus, HPKE's PSK mechanism is not suitable for use with a low-entropy
     password as the PSK: In scenarios in which the adversary knows the
     KEM shared secret shared_secret and has access to an oracle that
     distinguishes between a good and a wrong PSK, it can perform PSK-
     recovering attacks.  This oracle can be the decryption operation on a
     captured HPKE ciphertext or any other recipient behavior that is
     observably different when using a wrong PSK.  The adversary knows the
     KEM shared secret shared_secret if it knows all KEM private keys of
     one participant.  In the PSK mode, this is trivially the case if the
     adversary acts as the sender.

     To recover a lower entropy PSK, an attacker in this scenario can
     trivially perform a dictionary attack.  Given a set S of possible PSK
     values, the attacker generates an HPKE ciphertext for each value in
     S, and submits the resulting ciphertexts to the oracle to learn which
     PSK is being used by the recipient.  Further, because HPKE uses AEAD
     schemes that are not key-committing, an attacker can mount a
     partitioning oracle attack [LGR20] that can recover the PSK from a
     set of S possible PSK values, with |S| = m*k, in roughly m + log k
     queries to the oracle using ciphertexts of length proportional to k,
     the maximum message length in blocks.  (Applying the multi-collision
     algorithm from [LGR20] requires a small adaptation to the algorithm
     wherein the appropriate nonce is computed for each candidate key.
     This modification adds one call to HKDF per key.  The number of
     partitioning oracle queries remains unchanged.)  As a result, the PSK
     must therefore be chosen with sufficient entropy so that m + log k is
     prohibitive for attackers (e.g., 2^128).  Future specifications can
     define new AEAD algorithms that are key-committing.

  9.6.  Domain Separation

     HPKE allows combining a DHKEM variant DHKEM(Group, KDF') and a KDF
     such that both KDFs are instantiated by the same KDF.  By design, the
     calls to Extract() and Expand() inside DHKEM and the remainder of
     HPKE use separate input domains.  This justifies modeling them as
     independent functions even if instantiated by the same KDF.  This
     domain separation between DHKEM and the remainder of HPKE is achieved
     by using prefix-free sets of suite_id values in LabeledExtract() and
     LabeledExpand() (KEM... in DHKEM and HPKE... in the remainder of
     HPKE).  Recall that a set is prefix-free if no element is a prefix of
     another within the set.

     Future KEM instantiations MUST ensure, should Extract() and Expand()
     be used internally, that they can be modeled as functions independent
     from the invocations of Extract() and Expand() in the remainder of
     HPKE.  One way to ensure this is by using LabeledExtract() and



  Barnes, et al.          Expires 21 September 2025              [Page 35]


  Internet-Draft                    HPKE                        March 2025


     LabeledExpand() with a suite_id as defined in Section 4, which will
     ensure input domain separation, as outlined above.  Particular
     attention needs to be paid if the KEM directly invokes functions that
     are used internally in HPKE's Extract() or Expand(), such as Hash()
     and HMAC() in the case of HKDF.  It MUST be ensured that inputs to
     these invocations cannot collide with inputs to the internal
     invocations of these functions inside Extract() or Expand().  In
     HPKE's KeySchedule() this is avoided by using Extract() instead of
     Hash() on the arbitrary-length inputs info and psk_id.

     The string literal "HPKE-v1" used in LabeledExtract() and
     LabeledExpand() ensures that any secrets derived in HPKE are bound to
     the scheme's name and version, even when possibly derived from the
     same Diffie-Hellman or KEM shared secret as in another scheme or
     version.

  9.7.  Application Embedding and Non-Goals

     HPKE is designed to be a fairly low-level mechanism.  As a result, it
     assumes that certain properties are provided by the application in
     which HPKE is embedded and leaves certain security properties to be
     provided by other mechanisms.  Otherwise said, certain properties are
     out-of-scope for HPKE.

  9.7.1.  Message Order and Message Loss

     The primary requirement that HPKE imposes on applications is the
     requirement that ciphertexts MUST be presented to ContextR.Open() in
     the same order in which they were generated by ContextS.Seal().  When
     the single-shot API is used (see Section 6), this is trivially true
     (since there is only ever one ciphertext.  Applications that allow
     for multiple invocations of Open() / Seal() on the same context MUST
     enforce the ordering property described above.

     Ordering requirements of this character are usually fulfilled by
     providing a sequence number in the framing of encrypted messages.
     Whatever information is used to determine the ordering of HPKE-
     encrypted messages SHOULD be included in the AAD passed to
     ContextS.Seal() and ContextR.Open().  The specifics of this scheme
     are up to the application.

     HPKE is not tolerant of lost messages.  Applications MUST be able to
     detect when a message has been lost.  When an unrecoverable loss is
     detected, the application MUST discard any associated HPKE context.







  Barnes, et al.          Expires 21 September 2025              [Page 36]


  Internet-Draft                    HPKE                        March 2025


  9.7.2.  Downgrade Prevention

     HPKE assumes that the sender and recipient agree on what algorithms
     to use.  Depending on how these algorithms are negotiated, it may be
     possible for an intermediary to force the two parties to use
     suboptimal algorithms.

  9.7.3.  Replay Protection

     The requirement that ciphertexts be presented to the ContextR.Open()
     function in the same order they were generated by ContextS.Seal()
     provides a degree of replay protection within a stream of ciphertexts
     resulting from a given context.  HPKE provides no other replay
     protection.

  9.7.4.  Forward Secrecy

     HPKE ciphertexts are not forward secret with respect to recipient
     compromise in any mode.  This means that compromise of long-term
     recipient secrets allows an attacker to decrypt past ciphertexts
     encrypted under said secrets.  This is because only long-term secrets
     are used on the side of the recipient.

     HPKE ciphertexts are forward secret with respect to sender compromise
     in all modes.  This is because ephemeral randomness is used on the
     sender's side, which is supposed to be erased directly after
     computation of the KEM shared secret and ciphertext.

  9.7.5.  Bad Ephemeral Randomness

     If the randomness used for KEM encapsulation is bad -- i.e., of low
     entropy or compromised because of a broken or subverted random number
     generator -- the confidentiality guarantees of HPKE degrade
     significantly.  In Base mode, confidentiality guarantees can be lost
     completely; in the other modes, at least forward secrecy with respect
     to sender compromise can be lost completely.

     Such a situation could also lead to the reuse of the same KEM shared
     secret and thus to the reuse of same key-nonce pairs for the AEAD.
     The AEADs specified in this document are not secure in case of nonce
     reuse.  This attack vector is particularly relevant in authenticated
     modes because knowledge of the ephemeral randomness is not enough to
     derive shared_secret in these modes.

     One way for applications to mitigate the impacts of bad ephemeral
     randomness is to combine ephemeral randomness with a local long-term
     secret that has been generated securely, as described in [RFC8937].




  Barnes, et al.          Expires 21 September 2025              [Page 37]


  Internet-Draft                    HPKE                        March 2025


  9.7.6.  Hiding Plaintext Length

     AEAD ciphertexts produced by HPKE do not hide the plaintext length.
     Applications requiring this level of privacy should use a suitable
     padding mechanism.  See [I-D.ietf-tls-esni] and [RFC8467] for
     examples of protocol-specific padding policies.

  9.8.  Bidirectional Encryption

     As discussed in Section 5.2, HPKE encryption is unidirectional from
     sender to recipient.  Applications that require bidirectional
     encryption can derive necessary keying material with the secret
     export interface Section 5.3.  The type and length of such keying
     material depends on the application use case.

     As an example, if an application needs AEAD encryption from the
     recipient to the sender, it can derive a key and nonce from the
     corresponding HPKE context as follows:

     key = context.Export("response key", Nk)
     nonce = context.Export("response nonce", Nn)

     In this example, the length of each secret is based on the AEAD
     algorithm used for the corresponding HPKE context.

     Note that HPKE's limitations with regard to sender authentication
     become limits on recipient authentication in this context.  In
     particular, in the Base mode, there is no authentication of the
     remote party at all.  Even in the Auth mode, where the remote party
     has proven that they hold a specific private key, this authentication
     is still subject to key-compromise impersonation, as discussed in
     Section 9.1.1.

  9.9.  Metadata Protection

     The authenticated modes of HPKE (PSK, Auth, and AuthPSK) require that
     the recipient know what key material to use for the sender.  This can
     be signaled in applications by sending the PSK ID (psk_id above) and/
     or the sender's public key (pkS).  However, these values themselves
     might be considered sensitive, since, in a given application context,
     they might identify the sender.

     An application that wishes to protect these metadata values without
     requiring further provisioning of keys can use an additional instance
     of HPKE, using the unauthenticated Base mode.  Where the application
     might have sent (psk_id, pkS, enc, ciphertext) before, it would now
     send (enc2, ciphertext2, enc, ciphertext), where (enc2, ciphertext2)
     represent the encryption of the psk_id and pkS values.



  Barnes, et al.          Expires 21 September 2025              [Page 38]


  Internet-Draft                    HPKE                        March 2025


     The cost of this approach is an additional KEM operation each for the
     sender and the recipient.  A potential lower-cost approach (involving
     only symmetric operations) would be available if the nonce-protection
     schemes in [BNT19] could be extended to cover other metadata.
     However, this construction would require further analysis.

  10.  Message Encoding

     This document does not specify a wire format encoding for HPKE
     messages.  Applications that adopt HPKE must therefore specify an
     unambiguous encoding mechanism that includes, minimally: the
     encapsulated value enc, ciphertext value(s) (and order if there are
     multiple), and any info values that are not implicit.  One example of
     a non-implicit value is the recipient public key used for
     encapsulation, which may be needed if a recipient has more than one
     public key.

     The AEAD interface used in this document is based on [RFC5116], which
     produces and consumes a single ciphertext value.  As discussed in
     [RFC5116], this ciphertext value contains the encrypted plaintext as
     well as any authentication data, encoded in a manner described by the
     individual AEAD scheme.  Some implementations are not structured in
     this way, instead providing a separate ciphertext and authentication
     tag.  When such AEAD implementations are used in HPKE
     implementations, the HPKE implementation must combine these inputs
     into a single ciphertext value within Seal() and parse them out
     within Open(), where the parsing details are defined by the AEAD
     scheme.  For example, with the AES-GCM schemes specified in this
     document, the GCM authentication tag is placed in the last Nt bytes
     of the ciphertext output.

  11.  IANA Considerations

     IANA has created three new registries:

     *  HPKE KEM Identifiers

     *  HPKE KDF Identifiers

     *  HPKE AEAD Identifiers

     All these registries are under "Hybrid Public Key Encryption", and
     administered under a Specification Required policy [RFC8126]








  Barnes, et al.          Expires 21 September 2025              [Page 39]


  Internet-Draft                    HPKE                        March 2025


  11.1.  KEM Identifiers

     The "HPKE KEM Identifiers" registry lists identifiers for key
     encapsulation algorithms defined for use with HPKE.  These
     identifiers are two-byte values, so the maximum possible value is
     0xFFFF = 65535.

     Template:

     *  Value: The two-byte identifier for the algorithm

     *  KEM: The name of the algorithm

     *  Nsecret: The length in bytes of a KEM shared secret produced by
        the algorithm

     *  Nenc: The length in bytes of an encoded encapsulated key produced
        by the algorithm

     *  Npk: The length in bytes of an encoded public key for the
        algorithm

     *  Nsk: The length in bytes of an encoded private key for the
        algorithm

     *  Auth: A boolean indicating if this algorithm provides the
        AuthEncap()/AuthDecap() interface

     *  Reference: Where this algorithm is defined

     Initial contents: Provided in Table 2

  11.2.  KDF Identifiers

     The "HPKE KDF Identifiers" registry lists identifiers for key
     derivation functions defined for use with HPKE.  These identifiers
     are two-byte values, so the maximum possible value is 0xFFFF = 65535.

     Template:

     *  Value: The two-byte identifier for the algorithm

     *  KDF: The name of the algorithm

     *  Nh: The output size of the Extract function in bytes

     *  Reference: Where this algorithm is defined




  Barnes, et al.          Expires 21 September 2025              [Page 40]


  Internet-Draft                    HPKE                        March 2025


     Initial contents: Provided in Table 3

  11.3.  AEAD Identifiers

     The "HPKE AEAD Identifiers" registry lists identifiers for
     authenticated encryption with associated data (AEAD) algorithms
     defined for use with HPKE.  These identifiers are two-byte values, so
     the maximum possible value is 0xFFFF = 65535.

     Template:

     *  Value: The two-byte identifier for the algorithm

     *  AEAD: The name of the algorithm

     *  Nk: The length in bytes of a key for this algorithm

     *  Nn: The length in bytes of a nonce for this algorithm

     *  Nt: The length in bytes of an authentication tag for this
        algorithm

     *  Reference: Where this algorithm is defined

     Initial contents: Provided in Table 5

  12.  References

  12.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
                Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
                <https://www.rfc-editor.org/rfc/rfc5116>.

     [RFC8017]  Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
                "PKCS #1: RSA Cryptography Specifications Version 2.2",
                RFC 8017, DOI 10.17487/RFC8017, November 2016,
                <https://www.rfc-editor.org/rfc/rfc8017>.

     [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                Writing an IANA Considerations Section in RFCs", BCP 26,
                RFC 8126, DOI 10.17487/RFC8126, June 2017,
                <https://www.rfc-editor.org/rfc/rfc8126>.



  Barnes, et al.          Expires 21 September 2025              [Page 41]


  Internet-Draft                    HPKE                        March 2025


     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

  12.2.  Informative References

     [ABHKLR20] Alwen, J., Blanchet, B., Hauck, E., Kiltz, E., Lipp, B.,
                and D. Riepel, "Analysing the HPKE Standard", 2020,
                <https://eprint.iacr.org/2020/1499>.

     [ANSI]     American National Standards Institute, "ANSI X9.63 Public
                Key Cryptography for the Financial Services Industry --
                Key Agreement and Key Transport Using Elliptic Curve
                Cryptography", 2001.

     [BHK09]    Mihir Bellare, Dennis Hofheinz, and Eike Kiltz,
                "Subtleties in the Definition of IND-CCA: When and How
                Should Challenge-Decryption be Disallowed?", 2009,
                <https://eprint.iacr.org/2009/418>.

     [BJM97]    Blake-Wilson, S., Johnson, D., and A. Menezes, "Key
                agreement protocols and their security analysis: Extended
                Abstract", Springer Berlin Heidelberg, Lecture Notes in
                Computer Science pp. 30-45, DOI 10.1007/bfb0024447,
                ISBN ["9783540639275", "9783540696681"], 1997,
                <https://doi.org/10.1007/bfb0024447>.

     [BNT19]    Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed:
                AEAD Revisited", 2019,
                <http://dx.doi.org/10.1007/978-3-030-26948-7_9>.

     [CS01]     Cramer, R. and V. Shoup, "Design and Analysis of Practical
                Public-Key Encryption Schemes Secure against Adaptive
                Chosen Ciphertext Attack", 2001,
                <https://eprint.iacr.org/2001/108>.

     [GAP]      Okamoto, T. and D. Pointcheval, "The Gap-Problems - a New
                Class of Problems for the Security of Cryptographic
                Schemes", ISBN 978-3-540-44586-9, 2001,
                <https://link.springer.com/content/
                pdf/10.1007/3-540-44586-2_8.pdf>.

     [GCM]      Dworkin, M., "Recommendation for block cipher modes of
                operation :: GaloisCounter Mode (GCM) and GMAC", National
                Institute of Standards and Technology,
                DOI 10.6028/nist.sp.800-38d, 2007,
                <https://doi.org/10.6028/nist.sp.800-38d>.




  Barnes, et al.          Expires 21 September 2025              [Page 42]


  Internet-Draft                    HPKE                        March 2025


     [HHK06]    Herranz, J., Hofheinz, D., and E. Kiltz, "Some
                (in)sufficient conditions for secure hybrid encryption",
                2006, <https://eprint.iacr.org/2006/265>.

     [HPKEAnalysis]
                Lipp, B., "An Analysis of Hybrid Public Key Encryption",
                2020, <https://eprint.iacr.org/2020/243>.

     [I-D.ietf-mls-protocol]
                Barnes, R., Beurdouche, B., Robert, R., Millican, J.,
                Omara, E., and K. Cohn-Gordon, "The Messaging Layer
                Security (MLS) Protocol", Work in Progress, Internet-
                Draft, draft-ietf-mls-protocol-20, 27 March 2023,
                <https://datatracker.ietf.org/doc/html/draft-ietf-mls-
                protocol-20>.

     [I-D.ietf-tls-esni]
                Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
                Encrypted Client Hello", Work in Progress, Internet-Draft,
                draft-ietf-tls-esni-23, 19 February 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
                esni-23>.

     [IEEE1363] Institute of Electrical and Electronics Engineers, "IEEE
                1363a, Standard Specifications for Public Key Cryptography
                - Amendment 1 -- Additional Techniques"", 2004.

     [IMB]      Diffie, W., Van Oorschot, P., and M. Wiener,
                "Authentication and authenticated key exchanges", Springer
                Science and Business Media LLC, Designs, Codes and
                Cryptography vol. 2, no. 2, pp. 107-125,
                DOI 10.1007/bf00124891, June 1992,
                <https://doi.org/10.1007/bf00124891>.

     [ISO]      International Organization for Standardization /
                International Electrotechnical Commission, "ISO/IEC
                18033-2, Information Technology - Security Techniques -
                Encryption Algorithms - Part 2 -- Asymmetric Ciphers",
                2006.

     [keyagreement]
                Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
                Davis, "Recommendation for pair-wise key-establishment
                schemes using discrete logarithm cryptography", National
                Institute of Standards and Technology,
                DOI 10.6028/nist.sp.800-56ar3, April 2018,
                <https://doi.org/10.6028/nist.sp.800-56ar3>.




  Barnes, et al.          Expires 21 September 2025              [Page 43]


  Internet-Draft                    HPKE                        March 2025


     [LGR20]    Len, J., Grubbs, P., and T. Ristenpart, "Partitioning
                Oracle Attacks", 2021,
                <https://eprint.iacr.org/2020/1491>.

     [MAEA10]   Gayoso Martinez, V., Hernandez Alvarez, F., Hernandez
                Encinas, L., and C. Sanchez Avila, "A Comparison of the
                Standardized Versions of ECIES", 2010,
                <https://ieeexplore.ieee.org/abstract/document/5604194/>.

     [NaCl]     "Public-key authenticated encryption: crypto_box", 2019,
                <https://nacl.cr.yp.to/box.html>.

     [NISTCurves]
                "Digital signature standard (DSS)", National Institute of
                Standards and Technology (U.S.),
                DOI 10.6028/nist.fips.186-4, 2013,
                <https://doi.org/10.6028/nist.fips.186-4>.

     [RFC1421]  Linn, J., "Privacy Enhancement for Internet Electronic
                Mail: Part I: Message Encryption and Authentication
                Procedures", RFC 1421, DOI 10.17487/RFC1421, February
                1993, <https://www.rfc-editor.org/rfc/rfc1421>.

     [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
                Key Derivation Function (HKDF)", RFC 5869,
                DOI 10.17487/RFC5869, May 2010,
                <https://www.rfc-editor.org/rfc/rfc5869>.

     [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
                for Security", RFC 7748, DOI 10.17487/RFC7748, January
                2016, <https://www.rfc-editor.org/rfc/rfc7748>.

     [RFC8439]  Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
                Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
                <https://www.rfc-editor.org/rfc/rfc8439>.

     [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
                Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
                <https://www.rfc-editor.org/rfc/rfc8446>.

     [RFC8467]  Mayrhofer, A., "Padding Policies for Extension Mechanisms
                for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
                October 2018, <https://www.rfc-editor.org/rfc/rfc8467>.

     [RFC8696]  Housley, R., "Using Pre-Shared Key (PSK) in the
                Cryptographic Message Syntax (CMS)", RFC 8696,
                DOI 10.17487/RFC8696, December 2019,
                <https://www.rfc-editor.org/rfc/rfc8696>.



  Barnes, et al.          Expires 21 September 2025              [Page 44]


  Internet-Draft                    HPKE                        March 2025


     [RFC8937]  Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,
                and C. Wood, "Randomness Improvements for Security
                Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020,
                <https://www.rfc-editor.org/rfc/rfc8937>.

     [SECG]     "Elliptic Curve Cryptography, Standards for Efficient
                Cryptography Group, ver. 2", 2009,
                <https://secg.org/sec1-v2.pdf>.

     [SigncryptionDZ10]
                "Practical Signcryption", Springer Berlin Heidelberg,
                Information Security and Cryptography,
                DOI 10.1007/978-3-540-89411-7, ISBN ["9783540894094",
                "9783540894117"], 2010,
                <https://doi.org/10.1007/978-3-540-89411-7>.

     [TestVectors]
                "HPKE Test Vectors", 2021, <https://github.com/cfrg/draft-
                irtf-cfrg-
                hpke/blob/5f503c564da00b0687b3de75f1dfbdfc4079ad31/test-
                vectors.json>.

  Appendix A.  Acknowledgements

     The authors would like to thank Joël Alwen, Jean-Philippe Aumasson,
     David Benjamin, Benjamin Beurdouche, Bruno Blanchet, Frank Denis,
     Stephen Farrell, Scott Fluhrer, Eduard Hauck, Scott Hollenbeck, Kevin
     Jacobs, Burt Kaliski, Eike Kiltz, Julia Len, John Mattsson,
     Christopher Patton, Doreen Riepel, Raphael Robert, Michael Rosenberg,
     Michael Scott, Martin Thomson, Steven Valdez, Riad Wahby, and other
     contributors in the CFRG for helpful feedback that greatly improved
     this document.

  Appendix B.  Test Vectors

     Each section below contains test vectors for a single HPKE
     ciphersuite and contains the following values:

     1.  Configuration information and private key material: This includes
         the mode, info string, HPKE ciphersuite identifiers (kem_id,
         kdf_id, aead_id), and all sender, recipient, and ephemeral key
         material.  For each role X, where X is one of S, R, or E, as
         sender, recipient, and ephemeral, respectively, key pairs are
         generated as (skX, pkX) = DeriveKeyPair(ikmX).  Each key pair
         (skX, pkX) is written in its serialized form, where skXm =
         SerializePrivateKey(skX) and pkXm = SerializePublicKey(pkX).  For
         applicable modes, the shared PSK and PSK identifier are also
         included.



  Barnes, et al.          Expires 21 September 2025              [Page 45]


  Internet-Draft                    HPKE                        March 2025


     2.  Context creation intermediate values and outputs: This includes
         the KEM outputs enc and shared_secret used to create the context,
         along with intermediate values key_schedule_context and secret
         computed in the KeySchedule function in Section 5.1.  The outputs
         include the context values key, base_nonce, and exporter_secret.

     3.  Encryption test vectors: A fixed plaintext message is encrypted
         using different sequence numbers and AAD values using the context
         computed in (2).  Each test vector lists the sequence number and
         corresponding nonce computed with base_nonce, the plaintext
         message pt, AAD aad, and output ciphertext ct.

     4.  Export test vectors: Several exported values of the same length
         with differing context parameters are computed using the context
         computed in (2).  Each test vector lists the exporter_context,
         output length L, and resulting export value.

     These test vectors are also available in JSON format at
     [TestVectors].

  B.1.  DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, AES-128-GCM

  B.1.1.  Base Setup Information




























  Barnes, et al.          Expires 21 September 2025              [Page 46]


  Internet-Draft                    HPKE                        March 2025


     mode: 0
     kem_id: 32
     kdf_id: 1
     aead_id: 1
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     7268600d403fce431561aef583ee1613527cff655c1343f29812e66706df3234
     pkEm:
     37fda3567bdbd628e88668c3c8d7e97d1d1253b6d4ea6d44c150f741f1bf4431
     skEm:
     52c4a758a802cd8b936eceea314432798d5baf2d7e9235dc084ab1b9cfa2f736
     ikmR:
     6db9df30aa07dd42ee5e8181afdb977e538f5e1fec8a06223f33f7013e525037
     pkRm:
     3948cfe0ad1ddb695d780e59077195da6c56506b027329794ab02bca80815c4d
     skRm:
     4612c550263fc8ad58375df3f557aac531d26850903e55a9f23f21d8534e8ac8
     enc:
     37fda3567bdbd628e88668c3c8d7e97d1d1253b6d4ea6d44c150f741f1bf4431
     shared_secret:
     fe0e18c9f024ce43799ae393c7e8fe8fce9d218875e8227b0187c04e7d2ea1fc
     key_schedule_context: 00725611c9d98c07c03f60095cd32d400d8347d45ed670
     97bbad50fc56da742d07cb6cffde367bb0565ba28bb02c90744a20f5ef37f3052352
     6106f637abb05449
     secret:
     12fff91991e93b48de37e7daddb52981084bd8aa64289c3788471d9a9712f397
     key: 4531685d41d65f03dc48f6b8302c05b0
     base_nonce: 56d890e5accaaf011cff4b7d
     exporter_secret:
     45ff1c2e220db587171952c0592d5f5ebe103f1561a2614e38f2ffd47e99e3f8

  B.1.1.1.  Encryptions



















  Barnes, et al.          Expires 21 September 2025              [Page 47]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 56d890e5accaaf011cff4b7d
     ct: f938558b5d72f1a23810b4be2ab4f84331acc02fc97babc53a52ae8218a355a9
     6d8770ac83d07bea87e13c512a

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 56d890e5accaaf011cff4b7c
     ct: af2d7e9ac9ae7e270f46ba1f975be53c09f8d875bdc8535458c2494e8a6eab25
     1c03d0c22a56b8ca42c2063b84

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 56d890e5accaaf011cff4b7f
     ct: 498dfcabd92e8acedc281e85af1cb4e3e31c7dc394a1ca20e173cb7251649158
     8d96a19ad4a683518973dcc180

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 56d890e5accaaf011cff4b79
     ct: 583bd32bc67a5994bb8ceaca813d369bca7b2a42408cddef5e22f880b631215a
     09fc0012bc69fccaa251c0246d

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 56d890e5accaaf011cff4b82
     ct: 7175db9717964058640a3a11fb9007941a5d1757fda1a6935c805c21af32505b
     f106deefec4a49ac38d71c9e0a

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 56d890e5accaaf011cff4a7d
     ct: 957f9800542b0b8891badb026d79cc54597cb2d225b54c00c5238c25d05c30e3
     fbeda97d2e0e1aba483a2df9f2

  B.1.1.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025              [Page 48]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     3853fe2b4035195a573ffc53856e77058e15d9ea064de3e59f4961d0095250ee

     exporter_context: 00
     L: 32
     exported_value:
     2e8f0b54673c7029649d4eb9d5e33bf1872cf76d623ff164ac185da9e88c21a5

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     e9e43065102c3836401bed8c3c3c75ae46be1639869391d62c61f1ec7af54931

  B.1.2.  PSK Setup Information



































  Barnes, et al.          Expires 21 September 2025              [Page 49]


  Internet-Draft                    HPKE                        March 2025


     mode: 1
     kem_id: 32
     kdf_id: 1
     aead_id: 1
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     78628c354e46f3e169bd231be7b2ff1c77aa302460a26dbfa15515684c00130b
     pkEm:
     0ad0950d9fb9588e59690b74f1237ecdf1d775cd60be2eca57af5a4b0471c91b
     skEm:
     463426a9ffb42bb17dbe6044b9abd1d4e4d95f9041cef0e99d7824eef2b6f588
     ikmR:
     d4a09d09f575fef425905d2ab396c1449141463f698f8efdb7accfaff8995098
     pkRm:
     9fed7e8c17387560e92cc6462a68049657246a09bfa8ade7aefe589672016366
     skRm:
     c5eb01eb457fe6c6f57577c5413b931550a162c71a03ac8d196babbd4e5ce0fd
     psk:
     0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
     psk_id: 456e6e796e20447572696e206172616e204d6f726961
     enc:
     0ad0950d9fb9588e59690b74f1237ecdf1d775cd60be2eca57af5a4b0471c91b
     shared_secret:
     727699f009ffe3c076315019c69648366b69171439bd7dd0807743bde76986cd
     key_schedule_context: 01e78d5cf6190d275863411ff5edd0dece5d39fa48e04e
     ec1ed9b71be34729d18ccb6cffde367bb0565ba28bb02c90744a20f5ef37f3052352
     6106f637abb05449
     secret:
     3728ab0b024b383b0381e432b47cced1496d2516957a76e2a9f5c8cb947afca4
     key: 15026dba546e3ae05836fc7de5a7bb26
     base_nonce: 9518635eba129d5ce0914555
     exporter_secret:
     3d76025dbbedc49448ec3f9080a1abab6b06e91c0b11ad23c912f043a0ee7655

  B.1.2.1.  Encryptions
















  Barnes, et al.          Expires 21 September 2025              [Page 50]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 9518635eba129d5ce0914555
     ct: e52c6fed7f758d0cf7145689f21bc1be6ec9ea097fef4e959440012f4feb73fb
     611b946199e681f4cfc34db8ea

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 9518635eba129d5ce0914554
     ct: 49f3b19b28a9ea9f43e8c71204c00d4a490ee7f61387b6719db765e948123b45
     b61633ef059ba22cd62437c8ba

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 9518635eba129d5ce0914557
     ct: 257ca6a08473dc851fde45afd598cc83e326ddd0abe1ef23baa3baa4dd8cde99
     fce2c1e8ce687b0b47ead1adc9

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 9518635eba129d5ce0914551
     ct: a71d73a2cd8128fcccbd328b9684d70096e073b59b40b55e6419c9c68ae21069
     c847e2a70f5d8fb821ce3dfb1c

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 9518635eba129d5ce09145aa
     ct: 55f84b030b7f7197f7d7d552365b6b932df5ec1abacd30241cb4bc4ccea27bd2
     b518766adfa0fb1b71170e9392

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 9518635eba129d5ce0914455
     ct: c5bf246d4a790a12dcc9eed5eae525081e6fb541d5849e9ce8abd92a3bc15517
     76bea16b4a518f23e237c14b59

  B.1.2.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025              [Page 51]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     dff17af354c8b41673567db6259fd6029967b4e1aad13023c2ae5df8f4f43bf6

     exporter_context: 00
     L: 32
     exported_value:
     6a847261d8207fe596befb52928463881ab493da345b10e1dcc645e3b94e2d95

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     8aff52b45a1be3a734bc7a41e20b4e055ad4c4d22104b0c20285a7c4302401cd

  B.1.3.  Auth Setup Information



































  Barnes, et al.          Expires 21 September 2025              [Page 52]


  Internet-Draft                    HPKE                        March 2025


     mode: 2
     kem_id: 32
     kdf_id: 1
     aead_id: 1
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     6e6d8f200ea2fb20c30b003a8b4f433d2f4ed4c2658d5bc8ce2fef718059c9f7
     pkEm:
     23fb952571a14a25e3d678140cd0e5eb47a0961bb18afcf85896e5453c312e76
     skEm:
     ff4442ef24fbc3c1ff86375b0be1e77e88a0de1e79b30896d73411c5ff4c3518
     ikmR:
     f1d4a30a4cef8d6d4e3b016e6fd3799ea057db4f345472ed302a67ce1c20cdec
     pkRm:
     1632d5c2f71c2b38d0a8fcc359355200caa8b1ffdf28618080466c909cb69b2e
     skRm:
     fdea67cf831f1ca98d8e27b1f6abeb5b7745e9d35348b80fa407ff6958f9137e
     ikmS:
     94b020ce91d73fca4649006c7e7329a67b40c55e9e93cc907d282bbbff386f58
     pkSm:
     8b0c70873dc5aecb7f9ee4e62406a397b350e57012be45cf53b7105ae731790b
     skSm:
     dc4a146313cce60a278a5323d321f051c5707e9c45ba21a3479fecdf76fc69dd
     enc:
     23fb952571a14a25e3d678140cd0e5eb47a0961bb18afcf85896e5453c312e76
     shared_secret:
     2d6db4cf719dc7293fcbf3fa64690708e44e2bebc81f84608677958c0d4448a7
     key_schedule_context: 02725611c9d98c07c03f60095cd32d400d8347d45ed670
     97bbad50fc56da742d07cb6cffde367bb0565ba28bb02c90744a20f5ef37f3052352
     6106f637abb05449
     secret:
     56c62333d9d9f7767f5b083fdfce0aa7e57e301b74029bb0cffa7331385f1dda
     key: b062cb2c4dd4bca0ad7c7a12bbc341e6
     base_nonce: a1bc314c1942ade7051ffed0
     exporter_secret:
     ee1a093e6e1c393c162ea98fdf20560c75909653550540a2700511b65c88c6f1

  B.1.3.1.  Encryptions













  Barnes, et al.          Expires 21 September 2025              [Page 53]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: a1bc314c1942ade7051ffed0
     ct: 5fd92cc9d46dbf8943e72a07e42f363ed5f721212cd90bcfd072bfd9f44e06b8
     0fd17824947496e21b680c141b

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: a1bc314c1942ade7051ffed1
     ct: d3736bb256c19bfa93d79e8f80b7971262cb7c887e35c26370cfed62254369a1
     b52e3d505b79dd699f002bc8ed

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: a1bc314c1942ade7051ffed2
     ct: 122175cfd5678e04894e4ff8789e85dd381df48dcaf970d52057df2c9acc3b12
     1313a2bfeaa986050f82d93645

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: a1bc314c1942ade7051ffed4
     ct: dae12318660cf963c7bcbef0f39d64de3bf178cf9e585e756654043cc5059873
     bc8af190b72afc43d1e0135ada

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: a1bc314c1942ade7051ffe2f
     ct: 55d53d85fe4d9e1e97903101eab0b4865ef20cef28765a47f840ff99625b7d69
     dee927df1defa66a036fc58ff2

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: a1bc314c1942ade7051fffd0
     ct: 42fa248a0e67ccca688f2b1d13ba4ba84755acf764bd797c8f7ba3b9b1dc3330
     326f8d172fef6003c79ec72319

  B.1.3.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025              [Page 54]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     28c70088017d70c896a8420f04702c5a321d9cbf0279fba899b59e51bac72c85

     exporter_context: 00
     L: 32
     exported_value:
     25dfc004b0892be1888c3914977aa9c9bbaf2c7471708a49e1195af48a6f29ce

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     5a0131813abc9a522cad678eb6bafaabc43389934adb8097d23c5ff68059eb64

  B.1.4.  AuthPSK Setup Information



































  Barnes, et al.          Expires 21 September 2025              [Page 55]


  Internet-Draft                    HPKE                        March 2025


     mode: 3
     kem_id: 32
     kdf_id: 1
     aead_id: 1
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     4303619085a20ebcf18edd22782952b8a7161e1dbae6e46e143a52a96127cf84
     pkEm:
     820818d3c23993492cc5623ab437a48a0a7ca3e9639c140fe1e33811eb844b7c
     skEm:
     14de82a5897b613616a00c39b87429df35bc2b426bcfd73febcb45e903490768
     ikmR:
     4b16221f3b269a88e207270b5e1de28cb01f847841b344b8314d6a622fe5ee90
     pkRm:
     1d11a3cd247ae48e901939659bd4d79b6b959e1f3e7d66663fbc9412dd4e0976
     skRm:
     cb29a95649dc5656c2d054c1aa0d3df0493155e9d5da6d7e344ed8b6a64a9423
     ikmS:
     62f77dcf5df0dd7eac54eac9f654f426d4161ec850cc65c54f8b65d2e0b4e345
     pkSm:
     2bfb2eb18fcad1af0e4f99142a1c474ae74e21b9425fc5c589382c69b50cc57e
     skSm:
     fc1c87d2f3832adb178b431fce2ac77c7ca2fd680f3406c77b5ecdf818b119f4
     psk:
     0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
     psk_id: 456e6e796e20447572696e206172616e204d6f726961
     enc:
     820818d3c23993492cc5623ab437a48a0a7ca3e9639c140fe1e33811eb844b7c
     shared_secret:
     f9d0e870aba28d04709b2680cb8185466c6a6ff1d6e9d1091d5bf5e10ce3a577
     key_schedule_context: 03e78d5cf6190d275863411ff5edd0dece5d39fa48e04e
     ec1ed9b71be34729d18ccb6cffde367bb0565ba28bb02c90744a20f5ef37f3052352
     6106f637abb05449
     secret:
     5f96c55e4108c6691829aaabaa7d539c0b41d7c72aae94ae289752f056b6cec4
     key: 1364ead92c47aa7becfa95203037b19a
     base_nonce: 99d8b5c54669807e9fc70df1
     exporter_secret:
     f048d55eacbf60f9c6154bd4021774d1075ebf963c6adc71fa846f183ab2dde6

  B.1.4.1.  Encryptions










  Barnes, et al.          Expires 21 September 2025              [Page 56]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 99d8b5c54669807e9fc70df1
     ct: a84c64df1e11d8fd11450039d4fe64ff0c8a99fca0bd72c2d4c3e0400bc14a40
     f27e45e141a24001697737533e

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 99d8b5c54669807e9fc70df0
     ct: 4d19303b848f424fc3c3beca249b2c6de0a34083b8e909b6aa4c3688505c05ff
     e0c8f57a0a4c5ab9da127435d9

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 99d8b5c54669807e9fc70df3
     ct: 0c085a365fbfa63409943b00a3127abce6e45991bc653f182a80120868fc507e
     9e4d5e37bcc384fc8f14153b24

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 99d8b5c54669807e9fc70df5
     ct: 000a3cd3a3523bf7d9796830b1cd987e841a8bae6561ebb6791a3f0e34e89a4f
     b539faeee3428b8bbc082d2c1a

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 99d8b5c54669807e9fc70d0e
     ct: 576d39dd2d4cc77d1a14a51d5c5f9d5e77586c3d8d2ab33bdec6379e28ce5c50
     2f0b1cbd09047cf9eb9269bb52

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 99d8b5c54669807e9fc70cf1
     ct: 13239bab72e25e9fd5bb09695d23c90a24595158b99127505c8a9ff9f127e0d6
     57f71af59d67d4f4971da028f9

  B.1.4.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025              [Page 57]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     08f7e20644bb9b8af54ad66d2067457c5f9fcb2a23d9f6cb4445c0797b330067

     exporter_context: 00
     L: 32
     exported_value:
     52e51ff7d436557ced5265ff8b94ce69cf7583f49cdb374e6aad801fc063b010

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     a30c20370c026bbea4dca51cb63761695132d342bae33a6a11527d3e7679436d

  B.2.  DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, ChaCha20Poly1305

  B.2.1.  Base Setup Information

































  Barnes, et al.          Expires 21 September 2025              [Page 58]


  Internet-Draft                    HPKE                        March 2025


     mode: 0
     kem_id: 32
     kdf_id: 1
     aead_id: 3
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     909a9b35d3dc4713a5e72a4da274b55d3d3821a37e5d099e74a647db583a904b
     pkEm:
     1afa08d3dec047a643885163f1180476fa7ddb54c6a8029ea33f95796bf2ac4a
     skEm:
     f4ec9b33b792c372c1d2c2063507b684ef925b8c75a42dbcbf57d63ccd381600
     ikmR:
     1ac01f181fdf9f352797655161c58b75c656a6cc2716dcb66372da835542e1df
     pkRm:
     4310ee97d88cc1f088a5576c77ab0cf5c3ac797f3d95139c6c84b5429c59662a
     skRm:
     8057991eef8f1f1af18f4a9491d16a1ce333f695d4db8e38da75975c4478e0fb
     enc:
     1afa08d3dec047a643885163f1180476fa7ddb54c6a8029ea33f95796bf2ac4a
     shared_secret:
     0bbe78490412b4bbea4812666f7916932b828bba79942424abb65244930d69a7
     key_schedule_context: 00431df6cd95e11ff49d7013563baf7f11588c75a6611e
     e2a4404a49306ae4cfc5b69c5718a60cc5876c358d3f7fc31ddb598503f67be58ea1
     e798c0bb19eb9796
     secret:
     5b9cd775e64b437a2335cf499361b2e0d5e444d5cb41a8a53336d8fe402282c6
     key:
     ad2744de8e17f4ebba575b3f5f5a8fa1f69c2a07f6e7500bc60ca6e3e3ec1c91
     base_nonce: 5c4d98150661b848853b547f
     exporter_secret:
     a3b010d4994890e2c6968a36f64470d3c824c8f5029942feb11e7a74b2921922

  B.2.1.1.  Encryptions


















  Barnes, et al.          Expires 21 September 2025              [Page 59]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 5c4d98150661b848853b547f
     ct: 1c5250d8034ec2b784ba2cfd69dbdb8af406cfe3ff938e131f0def8c8b60b4db
     21993c62ce81883d2dd1b51a28

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 5c4d98150661b848853b547e
     ct: 6b53c051e4199c518de79594e1c4ab18b96f081549d45ce015be002090bb119e
     85285337cc95ba5f59992dc98c

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 5c4d98150661b848853b547d
     ct: 71146bd6795ccc9c49ce25dda112a48f202ad220559502cef1f34271e0cb4b02
     b4f10ecac6f48c32f878fae86b

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 5c4d98150661b848853b547b
     ct: 63357a2aa291f5a4e5f27db6baa2af8cf77427c7c1a909e0b37214dd47db122b
     b153495ff0b02e9e54a50dbe16

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 5c4d98150661b848853b5480
     ct: 18ab939d63ddec9f6ac2b60d61d36a7375d2070c9b683861110757062c52b888
     0a5f6b3936da9cd6c23ef2a95c

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 5c4d98150661b848853b557f
     ct: 7a4a13e9ef23978e2c520fd4d2e757514ae160cd0cd05e556ef692370ca53076
     214c0c40d4c728d6ed9e727a5b

  B.2.1.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025              [Page 60]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     4bbd6243b8bb54cec311fac9df81841b6fd61f56538a775e7c80a9f40160606e

     exporter_context: 00
     L: 32
     exported_value:
     8c1df14732580e5501b00f82b10a1647b40713191b7c1240ac80e2b68808ba69

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     5acb09211139c43b3090489a9da433e8a30ee7188ba8b0a9a1ccf0c229283e53

  B.2.2.  PSK Setup Information



































  Barnes, et al.          Expires 21 September 2025              [Page 61]


  Internet-Draft                    HPKE                        March 2025


     mode: 1
     kem_id: 32
     kdf_id: 1
     aead_id: 3
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     35706a0b09fb26fb45c39c2f5079c709c7cf98e43afa973f14d88ece7e29c2e3
     pkEm:
     2261299c3f40a9afc133b969a97f05e95be2c514e54f3de26cbe5644ac735b04
     skEm:
     0c35fdf49df7aa01cd330049332c40411ebba36e0c718ebc3edf5845795f6321
     ikmR:
     26b923eade72941c8a85b09986cdfa3f1296852261adedc52d58d2930269812b
     pkRm:
     13640af826b722fc04feaa4de2f28fbd5ecc03623b317834e7ff4120dbe73062
     skRm:
     77d114e0212be51cb1d76fa99dd41cfd4d0166b08caa09074430a6c59ef17879
     psk:
     0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
     psk_id: 456e6e796e20447572696e206172616e204d6f726961
     enc:
     2261299c3f40a9afc133b969a97f05e95be2c514e54f3de26cbe5644ac735b04
     shared_secret:
     4be079c5e77779d0215b3f689595d59e3e9b0455d55662d1f3666ec606e50ea7
     key_schedule_context: 016870c4c76ca38ae43efbec0f2377d109499d7ce73f4a
     9e1ec37f21d3d063b97cb69c5718a60cc5876c358d3f7fc31ddb598503f67be58ea1
     e798c0bb19eb9796
     secret:
     16974354c497c9bd24c000ceed693779b604f1944975b18c442d373663f4a8cc
     key:
     600d2fdb0313a7e5c86a9ce9221cd95bed069862421744cfb4ab9d7203a9c019
     base_nonce: 112e0465562045b7368653e7
     exporter_secret:
     73b506dc8b6b4269027f80b0362def5cbb57ee50eed0c2873dac9181f453c5ac

  B.2.2.1.  Encryptions















  Barnes, et al.          Expires 21 September 2025              [Page 62]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 112e0465562045b7368653e7
     ct: 4a177f9c0d6f15cfdf533fb65bf84aecdc6ab16b8b85b4cf65a370e07fc1d78d
     28fb073214525276f4a89608ff

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 112e0465562045b7368653e6
     ct: 5c3cabae2f0b3e124d8d864c116fd8f20f3f56fda988c3573b40b09997fd6c76
     9e77c8eda6cda4f947f5b704a8

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 112e0465562045b7368653e5
     ct: 14958900b44bdae9cbe5a528bf933c5c990dbb8e282e6e495adf8205d19da9eb
     270e3a6f1e0613ab7e757962a4

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 112e0465562045b7368653e3
     ct: c2a7bc09ddb853cf2effb6e8d058e346f7fe0fb3476528c80db6b698415c5f8c
     50b68a9a355609e96d2117f8d3

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 112e0465562045b736865318
     ct: 2414d0788e4bc39a59a26d7bd5d78e111c317d44c37bd5a4c2a1235f2ddc2085
     c487d406490e75210c958724a7

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 112e0465562045b7368652e7
     ct: c567ae1c3f0f75abe1dd9e4532b422600ed4a6e5b9484dafb1e43ab9f5fd662b
     28c00e2e81d3cde955dae7e218

  B.2.2.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025              [Page 63]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     813c1bfc516c99076ae0f466671f0ba5ff244a41699f7b2417e4c59d46d39f40

     exporter_context: 00
     L: 32
     exported_value:
     2745cf3d5bb65c333658732954ee7af49eb895ce77f8022873a62a13c94cb4e1

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     ad40e3ae14f21c99bfdebc20ae14ab86f4ca2dc9a4799d200f43a25f99fa78ae

  B.2.3.  Auth Setup Information



































  Barnes, et al.          Expires 21 September 2025              [Page 64]


  Internet-Draft                    HPKE                        March 2025


     mode: 2
     kem_id: 32
     kdf_id: 1
     aead_id: 3
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     938d3daa5a8904540bc24f48ae90eed3f4f7f11839560597b55e7c9598c996c0
     pkEm:
     f7674cc8cd7baa5872d1f33dbaffe3314239f6197ddf5ded1746760bfc847e0e
     skEm:
     c94619e1af28971c8fa7957192b7e62a71ca2dcdde0a7cc4a8a9e741d600ab13
     ikmR:
     64835d5ee64aa7aad57c6f2e4f758f7696617f8829e70bc9ac7a5ef95d1c756c
     pkRm:
     1a478716d63cb2e16786ee93004486dc151e988b34b475043d3e0175bdb01c44
     skRm:
     3ca22a6d1cda1bb9480949ec5329d3bf0b080ca4c45879c95eddb55c70b80b82
     ikmS:
     9d8f94537d5a3ddef71234c0baedfad4ca6861634d0b94c3007fed557ad17df6
     pkSm:
     f0f4f9e96c54aeed3f323de8534fffd7e0577e4ce269896716bcb95643c8712b
     skSm:
     2def0cb58ffcf83d1062dd085c8aceca7f4c0c3fd05912d847b61f3e54121f05
     enc:
     f7674cc8cd7baa5872d1f33dbaffe3314239f6197ddf5ded1746760bfc847e0e
     shared_secret:
     d2d67828c8bc9fa661cf15a31b3ebf1febe0cafef7abfaaca580aaf6d471e3eb
     key_schedule_context: 02431df6cd95e11ff49d7013563baf7f11588c75a6611e
     e2a4404a49306ae4cfc5b69c5718a60cc5876c358d3f7fc31ddb598503f67be58ea1
     e798c0bb19eb9796
     secret:
     3022dfc0a81d6e09a2e6daeeb605bb1ebb9ac49535540d9a4c6560064a6c6da8
     key:
     b071fd1136680600eb447a845a967d35e9db20749cdf9ce098bcc4deef4b1356
     base_nonce: d20577dff16d7cea2c4bf780
     exporter_secret:
     be2d93b82071318cdb88510037cf504344151f2f9b9da8ab48974d40a2251dd7

  B.2.3.1.  Encryptions












  Barnes, et al.          Expires 21 September 2025              [Page 65]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: d20577dff16d7cea2c4bf780
     ct: ab1a13c9d4f01a87ec3440dbd756e2677bd2ecf9df0ce7ed73869b98e00c09be
     111cb9fdf077347aeb88e61bdf

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: d20577dff16d7cea2c4bf781
     ct: 3265c7807ffff7fdace21659a2c6ccffee52a26d270c76468ed74202a65478bf
     aedfff9c2b7634e24f10b71016

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: d20577dff16d7cea2c4bf782
     ct: 3aadee86ad2a05081ea860033a9d09dbccb4acac2ded0891da40f51d4df19925
     f7a767b076a5cbc9355c8fd35e

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: d20577dff16d7cea2c4bf784
     ct: 502ecccd5c2be3506a081809cc58b43b94f77cbe37b8b31712d9e21c9e61aa69
     46a8e922f54eae630f88eb8033

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: d20577dff16d7cea2c4bf77f
     ct: 652e597ba20f3d9241cda61f33937298b1169e6adf72974bbe454297502eb4be
     132e1c5064702fc165c2ddbde8

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: d20577dff16d7cea2c4bf680
     ct: 3be14e8b3bbd1028cf2b7d0a691dbbeff71321e7dec92d3c2cfb30a0994ab246
     af76168480285a60037b4ba13a

  B.2.3.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025              [Page 66]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     070cffafd89b67b7f0eeb800235303a223e6ff9d1e774dce8eac585c8688c872

     exporter_context: 00
     L: 32
     exported_value:
     2852e728568d40ddb0edde284d36a4359c56558bb2fb8837cd3d92e46a3a14a8

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     1df39dc5dd60edcbf5f9ae804e15ada66e885b28ed7929116f768369a3f950ee

  B.2.4.  AuthPSK Setup Information



































  Barnes, et al.          Expires 21 September 2025              [Page 67]


  Internet-Draft                    HPKE                        March 2025


     mode: 3
     kem_id: 32
     kdf_id: 1
     aead_id: 3
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     49d6eac8c6c558c953a0a252929a818745bb08cd3d29e15f9f5db5eb2e7d4b84
     pkEm:
     656a2e00dc9990fd189e6e473459392df556e9a2758754a09db3f51179a3fc02
     skEm:
     5e6dd73e82b856339572b7245d3cbb073a7561c0bee52873490e305cbb710410
     ikmR:
     f3304ddcf15848488271f12b75ecaf72301faabf6ad283654a14c398832eb184
     pkRm:
     a5099431c35c491ec62ca91df1525d6349cb8aa170c51f9581f8627be6334851
     skRm:
     7b36a42822e75bf3362dfabbe474b3016236408becb83b859a6909e22803cb0c
     ikmS:
     20ade1d5203de1aadfb261c4700b6432e260d0d317be6ebbb8d7fffb1f86ad9d
     pkSm:
     3ac5bd4dd66ff9f2740bef0d6ccb66daa77bff7849d7895182b07fb74d087c45
     skSm:
     90761c5b0a7ef0985ed66687ad708b921d9803d51637c8d1cb72d03ed0f64418
     psk:
     0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
     psk_id: 456e6e796e20447572696e206172616e204d6f726961
     enc:
     656a2e00dc9990fd189e6e473459392df556e9a2758754a09db3f51179a3fc02
     shared_secret:
     86a6c0ed17714f11d2951747e660857a5fd7616c933ef03207808b7a7123fe67
     key_schedule_context: 036870c4c76ca38ae43efbec0f2377d109499d7ce73f4a
     9e1ec37f21d3d063b97cb69c5718a60cc5876c358d3f7fc31ddb598503f67be58ea1
     e798c0bb19eb9796
     secret:
     22670daee17530c9564001d0a7e740e80d0bcc7ae15349f472fcc9e057cbc259
     key:
     49c7e6d7d2d257aded2a746fe6a9bf12d4de8007c4862b1fdffe8c35fb65054c
     base_nonce: abac79931e8c1bcb8a23960a
     exporter_secret:
     7c6cc1bb98993cd93e2599322247a58fd41fdecd3db895fb4c5fd8d6bbe606b5

  B.2.4.1.  Encryptions









  Barnes, et al.          Expires 21 September 2025              [Page 68]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: abac79931e8c1bcb8a23960a
     ct: 9aa52e29274fc6172e38a4461361d2342585d3aeec67fb3b721ecd63f059577c
     7fe886be0ede01456ebc67d597

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: abac79931e8c1bcb8a23960b
     ct: 59460bacdbe7a920ef2806a74937d5a691d6d5062d7daafcad7db7e4d8c649ad
     ffe575c1889c5c2e3a49af8e3e

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: abac79931e8c1bcb8a239608
     ct: 5688ff6a03ba26ae936044a5c800f286fb5d1eccdd2a0f268f6ff9773b511693
     18d1a1466bb36263415071db00

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: abac79931e8c1bcb8a23960e
     ct: d936b7a01f5c7dc4c3dc04e322cc694684ee18dd71719196874e5235aed3cfb0
     6cadcd3bc7da0877488d7c551d

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: abac79931e8c1bcb8a2396f5
     ct: 4d4c462f7b9b637eaf1f4e15e325b7bc629c0af6e3073422c86064cc3c98cff8
     7300f054fd56dd57dc34358beb

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: abac79931e8c1bcb8a23970a
     ct: 9b7f84224922d2a9edd7b2c2057f3bcf3a547f17570575e626202e593bfdd99e
     9878a1af9e41ded58c7fb77d2f

  B.2.4.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025              [Page 69]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     c23ebd4e7a0ad06a5dddf779f65004ce9481069ce0f0e6dd51a04539ddcbd5cd

     exporter_context: 00
     L: 32
     exported_value:
     ed7ff5ca40a3d84561067ebc8e01702bc36cf1eb99d42a92004642b9dfaadd37

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     d3bae066aa8da27d527d85c040f7dd6ccb60221c902ee36a82f70bcd62a60ee4

  B.3.  DHKEM(P-256, HKDF-SHA256), HKDF-SHA256, AES-128-GCM

  B.3.1.  Base Setup Information

































  Barnes, et al.          Expires 21 September 2025              [Page 70]


  Internet-Draft                    HPKE                        March 2025


     mode: 0
     kem_id: 16
     kdf_id: 1
     aead_id: 1
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     4270e54ffd08d79d5928020af4686d8f6b7d35dbe470265f1f5aa22816ce860e
     pkEm: 04a92719c6195d5085104f469a8b9814d5838ff72b60501e2c4466e5e67b32
     5ac98536d7b61a1af4b78e5b7f951c0900be863c403ce65c9bfcb9382657222d18c4
     skEm:
     4995788ef4b9d6132b249ce59a77281493eb39af373d236a1fe415cb0c2d7beb
     ikmR:
     668b37171f1072f3cf12ea8a236a45df23fc13b82af3609ad1e354f6ef817550
     pkRm: 04fe8c19ce0905191ebc298a9245792531f26f0cece2460639e8bc39cb7f70
     6a826a779b4cf969b8a0e539c7f62fb3d30ad6aa8f80e30f1d128aafd68a2ce72ea0
     skRm:
     f3ce7fdae57e1a310d87f1ebbde6f328be0a99cdbcadf4d6589cf29de4b8ffd2
     enc: 04a92719c6195d5085104f469a8b9814d5838ff72b60501e2c4466e5e67b325
     ac98536d7b61a1af4b78e5b7f951c0900be863c403ce65c9bfcb9382657222d18c4
     shared_secret:
     c0d26aeab536609a572b07695d933b589dcf363ff9d93c93adea537aeabb8cb8
     key_schedule_context: 00b88d4e6d91759e65e87c470e8b9141113e9ad5f0c8ce
     efc1e088c82e6980500798e486f9c9c09c9b5c753ac72d6005de254c607d1b534ed1
     1d493ae1c1d9ac85
     secret:
     2eb7b6bf138f6b5aff857414a058a3f1750054a9ba1f72c2cf0684a6f20b10e1
     key: 868c066ef58aae6dc589b6cfdd18f97e
     base_nonce: 4e0bc5018beba4bf004cca59
     exporter_secret:
     14ad94af484a7ad3ef40e9f3be99ecc6fa9036df9d4920548424df127ee0d99f

  B.3.1.1.  Encryptions



















  Barnes, et al.          Expires 21 September 2025              [Page 71]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 4e0bc5018beba4bf004cca59
     ct: 5ad590bb8baa577f8619db35a36311226a896e7342a6d836d8b7bcd2f20b6c7f
     9076ac232e3ab2523f39513434

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 4e0bc5018beba4bf004cca58
     ct: fa6f037b47fc21826b610172ca9637e82d6e5801eb31cbd3748271affd4ecb06
     646e0329cbdf3c3cd655b28e82

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 4e0bc5018beba4bf004cca5b
     ct: 895cabfac50ce6c6eb02ffe6c048bf53b7f7be9a91fc559402cbc5b8dcaeb52b
     2ccc93e466c28fb55fed7a7fec

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 4e0bc5018beba4bf004cca5d
     ct: 8787491ee8df99bc99a246c4b3216d3d57ab5076e18fa27133f520703bc70ec9
     99dd36ce042e44f0c3169a6a8f

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 4e0bc5018beba4bf004ccaa6
     ct: 2ad71c85bf3f45c6eca301426289854b31448bcf8a8ccb1deef3ebd87f60848a
     a53c538c30a4dac71d619ee2cd

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 4e0bc5018beba4bf004ccb59
     ct: 10f179686aa2caec1758c8e554513f16472bd0a11e2a907dde0b212cbe87d74f
     367f8ffe5e41cd3e9962a6afb2

  B.3.1.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025              [Page 72]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     5e9bc3d236e1911d95e65b576a8a86d478fb827e8bdfe77b741b289890490d4d

     exporter_context: 00
     L: 32
     exported_value:
     6cff87658931bda83dc857e6353efe4987a201b849658d9b047aab4cf216e796

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     d8f1ea7942adbba7412c6d431c62d01371ea476b823eb697e1f6e6cae1dab85a

  B.3.2.  PSK Setup Information



































  Barnes, et al.          Expires 21 September 2025              [Page 73]


  Internet-Draft                    HPKE                        March 2025


     mode: 1
     kem_id: 16
     kdf_id: 1
     aead_id: 1
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     2afa611d8b1a7b321c761b483b6a053579afa4f767450d3ad0f84a39fda587a6
     pkEm: 04305d35563527bce037773d79a13deabed0e8e7cde61eecee403496959e89
     e4d0ca701726696d1485137ccb5341b3c1c7aaee90a4a02449725e744b1193b53b5f
     skEm:
     57427244f6cc016cddf1c19c8973b4060aa13579b4c067fd5d93a5d74e32a90f
     ikmR:
     d42ef874c1913d9568c9405407c805baddaffd0898a00f1e84e154fa787b2429
     pkRm: 040d97419ae99f13007a93996648b2674e5260a8ebd2b822e84899cd52d874
     46ea394ca76223b76639eccdf00e1967db10ade37db4e7db476261fcc8df97c5ffd1
     skRm:
     438d8bcef33b89e0e9ae5eb0957c353c25a94584b0dd59c991372a75b43cb661
     psk:
     0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
     psk_id: 456e6e796e20447572696e206172616e204d6f726961
     enc: 04305d35563527bce037773d79a13deabed0e8e7cde61eecee403496959e89e
     4d0ca701726696d1485137ccb5341b3c1c7aaee90a4a02449725e744b1193b53b5f
     shared_secret:
     2e783ad86a1beae03b5749e0f3f5e9bb19cb7eb382f2fb2dd64c99f15ae0661b
     key_schedule_context: 01b873cdf2dff4c1434988053b7a775e980dd2039ea24f
     950b26b056ccedcb933198e486f9c9c09c9b5c753ac72d6005de254c607d1b534ed1
     1d493ae1c1d9ac85
     secret:
     f2f534e55931c62eeb2188c1f53450354a725183937e68c85e68d6b267504d26
     key: 55d9eb9d26911d4c514a990fa8d57048
     base_nonce: b595dc6b2d7e2ed23af529b1
     exporter_secret:
     895a723a1eab809804973a53c0ee18ece29b25a7555a4808277ad2651d66d705

  B.3.2.1.  Encryptions
















  Barnes, et al.          Expires 21 September 2025              [Page 74]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: b595dc6b2d7e2ed23af529b1
     ct: 90c4deb5b75318530194e4bb62f890b019b1397bbf9d0d6eb918890e1fb2be1a
     c2603193b60a49c2126b75d0eb

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: b595dc6b2d7e2ed23af529b0
     ct: 9e223384a3620f4a75b5a52f546b7262d8826dea18db5a365feb8b997180b22d
     72dc1287f7089a1073a7102c27

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: b595dc6b2d7e2ed23af529b3
     ct: adf9f6000773035023be7d415e13f84c1cb32a24339a32eb81df02be9ddc6abc
     880dd81cceb7c1d0c7781465b2

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: b595dc6b2d7e2ed23af529b5
     ct: 1f4cc9b7013d65511b1f69c050b7bd8bbd5a5c16ece82b238fec4f30ba2400e7
     ca8ee482ac5253cffb5c3dc577

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: b595dc6b2d7e2ed23af5294e
     ct: cdc541253111ed7a424eea5134dc14fc5e8293ab3b537668b8656789628e4589
     4e5bb873c968e3b7cdcbb654a4

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: b595dc6b2d7e2ed23af528b1
     ct: faf985208858b1253b97b60aecd28bc18737b58d1242370e7703ec33b73a4c31
     a1afee300e349adef9015bbbfd

  B.3.2.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025              [Page 75]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     a115a59bf4dd8dc49332d6a0093af8efca1bcbfd3627d850173f5c4a55d0c185

     exporter_context: 00
     L: 32
     exported_value:
     4517eaede0669b16aac7c92d5762dd459c301fa10e02237cd5aeb9be969430c4

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     164e02144d44b607a7722e58b0f4156e67c0c2874d74cf71da6ca48a4cbdc5e0

  B.3.3.  Auth Setup Information



































  Barnes, et al.          Expires 21 September 2025              [Page 76]


  Internet-Draft                    HPKE                        March 2025


     mode: 2
     kem_id: 16
     kdf_id: 1
     aead_id: 1
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     798d82a8d9ea19dbc7f2c6dfa54e8a6706f7cdc119db0813dacf8440ab37c857
     pkEm: 042224f3ea800f7ec55c03f29fc9865f6ee27004f818fcbdc6dc68932c1e52
     e15b79e264a98f2c535ef06745f3d308624414153b22c7332bc1e691cb4af4d53454
     skEm:
     6b8de0873aed0c1b2d09b8c7ed54cbf24fdf1dfc7a47fa501f918810642d7b91
     ikmR:
     7bc93bde8890d1fb55220e7f3b0c107ae7e6eda35ca4040bb6651284bf0747ee
     pkRm: 04423e363e1cd54ce7b7573110ac121399acbc9ed815fae03b72ffbd4c18b0
     1836835c5a09513f28fc971b7266cfde2e96afe84bb0f266920e82c4f53b36e1a78d
     skRm:
     d929ab4be2e59f6954d6bedd93e638f02d4046cef21115b00cdda2acb2a4440e
     ikmS:
     874baa0dcf93595a24a45a7f042e0d22d368747daaa7e19f80a802af19204ba8
     pkSm: 04a817a0902bf28e036d66add5d544cc3a0457eab150f104285df1e293b5c1
     0eef8651213e43d9cd9086c80b309df22cf37609f58c1127f7607e85f210b2804f73
     skSm:
     1120ac99fb1fccc1e8230502d245719d1b217fe20505c7648795139d177f0de9
     enc: 042224f3ea800f7ec55c03f29fc9865f6ee27004f818fcbdc6dc68932c1e52e
     15b79e264a98f2c535ef06745f3d308624414153b22c7332bc1e691cb4af4d53454
     shared_secret:
     d4aea336439aadf68f9348880aa358086f1480e7c167b6ef15453ba69b94b44f
     key_schedule_context: 02b88d4e6d91759e65e87c470e8b9141113e9ad5f0c8ce
     efc1e088c82e6980500798e486f9c9c09c9b5c753ac72d6005de254c607d1b534ed1
     1d493ae1c1d9ac85
     secret:
     fd0a93c7c6f6b1b0dd6a822d7b16f6c61c83d98ad88426df4613c3581a2319f1
     key: 19aa8472b3fdc530392b0e54ca17c0f5
     base_nonce: b390052d26b67a5b8a8fcaa4
     exporter_secret:
     f152759972660eb0e1db880835abd5de1c39c8e9cd269f6f082ed80e28acb164

  B.3.3.1.  Encryptions













  Barnes, et al.          Expires 21 September 2025              [Page 77]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: b390052d26b67a5b8a8fcaa4
     ct: 82ffc8c44760db691a07c5627e5fc2c08e7a86979ee79b494a17cc3405446ac2
     bdb8f265db4a099ed3289ffe19

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: b390052d26b67a5b8a8fcaa5
     ct: b0a705a54532c7b4f5907de51c13dffe1e08d55ee9ba59686114b05945494d96
     725b239468f1229e3966aa1250

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: b390052d26b67a5b8a8fcaa6
     ct: 8dc805680e3271a801790833ed74473710157645584f06d1b53ad439078d880b
     23e25256663178271c80ee8b7c

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: b390052d26b67a5b8a8fcaa0
     ct: 04c8f7aae1584b61aa5816382cb0b834a5d744f420e6dffb5ddcec633a21b8b3
     472820930c1ea9258b035937a2

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: b390052d26b67a5b8a8fca5b
     ct: 4a319462eaedee37248b4d985f64f4f863d31913fe9e30b6e13136053b69fe5d
     70853c84c60a84bb5495d5a678

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: b390052d26b67a5b8a8fcba4
     ct: 28e874512f8940fafc7d06135e7589f6b4198bc0f3a1c64702e72c9e6abaf9f0
     5cb0d2f11b03a517898815c934

  B.3.3.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025              [Page 78]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     837e49c3ff629250c8d80d3c3fb957725ed481e59e2feb57afd9fe9a8c7c4497

     exporter_context: 00
     L: 32
     exported_value:
     594213f9018d614b82007a7021c3135bda7b380da4acd9ab27165c508640dbda

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     14fe634f95ca0d86e15247cca7de7ba9b73c9b9deb6437e1c832daf7291b79d5

  B.3.4.  AuthPSK Setup Information



































  Barnes, et al.          Expires 21 September 2025              [Page 79]


  Internet-Draft                    HPKE                        March 2025


     mode: 3
     kem_id: 16
     kdf_id: 1
     aead_id: 1
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     3c1fceb477ec954c8d58ef3249e4bb4c38241b5925b95f7486e4d9f1d0d35fbb
     pkEm: 046a1de3fc26a3d43f4e4ba97dbe24f7e99181136129c48fbe872d4743e2b1
     31357ed4f29a7b317dc22509c7b00991ae990bf65f8b236700c82ab7c11a84511401
     skEm:
     36f771e411cf9cf72f0701ef2b991ce9743645b472e835fe234fb4d6eb2ff5a0
     ikmR:
     abcc2da5b3fa81d8aabd91f7f800a8ccf60ec37b1b585a5d1d1ac77f258b6cca
     pkRm: 04d824d7e897897c172ac8a9e862e4bd820133b8d090a9b188b8233a64dfbc
     5f725aa0aa52c8462ab7c9188f1c4872f0c99087a867e8a773a13df48a627058e1b3
     skRm:
     bdf4e2e587afdf0930644a0c45053889ebcadeca662d7c755a353d5b4e2a8394
     ikmS:
     6262031f040a9db853edd6f91d2272596eabbc78a2ed2bd643f770ecd0f19b82
     pkSm: 049f158c750e55d8d5ad13ede66cf6e79801634b7acadcad72044eac2ae1d0
     480069133d6488bf73863fa988c4ba8bde1c2e948b761274802b4d8012af4f13af9e
     skSm:
     b0ed8721db6185435898650f7a677affce925aba7975a582653c4cb13c72d240
     psk:
     0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
     psk_id: 456e6e796e20447572696e206172616e204d6f726961
     enc: 046a1de3fc26a3d43f4e4ba97dbe24f7e99181136129c48fbe872d4743e2b13
     1357ed4f29a7b317dc22509c7b00991ae990bf65f8b236700c82ab7c11a84511401
     shared_secret:
     d4c27698391db126f1612d9e91a767f10b9b19aa17e1695549203f0df7d9aebe
     key_schedule_context: 03b873cdf2dff4c1434988053b7a775e980dd2039ea24f
     950b26b056ccedcb933198e486f9c9c09c9b5c753ac72d6005de254c607d1b534ed1
     1d493ae1c1d9ac85
     secret:
     3bf9d4c7955da2740414e73081fa74d6f6f2b4b9645d0685219813ce99a2f270
     key: 4d567121d67fae1227d90e11585988fb
     base_nonce: 67c9d05330ca21e5116ecda6
     exporter_secret:
     3f479020ae186788e4dfd4a42a21d24f3faabb224dd4f91c2b2e5e9524ca27b2

  B.3.4.1.  Encryptions










  Barnes, et al.          Expires 21 September 2025              [Page 80]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 67c9d05330ca21e5116ecda6
     ct: b9f36d58d9eb101629a3e5a7b63d2ee4af42b3644209ab37e0a272d44365407d
     b8e655c72e4fa46f4ff81b9246

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 67c9d05330ca21e5116ecda7
     ct: 51788c4e5d56276771032749d015d3eea651af0c7bb8e3da669effffed299ea1
     f641df621af65579c10fc09736

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 67c9d05330ca21e5116ecda4
     ct: 3b5a2be002e7b29927f06442947e1cf709b9f8508b03823127387223d7127034
     71c266efc355f1bc2036f3027c

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 67c9d05330ca21e5116ecda2
     ct: 8ddbf1242fe5c7d61e1675496f3bfdb4d90205b3dfbc1b12aab41395d71a8211
     8e095c484103107cf4face5123

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 67c9d05330ca21e5116ecd59
     ct: 6de25ceadeaec572fbaa25eda2558b73c383fe55106abaec24d518ef6724a7ce
     698f83ecdc53e640fe214d2f42

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 67c9d05330ca21e5116ecca6
     ct: f380e19d291e12c5e378b51feb5cd50f6d00df6cb2af8393794c4df342126c2e
     29633fe7e8ce49587531affd4d

  B.3.4.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025              [Page 81]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     595ce0eff405d4b3bb1d08308d70a4e77226ce11766e0a94c4fdb5d90025c978

     exporter_context: 00
     L: 32
     exported_value:
     110472ee0ae328f57ef7332a9886a1992d2c45b9b8d5abc9424ff68630f7d38d

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     18ee4d001a9d83a4c67e76f88dd747766576cac438723bad0700a910a4d717e6

  B.4.  DHKEM(P-256, HKDF-SHA256), HKDF-SHA512, AES-128-GCM

  B.4.1.  Base Setup Information

































  Barnes, et al.          Expires 21 September 2025              [Page 82]


  Internet-Draft                    HPKE                        March 2025


     mode: 0
     kem_id: 16
     kdf_id: 3
     aead_id: 1
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     4ab11a9dd78c39668f7038f921ffc0993b368171d3ddde8031501ee1e08c4c9a
     pkEm: 0493ed86735bdfb978cc055c98b45695ad7ce61ce748f4dd63c525a3b8d53a
     15565c6897888070070c1579db1f86aaa56deb8297e64db7e8924e72866f9a472580
     skEm:
     2292bf14bb6e15b8c81a0f45b7a6e93e32d830e48cca702e0affcfb4d07e1b5c
     ikmR:
     ea9ff7cc5b2705b188841c7ace169290ff312a9cb31467784ca92d7a2e6e1be8
     pkRm: 04085aa5b665dc3826f9650ccbcc471be268c8ada866422f739e2d531d4a88
     18a9466bc6b449357096232919ec4fe9070ccbac4aac30f4a1a53efcf7af90610edd
     skRm:
     3ac8530ad1b01885960fab38cf3cdc4f7aef121eaa239f222623614b4079fb38
     enc: 0493ed86735bdfb978cc055c98b45695ad7ce61ce748f4dd63c525a3b8d53a1
     5565c6897888070070c1579db1f86aaa56deb8297e64db7e8924e72866f9a472580
     shared_secret:
     02f584736390fc93f5b4ad039826a3fa08e9911bd1215a3db8e8791ba533cafd
     key_schedule_context: 005b8a3617af7789ee716e7911c7e77f84cdc4cc46e60f
     b7e19e4059f9aeadc00585e26874d1ddde76e551a7679cd47168c466f6e1f705cc93
     74c192778a34fcd5ca221d77e229a9d11b654de7942d685069c633b2362ce3b3d8ea
     4891c9a2a87a4eb7cdb289ba5e2ecbf8cd2c8498bb4a383dc021454d70d46fcbbad1
     252ef4f9
     secret: 0c7acdab61693f936c4c1256c78e7be30eebfe466812f9cc49f0b58dc970
     328dfc03ea359be0250a471b1635a193d2dfa8cb23c90aa2e25025b892a725353eeb
     key: 090ca96e5f8aa02b69fac360da50ddf9
     base_nonce: 9c995e621bf9a20c5ca45546
     exporter_secret: 4a7abb2ac43e6553f129b2c5750a7e82d149a76ed56dc342d7b
     ca61e26d494f4855dff0d0165f27ce57756f7f16baca006539bb8e4518987ba61048
     0ac03efa8

  B.4.1.1.  Encryptions
















  Barnes, et al.          Expires 21 September 2025              [Page 83]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 9c995e621bf9a20c5ca45546
     ct: d3cf4984931484a080f74c1bb2a6782700dc1fef9abe8442e44a6f09044c8890
     7200b332003543754eb51917ba

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 9c995e621bf9a20c5ca45547
     ct: d14414555a47269dfead9fbf26abb303365e40709a4ed16eaefe1f2070f1ddeb
     1bdd94d9e41186f124e0acc62d

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 9c995e621bf9a20c5ca45544
     ct: 9bba136cade5c4069707ba91a61932e2cbedda2d9c7bdc33515aa01dd0e0f7e9
     d3579bf4016dec37da4aafa800

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 9c995e621bf9a20c5ca45542
     ct: a531c0655342be013bf32112951f8df1da643602f1866749519f5dcb09cc6843
     2579de305a77e6864e862a7600

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 9c995e621bf9a20c5ca455b9
     ct: be5da649469efbad0fb950366a82a73fefeda5f652ec7d3731fac6c4ffa21a70
     04d2ab8a04e13621bd3629547d

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 9c995e621bf9a20c5ca45446
     ct: 62092672f5328a0dde095e57435edf7457ace60b26ee44c9291110ec135cb0e1
     4b85594e4fea11247d937deb62

  B.4.1.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025              [Page 84]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     a32186b8946f61aeead1c093fe614945f85833b165b28c46bf271abf16b57208

     exporter_context: 00
     L: 32
     exported_value:
     84998b304a0ea2f11809398755f0abd5f9d2c141d1822def79dd15c194803c2a

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     93fb9411430b2cfa2cf0bed448c46922a5be9beff20e2e621df7e4655852edbc

  B.4.2.  PSK Setup Information



































  Barnes, et al.          Expires 21 September 2025              [Page 85]


  Internet-Draft                    HPKE                        March 2025


     mode: 1
     kem_id: 16
     kdf_id: 3
     aead_id: 1
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     c11d883d6587f911d2ddbc2a0859d5b42fb13bf2c8e89ef408a25564893856f5
     pkEm: 04a307934180ad5287f95525fe5bc6244285d7273c15e061f0f2efb211c350
     57f3079f6e0abae200992610b25f48b63aacfcb669106ddee8aa023feed301901371
     skEm:
     a5901ff7d6931959c2755382ea40a4869b1dec3694ed3b009dda2d77dd488f18
     ikmR:
     75bfc2a3a3541170a54c0b06444e358d0ee2b4fb78a401fd399a47a33723b700
     pkRm: 043f5266fba0742db649e1043102b8a5afd114465156719cea90373229aabd
     d84d7f45dabfc1f55664b888a7e86d594853a6cccdc9b189b57839cbbe3b90b55873
     skRm:
     bc6f0b5e22429e5ff47d5969003f3cae0f4fec50e23602e880038364f33b8522
     psk:
     0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
     psk_id: 456e6e796e20447572696e206172616e204d6f726961
     enc: 04a307934180ad5287f95525fe5bc6244285d7273c15e061f0f2efb211c3505
     7f3079f6e0abae200992610b25f48b63aacfcb669106ddee8aa023feed301901371
     shared_secret:
     2912aacc6eaebd71ff715ea50f6ef3a6637856b2a4c58ea61e0c3fc159e3bc16
     key_schedule_context: 01713f73042575cebfd132f0cc4338523f8eae95c80a74
     9f7cf3eb9436ff1c612ca62c37df27ca46d2cc162445a92c5f5fdc57bcde129ca7b1
     f284b0c12297c037ca221d77e229a9d11b654de7942d685069c633b2362ce3b3d8ea
     4891c9a2a87a4eb7cdb289ba5e2ecbf8cd2c8498bb4a383dc021454d70d46fcbbad1
     252ef4f9
     secret: ff2051d2128d5f3078de867143e076262ce1d0aecafc3fff3d607f1eaff0
     5345c7d5ffcb3202cdecb3d1a2f7da20592a237747b6e855390cbe2109d3e6ac70c2
     key: 0b910ba8d9cfa17e5f50c211cb32839a
     base_nonce: 0c29e714eb52de5b7415a1b7
     exporter_secret: 50c0a182b6f94b4c0bd955c4aa20df01f282cc12c43065a0812
     fe4d4352790171ed2b2c4756ad7f5a730ba336c8f1edd0089d8331192058c385bae3
     9c7cc8b57

  B.4.2.1.  Encryptions













  Barnes, et al.          Expires 21 September 2025              [Page 86]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 0c29e714eb52de5b7415a1b7
     ct: 57624b6e320d4aba0afd11f548780772932f502e2ba2a8068676b2a0d3b5129a
     45b9faa88de39e8306da41d4cc

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 0c29e714eb52de5b7415a1b6
     ct: 159d6b4c24bacaf2f5049b7863536d8f3ffede76302dace42080820fa51925d4
     e1c72a64f87b14291a3057e00a

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 0c29e714eb52de5b7415a1b5
     ct: bd24140859c99bf0055075e9c460032581dd1726d52cf980d308e9b20083ca62
     e700b17892bcf7fa82bac751d0

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 0c29e714eb52de5b7415a1b3
     ct: 93ddd55f82e9aaaa3cfc06840575f09d80160b20538125c2549932977d1238dd
     e8126a4a91118faf8632f62cb8

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 0c29e714eb52de5b7415a148
     ct: 377a98a3c34bf716581b05a6b3fdc257f245856384d5f2241c8840571c52f5c8
     5c21138a4a81655edab8fe227d

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 0c29e714eb52de5b7415a0b7
     ct: cc161f5a179831d456d119d2f2c19a6817289c75d1c61cd37ac8a450acd9efba
     02e0ac00d128c17855931ff69a

  B.4.2.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025              [Page 87]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     8158bea21a6700d37022bb7802866edca30ebf2078273757b656ef7fc2e428cf

     exporter_context: 00
     L: 32
     exported_value:
     6a348ba6e0e72bb3ef22479214a139ef8dac57be34509a61087a12565473da8d

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     2f6d4f7a18ec48de1ef4469f596aada4afdf6d79b037ed3c07e0118f8723bffc

  B.4.3.  Auth Setup Information



































  Barnes, et al.          Expires 21 September 2025              [Page 88]


  Internet-Draft                    HPKE                        March 2025


     mode: 2
     kem_id: 16
     kdf_id: 3
     aead_id: 1
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     6bb031aa9197562da0b44e737db2b9e61f6c3ea1138c37de28fc37ac29bc7350
     pkEm: 04fec59fa9f76f5d0f6c1660bb179cb314ed97953c53a60ab38f8e6ace60fd
     59178084d0dd66e0f79172992d4ddb2e91172ce24949bcebfff158dcc417f2c6e9c6
     skEm:
     93cddd5288e7ef4884c8fe321d075df01501b993ff49ffab8184116f39b3c655
     ikmR:
     649a3f92edbb7a2516a0ade0b7dccc58a37240c4ba06f9726a952227b4adf6ff
     pkRm: 04378bad519aab406e04d0e5608bcca809c02d6afd2272d4dd03e9357bd0ee
     e8adf84c8deba3155c9cf9506d1d4c8bfefe3cf033a75716cc3cc07295100ec96276
     skRm:
     1ea4484be482bf25fdb2ed39e6a02ed9156b3e57dfb18dff82e4a048de990236
     ikmS:
     4d79b8691aab55a7265e8490a04bb3860ed64dece90953ad0dc43a6ea59b4bf2
     pkSm: 0404d3c1f9fca22eb4a6d326125f0814c35593b1da8ea0d11a640730b215a2
     59b9b98a34ad17e21617d19fe1d4fa39a4828bfdb306b729ec51c543caca3b2d9529
     skSm:
     02b266d66919f7b08f42ae0e7d97af4ca98b2dae3043bb7e0740ccadc1957579
     enc: 04fec59fa9f76f5d0f6c1660bb179cb314ed97953c53a60ab38f8e6ace60fd5
     9178084d0dd66e0f79172992d4ddb2e91172ce24949bcebfff158dcc417f2c6e9c6
     shared_secret:
     1ed49f6d7ada333d171cd63861a1cb700a1ec4236755a9cd5f9f8f67a2f8e7b3
     key_schedule_context: 025b8a3617af7789ee716e7911c7e77f84cdc4cc46e60f
     b7e19e4059f9aeadc00585e26874d1ddde76e551a7679cd47168c466f6e1f705cc93
     74c192778a34fcd5ca221d77e229a9d11b654de7942d685069c633b2362ce3b3d8ea
     4891c9a2a87a4eb7cdb289ba5e2ecbf8cd2c8498bb4a383dc021454d70d46fcbbad1
     252ef4f9
     secret: 9c846ba81ddbbd57bc26d99da6cf7ab956bb735ecd47fe21ed14241c7079
     1b7484c1d06663d21a5d97bf1be70d56ab727f650c4f859c5ed3f71f8928b3c082dd
     key: 9d4b1c83129f3de6db95faf3d539dcf1
     base_nonce: ea4fd7a485ee5f1f4b62c1b7
     exporter_secret: ca2410672369aae1afd6c2639f4fe34ca36d35410c090608d29
     24f60def17f910d7928575434d7f991b1f19d3e8358b8278ff59ced0d5eed4774cec
     72e12766e

  B.4.3.1.  Encryptions










  Barnes, et al.          Expires 21 September 2025              [Page 89]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: ea4fd7a485ee5f1f4b62c1b7
     ct: 2480179d880b5f458154b8bfe3c7e8732332de84aabf06fc440f6b31f169e154
     157fa9eb44f2fa4d7b38a9236e

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: ea4fd7a485ee5f1f4b62c1b6
     ct: 10cd81e3a816d29942b602a92884348171a31cbd0f042c3057c65cd93c540943
     a5b05115bd520c09281061935b

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: ea4fd7a485ee5f1f4b62c1b5
     ct: 920743a88d8cf6a09e1a3098e8be8edd09db136e9d543f215924043af8c7410f
     68ce6aa64fd2b1a176e7f6b3fd

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: ea4fd7a485ee5f1f4b62c1b3
     ct: 6b11380fcc708fc8589effb5b5e0394cbd441fa5e240b5500522150ca8265d65
     ff55479405af936e2349119dcd

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: ea4fd7a485ee5f1f4b62c148
     ct: d084eca50e7554bb97ba34c4482dfe32c9a2b7f3ab009c2d1b68ecbf97bee2d2
     8cd94b6c829b96361f2701772d

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: ea4fd7a485ee5f1f4b62c0b7
     ct: 247da592cc4ce834a94de2c79f5730ee49342470a021e4a4bc2bb77c53b17413
     e94d94f57b4fdaedcf97cfe7b1

  B.4.3.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025              [Page 90]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     f03fbc82f321a0ab4840e487cb75d07aafd8e6f68485e4f7ff72b2f55ff24ad6

     exporter_context: 00
     L: 32
     exported_value:
     1ce0cadec0a8f060f4b5070c8f8888dcdfefc2e35819df0cd559928a11ff0891

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     70c405c707102fd0041ea716090753be47d68d238b111d542846bd0d84ba907c

  B.4.4.  AuthPSK Setup Information



































  Barnes, et al.          Expires 21 September 2025              [Page 91]


  Internet-Draft                    HPKE                        March 2025


     mode: 3
     kem_id: 16
     kdf_id: 3
     aead_id: 1
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     37ae06a521cd555648c928d7af58ad2aa4a85e34b8cabd069e94ad55ab872cc8
     pkEm: 04801740f4b1b35823f7fb2930eac2efc8c4893f34ba111c0bb976e3c7d5dc
     0aef5a7ef0bf4057949a140285f774f1efc53b3860936b92279a11b68395d898d138
     skEm:
     778f2254ae5d661d5c7fca8c4a7495a25bd13f26258e459159f3899df0de76c1
     ikmR:
     7466024b7e2d2366c3914d7833718f13afb9e3e45bcfbb510594d614ddd9b4e7
     pkRm: 04a4ca7af2fc2cce48edbf2f1700983e927743a4e85bb5035ad562043e25d9
     a111cbf6f7385fac55edc5c9d2ca6ed351a5643de95c36748e11dbec98730f4d43e9
     skRm:
     00510a70fde67af487c093234fc4215c1cdec09579c4b30cc8e48cb530414d0e
     ikmS:
     ee27aaf99bf5cd8398e9de88ac09a82ac22cdb8d0905ab05c0f5fa12ba1709f3
     pkSm: 04b59a4157a9720eb749c95f842a5e3e8acdccbe834426d405509ac3191e23
     f2165b5bb1f07a6240dd567703ae75e13182ee0f69fc102145cdb5abf681ff126d60
     skSm:
     d743b20821e6326f7a26684a4beed7088b35e392114480ca9f6c325079dcf10b
     psk:
     0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
     psk_id: 456e6e796e20447572696e206172616e204d6f726961
     enc: 04801740f4b1b35823f7fb2930eac2efc8c4893f34ba111c0bb976e3c7d5dc0
     aef5a7ef0bf4057949a140285f774f1efc53b3860936b92279a11b68395d898d138
     shared_secret:
     02bee8be0dda755846115db45071c0cf59c25722e015bde1c124de849c0fea52
     key_schedule_context: 03713f73042575cebfd132f0cc4338523f8eae95c80a74
     9f7cf3eb9436ff1c612ca62c37df27ca46d2cc162445a92c5f5fdc57bcde129ca7b1
     f284b0c12297c037ca221d77e229a9d11b654de7942d685069c633b2362ce3b3d8ea
     4891c9a2a87a4eb7cdb289ba5e2ecbf8cd2c8498bb4a383dc021454d70d46fcbbad1
     252ef4f9
     secret: 0f9df08908a6a3d06c8e934cd3f5313f9ebccd0986e316c0198bb48bed30
     dc3db2f3baab94fd40c2c285c7288c77e2255401ee2d5884306addf4296b93c238b3
     key: b68bb0e2fbf7431cedb46cc3b6f1fe9e
     base_nonce: 76af62719d33d39a1cb6be9f
     exporter_secret: 7f72308ae68c9a2b3862e686cb547b16d33d00fe482c770c471
     7d8b54e9b1e547244c3602bdd86d5a788a8443befea0a7658002b23f1c96a62a6498
     6fffc511a

  B.4.4.1.  Encryptions







  Barnes, et al.          Expires 21 September 2025              [Page 92]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 76af62719d33d39a1cb6be9f
     ct: 840669634db51e28df54f189329c1b727fd303ae413f003020aff5e26276aaa9
     10fc4296828cb9d862c2fd7d16

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 76af62719d33d39a1cb6be9e
     ct: d4680a48158d9a75fd09355878d6e33997a36ee01d4a8f22032b22373b795a94
     1b7b9c5205ff99e0ff284beef4

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 76af62719d33d39a1cb6be9d
     ct: c45eb6597de2bac929a0f5d404ba9d2dc1ea031880930f1fd7a283f0a0cbebb3
     5eac1a9ee0d1225f5e0f181571

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 76af62719d33d39a1cb6be9b
     ct: 4ee2482ad8d7d1e9b7e651c78b6ca26d3c5314d0711710ca62c2fd8bb8996d7d
     8727c157538d5493da696b61f8

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 76af62719d33d39a1cb6be60
     ct: 65596b731df010c76a915c6271a438056ce65696459432eeafdae7b4cadb6290
     dd61e68edd4e40b659d2a8cbcc

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 76af62719d33d39a1cb6bf9f
     ct: 9f659482ebc52f8303f9eac75656d807ec38ce2e50c72e3078cd13d86b30e3f8
     90690a873277620f8a6a42d836

  B.4.4.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025              [Page 93]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     c8c917e137a616d3d4e4c9fcd9c50202f366cb0d37862376bc79f9b72e8a8db9

     exporter_context: 00
     L: 32
     exported_value:
     33a5d4df232777008a06d0684f23bb891cfaef702f653c8601b6ad4d08dddddf

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     bed80f2e54f1285895c4a3f3b3625e6206f78f1ed329a0cfb5864f7c139b3c6a

  B.5.  DHKEM(P-256, HKDF-SHA256), HKDF-SHA256, ChaCha20Poly1305

  B.5.1.  Base Setup Information

































  Barnes, et al.          Expires 21 September 2025              [Page 94]


  Internet-Draft                    HPKE                        March 2025


     mode: 0
     kem_id: 16
     kdf_id: 1
     aead_id: 3
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     f1f1a3bc95416871539ecb51c3a8f0cf608afb40fbbe305c0a72819d35c33f1f
     pkEm: 04c07836a0206e04e31d8ae99bfd549380b072a1b1b82e563c935c09582782
     4fc1559eac6fb9e3c70cd3193968994e7fe9781aa103f5b50e934b5b2f387e381291
     skEm:
     7550253e1147aae48839c1f8af80d2770fb7a4c763afe7d0afa7e0f42a5b3689
     ikmR:
     61092f3f56994dd424405899154a9918353e3e008171517ad576b900ddb275e7
     pkRm: 04a697bffde9405c992883c5c439d6cc358170b51af72812333b015621dc0f
     40bad9bb726f68a5c013806a790ec716ab8669f84f6b694596c2987cf35baba2a006
     skRm:
     a4d1c55836aa30f9b3fbb6ac98d338c877c2867dd3a77396d13f68d3ab150d3b
     enc: 04c07836a0206e04e31d8ae99bfd549380b072a1b1b82e563c935c095827824
     fc1559eac6fb9e3c70cd3193968994e7fe9781aa103f5b50e934b5b2f387e381291
     shared_secret:
     806520f82ef0b03c823b7fc524b6b55a088f566b9751b89551c170f4113bd850
     key_schedule_context: 00b738cd703db7b4106e93b4621e9a19c89c838e559642
     40e5d3f331aaf8b0d58b2e986ea1c671b61cf45eec134dac0bae58ec6f63e790b140
     0b47c33038b0269c
     secret:
     fe891101629aa355aad68eff3cc5170d057eca0c7573f6575e91f9783e1d4506
     key:
     a8f45490a92a3b04d1dbf6cf2c3939ad8bfc9bfcb97c04bffe116730c9dfe3fc
     base_nonce: 726b4390ed2209809f58c693
     exporter_secret:
     4f9bd9b3a8db7d7c3a5b9d44fdc1f6e37d5d77689ade5ec44a7242016e6aa205

  B.5.1.1.  Encryptions


















  Barnes, et al.          Expires 21 September 2025              [Page 95]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 726b4390ed2209809f58c693
     ct: 6469c41c5c81d3aa85432531ecf6460ec945bde1eb428cb2fedf7a29f5a685b4
     ccb0d057f03ea2952a27bb458b

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 726b4390ed2209809f58c692
     ct: f1564199f7e0e110ec9c1bcdde332177fc35c1adf6e57f8d1df24022227ffa87
     16862dbda2b1dc546c9d114374

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 726b4390ed2209809f58c691
     ct: 39de89728bcb774269f882af8dc5369e4f3d6322d986e872b3a8d074c7c18e85
     49ff3f85b6d6592ff87c3f310c

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 726b4390ed2209809f58c697
     ct: bc104a14fbede0cc79eeb826ea0476ce87b9c928c36e5e34dc9b6905d91473ec
     369a08b1a25d305dd45c6c5f80

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 726b4390ed2209809f58c66c
     ct: 8f2814a2c548b3be50259713c6724009e092d37789f6856553d61df23ebc0792
     35f710e6af3c3ca6eaba7c7c6c

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 726b4390ed2209809f58c793
     ct: b45b69d419a9be7219d8c94365b89ad6951caf4576ea4774ea40e9b7047a09d6
     537d1aa2f7c12d6ae4b729b4d0

  B.5.1.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025              [Page 96]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     9b13c510416ac977b553bf1741018809c246a695f45eff6d3b0356dbefe1e660

     exporter_context: 00
     L: 32
     exported_value:
     6c8b7be3a20a5684edecb4253619d9051ce8583baf850e0cb53c402bdcaf8ebb

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     477a50d804c7c51941f69b8e32fe8288386ee1a84905fe4938d58972f24ac938

  B.5.2.  PSK Setup Information



































  Barnes, et al.          Expires 21 September 2025              [Page 97]


  Internet-Draft                    HPKE                        March 2025


     mode: 1
     kem_id: 16
     kdf_id: 1
     aead_id: 3
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     e1a4e1d50c4bfcf890f2b4c7d6b2d2aca61368eddc3c84162df2856843e1057a
     pkEm: 04f336578b72ad7932fe867cc4d2d44a718a318037a0ec271163699cee653f
     a805c1fec955e562663e0c2061bb96a87d78892bff0cc0bad7906c2d998ebe1a7246
     skEm:
     7d6e4e006cee68af9b3fdd583a0ee8962df9d59fab029997ee3f456cbc857904
     ikmR:
     ee51dec304abf993ef8fd52aacdd3b539108bbf6e491943266c1de89ec596a17
     pkRm: 041eb8f4f20ab72661af369ff3231a733672fa26f385ffb959fd1bae46bfda
     43ad55e2d573b880831381d9367417f554ce5b2134fbba5235b44db465feffc6189e
     skRm:
     12ecde2c8bc2d5d7ed2219c71f27e3943d92b344174436af833337c557c300b3
     psk:
     0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
     psk_id: 456e6e796e20447572696e206172616e204d6f726961
     enc: 04f336578b72ad7932fe867cc4d2d44a718a318037a0ec271163699cee653fa
     805c1fec955e562663e0c2061bb96a87d78892bff0cc0bad7906c2d998ebe1a7246
     shared_secret:
     ac4f260dce4db6bf45435d9c92c0e11cfdd93743bd3075949975974cc2b3d79e
     key_schedule_context: 01622b72afcc3795841596c67ea74400ca3b029374d7d5
     640bda367c5d67b3fbeb2e986ea1c671b61cf45eec134dac0bae58ec6f63e790b140
     0b47c33038b0269c
     secret:
     858c8087a1c056db5811e85802f375bb0c19b9983204a1575de4803575d23239
     key:
     6d61cb330b7771168c8619498e753f16198aad9566d1f1c6c70e2bc1a1a8b142
     base_nonce: 0de7655fb65e1cd51a38864e
     exporter_secret:
     754ca00235b245e72d1f722a7718e7145bd113050a2aa3d89586d4cb7514bfdb

  B.5.2.1.  Encryptions















  Barnes, et al.          Expires 21 September 2025              [Page 98]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 0de7655fb65e1cd51a38864e
     ct: 21433eaff24d7706f3ed5b9b2e709b07230e2b11df1f2b1fe07b3c70d5948a53
     d6fa5c8bed194020bd9df0877b

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 0de7655fb65e1cd51a38864f
     ct: c74a764b4892072ea8c2c56b9bcd46c7f1e9ca8cb0a263f8b40c2ba59ac9c857
     033f176019562218769d3e0452

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 0de7655fb65e1cd51a38864c
     ct: dc8cd68863474d6e9cbb6a659335a86a54e036249d41acf909e738c847ff2bd3
     6fe3fcacda4ededa7032c0a220

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 0de7655fb65e1cd51a38864a
     ct: cd54a8576353b1b9df366cb0cc042e46eef6f4cf01e205fe7d47e306b2fdd90f
     7185f289a26c613ca094e3be10

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 0de7655fb65e1cd51a3886b1
     ct: 6324570c9d542c70c7e70570c1d8f4c52a89484746bf0625441890ededcc80c2
     4ef2301c38bfd34d689d19f67d

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 0de7655fb65e1cd51a38874e
     ct: 1ea6326c8098ed0437a553c466550114fb2ca1412cca7de98709b9ccdf19206e
     52c3d39180e2cf62b3e9f4baf4

  B.5.2.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025              [Page 99]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     530bbc2f68f078dccc89cc371b4f4ade372c9472bafe4601a8432cbb934f528d

     exporter_context: 00
     L: 32
     exported_value:
     6e25075ddcc528c90ef9218f800ca3dfe1b8ff4042de5033133adb8bd54c401d

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     6f6fbd0d1c7733f796461b3235a856cc34f676fe61ed509dfc18fa16efe6be78

  B.5.3.  Auth Setup Information



































  Barnes, et al.          Expires 21 September 2025             [Page 100]


  Internet-Draft                    HPKE                        March 2025


     mode: 2
     kem_id: 16
     kdf_id: 1
     aead_id: 3
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     0ecd212019008138a31f9104d5dba76b9f8e34d5b996041fff9e3df221dd0d5d
     pkEm: 040d5176aedba55bc41709261e9195c5146bb62d783031280775f32e507d79
     b5cbc5748b6be6359760c73cfe10ca19521af704ca6d91ff32fc0739527b9385d415
     skEm:
     085fd5d5e6ce6497c79df960cac93710006b76217d8bcfafbd2bb2c20ea03c42
     ikmR:
     d32236d8378b9563840653789eb7bc33c3c720e537391727bf1c812d0eac110f
     pkRm: 0444f6ee41818d9fe0f8265bffd016b7e2dd3964d610d0f7514244a60dbb7a
     11ece876bb110a97a2ac6a9542d7344bf7d2bd59345e3e75e497f7416cf38d296233
     skRm:
     3cb2c125b8c5a81d165a333048f5dcae29a2ab2072625adad66dbb0f48689af9
     ikmS:
     0e6be0851283f9327295fd49858a8c8908ea9783212945eef6c598ee0a3cedbb
     pkSm: 04265529a04d4f46ab6fa3af4943774a9f1127821656a75a35fade898a9a1b
     014f64d874e88cddb24c1c3d79004d3a587db67670ca357ff4fba7e8b56ec013b98b
     skSm:
     39b19402e742d48d319d24d68e494daa4492817342e593285944830320912519
     enc: 040d5176aedba55bc41709261e9195c5146bb62d783031280775f32e507d79b
     5cbc5748b6be6359760c73cfe10ca19521af704ca6d91ff32fc0739527b9385d415
     shared_secret:
     1a45aa4792f4b166bfee7eeab0096c1a6e497480e2261b2a59aad12f2768d469
     key_schedule_context: 02b738cd703db7b4106e93b4621e9a19c89c838e559642
     40e5d3f331aaf8b0d58b2e986ea1c671b61cf45eec134dac0bae58ec6f63e790b140
     0b47c33038b0269c
     secret:
     9193210815b87a4c5496c9d73e609a6c92665b5ea0d760866294906d089ebb57
     key:
     cf292f8a4313280a462ce55cde05b5aa5744fe4ca89a5d81b0146a5eaca8092d
     base_nonce: 7e45c21e20e869ae00492123
     exporter_secret:
     dba6e307f71769ba11e2c687cc19592f9d436da0c81e772d7a8a9fd28e54355f

  B.5.3.1.  Encryptions












  Barnes, et al.          Expires 21 September 2025             [Page 101]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 7e45c21e20e869ae00492123
     ct: 25881f219935eec5ba70d7b421f13c35005734f3e4d959680270f55d71e2f5cb
     3bd2daced2770bf3d9d4916872

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 7e45c21e20e869ae00492122
     ct: 653f0036e52a376f5d2dd85b3204b55455b7835c231255ae098d09ed138719b9
     7185129786338ab6543f753193

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 7e45c21e20e869ae00492121
     ct: 60878706117f22180c788e62df6a595bc41906096a11a9513e84f0141e43239e
     81a98d7a235abc64112fcb8ddd

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 7e45c21e20e869ae00492127
     ct: 0f9094dd08240b5fa7a388b824d19d5b4b1e126cebfd67a062c32f9ba9f1f386
     6cc38de7df2702626e2ab65c0f

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 7e45c21e20e869ae004921dc
     ct: dd29319e08135c5f8401d6537a364e92172c0e3f095f3fd18923881d11c0a683
     9345dd0b54acd0edd8f8344792

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 7e45c21e20e869ae00492023
     ct: e2276ec5047bc4b6ed57d6da7da2fb47a77502f0a30f17d040247c73da336d72
     2bc6c89adf68396a0912c6d152

  B.5.3.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025             [Page 102]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     56c4d6c1d3a46c70fd8f4ecda5d27c70886e348efb51bd5edeaa39ff6ce34389

     exporter_context: 00
     L: 32
     exported_value:
     d2d3e48ed76832b6b3f28fa84be5f11f09533c0e3c71825a34fb0f1320891b51

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     eb0d312b6263995b4c7761e64b688c215ffd6043ff3bad2368c862784cbe6eff

  B.5.4.  AuthPSK Setup Information



































  Barnes, et al.          Expires 21 September 2025             [Page 103]


  Internet-Draft                    HPKE                        March 2025


     mode: 3
     kem_id: 16
     kdf_id: 1
     aead_id: 3
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     f3a07f194703e321ef1f753a1b9fe27a498dfdfa309151d70bedd896c239c499
     pkEm: 043539917ee26f8ae0aa5f784a387981b13de33124a3cde88b946720301831
     10f331400115855808244ff0c5b6ca6104483ac95724481d41bdcd9f15b430ad16f6
     skEm:
     11b7e4de2d919240616a31ab14944cced79bc2372108bb98f6792e3b645fe546
     ikmR:
     1240e55a0a03548d7f963ef783b6a7362cb505e6b31dfd04c81d9b294543bfbd
     pkRm: 04d383fd920c42d018b9d57fd73a01f1eee480008923f67d35169478e55d2e
     8817068daf62a06b10e0aad4a9e429fa7f904481be96b79a9c231a33e956c20b81b6
     skRm:
     c29fc577b7e74d525c0043f1c27540a1248e4f2c8d297298e99010a92e94865c
     ikmS:
     ce2a0387a2eb8870a3a92c34a2975f0f3f271af4384d446c7dc1524a6c6c515a
     pkSm: 0492cf8c9b144b742fe5a63d9a181a19d416f3ec8705f24308ad316564823c
     344e018bd7c03a33c926bb271b28ef5bf28c0ca00abff249fee5ef7f33315ff34fdb
     skSm:
     53541bd995f874a67f8bfd8038afa67fd68876801f42ff47d0dc2a4deea067ae
     psk:
     0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
     psk_id: 456e6e796e20447572696e206172616e204d6f726961
     enc: 043539917ee26f8ae0aa5f784a387981b13de33124a3cde88b9467203018311
     0f331400115855808244ff0c5b6ca6104483ac95724481d41bdcd9f15b430ad16f6
     shared_secret:
     87584311791036a3019bc36803cdd42e9a8931a98b13c88835f2f8a9036a4fd6
     key_schedule_context: 03622b72afcc3795841596c67ea74400ca3b029374d7d5
     640bda367c5d67b3fbeb2e986ea1c671b61cf45eec134dac0bae58ec6f63e790b140
     0b47c33038b0269c
     secret:
     fe52b4412590e825ea2603fa88e145b2ee014b942a774b55fab4f081301f16f4
     key:
     31e140c8856941315d4067239fdc4ebe077fbf45a6fc78a61e7a6c8b3bacb10a
     base_nonce: 75838a8010d2e4760254dd56
     exporter_secret:
     600895965755db9c5027f25f039a6e3e506c35b3b7084ce33c4a48d59ee1f0e3

  B.5.4.1.  Encryptions









  Barnes, et al.          Expires 21 September 2025             [Page 104]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 75838a8010d2e4760254dd56
     ct: 9eadfa0f954835e7e920ffe56dec6b31a046271cf71fdda55db72926e1d8fae9
     4cc6280fcfabd8db71eaa65c05

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 75838a8010d2e4760254dd57
     ct: e357ad10d75240224d4095c9f6150a2ed2179c0f878e4f2db8ca95d365d174d0
     59ff8c3eb38ea9a65cfc8eaeb8

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 75838a8010d2e4760254dd54
     ct: 2fa56d00f8dd479d67a2ec3308325cf3bbccaf102a64ffccdb006bd7dcb93268
     5b9a7b49cdc094a85fec1da5ef

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 75838a8010d2e4760254dd52
     ct: 1fe9d6db14965003ed81a39abf240f9cd7c5a454bca0d69ef9a2de16d537364f
     bbf110b9ef11fa4a7a0172f0ce

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 75838a8010d2e4760254dda9
     ct: eaf4041a5c9122b22d1f8d698eeffe45d64b4ae33d0ddca3a4cdf4a5f595acc9
     5a1a9334d06cc4d000df6aaad6

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 75838a8010d2e4760254dc56
     ct: fb857f4185ce5286c1a52431867537204963ea66a3eee8d2a74419fd8751faee
     066d08277ac7880473aa4143ba

  B.5.4.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025             [Page 105]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     c52b4592cd33dd38b2a3613108ddda28dcf7f03d30f2a09703f758bfa8029c9a

     exporter_context: 00
     L: 32
     exported_value:
     2f03bebc577e5729e148554991787222b5c2a02b77e9b1ac380541f710e5a318

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     e01dd49e8bfc3d9216abc1be832f0418adf8b47a7b5a330a7436c31e33d765d7

  B.6.  DHKEM(P-521, HKDF-SHA512), HKDF-SHA512, AES-256-GCM

  B.6.1.  Base Setup Information

































  Barnes, et al.          Expires 21 September 2025             [Page 106]


  Internet-Draft                    HPKE                        March 2025


     mode: 0
     kem_id: 18
     kdf_id: 3
     aead_id: 2
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE: 7f06ab8215105fc46aceeb2e3dc5028b44364f960426eb0d8e4026c2f8b5d7
     e7a986688f1591abf5ab753c357a5d6f0440414b4ed4ede71317772ac98d9239f709
     04
     pkEm: 040138b385ca16bb0d5fa0c0665fbbd7e69e3ee29f63991d3e9b5fa740aab8
     900aaeed46ed73a49055758425a0ce36507c54b29cc5b85a5cee6bae0cf1c21f2731
     ece2013dc3fb7c8d21654bb161b463962ca19e8c654ff24c94dd2898de12051f1ed0
     692237fb02b2f8d1dc1c73e9b366b529eb436e98a996ee522aef863dd5739d2f29b0
     skEm: 014784c692da35df6ecde98ee43ac425dbdd0969c0c72b42f2e708ab9d5354
     15a8569bdacfcc0a114c85b8e3f26acf4d68115f8c91a66178cdbd03b7bcc5291e37
     4b
     ikmR: 2ad954bbe39b7122529f7dde780bff626cd97f850d0784a432784e69d86ecc
     aade43b6c10a8ffdb94bf943c6da479db137914ec835a7e715e36e45e29b587bab3b
     f1
     pkRm: 0401b45498c1714e2dce167d3caf162e45e0642afc7ed435df7902ccae0e84
     ba0f7d373f646b7738bbbdca11ed91bdeae3cdcba3301f2457be452f271fa6837580
     e661012af49583a62e48d44bed350c7118c0d8dc861c238c72a2bda17f64704f464b
     57338e7f40b60959480c0e58e6559b190d81663ed816e523b6b6a418f66d2451ec64
     skRm: 01462680369ae375e4b3791070a7458ed527842f6a98a79ff5e0d4cbde83c2
     7196a3916956655523a6a2556a7af62c5cadabe2ef9da3760bb21e005202f7b24628
     47
     enc: 040138b385ca16bb0d5fa0c0665fbbd7e69e3ee29f63991d3e9b5fa740aab89
     00aaeed46ed73a49055758425a0ce36507c54b29cc5b85a5cee6bae0cf1c21f2731e
     ce2013dc3fb7c8d21654bb161b463962ca19e8c654ff24c94dd2898de12051f1ed06
     92237fb02b2f8d1dc1c73e9b366b529eb436e98a996ee522aef863dd5739d2f29b0
     shared_secret: 776ab421302f6eff7d7cb5cb1adaea0cd50872c71c2d63c30c4f1
     d5e43653336fef33b103c67e7a98add2d3b66e2fda95b5b2a667aa9dac7e59cc1d46
     d30e818
     key_schedule_context: 0083a27c5b2358ab4dae1b2f5d8f57f10ccccc822a4733
     26f543f239a70aee46347324e84e02d7651a10d08fb3dda739d22d50c53fbfa8122b
     aacd0f9ae5913072ef45baa1f3a4b169e141feb957e48d03f28c837d8904c3d67753
     08c3d3faa75dd64adfa44e1a1141edf9349959b8f8e5291cbdc56f62b0ed6527d692
     e85b09a4
     secret: 49fd9f53b0f93732555b2054edfdc0e3101000d75df714b98ce5aa295a37
     f1b18dfa86a1c37286d805d3ea09a20b72f93c21e83955a1f01eb7c5eead563d21e7
     key:
     751e346ce8f0ddb2305c8a2a85c70d5cf559c53093656be636b9406d4d7d1b70
     base_nonce: 55ff7a7d739c69f44b25447b
     exporter_secret: e4ff9dfbc732a2b9c75823763c5ccc954a2c0648fc6de80a585
     81252d0ee3215388a4455e69086b50b87eb28c169a52f42e71de4ca61c920e7bd24c
     95cc3f992

  B.6.1.1.  Encryptions




  Barnes, et al.          Expires 21 September 2025             [Page 107]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 55ff7a7d739c69f44b25447b
     ct: 170f8beddfe949b75ef9c387e201baf4132fa7374593dfafa90768788b7b2b20
     0aafcc6d80ea4c795a7c5b841a

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 55ff7a7d739c69f44b25447a
     ct: d9ee248e220ca24ac00bbbe7e221a832e4f7fa64c4fbab3945b6f3af0c5ecd5e
     16815b328be4954a05fd352256

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 55ff7a7d739c69f44b254479
     ct: 142cf1e02d1f58d9285f2af7dcfa44f7c3f2d15c73d460c48c6e0e506a3144ba
     e35284e7e221105b61d24e1c7a

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 55ff7a7d739c69f44b25447f
     ct: 3bb3a5a07100e5a12805327bf3b152df728b1c1be75a9fd2cb2bf5eac0cca1fb
     80addb37eb2a32938c7268e3e5

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 55ff7a7d739c69f44b254484
     ct: 4f268d0930f8d50b8fd9d0f26657ba25b5cb08b308c92e33382f369c768b558e
     113ac95a4c70dd60909ad1adc7

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 55ff7a7d739c69f44b25457b
     ct: dbbfc44ae037864e75f136e8b4b4123351d480e6619ae0e0ae437f036f2f8f1e
     f677686323977a1ccbb4b4f16a

  B.6.1.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025             [Page 108]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     05e2e5bd9f0c30832b80a279ff211cc65eceb0d97001524085d609ead60d0412

     exporter_context: 00
     L: 32
     exported_value:
     fca69744bb537f5b7a1596dbf34eaa8d84bf2e3ee7f1a155d41bd3624aa92b63

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     f389beaac6fcf6c0d9376e20f97e364f0609a88f1bc76d7328e9104df8477013

  B.6.2.  PSK Setup Information

     mode: 1
     kem_id: 18
     kdf_id: 3
     aead_id: 2
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE: f3ebfa9a69a924e672114fcd9e06fa9559e937f7eccce4181a2b506df53dbe
     514be12f094bb28e01de19dd345b4f7ede5ad7eaa6b9c3019592ec68eaae9a14732c
     e0
     pkEm: 040085eff0835cc84351f32471d32aa453cdc1f6418eaaecf1c2824210eb1d
     48d0768b368110fab21407c324b8bb4bec63f042cfa4d0868d19b760eb4beba1bff7
     93b30036d2c614d55730bd2a40c718f9466faf4d5f8170d22b6df98dfe0c067d02b3
     49ae4a142e0c03418f0a1479ff78a3db07ae2c2e89e5840f712c174ba2118e90fdcb
     skEm: 012e5cfe0daf5fe2a1cd617f4c4bae7c86f1f527b3207f115e262a98cc6526
     8ec88cb8645aec73b7aa0a472d0292502d1078e762646e0c093cf873243d12c39915
     f6
     ikmR: a2a2458705e278e574f835effecd18232f8a4c459e7550a09d44348ae5d3b1
     ea9d95c51995e657ad6f7cae659f5e186126a471c017f8f5e41da9eba74d4e0473e1
     79
     pkRm: 04006917e049a2be7e1482759fb067ddb94e9c4f7f5976f655088dec452466
     14ff924ed3b385fc2986c0ecc39d14f907bf837d7306aada59dd5889086125ecd038
     ead400603394b5d81f89ebfd556a898cc1d6a027e143d199d3db845cb91c5289fb26
     c5ff80832935b0e8dd08d37c6185a6f77683347e472d1edb6daa6bd7652fea628fae
     skRm: 011bafd9c7a52e3e71afbdab0d2f31b03d998a0dc875dd7555c63560e142bd
     e264428de03379863b4ec6138f813fa009927dc5d15f62314c56d4e7ff2b485753eb
     72
     psk:
     0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
     psk_id: 456e6e796e20447572696e206172616e204d6f726961
     enc: 040085eff0835cc84351f32471d32aa453cdc1f6418eaaecf1c2824210eb1d4
     8d0768b368110fab21407c324b8bb4bec63f042cfa4d0868d19b760eb4beba1bff79
     3b30036d2c614d55730bd2a40c718f9466faf4d5f8170d22b6df98dfe0c067d02b34



  Barnes, et al.          Expires 21 September 2025             [Page 109]


  Internet-Draft                    HPKE                        March 2025


     9ae4a142e0c03418f0a1479ff78a3db07ae2c2e89e5840f712c174ba2118e90fdcb
     shared_secret: 0d52de997fdaa4797720e8b1bebd3df3d03c4cf38cc8c1398168d
     36c3fc7626428c9c254dd3f9274450909c64a5b3acbe45e2d850a2fd69ac0605fe5c
     8a057a5
     key_schedule_context: 0124497637cf18d6fbcc16e9f652f00244c981726f293b
     b7819861e85e50c94f0be30e022ab081e18e6f299fd3d3d976a4bc590f85bc7711bf
     ce32ee1a7fb1c154ef45baa1f3a4b169e141feb957e48d03f28c837d8904c3d67753
     08c3d3faa75dd64adfa44e1a1141edf9349959b8f8e5291cbdc56f62b0ed6527d692
     e85b09a4
     secret: 2cf425e26f65526afc0634a3dba4e28d980c1015130ce07c2ac7530d7a39
     1a75e5a0db428b09f27ad4d975b4ad1e7f85800e03ffeea35e8cf3fe67b18d4a1345
     key:
     f764a5a4b17e5d1ffba6e699d65560497ebaea6eb0b0d9010a6d979e298a39ff
     base_nonce: 479afdf3546ddba3a9841f38
     exporter_secret: 5c3d4b65a13570502b93095ef196c42c8211a4a188c4590d358
     63665c705bb140ecba6ce9256be3fad35b4378d41643867454612adfd0542a684b61
     799bf293f

  B.6.2.1.  Encryptions
































  Barnes, et al.          Expires 21 September 2025             [Page 110]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 479afdf3546ddba3a9841f38
     ct: de69e9d943a5d0b70be3359a19f317bd9aca4a2ebb4332a39bcdfc97d5fe62f3
     a77702f4822c3be531aa7843a1

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 479afdf3546ddba3a9841f39
     ct: 77a16162831f90de350fea9152cfc685ecfa10acb4f7994f41aed43fa5431f23
     82d078ec88baec53943984553e

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 479afdf3546ddba3a9841f3a
     ct: f1d48d09f126b9003b4c7d3fe6779c7c92173188a2bb7465ba43d899a6398a33
     3914d2bb19fd769d53f3ec7336

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 479afdf3546ddba3a9841f3c
     ct: 829b11c082b0178082cd595be6d73742a4721b9ac05f8d2ef8a7704a53022d82
     bd0d8571f578c5c13b99eccff8

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 479afdf3546ddba3a9841fc7
     ct: a3ee291e20f37021e82df14d41f3fbe98b27c43b318a36cacd8471a3b1051ab1
     2ee055b62ded95b72a63199a3f

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 479afdf3546ddba3a9841e38
     ct: eecc2173ce1ac14b27ee67041e90ed50b7809926e55861a579949c07f6d26137
     bf9cf0d097f60b5fd2fbf348ec

  B.6.2.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025             [Page 111]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     62691f0f971e34de38370bff24deb5a7d40ab628093d304be60946afcdb3a936

     exporter_context: 00
     L: 32
     exported_value:
     76083c6d1b6809da088584674327b39488eaf665f0731151128452e04ce81bff

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     0c7cfc0976e25ae7680cf909ae2de1859cd9b679610a14bec40d69b91785b2f6

  B.6.3.  Auth Setup Information

     mode: 2
     kem_id: 18
     kdf_id: 3
     aead_id: 2
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE: fe1c589c2a05893895a537f38c7cb4300b5a7e8fef3d6ccb8f07a498029c61
     e90262e009dc254c7f6235f9c6b2fd6aeff0a714db131b09258c16e217b7bd2aa619
     b0
     pkEm: 04017de12ede7f72cb101dab36a111265c97b3654816dcd6183f809d4b3d11
     1fe759497f8aefdc5dbb40d3e6d21db15bdc60f15f2a420761bcaeef73b891c2b117
     e9cf01e29320b799bbc86afdc5ea97d941ea1c5bd5ebeeac7a784b3bab524746f3e6
     40ec26ee1bd91255f9330d974f845084637ee0e6fe9f505c5b87c86a4e1a6c3096dd
     skEm: 0185f03560de87bb2c543ef03607f3c33ac09980000de25eabe3b224312946
     330d2e65d192d3b4aa46ca92fc5ca50736b624402d95f6a80dc04d1f10ae95171372
     61
     ikmR: 8feea0438481fc0ecd470d6adfcda334a759c6b8650452c5a5dd9b2dd2cc9b
     e33d2bb7ee64605fc07ab4664a58bb9a8de80defe510b6c97d2daf85b92cd4bb0a66
     bf
     pkRm: 04007d419b8834e7513d0e7cc66424a136ec5e11395ab353da324e3586673e
     e73d53ab34f30a0b42a92d054d0db321b80f6217e655e304f72793767c4231785c4a
     4a6e008f31b93b7a4f2b8cd12e5fe5a0523dc71353c66cbdad51c86b9e0bdfcd9a45
     698f2dab1809ab1b0f88f54227232c858accc44d9a8d41775ac026341564a2d749f4
     skRm: 013ef326940998544a899e15e1726548ff43bbdb23a8587aa3bef9d1b85733
     8d87287df5667037b519d6a14661e9503cfc95a154d93566d8c84e95ce93ad05293a
     0b
     ikmS: 2f66a68b85ef04822b054ef521838c00c64f8b6226935593b69e13a1a2461a
     4f1a74c10c836e87eed150c0db85d4e4f506cbb746149befac6f5c07dc48a615ef92
     db
     pkSm: 04015cc3636632ea9a3879e43240beae5d15a44fba819282fac26a19c989fa
     fdd0f330b8521dff7dc393101b018c1e65b07be9f5fc9a28a1f450d6a541ee0d7622
     1133001e8f0f6a05ab79f9b9bb9ccce142a453d59c5abebb5674839d935a3ca1a3fb



  Barnes, et al.          Expires 21 September 2025             [Page 112]


  Internet-Draft                    HPKE                        March 2025


     c328539a60b3bc3c05fed22838584a726b9c176796cad0169ba4093332cbd2dc3a9f
     skSm: 001018584599625ff9953b9305849850d5e34bd789d4b81101139662fbea8b
     6508ddb9d019b0d692e737f66beae3f1f783e744202aaf6fea01506c27287e359fe7
     76
     enc: 04017de12ede7f72cb101dab36a111265c97b3654816dcd6183f809d4b3d111
     fe759497f8aefdc5dbb40d3e6d21db15bdc60f15f2a420761bcaeef73b891c2b117e
     9cf01e29320b799bbc86afdc5ea97d941ea1c5bd5ebeeac7a784b3bab524746f3e64
     0ec26ee1bd91255f9330d974f845084637ee0e6fe9f505c5b87c86a4e1a6c3096dd
     shared_secret: 26648fa2a2deb0bfc56349a590fd4cb7108a51797b634694fc020
     61e8d91b3576ac736a68bf848fe2a58dfb1956d266e68209a4d631e513badf8f4dcf
     c00f30a
     key_schedule_context: 0283a27c5b2358ab4dae1b2f5d8f57f10ccccc822a4733
     26f543f239a70aee46347324e84e02d7651a10d08fb3dda739d22d50c53fbfa8122b
     aacd0f9ae5913072ef45baa1f3a4b169e141feb957e48d03f28c837d8904c3d67753
     08c3d3faa75dd64adfa44e1a1141edf9349959b8f8e5291cbdc56f62b0ed6527d692
     e85b09a4
     secret: 56b7acb7355d080922d2ddc227829c2276a0b456087654b3ac4b53828bd3
     4af8cf54626f85af858a15a86eba73011665cc922bc59fd07d2975f356d2674db554
     key:
     01fced239845e53f0ec616e71777883a1f9fcab22a50f701bdeee17ad040e44d
     base_nonce: 9752b85fe8c73eda183f9e80
     exporter_secret: 80466a9d9cc5112ddad297e817e038801e15fa18152bc4dc010
     a35d7f534089c87c98b4bacd7bbc6276c4002a74085adcd9019fca6139826b529256
     9cfb7fe47

  B.6.3.1.  Encryptions

























  Barnes, et al.          Expires 21 September 2025             [Page 113]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: 9752b85fe8c73eda183f9e80
     ct: 0116aeb3a1c405c61b1ce47600b7ecd11d89b9c08c408b7e2d1e00a4d64696d1
     2e6881dc61688209a8207427f9

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: 9752b85fe8c73eda183f9e81
     ct: 37ece0cf6741f443e9d73b9966dc0b228499bb21fbf313948327231e70a18380
     e080529c0267f399ba7c539cc6

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: 9752b85fe8c73eda183f9e82
     ct: d17b045cac963e45d55fd3692ec17f100df66ac06d91f3b6af8efa7ed3c88955
     50eb753bc801fe4bd27005b4bd

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: 9752b85fe8c73eda183f9e84
     ct: 50c523ae7c64cada96abea16ddf67a73d2914ec86a4cedb31a7e6257f7553ed2
     44626ef79a57198192b2323384

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: 9752b85fe8c73eda183f9e7f
     ct: 53d422295a6ce8fcc51e6f69e252e7195e64abf49252f347d8c25534f1865a6a
     17d949c65ce618ddc7d816111f

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: 9752b85fe8c73eda183f9f80
     ct: 0dfcfc22ea768880b4160fec27ab10c75fb27766c6bb97aed373a9b6eae35d31
     afb08257401075cbb602ac5abb

  B.6.3.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025             [Page 114]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     8d78748d632f95b8ce0c67d70f4ad1757e61e872b5941e146986804b3990154b

     exporter_context: 00
     L: 32
     exported_value:
     80a4753230900ea785b6c80775092801fe91183746479f9b04c305e1db9d1f4d

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     620b176d737cf366bcc20d96adb54ec156978220879b67923689e6dca36210ed

  B.6.4.  AuthPSK Setup Information

     mode: 3
     kem_id: 18
     kdf_id: 3
     aead_id: 2
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE: 54272797b1fbc128a6967ff1fd606e0c67868f7762ce1421439cbc9e90ce1b
     28d566e6c2acbce712e48eebf236696eb680849d6873e9959395b2931975d61d38bd
     6c
     pkEm: 04000a5096a6e6e002c83517b494bfc2e36bfb8632fae8068362852b70d0ff
     71e560b15aff96741ecffb63d8ac3090c3769679009ac59a99a1feb4713c5f090fc0
     dbed01ad73c45d29d369e36744e9ed37d12f80700c16d816485655169a5dd66e4ddf
     27f2acffe0f56f7f77ea2b473b4bf0518b975d9527009a3d14e5a4957e3e8a9074f8
     skEm: 003430af19716084efeced1241bb1a5625b6c826f11ef31649095eb2795261
     9e36f62a79ea28001ac452fb20ddfbb66e62c6c0b1be03c0d28c97794a1fb638207a
     83
     ikmR: 3db434a8bc25b27eb0c590dc64997ab1378a99f52b2cb5a5a5b2fa540888f6
     c0f09794c654f4468524e040e6b4eca2c9dcf229f908b9d318f960cc9e9baa92c5ee
     e6
     pkRm: 0401655b5d3b7cfafaba30851d25edc44c6dd17d99410efbed8591303b4dbe
     ea8cb1045d5255f9a60384c3bbd4a3386ae6e6fab341dc1f8db0eed5f0ab1aaac6d7
     838e00dadf8a1c2c64b48f89c633721e88369e54104b31368f26e35d04a442b0b428
     510fb23caada686add16492f333b0f7ba74c391d779b788df2c38d7a7f4778009d91
     skRm: 0053c0bc8c1db4e9e5c3e3158bfdd7fc716aef12db13c8515adf821dd692ba
     3ca53041029128ee19c8556e345c4bcb840bb7fd789f97fe10f17f0e2c6c25280728
     43
     ikmS: 65d523d9b37e1273eb25ad0527d3a7bd33f67208dd1666d9904c6bc04969ae
     5831a8b849e7ff642581f2c3e56be84609600d3c6bbdaded3f6989c37d2892b1e978
     d5
     pkSm: 040013761e97007293d57de70962876b4926f69a52680b4714bee1d4236aa9
     6c19b840c57e80b14e91258f0a350e3f7ba59f3f091633aede4c7ec4fa8918323aa4
     5d5901076dec8eeb22899fda9ab9e1960003ff0535f53c02c40f2ae4cdc6070a3870



  Barnes, et al.          Expires 21 September 2025             [Page 115]


  Internet-Draft                    HPKE                        March 2025


     b85b4bdd0bb77f1f889e7ee51f465a308f08c666ad3407f75dc046b2ff5a24dbe2ed
     skSm: 003f64675fc8914ec9e2b3ecf13585b26dbaf3d5d805042ba487a5070b8c5a
     c1d39b17e2161771cc1b4d0a3ba6e866f4ea4808684b56af2a49b5e5111146d45d93
     26
     psk:
     0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
     psk_id: 456e6e796e20447572696e206172616e204d6f726961
     enc: 04000a5096a6e6e002c83517b494bfc2e36bfb8632fae8068362852b70d0ff7
     1e560b15aff96741ecffb63d8ac3090c3769679009ac59a99a1feb4713c5f090fc0d
     bed01ad73c45d29d369e36744e9ed37d12f80700c16d816485655169a5dd66e4ddf2
     7f2acffe0f56f7f77ea2b473b4bf0518b975d9527009a3d14e5a4957e3e8a9074f8
     shared_secret: 9e1d5f62cb38229f57f68948a0fbc1264499910cce50ec62cb241
     88c5b0a98868f3c1cfa8c5baa97b3f24db3cdd30df6e04eae83dc4347be8a981066c
     3b5b945
     key_schedule_context: 0324497637cf18d6fbcc16e9f652f00244c981726f293b
     b7819861e85e50c94f0be30e022ab081e18e6f299fd3d3d976a4bc590f85bc7711bf
     ce32ee1a7fb1c154ef45baa1f3a4b169e141feb957e48d03f28c837d8904c3d67753
     08c3d3faa75dd64adfa44e1a1141edf9349959b8f8e5291cbdc56f62b0ed6527d692
     e85b09a4
     secret: 50a57775958037a04098e0054576cd3bc084d0d08d29548ba4befa5676b9
     1eb4dcd0752813a052c9a930d0aba6ca10b89dd690b64032dc635dece35d1bf4645c
     key:
     1316ed34bd52374854ed0e5cb0394ca0a79b2d8ce7f15d5104f21acdfb594286
     base_nonce: d9c64ec8deb8a0647fafe8ff
     exporter_secret: 6cb00ff99aebb2e4a05042ce0d048326dd2c03acd61a601b103
     8a65398406a96ab8b5da3187412b2324089ea16ba4ff7e6f4fe55d281fc8ae5f2049
     032b69ebd

  B.6.4.1.  Encryptions






















  Barnes, et al.          Expires 21 September 2025             [Page 116]


  Internet-Draft                    HPKE                        March 2025


     sequence number: 0
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d30
     nonce: d9c64ec8deb8a0647fafe8ff
     ct: 942a2a92e0817cf032ce61abccf4f3a7c5d21b794ed943227e07b7df2d6dd92c
     9b8a9371949e65cca262448ab7

     sequence number: 1
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d31
     nonce: d9c64ec8deb8a0647fafe8fe
     ct: c0a83b5ec3d7933a090f681717290337b4fede5bfaa0a40ec29f93acad742888
     a1513c649104c391c78d1d7f29

     sequence number: 2
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d32
     nonce: d9c64ec8deb8a0647fafe8fd
     ct: 2847b2e0ce0b9da8fca7b0e81ff389d1682ee1b388ed09579b145058b5af6a93
     a85dd50d9f417dc88f2c785312

     sequence number: 4
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d34
     nonce: d9c64ec8deb8a0647fafe8fb
     ct: fbd9948ab9ac4a9cb9e295c07273600e6a111a3a89241d3e2178f39d532a2ec5
     c15b9b0c6937ac84c88e0ca76f

     sequence number: 255
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323535
     nonce: d9c64ec8deb8a0647fafe800
     ct: 63113a870131b567db8f39a11b4541eafbd2d3cf3a9bf9e5c1cfcb41e52f9027
     310b82a4868215959131694d15

     sequence number: 256
     pt: 4265617574792069732074727574682c20747275746820626561757479
     aad: 436f756e742d323536
     nonce: d9c64ec8deb8a0647fafe9ff
     ct: 24f9d8dadd2107376ccd143f70f9bafcd2b21d8117d45ff327e9a78f603a3260
     6e42a6a8bdb57a852591d20907

  B.6.4.2.  Exported Values








  Barnes, et al.          Expires 21 September 2025             [Page 117]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     a39502ef5ca116aa1317bd9583dd52f15b0502b71d900fc8a622d19623d0cb5d

     exporter_context: 00
     L: 32
     exported_value:
     749eda112c4cfdd6671d84595f12cd13198fc3ef93ed72369178f344fe6e09c3

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     f8b4e72cefbff4ca6c4eabb8c0383287082cfcbb953d900aed4959afd0017095

  B.7.  DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, Export-Only AEAD

  B.7.1.  Base Setup Information

































  Barnes, et al.          Expires 21 September 2025             [Page 118]


  Internet-Draft                    HPKE                        March 2025


     mode: 0
     kem_id: 32
     kdf_id: 1
     aead_id: 65535
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     55bc245ee4efda25d38f2d54d5bb6665291b99f8108a8c4b686c2b14893ea5d9
     pkEm:
     e5e8f9bfff6c2f29791fc351d2c25ce1299aa5eaca78a757c0b4fb4bcd830918
     skEm:
     095182b502f1f91f63ba584c7c3ec473d617b8b4c2cec3fad5af7fa6748165ed
     ikmR:
     683ae0da1d22181e74ed2e503ebf82840deb1d5e872cade20f4b458d99783e31
     pkRm:
     194141ca6c3c3beb4792cd97ba0ea1faff09d98435012345766ee33aae2d7664
     skRm:
     33d196c830a12f9ac65d6e565a590d80f04ee9b19c83c87f2c170d972a812848
     enc:
     e5e8f9bfff6c2f29791fc351d2c25ce1299aa5eaca78a757c0b4fb4bcd830918
     shared_secret:
     e81716ce8f73141d4f25ee9098efc968c91e5b8ce52ffff59d64039e82918b66
     key_schedule_context: 009bd09219212a8cf27c6bb5d54998c5240793a70ca0a8
     92234bd5e082bc619b6a3f4c22aa6d9a0424c2b4292fdf43b8257df93c2f6adbf6dd
     c9c64fee26bdd292
     secret:
     04d64e0620aa047e9ab833b0ebcd4ff026cefbe44338fd7d1a93548102ee01af
     key:
     base_nonce:
     exporter_secret:
     79dc8e0509cf4a3364ca027e5a0138235281611ca910e435e8ed58167c72f79b

  B.7.1.1.  Exported Values

     exporter_context:
     L: 32
     exported_value:
     7a36221bd56d50fb51ee65edfd98d06a23c4dc87085aa5866cb7087244bd2a36

     exporter_context: 00
     L: 32
     exported_value:
     d5535b87099c6c3ce80dc112a2671c6ec8e811a2f284f948cec6dd1708ee33f0

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     ffaabc85a776136ca0c378e5d084c9140ab552b78f039d2e8775f26efff4c70e




  Barnes, et al.          Expires 21 September 2025             [Page 119]


  Internet-Draft                    HPKE                        March 2025


  B.7.2.  PSK Setup Information

     mode: 1
     kem_id: 32
     kdf_id: 1
     aead_id: 65535
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     c51211a8799f6b8a0021fcba673d9c4067a98ebc6794232e5b06cb9febcbbdf5
     pkEm:
     d3805a97cbcd5f08babd21221d3e6b362a700572d14f9bbeb94ec078d051ae3d
     skEm:
     1d72396121a6a826549776ef1a9d2f3a2907fc6a38902fa4e401afdb0392e627
     ikmR:
     5e0516b1b29c0e13386529da16525210c796f7d647c37eac118023a6aa9eb89a
     pkRm:
     d53af36ea5f58f8868bb4a1333ed4cc47e7a63b0040eb54c77b9c8ec456da824
     skRm:
     98f304d4ecb312689690b113973c61ffe0aa7c13f2fbe365e48f3ed09e5a6a0c
     psk:
     0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
     psk_id: 456e6e796e20447572696e206172616e204d6f726961
     enc:
     d3805a97cbcd5f08babd21221d3e6b362a700572d14f9bbeb94ec078d051ae3d
     shared_secret:
     024573db58c887decb4c57b6ed39f2c9a09c85600a8a0ecb11cac24c6aaec195
     key_schedule_context: 01446fb1fe2632a0a338f0a85ed1f3a0ac475bdea2cd72
     f8c713b3a46ee737379a3f4c22aa6d9a0424c2b4292fdf43b8257df93c2f6adbf6dd
     c9c64fee26bdd292
     secret:
     638b94532e0d0bf812cf294f36b97a5bdcb0299df36e22b7bb6858e3c113080b
     key:
     base_nonce:
     exporter_secret:
     04261818aeae99d6aba5101bd35ddf3271d909a756adcef0d41389d9ed9ab153

  B.7.2.1.  Exported Values














  Barnes, et al.          Expires 21 September 2025             [Page 120]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     be6c76955334376aa23e936be013ba8bbae90ae74ed995c1c6157e6f08dd5316

     exporter_context: 00
     L: 32
     exported_value:
     1721ed2aa852f84d44ad020c2e2be4e2e6375098bf48775a533505fd56a3f416

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     7c9d79876a288507b81a5a52365a7d39cc0fa3f07e34172984f96fec07c44cba

  B.7.3.  Auth Setup Information



































  Barnes, et al.          Expires 21 September 2025             [Page 121]


  Internet-Draft                    HPKE                        March 2025


     mode: 2
     kem_id: 32
     kdf_id: 1
     aead_id: 65535
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     43b078912a54b591a7b09b16ce89a1955a9dd60b29fb611e044260046e8b061b
     pkEm:
     5ac1671a55c5c3875a8afe74664aa8bc68830be9ded0c5f633cd96400e8b5c05
     skEm:
     83d3f217071bbf600ba6f081f6e4005d27b97c8001f55cb5ff6ea3bbea1d9295
     ikmR:
     fc9407ae72ed614901ebf44257fb540f617284b5361cfecd620bafc4aba36f73
     pkRm:
     ffd7ac24694cb17939d95feb7c4c6539bb31621deb9b96d715a64abdd9d14b10
     skRm:
     ed88cda0e91ca5da64b6ad7fc34a10f096fa92f0b9ceff9d2c55124304ed8b4a
     ikmS:
     2ff4c37a17b2e54046a076bf5fea9c3d59250d54d0dc8572bc5f7c046307040c
     pkSm:
     89eb1feae431159a5250c5186f72a15962c8d0debd20a8389d8b6e4996e14306
     skSm:
     c85f136e06d72d28314f0e34b10aadc8d297e9d71d45a5662c2b7c3b9f9f9405
     enc:
     5ac1671a55c5c3875a8afe74664aa8bc68830be9ded0c5f633cd96400e8b5c05
     shared_secret:
     e204156fd17fd65b132d53a0558cd67b7c0d7095ee494b00f47d686eb78f8fb3
     key_schedule_context: 029bd09219212a8cf27c6bb5d54998c5240793a70ca0a8
     92234bd5e082bc619b6a3f4c22aa6d9a0424c2b4292fdf43b8257df93c2f6adbf6dd
     c9c64fee26bdd292
     secret:
     355e7ef17f438db43152b7fb45a0e2f49a8bf8956d5dddfec1758c0f0eb1b5d5
     key:
     base_nonce:
     exporter_secret:
     276d87e5cb0655c7d3dad95e76e6fc02746739eb9d968955ccf8a6346c97509e

  B.7.3.1.  Exported Values













  Barnes, et al.          Expires 21 September 2025             [Page 122]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     83c1bac00a45ed4cb6bd8a6007d2ce4ec501f55e485c5642bd01bf6b6d7d6f0a

     exporter_context: 00
     L: 32
     exported_value:
     08a1d1ad2af3ef5bc40232a64f920650eb9b1034fac3892f729f7949621bf06e

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     ff3b0e37a9954247fea53f251b799e2edd35aac7152c5795751a3da424feca73

  B.7.4.  AuthPSK Setup Information



































  Barnes, et al.          Expires 21 September 2025             [Page 123]


  Internet-Draft                    HPKE                        March 2025


     mode: 3
     kem_id: 32
     kdf_id: 1
     aead_id: 65535
     info: 4f6465206f6e2061204772656369616e2055726e
     ikmE:
     94efae91e96811a3a49fd1b20eb0344d68ead6ac01922c2360779aa172487f40
     pkEm:
     81cbf4bd7eee97dd0b600252a1c964ea186846252abb340be47087cc78f3d87c
     skEm:
     a2b43f5c67d0d560ee04de0122c765ea5165e328410844db97f74595761bbb81
     ikmR:
     4dfde6fadfe5cb50fced4034e84e6d3a104aa4bf2971360032c1c0580e286663
     pkRm:
     f47cd9d6993d2e2234eb122b425accfb486ee80f89607b087094e9f413253c2d
     skRm:
     c4962a7f97d773a47bdf40db4b01dc6a56797c9e0deaab45f4ea3aa9b1d72904
     ikmS:
     26c12fef8d71d13bbbf08ce8157a283d5e67ecf0f345366b0e90341911110f1b
     pkSm:
     29a5bf3867a6128bbdf8e070abe7fe70ca5e07b629eba5819af73810ee20112f
     skSm:
     6175b2830c5743dff5b7568a7e20edb1fe477fb0487ca21d6433365be90234d0
     psk:
     0247fd33b913760fa1fa51e1892d9f307fbe65eb171e8132c2af18555a738b82
     psk_id: 456e6e796e20447572696e206172616e204d6f726961
     enc:
     81cbf4bd7eee97dd0b600252a1c964ea186846252abb340be47087cc78f3d87c
     shared_secret:
     d69246bcd767e579b1eec80956d7e7dfbd2902dad920556f0de69bd54054a2d1
     key_schedule_context: 03446fb1fe2632a0a338f0a85ed1f3a0ac475bdea2cd72
     f8c713b3a46ee737379a3f4c22aa6d9a0424c2b4292fdf43b8257df93c2f6adbf6dd
     c9c64fee26bdd292
     secret:
     c15c5bec374f2087c241d3533c6ec48e1c60a21dd00085619b2ffdd84a7918c3
     key:
     base_nonce:
     exporter_secret:
     695b1faa479c0e0518b6414c3b46e8ef5caea04c0a192246843765ae6a8a78e0

  B.7.4.1.  Exported Values










  Barnes, et al.          Expires 21 September 2025             [Page 124]


  Internet-Draft                    HPKE                        March 2025


     exporter_context:
     L: 32
     exported_value:
     dafd8beb94c5802535c22ff4c1af8946c98df2c417e187c6ccafe45335810b58

     exporter_context: 00
     L: 32
     exported_value:
     7346bb0b56caf457bcc1aa63c1b97d9834644bdacac8f72dbbe3463e4e46b0dd

     exporter_context: 54657374436f6e74657874
     L: 32
     exported_value:
     84f3466bd5a03bde6444324e63d7560e7ac790da4e5bbab01e7c4d575728c34a

  Authors' Addresses

     Richard L. Barnes
     Cisco
     Email: rlb@ipv.sx


     Karthik Bhargavan
     Inria
     Email: karthikeyan.bhargavan@inria.fr


     Benjamin Lipp
     Inria
     Email: ietf@benjaminlipp.de


     Christopher A. Wood
     Apple
     Email: caw@heapingbits.net
















  Barnes, et al.          Expires 21 September 2025             [Page 125]


