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

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 <lijun.liao@gmail.com>
Gesendet: Freitag, 18. Juni 2021 09:14
An: Brockhaus, Hendrik (T RDA CST SEA-DE) <hendrik.brockhaus@siemens.com>
Betreff: Re: [lamps] [CMP Updates] Hash algorithm to us for calculating certHash

Fine for me.

Brockhaus, Hendrik <hendrik.brockhaus@siemens.com<mailto:hendrik.brockhaus@siemens.com>> schrieb am Fr., 18. Juni 2021, 08:55:

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:

     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

     }

Proposed new Syntax:

   CertStatus ::= SEQUENCE {

      hashAlg [0] AlgorithmIdentifier OPTIONAL,

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

       -- to match this confirmation with the corresponding req/rep

       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 <housley@vigilsec.com<mailto:housley@vigilsec.com>>
Gesendet: Dienstag, 15. Juni 2021 17:14
An: David von Oheimb <nl0@von-Oheimb.de<mailto:nl0@von-Oheimb.de>>
Cc: Lijun Liao <lijun.liao@gmail.com<mailto:lijun.liao@gmail.com>>; LAMPS WG <spasm@ietf.org<mailto:spasm@ietf.org>>; Brockhaus, Hendrik (T RDA CST SEA-DE) <hendrik.brockhaus@siemens.com<mailto:hendrik.brockhaus@siemens.com>>; von Oheimb, David (T RDA CST SEA-DE) <david.von.oheimb@siemens.com<mailto:david.von.oheimb@siemens.com>>
Betreff: Re: [lamps] [CMP Updates] Hash algorithm to us for calculating certHash

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 <nl0@von-Oheimb.de<mailto:nl0@von-Oheimb.de>> 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 <spasm-bounces@ietf.org><mailto: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><mailto: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<mailto: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<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

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<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%7Cbcc6e177123949512a8908d93228ac99%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637595972536980556%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xBz6CR316E%2FYAJcnJ29txSQpDbPL402iqfaOizH0m1A%3D&reserved=0>