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

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 7 Jun 2021 08:51:30 -0400

Raising this in SAAG because this raises a policy issue and CFRG because
that is where the policy should be enforced. It is also relevant to LAMPS
but trying to avoid cross posting as everyone on the LAMPS list is likely
on SAAG.

rfc7253 specifies OCB mode. But there is no OID specified to use OCB with
CMS, nor are there identifiers for use with JOSE.

This is problematic to say the least. If an algorithm is worth publishing
as an RFC, there should be definitive identifiers for general purpose
packaging formats specified in that RFC.

I would like to propose that in future assignment of relevant OIDs and JOSE
identifiers be considered a requirement for similar work. If a spec for a
symmetric mode isn't sufficiently specified to enable interoperable
implementation in CMS and JOSE, it is not sufficiently specified to be an
RFC.

This would not cover TLS, IPSEC etc. since they have rather different
considerations. Algorithms are curated and selected as suites for TLS for a
start.

I am not a fan of having multiple registries for specifying identifiers for
algorithms. In fact if I had my way, there would be a single IANA text
registry because while we could write a spec for a cryptographic algorithm
and call it SMTP, that would be silly.

It seems to me that one registry for the ASN.1 identifiers and one for text
based identifiers is sufficient for all reasonable purposes. To the extent
that XML signature and encryption are still a thing, well why don't we just
specify a generic URN scheme for IANA registries and have done.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 7 Jun 2021 13:44:49 +0000

*   rfc7253 specifies OCB mode. But there is no OID specified to use OCB with CMS, nor are there identifiers for use with JOSE.

For this particular case, a request to the IANA expert will get an OID.  (He’s a co-chair of LAMPS :)

  *   I would like to propose that in future assignment of relevant OIDs and JOSE identifiers be considered a requirement for similar work. If a spec for a symmetric mode isn't sufficiently specified to enable interoperable implementation in CMS and JOSE, it is not sufficiently specified to be an RFC.

That’s a reasonable thing to ask for, and something that could be caught by SECDIR or AD review.

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 7 Jun 2021 13:53:10 +0000

Hi!

From: saag <[email-masked]> On Behalf Of Salz, Rich
Sent: Monday, June 7, 2021 9:45 AM
To: Phillip Hallam-Baker <[email-masked]>; IETF SAAG <[email-masked]>; IRTF CFRG <[email-masked]>
Subject: Re: [saag] [CFRG] OCB does not have an OID specified, that is a general problem

[Roman] Agreed in the general case for the IETF stream.  For RFC7253, this review would have been during IESG conflict review because that document was IRTF stream (which doesn’t have an SECDIR review, AD review or even an IESG ballot).

Roman

---

From: Neil Madden <[email-masked]>
Date: Mon, 7 Jun 2021 15:02:14 +0100

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).

— Neil

> On 7 Jun 2021, at 13:51, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> Raising this in SAAG because this raises a policy issue and CFRG because that is where the policy should be enforced. It is also relevant to LAMPS but trying to avoid cross posting as everyone on the LAMPS list is likely on SAAG.
> 
> 
> rfc7253 specifies OCB mode. But there is no OID specified to use OCB with CMS, nor are there identifiers for use with JOSE.
> 
> This is problematic to say the least. If an algorithm is worth publishing as an RFC, there should be definitive identifiers for general purpose packaging formats specified in that RFC.
> 
> I would like to propose that in future assignment of relevant OIDs and JOSE identifiers be considered a requirement for similar work. If a spec for a symmetric mode isn't sufficiently specified to enable interoperable implementation in CMS and JOSE, it is not sufficiently specified to be an RFC.
> 
> This would not cover TLS, IPSEC etc. since they have rather different considerations. Algorithms are curated and selected as suites for TLS for a start. 
> 
> I am not a fan of having multiple registries for specifying identifiers for algorithms. In fact if I had my way, there would be a single IANA text registry because while we could write a spec for a cryptographic algorithm and call it SMTP, that would be silly. 
> 
> It seems to me that one registry for the ASN.1 identifiers and one for text based identifiers is sufficient for all reasonable purposes. To the extent that XML signature and encryption are still a thing, well why don't we just specify a generic URN scheme for IANA registries and have done.
> _______________________________________________
> CFRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 7 Jun 2021 16:15:15 +0200

> 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 Encryptio…

... and for COSE, I don’t think there is such a constraint, so algorithm registration should be handled together with any OID checking.

Grüße, Carsten

---

From: Richard Outerbridge <[email-masked]>
Date: Mon, 7 Jun 2021 10:34:19 -0400

Hmm …
__outer

> On 2021-06-07 (158), at 09:53:10, Roman Danyliw <[email-masked]> wrote:
> 
> Hi!
>  
> From: saag <[email-masked] <mailto:[email-masked]>> On Behalf Of Salz, Rich
> To: Phillip Hallam-Baker <[email-masked] <mailto:[email-masked]>>; IETF SAAG <[email-masked] <mailto:[email-masked]>>; IRTF CFRG <[email-masked] <mailto:[email-masked]>>

[ … ]

> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/cfrg <https://www.irtf.org/mailman/listinfo/cfrg>

---

From: Russ Housley <[email-masked]>
Date: Mon, 7 Jun 2021 11:00:51 -0400

It would be very easy to write a document like RFC 5084 for AES-OCB.  If you want to do that, I'm sure that LAMPS could adopt and review it.

Russ

> On Jun 7, 2021, at 8:51 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 7 Jun 2021 20:58:12 -0400

On Mon, Jun 7, 2021 at 10:02 AM Neil Madden <[email-masked]> 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.

JWK is a protocol built on top of JOSE, so it makes sense for that protocol
to specify recommended algorithms. 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. 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.

---

From: Neil Madden <[email-masked]>
Date: Tue, 8 Jun 2021 08:53:26 +0100

On 8 Jun 2021, at 01:58, Phillip Hallam-Baker <[email-masked]> wrote:
> 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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 8 Jun 2021 12:36:14 -0400

My view of the way IETF/IRTF should consider cryptographic algorithms might
be described as a 'fat waist model'

First of all we have general discussion of the canon of prefered
cryptographic algorithms for use in IETF protocols in SAAG and CFRG. There
is a lot of overlap between the groups of course but CFRG is the primary
gatekeeper that algorithms must pass to be added to the canon and SAAG is
the primary grim reaper taking them away.

Once we decide an algorithm is no longer fit for purpose, we want to remove
it from the recommendations for every current standard. Merely adding an
algorithm to the canon does not mean that every current standard must allow
it. All that it means is that it is available for those standards which
might use it.

This canon represents the base of the pyramid.

At the very top of the pyramid we have protocol standards. Here we
typically look to limit the choices both for interoperability and for
security. The algorithm choices are taken from the canon but they are in
most cases going to be a subset of the canon. As a general rule we would
normally want to limit ourselves to one primary and one backup for each
cryptographic function. This is because the security of the system is
generally the security of the weakest algorithm, Adding stronger algorithms
to a protocol suite does not make the protocol any stronger, only removing
the obsolete weaker algorithms does that.

Since removing algorithms is typically a costly and painful process, most
new protocol proposals should adopt the strongest algorithm choices that
are appropriate at the time it is introduced. The choices I would have made
in 2014 have no bearing on the choices I would make in 2021. One of the
simplifications I have made in the Mesh is to require 448 bit ECDH, 256 bit
AES and 512 bit SHA-2 or SHA-3. Those are entirely defensible choices in
2021, I don't think I could have gotten away with those in 2014 and people
would have been looking at me funny if I proposed them in 2005.

And then in the middle of the pyramid we have standards which aren't
actually protocols in their own right but are components used in protocols.
In the security area these are our cryptographic format specs such as
PKCS#7/CMS, XML Signature, XML Encryption, JOSE, DARE, etc. etc.

I was one of the people who spent many hours debating the inclusion or
exclusion of various algorithms from most of those formats and it is only
now that I have realized that the entire discussion was a waste of time
because cryptographic format specs do not raise interoperability issues,
protocols do.

Since these are not protocols in their own right, the interoperability
issues are very different to those of a protocol. They might apply to
someone who is going to write a standalone library for a format. But even
that seems like the wrong approach to me. My reference code for the Mesh
contains a JOSE and a DARE library. Neither of which actually contains any
algorithm code. The algorithms are implemented in .NET Core which in turn
uses OpenSSL or Windows crypto or in the case of algorithms .NET does not
support, in my own code.

[My implementation has 2197 lines of executable code that provide packaging
of cryptographic algorithms so they can be applied in a consistent manner
and only 1439 lines that implement algorithms]

Does the fact that JOSE supports RSA require the Mesh to support RSA? - No.
Does the fact that JOSE requires HMAC-SHA2 256 bit require the Mesh to use
it? - No.
Does the fact that JOSE does not define an identifier for AES-OCB prevent
the Mesh using it? - No.
Should the Mesh define its own set of algorithm identifiers to compete with
those used by JOSE? - Oh please no.

Of course, the Mesh is really built on DARE which is based on JOSE but has
quite a bit added and even more taken away. The Mesh approach to crypto is
that there should be exactly one way to do a given thing. So where JOSE has
to allow six different key wrapping approaches, the Mesh has one, where
JOSE supports three cipher suite strengths, the Mesh has one, etc. etc.

It is this cryptographic format that I consider the 'fat waist'. Basically
any cryptographic algorithm that is a part of the canon can be
specified here and in some cases we are going to have algorithms that are
not specified. We can write text that says that an S/MIME application MUST
NOT sign using MD5 or encrypt using DES but both have to be in any real
world application and that can never change because Alice has to be able to
read the message Bob sent in 1995 in 2021 and possibly in 2050.

The one area in which cryptographic formats do raise interop issues is when
they are used as a file format. And only some formats are used as file
formats.

rfc7518 (ietf.org) <https://datatracker.ietf.org/doc/html/rfc7518>

   Registering the algorithms and identifiers here, rather than in the
   JWS, JWE, and JWK specifications, is intended to allow them to remain
   unchanged in the face of changes in the set of Required, Recommended,
   Optional, and Deprecated algorithms over time.  This also allows
   changes to the JWS, JWE, and JWK specifications without changing this
   document.

On Tue, Jun 8, 2021 at 3:53 AM Neil Madden <[email-masked]> wrote:

>> (This is in contrast to key agreement algorithms - “alg” - as these can
>> be advertised in the JSON Web Key metadata).
>>
>
> 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.

> 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.

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

> 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.
>
> 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.
>

And merely assigning a code point does not change the recommendations for
implementing algorithms in a 'JOSE Library'.

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.

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.

> (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. 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.

---

From: Neil Madden <[email-masked]>
Date: Fri, 11 Jun 2021 11:00:31 +0100

On 8 Jun 2021, at 17:36, Phillip Hallam-Baker <[email-masked]> wrote:
> […]
> 
> On Tue, Jun 8, 2021 at 3:53 AM Neil Madden <[email-masked] <mailto:[email-masked]>> wrote:
> On 8 Jun 2021, at 01:58, Phillip Hallam-Baker <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> On Mon, Jun 7, 2021 at 10:02 AM Neil Madden <[email-masked] <mailto:[email-masked]>> wrote:
> 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.

> 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> 

> 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 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?

> 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.
> 
>  
> 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.

> 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.
>  
> 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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 11 Jun 2021 23:52:41 -0400

On Fri, Jun 11, 2021 at 6:00 AM Neil Madden <[email-masked]> wrote:

> 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):
>

Yes, like I said. It was a mistake. There is no need to compound it.

> It absolutely does in this case.

Only because there is a column giving the recommendation status. My point
is that is a mistake.

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.
>

It will become the standard if people use it. Which is precisely the point:
Code point registrations are properties of algorithms, not one particular
protocol that might use them. There should never have been a JOSE algorithm
registry in the first place, it should have been a registry of algorithms
that JOSE was merely the first consumer of.

I remember when the IANA Content Type Registry was the MIME Type. If MIME
had made recommendations for supported types, should those have been
binding on the Web?