Re: [saag] [CFRG] OCB does not have an OID specified, that is a general problem

[Neil Madden <[e-mail]>]

On 8 Jun 2021, at 01:58, Phillip Hallam-Baker <[e-mail]> wrote:
> 
> 
>> On Mon, Jun 7, 2021 at 10:02 AM Neil Madden <[e-mail]> wrote:
>> Unless there is a compelling reason to do so, I’d prefer that registering algorithm identifiers for JOSE be a manual (and rare) step. JOSE provides no way for consumers to advertise which Encryption Methods they support (“enc” - which is what OCB would be), so adding new options here can only harm interoperability.
>> 
>> (This is in contrast to key agreement algorithms - “alg” - as these can be advertised in the JSON Web Key metadata).
> 
> I don't agree. JOSE has no algorithm negotiation mechanism because it is a format, not a protocol. After we went through the whole recommended/required algorithm thing on JOSE, it suddenly occurred to me that this was precisely none of JOSE's business. It is for the protocols and services built using XML Signature, JOSE, CMS etc. to decide what algorithms to require and/or recommend. 

Doesn’t this contradict your desire to have a single IANA algorithm registry? If individual application protocols are to state which algorithms to use then they need a registry each to state this. 

> 
> JWK is a protocol built on top of JOSE, so it makes sense for that protocol to specify recommended algorithms.

This is rather backwards: JWK is part of JOSE and indeed JOSE depends on JWK (see for example the “jwk” and “epk” headers). 

> But the recommendations made in the JOSE spec have absolutely no bearing on the Mesh which uses parts of JOSE because being written six years later, the state of the art has moved on. The Mesh does not support RSA at all and the elliptic curve algs are X448 and Ed448. The curve 25519 versions are not supported for profile signing, etc. etc.
> 
> I would expect the same to apply in the COSE world. Merely defining a code point for JOSE or CMS does not make a statement about the algorithm recommendation status.

Well it does actually - see the “JOSE Implementation Requirements” field: https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms

And the reason for this is because the algorithms are implemented by JOSE libraries. Indeed, this is the whole point of JOSE, that applications don’t need to implement their own algorithms but can just use a preexisting library. 

> All it does is specify the one canonical identifier every application will use. It is not at all important what that identifier is (provided it is not an absurd length) it is critical that everyone use the same identifier though.

If different applications are going to specify different algorithms then this somewhat argues against your point: they _don’t_ need to use the same algorithm identifiers as other applications in that case. 

But I think we’re rather getting off the track here because as I mentioned in my first email, OCB would be standardised as an Encryption Method (“enc” header value). This introduces more complications. JOSE supports encrypting a message to multiple recipients, each of which can use a different key management algorithm (“alg”). But the content of the message has to be encrypted using a common symmetric Encryption Method that all the recipients understand. This is why introducing new Encryption Methods is problematic because as the number of options goes up, the chances of finding an algorithm that all recipients agree on reduces.  

(The alternative is that we register as many new “enc” values as we like but they are all effectively ignored because everyone uses “A128CBC-HS256” as the only thing guaranteed to work everywhere. This is not the case currently because there are only a few “enc” options and so most libraries implement all of them). 

In 2021, I think OCB has very few advantages over JOSE’s existing GCM Encryption Methods, so I think it is much more trouble than it’s worth to specify it for use there. If we’re going to expand the “enc” registry I’d rather it was for an algorithm with significant advantages over the existing alternatives, such as misuse resistance or better performance on low-end hardware. 

— Neil