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

[Neil Madden <[e-mail]>]

On 8 Jun 2021, at 17:36, Phillip Hallam-Baker <[e-mail]> wrote:
> […]
> 
> On Tue, Jun 8, 2021 at 3:53 AM Neil Madden <[e-mail] <mailto:[e-mail]>> wrote:
> On 8 Jun 2021, at 01:58, Phillip Hallam-Baker <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> On Mon, Jun 7, 2021 at 10:02 AM Neil Madden <[e-mail] <mailto:[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. 
> 
> Not at all. My point is that the purpose of a registry is limited to assigning a signifier to one or more signified. It is not for IANA to specify that RSA is required or not, that is a WG decision.

And yet that is exactly what is recorded in the IANA JOSE registry. I appreciate that you’d like things to be different, but that’s not the reality today. A WG established the IANA registry and set up the procedures by which alterations to it are made, as described in RFC 7518 that established the registry (p34):

   The implementation requirements of an algorithm may be changed over
   time as the cryptographic landscape evolves, for instance, to change
   the status of an algorithm to Deprecated or to change the status of
   an algorithm from Optional to Recommended+ or Required.


>  
>> 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). 
> 
> Well yes and no, JWK also pops up in other contexts. OAUTH2 would have been a better example. 

OAuth2 doesn’t have any dependency on JOSE. I think you mean OIDC?

> JOSE doesn't even specify the serialization format, it is a component of a protocol, not a protocol.

Sorry, what? JOSE defines *two* serialization formats: https://datatracker.ietf.org/doc/html/rfc7515#section-7 <https://datatracker.ietf.org/doc/html/rfc7515#section-7> 

>  
>> 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 <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. 
> 
> And merely assigning a code point does not change the recommendations for implementing algorithms in a 'JOSE Library'.

It absolutely does in this case.

> 
> Since I wrote my own JOSE library in less than a week, I have a hard time believing that it is the JOSE part that is critical. And since I used the .NET crypto as base, the recommendations in the JOSE specs were not remotely relevant.

If you didn’t implement the Required algorithms, then you didn’t implement a standards-compliant JOSE library. Otherwise what do you think “JOSE Implementation Requirements: Required” means on an IANA JOSE algorithm registration?

>> 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. 
> 
> There is no reason why the algorithm suite for the Mesh should be the same as that for SIP and plenty of reasons why it needs to be different. The Mesh uses threshold cryptography which only works with DH and ECDH algorithms for a start. Even if RSA was still viable from a security point of view, I couldn't use it. OCB was patent encumbered when JOSE was written, it is not today. The advantages of OCB over GSM are significant but not something that is worth losing backwards compatibility over.
> 
>  
> 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.  
> 
> Since I have 0 users and 1 implementation, my scope for deciding algorithm choices is radically different from that of others.
> 
> You keep conflating the concerns that apply to existing JOSE applications to the concerns that properly apply to JOSE.

I’m not conflating anything. Unlike yourself, I am the primary maintainer of a JOSE library that is in use in some of the largest organisations in the world handling many millions of operations every day. You keep making statements that are directly in contradiction with the JOSE RFCs.

>  
> (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). 
> 
> OATH2 allows use of 128 bit AES and 256 bit SHA-2.

Again, I assume you mean OpenID Connect, as OAuth2 itself makes no recommendations about cryptography at all (other than requiring TLS). OIDC itself defers to JOSE for algorithms. So here you can see that the choice of algorithms in the IANA JOSE algorithms registry directly and immediately impacts a widely used protocol.

> The Mesh requires 256 bit AES and 512 bit SHA-2 or SHA-3. And that is exactly what you would expect. OAUTH2 is an attempt to define an authorization scheme that is conflated into an authentication mechanism that manages to squeeze itself into the legacy deployed base of Web Browsers. The Mesh is a Threshold PKI whose primary function is management of private keys. My problems have absolutely nothing in common with those of OAUTH2 which is why their algorithm choices have no bearing on mine any more than TLS is beholden to CMS or CMS to OpenPGP.
>  
> 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. 
> 
> This was discussed at some length on the cryptography list and the overwhelming feeling there was to go for OCB. That was not a decision taken lightly as it required me to write the implementation. GCM is a stream cipher and the uses in the Mesh clearly require a block cipher which means CBC and OCB are the only acceptable choices.
> 

By your own admission the Mesh is doing something entirely non-standard with JOSE anyway, so you are also free to also adopt OCB as a non-standard algorithm. 

As somebody who is responsible for maintaining a JOSE library (and an OIDC implementation), I’d rather we were somewhat conservative in adopting new JOSE algorithms. I strongly disagree that there should be a presumption that any algorithm published by CFRG should immediately be considered for adoption by default in JOSE. There are cases where I think adoption would be sensible - e.g. I hope to see post-quantum algorithms for JOSE at some point - but OCB doesn’t reach the bar in my opinion. 

— Neil