On Thu, Jul 27, 2017 at 10:37:50PM +0000, Kent Watsen wrote:
> Hi Juergen,
>
> > I looked a bit more and you define
> >
> > identity key-algorithm {
> > description
> > "Base identity from which all key-algorithms are derived.";
> > }
> >
> > plus a bunch of concrete algorithms. draft-ietf-rtgwg-yang-key-chain-24
> > defines
> >
> > identity crypto-algorithm {
> > description
> > "Base identity of cryptographic algorithm options.";
> > }
> >
> > and then a bunch of concrete algorithms (hashes and symmetric ones).
> > They also do not expect IANA to maintain things. I would love if
> > security area people would help us with getting this right, well
> > perhaps they jump in during secdir review.
>
>
> FWIW, the two sets of algorithm identities are disjoint. The ones in
> the keystore draft are all public-key algorithms. As for the key-chain
> draft, all but one of the identities are hmac algorithms, with the last
> one being for a key derivation function.
>
> It would be best to address this in the WG, for visibility. I think
> that it's possible to request an early secdir review, or maybe we can
> ask about just this concern. This is a chair-action.
>
I all for secdir review for this document. That said, perhaps it is OK
to have the identities as they are and to define a proper IANA
registry later. The price might be that some identities are defined
twice but that would likely not be a significant implementation cost.
Its a trade off between (i) moving fast and maybe requiring to adapt
later or (ii) trying to work everything out while doing the first
version and hence being slow.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>