Re: Last ditch proposal for crypto suites

[Charlie_Kaufman@notesdev.ibm.com]

> Can an explicitly specified attribute override what's predefined in the
> suite? Yes, no, it depends?

No means no. Suites have no attributes or parameters.

That said, cryptographic algorithms that are not negotiated need not be
part of suites. At least at the level of the specification, it is easier to
let them be independent.

What does this mean?

Whether an endpoint authenticates by signing with a 1024 bit RSA key, a
2048 bit RSA key, a 1024 bit DSS key, or an HMAC based on a password is not
negotiated. There is no place in the protocol where you tell the other end
what sort of authentication you want because the presumption is that the
other end has only one way to authenticate and you're going to take it or
leave it. (If there were multiple ways to authenticate and you really
wanted to hide preferences in the protocol, you could do so in the CERTREQ
field saying what authorities you trust - different algorithms could - and
probably in practice do - live under different authorities).

So I maintain that suites should not say anything about authentication
algorithms. We don't - but probably should - say something about must
implement authentication algorithms & key sizes. But there is no obvious
reason to tie these to the suites used to protect the data. (In IKEv1 there
was, because different key types resulted in different protocol exchanges.
In IKEv2, they only affect the AUTH payload, and it is explicitly allowed
for one end to authenticate with an HMAC based on a password while the
other end authenticates with a DSS key and certificates.

I hope this doesn't open a can of worms, because if someone demanded it be
otherwise I wouldn't know how to do it.

          --Charlie

Opinions expressed may not even by mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).