Support for full private keys

[adam-r-ncsc]

The need to support full private keys (versus seeds only) for use with HSMs has come up in WGLC for other PQC LAMPS drafts. We're almost immune to that discussion as the primary private key format is described in the ML-DSA X.509 draft, but we do include a definition for ML-DSA-PrivateKey that's restricted to 32 bytes.

If the ML-DSA X.509 draft adopts a choice of two key formats, ML-DSA-PrivateKey should follow suit. Either way, there's no explanation that the 32 byte restriction corresponds to a seed, which perhaps might not be immediately obvious, so a brief explanation might help there.

Relevant threads:
https://mailarchive.ietf.org/arch/msg/spasm/QRvuqH2uLCgWLthF3JUC1C8eAUE/
https://mailarchive.ietf.org/arch/msg/spasm/JRUQk0m0MtEr3YwFpcxD6PiwMLE/

[danvangeest]

I would be happy if the majority of our ASN.1 was moved over to the certs draft so we can sidestep the issue entirely. That would also avoid us needing to add any seed explanation.

I'll send an email to both sets of authors before making a WGLC comment on it for the certs draft.

[adam-r-ncsc]

I think that makes sense, the split does feel a little odd. The private key format is even arguably a CMS thing given the RFC it refers to a CMS RFC, but practically speaking the number of X.509 implementations using those formats is going to be much greater than the set of CMS implementations using them.

[danvangeest]

I think that makes sense, the split does feel a little odd. The private key format is even arguably a CMS thing given the RFC it refers to a CMS RFC, but practically speaking the number of X.509 implementations using those formats is going to be much greater than the set of CMS implementations using them.

Can you expand on "the RFC it refers to a CMS RFC"? Which RFC are you/it referring to?

[BenS-3]

I'm happy for everything to be moved over to the certs draft - having all of the ASN.1 everything in one place that we can just point to makes sense.

Equally, I'd be happy for consensus during WGLC to make the decision for us.

[adam-r-ncsc]

I think that makes sense, the split does feel a little odd. The private key format is even arguably a CMS thing given the RFC it refers to a CMS RFC, but practically speaking the number of X.509 implementations using those formats is going to be much greater than the set of CMS implementations using them.

Can you expand on "the RFC it refers to a CMS RFC"? Which RFC are you/it referring to?

RFC 5958 - the document's titled "Asymmetric Key Packages" (as opposed to "Asymmetric Key Formats") and it describes how to encrypt/sign/etc private keys in CMS, so I've always seen it as a CMS RFC. But it doesn't describe the core private key format as being part of CMS and that format's derived from PKCS#8 (rather than PKCS#7), so I think my perception is based on biases from my personal experiences, rather than a reflection of reality! 🙂

Either way, I agree that the X.509 draft is the right place if everyone's amenable to that.

[BenS-3]

Do we want to resolve this before going to WGLC ourselves, or should we publish as-is and let it all be sorted out as part of the WGLC process? Alternatively I can ask Russ what his preferred approach is.

[danvangeest]

Do we want to resolve this before going to WGLC ourselves, or should we publish as-is and let it all be sorted out as part of the WGLC process? Alternatively I can ask Russ what his preferred approach is.

You could reply to Russ' thread to us authors saying we're working with the dilithium-certs authors to move the ASN.1 and key encoding text to the dilithium-certs draft for the reasons I posted to LAMPS. There are PRs for the changes already. Then ask him if he wants to wait for those PRs, or start the WGLC knowing both drafts should be updated shortly.