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

["Massimo, Jake" <[e-mail]>]

Hi John, Uri, Russ, Corey,

Thank you for feedback so far, it is greatly appreciated.

    > 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

I'm glad to hear this. Yes, this is an intentional design decision, the OID should tell you all you need to know.

    > In regards to wrapping the public key in an OCTET_STRING:...

Thank you for kicking off this discussion, I was hoping for feedback in this regard, as I toyed with the historical precedent set by other standards. I'll keep tracking the ongoing discussion in this thread and make changes accordingly. I'll check out RFC 8017 for RSAPublicKey as Russ mentioned.

    > In regards to the Private Key format, I notice you have placed an option to contain the PublicKey inside the private key.  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.   

This raises a good point. Yes I was trying to align with other private key formats, but as you say, with the larger sizes of PQ keys it may further escalate the issues surrounding the large increase in key sizes across all PQ algorithms.

   > In section 5, you have this sentence:...

You are correct, this is an error I will fix accordingly - good spot!

Thanks again for the feedback so far,
Jake


---------

On 10/07/2022, 17:19, "Spasm on behalf of John Gray" <[e-mail] on behalf of John.Gray=[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.

    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