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

[Russ Housley <[e-mail]>]

David:

I think this means that any new signature mechanisms need to say what the default hash for use with CMP will be.

Russ


> On Jun 15, 2021, at 6:00 AM, David von Oheimb <[e-mail]> wrote:
> 
> 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
> 
> On 11.06.21 15:21, Brockhaus, Hendrik wrote:
>> If there is any further feedback to this from the WG, please let me know.
>> If not, I would include the section into the draft and submit an updated version.
>> 
>> Hendrik
>> 
>>> Von: Spasm <[e-mail]> <mailto:[e-mail]> Im Auftrag von Brockhaus, Hendrik
>>> 
>>> Russ
>>> 
>>> Thank you for this suggestion. In the meantime, David tested the backward
>>> compatibility of this approach. It works fine.
>>> 
>>>> Von: Russ Housley <[e-mail]> <mailto:[e-mail]>
>>>> 
>>>> The 3rd choice seems to be the most future proof.  You can add something
>>> like:
>>>> CertStatus ::= SEQUENCE {
>>>>    hashFunc [0] AlgorithmIdentifier DEFAULT sha256Identifier,
>>>>    ...
>>> This was the solution David and I discussed as well. But we called the field
>>> hashAlg, like in OOBCertHash.
>>> We feel the DEFAULT is in conflict with the CMP V2, that determines the hash
>>> algorithm from the signatureAlgorithm field of the certificate to be confirmed.
>>> We also tried to prevent to specify fixed algorithms in CMP to be crypto agile
>>> and prevent future updates. Therefore, we propose not to use the DEFAULT.
>>> @Liao, using this approach, you would need to specify SHA-512 for certificate
>>> signed with Ed25519 and SHAKE256 for Ed448. I would add a note on this to
>>> CMP Algorithms.
>>> 
>>>> That said, this would introduce another place where the CMP protocol
>>>> version comes into play with the ASN.1 parsing.
>>> You are absolutely right.
>>> 
>>> 
>>> To introduce the hashAlg field, we propose to add the following section to CMP
>>> Updates:
>>> 
>>> ---------------------------snip---------------------------
>>> 2.10.  Update Section 5.3.18. - Certificate Confirmation Content
>>> 
>>> This section introduces an optional hashAlg field to the CertStatus type used in
>>> certConf messages to explicitly specify the hash algorithm for those certificates
>>> where no hash algorithm is specified in the signatureAlgorithm field.
>>> 
>>> Replace the ASN.1 Syntax of CertStatus with the following text:
>>> 
>>>    CertStatus ::= SEQUENCE {
>>>       hashAlg [0] AlgorithmIdentifier OPTIONAL,
>>>       certHash    OCTET STRING,
>>>       certReqId   INTEGER,
>>>       statusInfo  PKIStatusInfo OPTIONAL
>>>    }
>>> 
>>> The hashAlg field SHOULD be used only in exceptional cases where the
>>> signatureAlgorithm of the certificate to be confirmed does not specify a hash
>>> algorithm, neither in the OID nor in the parameters. In such cases, e.g., for
>>> EdDSA, the hashAlg MUST be used to specify the hash algorithm to be used for
>>> calculating the certHash value. Otherwise, the certHash value SHALL be
>>> computed using the same hash algorithm as used to create and verify the
>>> certificate signature. If hashAlg is used, the CMP version indicated by the
>>> certConf message header must be cmp2021(3).
>>> ---------------------------snip---------------------------
>>> 
>>> Any comments and feedback on this proposal from the WG is welcome!
>>> 
>>> Hendrik
>>> 
>>> _______________________________________________
>>> Spasm mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf>
>>> .org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Chendrik.brockha
>>> us%40siemens.com%7C8a0703abedbe44504c8d08d92b5fec60%7C38ae3bcd957
>>> 94fd4addab42e1495d55a%7C1%7C0%7C637588513262560559%7CUnknown%7
>>> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
>>> XVCI6Mn0%3D%7C1000&amp;sdata=PTvMzW780CJ3gNrZVhPiRZX%2BwzA7LXIo
>>> LQcLQkgJk%2Bk%3D&amp;reserved=0
>> _______________________________________________
>> Spasm mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>
>>