



CoRE Working Group                                             M. Tiloca
Internet-Draft                                                   RISE AB
Updates: 8613 (if approved)                            J. Preuß Mattsson
Intended status: Standards Track                             Ericsson AB
Expires: 3 September 2026                                     R. Höglund
                                                                 RISE AB
                                                             G. Selander
                                                             Ericsson AB
                                                            2 March 2026


  Stand-in Key Identifier and Encrypted Partial IV in the Constrained
               Application Protocol (CoAP) OSCORE Option
                  draft-tiloca-core-oscore-piv-enc-02

Abstract

   The security protocol Object Security for Constrained RESTful
   Environments (OSCORE) provides end-to-end protection of messages
   exchanged with the Constrained Application Protocol (CoAP).  Messages
   protected with OSCORE include a CoAP OSCORE Option, where the
   "Partial IV" field specifies the sequence number value used by the
   message sender and the "kid" field specifies the identifier of the
   message sender.  In order to reduce the information exposed on the
   wire that can be used for fingerprinting traffic and for tracking
   endpoints, this document defines a lightweight add-on method that
   obfuscates certain fields of the OSCORE Option, by encrypting the
   "Partial IV" field and overwriting the "kid" field with a stand-in
   identifier.  Therefore, it updates RFC 8613.  With minor adaptations,
   the defined method is applicable also to the security protocol Group
   Object Security for Constrained RESTful Environments (Group OSCORE)
   that protects group communication for CoAP.

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://gitlab.com/crimson84/draft-tiloca-core-oscore-piv-enc.

Status of This Memo

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



Tiloca, et al.          Expires 3 September 2026                [Page 1]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


   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 3 September 2026.

Copyright Notice

   Copyright (c) 2026 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 . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Obfuscation Key . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Processing in OSCORE  . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Sender Side . . . . . . . . . . . . . . . . . . . . . . .   7
     3.2.  Recipient Side  . . . . . . . . . . . . . . . . . . . . .   9
       3.2.1.  Retrieving the Security Context to Use  . . . . . . .  10
       3.2.2.  Reversing the Field Obfuscation . . . . . . . . . . .  13
     3.3.  Special Cases . . . . . . . . . . . . . . . . . . . . . .  14
       3.3.1.  EDHOC + OSCORE Request  . . . . . . . . . . . . . . .  14
       3.3.2.  KUDOS . . . . . . . . . . . . . . . . . . . . . . . .  16
       3.3.3.  6TiSCH  . . . . . . . . . . . . . . . . . . . . . . .  16
   4.  Processing in Group OSCORE  . . . . . . . . . . . . . . . . .  17
     4.1.  Keying Material . . . . . . . . . . . . . . . . . . . . .  18
       4.1.1.  Obfuscation Sender Key  . . . . . . . . . . . . . . .  18
       4.1.2.  Obfuscation Recipient Key . . . . . . . . . . . . . .  18
     4.2.  Sender Side . . . . . . . . . . . . . . . . . . . . . . .  19
     4.3.  Recipient Side  . . . . . . . . . . . . . . . . . . . . .  19
       4.3.1.  Retrieving the Recipient Context to Use . . . . . . .  20
       4.3.2.  Reversing the Field Obfuscation . . . . . . . . . . .  26



Tiloca, et al.          Expires 3 September 2026                [Page 2]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


     4.4.  External Signature Checker  . . . . . . . . . . . . . . .  27
     4.5.  Deterministic Requests  . . . . . . . . . . . . . . . . .  27
   5.  Agreement on Obfuscating Fields in the OSCORE Option  . . . .  28
     5.1.  Agreement for OSCORE  . . . . . . . . . . . . . . . . . .  29
     5.2.  Agreement for Group OSCORE  . . . . . . . . . . . . . . .  29
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  29
     6.1.  Minimum Length of Sender Sequence Numbers . . . . . . . .  29
     6.2.  Limitations . . . . . . . . . . . . . . . . . . . . . . .  30
     6.3.  Encryption Robustness . . . . . . . . . . . . . . . . . .  30
     6.4.  Impact on Endpoint Trackability . . . . . . . . . . . . .  31
     6.5.  Trial Decryptions . . . . . . . . . . . . . . . . . . . .  31
     6.6.  Not Obfuscating the "kid" Field . . . . . . . . . . . . .  33
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  34
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  35
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  35
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  36
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  37
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  38

1.  Introduction

   The security protocol Object Security for Constrained RESTful
   Environments (OSCORE) [RFC8613] provides end-to-end protection of
   messages exchanged with the Constrained Application Protocol (CoAP)
   [RFC7252].  OSCORE operates at the application layer by using CBOR
   Object Signing and Encryption (COSE) [RFC9052] and is independent of
   the specific transport used to exchange CoAP messages.

   Messages protected with OSCORE include the CoAP OSCORE Option, which
   specifies information for the message recipient to correctly perform
   decryption and verification upon message reception.  In particular,
   some of the fields that can be included in the OSCORE Option
   comprise:

   *  The "Partial IV" field, which specifies the sequence number value
      used by the sender endpoint when protecting an outgoing message.
      This field is always present in request messages, while it is
      typically absent in response messages, with a few exceptions
      mandating its presence.

   *  The "kid" field, which specifies the identifier of the sender
      endpoint protecting an outgoing message (i.e., the sender
      endpoint's OSCORE Sender ID).  This field is always present in
      request messages, while it is typically absent in response
      messages.






Tiloca, et al.          Expires 3 September 2026                [Page 3]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


   Following a message protection with OSCORE, the OSCORE Option added
   to the message is not encrypted, since its content provides a
   recipient endpoint with information for processing the OSCORE-
   protected incoming message.

   However, the information conveyed in plaintext by the "Partial IV"
   and "kid" fields could be used for fingerprinting traffic from OSCORE
   endpoints, e.g., by giving hints about the order of messages sent by
   an endpoint, from which behavioral patterns could be implied.  Also,
   such information could be used to perform trivial tracking of OSCORE
   endpoints across different network paths, by correlating the values
   of those fields that are observed in those network paths (e.g.,
   following a network path migration, possibly across different network
   segments).

   In order to reduce the information exposed on the wire that can be
   used for fingerprinting traffic and for tracking endpoints, this
   document updates [RFC8613] and defines a lightweight add-on method
   that obfuscates certain fields of the OSCORE Option, by encrypting
   the "Partial IV" field and overwriting the "kid" field with a stand-
   in identifier.

   This method does not require in-band signaling and its use does not
   arbitrarily change on a per-message basis.

   Upon establishing an OSCORE Security Context, the communicating
   OSCORE endpoints already have an agreement about obfuscating the two
   fields of the OSCORE Option when that Security Context is used, for
   every OSCORE-protected message that includes the "Partial IV" field
   or the "kid" field.  In the interest of specific use cases, such an
   agreement can be about always obfuscating both the "Partial IV" and
   "kid" fields, or instead about always obfuscating only the "Partial
   IV" field.

   Like for the overall protection of messages with OSCORE, this method
   is agnostic of how exactly the OSCORE Security Context was
   established and of how the agreement on using this method was
   reached.  Nevertheless, this document also defines means that
   endpoints can use to reach that agreement.  Absent an explicit
   agreement, the "Partial IV" and "kid" fields in the OSCORE Option are
   not obfuscated and retain their original values, in order to preserve
   interoperability.

   With minor adaptations to what is defined when OSCORE is used, the
   method defined in this document is applicable also to the security
   protocol Group Object Security for Constrained RESTful Environments
   (Group OSCORE) [I-D.ietf-core-oscore-groupcomm] that protects group
   communication for CoAP [I-D.ietf-core-groupcomm-bis].  In the



Tiloca, et al.          Expires 3 September 2026                [Page 4]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


   interest of such a case, this document also defines means to align
   the members of an OSCORE group about obfuscating the "Partial IV" and
   "kid" fields of protected messages exchanged within the group.

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.

   Readers are expected to be familiar with the terms and concepts
   related to CoAP [RFC7252], Concise Data Definition Language (CDDL)
   [RFC8610], Concise Binary Object Representation (CBOR) [RFC8949],
   COSE [RFC9052], OSCORE [RFC8613], and Group OSCORE
   [I-D.ietf-core-oscore-groupcomm].

   This document refers also to the following terminology.

   *  Ordinary Security Context: an OSCORE Security Context [RFC8613] or
      a Group OSCORE Security Context [I-D.ietf-core-oscore-groupcomm]
      such that, when employed to process a message, the method defined
      in this document is not used to perform/reverse the obfuscation of
      the "Partial IV" and "kid" fields in the OSCORE Option.  An
      Ordinary Security Context does not include an Obfuscation Key in
      the Common Context (see Section 2).

   *  Obfuscating Security Context: an OSCORE Security Context or a
      Group OSCORE Security Context such that, when employed to process
      a message, the method defined in this document is used to perform/
      reverse the obfuscation of the "Partial IV" field in the OSCORE
      Option.  An Obfuscating Security Context includes an Obfuscation
      Key in the Common Context (see Section 2).

   *  Incognito Security Context: an Obfuscating Security Context such
      that, when employed to process a message, the method defined in
      this document is also used to perform/reverse the obfuscation of
      the "kid" field in the OSCORE Option.

      Unless a Security Context is an Incognito Security Context, the
      "kid" field (if present) in the OSCORE Option is left unaltered.

      The particular way to mark an Obfuscating Security Context as an
      Incognito Security Context is implementation specific.  For
      example, implementations can use an additional parameter in the
      Security Context.




Tiloca, et al.          Expires 3 September 2026                [Page 5]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


2.  Obfuscation Key

   When obfuscation is enabled for the OSCORE Option, the (Group) OSCORE
   Security Context is extended with one additional parameter in the
   Common Context.  The result is an Obfuscating Security Context.

   The new parameter Obfuscation Key specifies the encryption key for
   deriving two separate keystreams, namely PIV_KEYSTREAM and
   KID_KEYSTREAM.  On the sender side, PIV_KEYSTREAM and KID_KEYSTREAM
   are used to obfuscate the "Partial IV" and "kid" fields,
   respectively, when those are included in an outgoing message
   protected with (Group) OSCORE.  On the recipient side, the same
   keystreams are used to reverse the obfuscation of the two fields.

   The Obfuscation Key is derived as defined for the Sender/Recipient
   Keys in Section 3.2.1 of [RFC8613], with the following differences.

   *  The 'id' element of the 'info' array is the empty byte string.

   *  The 'type' element of the 'info' array is "OBFKey".  The label is
      an ASCII string and does not include a trailing NUL byte.

   *  If the Security Context is used for Group OSCORE and the Group
      Encryption Algorithm in the Common Context is set (see
      Section 2.1.7 of [I-D.ietf-core-oscore-groupcomm]), then:

      -  The 'alg_aead' element of the 'info' array specifies the Group
         Encryption Algorithm from the Common Context encoded as a CBOR
         integer or text string, consistently with the "Value" field in
         the entry of the "COSE Algorithms" Registry for this algorithm
         [COSE.Algorithms].

      -  The L parameter of the HKDF and the 'L' element of the 'info'
         array are the length in bytes of the key for the Group
         Encryption Algorithm specified in the Common Context.  While
         the obtained Obfuscation Key is never used with the Group
         Encryption Algorithm, its length was chosen to obtain a
         matching level of security.

   *  If the Security Context is used for Group OSCORE and the Group
      Encryption Algorithm in the Common Context is not set (see
      Section 2.1.7 of [I-D.ietf-core-oscore-groupcomm]), then:









Tiloca, et al.          Expires 3 September 2026                [Page 6]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


      -  The 'alg_aead' element of the 'info' array specifies the AEAD
         Algorithm from the Common Context (see Section 2.1.1 of
         [I-D.ietf-core-oscore-groupcomm]) encoded as a CBOR integer or
         text string, consistently with the "Value" field in the entry
         of the "COSE Algorithms" Registry for this algorithm
         [COSE.Algorithms].

      -  The L parameter of the HKDF and the 'L' element of the 'info'
         array are the length in bytes of the key for the AEAD Algorithm
         specified in the Common Context.  While the obtained
         Obfuscation Key is never used with the AEAD Algorithm, its
         length was chosen to obtain a matching level of security.

3.  Processing in OSCORE

   This section describes how the method defined in this document is
   specifically employed for messages protected with OSCORE [RFC8613].

3.1.  Sender Side

   When a sender endpoint uses a fresh Sender Sequence Number value from
   its own Sender Context to protect an outgoing message, that Sender
   Sequence Number value MUST be at least 65536.  Consequently, the
   "Partial IV" field of the OSCORE Option will have a length of at
   least 3 bytes.  As an exception, this requirement does not apply to
   the special case discussed in Section 3.3.1.

   When composing a protected outgoing message MSG, the OSCORE Option
   MUST NOT include the "s" and "kid context" fields.  As an exception,
   this requirement does not apply to the special case discussed in
   Section 3.3.3.

   Once MSG is composed, if at least one among the "Partial IV" and
   "kid" fields is included in the OSCORE Option (see Section 6.1 of
   [RFC8613]), the sender endpoint performs the following steps.

   1.  Compose SAMPLE_1 as the first N bytes of the CoAP payload of MSG,
       where N = min(LENGTH, 16) and LENGTH denotes the length in bytes
       of the CoAP payload of MSG.

       Note that the CoAP payload is the ciphertext of the COSE object
       and LENGTH is guaranteed to be at least 9.

   2.  Compose the 16-byte INPUT_1 as follows:

       *  If the length of SAMPLE_1 is less than 16 bytes, INPUT_1 is
          obtained by left-padding SAMPLE_1 with zeroes to exactly 16
          bytes.



Tiloca, et al.          Expires 3 September 2026                [Page 7]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


       *  If the length of SAMPLE_1 is 16 bytes, then INPUT_1 takes
          SAMPLE_1.

       If the OSCORE Option of MSG includes the "Partial IV" field, move
       to Step 3.  Otherwise, move to Step 6.

   3.  Compute the 16-byte PIV_KEYSTREAM as below:

       PIV_KEYSTREAM = AES-ECB(ENC_KEY, INPUT_1)

       where:

       *  AES-ECB is the AES algorithm in ECB mode [AES].

       *  ENC_KEY is the Obfuscation Key from the Common Context of the
          Security Context used to produce MSG (see Section 2).  ENC_KEY
          is used as the encryption key for the AES-ECB encryption.

       *  INPUT_1 is the result of Step 2.  It is used as the plaintext
          for the AES-ECB encryption.

   4.  Compute the ENC_PIV value, by XORing with each other:

       *  The PIV value encoded within the "Partial IV" field of the
          OSCORE Option of MSG; and

       *  The Q bytes from PIV_KEYSTREAM's start, where Q is the length
          in bytes of the "Partial IV" field and PIV_KEYSTREAM is the
          result of Step 3.

       For example, if the PIV value encoded within the "Partial IV"
       field of the OSCORE Option of MSG is 0x001122 (Q = 3 bytes) and
       PIV_KEYSTREAM is 0xffeeddccbbaa99887766554433221100 (16 bytes),
       then the bytes of PIV_KEYSTREAM to XOR with the PIV value are
       0xffeedd.

   5.  In the "Partial IV" field of the OSCORE Option of MSG, replace
       its current PIV value with the ENC_PIV value computed at Step 4.

       If the OSCORE Option of MSG includes the "kid" field, then move
       to Step 6.  Otherwise, terminate this algorithm.

   6.  If the Security Context used to produce MSG is an Incognito
       Security Context, compose the 16-byte INPUT_2, by taking INPUT_1
       from Step 2 and negating its last bit.  Then, move to Step 7.

       Otherwise, terminate this algorithm.




Tiloca, et al.          Expires 3 September 2026                [Page 8]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


   7.  Compute the 16-byte KID_KEYSTREAM as below:

       KID_KEYSTREAM = AES-ECB(ENC_KEY, INPUT_2)

       where:

       *  AES-ECB is the AES algorithm in ECB mode [AES].

       *  ENC_KEY is the Obfuscation Key from the Common Context of the
          Security Context used to produce MSG (see Section 2).  ENC_KEY
          is used as the encryption key for the AES-ECB encryption.

       *  INPUT_2 is the result of Step 6.  It is used as the plaintext
          for the AES-ECB encryption.

   8.  Compute the 3-byte STAND_IN_KID value, by XORing with each other:

       *  The 3 bytes from LATEST_PIV's start, where LATEST_PIV is
          determined as follows.

          -  If the OSCORE Option of MSG includes the "Partial IV"
             field, then LATEST_PIV is the ENC_PIV value computed at
             Step 4.  Otherwise,

          -  MSG is a response and LATEST_PIV is the value encoded
             within the "Partial IV" field of the OSCORE Option of the
             corresponding request as it was sent on the wire (i.e., in
             its obfuscated form).

       *  The 3 bytes from KID_KEYSTREAM's start, where KID_KEYSTREAM is
          the result of Step 7.

   9.  In the "kid" field of the OSCORE Option of MSG, replace the
       current KID value with the STAND_IN_KID value computed at Step 8.

       Unless the original KID value had a length of 3 bytes, this step
       alters the length of the OSCORE Option value.  In such a case,
       the sender endpoint MUST update the "Option Length" field of the
       OSCORE Option accordingly (see Section 3.1 of [RFC7252]).

   Finally, the sender endpoint transmits MSG as expected.

3.2.  Recipient Side

   Upon receiving a protected incoming message MSG, the recipient
   endpoint has to determine the OSCORE Security Context to use for
   decrypting and verifying MSG (see Section 3.2.1).




Tiloca, et al.          Expires 3 September 2026                [Page 9]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


   If a Security Context CTX is found and CTX is an Obfuscating Security
   Context, then the recipient endpoint uses CTX to reverse the
   obfuscation of the "Partial IV" and "kid" fields in the OSCORE Option
   of MSG (see Section 3.2.2).  After that, the recipient endpoint uses
   CTX to decrypt and verify MSG.

3.2.1.  Retrieving the Security Context to Use

   If the recipient endpoint is a client, hence MSG is a response, the
   Security Context CTX to use is the same one that was used to protect
   the request to which MSG replies.  That is, CTX is retrieved by
   leveraging the CoAP Token value that is specified in the "Token"
   field of MSG and was specified in the "Token" field of the
   corresponding request.

   Then, the following two cases are possible:

   *  CTX is an Ordinary Security Context.  In this case, the client
      uses CTX to decrypt and verify MSG, as defined in Section 8.4 of
      [RFC8613].

   *  CTX is an Obfuscating Security Context.  In this case, the client
      performs the steps defined in Section 3.2.2, in order to reverse
      the obfuscation of the "Partial IV" and "kid" fields in the OSCORE
      Option of MSG by using CTX.  Building on the result, the client
      uses CTX to decrypt and verify MSG, as defined in Section 8.4 of
      [RFC8613].

   If the recipient endpoint is a server, hence MSG is a request, the
   Security Context CTX to use is determined as follows.

   1.   If the server stores at least one Ordinary Security Context,
        then move to Step 2.  Otherwise, move to Step 3.

   2.   The server assumes that the "Partial IV" and "kid" fields in the
        OSCORE Option of MSG were not obfuscated.  Then, the server
        attempts to retrieve a Security Context as defined in
        Section 8.2 of [RFC8613].

        If this results in retrieving a Security Context CTX and CTX is
        an Ordinary Security Context, then the server uses CTX to
        decrypt and verify MSG, as defined in Section 8.2 of [RFC8613].
        In case of successful decryption and verification, this
        algorithm terminates and the server continues processing MSG as
        expected.

        Instead, if no such CTX is found or if MSG is not processed
        successfully, the following applies:



Tiloca, et al.          Expires 3 September 2026               [Page 10]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


        *  If the server stores at least one Obfuscating Security
           Context, the server MUST NOT presently reply with any of the
           optional 4.01 (Unauthorized) or 4.00 (Bad Request) error
           responses defined in Sections 7.4 and 8.2 of [RFC8613].
           Then, this algorithm moves to Step 4.

        *  Otherwise, the server performs the same error handling as
           defined in Sections 7.4 and 8.2 of [RFC8613].  Then, this
           algorithm terminates.

   3.   If the server stores at least one Obfuscating Security Context,
        then move to Step 4.

        Otherwise, the server performs the same error handling as
        defined at Step 2 of Section 8.4 of [RFC8613] for the case where
        a Security Context is not found.  Then, this algorithm
        terminates.

   4.   Compose SAMPLE_1 by means of the same method at Step 1 of
        Section 3.1, with reference to the present incoming message MSG.

   5.   Compose the 16-byte INPUT_1 by means of the same method at Step
        2 of Section 3.1, using as SAMPLE_1 the result of Step 4 of the
        present algorithm.

   6.   Compose the 16-byte INPUT_2, by taking INPUT_1 from Step 5 and
        negating its last bit.

   7.   Select a Security Context CTX, such that CTX is an Obfuscating
        Security Context and has not been tested yet during this
        execution of the present algorithm.

        In case the recipient endpoint does not store any Incognito
        Security Contexts, the selection process can effectively be the
        one used in Section 8.2 of [RFC8613].

        If no such CTX is found, then move to Step 12.  Otherwise, the
        selected CTX is marked as tested and the following applies:

        *  If CTX is an Incognito Security Context, check the length of
           the "kid" field of the OSCORE Option of MSG.

           If the length is 3 bytes, move to Step 8.  Otherwise, perform
           Step 7 again.







Tiloca, et al.          Expires 3 September 2026               [Page 11]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


        *  If CTX is not an Incognito Security Context, check whether
           the value encoded in the "kid" field of the OSCORE Option of
           MSG is equal to the Recipient ID specified in the Recipient
           Context of CTX.

           In case the two values are equal, CTX is the Security Context
           to use for decrypting and verifying MSG, and this algorithm
           moves to Step 11.  Otherwise, perform Step 7 again.

   8.   Compute the 16-byte KID_KEYSTREAM by means of the same method at
        Step 7 of Section 3.1.  In particular:

        *  ENC_KEY is the Obfuscation Key from the Common Context of the
           latest CTX selected at Step 7 of the present algorithm.

        *  INPUT_2 is the result of Step 6 of the present algorithm.

   9.   Compute the 3-byte STAND_IN_KID value, by XORing with each
        other:

        *  The 3 bytes from ENC_PIV's start, where ENC_PIV is the value
           encoded within the "Partial IV" field of the OSCORE Option of
           MSG.

        *  The 3 bytes from KID_KEYSTREAM's start, where KID_KEYSTREAM
           is the result of Step 8.

   10.  If the STAND_IN_KID value computed at Step 9 is not equal to the
        value encoded in the "kid" field of the OSCORE Option of MSG,
        then move to Step 7.

        Otherwise, the latest CTX selected at Step 7 is the Security
        Context to use for decrypting and verifying MSG, and this
        algorithm moves to Step 11.

   11.  Run the algorithm in Section 3.2.2, in order to reverse the
        obfuscation of the "Partial IV" and "kid" fields in the OSCORE
        Option of MSG, by using the latest CTX selected at Step 7.

        Building on the result, the server uses CTX to decrypt and
        verify MSG, as defined in Section 8.2 of [RFC8613].  In case of
        successful decryption and verification, this algorithm
        terminates and the server continues processing MSG as expected.

        Otherwise, if MSG is not processed successfully, the following
        applies:





Tiloca, et al.          Expires 3 September 2026               [Page 12]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


        *  The server MUST NOT presently reply with any of the optional
           4.01 (Unauthorized) or 4.00 (Bad Request) error responses
           defined in Sections 7.4 and 8.2 of [RFC8613].

        *  The OSCORE Option of MSG is restored to be as it was before
           running the algorithm in Section 3.2.2.

        *  This algorithm moves to Step 7.

   12.  The following applies:

        *  If, since Step 4 of this execution of the present algorithm,
           the server has performed and failed at least one decryption
           and verification of MSG (see Step 6 of Section 8.2 of
           [RFC8613]), the server performs the same error handling
           defined at Step 6 of Section 8.2 of [RFC8613] for the case
           where decryption has failed.  Then, this algorithm
           terminates.  Otherwise,

        *  If, since Step 4 of this execution of the present algorithm,
           the server has performed and failed at least one replay check
           on MSG (see Step 3 of Section 8.2 of [RFC8613]), the server
           performs the same error handling defined in Section 7.4 of
           [RFC8613] for the case where a replay has been detected.
           Then, this algorithm terminates.  Otherwise,

        *  The server performs the same error handling defined at Step 2
           of Section 8.2 of [RFC8613] for the case where a Security
           Context is not found.

3.2.2.  Reversing the Field Obfuscation

   Given an Obfuscating Security Context CTX that was retrieved
   according to what is specified in Section 3.2.1, the recipient
   endpoint performs the following steps, in order to reverse the
   obfuscation of the "Partial IV" and "kid" fields in the OSCORE Option
   of the protected incoming message MSG.

   1.  If the OSCORE Option of MSG includes the "kid" field and CTX is
       an Incognito Security Context, then move to Step 2.  Otherwise,
       move to Step 3.

   2.  In the "kid" field of the OSCORE Option of MSG, replace the
       current STAND_IN_KID value with the Recipient ID specified in the
       Recipient Context of CTX.






Tiloca, et al.          Expires 3 September 2026               [Page 13]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


       Unless the Recipient ID has a length of 3 bytes, this step alters
       the length of the OSCORE Option value.  In such a case, the
       recipient endpoint MUST update the "Option Length" field of the
       OSCORE Option accordingly (see Section 3.1 of [RFC7252]).

   3.  If the OSCORE Option of MSG includes the "Partial IV" field, move
       to Step 4.  Otherwise, terminate this algorithm.

   4.  Compute the 16-byte PIV_KEYSTREAM by means of the same method
       defined at Step 3 of Section 3.1.  In particular:

       *  ENC_KEY is the Obfuscation Key from the Common Context of the
          Security Context CTX that is used during this execution of the
          present algorithm.

       *  INPUT_1 is composed by means of the same method defined at
          Step 5 of Section 3.2.1.  Note that, if the recipient endpoint
          is a server, then INPUT_1 was already computed when actually
          performing Step 5 of Section 3.2.1.

   5.  Compute the PIV value, by XORing with each other:

       *  The ENC_PIV value encoded within the "Partial IV" field of the
          OSCORE Option of MSG; and

       *  The Q bytes from PIV_KEYSTREAM's start, where Q is the length
          in bytes of the "Partial IV" field and PIV_KEYSTREAM is the
          result of Step 4.

   6.  In the "Partial IV" field of the OSCORE Option of MSG, replace
       its current ENC_PIV value with the PIV value computed at Step 5.

3.3.  Special Cases

   This section discusses some special cases where the use of the method
   defined in this document deviates from what is specified in
   Section 3.1 and Section 3.2.

3.3.1.  EDHOC + OSCORE Request

   Two endpoints can run the authenticated key agreement Ephemeral
   Diffie-Hellman over COSE (EDHOC) [RFC9528] in order to establish an
   OSCORE Security Context (see Appendix A.1 of [RFC9528]).  In
   particular, EDHOC messages can be transported over CoAP (see
   Appendix A.2 of [RFC9528]).






Tiloca, et al.          Expires 3 September 2026               [Page 14]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


   When doing so, if the endpoint that sends the first EDHOC message
   acts as a CoAP client, it is possible to use the optimized workflow
   defined in Section 3 of [RFC9668].  In such a case, the first OSCORE-
   protected CoAP request sent by the client additionally embeds the
   final EDHOC message, and it is protected with the OSCORE Security
   Context established from the present and still ongoing EDHOC session.

   Upon receiving such an EDHOC + OSCORE request, the server first
   extracts and processes the EDHOC message embedded therein, completes
   the EDHOC session, establishes the OSCORE Security Context, and
   finally uses the latter to decrypt and verify the OSCORE-protected
   CoAP request.

   When using this optimized workflow, the method defined in this
   document cannot be used to obfuscate the "Partial IV" and "kid"
   fields in the OSCORE Option of the EDHOC + OSCORE request.

   Therefore, the following applies for the OSCORE Option of that
   specific request:

   *  The "Partial IV" field conveys the Sender Sequence Number of the
      client in plaintext.  As an exception to the requirement defined
      in Section 3.1, the "Partial IV" field can have a length smaller
      than 3 bytes.  In fact, it is expected to have a length of 1 byte
      and to encode the Sender Sequence Number 0.

   *  The "kid" field conveys the actual OSCORE Sender ID of the client,
      which the server offered earlier in the EDHOC session as its own
      EDHOC connection identifier C_R.  Upon receiving the EDHOC +
      OSCORE request, the server needs to retrieve such an identifier
      as-is from the request, in order to correctly retrieve the EDHOC
      session and complete it, before establishing the OSCORE Security
      Context shared with the client.

      That is, even if the OSCORE Security Context under establishment
      is an Incognito Security Context, the "kid" field in the OSCORE
      Option of the EDHOC + OSCORE request is not obfuscated.

      Note that, if EDHOC is instead run as per the original workflow
      (see Appendix A.2.1 of [RFC9528], the OSCORE Sender ID of the
      client is anyway exposed at least once, since C_R is prepended to
      EDHOC message_3 within the CoAP payload of a request sent by the
      client.








Tiloca, et al.          Expires 3 September 2026               [Page 15]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


3.3.2.  KUDOS

   Two endpoints can use Key Update for OSCORE (KUDOS)
   [I-D.ietf-core-oscore-key-update], a lightweight procedure for
   updating their OSCORE keying material by establishing a new OSCORE
   Security Context.

   Given the Security Context CTX_OLD to be replaced, there are two
   possible types of KUDOS messages that are exchanged during a KUDOS
   execution:

   *  A divergent KUDOS message is protected with a temporary OSCORE
      Security Context CTX_TEMP, which is derived from CTX_OLD.

   *  A convergent KUDOS message is protected with the OSCORE Security
      Context CTX_NEW, which is derived from CTX_OLD and is intended to
      replace CTX_OLD.

   When using the method defined in this document to obfuscate the
   "Partial IV" and "kid" fields in the OSCORE Option of a KUDOS
   message, the following applies.

   *  The Obfuscation Key to use MUST be the one specified in the Common
      Context of the Security Context CTX_OLD, from which the Security
      Context CTX_TEMP (CTX_NEW) is derived for protecting a divergent
      (convergent) KUDOS message.

      That is, with reference to a divergent (convergent) KUDOS message,
      the Obfuscation Key to use is not the one specified in the Common
      Context of the Security Context CTX_TEMP (CTX_NEW) that is used to
      protect the message.

3.3.3.  6TiSCH

   The Constrained Join Protocol (CoJP) defined in [RFC9031] specifies a
   "secure join" solution for a new device, called a "pledge", to
   securely join a 6TiSCH network where communications are protected
   with OSCORE.  The Join process is assisted by a central entity called
   Join Registrar/Coordinator (JRC).

   In particular, as defined in Section 7.3 of [RFC9031], the following
   holds for a given pledge and the JRC using OSCORE:

   *  The OSCORE ID Context in the shared OSCORE Security Context is set
      to the pledge identifier.

   *  The OSCORE Sender ID of the pledge is set to the empty byte
      string.



Tiloca, et al.          Expires 3 September 2026               [Page 16]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


   *  The OSCORE Sender ID of the JRC is set to the byte string 0x4a5243
      ("JRC" in ASCII).

   In the Join Request that the pledge sends to the JRC, the OSCORE
   Option includes the "s" and "kid context" fields, with the latter
   encoding the OSCORE ID Context.

   When using the method defined in this document to obfuscate the
   "Partial IV" and "kid" fields in the OSCORE Option of CoJP messages,
   the following applies:

   *  If the "s" and "kid context" fields are present in the OSCORE
      Option of an outgoing CoJP message, the sender endpoint MUST
      remove the "kid context" field and MUST update the "s" field to
      encode the value 0.

      This step alters the length of the OSCORE Option value.
      Therefore, the sender endpoint MUST update the "Option Length"
      field of the OSCORE Option accordingly (see Section 3.1 of
      [RFC7252]).

   *  If the OSCORE Option of an incoming CoJP message MSG does not
      include the "kid context" field and includes the "s" field
      encoding the value 0, the recipient endpoint performs the
      following steps in addition to those compiled in Section 3.2.2:

      -  Add the "kid context" field to the OSCORE Option of MSG.

      -  In the "kid context" field of the OSCORE Option, set as value
         the ID Context that is specified in the OSCORE Security Context
         CTX to be used for decrypting and verifying MSG.

      -  In the "s" field of the OSCORE Option, set as value the length
         in bytes of the "kid context" field.

      Unless the ID Context has a length of 0 bytes, this step alters
      the length of the OSCORE Option value.  In such a case, the
      recipient endpoint MUST update the "Option Length" field of the
      OSCORE Option accordingly (see Section 3.1 of [RFC7252]).

4.  Processing in Group OSCORE

   This section describes how the method defined in this document is
   specifically employed for messages protected with Group OSCORE
   [I-D.ietf-core-oscore-groupcomm].

   In particular, the following presents the differences that apply with
   respect to the case where OSCORE is used (see Section 3).



Tiloca, et al.          Expires 3 September 2026               [Page 17]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


4.1.  Keying Material

   When the Group OSCORE Security Context is an Obfuscating Security
   Context, it is further extended with one additional parameter
   Obfuscation Sender Key in the Sender Context (see Section 4.1.1) and
   with one additional parameter Obfuscation Recipient Key in each
   Recipient Context (see Section 4.1.2).

4.1.1.  Obfuscation Sender Key

   Within the Sender Context, the new parameter Obfuscation Sender Key
   specifies the encryption key for deriving the keystreams
   PIV_KEYSTREAM and KID_KEYSTREAM, when those are used to obfuscate the
   "Partial IV" and "kid" fields in the OSCORE Option of an outgoing
   message.

   The Obfuscation Sender Key is derived as the output OKM of an HKDF-
   Expand step [RFC5869], i.e., OKM = HKDF-Expand(PRK, info, L), where:

   *  The HKDF used is the HKDF Algorithm specified in the Common
      Context.

   *  PRK is the Obfuscation Key from the Common Context.

   *  info is the Sender ID specified in the Sender Context.

   *  L is the length in bytes of the Obfuscation Key from the Common
      Context.

4.1.2.  Obfuscation Recipient Key

   Within a given Recipient Context, the new parameter Obfuscation
   Recipient Key specifies the encryption key for deriving the
   keystreams PIV_KEYSTREAM and KID_KEYSTREAM, when those are used to
   reverse the obfuscation of the "Partial IV" and "kid" fields in the
   OSCORE Option of an incoming message.

   The Obfuscation Recipient Key is derived as the output OKM of an
   HKDF-Expand step [RFC5869], i.e., OKM = HKDF-Expand(PRK, info, L),
   where:

   *  The HKDF used is the HKDF Algorithm specified in the Common
      Context.

   *  PRK is the Obfuscation Key from the Common Context.

   *  info is the Recipient ID specified in the Recipient Context.




Tiloca, et al.          Expires 3 September 2026               [Page 18]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


   *  L is the length in bytes of the Obfuscation Key from the Common
      Context.

4.2.  Sender Side

   When composing a protected outgoing message MSG, the OSCORE Option
   includes the "s" and "kid context" fields according to what is
   specified for Group OSCORE in [I-D.ietf-core-oscore-groupcomm].  That
   is, the OSCORE Option always includes those fields in a request and
   may include those fields in a response.

   Once MSG is composed, if at least one among the "Partial IV" and
   "kid" fields is included in the OSCORE Option (see Section 6.1 of
   [RFC8613]), the sender endpoint performs the same steps of
   Section 3.1, with the following differences:

   *  At Step 1, LENGTH is guaranteed to be at least 9.  In particular:

      -  If MSG is protected with the group mode of Group OSCORE (see
         Section 7 of [I-D.ietf-core-oscore-groupcomm]), then the CoAP
         payload is the ciphertext of the COSE object concatenated with
         the encrypted countersignature.

      -  If MSG is protected with the pairwise mode of Group OSCORE (see
         Section 8 of [I-D.ietf-core-oscore-groupcomm]), then the CoAP
         payload is the ciphertext of the COSE object.

   *  At Step 3, ENC_KEY is the Obfuscation Sender Key from the Sender
      Context.

   *  At Step 7, ENC_KEY is the Obfuscation Sender Key from the Sender
      Context.

   Section 4.5 defines an exceptional case where a value smaller than
   65536 is used as Sender Sequence Number and the "kid" field of the
   OSCORE Option is not overwritten by a STAND_IN_KID value, even if the
   Group OSCORE Security Context is an Incognito Security Context.

4.3.  Recipient Side

   Upon receiving a protected incoming message MSG, the recipient
   endpoint determines the Group OSCORE Security Context CTX to use
   according to what is specified in [I-D.ietf-core-oscore-groupcomm],
   i.e.:

   *  If MSG is a request, CTX is retrieved by leveraging the Group
      Identifier value (Gid) of the group, which is encoded within the
      "kid context" field in the OSCORE Option of MSG.



Tiloca, et al.          Expires 3 September 2026               [Page 19]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


   *  If MSG is a response, CTX is the same Group OSCORE Security
      Context that was used to protect the request to which MSG replies.
      That is, CTX is retrieved by leveraging the CoAP Token value that
      is specified in the "Token" field of MSG and was specified in the
      "Token" field of the corresponding request.  The possible presence
      of the "kid context" field in the OSCORE Option can further aid
      the client, e.g., in case the group has been rekeyed and its Gid
      has changed.

   If the retrieved Group OSCORE Security Context CTX is an Obfuscating
   Security Context, then the method defined in this document is used to
   obfuscate the "Partial IV" field in the OSCORE Option of every
   protected message exchanged within the group.  Furthermore, if CTX is
   specifically an Incognito Security Context, then the method defined
   in this document is used to obfuscate also the "kid" field in the
   OSCORE Option of every protected message exchanged within the group.

   Consequently, within CTX, the recipient endpoint has to determine the
   specific Recipient Context REC_CTX to use for decrypting and
   verifying MSG (see Section 4.3.1).

   Then, the recipient endpoint uses REC_CTX to reverse the obfuscation
   of the "Partial IV" and "kid" fields in the OSCORE Option of MSG (see
   Section 4.3.2).  After that, the recipient endpoint uses REC_CTX to
   decrypt and verify MSG.

4.3.1.  Retrieving the Recipient Context to Use

   Given the retrieved Group OSCORE Security Context CTX, the following
   describes how the recipient endpoint retrieves from CTX the specific
   Recipient Context REC_CTX to use.

   If the recipient endpoint is a client, hence MSG is a response, the
   client is able to simply retrieve the Recipient Context REC_CTX to
   use, in case both the following conditions apply:

   *  The request corresponding to MSG was protected with the pairwise
      mode of Group OSCORE; and

   *  The "kid" field is not included in the OSCORE Option of MSG.

   In such a case, REC_CTX is the Recipient Context associated with the
   other endpoint for which the request corresponding to MSG was
   protected.  That is, this client protected such request by using its
   Pairwise Sender Key associated with that other endpoint.
   Consequently, the client performs the steps defined in Section 4.3.2,
   in order to reverse the obfuscation of the "Partial IV" field (if
   present) in the OSCORE Option of MSG by using REC_CTX.  Building on



Tiloca, et al.          Expires 3 September 2026               [Page 20]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


   the result, the client uses REC_CTX to decrypt and verify MSG, as
   defined in [I-D.ietf-core-oscore-groupcomm].  The specific operations
   to perform depend on whether MSG is protected with the group mode or
   with the pairwise mode of Group OSCORE.

   In any other case, the recipient endpoint determines the Recipient
   Context REC_CTX to use as follows.

   1.   If CTX is an Incognito Security Context and the length of the
        "kid" field of the OSCORE Option of MSG is different from 3
        bytes, move to Step 17.

        Otherwise, compose SAMPLE_1 as the first N bytes of the CoAP
        payload of MSG, where N = min(LENGTH, 16) and LENGTH denotes the
        length in bytes of the CoAP payload of MSG.

        The same considerations about LENGTH from Section 4.2 apply.

   2.   Compose the 16-byte INPUT_1 by means of the same method at Step
        2 of Section 3.1, using as SAMPLE_1 the result of Step 1 of the
        present algorithm.

   3.   Compose the 16-byte INPUT_2, by taking INPUT_1 from Step 2 and
        negating its last bit.

   4.   Within CTX, select a Recipient Context REC_CTX that has not been
        tested yet during this execution of the present algorithm.

        In case CTX is not an Incognito Security Context, the selection
        process can effectively be the one used in Section 6 of
        [I-D.ietf-core-oscore-groupcomm].

        If no such REC_CTX is found, then move to Step 9.  Otherwise,
        the selected REC_CTX is marked as tested and the following
        applies:

        *  If CTX is an Incognito Security Context, move to Step 5.

        *  If CTX is not an Incognito Security Context, check whether
           the value encoded in the "kid" field of the OSCORE Option of
           MSG is equal to the Recipient ID specified in REC_CTX.

           In case the two values are equal, REC_CTX is the Recipient
           Context to use for decrypting and verifying MSG, and this
           algorithm moves to Step 8.  Otherwise, perform Step 4 again.

   5.   Compute the 16-byte KID_KEYSTREAM by means of the same method at
        Step 7 of Section 3.1.  In particular:



Tiloca, et al.          Expires 3 September 2026               [Page 21]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


        *  ENC_KEY is the Obfuscation Recipient Key from the latest
           REC_CTX selected at Step 4 of the present algorithm.

        *  INPUT_2 is the result of Step 3 of the present algorithm.

   6.   Compute the 3-byte STAND_IN_KID value, by XORing with each
        other:

        *  The 3 bytes from LATEST_PIV's start, where LATEST_PIV is
           determined as follows.

           -  If the OSCORE Option of MSG includes the "Partial IV"
              field, then LATEST_PIV is the value encoded within that
              field.  Otherwise,

           -  MSG is a response and LATEST_PIV is the value encoded
              within the "Partial IV" field of the OSCORE Option of the
              corresponding request as it was sent on the wire (i.e., in
              its obfuscated form).

        *  The 3 bytes from KID_KEYSTREAM's start, where KID_KEYSTREAM
           is the result of Step 5.

   7.   If the STAND_IN_KID value computed at Step 6 is not equal to the
        value encoded in the "kid" field of the OSCORE Option of MSG,
        then move to Step 4.

        Otherwise, the latest REC_CTX selected at Step 4 is the
        Recipient Context to use for decrypting and verifying MSG, and
        this algorithm moves to Step 8.

   8.   Run the algorithm in Section 4.3.2, in order to reverse the
        obfuscation of the "Partial IV" and "kid" fields in the OSCORE
        Option of MSG, by using the latest REC_CTX selected at Step 4.

        Building on the result, the recipient endpoint uses REC_CTX to
        decrypt and verify MSG, as defined in
        [I-D.ietf-core-oscore-groupcomm].  The specific operations to
        perform depend on whether MSG is protected with the group mode
        or with the pairwise mode of Group OSCORE.

        In case of successful decryption and verification, this
        algorithm terminates and the recipient endpoint continues
        processing MSG as expected.

        Otherwise, if MSG is not processed successfully, the following
        applies:




Tiloca, et al.          Expires 3 September 2026               [Page 22]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


        *  If MSG is a request, the recipient endpoint MUST NOT
           presently reply with any of the optional 4.01 (Unauthorized),
           5.03 (Service Unavailable), or 4.00 (Bad Request) error
           responses that pertain to a failed processing of incoming
           requests.  Note that, although such processing is defined in
           Sections 5.3, 7.2, and 8.4 of
           [I-D.ietf-core-oscore-groupcomm], some of the corresponding
           error handling is inherited from Sections 7.4 and 8.2 of
           [RFC8613].

        *  The OSCORE Option of MSG is restored to be as it was before
           running the algorithm in Section 4.3.2.

        *  This algorithm moves to Step 4.

   9.   If the application admits the dynamic derivation of new
        Recipient Contexts and the recipient endpoint intends to take
        advantage of that, move to Step 10.  Otherwise, move to Step 17.

   10.  The recipient endpoint contacts the Group Manager responsible
        for the OSCORE group (see Section 12 of
        [I-D.ietf-core-oscore-groupcomm]) and retrieves a set of pairs P
        = (ID, CRED), where ID and CRED in each pair P are the Sender ID
        and the public authentication credential of a current group
        member.

        Depending on the particular realization of Group Manager, it can
        also be possible to retrieve a selected subset of those pairs,
        e.g., such that the ID specified therein is not part of a list
        provided in the request to the Group Manager.  The realization
        of Group Manager specified in
        [I-D.ietf-ace-key-groupcomm-oscore] makes it possible to do so.

   11.  From the set obtained at Step 10, select a pair P such that:

        *  P has not been selected yet during this execution of the
           present algorithm; and

        *  The ID specified within P is not the Recipient ID stored in
           any of the Recipient Contexts within CTX.

        If no such P is found, then move to Step 17.  Otherwise, move to
        Step 12.

        In case CTX is not an Incognito Security Context, the first pair
        P to select (if present) should be the one such that the ID
        specified therein is equal to the value encoded in the "kid"
        field of the OSCORE Option of MSG.



Tiloca, et al.          Expires 3 September 2026               [Page 23]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


   12.  Check if either of the following conditions applies:

        *  CTX is an Incognito Security Context; or

        *  CTX is not an Incognito Security Context and the value
           encoded in the "kid" field of the OSCORE Option of MSG is
           equal to the ID specified within the latest pair P selected
           at Step 11.

        If any of the two conditions above apply, then establish within
        CTX a new Recipient Context REC_CTX associated with the same
        other group member with which the latest pair P selected at Step
        11 is associated.  That is, within REC_CTX, ID and CRED from P
        are stored as the Recipient ID and authentication credential
        associated with the other group member.

        If the first of the two conditions above applies, this algorithm
        moves to Step 13.

        If the second of the two conditions above applies, REC_CTX is
        the Recipient Context to use for decrypting and verifying MSG,
        and this algorithm moves to Step 16.

        If none of the two conditions above applies, this algorithm
        moves to Step 11.

   13.  Compute the 16-byte KID_KEYSTREAM by means of the same method at
        Step 7 of Section 3.1.  In particular:

        *  ENC_KEY is the Obfuscation Recipient Key from the latest
           REC_CTX established at Step 12 of the present algorithm.

        *  INPUT_2 is the result of Step 3 of the present algorithm.

   14.  Compute the 3-byte STAND_IN_KID value, by XORing with each
        other:

        *  The 3 bytes from LATEST_PIV's start, where LATEST_PIV is the
           same one determined at Step 6.

        *  The 3 bytes from KID_KEYSTREAM's start, where KID_KEYSTREAM
           is the result of Step 13.

   15.  If the STAND_IN_KID value computed at Step 14 is not equal to
        the value encoded in the "kid" field of the OSCORE Option of
        MSG, then the following applies:





Tiloca, et al.          Expires 3 September 2026               [Page 24]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


        *  Depending on what is specified by the application, the
           recipient endpoint MAY delete the latest REC_CTX established
           at Step 12.

           If REC_CTX is deleted in this particular circumstance, then
           this deletion does not require the recipient endpoint to
           initialize as invalid the Replay Window of any new Recipient
           Context created later within CTX (see Section 2.6.1.2 of
           [I-D.ietf-core-oscore-groupcomm]).

        *  This algorithm moves to Step 11.

        Otherwise, the latest REC_CTX established at Step 12 is the
        Recipient Context to use for decrypting and verifying MSG, and
        this algorithm moves to Step 16.

   16.  Run the algorithm in Section 4.3.2, in order to reverse the
        obfuscation of the "Partial IV" and "kid" fields in the OSCORE
        Option of MSG, by using the latest REC_CTX established at Step
        12.

        Building on the result, the recipient endpoint uses REC_CTX to
        decrypt and verify MSG, as defined in
        [I-D.ietf-core-oscore-groupcomm].  The specific operations to
        perform depend on whether MSG is protected with the group mode
        or with the pairwise mode of Group OSCORE.

        In case of successful decryption and verification, this
        algorithm terminates and the recipient endpoint continues
        processing MSG as expected.

        Otherwise, if MSG is not processed successfully, the following
        applies:

        *  If MSG is a request, the recipient endpoint MUST NOT
           presently reply with any of the optional 4.01 (Unauthorized),
           5.03 (Service Unavailable), or 4.00 (Bad Request) error
           responses that pertain to a failed processing of incoming
           requests.  Note that, although such processing is defined in
           Sections 5.3, 7.2, and 8.4 of
           [I-D.ietf-core-oscore-groupcomm], some of the corresponding
           error handling is inherited from Sections 7.4 and 8.2 of
           [RFC8613].

        *  Depending on what is specified by the application, the
           recipient endpoint MAY delete the latest REC_CTX established
           at Step 12.




Tiloca, et al.          Expires 3 September 2026               [Page 25]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


           If REC_CTX is deleted in this particular circumstance, then
           this deletion does not require the recipient endpoint to
           initialize as invalid the Replay Window of any new Recipient
           Context created later within CTX (see Section 2.6.1.2 of
           [I-D.ietf-core-oscore-groupcomm]).

        *  The OSCORE Option of MSG is restored to be as it was before
           running the algorithm in Section 4.3.2.

        *  This algorithm moves to Step 11.

   17.  The following applies:

        *  If, during this execution of the present algorithm, the
           server has performed and failed at least one decryption and
           verification of MSG, the server performs the same error
           handling defined in Sections 7.2 and 8.4 of
           [I-D.ietf-core-oscore-groupcomm] for the case where
           decryption or signature verification has failed.  Then, this
           algorithm terminates.  Otherwise,

        *  If, during this execution of the present algorithm, the
           server has performed and failed at least one replay check on
           MSG (see Section 5.3 of [I-D.ietf-core-oscore-groupcomm]),
           the server performs the same error handling defined in
           Section 5.3 of [I-D.ietf-core-oscore-groupcomm] for the case
           where a replay has been detected.  Then, this algorithm
           terminates.  Otherwise,

        *  The server performs the same error handling defined in
           Sections 7.2 and 8.4 of [I-D.ietf-core-oscore-groupcomm] for
           the case where a Security Context is not found.

4.3.2.  Reversing the Field Obfuscation

   Given a Recipient Context RX_CTX that was retrieved according to what
   is specified in Section 4.3.1, the recipient endpoint performs the
   following steps, in order to reverse the obfuscation of the "Partial
   IV" and "kid" fields in the OSCORE Option of the protected incoming
   message MSG.

   1.  If the OSCORE Option of MSG includes the "kid" field and CTX is
       an Incognito Security Context, then move to Step 2.  Otherwise,
       move to Step 3.

   2.  In the "kid" field of the OSCORE Option of MSG, replace the
       current STAND_IN_KID value with the Recipient ID specified in
       RX_CTX.



Tiloca, et al.          Expires 3 September 2026               [Page 26]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


       Unless the Recipient ID has a length of 3 bytes, this step alters
       the length of the OSCORE Option value.  In such a case, the
       recipient endpoint MUST update the "Option Length" field of the
       OSCORE Option accordingly (see Section 3.1 of [RFC7252]).

   3.  If the OSCORE Option of MSG includes the "Partial IV" field, move
       to Step 4.  Otherwise, terminate this algorithm.

   4.  Compute the 16-byte PIV_KEYSTREAM by means of the same method
       defined at Step 3 of Section 3.1.  In particular:

       *  ENC_KEY is the Obfuscation Recipient Key from the RX_CTX that
          is used during this execution of the present algorithm.

       *  INPUT_1 is composed by means of the same method defined at
          Step 2 of Section 4.3.1.  Note that, except for the particular
          case discussed at the beginning of Section 4.3.1 where the
          recipient endpoint is a client, INPUT_1 was already computed
          when actually performing Step 2 of Section 4.3.1.

   5.  Compute the PIV value, by XORing with each other:

       *  The ENC_PIV value encoded within the "Partial IV" field of the
          OSCORE Option of MSG; and

       *  The Q bytes from PIV_KEYSTREAM's start, where Q is the length
          in bytes of the "Partial IV" field and PIV_KEYSTREAM is the
          result of Step 4.

   6.  In the "Partial IV" field of the OSCORE Option of MSG, replace
       its current ENC_PIV value with the PIV value computed at Step 5.

4.4.  External Signature Checker

   TBD

   Editor's note: describe how to ensure that an external signature
   checker (see Section 7.5 of [I-D.ietf-core-oscore-groupcomm]) can
   still perform its intended operations, when the "Partial IV" and
   "kid" fields of the OSCORE Option are obfuscated.

4.5.  Deterministic Requests

   This section defines an exceptional case where a value smaller than
   65536 is used as the Sender Sequence Number and the "kid" field of
   the OSCORE Option is not overwritten by a STAND_IN_KID value, even if
   the Group OSCORE Security Context is an Incognito Security Context.




Tiloca, et al.          Expires 3 September 2026               [Page 27]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


   The specification [I-D.ietf-core-cacheable-oscore] defines an
   approach for restoring cacheability of CoAP responses that are
   protected end-to-end with Group OSCORE.  The approach relies on the
   concept of Deterministic Request, i.e., a request protected with the
   pairwise mode of Group OSCORE that any client in the OSCORE group is
   able to prepare.

   When preparing a Deterministic Request, a client effectively
   impersonates a Deterministic Client, i.e., a fictitious member of the
   OSCORE group associated with a dedicated OSCORE Sender ID.  Also,
   each Deterministic Request is computed by using the Sender Sequence
   Number 0.

   Therefore, even when using the method defined in the present
   document, the following applies to the OSCORE Option of a
   Deterministic Request:

   *  The "Partial IV" field has a length of 1 byte and encodes the
      Sender Sequence Number 0.

   *  The "kid" field conveys the actual OSCORE Sender ID of the
      Deterministic Client.

      That is, even if the Group OSCORE Security Context used is an
      Incognito Security Context, the "kid" field in the OSCORE Option
      of a Deterministic Request is not obfuscated.

5.  Agreement on Obfuscating Fields in the OSCORE Option

   If an endpoint does not have an explicit agreement with its peer(s)
   about employing the method specified in this document when using a
   (Group) OSCORE Security Context CTX, the following applies in order
   to preserve interoperability:

   *  The endpoint MUST NOT obfuscate the "Partial IV" and "kid" fields
      in the OSCORE Option of its outgoing messages protected with CTX.

   *  The endpoint MUST NOT attempt to reverse the obfuscation of the
      "Partial IV" and "kid" fields in the OSCORE Option of incoming
      messages protected with CTX.

   The rest of this section defines means that endpoints can use to
   reach an agreement about obfuscating the "Partial IV" and "kid"
   fields as per the method specified in this document.







Tiloca, et al.          Expires 3 September 2026               [Page 28]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


5.1.  Agreement for OSCORE

   TBD

   Editor's note: expected means to cover include:

   *  Pre-provisioning

   *  In EDHOC

   *  In the OSCORE profile of the ACE framework

   *  In OMA Lightweight Machine-to-Machine (LwM2M)

5.2.  Agreement for Group OSCORE

   TBD

   Editor's note: expected means to cover include:

   *  The OSCORE Group Manager based on the ACE framework

      -  Messages to (candidate) group members

      -  Messages to external signature verifiers

      -  Message to/from an Administrator

   *  A CoAP server supporting observe multicast notifications and self-
      managing the OSCORE group for its group observations.

6.  Security Considerations

   The same security considerations from [RFC8613] and
   [I-D.ietf-core-oscore-groupcomm] hold for this document when messages
   are protected with OSCORE or Group OSCORE, respectively.
   Furthermore, the following considerations also apply.

6.1.  Minimum Length of Sender Sequence Numbers

   As per Section 3.1, a Sender Sequence Number value has to be at least
   65536 when using the method defined in this document.

   This ensures that the "Partial IV" field of the OSCORE Option has a
   length of at least 3 bytes.  In turn, this defeats possible attempts
   to track an endpoint or to fingerprint its traffic that leverage a
   transition of the length of the "Partial IV" field from 1 to 2 bytes,
   or from 2 to 3 bytes.



Tiloca, et al.          Expires 3 September 2026               [Page 29]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


   An exception applies to the special case discussed in Section 3.3.1,
   where the requirement above does not apply for the one-off EDHOC +
   OSCORE request [RFC9668].  However, the requirement does apply for
   all the messages that the two endpoints exchange after the EDHOC +
   OSCORE request and that are protected with the same OSCORE Security
   Context.

6.2.  Limitations

   The method defined in this document provides confidentiality
   protection of the Partial IV against passive adversaries.

   An active adversary could guess the plain Partial IV and have a
   recipient OSCORE endpoint confirm the guesses, e.g., taking advantage
   of timing side channels.  For instance, this can be the case when the
   recipient endpoint discards an incoming message that is detected as a
   replay, i.e., without attempting to decrypt and verify the message
   and hence revealing information through timing side channels.

   Similarly, depending on whether the processing of an incoming request
   message fails due to a replay detection or instead to a failed
   decryption and verification, the recipient endpoint would follow-up
   by sending different, unprotected error response messages, which the
   adversary can leverage to confirm the guesses.

6.3.  Encryption Robustness

   When performing the steps at Section 3.1 and Section 3.2, using the
   same Obfuscation Key and SAMPLE_1 more than once risks compromising
   the encryption of the PIV value in the "Partial IV" field.  That is,
   encrypting the PIV_A and PIV_B values of two different "Partial IV"
   fields by leveraging the same Obfuscation Key and SAMPLE_1 reveals
   the exclusive OR of PIV_A and PIV_B.

   Assuming that SAMPLE_1 is consistent with the outcome of a
   pseudorandom function (PRF), if L bits are sampled, then the
   probability that two SAMPLE_1 byte strings of length L are identical
   approach P = 2^(-L/2), that is, the birthday bound.  For messages
   protected with (Group) OSCORE, SAMPLE_1 has a minimum length L_MIN of
   72 bits and a maximum length L_MAX of 128 bits.  Therefore, P is at
   least 2^36 (when the CoAP payload has a length of L_MIN bits) and at
   most 2^64 (when the CoAP payload has a length of L_MAX bits or more).









Tiloca, et al.          Expires 3 September 2026               [Page 30]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


6.4.  Impact on Endpoint Trackability

   The tracking of an OSCORE endpoint that migrates to a new network
   path can be largely counteracted by using the method defined in this
   document, if combined with the use of new source addressing
   information (e.g., IP address and link-layer address).  If addressing
   information does not change upon network migration, an on-path
   adversary might still be able to track an endpoint.

   Even if combined with the change of addressing information upon
   network migration, the method defined in this document does not
   prevent other properties of network packets, e.g., their timing or
   length, from being used to correlate activities of the same endpoint
   across different network paths.

6.5.  Trial Decryptions

   Due to the possible obfuscation of the "kid" field of the OSCORE
   Option, a recipient endpoint could end up performing trial
   decryptions on an incoming message, when attempting to retrieve the
   right Recipient Context to use.

   Such trial decryptions will fail, when the recipient endpoint
   retrieves a Recipient Context that appears to be the right one to
   use, while in fact it is not and its selection was the result of a
   false positive matching of (stand-in) key identifiers.

   This could be the case in the following circumstances.

   *  OSCORE is used and the recipient endpoint is a server (see
      Section 3.2.1).

      -  If the recipient endpoint stores at least one Ordinary Security
         Context, the endpoint first assumes that the "Partial IV" and
         "kid" fields in the OSCORE Option of the incoming message were
         not obfuscated.

         Consequently, the endpoint first attempts to retrieve an
         Ordinary Security Context to decrypt and verify the message
         (see Step 2 in Section 3.2.1).  If a Security Context is found
         and the OSCORE processing of the incoming message fails, the
         endpoint proceeds with looking for Obfuscating Security
         Contexts to use.








Tiloca, et al.          Expires 3 September 2026               [Page 31]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


      -  If the recipient endpoint stores Incognito Security Contexts,
         multiple of those might result in computing a STAND_IN_KID
         value that is equal to the value encoded in the "kid" field of
         the OSCORE Option of the incoming message (see Step 10 in
         Section 3.2.1).

         In case of a positive match, the selected Incognito Security
         Context is used for the OSCORE processing of the incoming
         message (see Step 11 in Section 3.2.1), which fails unless the
         selected Security Context is actually the right one to use.  If
         the OSCORE processing fails, the endpoint continues inspecting
         the set of Obfuscating Security Contexts.

   *  Group OSCORE is used and the Group OSCORE Security Context is an
      Incognito Security Context (see Section 4.3.1).

      -  Within the Group OSCORE Security Context, multiple Recipient
         Contexts might result in computing a STAND_IN_KID value that is
         equal to the value encoded in the "kid" field of the OSCORE
         Option of the incoming message (see Step 7 in Section 4.3.1).

         In case of a positive match, the selected Recipient Context is
         used for the Group OSCORE processing of the incoming message
         (see Step 8 in Section 4.3.1), which fails unless the selected
         Recipient Context is actually the right one to use.  If the
         Group OSCORE processing fails, the endpoint continues
         inspecting the set of Recipient Contexts.

      -  If the recipient endpoint does not find an eligible Recipient
         Context among the stored ones, the endpoint might proceed with
         the dynamic derivation of new Recipient Contexts, if allowed by
         the application (see Step 8 in Section 4.3.1).

         After establishing a new Recipient Context, this might result
         in computing a STAND_IN_KID value that is equal to the value
         encoded in the "kid" field of the OSCORE Option of the incoming
         message (see Step 15 in Section 4.3.1).

         In case of a positive match, the newly established Recipient
         Context is used for the Group OSCORE processing of the incoming
         message (see Step 16 in Section 4.3.1), which fails unless the
         Recipient Context is actually the right one to use.  If the
         Group OSCORE processing fails, the endpoint can continue
         establishing and trying further available Recipient Contexts,
         as long as information to do so is available.






Tiloca, et al.          Expires 3 September 2026               [Page 32]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


   Although the specific circumstances above are new and introduced by
   the method defined in this document, trial decryption is in fact
   already a possibility:

   *  When using OSCORE, a server receiving a request might end up
      processing it with multiple OSCORE Security Contexts in sequence.
      This can happen, e.g., in case of collisions with the values of ID
      Context and Recipient ID across stored Security Contexts.

   *  When using OSCORE, a client receiving a response might end up
      processing it with multiple OSCORE Security Contexts in sequence.
      This can happen, e.g., in case the same Token value is used for
      multiple messages exchanges that are simultaneously active.

   *  When using Group OSCORE, a server receiving a request might end up
      processing it with multiple Group OSCORE Security Contexts in
      sequence.  This can happen, e.g., in case of collisions with the
      values of ID Context and Recipient ID across stored Security
      Contexts.  For example, both the sender endpoint and the recipient
      endpoint can be in two different OSCORE groups under different
      Group Managers, with both OSCORE groups identified by the same
      Group ID and with the sender endpoint using the same Sender ID in
      both groups.

   In either case, the recipient endpoint can attempt using multiple
   available Security Contexts in sequence, until the right one is
   possibly found and message decryption and verification succeed.

   Regardless of the specific circumstance by which trial decryptions
   occur, recipient endpoints still have to keep updated the status of
   their keying material, including after decryption failure.  In
   particular, symmetric keys ought not to be used beyond certain key
   usage limits, i.e., after having reached a maximum number of failed
   decryptions
   [I-D.ietf-core-oscore-key-limits][I-D.irtf-cfrg-aead-limits].

   Clearly, broadening the opportunities for trial decryption increases
   the pace by which key usage limits are approached, thereby increasing
   the frequency by which keying material needs to be updated, e.g., by
   using the key update procedure KUDOS
   [I-D.ietf-core-oscore-key-update].

6.6.  Not Obfuscating the "kid" Field

   When using an Obfuscating Security Context that is not an Incognito
   Security Context, the method specified in this document results only
   in obfuscating the "Partial IV" field of the OSCORE Option, but not
   the "kid" field.



Tiloca, et al.          Expires 3 September 2026               [Page 33]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


   This is useful in some use cases where such information is
   effectively still obfuscated by other means.  In such use cases,
   obfuscating the "kid" field by using the method defined in this
   document would simply result in unjustified (performance) penalties.

   For example, the specification [I-D.ietf-schc-8824-update] defines
   how to use the Static Context Header Compression and fragmentation
   (SCHC) framework [RFC8724] for compressing headers of CoAP messages,
   also when messages are protected with OSCORE or Group OSCORE.

   Two endpoints using (Group) OSCORE and SCHC header compression can
   enforce SCHC compression Rules that include a Field Descriptor for
   the "kid" field of the OSCORE Option.  The intent of such a SCHC Rule
   is typically to match with a protected message where the "kid" field
   conveys the same value specified in the corresponding Field
   Descriptor of the Rule.  As a result, the SCHC compression elides the
   "kid" field before transmission, and the field will be reconstructed
   by the recipient endpoint when performing SCHC Decompression per the
   same SCHC Rule.

   In such a scenario, obfuscating the "kid" field by means of the
   method defined in this document will prevent the intended SCHC
   compression Rule to match with the protected message to compress,
   since the stand-in identifier that is overwritten in the "kid" field
   of the OSCORE Option will differ from the static, expected value
   specified in the Field Descriptor of the SCHC Rule.  In fact, unless
   other installed SCHC compression Rules produce a match, the message
   as a whole will simply not be compressed.

   To ensure that at least other fields of the message are compressed,
   the SCHC Rule would instead have to include the Field Descriptor for
   the "kid" field that always results in preserving the "kid" field as-
   is, without compression.  Clearly, it is instead better to enforce
   the originally intended SCHC Rule, while not obfuscating the "kid"
   field through the method specified in this document.

   With the exception of such use cases that effectively achieve
   obfuscation of the "kid" field by other means, endpoints that support
   the method defined in this document and explicitly agree to use it
   ought to rely on Incognito Security Contexts and thus obfuscate the
   "kid" field of the OSCORE Option accordingly.

7.  IANA Considerations

   TBD

   Editor's note: expected actions are registrations of new parameters
   that effectively enable the means defined in Section 5.



Tiloca, et al.          Expires 3 September 2026               [Page 34]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


8.  References

8.1.  Normative References

   [AES]      NIST, "Advanced Encryption Standard (AES)", May 2023,
              <https://doi.org/10.6028/NIST.FIPS.197-upd1>.

   [COSE.Algorithms]
              IANA, "COSE Algorithms",
              <https://www.iana.org/assignments/cose/
              cose.xhtml#algorithms>.

   [I-D.ietf-core-cacheable-oscore]
              Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in
              Progress, Internet-Draft, draft-ietf-core-cacheable-
              oscore-00, 22 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              cacheable-oscore-00>.

   [I-D.ietf-core-oscore-groupcomm]
              Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P.,
              and R. Höglund, "Group Object Security for Constrained
              RESTful Environments (Group OSCORE)", Work in Progress,
              Internet-Draft, draft-ietf-core-oscore-groupcomm-28, 23
              December 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-core-oscore-groupcomm-28>.

   [I-D.ietf-core-oscore-key-update]
              Höglund, R. and M. Tiloca, "Key Update for OSCORE
              (KUDOS)", Work in Progress, Internet-Draft, draft-ietf-
              core-oscore-key-update-12, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              oscore-key-update-12>.

   [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>.

   [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>.

   [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>.



Tiloca, et al.          Expires 3 September 2026               [Page 35]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


   [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>.

   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
              Definition Language (CDDL): A Notational Convention to
              Express Concise Binary Object Representation (CBOR) and
              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
              June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

   [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>.

   [RFC9031]  Vučinić, M., Ed., Simon, J., Pister, K., and M.
              Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH",
              RFC 9031, DOI 10.17487/RFC9031, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9031>.

   [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>.

   [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>.

   [RFC9668]  Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and
              G. Selander, "Using Ephemeral Diffie-Hellman Over COSE
              (EDHOC) with the Constrained Application Protocol (CoAP)
              and Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 9668, DOI 10.17487/RFC9668, November 2024,
              <https://www.rfc-editor.org/rfc/rfc9668>.

8.2.  Informative References

   [I-D.ietf-ace-key-groupcomm-oscore]
              Tiloca, M. and F. Palombini, "Key Management for Group
              Object Security for Constrained RESTful Environments
              (Group OSCORE) Using Authentication and Authorization for



Tiloca, et al.          Expires 3 September 2026               [Page 36]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


              Constrained Environments (ACE)", Work in Progress,
              Internet-Draft, draft-ietf-ace-key-groupcomm-oscore-20, 25
              February 2026, <https://datatracker.ietf.org/doc/html/
              draft-ietf-ace-key-groupcomm-oscore-20>.

   [I-D.ietf-core-groupcomm-bis]
              Dijk, E. and M. Tiloca, "Group Communication for the
              Constrained Application Protocol (CoAP)", Work in
              Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
              18, 10 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              groupcomm-bis-18>.

   [I-D.ietf-core-oscore-key-limits]
              Höglund, R. and M. Tiloca, "Key Usage Limits for OSCORE",
              Work in Progress, Internet-Draft, draft-ietf-core-oscore-
              key-limits-06, 7 January 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              oscore-key-limits-06>.

   [I-D.ietf-schc-8824-update]
              Tiloca, M., Toutain, L., Martínez, I., and A. Minaburo,
              "Static Context Header Compression (SCHC) for the
              Constrained Application Protocol (CoAP)", Work in
              Progress, Internet-Draft, draft-ietf-schc-8824-update-07,
              1 December 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-schc-8824-update-07>.

   [I-D.irtf-cfrg-aead-limits]
              Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on
              AEAD Algorithms", Work in Progress, Internet-Draft, draft-
              irtf-cfrg-aead-limits-11, 4 December 2025,
              <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
              aead-limits-11>.

   [RFC8724]  Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
              Zuniga, "SCHC: Generic Framework for Static Context Header
              Compression and Fragmentation", RFC 8724,
              DOI 10.17487/RFC8724, April 2020,
              <https://www.rfc-editor.org/rfc/rfc8724>.

Acknowledgments

   The authors sincerely thank Christian Amsüss, Carsten Bormann, and
   Martine Lenders for their comments and feedback.

   This work was supported by the Sweden's Innovation Agency VINNOVA
   within the EUREKA CELTIC-NEXT project CYPRESS.



Tiloca, et al.          Expires 3 September 2026               [Page 37]

Internet-Draft   OSCORE - Stand-in KID and Encrypted PIV      March 2026


Authors' Addresses

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


   John Preuß Mattsson
   Ericsson AB
   SE-164 40 Kista
   Sweden
   Email: john.mattsson@ericsson.com


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


   Göran Selander
   Ericsson AB
   SE-164 40 Kista
   Sweden
   Email: goran.selander@ericsson.com





















Tiloca, et al.          Expires 3 September 2026               [Page 38]
