Hi Jim,
Inline.
Thanks,
Francesca
On 31/01/2019, 01:34, "Jim Schaad" <i...@augustcellars.com> wrote:
1. Please update the text for MUST/SHOULD/MAY to include the language from
RFC 8174.
FP: Right, thanks. Updated now in the github.
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?
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
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
