Subject: [Ace] Shepard comments on draft-ietf-ace-oscore-profile

From: Jim Schaad <[email-masked]>
Date: Wed, 30 Jan 2019 16:34:21 -0800

1.  Please update the text for MUST/SHOULD/MAY to include the language from
RFC 8174.

2.  Section 3.2.1 - What to do is clear if a field is not missing.  What is
the correct behavior if a field is present that the client and/or resource
server does not recognize.  Is this a fatal error or is it sufficient that
they may not behave the same?

Jim

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 31 Jan 2019 07:35:59 +0100

> 1.  Please update the text for MUST/SHOULD/MAY to include the language from

(Public service announcement:
If you use kramdown-rfc, just say

{::boilerplate bcp14}

and that is taken care of, including the all the references needed.)

Grüße, Carsten

---

From: Francesca Palombini <[email-masked]>
Date: Thu, 31 Jan 2019 14:26:07 +0000

Hi Jim,

Inline.

Thanks,
Francesca

On 31/01/2019, 01:34, "Jim Schaad" <[email-masked]> wrote:

FP: Right, thanks. Updated now in the github.

FP: Assuming you are referring to fields missing in the OSCORE_Security_Context, (please correct me otherwise) this is a good point. We currently do not define what happens if the security context has unrecognized parameters. We don't foresee this happening, as the AS should know what the client and RS implement. However, to cover this case (bad implementation or something went wrong), to be on the safe side, we propose that there is a fatal error in that case. In fact, we don't know what additional parameters might be registered in the OSCORE_Security_Context, and although they could be "risk-free" (as in optional additional information non-necessary for the security context derivation), they could also be input to the key derivation for example, in which case the endpoint non-recognizing them would end up storing a "wrong" security context. What do you think?
    
    Jim

---

From: Jim Schaad <[email-masked]>
Date: Thu, 31 Jan 2019 08:45:48 -0800

> -----Original Message-----
> From: Francesca Palombini <[email-masked]>
> Sent: Thursday, January 31, 2019 6:26 AM
> To: Jim Schaad <[email-masked]>; draft-ietf-ace-oscore-
> [email-masked]
> Cc: [email-masked]
> Subject: Re: Shepard comments on draft-ietf-ace-oscore-profile
> 
> Hi Jim,
> 
> Inline.
> 
> Thanks,
> Francesca
> 
> FP: Assuming you are referring to fields missing in the
> OSCORE_Security_Context, (please correct me otherwise) this is a good
> point. We currently do not define what happens if the security context has
> unrecognized parameters. We don't foresee this happening, as the AS
> should know what the client and RS implement. However, to cover this case
> (bad implementation or something went wrong), to be on the safe side, we
> propose that there is a fatal error in that case. In fact, we don't know what
> additional parameters might be registered in the OSCORE_Security_Context,
> and although they could be "risk-free" (as in optional additional information
> non-necessary for the security context derivation), they could also be input
> to the key derivation for example, in which case the endpoint non-
> recognizing them would end up storing a "wrong" security context. What do
> you think?

Sounds good.  I had a vague thought that perhaps some of the group items might be added in the future but no hard items to add.

Jim