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

[David von Oheimb <[e-mail]>]

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 <[e-mail]>
*Gesendet:* Freitag, 18. Juni 2021 09:14
*An:* Brockhaus, Hendrik (T RDA CST SEA-DE) <[e-mail]>
*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
> <[e-mail] <mailto:[e-mail]>>
> wrote:
>>
>> 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
>>