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

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 <spasm-bounces@ietf.org> 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 <housley@vigilsec.com>
>>>
>>> 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
>> Spasm@ietf.org
>> 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
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>