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

Thanks Russ,

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... 😊

Here is a Dilithium2 Public Key encoding  using the OCTET STRING encoding which is then encoded 
into the BIT STRING.  This is what I think the current draft is saying how it should be encoded.   

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 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...  😊 

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.

Cheers,

John Gray

-----Original Message-----
From: Russ Housley <housley@vigilsec.com> 
Sent: Monday, July 11, 2022 4:13 PM
To: John Gray <John.Gray@entrust.com>; Uri Blumenthal <uri@ll.mit.edu>; Massimo, Jake <jakemas@amazon.com>
Cc: spasm@ietf.org
Subject: [EXTERNAL] Re: [lamps] New Version Notification for draft-massimo-lamps-pq-sig-certificates-00.txt

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________
John and Uri and Jake:

RFC 5280 does carry the subject public key in a BIT STRING, but that does not mean that each element of the DilithiumPrivateKey SEQUENCE needs to be a BIT STRING.  Quite the opposite.  Please use the most natural structure, and then tell how to encode that structure into a BIT STRING.  Please take a look at RFC 8017 to see how this was done for RSAPublicKey.  I would hope that DilithiumPrivateKey can be done in a manner that has no parameters, even if that means that there are several different OIDs that need to be assigned.

Russ

> On Jul 11, 2022, at 9:06 AM, John Gray <John.Gray=40entrust.com@dmarc.ietf.org> wrote:
> 
> 5280 says that the subjectPublicKey has to be a BIT STRING, so even if we don't like it I don't think we can change the fact that the subjectPublicKey will eventually be held in a BIT STRING.   So wrapping the subjectPublicKey material in OCTET STRING before the final BIT STRING is just an extra layer of wrapping is it not?  I was just wondering if there is a technical reason for having that extra layer?
> 
> SubjectPublicKeyInfo  ::=  SEQUENCE  {
>        algorithm            AlgorithmIdentifier,
>        subjectPublicKey     BIT STRING  }
> 
> I have created Dilithium certificates both ways and both work equally well (encoded the subjectPublicKey BIT STRING with the DilithiumKey encoded as an OCTET STRING), and the DilithiumKey encoded as a BIT STRING.    The second way saves a few bytes is all, but there are no issues I can see other than causing incompatibility between different parsers if one only works with one format or the other.   
> 
> I notice that the PrivateKeyInfo uses OCTET STRING for its key encoding, which is different than the public key.   I would have expected them to be the same, but I guess that is part of history why that happened...   ☹
> 
> PrivateKeyInfo ::= SEQUENCE {
>        version                   Version,
>        privateKeyAlgorithm       PrivateKeyAlgorithmIdentifier,
>        privateKey                PrivateKey,
>        attributes           [0]  IMPLICIT Attributes OPTIONAL }
> 
>      Version ::= INTEGER
> 
>      PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier
> 
>      PrivateKey ::= OCTET STRING
> 
> 
> Cheers,
> 
> John Gray
> 
> 
> -----Original Message-----
> From: Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu>
> Sent: Sunday, July 10, 2022 8:33 PM
> To: John Gray <John.Gray@entrust.com>
> Cc: Massimo, Jake <jakemas@amazon.com>; spasm@ietf.org
> Subject: [EXTERNAL] Re: [lamps] New Version Notification for 
> draft-massimo-lamps-pq-sig-certificates-00.txt
> 
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
> 
> ______________________________________________________________________
> I am strongly against wrapping keys into BIT STRING. 
> 
> This is a relict from the past, originally caused by insufficient experience, and a relict that proved itself useless. 
> 
> Stick with OCTET STRING. 
> 
> Regards,
> Uri
> 
>> On Jul 10, 2022, at 20:19, John Gray <John.Gray=40entrust.com@dmarc.ietf.org> wrote:
>> 
>> Thank you for posting this draft.   It looks very well formed, almost as if you were just waiting for an announcement to be made...  😊
>> 
>> I am glad to see there are no algorithm parameters.   We have already been doing experiments with Dilithium certificates based on the round 3 candidates, and had to pick our own OIDs (due to lack of standard) and chose NOT to use parameters because we didn't know if there would be any.   So it looks like there won't be a lot of changes required to our early non-standard prototype implementations.  😊
>> 
>> That being said, I have a couple of comments:
>> 
>> In regards to wrapping the public key in an OCTET_STRING:
>> 
>> The Dilithium public key MUST be encoded using the ASN.1 type
>>  DilithiumPublicKey:
>> 
>>    DilithiumPublicKey ::= OCTET STRING
>> 
>> In testing interop with other implementations (openSSL with open quantum safe for example), I noticed they DO NOT wrap the DilithiumPublicKey in an OCTET_STRING.   We did that in our initial implementation, but after going through RFC 5280 again, I don't see a specific need to first wrap the DilithiumKey (or in fact any of the other Post Quantum Signature types such as SPHINCS+ or Falcon) in an OCTET_STRING as that OCTET_STRING then gets wrapped into a BIT STRING as per the SubjectPublicKeyInfo.   You actually save 4 bytes without the wrapping....    In any case our current implementation can handle both ways, but it was something I came across and thought I would ask if there was a specific reason why it needed to be wrapped in an OCTET_STRING?
>> 
>> This question underlies why we definitely need a standard...   😊
>> 
>> 
>> In regards to the Private Key format, I notice you have placed an option to contain the PublicKey inside the private key.
>> 
>> DilithiumPrivateKey ::= SEQUENCE {
>>        rho         BIT STRING,         - nonce/seed
>>        K           BIT STRING,         - key/seed
>>        tr          BIT STRING,         - PRF bytes (CRH in spec.)
>>        s1          BIT STRING,         - vector l
>>        s2          BIT STRING,         - vector k
>>        t0          BIT STRING,         - encoded vector
>>        PublicKey   IMPLICIT DilithiumPublicKey OPTIONAL
>>    }
>> 
>> Is this to align with other private key formats like RFC 5915 (Elliptic Curve Private Key)?     With the larger size of these Dilithium keys (and other Post Quantum Keys), I think there would be less appetite for including the public key inside the private key.   If an implementation depends on the public key being there, and it is not there, then I guess it would fail, possibly causing interop issues (I have already come across this with the openSSL - libOQS library as they concatenated the public key in the private key, and our implementation did not).  So I guess with it being optional are you saying implementations MUST accept the key in either format (with the public key included or with no public key included)?
>> 
>> 
>> In section 5, you have this sentence:
>> 
>> Dilithium public keys are
>>  optionally distributed in the publicKey field of the PrivateKeyInfo  
>> structure.
>> 
>> I think you mean:
>> 
>> Dilithium public keys are
>>  optionally distributed in the publicKey field of the 
>> DilithiumPrivateKey  structure.
>> 
>> 
>> The PrivateKeyInfo structure from RFC 5208 does not contain a public key structure:
>> 
>> PrivateKeyInfo ::= SEQUENCE {
>>       version                   Version,
>>       privateKeyAlgorithm       PrivateKeyAlgorithmIdentifier,
>>       privateKey                PrivateKey,
>>       attributes           [0]  IMPLICIT Attributes OPTIONAL }
>> 
>> 
>> Thanks again for putting this draft out so quickly after the NIST announcement!
>> 
>> Cheers,
>> 
>> John Gray
>> Entrust
>> 
>> -----Original Message-----
>> From: Spasm <spasm-bounces@ietf.org> On Behalf Of Massimo, Jake
>> Sent: Friday, July 8, 2022 4:08 PM
>> To: spasm@ietf.org
>> Subject: [EXTERNAL] [lamps] FW: New Version Notification for 
>> draft-massimo-lamps-pq-sig-certificates-00.txt
>> 
>> WARNING: This email originated outside of Entrust.
>> DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
>> 
>> _____________________________________________________________________
>> _
>> Hi!
>> 
>> I'd like to introduce the 00 draft of the I-D we discussed @ IETF 113 (and we will discuss again @ IETF 114) that will document algorithm identifiers and ASN.1 encoding format for NIST's PQC signature algorithms in X.509. As discussed by Sean Turner in the introduction of the I-D draft-turner-lamps-nist-pqc-kem-certificates, we are splitting up the KEMs from the signature algorithms into separate I-Ds. This is the signature algorithm part. We focus on single PQC algorithm rather than hybrid constructions that are covered in other drafts. We are planning to use the algorithm identifiers assigned by NIST. The draft discusses the signature algorithm Dilithium.
>> 
>> If there are any feedback or comments to the draft in advance to the meeting, feel free to contact me.
>> 
>> Cheers,
>> Jake
>> 
>> 
>> On 08/07/2022, 11:37, "internet-drafts@ietf.org" <internet-drafts@ietf.org> wrote:
>> 
>>   CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>> 
>> 
>> 
>>   A new version of I-D, draft-massimo-lamps-pq-sig-certificates-00.txt
>>   has been successfully submitted by Jake Massimo and posted to the
>>   IETF repository.
>> 
>>   Name:           draft-massimo-lamps-pq-sig-certificates
>>   Revision:       00
>>   Title:          Algorithms and Identifiers for Post-Quantum Algorithms
>>   Document date:  2022-07-08
>>   Group:          Individual Submission
>>   Pages:          12
>>   URL:            https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-massimo-lamps-pq-sig-certificates-00.txt__;!!FJ-Y8qCqXTj2!em5Q_A_k1PMQ0W4omwWUauCCeb4EMshOz6mYYWzWzuQkN7W39uZc2n6qACvqm-IoJWr8lOb4JA7PFy5EbwwaOZJYPgTgSdndyJ0lmSg$
>>   Status:         https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-massimo-lamps-pq-sig-certificates/__;!!FJ-Y8qCqXTj2!em5Q_A_k1PMQ0W4omwWUauCCeb4EMshOz6mYYWzWzuQkN7W39uZc2n6qACvqm-IoJWr8lOb4JA7PFy5EbwwaOZJYPgTgSdnd2kZG978$
>>   Html:           https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-massimo-lamps-pq-sig-certificates-00.html__;!!FJ-Y8qCqXTj2!em5Q_A_k1PMQ0W4omwWUauCCeb4EMshOz6mYYWzWzuQkN7W39uZc2n6qACvqm-IoJWr8lOb4JA7PFy5EbwwaOZJYPgTgSdnd7ZiJyGA$
>>   Htmlized:       https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-massimo-lamps-pq-sig-certificates__;!!FJ-Y8qCqXTj2!em5Q_A_k1PMQ0W4omwWUauCCeb4EMshOz6mYYWzWzuQkN7W39uZc2n6qACvqm-IoJWr8lOb4JA7PFy5EbwwaOZJYPgTgSdnd7k9nM9I$
>> 
>> 
>>   Abstract:
>>      Digital signatures are used within X.509 certificates, Certificate
>>      Revocation Lists (CRLs), and to sign messages.  This document
>>      describes the conventions for using Dilithium quantum-resistant
>>      signatures in Internet X.509 certificates and certifiate revocation
>>      lists.  The conventions for the associated post-quantum signatures,
>>      subject public keys, and private key are also described.
>> 
>> 
>> 
>> 
>>   The IETF Secretariat
>> 
>> 
>> 
>> _______________________________________________
>> Spasm mailing list
>> Spasm@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spa
>> sm__;!!FJ-Y8qCqXTj2!em5Q_A_k1PMQ0W4omwWUauCCeb4EMshOz6mYYWzWzuQkN7W39
>> uZc2n6qACvqm-IoJWr8lOb4JA7PFy5EbwwaOZJYPgTgSdnd2gf0i_M$
>> Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
>> _______________________________________________
>> Spasm mailing list
>> Spasm@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spa
>> sm__;!!FJ-Y8qCqXTj2!bpBsAYDumiPJtCWh3ECigcLXWuM5DkdpqSr-zsAO3qtAts9vl
>> fEDfo2nmwmxdE3FNFtlw7AfX9AAK8VBF8Q$
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spas
> m__;!!FJ-Y8qCqXTj2!bpBsAYDumiPJtCWh3ECigcLXWuM5DkdpqSr-zsAO3qtAts9vlfEDfo2nmwmxdE3FNFtlw7AfX9AAK8VBF8Q$