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
