[lamps] Fwd: [CMP Updates] Hash algorithm to us for calculating certHash

[David von Oheimb <[e-mail]>]

Russ, what do you think, also on Lijun's response quoted here?


-------- Forwarded Message --------
Subject: 	Re: [lamps] [CMP Updates] Hash algorithm to us for calculating
certHash
Date: 	Tue, 15 Jun 2021 13:17:58 +0200
From: 	Lijun Liao <[e-mail]>
To: 	David von Oheimb <[e-mail]>



I am fine with the ASN.1 discussed in this email thread.

Since the upgrade to CMPv3
will take much longer than the use of EdDSA, I prefer to fix the hash
algorithm for EdDSA if it is not specified explicitly. This allows the
use of EdDSA in CMPv2.

Lijun

David von Oheimb <[e-mail] <mailto:[e-mail]>> schrieb
am Di., 15. Juni 2021, 12:30:

    Yes, in case a certConf message is expected by the server and the
    client needs to positively conform a newly enrolled EdDSA cert, I
    think this cannot be avoided
    because the assumption of CMPv2 that a cert signature alg
    automatically implies/includes a cert hash alg does not hold anymore
    for EdDSA.
    So the client needs to specify which hash alg it uses, since for
    EdDSA in general (except for CMS) there is no clear/mandatory
    implicit hash alg defined.

        David

    On 15.06.21 12:18, Lijun Liao wrote:
>     Does this mean we need CMPv3 for the EdDSA certificates? 
>
>     Lijun
>
>     David von Oheimb <[e-mail] <mailto:[e-mail]>>
>     schrieb am Di., 15. Juni 2021, 12:00:
>
>         Russ, Lijun, et al.,
>
>         we have not yet heard back on our latest proposal how to
>         determine the hash alg to use for the certHash field in CMP
>         certConf messages.
>         Would be good to finalize this topic by the end of this week
>         in order to bring it into the next version of the CMP-related
>         drafts.
>
>         To summarize, our proposal is to add a hashAlg field to the
>         CertStatus structure as follows, which is binary backward
>         compatible:
>
>            CertStatus ::= SEQUENCE {
>
>               hashAlg [0] AlgorithmIdentifier OPTIONAL,
>
>               certHash    OCTET STRING,
>
>               certReqId   INTEGER,
>
>               statusInfo  PKIStatusInfo OPTIONAL
>
>            }
>
>         In case the signature alg identifier of the cert explicitly
>         contains a hash alg (which so far always was the case until
>         EdDSA came up),
>         then use that hash alg and the optional hashAlg field MUST be
>         omitted, which means the certConf message can keep version CMPv2.
>         Otherwise, the hashAlg field MUST be used to specify the hash
>         alg used and the version of the certConf message is CMPv3.
>         (In addition, we gonna specify in the CMP- Algorithms draft
>         that  SHA-512 SHALL be used for Ed25519 and SHAKE256 for Ed448,
>         like done for CMS in RFC8419).
>
>         Does this sound fine?
>
>             David
>
>