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
. 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'
: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
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
ca
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
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
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 c
It is probably enough to add to the text of est-coaps:
(see section 5.10.1 of RFC7252)
Peter
Carsten Bormann schreef op 2019-12-20 08:06:
On Dec 20, 2019, at 01:47, Benjamin Kaduk wrote:
The statement above
When omitted, they are logically
assumed to be the transport protocol destination add
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:
-
ying took 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.
ained 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-e
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 qu
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
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
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 c
Hi Ben,
Below some additional reactions to your review.
In some parts the term "suggest" is used, meaning that I am not sure of
the correctness of my reaction.
A confirmation/denial would be appreciated in those cases.
My co-authors can always improve my changes.
To-morrow I hope to do the follow
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,
Pet
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 member
Hi co-authors of groupcomm-oscore,
It is not clear how valid groups are created and stored by the group
manager.
Is the request by a client to join a non-existing group honored by
creating the specified group?
If not, will there be additional group creation commands?
Peter
--
Peter van der Stok
HI ACE co-chairs,
It might be good the pressent the WGLC results for draft est-coaps,
thanks,
peter
Jim Schaad schreef op 2019-03-11 23:24:
> Call Number 2 for agenda items. If you don't ask you will not be on the
> agenda.
>
> Jim
>
>> -Original Message-
>> From: Ace On Behalf Of R
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:
>
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. Correc
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.
I
]]
|
+--+--++
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
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 ASN.1
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
> https://tools.ietf.o
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
> ht
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 1
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 inco
Sorry folks,
But you confuse me.
discovery is about /.well-known/core.
I don't understand where /.well-known/est comes in for discovery.
Peter.
Esko Dijk schreef op 2018-09-21 10:24:
>> I've asked if discovery is always required, permitted, or encouraged.
>
> Normally it is always encouraged to
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
Ac
ut this involves storage 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:
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 o
ure with request before section 7.1
scope: same comment on group identifier and topic.
_____________
Hope this helps,
greetings,
Peter
--
Peter van der Stok
vanderstok consultancy
mailto: consulta...@vanderstok.org, stokc...@bbhmail.nl
www: www.vand
> * 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
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 d
HI Jim,
I like 10-15 mins to discuss est-coaps,
- discuss delayed response,
- open points,
Peter
Jim Schaad schreef op 2018-06-25 13:35:
> If you want a spot on the agenda please let the chairs know.
>
> Please include topic/draft, presenter and a time request.
>
> Jim
>
> ___
HI Carsten, Jim
Just to get this clear.
We will update the the est-coaps draft by referring to
draft-fossati-core-multipart-ct-05 [1] for the wanted early registration
of the content formats specified in est-coaps.
Once done, we direct a request for early registration of the
content-format values
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 med
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 the discussion so far I belie
s specification" suggest to
move this phrase to section 6.
section 6. I suggest to add the reference to oscore-groupcomm when
referring to the (sections) or (appendix).
Hope this helps,
Peter
--
Peter van der Stok
vanderstok consultancy
mailto: consulta...@vanderstok.org
www: www.vandersto
Michael Richardson schreef op 2018-03-15 09:00:
peter van der Stok wrote:
>> >> 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.
>>
&
>> * 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 sectio
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 progress
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
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, jus
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
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; Possib
Hi all,
A new version of I-D, draft-vanderstok-ace-coap-est-03.txt
has been successfully submitted by Peter van der Stok and posted to the
IETF repository.
This version has no reference to BRSKI and is stand-alone EST over CoAP.
Other comments from the WG have been taken into account.
According
I'm slowly absorbing the contents of draft-vanderstok-ace-coap-est-02.
I'm building draft-ietf-6tisch-zerotouch-join with the assumption that
it
might run over DTLS, use EDHOC w/OSCORE, or some DTLS-over-CoAP
mechanism.
Good
I looked through section 6, and I don't understand why COAPS woul
Hi,
Jim suggests to keep both the /.well-known/est/* entry-points and the
optional short ones.
Seems the right approach to me and gives the application the opportunity
to shorten the request URIs.
Michael Richardson schreef op 2017-11-14 03:57:
Carsten Bormann wrote:
>> I'm less convin
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 that, but I
really
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
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
operation.
Hi Goran and Hannes,
Thanks Hannes, for starting the discussion.
I am glad to contribute to this discussion, as one of the more
interested parties, co-author of est-coaps.
Looking at the charter of ACE, the following sentences seemed of
interest to me.
"As a starting point, the working
group
Datum: 2017-06-12 12:35
Afzender: internet-dra...@ietf.org
Ontvanger: "Panos Kampanakis" , "Sandeep S. Kumar"
, "Sandeep Kumar" , "Peter Van der
Stok" , "Peter van der Stok"
, "Martin Furuhed"
, "Shahid Raza"
A new vers
would also match the HTTP way to do it.
--
Julien Vermillard
On Thu, Mar 30, 2017 at 4:16 PM, peter van der Stok
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 simple enrollment
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 CoA
Hi Michael,
thanks for this extended explanation. This really helps to understand
the final goals and motivation.
A few questions below to remove my remaining confusion.
Michael Richardson schreef op 2017-03-20 22:57:
Some background:
There are two of them because there is some concern tha
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
After reading Jim's statement, my position is a bit different.
Multicast security is severely needed.
Not making it a WG document augments the risk that the subject is frozen
and no progress is made.
To guarantee progress, adoption seems to me the right way forward.
Peter
Jim Schaad schreef op
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).
, 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
63 matches
Mail list logo
