Re: [lamps] New Version Notification for draft-massimo-lamps-pq-sig-certificates-00.txt

[Russ Housley <[e-mail]>]

John:

> I agree, we just need to know how to encode the public key structure into a BIT STRING.   So I am just looking forward to clarity on the encoding of the DilithiumPublicKey.
> 
> For example, here is a Dilithium2 Public Key (using the Round 3 implementation from open quantum safe), encoded as a BIT STRING:
> 
> The OIDs I'm using are not standard as they still need to be defined... 😊

The LAMPS WG Charter assumes that NIST will assign these OIDs. as they have done for AES, SHA2, SHA3, and so on.

[snip]

> Russ, in regards to the PrivateKeyInfo structure, I was just pointing out the difference that I see in 5280 (OCTET STRING for privateKey vs BIT STRING for public key).   I think the way they have defined the DilithiumPrivateKey as an OCTET STRING is fine as it complies with 5280.   My only question in relation to the private key is why there has to be an option to have the public key in there?  If it is not there and an implementation required it to be there then wouldn't that cause interop issues?  

I am expecting both the public key and the private key to be octet strings.  For the public key, is it easy to specify how to carry an octet string in an ASN.1 BIT STRING.  For the private key, is it trivial to specify how to carry an octet string in an ASN.1 OCTET STRING.

One of the issues regarding private keys is discussed in draft-uni-qsckeys.  If the private key contains all of the optional values, then the structure gets very big.  If the private key does not contain all of the optional values, then these values need to be computed locally.  The right approach may depend recipient device and communications environment.  

> I notice in RFC 5915 (EC Private Keys) there is language to try and mitigate incompatibilities by suggesting the public key SHOULD always be in the ECPrivateKey, and then if it is not it can just be recomputed if it was needed.   I don't know if it is possible to recompute dilithium public keys from private keys, if it is possible, then I suppose something similar could be explained.   In any case, I just think an expanded explanation for that optional field and language to try and mitigate incompatibility between implementations should be considered.   Since I have already come across this exact incompatibility in practice, it isn't just hypothetical.   I could send samples of this incompatibility as well if that is helpful...  😊 

It was a long time ago, but I think that the SHOULD was intended to reflect environments where the private key is locally generated and never sent to any other places.

> 
> From 5915: 
> publicKey contains the elliptic curve public key associated with
>      the private key in question.  The format of the public key is
>      specified in Section 2.2 of [RFC5480].  Though the ASN.1 indicates
>      publicKey is OPTIONAL, implementations that conform to this
>      document SHOULD always include the publicKey field.  The publicKey
>      field can be omitted when the public key has been distributed via
>      another mechanism, which is beyond the scope of this document.
>      Given the private key and the parameters, the public key can
>      always be recomputed; this field exists as a convenience to the
>      consumer.

Right, if one has the private key, it can compute the public key from it.  This is another example of the size tradeoff.

Russ