[jose] Re: Algorithm identifiers for ML-KEM and ML-DSA

[Phillip Hallam-Baker <[e-mail]>]

Oh... now I know why I didn't find them, I was searching for the KEM
identifiers assuming if one was defined, both would be.

I suggest we get a stick in the ground on ML-KEM-512 etc post haste, they
had better follow the same pattern.


Could not really care less what the identifiers are. They do make a (small)
difference for my application though.

Currently Mesh profiles are a svelte 1KB or so which is really not bad
given that they are the digital hook for a person's entire digital gestalt.
They contain three Ed448/X448 keys and an X448 signature and a few other
bits, not bad eh?

The X448 key is only used to sign delegations under that profile and the
fingerprint of that ky is the user's life long personal identifier. They
may acquire others in their life but the old one never expires and will
never signify anyone else.


OK so what happens when I add Dilithium? If I just switch to the new
algorithms, the profile increases in size 16x. Ugh... And I am not sure I
want PQC overhead on my IoT interactions.

So for the first release of my system, I am going to modify the profile so
that it specifies a list of root key fingerprints (i.e. 512 bit digest)

roots : [ { "ML-DSA-87", 23kjhdkl3ir...}, { "Ed448", so39ji3jnjf...},  ]

Then take the fingerprint over a canonicalized version of the above. So
adding PQC upgrade capability adds only 80 bytes to each device/user
profile in the binary encoding (the algorithm tag + 64 byte hash +
punctuation). So as I said, it does impact my application but not by enough
to make a difference. Either the profile is small enough to fit easily in a
UDP packet or it isn't.


On Tue, Aug 20, 2024 at 2:48 PM Orie Steele <[e-mail]>
wrote:

> Hey PHB : )
>
> I'm only replying for ML-DSA / SLH-DSA, I'm not on the hook for ML-KEM.
>
> Thanks for trying to keep JWS small... even with massive PQ Signatures.
>
> Current JWS algorithms registry:
>
>
> https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms
>
> Current ML-DSA proposal:
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-cose-dilithium-03#name-the-ml-dsa-algorithm-family
>
> The names were chosen to align with:
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-04#section-2
>
> If you search either draft for "ML-DSA-44" you get an exact string match
> in both documents.
>
> I'm not in favor of changing the algorithm names, unless there is strong
> consensus to do so.
>
> I was hoping we might send the document to WGLC, and make some final
> adjustments to test vectors, as soon as a good non -ipd version emerges
> that I can use to generate examples.
>
> Can you live with the current algorithm names?
>
> Are you planning on shipping an implementation, that might be done in time
> to be added as an implementation report per:
> https://www.rfc-editor.org/rfc/rfc7942
>
> I'm happy to add your implementation to the draft if that's the case.
>
> Regards,
>
> OS
>
>
>
> On Tue, Aug 20, 2024 at 1:26 PM Phillip Hallam-Baker <
> [e-mail]> wrote:
>
>> All,
>>
>> I am looking for guidance on algorithm identifiers for ML-KEM and ML-DSA,
>> I understand that the drafts are not yet final. But I need to push code
>> that has PQC roots embedded before that is going to happen and would like
>> to follow as close as possible to what the final choices are going to be.
>>
>> I did try to look for this info but the work is spread thinly across many
>> forums...
>>
>> My preference is for fully specified algorithms with the strength
>> specified. I am also partial to longer rather than smaller identifiers but
>> that does not seem to be to the taste here. So my IDs would be
>>
>>
>> MLKEM512
>> MLKEM768
>> MLKEM1024
>> MLDSA44
>> MLDSA65
>> MLDSA87
>>
>> If we want to go denser:
>>
>> MLK512
>> MLK768
>> MLK1024
>> MLD44
>> MLD65
>> MLD87
>>
>> Actually, I like the second as they are more readable. I have been
>> reading a large number of tweets by an elderly person who types in all caps
>> online of late...
>>
>>
>> Since I need to ship before the specs are final, I will probably use:
>>
>> MLKa1024
>> MLDa87
>>
>> I see no need for other identifiers since I cannot imagine anyone who is
>> so concerned about CRQC robustness as to use PQC not using the highest
>> strength available at this point. Also, I want to stress test with the
>> biggest payloads.
>>
>> Signing every message with MLD87 turns out to have a very serious impact.
>> And not one I think I can justify for every application when a CRQC is
>> still at least a decade out. So the real goal at this point is to ensure
>> that if people start deploying the system and make use of it today, they
>> know they can transition seamlessly to a PQC version of everything in the
>> future.
>>
>> Turns out that costs only an extra 200 bytes or so in the user profiles!
>>
>> And before folk start whining about me mentioning my work on the Mesh,
>> the point of building a completely green field infrastructure is to test
>> out design approaches which we might attempt to retrofit to PKIX and SAML.
>>
>>
>> _______________________________________________
>> jose mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>
>
> --
>
>
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries>
>