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

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 <lijun.liao@gmail.com>
Gesendet: Dienstag, 8. Juni 2021 17:42
An: Brockhaus, Hendrik (T RDA CST SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: LAMPS WG <spasm@ietf.org>; von Oheimb, David (T RDA CST SEA-DE) <david.von.oheimb@siemens.com>
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

   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://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 <hendrik.brockhaus@siemens.com<mailto:hendrik.brockhaus@siemens.com>> 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>

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

_______________________________________________
Spasm mailing list
Spasm@ietf.org<mailto:Spasm@ietf.org>
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