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

[Michael Richardson]

Jim Schaad  wrote:
> That sounds like a good plan forward. Are you also going to need an early
> registration on the multipart-core draft as well?

yes, it would be nice, ... we think that it's CORE's problem to adopt the
draft and ask for that.

The multipart response is only need for systems where the private key will be
generated on the EST server: and a number of implementers are keen *not* to
do that, so the multipart is not urgent to as many people.


> From: Peter van der Stok 
> Sent: Wednesday, June 20, 2018 3:07 AM
> To: Carsten Bormann 
> Cc: Hannes Tschofenig ; core ;
> ace@ietf.org; Jim Schaad ; r...@cert.org
> Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP

> 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 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 to the ACE chairs.
> Although the corresponding media formats have not been allocated yet for
> multipart-ct draft, the corresponding content-format numbers can be 
allocated
> already.

> Is that the approved plan?

> Please confirm or specify the conditions on multipart-ct draft.

> Many thanks for your understanding,

> Peter

> Carsten Bormann schreef op 2018-06-19 14:22:

> On Jun 19, 2018, at 14:11, Carsten Bormann  wrote:


> Since the registry that we are registering into does not fulfill the
> preconditions of RFC 7120 Section 2 point (a),




> (Sorry, wasn't awake enough. If we go for the 256- space, of course
> it does. And we probably do.)

> So we'll have to follow the process according to Section 3 of RFC 7120.

> Starting with point (1) of Section 3.1:

> 1. The authors (editors) of the document submit a request for early
> allocation to the Working Group chairs, specifying which code
> points require early allocation and to which document they should
> be assigned.

> Grüße, Carsten

> ___
> core mailing list
> c...@ietf.org
> https://www.ietf.org/mailman/listinfo/core




> 
> Alternatives:

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

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Jim Schaad]

That sounds like a good plan forward.  Are you also going to need an early 
registration on the multipart-core draft as well?

 

Jim

 

 

From: Peter van der Stok  
Sent: Wednesday, June 20, 2018 3:07 AM
To: Carsten Bormann 
Cc: Hannes Tschofenig ; core ; 
ace@ietf.org; Jim Schaad ; r...@cert.org
Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP

 

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 
  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 to the ACE chairs.
Although the corresponding media formats have not been allocated yet for 
multipart-ct draft, the corresponding content-format numbers can be allocated 
already.

Is that the approved plan?

Please confirm or specify the conditions on multipart-ct draft.

Many thanks for your understanding,

Peter

Carsten Bormann schreef op 2018-06-19 14:22:

On Jun 19, 2018, at 14:11, Carsten Bormann mailto:c...@tzi.org> 
> wrote: 


Since the registry that we are registering into does not fulfill the 
preconditions of RFC 7120 Section 2 point (a),


(Sorry, wasn't awake enough.  If we go for the 256- space, of course it 
does.  And we probably do.)

So we'll have to follow the process according to Section 3 of RFC 7120.

Starting with point (1) of Section 3.1:

   1.  The authors (editors) of the document submit a request for early
   allocation to the Working Group chairs, specifying which code
   points require early allocation and to which document they should
   be assigned.

Grüße, Carsten

___
core mailing list
c...@ietf.org  
https://www.ietf.org/mailman/listinfo/core

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

Re: [Ace] CWT-PoP & Multiple PoP keys

[Mike Jones]

Good.  Having resolved this, I believe we should be in position to do a release 
addressing the WGLC comments this week.

-- Mike

-Original Message-
From: Ace  On Behalf Of Ludwig Seitz
Sent: Wednesday, June 20, 2018 12:14 AM
To: ace@ietf.org
Subject: Re: [Ace] CWT-PoP & Multiple PoP keys

On 2018-06-20 08:57, Hannes Tschofenig wrote:
> Hi Jim,
> 
> I had a chat with Mike about relaxing the CWT-PoP spec to allow 
> multiple PoP keys in a single CWT token.
> 
> He is concerned about the departure from RFC 7800 and, after giving it 
> a bit more thoughts, I believe there is an issue. Initially, when we 
> started the work our promise was that this is really just an 
> alternative encoding of RFC 7800. With changes like those we are 
> obviously breaking that concept. Having multiple keys within a single 
> CWT is a corner case and I am not sure anymore whether I indeed want 
> to go into that direction. In our implementation we are also not using 
> multiple keys in a single CWT either.
> 
> Ciao
> 
> Hannes
>

I agree that having multiple PoP keys in cnf for CWT-PoP seem like overkill. 
After all this is a draft aimed at constrained environments.
I also sympathize with Mike's suggestion to keep CWT-PoP aligned with RFC 7800.

/Ludwig


> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended

Sending confidential email to a public mailing list again Hannes? You are a 
rebel ;-)


-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

___
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] CWT-PoP & Multiple PoP keys

[Ludwig Seitz]

On 2018-06-20 08:57, Hannes Tschofenig wrote:

Hi Jim,

I had a chat with Mike about relaxing the CWT-PoP spec to allow multiple 
PoP keys in a single CWT token.


He is concerned about the departure from RFC 7800 and, after giving it a 
bit more thoughts, I believe there is an issue. Initially, when we 
started the work our promise was that this is really just an alternative 
encoding of RFC 7800. With changes like those we are obviously breaking 
that concept. Having multiple keys within a single CWT is a corner case 
and I am not sure anymore whether I indeed want to go into that 
direction. In our implementation we are also not using multiple keys in 
a single CWT either.


Ciao

Hannes



I agree that having multiple PoP keys in cnf for CWT-PoP seem like 
overkill. After all this is a draft aimed at constrained environments.
I also sympathize with Mike's suggestion to keep CWT-PoP aligned with 
RFC 7800.


/Ludwig


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended 


Sending confidential email to a public mailing list again Hannes? You 
are a rebel ;-)



--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

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

[Ace] CWT-PoP & Multiple PoP keys

[Hannes Tschofenig]

Hi Jim,

I had a chat with Mike about relaxing the CWT-PoP spec to allow multiple PoP 
keys in a single CWT token.

He is concerned about the departure from RFC 7800 and, after giving it a bit 
more thoughts, I believe there is an issue. Initially, when we started the work 
our promise was that this is really just an alternative encoding of RFC 7800. 
With changes like those we are obviously breaking that concept. Having multiple 
keys within a single CWT is a corner case and I am not sure anymore whether I 
indeed want to go into that direction. In our implementation we are also not 
using multiple keys in a single CWT either.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace