[lamps] [CMP Updates] position of hashAlg in certStatus

["Brockhaus, Hendrik" <[e-mail]>]

Russ

Currently we receive valuable feedback from John Gray on the CMP Updates draft.

One proposal from John is on moving the hashAlg field in the certStatus sequence from the first to the last position. Please see his arguments in this email tread below.

Current syntax:

   CertStatus ::= SEQUENCE {

      hashAlg [0] AlgorithmIdentifier OPTIONAL

      certHash    OCTET STRING,

      certReqId   INTEGER,

      statusInfo  PKIStatusInfo OPTIONAL,

   }

Johns proposal:

   CertStatus ::= SEQUENCE {

      certHash    OCTET STRING,

      certReqId   INTEGER,

      statusInfo  PKIStatusInfo OPTIONAL,

      hashAlg [0] AlgorithmIdentifier OPTIONAL

   }

Davids proposal:

   CertStatus ::= SEQUENCE {

      certHash    OCTET STRING,

      certReqId   INTEGER,

      statusInfo  PKIStatusInfo OPTIONAL,

      hashAlg     AlgorithmIdentifier OPTIONAL

   }

We are uncertain what the best approach from an ASN.1 syntax parsing perspective is. What is your opinion?

Hendrik


Von: Brockhaus, Hendrik (T RDA CST SEA-DE)
Gesendet: Dienstag, 31. August 2021 14:07
An: John Gray <[e-mail]>

Von: David von Oheimb <[e-mail]<mailto:[e-mail]>>
Gesendet: Donnerstag, 26. August 2021 22:43
An: John Gray <[e-mail]<mailto:[e-mail]>>

On 26.08.21 11:26, Brockhaus, Hendrik (T RDA CST SEA-DE) wrote:

Von: John Gray <[e-mail]><mailto:[e-mail]>
Gesendet: Mittwoch, 25. August 2021 18:35
An: von Oheimb, David (T RDA CST SEA-DE) <[e-mail]><mailto:[e-mail]>; Brockhaus, Hendrik (T RDA CST SEA-DE) <[e-mail]><mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; Kretschmer, Andreas (T RDA CST SEA-DE) <[e-mail]><mailto:[e-mail]>
Betreff: RE: [EXTERNAL] Re: CMP Updates and Lightweight CMP Profile

Thanks for the updates.

I continued to review the document today as well.   Here are some more comments:

Section 2.10 -  CertStatus update.  I was wondering if adding the optional tagged element as the last element *might* make a difference:

For now it is defined as:

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
      }


I would have expected that adding something new would be added like this:


Replace the ASN.1 Syntax of CertStatus with the following text:



      CertStatus ::= SEQUENCE {

         certHash    OCTET STRING,

         certReqId   INTEGER,

         statusInfo  PKIStatusInfo OPTIONAL,

         hashAlg [0] AlgorithmIdentifier OPTIONAL

      }

If a CMPv2 server received the hashAlg as the last element, it might still work, but would fail in the first case.   However, I know you say if the hashAlg is included then it must use the pvno of version 3, so the order doesn’t really matter.   I just thought that for someone implementing it, it might be a bit easier to check if the tag exists after the existing parsing (at the end), rather than checking if it exists on the first element.  It would mean no parsing logic has to change until it reaches the last element.   However, I suppose the counter argument would be that if hashAlg is included first, but it isn’t supported then an older server would fail faster which is probably a desirable property.

[Bro] This is a interesting point we also thought about. Here are some thoughts we had.
First of all, we think the binary ASN.1 of a certConf message produced by a client only knowing the original cmp2000 without hashAlg does not differ between from a client knowing the hashAlg field, but not using it.
This should be the case when placing the hashAlg field at the first as well as at the last position of the sequence.
Second, we took the OOBCertHash type as an example and therefore decided for placing the hashAlg field also at the first position.
        OOBCertHash ::= SEQUENCE {
            hashAlg     [0] AlgorithmIdentifier     OPTIONAL,
            certId      [1] CertId                  OPTIONAL,
            hashVal         BIT STRING
        }
Third, the hash algorithm OID is required before calculating the hash value. Therefore, it is the logical order to have hashAlg first.
Theses were the thoughts we had for placing hashAlg in the first position, but they are no strict reasons to do it this way round.
I cannot say, if your arguments still hold true from an implementation perspective. @David, maybe you can comment on the more implementation related issues.

I am not an ASN.1 expert, but as far as I understand from using its OpenSSL implementation, it should not make much difference whether to fail earlier or later in case the bits do not fit with the expected structure.
At least for the CMP implementation, which simply uses the ASN.1 parser, there would be no noticeable difference since either the parsing of the whole structure (including its total sequence length) succeeds or not.
If a receiver expects a structure encoded as in CMPv2 but gets an encoding for CMPv3, I think due to the presence of the "[0]" tag, parsing will fail even if the hashAlg fields is at the end with not value being present.
A backward-compatible definition might look like this:

      CertStatus ::= SEQUENCE {

         certHash    OCTET STRING,

         certReqId   INTEGER,

         statusInfo  PKIStatusInfo OPTIONAL,

         hashAlg     AlgorithmIdentifier OPTIONAL

      }

but supposedly we cannot do this because it would be ambiguous whether the optional statusInfo or hashAlg field is present.
To me, the main point is a conceptual one: the hashAlg needs to "seen" before the certHash, so it is logical to have them in this order.

[Bro] I am also no ASN.1 expert, but Russ is. Therefore, I will forward the question to him to get his advice. As statusInfo and hashAlg have different types, it may also work without tagging.