AAD Usage Clarifications #51
Conversation
Based on interop testing with Daisuke
draft-ietf-cose-hpke.md
Outdated
| discouraged by RFC 9052, this profile allows the use of the 'kid' parameter | ||
| (or other parameters) to identify the static recipient public key used by | ||
| the sender. If the COSE_Encrypt0 contains the 'kid' then the recipient may | ||
| discouraged by RFC 9052, this profile RECOMMENDS the use of the 'kid' parameter |
There was a problem hiding this comment.
COSE-HKPE is not really a "profile". It is a new standard encryption mechanism for COSE (not a big deal, but I thought I'd mention it).
| (or other parameters) to identify the static recipient public key used by | ||
| the sender. If the COSE_Encrypt0 contains the 'kid' then the recipient may | ||
| discouraged by RFC 9052, this profile RECOMMENDS the use of the 'kid' parameter | ||
| (or other parameters) to explicitly identify the static recipient public key |
There was a problem hiding this comment.
I think the use or non-use of kid depends on the use case. If you have a use case where the key is known already then it is not needed (not a big deal, but I thought I'd mention it).
There was a problem hiding this comment.
That's correct. You don't have to use it but we recommend it in the generic case.
| @@ -208,7 +197,7 @@ structure, i.e. one COSE_recipient structure per recipient. | |||
| In this approach the following layers are involved: | |||
|
|
|||
| - Layer 0 (corresponding to the COSE_Encrypt structure) contains the content (plaintext) | |||
| encrypted with the CEK. This ciphertext MAY be detached. If not detached, then | |||
| encrypted with the CEK. This ciphertext may be detached, and if not detached, then | |||
There was a problem hiding this comment.
I don't think detached / non-detached needs to be mention in this document. (not a big deal, but I thought I'd mention it).
There was a problem hiding this comment.
I downgraded the sentence to avoid the use of the MAY to may
draft-ietf-cose-hpke.md
Outdated
| Section 5.3 of {{RFC9052}} need to be followed, which includes the | ||
| calculation of the authenticated data strcture. | ||
|
|
||
| At layer 1 where HPKE is used to encrypted the CEK, the "aad" parameter |
There was a problem hiding this comment.
"encrypt", not "encrypted"
draft-ietf-cose-hpke.md
Outdated
| @@ -251,6 +240,34 @@ header_map = { | |||
|
|
|||
| The COSE_Encrypt MAY be tagged or untagged. | |||
|
|
|||
| When encrypting the content at layer 0 then the instructions in | |||
| Section 5.3 of {{RFC9052}} need to be followed, which includes the | |||
There was a problem hiding this comment.
"need" -> "MUST"
| @@ -251,6 +240,34 @@ header_map = { | |||
|
|
|||
| The COSE_Encrypt MAY be tagged or untagged. | |||
|
|
|||
| When encrypting the content at layer 0 then the instructions in | |||
There was a problem hiding this comment.
This seems correct to me.
draft-ietf-cose-hpke.md
Outdated
| Section 5.3 of {{RFC9052}} need to be followed, which includes the | ||
| calculation of the authenticated data strcture. | ||
|
|
||
| At layer 1 where HPKE is used to encrypted the CEK, the "aad" parameter |
There was a problem hiding this comment.
This is progress on #42. It is saying what the "aad" parameter input to the Seal() API is.
draft-ietf-cose-hpke.md
Outdated
| from the COSE_recipient structure at layer 1, encoded in a bstr type. | ||
|
|
||
| The external_aad field in the Enc_structure contains the Externally Supplied | ||
| Data described in Section 4.3 and Section 5.3 in RFC 9052. If this field is |
There was a problem hiding this comment.
This is restating some of 9052. I kind of thought it's better not to do restatements and if you do, say the original is normative. (not a big deal, but I thought I'd mention it).
There was a problem hiding this comment.
I agree with Laurence that there is no need to restate what is written in another spec. However, I also think that this PR should be merged once and editorial corrections can be done later as a PR that resolves the issue (#41) Laurence filed.
| not supplied, it defaults to a zero-length byte string. | ||
|
|
||
| The HPKE APIs also use an "info" parameter as input and the details are | ||
| provided in {{info}}. |
There was a problem hiding this comment.
Wish we could improve this a lot. Kind of seems like the user of COSE-HPKE has to do a deep threat analysis of their use case to know what to do here. Probably they have to do a lot less than in regular COSE, because COSE-HPKE internally takes care of a lot of this.
There was a problem hiding this comment.
I agree, and I think it would be better to solve this with another PR.
draft-ietf-cose-hpke.md
Outdated
| The protected field in the Enc_structure contains the protected attributes | ||
| from the COSE_recipient structure at layer 1, encoded in a bstr type. | ||
|
|
||
| The external_aad field in the Enc_structure contains the Externally Supplied |
There was a problem hiding this comment.
| The external_aad field in the Enc_structure contains the Externally Supplied |
draft-ietf-cose-hpke.md
Outdated
| from the COSE_recipient structure at layer 1, encoded in a bstr type. | ||
|
|
||
| The external_aad field in the Enc_structure contains the Externally Supplied | ||
| Data described in Section 4.3 and Section 5.3 in RFC 9052. If this field is |
There was a problem hiding this comment.
| Data described in Section 4.3 and Section 5.3 in RFC 9052. If this field is |
draft-ietf-cose-hpke.md
Outdated
|
|
||
| The external_aad field in the Enc_structure contains the Externally Supplied | ||
| Data described in Section 4.3 and Section 5.3 in RFC 9052. If this field is | ||
| not supplied, it defaults to a zero-length byte string. |
There was a problem hiding this comment.
| not supplied, it defaults to a zero-length byte string. |
Based on interop testing with Daisuke