[openpgp] Re: ML-KEM and ML-DSA secret key format

[Heiko Schäfer <[e-mail]>]

Hi Michael, Daniel, list,

to make one point (which I think both of you have implied) explicit:

The "small HSM" OpenPGP card devices that are quite popular with OpenPGP 
users are all designed so that it's (supposed to be) impossible to 
retrieve private key material from them.
So for all devices in this class, the question of "migrating from 
hardware-backed to software-backed" key format does not arise, because 
these cards do not support exporting the private key material. In any 
format.


Separately, like Daniel, I think we should not try to support the exotic 
use case of exporting private key material from some other type of HSM 
and transforming it into OpenPGP framing. Expending format-complexity on 
this use case seems like a bad tradeoff to me.

Users of such HSMs can either keep a copy of their key material in safe 
storage, in an OpenPGP-appropriate format - or rotate to a new subkey 
when needed.

Thanks,
Heiko


On 3/2/25 10:45 AM, Daniel Huigens wrote:
> Hi Michael,
>
> I agree with most of what you wrote, but I don't think any of it
> implies that we need to wait for the decision in LAMPS or base
> our own decision (for the OpenPGP wire format) on it (if you even
> meant to imply that, perhaps you didn't).
>
> If we mainly care about importing an OpenPGP key to an HSM, then
> storing the key as a seed up until that point is most convenient
> as you can go from a seed to an expanded key but not the other way
> around. So even if the HSM vendor decides not to support seeds in
> any way, we could convert the seed to an expanded key in software
> and then import that in whichever format the HSM vendors like
> (without specifying an OpenPGP-specific wire format for it).
>
> If we care about moving keys between HSMs, that can happen again
> in some format decided on by the HSM vendors and doesn't need to be
> specified by OpenPGP, specifically.
>
> It's only if we care about exporting an HSM key to a "software-backed"
> OpenPGP key that supporting an expanded key wire format could make
> sense, but IMHO this is not a use case that we should want to support.
>
> Best,
> Daniel
>
>
> On Friday, February 28th, 2025 at 20:08, Michael Richardson wrote:
>> The reason why the PKCS8 discussion in LAMPS is relevant to OPENPGP is
>> because one can hope that there will be support in OPENPGP products for
>> smaller/personal HSMs (USB tokens). The tokens might get used with a variety
>> of protocols.
>>
>> Today, signing of software is largely a PGP thing not an S/MIME thing.
>> (It's different in the MS-MSI space)
>> Particularly when it comes to signing git commits.
>>
>> My opinion is that there are very few situations where it's better to move a
>> private key rather than just have two or more signing keys be validated.
>> At least -- in an PKIX situation with a certification authority.
>> I think that YUM, and APT based systems can now specify a PGP keyring for
>> each source, and a signature from any key in that keyring is valid.
>> (And we've finally moved beyond mixing all the keys up for the different
>> sources)
>>
>> Having a way to backup a private key from one token to another one seems
>> (rather than generating a new key) might be operationally important for in
>> the software signing space.
>> I don't think the same considerations apply to individual use personal keys.
>>
>> I also think that OPENPGP key format allows us to have multiple private keys
>> attached to a single identity, and for those keys to reside on distinct
>> tokens. I admit that I've never tried this, but I ought to already.
>>
>>
>> --
>> Michael Richardson [e-mail] . o O ( IPv6 IøT consulting )
>>
>> Sandelman Software Works Inc, Ottawa and Worldwide
>> _______________________________________________
>> openpgp mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
> _______________________________________________
> openpgp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]