Bouncycastle support for SPHINCS shows that they treat it as a separate
(unique) crypto system
https://www.bouncycastle.org/docs/docs1.8on/org/bouncycastle/pqc/jcajce/interfaces/SPHINCSKey.html
On 2022-07-06 14:58, Ilari Liusvaara wrote:
On Wed, Jul 06, 2022 at 10:04:00AM +0200, Anders Rundgren wrote:
I agree. New crypto systems should follow the standard for "kty":
https://datatracker.ietf.org/doc/html/rfc7517#section-4.1
The "kty" (key type) parameter identifies the
On 2022-07-06, at 20:14, Laurence Lundblade wrote:
>
> By RFC 9052:
> ? 4 => bstr,; key identifier
>
> which says kid is either entirely absent
(i.e., both the 4 and the byte string are absent, which they can be because the
entry was marked with a ?, which is a shortcut for 0*1,
By RFC 9052:
? 4 => bstr,; key identifier
which says kid is either entirely absent from the header parameters or h’’ or
some byte string value . Don’t think it can be NULL or “”. I didn’t allow
those in my implementation.
Maybe this is different in YANG, but pretty sure this is
On Wed, Jul 06, 2022 at 10:04:00AM +0200, Anders Rundgren wrote:
> I agree. New crypto systems should follow the standard for "kty":
> https://datatracker.ietf.org/doc/html/rfc7517#section-4.1
>
>The "kty" (key type) parameter identifies the cryptographic
>algorithm family used with the
Agree here, the ‘kid’ field includes a hint as to which key to use to verify
the COSE object.
If the hint is null, or an empty item, and the receiver isn’t able to use that
as a hint, it can try to identify the key in some other way e.g. based on
context.
If that’s not possible, then it will
On Tue, Jul 05, 2022 at 02:45:00PM -0500, Orie Steele wrote:
> Hello,
>
> We've been working on JOSE/COSE representations for post quantum
> cryptography here:
>
> https://mesur-io.github.io/post-quantum-signatures/draft-prorock-cose-post-quantum-signatures.html
>
