Re: [Ace] EST over CoAP in ACE wg

Hi Michael, As such, what we would really like is an EST-like mechanism which runs over OSCOAP with EDHOC keying. Ideally, it would also permit the process to be managed/initiated from the new device (the pledge), or from the JCE (Registrar, which might also be the AS in ACE terminology).

[Ace] Fwd: New Version Notification for draft-vanderstok-ace-coap-est-00.txt

, draft-vanderstok-ace-coap-est-00.txt has been successfully submitted by Peter van der Stok and posted to the IETF repository. Name: draft-vanderstok-ace-coap-est Revision: 00 Title: EST based on DTLS secured CoAP (EST-coaps) Document date: 2016-12-07 Group

Re: [Ace] EST over CoAP PKCS#10 encoding

HI Julien, Julien Vermillard schreef op 2017-03-30 09:08: Hi, I'm currently implementing EST over CoAP. Great, that is good news. I wonder why, on simple enrollment, the payload is put in a CBOR binary string? I understand why dropping base64, but just putting the PKCS#10 binary in the

Re: [Ace] EST over CoAP PKCS#10 encoding

. And would also match the HTTP way to do it. -- Julien Vermillard On Thu, Mar 30, 2017 at 4:16 PM, peter van der Stok <stokc...@xs4all.nl> wrote: HI Julien, Julien Vermillard schreef op 2017-03-30 09:08: Hi, I'm currently implementing EST over CoAP. Great, that is good news. I wonder why, on

[Ace] Fwd: New Version Notification for draft-vanderstok-ace-coap-est-01.txt

Hi Ace, This is a new version based on improved insight and comments we received since presentation of the problem during the Seoul ACE meeting. Looking forward to your comments, Peter A new version of I-D, draft-vanderstok-ace-coap-est-01.txt has been successfully submitted by Peter van

[Ace] Fwd: New Version Notification for draft-vanderstok-ace-coap-est-02.txt

Datum: 2017-06-12 12:35 Afzender: internet-dra...@ietf.org Ontvanger: "Panos Kampanakis" <pkamp...@cisco.com>, "Sandeep S. Kumar" <i...@sandeep.de>, "Sandeep Kumar" <i...@sandeep.de>, "Peter Van der Stok" <consulta...@vanderstok.org&

Re: [Ace] Early warning: Rewrite of vanderstok-ace-coap-est

Hi Hannes, thanks for the early warning. Looking forward to reading your version. Let's see afterwards how we continue ( one document or two complementary documents) cheerio, peter Hannes Tschofenig schreef op 2017-11-13 03:55: Hi all, I had provided comments on the EST over CoAP document

Re: [Ace] some thoughts about vanderstok-ace-coap-est

Hi Michael, See below. Michael Richardson schreef op 2017-11-10 19:41: {In some ways this should be a discussion among the authors of which I am now one, but I feel that the discussion belongs in public} 1) discovery. Section 4.1 provides for the process to start with a discovery

Re: [Ace] some thoughts about vanderstok-ace-coap-est

Michael Richardson schreef op 2017-11-13 03:32: Michael Richardson wrote: > Section 4.1 provides for the process to start with a discovery > operation. ... > REQ: GET /.well-known/core?rt=ace.est > I can see the architectural reasons for why we do

Re: [Ace] [core] Early media-type registration for EST over CoAP

Ok, I will raise the experts to-morrow. Peter Carsten Bormann schreef op 2018-05-24 16:37: On May 24, 2018, at 16:15, Hannes Tschofenig wrote: Hi all, Trying to finalize this discussion: Could we do an early registry of the Content-Format numbers? Yes. From

Re: [Ace] [core] New Version of draft-fossati-core-multipart-ct-04.txt

Hi Carsten et al. I have looked at the multipart draft, and I am happy to see that the CBOR array is maintained as proposed in est-coaps. So now we have two drafts that both propose an almost identical new media type. The choice will be determined by the delay needed to (pre-)register the new

[Ace] Fwd: New Version Notification for draft-vanderstok-ace-coap-est-04.txt

Hi Ace, WG-chairs, This new version of coap-est takes into account the remarks made by Hannes; thanks Hannes. This version looks appropriate for acceptance by the WG. Greetings, peter A new version of I-D, draft-vanderstok-ace-coap-est-04.txt has been successfully submitted by Peter van

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

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,

Re: [Ace] draft-vanderstok-ace-coap-est-03

Hi Hannes, Happy new year. Many thanks for your comments; See below for my "late" reactions Would it make sense to expand the title of the draft to something like "Using Enrollment over Secure Transport (EST) over the Constrained Application Protocol (CoAP)" Thanks for the suggestion;

Re: [Ace] Review draft-ietf-ace-coap-est

Hi Jim, Many thanks for the review. See our answers below. * In section 4.1 I have a question about what you are using for payload content encoding. Part of this might just be a question of how you plan to move from ASN.1 to CBOR at some point in the future. I think that it would necessitate

Re: [Ace] Review draft-ietf-ace-coap-est

> * In section 4.1 I have a question about what you are using for payload > content encoding. Part of this might just be a question of how you plan to > move from ASN.1 to CBOR at some point in the future. I think that it would > necessitate doing new media-types in that event. You appear to

Re: [Ace] draft-ietf-ace-coap-est-00

Hi Jim, thanks for the comments. See my reactions below. Jim Schaad schreef op 2018-03-10 22:15: I agree with Hannes, this version of the document is much cleaner and much clearer. I think that it has solved most of the problems that I initially had with the draft. It is not ready to

Re: [Ace] draft-ietf-ace-coap-est-00

>> * Should probably add a note in section 6 that any proxy that terminates >> the >> DTLS connection is going to be required to act as an RA. RAs are required >> to have the entire request for adding authentication as necessary. > This is visible in the figure of

Re: [Ace] draft-ietf-ace-coap-est-00

Michael Richardson schreef op 2018-03-15 09:00: peter van der Stok <stokc...@xs4all.nl> wrote: >> >> DTLS connection is going to be required to act as an RA. RAs >> are required >> >> to have the entire request for

Re: [Ace] Agenda Items for London

Hi Jim, I like to have 10 mins the present the additions to be done to ietf-ace-coap-est-00. and additionally explain the ongoing relation with other drafts. Peter Jim Schaad schreef op 2018-02-28 01:33: Please let the chairs know if you want a slot on the agenda for London. Please give us

Re: [Ace] Fwd: review of palombini-ace-key-groupcomm

HI FP, Answering below. section 1.1 does not mention groupcomm draft for the terms: group identifier and role identifier. group identifier is described in groupcomm document role identifier is not; hence difficult to know what to do in the implementation Francesca Palombini schreef op 2018-10-29

[Ace] review oscore-groupcomm-2

rage of messages at the sender (how many?), and possibly re-encrypting to guarantee freshness when they are repeated on loss detection. Hope this helps. Greetings, peter -- Peter van der Stok vanderstok consultancy mailto: consulta...@vanderstok.org, stokc...@bbhmail.nl www: www.vanderstok.org

Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI

Hi, What do I read? when you do GET coap://example.com/.well-known/core The discovery is on port 5683. When you do GET coaps://example.com/.well-known/core the discovery port is 5684. I agree that we did not assign a port to coaps://example.com/est for that matter, and as such the example is

Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI

Michael Richardson schreef op 2018-09-20 16:51: > I didn't think that CoAP resource discovery supports port numbers, does it? > > It does; at least for the 3rd party registration, but also examples in the RD > show return of port___ Ace mailing list

Re: [Ace] Call for adoption of draft-tiloca-ace-oscoap-joining

I support the adoption of this draft. It is fulfils our group commuication requirements. Peter Roman Danyliw schreef op 2018-11-30 22:58: > Hello! > > This is the start of a two week call for input on the WG adoption of the > document: > > draft-tiloca-ace-oscoap-joining >

Re: [Ace] Call for adoption of draft-palombini-ace-key-groupcomm

I support the adoption of this draft. It is the right solution to our secure group communication wishes. Peter Roman Danyliw schreef op 2018-11-30 22:58: > Hello! > > This is the start of a two week call for input on the WG adoption of the > document: > > draft-palombini-ace-key-groupcomm >

Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI

Hi esko, we can add a reference to sections 3.1 and 3.2.2. of RFC7030 Peter Panos Kampanakis (pkampana) schreef op 2018-09-12 17:31: > Hi Esko, > > Thanks for the comment.. > > Certificate authorities use the ArbitraryLabel in order to direct the CSR > request and issue certificates based

Re: [Ace] Review draft-ietf-ace-coap-est / Removal of CBOR-wrapped ASN.1 ?

Hi esko, apologies for being unclear. The CBOR wrapping is removed. It is only present for response of server key generation /skg Peter Esko Dijk schreef op 2018-12-19 13:32: > Dear Panos & Peter, > > On Jim's first point for section 4.1 below (content encoding) - will the > CBOR-wrapped

Re: [Ace] Embedded Content Types

Hi, For me the est-coaps solution with different URIs is a good one. as suggested by Carsten, /skg/ctnumbers seems straightforward. In the return of /.well-known/core, the CT hints will help. No need to define multiple content-format combinations. Peter Jim Schaad schreef op 2019-02-20 18:58:

Re: [Ace] Shepard comments draft-ietf-ace-coap-est-08

Hi Jim, thanks for the review. see below. Peter Jim Schaad schreef op 2019-02-16 20:55: > 1. In section 10.1 the last sentence of the first paragraph and the first > sentence of the last paragraph duplicate each other. This should be cleaned > up. > > removed the 2nd instance > > 2.

Re: [Ace] ace-coap-est-08: using /skg with Accept Option set to TBD287

HI all, I have seen at least two viable solutions to the content-format associated with draft-ietf-core-multipart-ct. Probably, there are more possibiities. Of course est-coaps can take over any of those solutions, but it then remains a local est-coaps solution. IMO the problem is more general.

[Ace] preliminary registration of content-format

]] | +--+--++ We suggest the number 287 consecutive to the earlier preliminary content-format assignments. Many thanks, peter -- Peter van der Stok vanderstok consultancy mailto: consulta...@vanderstok.org, stokc...@bbhmail.nl www: www.vanderstok.org [2

Re: [Ace] Keeping the same key identifier for groups

Example: If you have a CWT authorizing A for audience Z and you now also need authorization B for audience Z, you should request a CWT for A+B for audience Z, that replaces your previous one. Do I understand? two possibilities: A and B are members of audience Z; no new CWT needed B is a new

Re: [Ace] AD review of draft-ietf-ace-coap-est-12

HI Jim and Ben, Ben, many thanks for a nice and elaborate review of the draft. beginning next week I will provide partial answers to the review. Some small remarks below to the much appreciated explanations by Jim. An initial answer to the first point precedes the answers by Jim. cheerio,

Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

Hi Ben, the last part of the responses to your thorough review. Apart from nits you found some "nice" mistakes. the openssl example make me worry a bit. See below. Peter ___ When requesting server-side key generation, the

Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

I concluded on the pruned . Peter Jim Schaad schreef op 2019-09-03 20:48: > I have pruned and tossed in a few [JLS] comments. > > Jim > > FROM: Peter van der Stok > SENT: Tuesday, September 3, 2019 5:18 AM > TO: Benjamin Kaduk > CC: Jim Schaad ; > draft-iet

[Ace] Fwd: I-D Action: draft-ietf-ace-coap-est-13.txt

Environments WG of the IETF. Title : EST over secure CoAP (EST-coaps) Authors : Peter van der Stok Panos Kampanakis Michael C. Richardson Shahid Raza Filename: draft-ietf-ace-coap-est-13

Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

ECPrivate Key [RFC 5915] > > INTEGER 1 - Version - ecPrivkeyVer1 > > OCTET STRING (32 byte) > 0B9A67785B65E07360B6D28CFC1D3F3925C0755799DEECA745372B01697BD8A6 - Private > Key value > > [1] (1 elem) - Public key value > > BIT STRING (520 bit) > 01000001101110111000110100010001000010

Re: [Ace] AD review of draft-ietf-ace-coap-est-12

Hi all, below are comments to a subset of not yet concluded review exchanges. Peter ___ The serverkeygen endpoints could perhaps have some notation to indicate that the private key is always returned, in addition to the PKCS#7 vs. pkix-cert

[Ace] ace-key-groupcomm-03

place and new material needs to be fetched. However, is there enough information to know which KDC handles the rekeyed group? The ContextId is unknown, and the receiverId may refer to multiple contexts, while it is not guaranteed that each group has its own resource on the member platform. Greetings,

[Ace] ace-key-groupcomm-oscore-03

cs_key_enc. Hope this helps, Thanks for all your work, greetings, Peter -- Peter van der Stok vanderstok consultancy mailto: consulta...@vanderstok.org, stokc...@bbhmail.nl www: www.vanderstok.org [1] tel NL: +31(0)492474673 F: +33(0)966015248 Links: -

Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)

HI all, We had this discussion about this specific text several times. I like to keep at least some text for the following reason: Implementers, new to coap without a photographic memory of RFC7252 text, are surprised by the absence of uri host in the examples, and tend to assume an error. The

Re: [Ace] draft-ietf-ace-oauth-authz

already been established for AS initialization. Many thanks, peter Jim Schaad schreef op 2020-04-30 17:25: What do you expect to see? By default a client needs to know that something is an AS and have a key to interact with that AS. Jim From: Ace On Behalf Of Peter van der Stok Sent

Re: [Ace] draft-ietf-ace-oauth-authz

Hi Carsten, The imagination will not have finished its work in 10 yeras time if coap and the authorization will enjoy the success they merit. Also I don't see anybody being ready to start such a document the coming month. Do you see another document in which a first set of these registrations

Re: [Ace] draft-ietf-ace-oauth-authz

:06AM +0200, Olaf Bergmann wrote: Hi Peter, Peter van der Stok writes: When I want to access an OCF device I can find its IP address through service discovery (rfc7252 section 7) using an rt-value registered at the IANA core parameters registry. For example, when I want to initialize the AS I have

[Ace] draft-ietf-ace-oauth-authz

Hi authz authors,, While implementing a version of AS, I noticed that there is no resource type (rt) registered for /.well-known/core discovery. Is this voluntary? If not, can it still be added? thanks, peter -- Peter van der Stok vanderstok consultancy mailto: consulta...@vanderstok.org

Re: [Ace] draft-ietf-ace-oauth-authz

. It would make more sense to define a new interface identifier for the upload/control protocol rather than just identifying who is an AS. Jim From: Ace On Behalf Of Peter van der Stok Sent: Tuesday, May 5, 2020 12:26 AM To: Benjamin Kaduk Cc: Jim Schaad ; Olaf Bergmann ; 'Ace' Subject: Re

Re: [Ace] Progressing draft-ietf-ace-oauth-authz

HI, "My proposed fix for this would be to amend the descriptions of these two parameters in 5.9.2, specifying that their JSON representation is a text string containing the Base64url encoding of the original byte string payload." exactly the same fix we did for json and cbor voucher-request