Accept and CF values for multipart response (Esko - Klaus WGLC review 2/12/2019)

[csosto-pk]

By Esko

Dear authors & WG,

A question on the new -08 text regarding the /skg response: the text indicates the following request & response

Client: POST /.well-known/est/skg Accept: TBD287 Content-Format: 286

Server: 2.04 Content-Format: 62

So the client asks for 286, but gets 62 (which has 286 embedded in it as one of the parts). At first sight this appears incompatible with CoAP RFC7252 logic. A strict server implementation might return 4.06 Not Acceptable since the server code has registered the response type to be 62; and the client asks something different.

Maybe the draft-ietf-core-multipart-ct should extend the semantics of “Accept” to cover this case?

(Or would we rather fall back to returning PKCS#7 always, within the multipart content. It would be possible to define a /skg2 URI that returns the other multipart format. Or we could even define a new content format TBD which encodes a multipart type including a TBD287, so the client can use the Accept Option as normal to request the wanted multipart type.)

[csosto-pk]

By Klaus

RFC 7252 is quite strict about this:

If the preferred Content- Format cannot be returned, then a 4.06 "Not Acceptable" MUST be sent as a response, unless another error code takes precedence for this response.

That's a MUST, not a SHOULD.

Since a client might actually support multiple formats, it might make sense to indicate all supported formats in order of preference e.g. as query parameters:

Client: POST /.well-known/est/skg?ct=TBD287&ct=281 Accept: 62 ...

Server: 2.04 Content-Format: 62 Payload: (multipart containing TBD287)

[mcr]

Panos K. notifications@github.com wrote:

So the client asks for 286, but gets 62 (which has 286 embedded in it as one of the parts). At first sight this appears incompatible with CoAP RFC7252 logic. A strict server implementation might return 4.06 Not Acceptable since the server code has registered the response type to be 62; and the client asks something different.

Maybe the draft-ietf-core-multipart-ct should extend the semantics of “Accept” to cover this case?

Ick. That's annoying and needs to come to the list, and go to the CORE WG too. Maybe we need to Accept 62. I'm not sure here.

-- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [

[csosto-pk]

Klaus H.'s suggestion was to have the client use Uri-Query to tell the server what formats he supports in the multipart response.. Something like

POST /.well-known/est/skg?ct=TBD287&ct=281 Accept: 62

This looks like a decent option. If we chose to go that route we need to update paragraph 3 of the server-side keygen section 5.8 to explain how the client signals his preference. Also what if the server does not support the format asked? Also update Section A.4 to fix the Accept Option and the CF option in the format.

[mcr]

Panos K. notifications@github.com wrote:

Klaus H. suggestion was to have the client use Uri-Query to tell the server what formats he supports in the multipart response.. Something like

POST /.well-known/est/skg?ct=TBD287&ct=281 Accept: 62

This looks like a decent option. If we chose to go that route we need

Can we bring this up in CORE for review?

[petervanderstok]

I am more in favor of the text proposed by Klaus and extended by Jim.

Michael Richardson schreef op 2019-02-13 22:16:

Panos K. notifications@github.com wrote:

Klaus H. suggestion was to have the client use Uri-Query to tell the server what formats he supports in the multipart response.. Something like

POST /.well-known/est/skg?ct=TBD287&ct=281 Accept: 62

This looks like a decent option. If we chose to go that route we need

Can we bring this up in CORE for review?

-- You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub [1], or mute the thread [2].

Links:

[1] https://github.com/SanKumar2015/EST-coaps/issues/121#issuecomment-463374690 [2] https://github.com/notifications/unsubscribe-auth/AMWTQfVq6xVXWj3C7EtqisjGK0CQZLeOks5vNICYgaJpZM4a4DYr

[csosto-pk]

Jim will bring this discussion up in the next CoRE interim meeting.. Will wait for this discussion to converge.

[mcr]

draft-ietf-core-multipart-ct needs to resolve, and we can progress without resolution of this, and we'll just stall is MISREF on it anyway.

[csosto-pk]

Options so far

1. four new content format IDs for the dual format combinations
2. using queries with ct to signal to the server the requested format.
3. different URIs for key and cert.
4. include more than one values in the Accept option and get back a content format ID of 62, which violates RFC7252.

Will wait for CORE to clarify.

[csosto-pk]

From CORE discussions 4 is not allowed. Accept can only be 62. 1 was not liked because of scaling. 2 was OK, but is slightly awkward for CORE. 3 has a lot of challenges for CAs that would need to keep track of key and cert. And the client would need to signal the key/cert he is expecting.

Thinking that one type of supported certs.

[csosto-pk]

The proposal from Jim was to support two URIs

• /skg that requests for PKCS#7 composite. The priv key CF is requested by the client.
• /skgsc that requests simple cert composite. The priv key CF is requested by the client.

The client knows what the server supports from discovery if he sees /skg or /skgsc. The client does not know if the server supports just PKCS#8 or encrypted private key as well. But he signals what he want in the CSR.

Need to update the draft.

[mcr]

okay. But, how about /skg and /skp or some other TLA.

[csosto-pk]

okay. But, how about /skg and /skp or some other TLA.

That works. I used

• /skg (secret key gen with PKCS#7 in the response)
• /skc (from secret key & an cert with pkix-cert in the response)

I updated all the relevant sections of the draft. Closing.