I wonder if we might propose a concrete serialization for SPHINCS+ given
this commentary...
Please hold the bikeshed for "pset"... it's a placeholder for
parameterization.
Option 1: { kty: OKP, pset: SPHINCS+-128s }
Option 2: { kty: SPHINCS+, pset: 128s }
Consider also the similar options for Dilithium:
Option 1: { kty: OKP, pset: CRYDI3 }
Option 2: { kty: CRYDI, pset: CRYDI3 }
Which do you prefer: Option 1 or Option 2?
Regards,
OS
On Fri, Jul 8, 2022 at 11:33 AM Ilari Liusvaara <[email protected]>
wrote:
> On Wed, Jul 06, 2022 at 09:32:23PM +0200, Anders Rundgren wrote:
> > 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 cryptographic
> > > > algorithm family used with the key, such as "RSA" or "EC"
> > >
> > > COSE defines things bit differently:
> > >
> > > This parameter is used to identify the family of keys for this
> > > structure and, thus, the set of key-type-specific parameters
> > > to be found.
> >
> > I don't see that this depart from JOSE from an implementer's point of
> > view.
>
> The implementations I have done have key handling of the form:
>
> - Grab kty
> - Switch on kty
> + decode the keyshape.
> + Switch on subtype.
> * Construct the key from decoded parts.
>
> I have used that kind of structure for both static and dynamic
> registration. For the dynamic one, I handled OKP, EC and oct as special
> cases. Handling the EdDSA alg overload is no problem at all.
>
> Where things get genuinely annoying is the oct kty with dynamic
> registration. There is no subtype field and alg is optional, so when
> loading key, there is no way to tell what kind of key it is.
>
> > >
> > > > Putting different PQ crypto systems under the same moniker would be
> > > > a mistake regardless of the system's maturity. Distinct names permit
> > > > dynamic registration of cryptographic providers which is used by
> > > > platforms like Java.
> > >
> > > One should note that dynamic registration at crv(okp) level and kty
> > > level requires very different interfaces. The reason is that the first
> > > has to deal with fixed keyshape, while the latter has to deal with
> > > arbitrary keyshapes. And crv(ec2) is another different keyshape
> > > requiring yet another interface for dynamic registration (and watch
> > > out for key-algorithm pairs that would work, but are prohibited).
> >
> > When I referred to dynamic registration of cryptographic providers I
> > did not even consider the format of keys because this is a very small
> > issue compared to algorithm implementation.
>
> Interface design is no small matter. It is very easy to make flawed
> interfaces that then proceed to cause large amount of headache later.
>
> > That is, EC, RSA, RFC8037/OKP, SPHINCS+, etc.
>
> Looking back at RFC8037, for x25519 and x448, OKP is the only sensible
> keyshape. For Ed25519/Ed448, another keyshape that would make sense
> would be the one that has octet-string private/public keys and overloads
> alg for subtype selection (like what was proposed in this thread).
>
> And because of the properties of SPHINCS+, the sensible keyshapes for
> SPHINCS+ are exactly the same as the sensible keyshapes for Ed25519/
> Ed448.
>
> > >
> > > For relative difficulty of designing such interface, crv(okp) is
> > > the easiest, followed by crv(ec2) and kty is the hardest.
> > >
> > > And things get even less pleasant if two kty's actually have the same
> > > keyshape, as that will result in code duplication to parse the
> keyshape.
> > > As of currently, no two keyshapes are the same (OKP and HSS-LMS are
> > > subly different, as OKP has private keys, but HSS-LMS does not).
> > >
> > >
> > > And with regards to there being more OKP crv's in the future, the test
> > > implementation of COSE-HPKE I wrote uses five new OKP crv values...
> >
> > Sure, it works fine as long as there is a single implementation
> > supporting all known OKP algorithms.
>
> That has never been true in any JWS implementation I have done, as
> all have separate Ed25519 and Ed448 implementations that need to be
> dispatched between. It still works fine.
>
>
>
> -Ilari
>
> _______________________________________________
> COSE mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/cose
>
--
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries
<https://www.transmute.industries>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
