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

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Tue, 8 Jun 2021 15:19:52 +0000

In OpenSSL recently a problem has been identified on how to derive a hash algorithm from signatureAlgorithm OID when using EdDSA, see https://github.com/openssl/openssl/issues/15477

In CMP this implicitly defined hash algorithms is used to calculate the certHash in a certConf messages. This would fail when using EdDSA.
The CertStatus structure including certHash is defined as follows:
     CertStatus ::= SEQUENCE {
        certHash    OCTET STRING,
        -- the hash of the certificate, using the same hash algorithm
        -- as is used to create and verify the certificate signature
        certReqId   INTEGER,
        -- to match this confirmation with the corresponding req/rep
        statusInfo  PKIStatusInfo OPTIONAL
     }
 
Therefore, the hash algorithms to be used for computing the certHash must be determined in some other way.
I currently see the following options:
(1) Specify usage of SHA-1 for calculating certHash, similar to the definition of the keyIdentifier in RFC 5280 Section 4.2.1.2.
  This is the cheapest solution, but we explicitly removed SHA-1 from CMP Algorithms, see mail thread "Re: CMP Algorithms I-D".
(2) Specify a hash algorithm on a per signature algorithm basis.
   This is also quite simple to implement, but costly to maintain for upcoming algorithms.
(3) Extend the ASN.1 syntax of CertStatus to allow to specify an optional hashAlg OID for those cases where the hash algorithm cannot be determined automatically.
   This is probably the cleanest solution, but involves a change to the ASN.1 syntax.
 
Does anyone sees other, better solutions?
What solution is preferred by the WG?

- Hendrik

---

From: Lijun Liao <[email-masked]>
Date: Tue, 8 Jun 2021 17:42:06 +0200

I prefer to use SHA-512 for Ed25519 and SHAKE256(x, 64) for Ed448, as in
RFC8419:

2.3 <https://datatracker.ietf.org/doc/html/rfc8419#section-2.3>.
Message Digest Algorithm Identifiers

   When the signer includes signed attributes, a message digest
   algorithm is used to compute the message digest on the eContent
   value.  When signing with Ed25519, the message digest algorithm MUST
   be SHA-512 [FIPS180
<https://datatracker.ietf.org/doc/html/rfc8419#ref-FIPS180>].
Additional information on SHA-512 is available
   in [RFC6234 <https://datatracker.ietf.org/doc/html/rfc6234>].  When
signing with Ed448, the message digest algorithm
   MUST be SHAKE256 [FIPS202
<https://datatracker.ietf.org/doc/html/rfc8419#ref-FIPS202>] with a
512-bit output value.

On Tue, Jun 8, 2021 at 5:20 PM Brockhaus, Hendrik <
[email-masked]> wrote:

> In OpenSSL recently a problem has been identified on how to derive a hash
> algorithm from signatureAlgorithm OID when using EdDSA, see
> https://github.com/openssl/openssl/issues/15477
>
> In CMP this implicitly defined hash algorithms is used to calculate the
> certHash in a certConf messages. This would fail when using EdDSA.
> (1) Specify usage of SHA-1 for calculating certHash, similar to the
> definition of the keyIdentifier in RFC 5280 Section 4.2.1.2.
>   This is the cheapest solution, but we explicitly removed SHA-1 from CMP
> Algorithms, see mail thread "Re: CMP Algorithms I-D".
> (3) Extend the ASN.1 syntax of CertStatus to allow to specify an optional
> hashAlg OID for those cases where the hash algorithm cannot be determined
> automatically.
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

-- 
Lijun Liao

---

From: Russ Housley <[email-masked]>
Date: Tue, 8 Jun 2021 11:53:39 -0400

The 3rd choice seems to be the most future proof.  You can add something like:

CertStatus ::= SEQUENCE {
   hashFunc [0] AlgorithmIdentifier DEFAULT sha256Identifier,
   ...

That said, this would introduce another place where the CMP protocol version comes into play with the ASN.1 parsing.

Russ

> On Jun 8, 2021, at 11:19 AM, Brockhaus, Hendrik <[email-masked]> wrote:
>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Tue, 8 Jun 2021 16:03:54 +0000

Thanks Liao for pointing me to this section. This would solve the issue for EdDSA. But a similar solution would be needed for upcoming signature algorithms having the same issue.
Using solution (3), like Russ proposes, one could of explicitly specify these hashAlgs. This could as well be mentioned somewhere in CMP Algorithms.
What do you think?

Hendrik

Von: Lijun Liao <[email-masked]>
Gesendet: Dienstag, 8. Juni 2021 17:42
An: Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>
Cc: LAMPS WG <[email-masked]>; von Oheimb, David (T RDA CST SEA-DE) <[email-masked]>
Betreff: Re: [lamps] [CMP Updates] Hash algorithm to us for calculating certHash

I prefer to use SHA-512 for Ed25519 and SHAKE256(x, 64) for Ed448, as in RFC8419:

2.3<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8419%23section-2.3&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cb7df84886b3840ccf54b08d92a9400b5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637587638146409426%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Y627fZeD%2BEQVX5f5qy4X%2BU0vQl0NLO329E%2Beqx0p0t4%3D&reserved=0>.  Message Digest Algorithm Identifiers

   be SHA-512 [FIPS180<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8419%23ref-FIPS180&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cb7df84886b3840ccf54b08d92a9400b5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637587638146409426%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mnWxww79bLA1LOJcUAjuU72ofBd1SpZ%2FMPQngC2olgY%3D&reserved=0>].  Additional information on SHA-512 is available

   in [RFC6234<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc6234&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cb7df84886b3840ccf54b08d92a9400b5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637587638146419422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6Z%2BYO8Z9WHBqo%2Flf2ptpZafEV9cp8nKdYFLebB1yo50%3D&reserved=0>].  When signing with Ed448, the message digest algorithm

   MUST be SHAKE256 [FIPS202<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8419%23ref-FIPS202&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cb7df84886b3840ccf54b08d92a9400b5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637587638146419422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ATwZyWcQVZQSlPAxY4U8sdOWFmRRQXivUtjTT%2BuOjjA%3D&reserved=0>] with a 512-bit output value.

On Tue, Jun 8, 2021 at 5:20 PM Brockhaus, Hendrik <[email-masked]<mailto:[email-masked]>> wrote:
In OpenSSL recently a problem has been identified on how to derive a hash algorithm from signatureAlgorithm OID when using EdDSA, see https://github.com/openssl/openssl/issues/15477<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenssl%2Fopenssl%2Fissues%2F15477&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cb7df84886b3840ccf54b08d92a9400b5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637587638146429413%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=weix2JOonIy8FvoHb0rF8jZIsQPDMSd7ZOJiG8LXkXA%3D&reserved=0>

- Hendrik

_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cb7df84886b3840ccf54b08d92a9400b5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637587638146429413%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gfBHS7RQse%2BFFf4Z2k75gy8Ywr%2FLc9xf%2FlwtT4IUUr8%3D&reserved=0>

--
Lijun Liao

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Tue, 8 Jun 2021 16:07:24 +0000

David an I also thought of this solution.
If hashFunc is not used, will it be backward compatible with the current syntax, due to the tagging?

Hendrik

> -----Ursprüngliche Nachricht-----
> Von: Russ Housley <[email-masked]>
> Gesendet: Dienstag, 8. Juni 2021 17:54
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> m%2Fopenssl%2Fopenssl%2Fissues%2F15477&amp;data=04%7C01%7Chendrik.
> brockhaus%40siemens.com%7Cb42615faad7148e5c72a08d92a959af3%7C38ae
> 3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637587644304574885%7CUnk
> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
> aWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=huwpvD%2FmhG69ELrYfhgq48B7
> txllaBmseogq3%2BrIbLs%3D&amp;reserved=0
> >
> > In CMP this implicitly defined hash algorithms is used to calculate the certHash
> in a certConf messages. This would fail when using EdDSA.
> > (1) Specify usage of SHA-1 for calculating certHash, similar to the definition of
> the keyIdentifier in RFC 5280 Section 4.2.1.2.
> 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%7Cb42615faad7148e5c72a08d92a959af3%7C38ae3bcd957
> 94fd4addab42e1495d55a%7C1%7C0%7C637587644304574885%7CUnknown%7
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> XVCI6Mn0%3D%7C1000&amp;sdata=7IIE0jKvlS%2B81cW1eqEn6Rr%2BnYi0i7o5
> NAkwWs3coY4%3D&amp;reserved=0

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 9 Jun 2021 16:01:42 +0000

Russ

Thank you for this suggestion. In the meantime, David tested the backward compatibility of this approach. It works fine.

>    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.
 
> 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

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 11 Jun 2021 13:21:55 +0000

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 <[email-masked]> 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.
> 
> 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.
> 
> 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.
> 
> 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).
> us%40siemens.com%7C8a0703abedbe44504c8d08d92b5fec60%7C38ae3bcd957
> 94fd4addab42e1495d55a%7C1%7C0%7C637588513262560559%7CUnknown%7
> XVCI6Mn0%3D%7C1000&amp;sdata=PTvMzW780CJ3gNrZVhPiRZX%2BwzA7LXIo
> LQcLQkgJk%2Bk%3D&amp;reserved=0

---

From: David von Oheimb <[email-masked]>
Date: Tue, 15 Jun 2021 12:00:07 +0200

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:

      certHash    OCTET STRING,

      certReqId   INTEGER,

   }

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:14:06 -0400

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 <[email-masked]> 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:
> 
> 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, 
>>> Von: Spasm <[email-masked]> <mailto:[email-masked]> Im Auftrag von Brockhaus, Hendrik
>>> 
>>> Russ
>>> 
>>>> Von: Russ Housley <[email-masked]> <mailto:[email-masked]>
>>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>
>>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 18 Jun 2021 06:55:53 +0000

Thanks Russ and Lijun for your feedback.

Trying to address Lijun's concerns and still keeping full crypto agility we could also do the following:

Old Syntax as of RFC 4210:

        certHash    OCTET STRING,

        certReqId   INTEGER,

     }

Proposed new Syntax:

      -- the hash algorithm to use for calculating certHash

      -- MUST be present if the hash algorithm to use is neither implied by the AlgorithmIdentifier of the certificate signature nor by other standards like [CMP Algorithms]

      -- SHOULD be present only if this field is supported on client and server side and MUST be indicated by using cmp2021(3)

       certHash    OCTET STRING,

      -- the hash of the certificate to be confirmed

      -- if hashAlg is present, the given hash algorithm MUST be used

      -- if hashAlg is not present, the hash algorithm implied by the AlgorithmIdentifier of the certificate signature or by other standards like [CMP Algorithms] MUST be used

       certReqId   INTEGER,

       statusInfo  PKIStatusInfo OPTIONAL }

Would this help to be as backward compatible and as crypto agile as possible.

What do you think?

Hendrik

Von: Russ Housley <[email-masked]>
Gesendet: Dienstag, 15. Juni 2021 17:14
An: David von Oheimb <[email-masked]>
Cc: Lijun Liao <[email-masked]>; LAMPS WG <[email-masked]>; Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>; von Oheimb, David (T RDA CST SEA-DE) <[email-masked]>
Betreff: Re: [lamps] [CMP Updates] Hash algorithm to us for calculating certHash

David:

Russ

On Jun 15, 2021, at 6:00 AM, David von Oheimb <[email-masked]<mailto:[email-masked]>> wrote:

Russ, Lijun, et al.,

      certHash    OCTET STRING,

      certReqId   INTEGER,

   }

Hendrik

Von: Spasm <[email-masked]><mailto:[email-masked]> Im Auftrag von Brockhaus, Hendrik

Russ

Von: Russ Housley <[email-masked]><mailto:[email-masked]>

The 3rd choice seems to be the most future proof.  You can add something

like:

   ...

This was the solution David and I discussed as well. But we called the field

hashAlg, like in OOBCertHash.

CMP Algorithms.

To introduce the hashAlg field, we propose to add the following section to CMP

Updates:

---------------------------snip---------------------------

      certHash    OCTET STRING,

      certReqId   INTEGER,

   }

---------------------------snip---------------------------

Hendrik

Spasm mailing list

us%40siemens.com<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40siemens.com%2F&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ce1783822e46b46c9adfb08d930103e1e%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637593668582071924%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=S3h7Tv55%2Bnn90ytEd4BfxrlbzHRDnWrNZ2uVvozcTzs%3D&reserved=0>%7C8a0703abedbe44504c8d08d92b5fec60%7C38ae3bcd957

Spasm mailing list

https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ce1783822e46b46c9adfb08d930103e1e%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637593668582081915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DVxMQedBsxAQ2EvJiEigZ9bziuvCF5wOjfWJu5u6344%3D&reserved=0>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 18 Jun 2021 08:52:04 +0000

Thanks Lijun for you feedback.
I would also change CMP Algorithms Section 3.3 to make it clear which hash algorithms to use with CMP.

Current text:
Specific conventions to be considered are specified in RFC 8419 [RFC8419].

New text:
Specific conventions to be considered are specified in RFC 8419 [RFC8419]. The hash algorithm used to calculate the certHash in certConf messages MUST be SHA512 if the certificate is signed using Ed25519 and SHAKE256 if signed using Ed448.

Hendrik

Von: Lijun Liao <[email-masked]>
Gesendet: Freitag, 18. Juni 2021 09:14
An: Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>
Betreff: Re: [lamps] [CMP Updates] Hash algorithm to us for calculating certHash

Fine for me.

Brockhaus, Hendrik <[email-masked]<mailto:[email-masked]>> schrieb am Fr., 18. Juni 2021, 08:55:

        certHash    OCTET STRING,

        certReqId   INTEGER,

     }

Proposed new Syntax:

       certHash    OCTET STRING,

       certReqId   INTEGER,

What do you think?

Hendrik

Von: Russ Housley <[email-masked]<mailto:[email-masked]>>
Gesendet: Dienstag, 15. Juni 2021 17:14
An: David von Oheimb <[email-masked]<mailto:[email-masked]>>
Cc: Lijun Liao <[email-masked]<mailto:[email-masked]>>; LAMPS WG <[email-masked]<mailto:[email-masked]>>; Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]<mailto:[email-masked]>>; von Oheimb, David (T RDA CST SEA-DE) <[email-masked]<mailto:[email-masked]>>
Betreff: Re: [lamps] [CMP Updates] Hash algorithm to us for calculating certHash

David:

Russ

Russ, Lijun, et al.,

      certHash    OCTET STRING,

      certReqId   INTEGER,

   }

Hendrik

Russ

like:

   ...

CMP Algorithms.

Updates:

---------------------------snip---------------------------

      certHash    OCTET STRING,

      certReqId   INTEGER,

   }

---------------------------snip---------------------------

Hendrik

Spasm mailing list

us%40siemens.com<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40siemens.com%2F&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cbcc6e177123949512a8908d93228ac99%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637595972536970561%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ftxARzek3QgghAeelIjUb6mi91nSim8yXM8%2Bv5xLwn0%3D&reserved=0>%7C8a0703abedbe44504c8d08d92b5fec60%7C38ae3bcd957

Spasm mailing list

https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cbcc6e177123949512a8908d93228ac99%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637595972536980556%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xBz6CR316E%2FYAJcnJ29txSQpDbPL402iqfaOizH0m1A%3D&reserved=0>

---

From: Russ Housley <[email-masked]>
Date: Fri, 18 Jun 2021 12:59:36 -0400

Hendrik:

This seems fine to me, but the text that goes with it needs to say that you must use CMPv3 in order to include the optional hashAlg.

Russ

> On Jun 18, 2021, at 2:55 AM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> Von: Russ Housley <[email-masked] <mailto:[email-masked]>> 
> An: David von Oheimb <[email-masked] <mailto:[email-masked]>>
> Cc: Lijun Liao <[email-masked] <mailto:[email-masked]>>; LAMPS WG <[email-masked] <mailto:[email-masked]>>; Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked] <mailto:[email-masked]>>; von Oheimb, David (T RDA CST SEA-DE) <[email-masked] <mailto:[email-masked]>>
> On Jun 15, 2021, at 6:00 AM, David von Oheimb <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Russ, Lijun, et al.,
> 
> us%40siemens.com <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40siemens.com%2F&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ce1783822e46b46c9adfb08d930103e1e%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637593668582071924%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=S3h7Tv55%2Bnn90ytEd4BfxrlbzHRDnWrNZ2uVvozcTzs%3D&reserved=0>%7C8a0703abedbe44504c8d08d92b5fec60%7C38ae3bcd957
> https://www.ietf.org/mailman/listinfo/spasm <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ce1783822e46b46c9adfb08d930103e1e%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637593668582081915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DVxMQedBsxAQ2EvJiEigZ9bziuvCF5wOjfWJu5u6344%3D&reserved=0>
>  
>

---

From: David von Oheimb <[email-masked]>
Date: Fri, 18 Jun 2021 20:55:28 +0200

Russ and Lijun,

pleased to hear.

On 18.06.21 18:59, Russ Housley wrote:
> This seems fine to me, but the text that goes with it needs to say
> that you must use CMPv3 in order to include the optional hashAlg.

Sure - this is what we meant by: "SHOULD be present only if this field
is supported on client and server side and MUST be indicated by using
cmp2021(3)"

We are also going to specify in the section on version negotiation:

If a client is supposed to send a certConf message containing the
hashAlg field
the client MUST choose the version for the message as follows:
* If the client supports cmp2021 it MUST use cmp2021 in the certConf
message.
* If the client does not support cmp2021 it MUST reject the certificate.

    David

*Von:* Lijun Liao <[email-masked]>
*Gesendet:* Freitag, 18. Juni 2021 09:14
*An:* Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>
*Betreff:* Re: [lamps] [CMP Updates] Hash algorithm to us for
calculating certHash

Fine for me.

> On Jun 18, 2021, at 2:55 AM, Brockhaus, Hendrik
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>>
>>       -- MUST be present if the hash algorithm to use is neither
>> implied by the AlgorithmIdentifier of the certificate signature nor
>> by other standards like [CMP Algorithms]
>>       -- SHOULD be present only if this field is supported on client
>> and server side and MUST be indicated by using cmp2021(3)
>>        certHash    OCTET STRING,
>>       -- if hashAlg is not present, the hash algorithm implied by the
>> AlgorithmIdentifier of the certificate signature or by other
>> standards like [CMP Algorithms] MUST be used
>>        certReqId   INTEGER,