Object Security for Constrained RESTful Environments (OSCORE)
draft-ietf-core-object-security-16

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

The IANA Functions Operator has completed its review of draft-ietf-core-object-security-13. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has questions about the actions requested in the IANA Considerations section of this document.

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

First, in the COSE Header Parameters registry on the CBOR Object Signing and Encryption (COSE) regsitry page located at:

https://www.iana.org/assignments/cose/

a single new registration will be made as follows:

Name: kid context
Label: [ TBD-at-Registration; 1-255 requested ]
Value Type: bstr
Value Registry:
Description: Identifies the context for kid
Reference: [ RFC-to-be, Section 5.1 ]

As this document requests registrations in a "Standards Action With Expert Review" registry range, we will initiate the required expert review via a separate request. Expert review should be completed before your document is approved for publication as an RFC.

Second, in the CoAP Option Numbers registry on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

https://www.iana.org/assignments/core-parameters/

a single new registration will be made as follows:

Number: [ TBD-at-Registration ]
Name: OSCORE
Reference: [ RFC-to-be ]

IANA Question --> Should this registration be made in the registry's 0-255 range, which requires IETF Review or IESG Approval but not expert review, or in one of the other ranges?

Third, in the CoAP Signaling Option Numbers also on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

https://www.iana.org/assignments/core-parameters/

a single new registration will be made as follows:

Applies to: 7.xx (any)
Number: [ TBD-at-Registration ]
Name: OSCORE
Reference: [ TBD-at-Registration ]

IANA Question --> Can you confirm that the value in the "Number" field is the same value that's being assigned to the new Option Number?

Fourth, in the Permanent Message Header Field Names registry on the Message Headers registry page located at:

https://www.iana.org/assignments/message-headers/

a single new message header field name will be added as follows:

Header Field Name: OSCORE
Template:
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required expert review via a separate request. Expert review should be completed before your document is approved for publication as an RFC.

Fifth, in the application namespace of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a single new media type will be registered as follows:

Name: oscore
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Sixth, in the CoAP Content-Formats registry on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

https://www.iana.org/assignments/core-parameters/

a single new registration will be made as follows:

Media Type: application/oscore
Encoding:
ID: [ TBD-at-Registration; 10000-64999 requested ]
Reference: [ RFC-to-be ]

Seventh, a new registry called OSCORE Octet will be created.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry will be maintained via Expert Review as defined in RFC 8126.

IANA Question --> IANA understands that bits 3-7 are defined by this document. Also, that bits 8-63 are to be defined by a future document. How should bits 1, 2 and 8-63 be marked in the initial version of the registry? Should they be marked "Unassigned," as defined by RFC 8126, or designated in some other way?

There are initial values for the new registry as follows:

+--------------+-------------+---------------------+-------------------+
| Bit Position | Name | Description | Specification |
+--------------+-------------+---------------------+-------------------+
| 0 | Reserved | | |
+--------------+-------------+---------------------+-------------------+
| 3 | Kid Context | Set to 1 if kid | [ RFC-to-be ] |
| | Flag | context is present | |
| | | in the compressed | |
| | | COSE object | |
+--------------+-------------+---------------------+-------------------+
| 4 | Kid Flag | Set to 1 if kid is | [ RFC-to-be ] |
| | | present in the com- | |
| | | pressed COSE object | |
+--------------+-------------+---------------------+-------------------+
| 5-7 | Partial IV | Encodes the Partial | [ RFC-to-be ] |
| | Length | IV length; can have | |
| | | value 0 to 5 | |
+--------------+-------------+---------------------+-------------------+

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

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

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-07-30):

From: The IESG
To: IETF-Announce
CC: jaime.jimenez@ericsson.com, core-chairs@ietf.org, Carsten Bormann , core@ietf.org, alexey.melnikov@isode.com, cabo@tzi.org, draft-ietf-core-object-security@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Object Security for Constrained RESTful Environments (OSCORE)) to Proposed Standard


The IESG has received a request from the Constrained RESTful Environments WG
(core) to consider the following document: - 'Object Security for Constrained
RESTful Environments (OSCORE)'
  as Proposed Standard

This is the Second IETF Last Call on the document, as the document has changed
significantly after IESG review and IETF community should be given a change
to review the changes. In particular interested readers should review updated
Section 11 (HTTP Operations) and newly added Appendix D (Overview of
Security Properties).

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

Abstract

  This document defines Object Security for Constrained RESTful
  Environments (OSCORE), a method for application-layer protection of
  the Constrained Application Protocol (CoAP), using CBOR Object
  Signing and Encryption (COSE).  OSCORE provides end-to-end protection
  between endpoints communicating using CoAP or CoAP-mappable HTTP.
  OSCORE is designed for constrained nodes and networks supporting a
  range of proxy operations, including translation between different
  transport protocols.


The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-core-object-security/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ballot/


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

[Ballot comment]
I strongly support an object level security solution to provide end-to-end security when traffic traverses proxies or is relayed in the case of many IoT scenarios.  There are billions of devices in the IoT space with different constraints and operating requirements.  As such, I support and appreciate your work on this draft.  I had already known that this work was decoupled from EDHOC and appreciate that it can now be used either with TLS, EDHOC, or some other transport security protocol to offer object level security and protection in transit for data.

Thanks for addressing the OpsDir review a couple of weeks ago that pointed out where the work for provisioning the master secret, use of pre-shared keys in some scenarios, the use of profiles for algorithm agility, and the candidate key exchange protocols are done and other questions on security considerations and MTI.  Since EKR's review pointed some of these same things out, having the pointers more clearly stated in the draft would be beneficial to the reader and implementer.  Perhaps a longer discussion is needed in the draft. Where there are still multiple candidate drafts, you may not want to name one yet, but rather point to existing work.  Thanks again!

[Ballot comment]
I support EKR's DISCUSS.

Martin Thompson raises a number of fairly important points in his review (see
). I
recognize that many of these are fundamental to the design in the document. It
is still worthwhile thinking through them and trying to suss out whether a
redesign by the working group is warranted.

I do want to put a little more meat on Martin's assertion "This doesn't appear
to have any supporting security analysis," as this was something I was going
to highlight myself (and this is related to EKR's DISCUSS as well). Given that
this document seems to be putting together security primitives in a de novo
fashion, I would expect to see something equivalent to draft-ietf-tls-tls13's
Appendix E.

Specific comments follow.

---------------------------------------------------------------------------

§1:

>  ([RFC6347]) for security.  CoAP and HTTP proxies require (D)TLS to be
>  terminated at the proxy

Presumably, this means "CoAP-to-HTTP proxies"? Otherwise, the assertion is
wrong: HTTP proxies do not terminate TLS connections.

---------------------------------------------------------------------------
§1:

>  An implementation supporting this specification MAY only implement
>  the client part, MAY only implement the server part, or MAY only
>  implement one of the proxy parts

Replace "MAY only implement" with "MAY implement only" (in three places)

---------------------------------------------------------------------------

§1.1:

>  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].  These
>  words may also appear in this document in lowercase, absent their
>  normative meanings.

This is almost, but not quite, the RFC 8174 boilerplate. Please fix it to match
RFC 8174.

---------------------------------------------------------------------------

§2:

>  +-----+---+---+---+---+-----------------+--------+--------+---------+
>  | No. | C | U | N | R | Name            | Format | Length | Default |
>  +-----+---+---+---+---+-----------------+--------+--------+---------+
>  | TBD | x |  |  |  | Object-Security |  (*)  | 0-255  | (none)  |
>  +-----+---+---+---+---+-----------------+--------+--------+---------+
>      C = Critical,  U = Unsafe,  N = NoCacheKey,  R = Repeatable
>      (*) See below.
>
>                  Figure 3: The Object-Security Option

I get the impression that this is supposed to be extending a table that already
exists somewhere. This document should say which table.

---------------------------------------------------------------------------

§4.1:

>  The CoAP Payload, if present in the original CoAP message, SHALL be
>  encrypted and integrity protected and is thus an Inner message field.
>  See Figure 5.
>
>                      +------------------+---+---+
>                      | Field            | E | U |
>                      +------------------+---+---+
>                      | Payload          | x |  |
>                      +------------------+---+---+
>
>                E = Encrypt and Integrity Protect (Inner)
>                U = Unprotected (Outer)
>
>                  Figure 5: Protection of CoAP Payload

The figure adds nothing to the prose; and is, in fact, harder to understand than
the prose. I would recommend removing it.

---------------------------------------------------------------------------

§4.3:

>  The other CoAP Header fields are Unprotected (Class U).

Presumably this should say "The other currently defined CoAP Header fields...",
right?


---------------------------------------------------------------------------

§5:

>  As specified in [RFC5116], plaintext denotes the data that is
>  encrypted and integrity protected...

Traditionally, data that is encrypted is called "cipher text." I gather from
context that this should probably say "...the data that is to be encrypted...",
right?

---------------------------------------------------------------------------

§5.2:

>  responses, which reduces the size.  For processing instructions (see
>  Section 8).

This final fragment can be turned into a sentence by removing the parentheses.


---------------------------------------------------------------------------

§6 and its subsections:

The use of a bespoke profile of COSE adds implementation complexity to
ostenstibly resource-limited device for what appears to be very little gain. In
the examples given, savings of 4 to 7 bytes are demonstrated, which seems to
hardly warrant the addition of this mechanism. These do not appear to be
degenerate cases, so I can't imagine that compression performance under
real-world conditions would be much better.  Was there an explicit discussion
in the working group regarding this complexity/wire-size trade-off?

---------------------------------------------------------------------------

§6.3.1:

>  1.  Request with kid = 25 and Partial IV = 5

The base of the numbers above isn't indicated, and the reasonable reader may
take it to be 10. Please either change the above line to "...kid = 0x25...",
or change the hex encodings in the examples to h'19'.

---------------------------------------------------------------------------

§7.3:

>  For requests, OSCORE provides weak absolute freshness as the only

The meaning of "weak absolute freshness" doesn't appear to be given anywhere,
and is not evident by combining the normal meanings of those three words. Please
describe the property of "weak absolute freshness" in more detail (or, if this
is a term of art defined elsewhere, a citation would be sufficient).

--------------------------------------------------------------------------

§10.3:

>  o  "" (empty string) if the CoAP Object-Security option is empty, or

Which is it? Is this an empty string on the wire, or is it a string consisting
of "" (that is, the two-byte sequence 0x22 0x22)?

---------------------------------------------------------------------------

§10.3:

>[HTTP request -- Before client object security processing]

This line should be indented to match the rest of the example.

---------------------------------------------------------------------------

§10.3:

>  o  the value of the CoAP Object-Security option (Section 6.1) in
>    base64url encoding (Section 5 of [RFC4648]) without padding (see
>    [RFC7515] Appendix C for implementation notes for this encoding).

...

>    POST http://proxy.url/hc/?target_uri=coap://server.url/ HTTP/1.1
>    Content-Type: application/oscore
>    CoAP-Object-Security: 09 25

The first block of text defines CoAP-Object-Security as a Base64 string. The
second shows an example string of hex digits. Please either redefine the
syntax in the first block, or show a matching syntax in the examples.

This comment applies to §10.4 also.

[Ballot discuss]
§5 contains the following uses of "SHOULD NOT":

>    *  The 'Partial IV' parameter.  The value is set to the Sender
>        Sequence Number.  All leading zeroes SHALL be removed when
>        encoding the Partial IV.  The value 0 encodes to the byte
>        string 0x00.  This parameter SHALL be present in requests.  In
>        case of Observe (Section 4.2.3.4) the Partial IV SHALL be
>        present in responses, and otherwise the Partial IV SHOULD NOT
>        be present in responses.  (A non-Observe example where the
>        Partial IV is included in a response is provided in
>        Section 7.5.2.)
>
>    *  The 'kid' parameter.  The value is set to the Sender ID.  This
>        parameter SHALL be present in requests and SHOULD NOT be
>        present in responses.  An example where the Sender ID is
>        included in a response is the extension of OSCORE to group
>        communication [I-D.tiloca-core-multicast-oscoap].

As far as I can tell, both "SHOULD NOT" instances describe behavior that is
unnecessary but benign. This usage is inconsistent with the definition of
"SHOULD NOT" in RFC 2119:

4. SHOULD NOT  This phrase, or the phrase "NOT RECOMMENDED" mean that
  there may exist valid reasons in particular circumstances when the
  particular behavior is acceptable or even useful, but the full
  implications should be understood and the case carefully weighed
  before implementing any behavior described with this label.

If the implications are simply "this is unnecessary but benign," then
implementors have no real implications to weigh, and the described behavior
doesn't rise to the level of "SHOULD NOT". If the implications are stronger
than that, then *this* document doesn't contain enough information for
implementors to perform such an evaluation.

In the former case, you can clear this discuss by changing "SHOULD NOT" to "will
not typically". In the latter case, you can clear this discuss by adding enough
information for implementors to be able to make an educated weighing of
implications. I'm also open to other proposals that remedy this use of 2119
language.

[Ballot comment]
I support EKR's DISCUSS.

Martin Thompson raises a number of fairly important points in his review (see
). I
recognize that many of these are fundamental to the design in the document. It
is still worthwhile thinking through them and trying to suss out whether a
redesign by the working group is warranted.

I do want to put a little more meat on Martin's assertion "This doesn't appear
to have any supporting security analysis," as this was something I was going
to highlight myself (and this is related to EKR's DISCUSS as well). Given that
this document seems to be putting together security primitives in a de novo
fashion, I would expect to see something equivalent to draft-ietf-tls-tls13's
Appendix E.

Specific comments follow.

---------------------------------------------------------------------------

§1:

>  ([RFC6347]) for security.  CoAP and HTTP proxies require (D)TLS to be
>  terminated at the proxy

Presumably, this means "CoAP-to-HTTP proxies"? Otherwise, the assertion is
wrong: HTTP proxies do not terminate TLS connections.

---------------------------------------------------------------------------
§1:

>  An implementation supporting this specification MAY only implement
>  the client part, MAY only implement the server part, or MAY only
>  implement one of the proxy parts

Replace "MAY only implement" with "MAY implement only" (in three places)

---------------------------------------------------------------------------

§1.1:

>  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].  These
>  words may also appear in this document in lowercase, absent their
>  normative meanings.

This is almost, but not quite, the RFC 8174 boilerplate. Please fix it to match
RFC 8174.

---------------------------------------------------------------------------

§2:

>  +-----+---+---+---+---+-----------------+--------+--------+---------+
>  | No. | C | U | N | R | Name            | Format | Length | Default |
>  +-----+---+---+---+---+-----------------+--------+--------+---------+
>  | TBD | x |  |  |  | Object-Security |  (*)  | 0-255  | (none)  |
>  +-----+---+---+---+---+-----------------+--------+--------+---------+
>      C = Critical,  U = Unsafe,  N = NoCacheKey,  R = Repeatable
>      (*) See below.
>
>                  Figure 3: The Object-Security Option

I get the impression that this is supposed to be extending a table that already
exists somewhere. This document should say which table.

---------------------------------------------------------------------------

§4.1:

>  The CoAP Payload, if present in the original CoAP message, SHALL be
>  encrypted and integrity protected and is thus an Inner message field.
>  See Figure 5.
>
>                      +------------------+---+---+
>                      | Field            | E | U |
>                      +------------------+---+---+
>                      | Payload          | x |  |
>                      +------------------+---+---+
>
>                E = Encrypt and Integrity Protect (Inner)
>                U = Unprotected (Outer)
>
>                  Figure 5: Protection of CoAP Payload

The figure adds nothing to the prose; and is, in fact, harder to understand than
the prose. I would recommend removing it.

---------------------------------------------------------------------------

§4.3:

>  The other CoAP Header fields are Unprotected (Class U).

Presumably this should say "The other currently defined CoAP Header fields...",
right?


---------------------------------------------------------------------------

§5:

>  As specified in [RFC5116], plaintext denotes the data that is
>  encrypted and integrity protected...

Traditionally, data that is encrypted is called "cipher text." I gather from
context that this should probably "...the data that is to be encrypted...",
right?

---------------------------------------------------------------------------

§5.2:

>  responses, which reduces the size.  For processing instructions (see
>  Section 8).

This final fragment can be turned into a sentence by removing the parentheses.


---------------------------------------------------------------------------

§6 and its subsections:

The use of a bespoke profile of COSE adds implementation complexity to
ostenstibly resource-limited device for what appears to be very little gain. In
the examples given, savings of 4 to 7 bytes are demonstrated, which seems to
hardly warrant the addition of this mechanism. These do not appear to be
degenerate cases, so I can't imagine that compression performance under
real-world conditions would be much better.  Was there an explicit discussion
in the working group regarding this complexity/wire-size trade-off?

---------------------------------------------------------------------------

§6.3.1:

>  1.  Request with kid = 25 and Partial IV = 5

The base of the numbers above isn't indicated, and the reasonable reader may
take it to be 10. Please either change the above line to "...kid = 0x25...",
or change the hex encodings in the examples to h'19'.

---------------------------------------------------------------------------

§7.3:

>  For requests, OSCORE provides weak absolute freshness as the only

The meaning of "weak absolute freshness" doesn't appear to be given anywhere,
and is not evident by combining the normal meanings of those three words. Please
describe the property of "weak absolute freshness" in more detail (or, if this
is a term of art defined elsewhere, a citation would be sufficient).

--------------------------------------------------------------------------

§10.3:

>  o  "" (empty string) if the CoAP Object-Security option is empty, or

Which is it? Is this an empty string on the wire, or is it a string consisting
of "" (that is, the two-byte sequence 0x22 0x22)?

---------------------------------------------------------------------------

§10.3:

>[HTTP request -- Before client object security processing]

This line should be indented to match the rest of the example.

---------------------------------------------------------------------------

§10.3:

>  o  the value of the CoAP Object-Security option (Section 6.1) in
>    base64url encoding (Section 5 of [RFC4648]) without padding (see
>    [RFC7515] Appendix C for implementation notes for this encoding).

...

>    POST http://proxy.url/hc/?target_uri=coap://server.url/ HTTP/1.1
>    Content-Type: application/oscore
>    CoAP-Object-Security: 09 25

The first block of text defines CoAP-Object-Security as a Base64 string. The
second shows an example string of hex digits. Please either redefine the
syntax in the first block, or show a matching syntax in the examples.

This comment applies to §10.4 also.

[Ballot discuss]
https://mozphab-ietf.devsvcdev.mozaws.net/D3075

DISCUSS
My overall concern with this document is that I am unable to evaluate
the security properties of the system. I have described a number of
issues below, but the basic problem is that this sort of partial
protection is extremely hard to reason about and the security
considerations do not do an adequate job of evaluating the impact of
proxies modifying these values. I am similarly concerned about the
HTTP mapping and link section which seems extremely sketchy and has
essentially no security analysis, and yet potentially have a lot
of landmines.

At minimum, this document needs to walk through the implications
of modifications by the proxy to every unprotected field in
the pure CoAP context as well as the HTTP context (if you want
to retain that binding).


  are given in Appendix A.  OSCORE does not depend on underlying
  layers, and can be used anywhere where CoAP or HTTP can be used,
  including non-IP transports (e.g., [I-D.bormann-6lo-coap-802-15-ie]).
 
IMPORTANT: This document claims to be applicable to protocols other
than COAP, in particular HTTP. Has this been reviewed by the HTTP
working group? Martin Thomson's review suggests that this is out of
step with HTTP practice.


  IDs MUST be long uniformly random distributed byte strings such that
  the probability of collisions is negligible.

IMPORTANT: I don't understand how this paragraph and the previous
paragraph interact. You say that the maximum length is 7 octets in the
previous paragraph, which I don't think qualifies as "long".


                    |  1 | If-Match        | x |  |
                    |  3 | Uri-Host        |  | x |
                    |  4 | ETag            | x |  |
IMPORTANT: Why do you think that it's not important to have integrity protection for Uri-Host and Uri-port?


  Outer option message fields (Class U or I) are used to support proxy
  operations.
IMPORTANT: This seems problematic because the proxy cannot verify class I fields.



  layer only, and not the Messaging Layer (Section 2 of [RFC7252]), so
  fields such as Type and Message ID are not protected with OSCORE.
 
IMPORTANT: This seems extremely hard to reason about. What are the
implications of the proxy being able to change these?



  o  request_piv: contains the value of the 'Partial IV' in the COSE
      object of the request (see Section 5).
     
IMPORTANT: I think what I am getting here is that the request_piv is
used to verify that the request and response match. However, I do not
see this explicitly stated anywhere, and it's not clear to me how the
client is supposed to recover the request_piv and the text is pretty
unclear here? Is the external_aad carried somewhere in the message? Am
I supposed to reconstruct it from the message id?


  For responses, the message binding guarantees that a response is not
  older than its request.  For responses without Observe, this gives
 
IMPORTANT: I am not sure that this is true. What happens of the
counterparty lies? What is your threat model?

  An extension of OSCORE may also be used to protect group
  communication for CoAP [I-D.tiloca-core-multicast-oscoap].  The use
  of OSCORE does not affect the URI scheme and OSCORE can therefore be
  used with any URI scheme defined for CoAP or HTTP.  The application
  decides the conditions for which OSCORE is required.

This is pretty surprising to just drop in here. Multicast has totally different
security properties from non-multicast.

[Ballot comment]


  but is also able to eavesdrop on, or manipulate any part of the
  message payload and metadata, in transit between the endpoints.  The
  proxy can also inject, delete, or reorder packets since they are no
Nit: you want
"eavesdrop on, or manipulate any part of, the message payload and metadata in transit"

I.e., move the second comma



  the endpoints, and those are therefore processed as defined in
  [RFC7252].  Additionally, since the message formats for CoAP over
  unreliable transport [RFC7252] and for CoAP over reliable transport
Nit: "OSCORE protects neither .... nor...."


                       

      Salt.  Length is determined by the AEAD Algorithm.  Its value is
>      immutable once the security context is established.
Nit: you might just say above or below this list that all the values are immutable,



  different operations.  One mechanism enabling this is specified in
  [I-D.ietf-core-echo-request-tag].
Is this a security condition?



      of [RFC7252], where the delta is the difference to the previously
      included class I option.
Is the delta here the previously included Class I option or the previously included instance of the same option, as it appears to say in S 3.1.



        compressed COSE object.  The values n = 6 and n = 7 are
        reserved.
How can Partial IV not be present? it's the sequence number. Is the answer that it is the 0 value?



  response.  The server therefore needs to store the kid and Partial IV
  of the request until all responses have been sent.
It was my understanding that the kid was needed to look up the key. Why are kid substitution attacks an issue?



  The maximum Sender Sequence Number is algorithm dependent (see
  Section 11), and no greater than 2^40 - 1.  If the Sender Sequence
  Number exceeds the maximum, the endpoint MUST NOT process any more
If you take my suggestion about removing senderID from the nonce you will be able to relax this.




  After boot, an endpoint MAY reject to use existing security contexts
  from before it booted and MAY establish a new security context with
Nit: this is ungrammatical



      included in the message.  If the AEAD nonce from the request was
      used, the Partial IV MUST NOT be included in the message.
IMPORTANT: You are now violating the invariant of using the same nonce twice. That's fine in this case, because you have per-sender keys but it demonstrates that it is unnecessary to encode the sender_id in the nonce field.



  Security level here means that an attacker can recover one of the m
  keys with complexity 2^(k + n) / m.  Protection against such attacks
  can be provided by increasing the size of the keys or the entropy of
This paragraph is extremely hard to follow but I am not persuaded that it is correct. Do you have a citation for the claim that you can add the key entropy and the nonce entropy like this.



  style of padding means that all values need to be padded.  Similar
  arguments apply to other message fields such as resource names.
The PKCS#7 padding scheme at minimum has potential timing channels



  The server verifies that the Partial IV has not been received before.
  The client verifies that the response is bound to the request.
How does the client verify this


      Partial IV (in network byte order) with zeroes to exactly nonce
      length - 6 bytes,
     
IMPORTANT: I don't understand the reason for this construction. You
already require that the key be derived via HKDF from the |master key|
and |sender ID| therefore, it is not necessarily to separately encode
the sender ID in the nonce. This would ordinarily not be a large
issue, but as it requires very extreme restrictions on the sender ID
(and essentially precludes random sender IDs) I believe it is worth
considering changing, but it's ultimately a WG decision, hence not
in my discuss.

[Ballot comment]
I’m balloting “yes”, but I have a few very minor comments:

Substantive Comments:

§4.2.2, last paragraph: Why not specify that directly, rather than put a normative requirements on new specifications?

Editorial and Nits:

§4.2.3.1, 2nd to last paragraph:
Last sentence is hard to parse.

§5, third paragraph:
I don’t think that spec claims “plaintext” means “data that is encrypted and integrity protected”. I think it means “ the clear text input that will be encrypted and integrity protected” (This could probably be fixed by changing “data that is” to “data to be”.)

§8.1, last paragraph: The SHALL seems more like a statement of fact than a requirement.

[Ballot comment]
This sentence in the intro sounds rather speculative to me:
"An extension of OSCORE may also be used to protect group
  communication for CoAP [I-D.tiloca-core-multicast-oscoap]. "
Maybe just remove it?

HTML format at http://jaimejim.github.io/temp/draft-ietf-core-object-security.html

## Shepherd Writeup

###Summary

* Document Shepherd: Jaime Jiménez,
* Area Director: Alexey Melnikov,

This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.

The document is intended as a Standards Track document.

###Review and Consensus

The document has gone through multiple expert reviews and has been discussed on multiple IETF meetings. Before the last IETF the WGLC was completed.

###Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

###Other Points
There are RFC Editor comments that need to be edited out "note to RFC Editor".
There have been multiple (informal) interops that have been instrumental in improving the document.
There are some available implementations at:
- Java (Californium): https://bitbucket.org/lseitz/oscoap_californium
- C (Contiki, Erbium): https://github.com/Gunzter/contiki-oscoap
- Python (aiocoap): https://github.com/chrysn/aiocoap
- C# (CoAP-CSharp): https://github.com/Com-AugustCellars/CoAP-CSharp
- Python (CoAP for openwsn): https://github.com/openwsn-berkeley/coap
- C (openwsn-fw): https://github.com/openwsn-berkeley/openwsn-fw

###Checklist

* [x] Does the shepherd stand behind the document and think the document is ready for publication?
* [x] Is the correct RFC type indicated in the title page header?
* [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
* [x] Is the intent of the document accurately and adequately explained in the introduction?
* [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
* [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
* [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
* [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
* [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
* [x] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction? `Does not apply`
* [x] If this is a "bis" document, have all of the errata been considered? `Does not apply`

**IANA** Considerations:

```
IANA shall add 'kid context' to the COSE Header Parameters Registry.
A new CoAP Option is created.
a new CoAP Signaling Option is created.
a new Header Field is added to the Message Headers registry.
```

* [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
* [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
* [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
* [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
* [x] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
* [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
* [x] Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?

HTML format at http://jaimejim.github.io/temp/draft-ietf-core-object-security.html

## Shepherd Writeup

###Summary

* Document Shepherd: Jaime Jiménez,
* Area Director: Alexey Melnikov,

This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.

The document is intended as a Standards Track document.

###Review and Consensus

The document has gone through multiple expert reviews and has been discussed on multiple IETF meetings. Before the last IETF the WGLC was completed.

###Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

###Other Points
There are RFC Editor comments that need to be edited out "note to RFC Editor".
There have been multiple (informal) interops that have been instrumental in improving the document.
There are some available implementations at:
- https://bitbucket.org/lseitz/oscoap_californium/  (Java, based on Californium library)
- https://github.com/Gunzter/contiki-oscoap  (C, based on Contiki OS)
- https://github.com/jimsch/CoAP-CSharp

###Checklist

* [x] Does the shepherd stand behind the document and think the document is ready for publication?
* [x] Is the correct RFC type indicated in the title page header?
* [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
* [x] Is the intent of the document accurately and adequately explained in the introduction?
* [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
* [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
* [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
* [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
* [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
* [x] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction? `Does not apply`
* [x] If this is a "bis" document, have all of the errata been considered? `Does not apply`

**IANA** Considerations:

```
IANA shall add 'kid context' to the COSE Header Parameters Registry.
A new CoAP Option is created.
a new CoAP Signaling Option is created.
a new Header Field is added to the Message Headers registry.
```

* [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
* [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
* [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
* [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
* [x] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
* [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
* [x] Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?

[Ballot comment]
Unfortunately, I ran out of time to properly ballot / review - I'd like to point the responsible AD at Erik Vyncke's OPS-DIR review (and the response) at https://www.ietf.org/mail-archive/web/ops-dir/current/msg03116.html

HTML format at http://jaimejim.github.io/temp/draft-ietf-core-object-security.html

## Shepherd Writeup

###Summary

* Document Shepherd: Jaime Jiménez,
* Area Director: Alexey Melnikov,

This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.

The document is intended as a Standards Track document.

###Review and Consensus

The document has gone through multiple expert reviews and has been discussed on multiple IETF meetings. Before the last IETF the WGLC was completed.

###Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

###Other Points
There are RFC Editor comments that need to be edited out "note to RFC Editor".
There have been multiple (informal) interops that have been instrumental in improving the document.

###Checklist

* [x] Does the shepherd stand behind the document and think the document is ready for publication?
* [x] Is the correct RFC type indicated in the title page header?
* [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
* [x] Is the intent of the document accurately and adequately explained in the introduction?
* [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
* [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
* [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
* [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
* [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
* [x] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction? `Does not apply`
* [x] If this is a "bis" document, have all of the errata been considered? `Does not apply`

**IANA** Considerations:

```
IANA shall add 'kid context' to the COSE Header Parameters Registry.
A new CoAP Option is created.
a new CoAP Signaling Option is created.
a new Header Field is added to the Message Headers registry.
```

* [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
* [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
* [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
* [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
* [x] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
* [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
* [x] Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?

HTML format at http://jaimejim.github.io/temp/draft-ietf-core-object-security.html

## Shepherd Writeup

###Summary

* Document Shepherd: Jaime Jiménez,
* Area Director: Alexey Melnikov,

This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.

The document is intended as a Standards Track document.

###Review and Consensus

The document has gone through multiple expert reviews and has been discussed on multiple IETF meetings. Before the last IETF the WGLC was completed.

###Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

###Other Points
There are RFC Editor comments that need to be edited out "note to RFC Editor".

###Checklist

* [x] Does the shepherd stand behind the document and think the document is ready for publication?
* [x] Is the correct RFC type indicated in the title page header?
* [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
* [x] Is the intent of the document accurately and adequately explained in the introduction?
* [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
* [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
* [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
* [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
* [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
* [x] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction? `Does not apply`
* [x] If this is a "bis" document, have all of the errata been considered? `Does not apply`

**IANA** Considerations:

```
IANA shall add 'kid context' to the COSE Header Parameters Registry.
A new CoAP Option is created.
a new CoAP Signaling Option is created.
a new Header Field is added to the Message Headers registry.
```

* [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
* [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
* [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
* [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
* [x] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
* [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
* [x] Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?

## Shepherd Writeup

###Summary

* Document Shepherd: Jaime Jiménez,
* Area Director: Alexey Melnikov,

This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.

The document is intended as a Standards Track document.

###Review and Consensus

The document has gone through multiple expert reviews and has been discussed on multiple IETF meetings. Before the last IETF the WGLC was completed.

###Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

###Other Points
There are RFC Editor comments that need to be edited out "note to RFC Editor".

###Checklist

* [x] Does the shepherd stand behind the document and think the document is ready for publication?
* [x] Is the correct RFC type indicated in the title page header?
* [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
* [x] Is the intent of the document accurately and adequately explained in the introduction?
* [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
* [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
* [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
* [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
* [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
* [x] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction? `Does not apply`
* [x] If this is a "bis" document, have all of the errata been considered? `Does not apply`

**IANA** Considerations:

```
IANA shall add 'kid context' to the COSE Header Parameters Registry.
A new CoAP Option is created.
a new CoAP Signaling Option is created.
a new Header Field is added to the Message Headers registry.
```

* [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
* [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
* [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
* [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
* [x] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
* [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
* [x] Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?

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

The IANA Services Operator has completed its review of draft-ietf-core-object-security-08. If any part of this review is inaccurate, please let us know.

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

First, in the COSE Header Parameters registry on the CBOR Object Signing and Encryption (COSE) registry page located at:

https://www.iana.org/assignments/cose/

a single new header parameter will be registered as follows:

Name: kid context
Label: kidctx
Value type: bstr
Value registry:
Description: kid context
Reference: [ RFC-to-be ]

NOTE: The document doesn't state which value range the parameter should come from, but as all registrations in this registry require expert review, even in the Standards Action ranges, we've sent the document to the designated experts for review. If you have more information, we can send it on. This registration should be approved by the experts before the document is approved.

Second, CoAP Option Numbers registry on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

https://www.iana.org/assignments/core-parameters/

a single new option number will be registered as follows:

Number: [ TBD-at-Registration ]
Name: Object-Security
Reference: [ RFC-to-be ]

Third, in the CoAP Signaling Option Numbers registry also on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

https://www.iana.org/assignments/core-parameters/

a single new signalling option number will be registered as follows:

Applies to: 7.XXXX
Number: [ TBD-at-Registration ]
Name: Object-Security
Reference: [ RFC-to-be ]

where XXXX is the value to be determined in step two above.

Fourth, in the Permanent Message Header Field Names registry on the Message Headers registry page located at:

https://www.iana.org/assignments/message-headers/

a single new message header is to be added to the registry as follows:

Header Field Name: Object-Security
Template:
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 5226) registry, we have initiated the required review via a separate request. Expert review should be completed before your document is approved for publication as an RFC.

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

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

Thank you,

Amanda Baber
IANA Services Specialist

AD review of -08:

In general I found the document to be well written and quite detailed
(which I like). Some smaller issues and a few questions below:

Minor:

1) I found Section 6 to be confusing. There is nothing about payload
compression there. There is also description of the Object-Security
option format. Maybe rename the section, as it is not purely about
compression?

In particular, In Section 6.1: I suggest you explain that
Object-Security option is a more compact encoding of the Headers in the
COSE_Encrypt0 structure. If that is not the case, then I think this
section needs even more work.

2) In Section 8.3, point 3:

If Observe is not used, either the nonce from the
request is used or a new Partial IV is used.

How can the responder decide which of the choices to use? (If this is
covered elsewhere in the document, I would appreciate a reference).

3) In Section 9: Does "osc" target attribute need to be registered with
IANA?

4) In Section 10.1: the reference to [I-D.ietf-core-echo-request-tag]
looks Normative to me, not Informative.

5) In Section 10.2: which media type is used for the OSCORE-encrypted
payload transported in HTTP?


Nits:

In Section 3.3:
  To enable retrieval of the right Recipient Context, the Recipient ID
  SHOULD be unique in the sets of all Recipient Contexts used by an

Does this SHOULD need a bit more explaining (i.e. why it is not a MUST)?

  endpoint. The Client MAY provide a 'kid context' parameter (Section
  5.1) to help the Server find the right context.

[I-D.ietf-core-coap-tcp-tls] - this is RFC 8323 now.

First mention of AEAD needs a reference to RFC 5116. The document
references it later on in the document, so maybe just move the reference
earlier.

The following Last Call announcement was sent out (ends 2018-03-02):

From: The IESG
To: IETF-Announce
CC: alexey.melnikov@isode.com, draft-ietf-core-object-security@ietf.org, core-chairs@ietf.org, core@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Object Security for Constrained RESTful Environments (OSCORE)) to Proposed Standard


The IESG has received a request from the Constrained RESTful Environments WG
(core) to consider the following document: - 'Object Security for Constrained
RESTful Environments (OSCORE)'
  as Proposed Standard

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

Abstract


  This document defines Object Security for Constrained RESTful
  Environments (OSCORE), a method for application-layer protection of
  the Constrained Application Protocol (CoAP), using CBOR Object
  Signing and Encryption (COSE).  OSCORE provides end-to-end protection
  between endpoints communicating using CoAP or CoAP-mappable HTTP.
  OSCORE is designed for constrained nodes and networks supporting a
  range of proxy operations, including translation between different
  transport protocols.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-core-object-security/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ballot/


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