Subject: [saag] storing validation parameters on PKCS#8 formatted private keys

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 7 Aug 2017 13:11:50 +0200

Hi,
 I've needed to store parameters related to FIPS-186-4 provable key
generation validation in a PKCS#8 private keys for RSA (can be used
for DSA too if anyone cares). I've described the PKCS#8 extension at:
http://nmav.gitlab.io/draft-mavrogiannopoulos-pkcs8-validated-parameters/

The approach followed was simple, store the validation parameters as
an attribute, something that allows the keys to be backwards
compatible. I'd appreciate comments on the approach.

regards,
Nikos

---

From: Russ Housley <[email-masked]>
Date: Mon, 7 Aug 2017 11:53:39 -0400

This seems like a simple and straightforward approach to me.  I'd support publication as an RFC.

Russ

> On Aug 7, 2017, at 7:11 AM, Nikos Mavrogiannopoulos <[email-masked]> wrote:
> 
> Hi,
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 8 Aug 2017 10:24:17 +0200

Thank you.
I've posted a version at:
https://tools.ietf.org/html/draft-mavrogiannopoulos-pkcs8-validated-parameters-00

---

From: Brian Smith <[email-masked]>
Date: Thu, 10 Aug 2017 02:21:17 -1000

> compatible. I'd appreciate comments on the approach.

This format only supports one private key generation method, and also
requires (IIUC) that the proof be generated at the time the key was
generated.

Why not instead define an attribute for storing a primality certificate? A
primality certificate can be generated after-the-fact and for any (IIUC)
key generation algorithm.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 10 Aug 2017 14:53:44 +0200

On Thu, Aug 10, 2017 at 2:21 PM, Brian Smith <[email-masked]> wrote:
> primality certificate can be generated after-the-fact and for any (IIUC) key
> generation algorithm.

That's an interesting question. The algorithm's parameters above are
part of the key generation process and thus makes quite some sense to
store them with the private key.  However, a primality certificate as
you mentioned is typically generated after the fact, there are
multiple methods for it, and all of them involve a very long process
(which would also make key generation process longer if you'd like to
store them with the key), while they often produce several megabytes
of output.

Ignoring all that, I am still not sure what would a primality
certificate buy attached to a private key. The FIPS186-4 Shawe-Taylor
process on the other hand gives you not only an assurance that numbers
are prime, but that they were generated from the specific seed, with
the specific hash.

On the other hand, I see primality certificates being more suitable
for DH parameters, and in fact more suitable for being companions to
RFCs defining such parameters. Though even then, they only guarantee
primality, not that some particular process was followed when
generating them.

Don't take me wrong, I have nothing against primality certificates,
and I'd be happy to assign an OID for storing them if you have a use
for them.

regards,
Nikos