Re: [Ace] CBOR Web Token (CWT) draft addressing shepherd review comments

[Mike Jones]

Good point.  I'll make a note to update the description the next time we 
publish a draft to not imply that values in the Private Use range are 
registered.  I don't think it's worth publishing another draft for just this 
until we receive Kathleen's AD review, at which point I'll address it.

Grüße,
-- Mike 

-Original Message-
From: Carsten Bormann  
Sent: Friday, February 2, 2018 9:28 PM
To: Mike Jones 
Cc: ace@ietf.org
Subject: Re: [Ace] CBOR Web Token (CWT) draft addressing shepherd review 
comments

»
Depending upon the values being requested, registration requests are
evaluated on a Standards Track Required, Specification Required,
Expert Review, or Private Use basis [RFC8126] «

This might give the impression that IANA registrations can be made on a 
“Private Use” basis.
RFC 8126 Section 4.1 says about Private Use:

   […] IANA does not record assignments from registries
   or ranges with this policy (and therefore there is no need for IANA
   to review them) and assignments are not generally useful for broad
   interoperability.  It is the responsibility of the sites making use
   of the Private Use range to ensure that no conflicts occur (within
   the intended scope of use).

Maybe it is better to just point at the section giving the actual policies?

Grüße, Carsten

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] CBOR Web Token (CWT) draft addressing shepherd review comments

[Carsten Bormann]

»
Depending upon the values being requested, registration requests are
evaluated on a Standards Track Required, Specification Required,
Expert Review, or Private Use basis [RFC8126]
«

This might give the impression that IANA registrations can be made on a 
“Private Use” basis.
RFC 8126 Section 4.1 says about Private Use:

   […] IANA does not record assignments from registries
   or ranges with this policy (and therefore there is no need for IANA
   to review them) and assignments are not generally useful for broad
   interoperability.  It is the responsibility of the sites making use
   of the Private Use range to ensure that no conflicts occur (within
   the intended scope of use).

Maybe it is better to just point at the section giving the actual policies?

Grüße, Carsten

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] shepherd review of draft-ietf-ace-cbor-web-token-11

[Mike Jones]

Thanks for your useful review, Ben.  I believe that 
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-12 addresses all your 
comments and is ready to send to Kathleen.

Best wishes,
-- Mike

-Original Message-
From: Benjamin Kaduk  
Sent: Friday, February 2, 2018 2:25 PM
To: ace@ietf.org; draft-ietf-ace-cbor-web-to...@ietf.org
Subject: shepherd review of draft-ietf-ace-cbor-web-token-11

Hi all,

We're getting ready to send this to Kathleen for processing (hopefully to 
finish before her term as AD does!), but there are a few nits that should be 
fixed with a new rev before we actually push the button.

We currently have an informational reference to RFC 5226, which has since been 
replaced by RFC 8126; we should update our citation to the newer document with 
guidelines for writing IANA considerations.

In section 9.1 the second pargaraph says that the values are registerd on a 
"Specification Required" basis, but we have some ranges that are just "Expert 
Review".  So I think this text should say "Expert Review" instead (with some of 
the guidance to the experts being that certain subranges have additional 
requirements).

We also note that the Experts should consider "whether it is useful only for a 
single application", and it's not entirely clear to me what the reuslt of that 
consideration should be.  Is only being useful for a single application 
supposed to be grounds for rejecting a registration?  (That doesn't seem 
necessarily true, for the Expert Review range.)  Or is that just a factor for 
whether "nice-looking"
names should be allowed for them?  Or something else?

In section 9.4, we attempt to register a value from the CBOR Tag registry; 
however, the template in RFC 7049 includes a "description of semantics" field, 
and not the "reference" field that we provide.

Finally, in the acknowledgments, we can ask the RFC Editor to use the non-ASCII 
"Gőran" if he so desires.  (Last I heard the tooling isn't there to use 
non-ASCII for internet drafts yet, though.)

Authors, will you be able to prepare a new version with these changes?

Thanks,

Ben
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] CBOR Web Token (CWT) draft addressing shepherd review comments

[Mike Jones]

The CBOR Web Token (CWT) specification has been updated to address the shepherd 
comments by Benjamin Kaduk.  Changes were:

  *   Updated the RFC 5226 reference to RFC 8126.
  *   Made the IANA registration criteria consistent across sections.
  *   Stated that registrations for the limited set of values between -256 and 
255 and strings of length 1 are to be restricted to claims with general 
applicability.
  *   Changed the "Reference" field name to "Description of Semantics" in the 
CBOR Tag registration request.
  *   Asked the RFC Editor whether it is possible to preserve the non-ASCII 
spellings of the names Erik Wahlström and Göran Selander in the final 
specification.

Thanks to Ben for his careful review of the specification!

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-12

An HTML-formatted version is also available at:

  *   http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-12.html

   -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1776 and as 
@selfissued.


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] I-D Action: draft-ietf-ace-cbor-web-token-12.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for 
Constrained Environments WG of the IETF.

Title   : CBOR Web Token (CWT)
Authors : Michael B. Jones
  Erik Wahlström
  Samuel Erdtman
  Hannes Tschofenig
Filename: draft-ietf-ace-cbor-web-token-12.txt
Pages   : 25
Date: 2018-02-02

Abstract:
   CBOR Web Token (CWT) is a compact means of representing claims to be
   transferred between two parties.  The claims in a CWT are encoded in
   the Concise Binary Object Representation (CBOR) and CBOR Object
   Signing and Encryption (COSE) is used for added application layer
   security protection.  A claim is a piece of information asserted
   about a subject and is represented as a name/value pair consisting of
   a claim name and a claim value.  CWT is derived from JSON Web Token
   (JWT) but uses CBOR rather than JSON.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-12
https://datatracker.ietf.org/doc/html/draft-ietf-ace-cbor-web-token-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-cbor-web-token-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] shepherd review of draft-ietf-ace-cbor-web-token-11

[Carsten Bormann]

On Feb 2, 2018, at 23:24, Benjamin Kaduk  wrote:
> 
> Finally, in the acknowledgments, we can ask the RFC Editor to use
> the non-ASCII "Gőran" if he so desires.  (Last I heard the tooling
> isn't there to use non-ASCII for internet drafts yet, though.)

We have the same issue in RFC 8323-to-be (CoAP over TCP), and the RFC editor is 
in the process of figuring out how to handle Swedish umlauts in names (UTF-8 
not just yet!).  So don’t worry about this too much now; the RFC editor will 
fix it.

Grüße, Carsten

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] shepherd review of draft-ietf-ace-cbor-web-token-11

[Mike Jones]

Thanks for the detailed read, Ben.  Will do.

-- Mike

-Original Message-
From: Benjamin Kaduk [mailto:ka...@mit.edu] 
Sent: Friday, February 2, 2018 2:25 PM
To: ace@ietf.org; draft-ietf-ace-cbor-web-to...@ietf.org
Subject: shepherd review of draft-ietf-ace-cbor-web-token-11

Hi all,

We're getting ready to send this to Kathleen for processing (hopefully to 
finish before her term as AD does!), but there are a few nits that should be 
fixed with a new rev before we actually push the button.

We currently have an informational reference to RFC 5226, which has since been 
replaced by RFC 8126; we should update our citation to the newer document with 
guidelines for writing IANA considerations.

In section 9.1 the second pargaraph says that the values are registerd on a 
"Specification Required" basis, but we have some ranges that are just "Expert 
Review".  So I think this text should say "Expert Review" instead (with some of 
the guidance to the experts being that certain subranges have additional 
requirements).

We also note that the Experts should consider "whether it is useful only for a 
single application", and it's not entirely clear to me what the reuslt of that 
consideration should be.  Is only being useful for a single application 
supposed to be grounds for rejecting a registration?  (That doesn't seem 
necessarily true, for the Expert Review range.)  Or is that just a factor for 
whether "nice-looking"
names should be allowed for them?  Or something else?

In section 9.4, we attempt to register a value from the CBOR Tag registry; 
however, the template in RFC 7049 includes a "description of semantics" field, 
and not the "reference" field that we provide.

Finally, in the acknowledgments, we can ask the RFC Editor to use the non-ASCII 
"Gőran" if he so desires.  (Last I heard the tooling isn't there to use 
non-ASCII for internet drafts yet, though.)

Authors, will you be able to prepare a new version with these changes?

Thanks,

Ben
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] shepherd review of draft-ietf-ace-cbor-web-token-11

[Benjamin Kaduk]

Hi all,

We're getting ready to send this to Kathleen for processing
(hopefully to finish before her term as AD does!), but there are a
few nits that should be fixed with a new rev before we actually push
the button.

We currently have an informational reference to RFC 5226, which has
since been replaced by RFC 8126; we should update our citation to
the newer document with guidelines for writing IANA considerations.

In section 9.1 the second pargaraph says that the values are
registerd on a "Specification Required" basis, but we have some
ranges that are just "Expert Review".  So I think this text should
say "Expert Review" instead (with some of the guidance to the
experts being that certain subranges have additional requirements).

We also note that the Experts should consider "whether it is useful
only for a single application", and it's not entirely clear to me
what the reuslt of that consideration should be.  Is only being
useful for a single application supposed to be grounds for rejecting
a registration?  (That doesn't seem necessarily true, for the Expert
Review range.)  Or is that just a factor for whether "nice-looking"
names should be allowed for them?  Or something else?

In section 9.4, we attempt to register a value from the CBOR Tag
registry; however, the template in RFC 7049 includes a "description
of semantics" field, and not the "reference" field that we provide.

Finally, in the acknowledgments, we can ask the RFC Editor to use
the non-ASCII "Gőran" if he so desires.  (Last I heard the tooling
isn't there to use non-ASCII for internet drafts yet, though.)

Authors, will you be able to prepare a new version with these
changes?

Thanks,

Ben

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Working group adoption of draft-vanderstok-ace-est

[Rupak Chandra (ruchandr)]

I support the adoption of this draft. There is a great need for a standards 
based mechanism for secure enrollment of constrained endpoints, which this 
draft provides.

Thanks
Rupak
-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Jim Schaad
Sent: Tuesday, January 30, 2018 12:23 PM
To: ace@ietf.org
Subject: [Ace] Working group adoption of draft-vanderstok-ace-est

This is the start of a two week call for input on the adoption of the WG of the 
document draft-vanderstok-ace-est.  The document has been presented at the last 
two meetings and has some significant recent updates to respond to feedback.  
There seemed to be support at the last F2F to adopt. 

Please provide feedback to the list/chairs if you believe that this document
should be adopted as a WG document.The adoption call will end on Feb 13
2018.

Jim


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Working group adoption of draft-vanderstok-ace-est

[Nancy Cam-Winget (ncamwing)]

I support the adoption of this draft.  The industrial IoT sector is 
establishing certificate based secure communications and will need a secure 
means to manage these certificates.  With the use of CoAp in that space, this 
draft can be the what/how to achieve just that.

Warm regards, Nancy

On 1/30/18, 12:23 PM, "Ace on behalf of Jim Schaad"  wrote:

This is the start of a two week call for input on the adoption of the WG of
the document draft-vanderstok-ace-est.  The document has been presented at
the last two meetings and has some significant recent updates to respond to
feedback.  There seemed to be support at the last F2F to adopt.

Please provide feedback to the list/chairs if you believe that this document
should be adopted as a WG document.The adoption call will end on Feb 13
2018.

Jim


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Working group adoption of draft-vanderstok-ace-est

[peter van der Stok]

Hi Stefan,

Thanks for the support.
I see your point of view; We will look at the text to avoid suggesting 
that EST/https and EST/coaps cannot exist together.


Peter

Beck, Stefan schreef op 2018-02-01 12:51:

+1
I support adoption, as it perfectly complements the existing EST work.

So far, just one general comment:
The draft could emphasize (e.g. in the intro) that coexistence of EST
and EST-coaps is supported in target deployments. And you even may
have a combination of constrained devices in a non-constrained network
and vice versa.
If that matches the authors’ view, then some general statements need
to be adapted. Two examples see below

Stevie


1. Abstract:
 "This allows low-resource constrained devices to re-use existing EST
functionality. Example low-resource use cases for EST are: secure
bootstrapping and certificate enrollment."

Well, to me those are the two main use cases for non-constrained
devices using EST, too. So I would write:
 "This allows low-resource constrained devices to re-use existing EST
functionality to implement use cases such as secure bootstrapping and
certificate enrollment."


2. Chapter 3.5 (Deployment limits):
2a. " Although EST-coaps paves the way for the utilization of EST for
constrained devices on constrained networks..."
--> s?on?and/or?

2b. " EST-coaps is intended to ensure that EST works for networks of
constrained devices that choose to limit their communications stack to
UDP/CoAP."
--> Remove "networks of"

-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Shahid Raza
Sent: Thursday, February 01, 2018 11:56 AM
To: Sandeep Kumar 
Cc: Jim Schaad ; ace@ietf.org
Subject: Re: [Ace] Working group adoption of draft-vanderstok-ace-est

As a co-author, I also strongly support the adoption of this draft as
a WG document. Recall that , we already have an implementation of this
draft, both in constrained devices (SICS Contiki) and in the Nexus CA
software. Recently, we have also implemented the "integration of this
draft into LwM2M", which is part of the latest LwM2M release.

Best,
Shahid

Shahid Raza, PhD
Director Security Lab and Expert Researcher
RISE - Research Institutes of Sweden
Division ICT - RISE SICS

Isafjordsgatan 22 / Kistagången 16
16440, Kista Stockholm
Mobile: +46 768831797
shahid.r...@ri.se
http://www.shahidraza.net
http://www.sics.se
The RISE institutes Innventia, SP and Swedish ICT have merged in order
to become a stronger research and innovation partner for businesses
and society.


On 1 Feb 2018, at 11:40, Sandeep Kumar  
wrote:


As co-author, I support adoption of the draft as WG document. There is
need in industry and multiple standardization bodies for this draft.

Regards
Sandeep

-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Jim Schaad
Sent: Tuesday, January 30, 2018 9:23 PM
To: ace@ietf.org
Subject: [Ace] Working group adoption of draft-vanderstok-ace-est

This is the start of a two week call for input on the adoption of the
WG of the document draft-vanderstok-ace-est.  The document has been
presented at the last two meetings and has some significant recent
updates to respond to feedback.  There seemed to be support at the
last F2F to adopt.

Please provide feedback to the list/chairs if you believe that this 
document
should be adopted as a WG document.The adoption call will end on 
Feb 13

2018.

Jim


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


The information contained in this email may be confidential and/or
legally protected under applicable law. The message is intended solely
for the addressee(s). If you are not the intended recipient, you are
hereby notified that any use, forwarding, dissemination, or
reproduction of this email is strictly prohibited and may be unlawful.
If you are not the intended recipient, please contact the sender by
return e-mail and destroy all copies of the original email.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace