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

From: David von Oheimb <[email-masked]>
Date: Tue, 15 Jun 2021 13:48:52 +0200

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 <[email-masked]>
To: 	David von Oheimb <[email-masked]>

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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>>
>     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
>
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 15 Jun 2021 11:11:21 -0400

David:

I thought that some people were concerned that it was unclear what hash to use in with EdDSA in CMPv2.  I thout that wat the question the opened this can of worm in the first place.

Russ

> On Jun 15, 2021, at 7:48 AM, David von Oheimb <[email-masked]> wrote:
> 
> Subject:	Re: [lamps] [CMP Updates] Hash algorithm to us for calculating certHash
> From:	Lijun Liao <[email-masked]> <mailto:[email-masked]>
> To:	David von Oheimb <[email-masked]> <mailto:[email-masked]>
> 
> 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 <[email-masked] <mailto:[email-masked]>> 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
> 
>> David von Oheimb <[email-masked] <mailto:[email-masked]>> 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:
>> 
>> 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, 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm