--- 1/draft-ietf-ace-cwt-proof-of-possession-10.txt 2019-10-31 08:13:13.458077115 -0700 +++ 2/draft-ietf-ace-cwt-proof-of-possession-11.txt 2019-10-31 08:13:13.494078024 -0700 @@ -1,25 +1,25 @@ ACE M. Jones Internet-Draft Microsoft Intended status: Standards Track L. Seitz -Expires: May 2, 2020 RISE SICS +Expires: May 3, 2020 RISE SICS G. Selander Ericsson AB S. Erdtman Spotify H. Tschofenig Arm Ltd. - October 30, 2019 + October 31, 2019 Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) - draft-ietf-ace-cwt-proof-of-possession-10 + draft-ietf-ace-cwt-proof-of-possession-11 Abstract This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder- of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs @@ -34,21 +34,21 @@ 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 May 2, 2020. + This Internet-Draft will expire on May 3, 2020. Copyright Notice Copyright (c) 2019 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 @@ -437,22 +437,22 @@ However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published. [[ Note to the RFC Editor: The name of the mailing list should be determined in consultation with the IESG and IANA. Suggested name: cwt-reg- review@ietf.org. ]] Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to Register CWT Confirmation Method: example"). Registration requests that are undetermined for a - period longer than 21 days can be brought to the IESG's attention - (using the iesg@ietf.org mailing list) for resolution. + period longer than 21 days can be brought directly to IANA's + attention (using the iana@iana.org mailing list) for resolution. Designated Experts should determine whether a registration request contains enough information for the registry to be populated with the new values and whether the proposed new functionality already exists. In the case of an incomplete registration or an attempt to register already existing functionality, the Designated Experts should ask for corrections or reject the registration. It is suggested that multiple Designated Experts be appointed who are able to represent the perspectives of different applications using @@ -632,20 +632,24 @@ Vyncke, and Jim Schaad. Ludwig Seitz and Goeran Selander worked on this document as part of the CelticPlus projects CyberWI and CRITISEC, with funding from Vinnova. Document History [[ to be removed by the RFC Editor before publication as an RFC ]] + -11 + + o Addressed remaining IESG review comment by Mirja Kuehlewind. + -10 o Addressed IESG review comments by Adam Roach and Eric Vyncke. -09 o Addressed Gen-ART review comments by Christer Holmberg and SecDir review comments by Yoav Nir. -08