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 payload be changed to "pure" ASN.1 payload for the media
> types that are non-multipart?
> I agree with Jim that the CBOR wrapping in this case is not needed (since the
> CoAP Content-Format / media type id will tell the receiver how it is encoded
> anyhow). Also it seems harmful in this case, since an existing CoAP media
> type-plus-encoding is "overloaded" with a second encoding if we allow the
> CBOR-wrapping. Doing this would require registering a new value in the CoAP
> Content-Formats registry, e.g. like "application/csrattrs+cbor" and then it
> would be ok.
>
> I'm asking this because in implementations we now use the CBOR-wrapping and
> if we don't make the change now it will stay that way most likely. And the
> present "EDnote" in the text is not so clear on what will happen.
>
> Best regards
> Esko Dijk
>
> -----Original Message-----
> From: Ace <[email protected]> On Behalf Of Panos Kampanakis (pkampana)
> Sent: Monday, September 17, 2018 18:56
> To: Jim Schaad <[email protected]>; [email protected]
> Cc: 'ace' <[email protected]>
> Subject: Re: [Ace] Review draft-ietf-ace-coap-est
>
> Hi Jim,
> We have now addressed all the issues you brought up in July. The fixes will
> be in the last iteration.
> We will still make some cosmetic updates and post a new version.
> Thank you for the thorough review.
> Rgs,
> Panos
>
> -----Original Message-----
> From: Ace [mailto:[email protected]] On Behalf Of Jim Schaad
> Sent: Sunday, July 01, 2018 9:34 AM
> To: [email protected]
> Cc: 'ace' <[email protected]>
> Subject: [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 be doing a
> CBOR bstr wrapping on the ASN.1 encoding payload. I don't believe that there
> is any reason for doing this. I would expect that the payload would be the
> ASN.1 w/o any ASN.1. It is highly possible that I am just mis-reading what
> the text says and this is what you say.
>
> * In section 5.0 - As written, the example of doing a query against
> /.well-known/core does not match my understanding of what would be return.
> It should only return those resources which have the rt field set on them.
> I do not understand why you believe that the following lines MAY be returned.
> Clarification of why you think this is true would be appreciated.
>
> * Section 6 - Is there a need to have all of this description around
> TLS-unique? Do you have a reason to believe that people are going get this
> implemented wrong?
>
> * Section 7 - I think the figure has an error associated w/ it. The CA
> should be tied to the EST Server and not to the Registrar
>
> * Section 7 - Your language is a bit sloppy around the terms of POP and POP
> linking. Unless it is really badly behaved, POP should never be broken by an
> RA. The POP is the signature on the request and not tied to the TLS channel.
> The POP linking is tied to the TLS channel and is broken by the changing of
> the TLS sessions (client <-> RA, RA <-> CA)
>
> * Section 7 - It is not clear to me that the SHOULD on reassembly of
> fragmentation is not a MUST. I doubt that any EST server is going to be able
> to deal with getting fragments of requests from a registrar in separate
> messages. This would be compounded if the proxy is handling multiple
> sessions at the same time.
>
> * Section 7 - It should be possible that when doing key generation for the
> protection of the private key to be end-to-end and it should not be necessary
> for the Proxy to decrypt and then re-encrypt the private key. It should not
> matter for this if one does either symmetric or asymmetric encryption of the
> private key.
>
> * Section 7 - It is very possible that the private key generation function
> would be hosted on the proxy and not at the CA. I think that you might want
> to describe this as a normal configuration. (Just spotted this in the
> Security considerations. I think it should be here as well.)
>
> * Section 9.1 - application/multipart-core should not be in the table of
> items for IANA to register. This is being done in a different document. If
> you want this table as a whole then it needs to be moved out of IANA
> considerations.
>
> * Section 9.2 - please expand this text some. You might want to look at
> https://tools.ietf.org/html/rfc7390#section-6.1 for a template.
>
> Jim
>
> _______________________________________________
> Ace mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ace
>
> _______________________________________________
> Ace mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
