Re: [jose] RFC 8037 "alg" quirkiness

[Anders Rundgren <[e-mail]>]

Apparently the PKIX folks came to a different conclusion:

https://tools.ietf.org/html/rfc8410#section-3

"The same algorithm identifiers are used for identifying a public key,
  a private key, and a signature (for the two EdDSA related OIDs)."

Anders

On 2020-09-16 15:01, Anders Rundgren wrote:
> On 2020-09-16 14:30, Ilari Liusvaara wrote:
>> On Sun, Aug 30, 2020 at 08:10:17AM +0100, Neil Madden wrote:
>>>> On 30 Aug 2020, at 07:58, Anders Rundgren <[e-mail]> wrote:
> 
> Hi Ilari, thanx for the explanation.
> 
> I guessed that the motive for changing the 00 spec was because no
> other algorithm was considered useful.
> 
> Personally, I rather noted the "deviation" in how things were
> expressed compared to the EC algorithms.
> 
> It is a bit in the same vein as JWS's Base64Url-encoding all binary
> elements except for "x5c".
> 
> I'm apparently "allergic" to asymmetry :-)
> 
>>>>
>>>> I have just implemented support for Edwards curves in my JSON
>>>> library.
>>    
>> You mean JOSE or JWS? Because JSON is a data model and encoding of
>> it. :-)
> 
> My JSON tools/library does indeed have integrated support for signatures
> and encryption, although based on RFC 8785 rather than forcing the
> entire caboodle to be in Base64Url or relying on HTTP headers holding
> detached JWS signatures (which does not permit simple serialization,
> embedding, or counter-signing) used by several Open Banking schemes.
> 
> Anders
> 
> 
>>
>>>> Although it is certainly not a deal-breaker I find the use of
>>>> "EdDSA" as a generic Edwards algorithm identifier rather quirky
>>>> since it departs from the other JWS algorithms:
>>>> https://tools.ietf.org/html/rfc8037#appendix-A.4
>>>>
>>>> For curiosity reasons I took a peek at the initial draft which has
>>>> (in my opinion...) a more logical solution:
>>>> https://tools.ietf.org/html/draft-liusvaara-jose-cfrg-curves-00#appendix-A.4
>>
>> On weird changes, I find the member name changes a bit weird. For
>> example it calls something that is not a curve a curve.
>>
>>>> May I ask why this change was performed?
>>
>> After prehashing was eliminated, there was only one algorithm that made
>> sense with either, so those were merged.
>>
>>>> For JSF (JSON Signature Format) I will stick to the "00" scheme
>>>> which also permits use of ed25519ph and friends if needed:
>>>> https://mobilepki.org/jsf-lab/home
>>
>> Beware of implementations that use wildly wrong algorithms.
>>
>> And on interactions of Ed25519 and Ed25519ph, they originally interacted
>> in harmful ways. Ed25519ph was later changed (in very hacky way) in
>> order to fix this (the same mechanism as used to contextualize Ed25519,
>> which turned out later to be horrible idea due to API issues it causes).
>>
>> And Ed25519ph is weaker than Ed25519. In order to prehash without
>> weakening the algorithm, one needs to salt the prehash, which Ed25519ph
>> does not do. And lack of salting has been exploited in real world.
>>
>>> 8037 was done by CFRG, so probably best to ask there.
>>
>> 8037 was done by JOSE. The CFRG part (generic specification of
>> EdDSA2) was 8032.
>>
>>> I like this aspect of the spec. IMO “alg” as a header was a mistake.
>>> By using a generic algorithm header, it forces implementors to
>>> associate the specific details in metadata stored with the key, which
>>> is much safer.
>>
>> Actually a few months ago I came up with idea of having a way to express
>> "algorithm determined by the key" in JOSE/COSE.
>>
>> - There have been some serious security issues in JWS implementations
>>     that have been caused by using completely wrong algorithms.
>> - In general, using the same key with multiple algorithms is not
>>     cryptographically safe. There can be algorithm pairs which interact
>>     badly (for instance, Ed25519 and the original Ed25519ph).
>>
>>
>> -Ilari
>>
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
>>
>