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

[Corey Bonnell <[e-mail]>]

> 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?

If the DER encoding of the OCTET STRING itself were encapsulated in the subjectPublicKey BIT STRING, then there would be a few octets wasted due to the explicit encapsulation. However, some specifications specify a mapping to forego the extra layer of encapsulation:

For example, RFC 5480, section 2.2 says:

" The elliptic curve public key (a value of type ECPoint that is
        an OCTET STRING) is mapped to a subjectPublicKey (a value of
        type BIT STRING) as follows: the most significant bit of the
        OCTET STRING value becomes the most significant bit of the BIT
        STRING value, and so on; the least significant bit of the OCTET
        STRING becomes the least significant bit of the BIT STRING.
        Conversion routines are found in Sections 2.3.1 and 2.3.2 of
        [SEC1]."

Using a mapping convention such as this would allow for OCTET STRING semantics without the overhead of encapsulating the DER-encoded OCTET STRING.

Thanks,
Corey

-----Original Message-----
From: Spasm <[e-mail]> On Behalf Of John Gray
Sent: Monday, July 11, 2022 9:07 AM
To: Blumenthal, Uri - 0553 - MITLL <[e-mail]>
Cc: Massimo, Jake <[e-mail]>; [e-mail]
Subject: Re: [lamps] New Version Notification for draft-massimo-lamps-pq-sig-certificates-00.txt

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 <[e-mail]> 
Sent: Sunday, July 10, 2022 8:33 PM
To: John Gray <[e-mail]>
Cc: Massimo, Jake <[e-mail]>; [e-mail]
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=[e-mail]> 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 <[e-mail]> On Behalf Of Massimo, Jake
> Sent: Friday, July 8, 2022 4:08 PM
> To: [e-mail]
> 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, "[e-mail]" <[e-mail]> 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
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!em5Q_A_k1PMQ0W4omwWUauCCeb4EMshOz6mYYWzWzuQkN7W39uZc2n6qACvqm-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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
_______________________________________________
Spasm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/spasm