Hi Carsten,
> Trivial to add (assign AEAD-Value 7).
The AEAD-Value for Export-Only is 0xffff. I think AEAD-Value 7 cannot be
assigned. Am I wrong?
> Don’t do that, then.
Indeed. It may not be something to worry about too much :-)
> Indeed. 2 bytes extra. As will be any a-la-carte approach.
a-la-carte approach registers only one alg (HPKE-v1-Base). The
smallest-length number can be assigned to it.
> Can you explain this point?
The current draft utilizes the algorithm IDs (kem_id, kdf_id, aead_id) of
HPKE as they are. They are passed directly from the higher-level
application to the HPKE library, so there is no need for a conversion
process like your proposed alg_id => {kem_id, kdf_id, aead_id}.
Best,
Daisuke
2023年6月4日(日) 15:04 Carsten Bormann <[email protected]>:
> Hi Daisuke,
>
> > On 4. Jun 2023, at 05:18, AJITOMI Daisuke <[email protected]> wrote:
> >
> >
> > - It cannot represent ExportOnly. There is no reasonable justification
> to exclude ExportOnly at the current stage.
>
> Trivial to add (assign AEAD-Value 7).
>
> > - There is a need for continuous standardization effort to ensure that
> HPKE algorithm IDs are assigned within the applicable scope of this ID
> conversion rule.
>
> As soon as one registers an ID that is not in the range covered.
> Don’t do that, then.
>
> > - Starting the IDs from 1024 would result in larger ID sizes.
>
> Indeed. 2 bytes extra. As will be any a-la-carte approach.
>
> > - Compared to the current specification, unnecessary conversion
> implementations would be required at the COSE library layer.
>
> Can you explain this point?
>
> Grüße, Carsten
>
>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
