Subject: Re: [lamps] [CMP Updates] position of hashAlg in certStatus

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 1 Sep 2021 15:00:25 +0000

Manny thanks for the discussion. It helps a lot to improve the draft.
I see two variants still in the discussion. Both add hashAlg to the current syntax of RFC 4210.
Current syntax in RFC 4210 (CMP v2):

   CertStatus ::= SEQUENCE {

      certHash     OCTET STRING,

      certReqId    INTEGER,

      statusInfo   PKIStatusInfo OPTIONAL,

   }

Proposal 1 (current proposal in draft-ietf-lamps-cmp-updates-12):

   CertStatus ::= SEQUENCE {

      hashAlg [0]  AlgorithmIdentifier OPTIONAL

      certHash     OCTET STRING,

      certReqId    INTEGER,

      statusInfo   PKIStatusInfo OPTIONAL,

   }

Proposal 2 (proposal made by John):

   CertStatus ::= SEQUENCE {

      certHash     OCTET STRING,

      certReqId    INTEGER,

      statusInfo   PKIStatusInfo OPTIONAL,

      hashAlg [0]  AlgorithmIdentifier OPTIONAL

   }

Both proposals should compile and should be bitwise backward compatible when not using hashAlg.
I am happy with both proposals. There still seam to be some preferences for the one or the other proposal.
To come to a conclusion, could all briefly indicate their preferred proposal.

Hendrik

Von: Spasm <[email-masked]> Im Auftrag von Carl Wallace
Gesendet: Dienstag, 31. August 2021 21:10

Thank you. “Current syntax” did not mean current as in v2. That was what I had gotten wrong. You are adding the hashAlg field, not simply moving it (relative to v2). I agree adding it at the end makes the most sense and it needs a tag.

From: David von Oheimb <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 31, 2021 at 2:56 PM
To: Carl Wallace <[email-masked]<mailto:[email-masked]>>, "Blumenthal, Uri - 0553 - MITLL" <[email-masked]<mailto:[email-masked]>>, "Brockhaus, Hendrik" <[email-masked]<mailto:[email-masked]>>, Russ Housley <[email-masked]<mailto:[email-masked]>>, John Gray <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [lamps] [CMP Updates] position of hashAlg in certStatus

Let me clarify at first three things:

  1.  What Hendrik introduced as "David's proposal" was meant by me just as potential a variant of John's proposal, not something that I would actually like to propose.
Anyway interesting to learn from Russ that the fact that two optional sequences after each other already make parsing ambiguous -
I would have hoped that the parser looked deeper: as far as to the first basic (non-sequence) field, where there is more chance that field types/tags are sufficiently different.
  2.  The versions in question are not CMP v1 vs. v3, but v2 vs. v3
  3.  The change from v2 to v3 is not about changing the order of fields, but where to add the new (v3) hashAlg field: at the beginning or at the end.

My preference is the original proposal by Hendrik and me, for two reasons:

  *   It is conceptually most clean: the presence and value of the first field (hashAlg) determines the interpretation of the following field (certHash);
there is no need to "go back" in the linear handling of the fields after discovering that a hashAlg field is present.
  *   AFAICS, it is as backward compatible as John's proposal: if a CMPv3 capable sender leaves out the new optional hashAlg field (when it is not needed),
the overall structure would look identical to a CMPv2 structure, regardless whether the hashAlg fields was left out at the beginning or the end, right?

David

On 31.08.21 20:24, Carl Wallace wrote:
I did not say it was difficult. What are the several reasons?

On Aug 31, 2021, at 2:16 PM, Blumenthal, Uri - 0553 - MITLL <[email-masked]><mailto:[email-masked]> wrote:

I would rather not leave the structure as-is, for several reasons. Also, given the amount of differences between v1 and v3, modifying hand-rolled implementations seems trivial enough.
--
Regards,
Uri

There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                                                                     -  C. A. R. Hoare

From: Carl Wallace <[email-masked]><mailto:[email-masked]>
Date: Tuesday, August 31, 2021 at 14:03
To: John Gray <[email-masked]><mailto:[email-masked]>, Uri Blumenthal <[email-masked]><mailto:[email-masked]>, Russ Housley <[email-masked]><mailto:[email-masked]>, "Brockhaus, Hendrik" <[email-masked]><mailto:[email-masked]>
Cc: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: [lamps] [CMP Updates] position of hashAlg in certStatus

For folks who use a compiler to update encoders/decoders to v3, this change is likely more or less a no-op (delta Russ’ tagging point about one of the options), since all you are doing is sliding the same fields around within a structure. For folks who hand roll their encoders and decoders, this change makes unnecessary work to align with v3. I’d just leave this structure as-is.

From: John Gray <[email-masked]><mailto:[email-masked]>
Date: Tuesday, August 31, 2021 at 1:37 PM
To: Carl Wallace <[email-masked]><mailto:[email-masked]>, "Blumenthal, Uri - 0553 - MITLL" <[email-masked]><mailto:[email-masked]>, Russ Housley <[email-masked]><mailto:[email-masked]>, "Brockhaus, Hendrik" <[email-masked]><mailto:[email-masked]>
Cc: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: RE: [lamps] [CMP Updates] position of hashAlg in certStatus

When I made the proposal, I was thinking in terms of backwards compatibility and making it easier for an existing CMP implementation to add the v3 functionality.   I recognize that either way will technically work, and since the tagging is optional in Hendrik’s proposal that would be bit identical to CMPv2 when the hashAlg is not present.   The same is true if it goes at the end since it is tagged and is optional.  CertConf was a new message in CMPv2, so a pure CMPv1 implementation would always fail.  However, it is possible an implementation may have modified a CMPv1 implementation to accept the CertConf which may continue working if hashAlg is at the end if they encounter a v3 server (which may be more desirable that failing and requiring the implementation to be updated).     Also, I was thinking as a CMP implementer, I would only need to append to the end of the parsing logic rather than muddling up the existing logic which may make it a bit simpler to implement (for existing implementations).

So that was my rational for asking the question, but as I mentioned above, either way will work.

Cheers,

John Gray

From: Carl Wallace <[email-masked]><mailto:[email-masked]>
Sent: Tuesday, August 31, 2021 1:28 PM
To: Blumenthal, Uri - 0553 - MITLL <[email-masked]><mailto:[email-masked]>; Russ Housley <[email-masked]><mailto:[email-masked]>; Brockhaus, Hendrik <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; John Gray <[email-masked]><mailto:[email-masked]>
Subject: [EXTERNAL] Re: [lamps] [CMP Updates] position of hashAlg in certStatus

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
I apologize for maybe having missing some bit of rationale in this thread, but what is the advantage of moving the hash alg field to the end? It definitely breaks backwards compatibility. What does it add?

From: Spasm <[email-masked]<mailto:[email-masked]>> on behalf of "Blumenthal, Uri - 0553 - MITLL" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 31, 2021 at 12:38 PM
To: Russ Housley <[email-masked]<mailto:[email-masked]>>, "Brockhaus, Hendrik" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, John Gray <[email-masked]<mailto:[email-masked]>>
Subject: Re: [lamps] [CMP Updates] position of hashAlg in certStatus

Hendrik:

John's proposal compiles.  Your new one does too.

I have a mild preference for John's proposal because the bit on the wire are the same as CMPv1 when the hashAlg field is absent.

For the sake of purity, I would prefer Hendrik’s variant.

Also, I’m not sure it’s good if some of CMPv2 messages parse OK by CMPv1 decoder, and others fail. That’s another argument in favor of Hendrik’s.

On Aug 31, 2021, at 12:25 PM, Brockhaus, Hendrik <[email-masked]<mailto:[email-masked]>> wrote:

Russ

Thank you for this explanation.

Would this mean, that Johns proposal should look like this?

   CertStatus ::= SEQUENCE {

      certHash        OCTET STRING,

      certReqId       INTEGER,

      statusInfo [0]  PKIStatusInfo OPTIONAL,

      hashAlg    [1]  AlgorithmIdentifier OPTIONAL

   }

Do you have any preference for the current test or for Johns proposal?

- Hendrik

Gesendet: Dienstag, 31. August 2021 17:12
An: Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]<mailto:[email-masked]>>

Hendrik:

David's proposal will not compile.  The OSS compiler produces this error with that syntax:

   line 62 (TestModule): A0100E: Duplicate tag in type CertStatus: element 'statusInfo' (line 61) and element 'hashAlg' (line 62).

   C0043I: 1 error message, 0 warning messages and 0 informatory messages issued.

The reason for this error is that the two optional elements are both SEQUENCEs.  So, when decoding, if only one of the optional SEQUENCEs is present, it cannot figure out which one it is.

The use of the [0] allows the decoder to tell the two SEQUENCEs apart.

Russ

On Aug 31, 2021, at 8:21 AM, Brockhaus, Hendrik <[email-masked]<mailto:[email-masked]>> wrote:

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 <[email-masked]<mailto:[email-masked]>>
Von: David von Oheimb <[email-masked]<mailto:[email-masked]>>
Gesendet: Donnerstag, 26. August 2021 22:43
An: John Gray <[email-masked]<mailto:[email-masked]>>
On 26.08.21 11:26, Brockhaus, Hendrik (T RDA CST SEA-DE) wrote:

Von: John Gray <[email-masked]><mailto:[email-masked]>
Gesendet: Mittwoch, 25. August 2021 18:35
An: von Oheimb, David (T RDA CST SEA-DE) <[email-masked]><mailto:[email-masked]>; Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Kretschmer, Andreas (T RDA CST SEA-DE) <[email-masked]><mailto:[email-masked]>
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.

_______________________________________________
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%2Furldefense.com%2Fv3%2F__https%3A%2Feur01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm%26data%3D04*7C01*7Chendrik.brockhaus*40siemens.com*7C143aeb858f18456f4ef008d96c91b913*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637660195485199311*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000%26sdata%3D0zVGASW8q0wKP6L3y*2FDbArvhPZfu7N1dddePGJbIfHU*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!LoXbEbIyNev6LwqxU8VE7vr48hf8P9r65NL7ritq1xGlhzX0ww9Z6Z8rGDYc9yQx%24&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C22b22e605bb74452459a08d96cb30447%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637660338422910393%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bYMLnfFal41qVClyFbjeoIiS4kNmAAJxWtQX0LYVH2M%3D&reserved=0>

_______________________________________________ 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%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm__%3B!!FJ-Y8qCqXTj2!LoXbEbIyNev6LwqxU8VE7vr48hf8P9r65NL7ritq1xGlhzX0ww9Z6Z8rGOpMzia-%24&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C22b22e605bb74452459a08d96cb30447%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637660338422920390%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=c68%2F195BNv%2BzHWZQVT%2FncY3XfeyHyjrXW%2FhjOsrOOGg%3D&reserved=0>
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

_______________________________________________

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%7C22b22e605bb74452459a08d96cb30447%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637660338422920390%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fzrs1wW9G%2BhCAtwNV9TTJridHaUW8yFLx2%2FNkuI4%2BHU%3D&reserved=0>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 1 Sep 2021 15:08:10 +0000

Here’s my preference:

 

I don’t see the ability of an older decoder to parse some – but not other – of the new messages as a benefit.

--

Regards,

Uri

                                                                                                                                     -  C. A. R. Hoare

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wednesday, September 1, 2021 at 11:01
To: Carl Wallace <[email-masked]>, "[email-masked]" <[email-masked]>, Uri Blumenthal <[email-masked]>, Russ Housley <[email-masked]>, John Gray <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: AW: [lamps] [CMP Updates] position of hashAlg in certStatus

Hendrik

From: David von Oheimb <[email-masked]>
Date: Tuesday, August 31, 2021 at 2:56 PM
To: Carl Wallace <[email-masked]>, "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>, "Brockhaus, Hendrik" <[email-masked]>, Russ Housley <[email-masked]>, John Gray <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [lamps] [CMP Updates] position of hashAlg in certStatus

·         It is conceptually most clean: the presence and value of the first field (hashAlg) determines the interpretation of the following field (certHash);
there is no need to "go back" in the linear handling of the fields after discovering that a hashAlg field is present.

·         AFAICS, it is as backward compatible as John's proposal: if a CMPv3 capable sender leaves out the new optional hashAlg field (when it is not needed),
the overall structure would look identical to a CMPv2 structure, regardless whether the hashAlg fields was left out at the beginning or the end, right?

David

On Aug 31, 2021, at 2:16 PM, Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:

--

Regards,

Uri

                                                                                                                                     -  C. A. R. Hoare

From: Carl Wallace <[email-masked]>
Date: Tuesday, August 31, 2021 at 14:03
To: John Gray <[email-masked]>, Uri Blumenthal <[email-masked]>, Russ Housley <[email-masked]>, "Brockhaus, Hendrik" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [lamps] [CMP Updates] position of hashAlg in certStatus

From: John Gray <[email-masked]>
Date: Tuesday, August 31, 2021 at 1:37 PM
To: Carl Wallace <[email-masked]>, "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>, Russ Housley <[email-masked]>, "Brockhaus, Hendrik" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [lamps] [CMP Updates] position of hashAlg in certStatus

Cheers,

John Gray

From: Carl Wallace <[email-masked]> 
Sent: Tuesday, August 31, 2021 1:28 PM
To: Blumenthal, Uri - 0553 - MITLL <[email-masked]>; Russ Housley <[email-masked]>; Brockhaus, Hendrik <[email-masked]>
Cc: [email-masked]; [email-masked]; John Gray <[email-masked]>
Subject: [EXTERNAL] Re: [lamps] [CMP Updates] position of hashAlg in certStatus

From: Spasm <[email-masked]> on behalf of "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tuesday, August 31, 2021 at 12:38 PM
To: Russ Housley <[email-masked]>, "Brockhaus, Hendrik" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, John Gray <[email-masked]>
Subject: Re: [lamps] [CMP Updates] position of hashAlg in certStatus

Hendrik:

On Aug 31, 2021, at 12:25 PM, Brockhaus, Hendrik <[email-masked]> wrote:

Russ

- Hendrik

Gesendet: Dienstag, 31. August 2021 17:12
An: Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>

Hendrik:

Russ

On Aug 31, 2021, at 8:21 AM, Brockhaus, Hendrik <[email-masked]> wrote:

Russ

Current syntax:

Johns proposal:

Davids proposal:

Hendrik

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

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

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

Thanks for the updates.

         certHash    OCTET STRING,

         certReqId   INTEGER,

      }

 

            hashVal         BIT STRING

        }

_______________________________________________
Spasm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spasm

_______________________________________________ Spasm mailing list [email-masked] https://www.ietf.org/mailman/listinfo/spasm 

_______________________________________________
Spasm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Thu, 2 Sep 2021 12:23:13 -0400

Uri:

<no hats>

I think the fields that carry forward from CMPv1 should have the same tags that they do in CMPv1.

<\no hats>

Russ

> On Sep 1, 2021, at 11:08 AM, Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
> 
> Here’s my preference:
> 
> From: "Brockhaus, Hendrik" <[email-masked] <mailto:[email-masked]>>
> To: Carl Wallace <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Uri Blumenthal <[email-masked] <mailto:[email-masked]>>, Russ Housley <[email-masked] <mailto:[email-masked]>>, John Gray <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Von: Spasm <[email-masked] <mailto:[email-masked]>> Im Auftrag von Carl Wallace
> From: David von Oheimb <[email-masked] <mailto:[email-masked]>>
> To: Carl Wallace <[email-masked] <mailto:[email-masked]>>, "Blumenthal, Uri - 0553 - MITLL" <[email-masked] <mailto:[email-masked]>>, "Brockhaus, Hendrik" <[email-masked] <mailto:[email-masked]>>, Russ Housley <[email-masked] <mailto:[email-masked]>>, John Gray <[email-masked] <mailto:[email-masked]>>
> Cc: <[email-masked] <mailto:[email-masked]>>
>>> On Aug 31, 2021, at 2:16 PM, Blumenthal, Uri - 0553 - MITLL <[email-masked]> <mailto:[email-masked]> wrote:
>>> 
>>> 
>>> From: Carl Wallace <[email-masked]> <mailto:[email-masked]>
>>> To: John Gray <[email-masked]> <mailto:[email-masked]>, Uri Blumenthal <[email-masked]> <mailto:[email-masked]>, Russ Housley <[email-masked]> <mailto:[email-masked]>, "Brockhaus, Hendrik" <[email-masked]> <mailto:[email-masked]>
>>> Cc: "[email-masked]" <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>, "[email-masked]" <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
>>> From: John Gray <[email-masked]> <mailto:[email-masked]>
>>> To: Carl Wallace <[email-masked]> <mailto:[email-masked]>, "Blumenthal, Uri - 0553 - MITLL" <[email-masked]> <mailto:[email-masked]>, Russ Housley <[email-masked]> <mailto:[email-masked]>, "Brockhaus, Hendrik" <[email-masked]> <mailto:[email-masked]>
>>> Cc: "[email-masked]" <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>, "[email-masked]" <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
>>> From: Carl Wallace <[email-masked]> <mailto:[email-masked]>
>>> To: Blumenthal, Uri - 0553 - MITLL <[email-masked]> <mailto:[email-masked]>; Russ Housley <[email-masked]> <mailto:[email-masked]>; Brockhaus, Hendrik <[email-masked]> <mailto:[email-masked]>
>>> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; John Gray <[email-masked]> <mailto:[email-masked]>
>>> From: Spasm <[email-masked] <mailto:[email-masked]>> on behalf of "Blumenthal, Uri - 0553 - MITLL" <[email-masked] <mailto:[email-masked]>>
>>> To: Russ Housley <[email-masked] <mailto:[email-masked]>>, "Brockhaus, Hendrik" <[email-masked] <mailto:[email-masked]>>
>>> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, John Gray <[email-masked] <mailto:[email-masked]>>
>>>> On Aug 31, 2021, at 12:25 PM, Brockhaus, Hendrik <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> Russ
>>>> 
>>>> An: Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked] <mailto:[email-masked]>>
>>>> 
>>>> 
>>>> Hendrik:
>>>> 
>>>>> On Aug 31, 2021, at 8:21 AM, Brockhaus, Hendrik <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 
>>>>> Russ
>>>>> 
>>>>> An: John Gray <[email-masked] <mailto:[email-masked]>>
>>>>> 
>>>>> Von: David von Oheimb <[email-masked] <mailto:[email-masked]>>
>>>>> An: John Gray <[email-masked] <mailto:[email-masked]>>
>>>>> 
>>>>>> Von: John Gray <[email-masked]> <mailto:[email-masked]>
>>>>>> An: von Oheimb, David (T RDA CST SEA-DE) <[email-masked]> <mailto:[email-masked]>; Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]> <mailto:[email-masked]>
>>>>>> Cc: [email-masked] <mailto:[email-masked]>; Kretschmer, Andreas (T RDA CST SEA-DE) <[email-masked]> <mailto:[email-masked]>
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> https://www.ietf.org/mailman/listinfo/spasm <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Feur01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm%26data%3D04*7C01*7Chendrik.brockhaus*40siemens.com*7C143aeb858f18456f4ef008d96c91b913*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637660195485199311*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000%26sdata%3D0zVGASW8q0wKP6L3y*2FDbArvhPZfu7N1dddePGJbIfHU*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!LoXbEbIyNev6LwqxU8VE7vr48hf8P9r65NL7ritq1xGlhzX0ww9Z6Z8rGDYc9yQx%24&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C22b22e605bb74452459a08d96cb30447%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637660338422910393%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bYMLnfFal41qVClyFbjeoIiS4kNmAAJxWtQX0LYVH2M%3D&reserved=0>
>>> 
>>> _______________________________________________ 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%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm__%3B!!FJ-Y8qCqXTj2!LoXbEbIyNev6LwqxU8VE7vr48hf8P9r65NL7ritq1xGlhzX0ww9Z6Z8rGOpMzia-%24&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C22b22e605bb74452459a08d96cb30447%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637660338422920390%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=c68%2F195BNv%2BzHWZQVT%2FncY3XfeyHyjrXW%2FhjOsrOOGg%3D&reserved=0>
>> [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%7C22b22e605bb74452459a08d96cb30447%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637660338422920390%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fzrs1wW9G%2BhCAtwNV9TTJridHaUW8yFLx2%2FNkuI4%2BHU%3D&reserved=0>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 2 Sep 2021 16:25:47 +0000

*   I think the fields that carry forward from CMPv1 should have the same tags that they do in CMPv1.

I super-strongly agree with this.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 2 Sep 2021 23:56:38 +0000

<no hats>

<\no hats>

May I ask why, given that packets from CMPv{2,3} in general can’t be correctly decoded by CMPv1 parser?

Here’s my preference:

 

--

Regards,

Uri

                                                                                                                                     -  C. A. R. Hoare

Hendrik

David

--

Regards,

Uri

                                                                                                                                     -  C. A. R. Hoare

Cheers,

John Gray

Hendrik:

Russ

- Hendrik

Hendrik:

Russ

Russ

Current syntax:

Johns proposal:

Davids proposal:

Hendrik

Thanks for the updates.

         certHash    OCTET STRING,

         certReqId   INTEGER,

      }

 

            hashVal         BIT STRING

        }

---

From: David von Oheimb <[email-masked]>
Date: Fri, 3 Sep 2021 13:52:21 +0200

> correctly decoded by CMPv1 parser? 

Again, the topic being discussed here does not regard CMPv1 vs.
CMPv{2,3}, but CMPv2 vs. CMPv3.
Note that CMPv1 did not even have a CertStatus message since it did not
have the certificate confirmation feature.

If you feed some CertStatus structure to a CMPv2 parser, which expects

it should be obvious that any value not matching this definition will
not decode.

So basically the only thing you can do in a somewhat backward-compatible
way is to add optional fields in any positions,
and as long as none of those optional fields is actually present in a
value to be parsed, CMPv2 decoding can succeed.
Changing tags of existing fields is clearly not backward compatible.

    David

>     On Sep 1, 2021, at 11:08 AM, Blumenthal, Uri - 0553 - MITLL
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>      
>
>     Here’s my preference:
>
>      
>
>     I don’t see the ability of an older decoder to parse some – *but
>     not other* – of the new messages as a benefit.
>
>      
>
>     --
>
>     Regards,
>
>     Uri
>
>     / /
>
>     /There are two ways to design a system. One is to make is so
>     simple there are obviously no deficiencies./
>
>     /The other is to make it so complex there are no obvious
>     deficiencies./
>
>     /                 
>                                                                                                                        - 
>     C. A. R. Hoare/
>
>      
>
>      
>
>     *From: *"Brockhaus, Hendrik" <[email-masked]
>     <mailto:[email-masked]>>
>     *Date: *Wednesday, September 1, 2021 at 11:01
>     *To: *Carl Wallace <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>"
>     <[email-masked]
>     <mailto:[email-masked]>>, Uri Blumenthal
>     <[email-masked] <mailto:[email-masked]>>, Russ Housley
>     <[email-masked] <mailto:[email-masked]>>, John Gray
>     <[email-masked] <mailto:[email-masked]>>
>     *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     *Subject: *AW: [lamps] [CMP Updates] position of hashAlg in certStatus
>
>      
>
>     I am happy with both proposals. There still seam to be some
>     preferences for the one or the other proposal.
>
>     *Von:* Spasm <[email-masked]
>     <mailto:[email-masked]>> *Im Auftrag von *Carl Wallace
>     *Gesendet:* Dienstag, 31. August 2021 21:10
>
>      
>
>     Thank you. “Current syntax” did not mean current as in v2. That
>     was what I had gotten wrong. You are adding the hashAlg field, not
>     simply moving it (relative to v2). I agree adding it at the end
>     makes the most sense and it needs a tag. 
>
>      
>
>     *From: *David von Oheimb <[email-masked]
>     <mailto:[email-masked]>>
>     *Date: *Tuesday, August 31, 2021 at 2:56 PM
>     *To: *Carl Wallace <[email-masked]
>     <mailto:[email-masked]>>, "Blumenthal, Uri - 0553 -
>     MITLL" <[email-masked] <mailto:[email-masked]>>, "Brockhaus,
>     Hendrik" <[email-masked]
>     <mailto:[email-masked]>>, Russ Housley
>     <[email-masked] <mailto:[email-masked]>>, John Gray
>     <[email-masked] <mailto:[email-masked]>>
>     *Cc: *<[email-masked] <mailto:[email-masked]>>
>     *Subject: *Re: [lamps] [CMP Updates] position of hashAlg in certStatus
>
>      
>
>     1.       What Hendrik introduced as "David's proposal" was meant
>     by me just as potential a variant of John's proposal, not
>     something that I would actually like to propose.
>     Anyway interesting to learn from Russ that the fact that two
>     optional sequences after each other already make parsing ambiguous -
>     I would have hoped that the parser looked deeper: as far as to the
>     first basic (non-sequence) field, where there is more chance that
>     field types/tags are sufficiently different.
>
>     3.       The change from v2 to v3 is not about changing the order
>     of fields, but where to add the new (v3) hashAlg field: at the
>     beginning or at the end.
>
>     ·         It is conceptually most clean: the presence and value of
>     the first field (hashAlg) determines the interpretation of the
>     following field (certHash);
>     there is no need to "go back" in the linear handling of the fields
>     after discovering that a hashAlg field is present.
>
>     ·         AFAICS, it is as backward compatible as John's proposal:
>     if a CMPv3 capable sender leaves out the new optional hashAlg
>     field (when it is not needed),
>     the overall structure would look identical to a CMPv2 structure,
>     regardless whether the hashAlg fields was left out at the
>     beginning or the end, right?
>
>     David
>
>      
>
>             On Aug 31, 2021, at 2:16 PM, Blumenthal, Uri - 0553 -
>             MITLL <[email-masked]> <mailto:[email-masked]> wrote:
>
>              
>
>             I would rather not leave the structure as-is, for several
>             reasons. Also, given the amount of differences between v1
>             and v3, modifying hand-rolled implementations seems
>             trivial enough. 
>
>             --
>
>             Regards,
>
>             Uri
>
>             / /
>
>             /There are two ways to design a system. One is to make is
>             so simple there are obviously no deficiencies./
>
>             /The other is to make it so complex there are no obvious
>             deficiencies./
>
>             /                 
>                                                                                                                                - 
>             C. A. R. Hoare/
>
>              
>
>              
>
>             *From: *Carl Wallace <[email-masked]>
>             <mailto:[email-masked]>
>             *Date: *Tuesday, August 31, 2021 at 14:03
>             *To: *John Gray <[email-masked]>
>             <mailto:[email-masked]>, Uri
>             Blumenthal <[email-masked]> <mailto:[email-masked]>, Russ
>             Housley <[email-masked]>
>             <mailto:[email-masked]>, "Brockhaus,
>             Hendrik" <[email-masked]>
>             <mailto:[email-masked]>
>             *Cc: *"[email-masked]"
>             <mailto:[email-masked]> <[email-masked]>
>             <mailto:[email-masked]>, "[email-masked]"
>             <mailto:[email-masked]> <[email-masked]>
>             <mailto:[email-masked]>
>             *Subject: *Re: [lamps] [CMP Updates] position of hashAlg
>             in certStatus
>
>              
>
>             For folks who use a compiler to update encoders/decoders
>             to v3, this change is likely more or less a no-op (delta
>             Russ’ tagging point about one of the options), since all
>             you are doing is sliding the same fields around within a
>             structure. For folks who hand roll their encoders and
>             decoders, this change makes unnecessary work to align with
>             v3. I’d just leave this structure as-is.
>
>              
>
>             *From: *John Gray <[email-masked]>
>             <mailto:[email-masked]>
>             *Date: *Tuesday, August 31, 2021 at 1:37 PM
>             *To: *Carl Wallace <[email-masked]>
>             <mailto:[email-masked]>, "Blumenthal, Uri -
>             0553 - MITLL" <[email-masked]> <mailto:[email-masked]>,
>             Russ Housley <[email-masked]>
>             <mailto:[email-masked]>, "Brockhaus,
>             Hendrik" <[email-masked]>
>             <mailto:[email-masked]>
>             *Cc: *"[email-masked]"
>             <mailto:[email-masked]> <[email-masked]>
>             <mailto:[email-masked]>, "[email-masked]"
>             <mailto:[email-masked]> <[email-masked]>
>             <mailto:[email-masked]>
>             *Subject: *RE: [lamps] [CMP Updates] position of hashAlg
>             in certStatus
>
>              
>
>             When I made the proposal, I was thinking in terms of
>             backwards compatibility and making it easier for an
>             existing CMP implementation to add the v3 functionality.  
>             I recognize that either way will technically work, and
>             since the tagging is optional in Hendrik’s proposal that
>             would be bit identical to CMPv2 when the hashAlg is not
>             present.   The same is true if it goes at the end since it
>             is tagged and is optional.  CertConf was a new message in
>             CMPv2, so a pure CMPv1 implementation would always fail. 
>             However, it is possible an implementation may have
>             modified a CMPv1 implementation to accept the CertConf
>             which may continue working if hashAlg is at the end if
>             they encounter a v3 server (which may be more desirable
>             that failing and requiring the implementation to be
>             updated).     Also, I was thinking as a CMP implementer, I
>             would only need to append to the end of the parsing logic
>             rather than muddling up the existing logic which may make
>             it a bit simpler to implement (for existing
>             implementations).    
>
>              
>
>             *From:* Carl Wallace <[email-masked]>
>             <mailto:[email-masked]> 
>             *Sent:* Tuesday, August 31, 2021 1:28 PM
>             *To:* Blumenthal, Uri - 0553 - MITLL <[email-masked]>
>             <mailto:[email-masked]>; Russ
>             Housley <[email-masked]>
>             <mailto:[email-masked]>; Brockhaus,
>             Hendrik <[email-masked]>
>             <mailto:[email-masked]>
>             *Cc:* [email-masked]
>             <mailto:[email-masked]>; [email-masked]
>             <mailto:[email-masked]>; John
>             Gray <[email-masked]> <mailto:[email-masked]>
>             *Subject:* [EXTERNAL] Re: [lamps] [CMP Updates] position
>             of hashAlg in certStatus
>
>              
>
>             ------------------------------------------------------------------------
>
>             I apologize for maybe having missing some bit of rationale
>             in this thread, but what is the advantage of moving the
>             hash alg field to the end? It definitely breaks backwards
>             compatibility. What does it add?
>
>              
>
>             *From: *Spasm <[email-masked]
>             <mailto:[email-masked]>> on behalf of "Blumenthal,
>             Uri - 0553 - MITLL" <[email-masked] <mailto:[email-masked]>>
>             *Date: *Tuesday, August 31, 2021 at 12:38 PM
>             *To: *Russ Housley <[email-masked]
>             <mailto:[email-masked]>>, "Brockhaus, Hendrik"
>             <[email-masked]
>             <mailto:[email-masked]>>
>             *Cc: *"[email-masked] <mailto:[email-masked]>"
>             <[email-masked] <mailto:[email-masked]>>,
>             "[email-masked]
>             <mailto:[email-masked]>"
>             <[email-masked]
>             <mailto:[email-masked]>>, John Gray
>             <[email-masked] <mailto:[email-masked]>>
>             *Subject: *Re: [lamps] [CMP Updates] position of hashAlg
>             in certStatus
>
>              
>
>             Hendrik:
>
>              
>
>             I have a mild preference for John's proposal because the
>             bit on the wire are the same as CMPv1 when the hashAlg
>             field is absent.
>
>              
>
>             Also, I’m not sure it’s good if some of CMPv2 messages
>             parse OK by CMPv1 decoder, and others fail. That’s another
>             argument in favor of Hendrik’s.
>
>              
>
>                 On Aug 31, 2021, at 12:25 PM, Brockhaus, Hendrik
>                 <[email-masked]
>                 <mailto:[email-masked]>> wrote:
>
>                  
>
>                 Russ
>
>                  
>
>                 *Gesendet:* Dienstag, 31. August 2021 17:12
>                 *An:* Brockhaus, Hendrik (T RDA CST SEA-DE)
>                 <[email-masked]
>                 <mailto:[email-masked]>>
>
>                  
>
>                 Hendrik:
>
>                  
>
>                    line 62 (TestModule): A0100E: Duplicate tag in type
>                 CertStatus: element 'statusInfo' (line 61) and element
>                 'hashAlg' (line 62).
>
>                  
>
>                 The reason for this error is that the two optional
>                 elements are both SEQUENCEs.  So, when decoding, if
>                 only one of the optional SEQUENCEs is present, it
>                 cannot figure out which one it is.
>
>                  
>
>                     On Aug 31, 2021, at 8:21 AM, Brockhaus, Hendrik
>                     <[email-masked]
>                     <mailto:[email-masked]>> wrote:
>
>                      
>
>                     Russ
>
>                      
>
>                     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:
>
>                     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 <[email-masked]
>                     <mailto:[email-masked]>>
>
>                     *Von:* David von Oheimb
>                     <[email-masked]
>                     <mailto:[email-masked]>> 
>                     *Gesendet:* Donnerstag, 26. August 2021 22:43
>                     *An:* John Gray <[email-masked]
>                     <mailto:[email-masked]>>
>
>                         *Von:* John Gray <[email-masked]>
>                         <mailto:[email-masked]> 
>                         *Gesendet:* Mittwoch, 25. August 2021 18:35
>                         *An:* von Oheimb, David (T RDA CST
>                         SEA-DE) <[email-masked]>
>                         <mailto:[email-masked]>;
>                         Brockhaus, Hendrik (T RDA CST
>                         SEA-DE) <[email-masked]>
>                         <mailto:[email-masked]>
>                         *Cc:* [email-masked]
>                         <mailto:[email-masked]>;
>                         Kretschmer, Andreas (T RDA CST
>                         SEA-DE) <[email-masked]>
>                         <mailto:[email-masked]>
>                         *Betreff:* RE: [EXTERNAL] Re: CMP Updates and
>                         Lightweight CMP Profile
>
>                          
>
>                         Thanks for the updates.
>
>                          
>
>                         Section 2.10 -  CertStatus update.  I was
>                         wondering if adding the optional tagged
>                         element as the last element **might** make a
>                         difference:
>
>                          
>
>                         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.
>
>                         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.
>                     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.
>
>                          
>
>                     <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Feur01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm%26data%3D04*7C01*7Chendrik.brockhaus*40siemens.com*7C143aeb858f18456f4ef008d96c91b913*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637660195485199311*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000%26sdata%3D0zVGASW8q0wKP6L3y*2FDbArvhPZfu7N1dddePGJbIfHU*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!LoXbEbIyNev6LwqxU8VE7vr48hf8P9r65NL7ritq1xGlhzX0ww9Z6Z8rGDYc9yQx%24&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C22b22e605bb74452459a08d96cb30447%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637660338422910393%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bYMLnfFal41qVClyFbjeoIiS4kNmAAJxWtQX0LYVH2M%3D&reserved=0>
>
>              
>
>             _______________________________________________ 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%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm__%3B!!FJ-Y8qCqXTj2!LoXbEbIyNev6LwqxU8VE7vr48hf8P9r65NL7ritq1xGlhzX0ww9Z6Z8rGOpMzia-%24&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C22b22e605bb74452459a08d96cb30447%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637660338422920390%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=c68%2F195BNv%2BzHWZQVT%2FncY3XfeyHyjrXW%2FhjOsrOOGg%3D&reserved=0>
>
>             /Any email and files/attachments transmitted with it are
>             confidential and are intended solely for the use of the
>             individual or entity to whom they are addressed. If this
>             message has been sent to you in error, you must not copy,
>             distribute or disclose of the information it
>             contains. _Please notify Entrust immediately_ and delete
>             the message from your system./
>
>          
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 3 Sep 2021 12:47:58 +0000

Again, the topic being discussed here does not regard CMPv1 vs. CMPv{2,3}, but CMPv2 vs. CMPv3. 
Note that CMPv1 did not even have a CertStatus message since it did not have the certificate confirmation feature.

Yeah, the actual version numbers are irrelevant (not that I could ever get them right anyway).

So basically the only thing you can do in a somewhat backward-compatible way is to add optional fields in any positions,
and as long as none of those optional fields is actually present in a value to be parsed, CMPv2 decoding can succeed.
Changing tags of existing fields is clearly not backward compatible.

Thank you, I understand all this very well. 

What I am trying to understand is what is the purpose of catering to a decoder that by definition can parse only some of the set of the valid messages. What’s so desirable about “somewhat backward-compatible way” (which means that in general it is not compatible, but some messages it can parse)?

I prefer a clean break. Or, if you must – remain fully backward-compatible.

Here’s my preference:

 

--

Regards,

Uri

                                                                                                                                     -  C. A. R. Hoare

Hendrik

David

--

Regards,

Uri

                                                                                                                                     -  C. A. R. Hoare

Cheers,

John Gray

Hendrik:

Russ

- Hendrik

Hendrik:

Russ

Russ

Current syntax:

Johns proposal:

Davids proposal:

Hendrik

Thanks for the updates.

         certHash    OCTET STRING,

         certReqId   INTEGER,

      }

 

            hashVal         BIT STRING

        }

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 3 Sep 2021 13:02:16 +0000

> What’s so desirable about “somewhat backward-compatible way” (which means that in general it is not compatible, but some messages it can parse)?

I think you are looking at it backwards.  I can no write a v3 parser that understands both v3 and v2, perhaps controlled by a flag.

---

From: Russ Housley <[email-masked]>
Date: Fri, 3 Sep 2021 09:31:38 -0400

David:

In some ASN.1 implementation approaches, a routine is written for each type.  Using the same tags would allow the statusInfo filed to be the same for CMPv1 and CMPv2 in an implementation that supports both versions.

Russ

> On Sep 3, 2021, at 7:52 AM, David von Oheimb <[email-masked]> wrote:
> 
> 
> it should be obvious that any value not matching this definition will not decode.
>> On Sep 1, 2021, at 11:08 AM, Blumenthal, Uri - 0553 - MITLL <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>  
>> Here’s my preference:
>> 
>>  
>>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 3 Sep 2021 15:25:02 +0000

All:

I am still trying to find a conclusion the majority can live with. :-)

To sum up:

CMP V1 (RFC 2510) does not define CertStatus at all.
CMP V2 (RFC 4210) defines CertStatus as follows:
   CertStatus ::= SEQUENCE {
      certHash    OCTET STRING,
      certReqId   INTEGER,
      statusInfo  PKIStatusInfo OPTIONAL
      }
Proposals for adding hashAlg for CMP V3 syntax as defined in draft-ietf-lamps-cmp-updates.
Proposal 1 (current proposal in draft-ietf-lamps-cmp-updates-12):

      certHash     OCTET STRING,

      certReqId    INTEGER,

      }

      certHash     OCTET STRING,

      certReqId    INTEGER,

      }
Proposal 3 (preferred by Uri):

      certHash       OCTET STRING,

      certReqId      INTEGER,

      }
All proposals compile and therefore technically work.

As already stated, I can also live with proposal 2. But I dislike proposal 3, as it changes more than necessary and we look for limited changes to CMP V2.

Reviewing the email exchange, I see the following preferences.
Proposal 1
+ David, Hendrik
- John, Uri
Proposal 2
+ John, Russ, Carl(, Hendrik)
- Uri
Proposal 3
+ Uri
- Russ, Rich, David, Hendrik

Summing up, I see a clear preference for proposal 2.
Please let me know if I misunderstood anyone's preference.

Hendrik

Von: Spasm <[email-masked]> Im Auftrag von Russ Housley
Gesendet: Freitag, 3. September 2021 15:32

David:

Russ

On Sep 3, 2021, at 7:52 AM, David von Oheimb <[email-masked]<mailto:[email-masked]>> wrote:

May I ask why, given that packets from CMPv{2,3} in general can't be correctly decoded by CMPv1 parser?
Again, the topic being discussed here does not regard CMPv1 vs. CMPv{2,3}, but CMPv2 vs. CMPv3.
Note that CMPv1 did not even have a CertStatus message since it did not have the certificate confirmation feature.
If you feed some CertStatus structure to a CMPv2 parser, which expects

            certHash    OCTET STRING,

            certReqId   INTEGER,

         }

On Sep 1, 2021, at 11:08 AM, Blumenthal, Uri - 0553 - MITLL <[email-masked]<mailto:[email-masked]>> wrote:

Here's my preference:

      certHash        OCTET STRING,

      certReqId       INTEGER,

   }

I don't see the ability of an older decoder to parse some - but not other - of the new messages as a benefit.

--
Regards,
Uri

From: "Brockhaus, Hendrik" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 1, 2021 at 11:01
To: Carl Wallace <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Uri Blumenthal <[email-masked]<mailto:[email-masked]>>, Russ Housley <[email-masked]<mailto:[email-masked]>>, John Gray <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: AW: [lamps] [CMP Updates] position of hashAlg in certStatus

      certHash     OCTET STRING,

      certReqId    INTEGER,

   }

      certHash     OCTET STRING,

      certReqId    INTEGER,

   }

      certHash     OCTET STRING,

      certReqId    INTEGER,

   }

Hendrik

Von: Spasm <[email-masked]<mailto:[email-masked]>> Im Auftrag von Carl Wallace
Gesendet: Dienstag, 31. August 2021 21:10

Thank you. "Current syntax" did not mean current as in v2. That was what I had gotten wrong. You are adding the hashAlg field, not simply moving it (relative to v2). I agree adding it at the end makes the most sense and it needs a tag.

For folks who use a compiler to update encoders/decoders to v3, this change is likely more or less a no-op (delta Russ' tagging point about one of the options), since all you are doing is sliding the same fields around within a structure. For folks who hand roll their encoders and decoders, this change makes unnecessary work to align with v3. I'd just leave this structure as-is.

When I made the proposal, I was thinking in terms of backwards compatibility and making it easier for an existing CMP implementation to add the v3 functionality.   I recognize that either way will technically work, and since the tagging is optional in Hendrik's proposal that would be bit identical to CMPv2 when the hashAlg is not present.   The same is true if it goes at the end since it is tagged and is optional.  CertConf was a new message in CMPv2, so a pure CMPv1 implementation would always fail.  However, it is possible an implementation may have modified a CMPv1 implementation to accept the CertConf which may continue working if hashAlg is at the end if they encounter a v3 server (which may be more desirable that failing and requiring the implementation to be updated).     Also, I was thinking as a CMP implementer, I would only need to append to the end of the parsing logic rather than muddling up the existing logic which may make it a bit simpler to implement (for existing implementations).

Cheers,

John Gray

Hendrik:

For the sake of purity, I would prefer Hendrik's variant.

Also, I'm not sure it's good if some of CMPv2 messages parse OK by CMPv1 decoder, and others fail. That's another argument in favor of Hendrik's.

Russ

      certHash        OCTET STRING,

      certReqId       INTEGER,

   }

- Hendrik

Hendrik:

Russ

Russ

Current syntax:

      certHash    OCTET STRING,

      certReqId   INTEGER,

   }

Johns proposal:

      certHash    OCTET STRING,

      certReqId   INTEGER,

   }

Davids proposal:

      certHash    OCTET STRING,

      certReqId   INTEGER,

   }

Hendrik

Thanks for the updates.

         certHash    OCTET STRING,

         certReqId   INTEGER,

      }

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.

         certHash    OCTET STRING,

         certReqId   INTEGER,

      }

_______________________________________________
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%2Furldefense.com%2Fv3%2F__https%3A%2Feur01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm%26data%3D04*7C01*7Chendrik.brockhaus*40siemens.com*7C143aeb858f18456f4ef008d96c91b913*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637660195485199311*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000%26sdata%3D0zVGASW8q0wKP6L3y*2FDbArvhPZfu7N1dddePGJbIfHU*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!LoXbEbIyNev6LwqxU8VE7vr48hf8P9r65NL7ritq1xGlhzX0ww9Z6Z8rGDYc9yQx%24&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C0f53a2b88007496f716108d96edf4101%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637662727449199119%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=88KpSrVoiGaDMtBAJTCc6YZsfmiSUdXS0qccTphgud4%3D&reserved=0>

_______________________________________________ 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%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm__%3B!!FJ-Y8qCqXTj2!LoXbEbIyNev6LwqxU8VE7vr48hf8P9r65NL7ritq1xGlhzX0ww9Z6Z8rGOpMzia-%24&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C0f53a2b88007496f716108d96edf4101%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637662727449209115%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IngMg4XxSQBzeq1J1PeYQR%2F6IeI9ipymAG8lOSMNqBk%3D&reserved=0>
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

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%7C0f53a2b88007496f716108d96edf4101%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637662727449219116%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pfhz%2Bph3xK4SN%2B9TAXHX5zoiV49xiIOssDmy6XcnaeI%3D&reserved=0>

---

From: John Gray <[email-masked]>
Date: Fri, 3 Sep 2021 15:46:07 +0000

Hi Hendrik,

Thanks for helping us to come to a consensus!

You can add a '-' to proposal 3 from me as well.  It actually changes the 4210 definition (when hashAlg) is not there, and would add an extra bit of complexity in the ASN.1 parsing to handle backwards compatibility for implementers that does not need to be there...

Cheers,

John Gray

From: Brockhaus, Hendrik <[email-masked]>
Sent: Friday, September 3, 2021 11:25 AM
To: Russ Housley <[email-masked]>; David von Oheimb <[email-masked]>; Carl Wallace <[email-masked]>; Uri Blumenthal <[email-masked]>; John Gray <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] AW: [lamps] [CMP Updates] position of hashAlg in certStatus

To sum up:

      certHash     OCTET STRING,

      certReqId    INTEGER,

      }

      certHash     OCTET STRING,

      certReqId    INTEGER,

      }

      certHash       OCTET STRING,

      certReqId      INTEGER,

      }

Hendrik

Von: Spasm <[email-masked]<mailto:[email-masked]>> Im Auftrag von Russ Housley
Gesendet: Freitag, 3. September 2021 15:32
David:

Russ

            certHash    OCTET STRING,

            certReqId   INTEGER,

         }

Here's my preference:

      certHash        OCTET STRING,

      certReqId       INTEGER,

   }

--
Regards,
Uri

      certHash     OCTET STRING,

      certReqId    INTEGER,

   }

      certHash     OCTET STRING,

      certReqId    INTEGER,

   }

      certHash     OCTET STRING,

      certReqId    INTEGER,

   }

Hendrik

Cheers,

John Gray

Hendrik:

Russ

      certHash        OCTET STRING,

      certReqId       INTEGER,

   }

- Hendrik

Hendrik:

Russ

Russ

Current syntax:

      certHash    OCTET STRING,

      certReqId   INTEGER,

   }

Johns proposal:

      certHash    OCTET STRING,

      certReqId   INTEGER,

   }

Davids proposal:

      certHash    OCTET STRING,

      certReqId   INTEGER,

   }

Hendrik

Thanks for the updates.

         certHash    OCTET STRING,

         certReqId   INTEGER,

      }

         certHash    OCTET STRING,

         certReqId   INTEGER,

      }

_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://urldefense.com/v3/__https:/eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Feur01.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm*26data*3D04*7C01*7Chendrik.brockhaus*40siemens.com*7C143aeb858f18456f4ef008d96c91b913*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637660195485199311*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000*26sdata*3D0zVGASW8q0wKP6L3y*2FDbArvhPZfu7N1dddePGJbIfHU*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!LoXbEbIyNev6LwqxU8VE7vr48hf8P9r65NL7ritq1xGlhzX0ww9Z6Z8rGDYc9yQx*24&data=04*7C01*7Chendrik.brockhaus*40siemens.com*7C0f53a2b88007496f716108d96edf4101*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637662727449199119*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=88KpSrVoiGaDMtBAJTCc6YZsfmiSUdXS0qccTphgud4*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqKiUlKioqKioqKioqKioqJSUqKiUlJSUlJSUlJSUlJSUlJSUl!!FJ-Y8qCqXTj2!Nz_C7tBrJ8IelJmdscBpLtz9VTsBCMoSHKyb2cH7sKIiqx5MWxovjd5F43tzKzrg$>

_______________________________________________ Spasm mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/spasm<https://urldefense.com/v3/__https:/eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm__*3B!!FJ-Y8qCqXTj2!LoXbEbIyNev6LwqxU8VE7vr48hf8P9r65NL7ritq1xGlhzX0ww9Z6Z8rGOpMzia-*24&data=04*7C01*7Chendrik.brockhaus*40siemens.com*7C0f53a2b88007496f716108d96edf4101*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637662727449209115*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=IngMg4XxSQBzeq1J1PeYQR*2F6IeI9ipymAG8lOSMNqBk*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!Nz_C7tBrJ8IelJmdscBpLtz9VTsBCMoSHKyb2cH7sKIiqx5MWxovjd5F44j3tWy7$>
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

Spasm mailing list

https://www.ietf.org/mailman/listinfo/spasm<https://urldefense.com/v3/__https:/eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm&data=04*7C01*7Chendrik.brockhaus*40siemens.com*7C0f53a2b88007496f716108d96edf4101*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637662727449219116*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=pfhz*2Bph3xK4SN*2B9TAXHX5zoiV49xiIOssDmy6XcnaeI*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!FJ-Y8qCqXTj2!Nz_C7tBrJ8IelJmdscBpLtz9VTsBCMoSHKyb2cH7sKIiqx5MWxovjd5F43xZX7R3$>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 3 Sep 2021 17:14:41 +0000

I can live with (2) - I just think that justification voiced for it is too weak. 

Regards,
Uri

> On Sep 3, 2021, at 11:47, John Gray <[email-masked]> wrote:
> 
> 
> Hi Hendrik,
>  
> You can add a ‘–‘ to proposal 3 from me as well.  It actually changes the 4210 definition (when hashAlg) is not there, and would add an extra bit of complexity in the ASN.1 parsing to handle backwards compatibility for implementers that does not need to be there…
>  
> Cheers,
>  
> John Gray
>  
>  
>

---

From: David von Oheimb <[email-masked]>
Date: Sun, 5 Sep 2021 15:52:34 +0200

John, Russ, Carl,

can you explain why you (to some extent) prefer proposal 2 over proposal 1?
As mentioned, proposal 1 should be as backward-compatible as proposal 2,
and proposal 1 has the clear conceptual advantage that the hashAlg field
comes before the field that it governs: certHash.

    David

On 03.09.21 17:46, John Gray wrote:
> You can add a ‘–‘ to proposal 3 from me as well.  It actually changes
> the 4210 definition (when hashAlg) is not there, and would add an
> extra bit of complexity in the ASN.1 parsing to handle backwards
> compatibility for implementers that does not need to be there…
>
>  
>
> Cheers,
>
>  
>
> John Gray
>
>  
>
>  
>
>  
>
> *From:* Brockhaus, Hendrik <[email-masked]>
> *Sent:* Friday, September 3, 2021 11:25 AM
> *To:* Russ Housley <[email-masked]>; David von Oheimb
> <[email-masked]>; Carl Wallace <[email-masked]>; Uri
> Blumenthal <[email-masked]>; John Gray <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* [EXTERNAL] AW: [lamps] [CMP Updates] position of hashAlg in
> certStatus
>
>  
>
> As already stated, I can also live with proposal 2. But I dislike
> proposal 3, as it changes more than necessary and we look for limited
> changes to CMP V2.
>
>  
>
> *Von:*Spasm <[email-masked] <mailto:[email-masked]>>
> *Im Auftrag von *Russ Housley
> *Gesendet:* Freitag, 3. September 2021 15:32
>
> David:
>
>  
>
> In some ASN.1 implementation approaches, a routine is written for each
> type.  Using the same tags would allow the statusInfo filed to be the
> same for CMPv1 and CMPv2 in an implementation that supports both versions.
>
>  
>
> Russ
>
>  
>
>  
>
>         May I ask why, given that packets from CMPv{2,3} in general
>         can’t be correctly decoded by CMPv1 parser?
>
>     Note that CMPv1 did not even have a CertStatus message since it
>     did not have the certificate confirmation feature.
>
>     So basically the only thing you can do in a somewhat
>     backward-compatible way is to add optional fields in any positions,
>     and as long as none of those optional fields is actually present
>     in a value to be parsed, CMPv2 decoding can succeed.
>             On Sep 1, 2021, at 11:08 AM, Blumenthal, Uri - 0553 -
>             MITLL <[email-masked] <mailto:[email-masked]>> wrote:
>
>              
>
>             Here’s my preference:
>
>              
>
>             I don’t see the ability of an older decoder to parse some
>             – *but not other* – of the new messages as a benefit.
>
>              
>
>             --
>
>             Regards,
>
>             Uri
>
>             / /
>
>             <[email-masked] <mailto:[email-masked]>>, John
>             Gray <[email-masked] <mailto:[email-masked]>>
>             <[email-masked] <mailto:[email-masked]>>
>             I see two variants still in the discussion. Both add
>             hashAlg to the current syntax of RFC 4210.
>
>             Both proposals should compile and should be bitwise
>             backward compatible when not using hashAlg.
>
>             I am happy with both proposals. There still seam to be
>             some preferences for the one or the other proposal.
>
>             Thank you. “Current syntax” did not mean current as in v2.
>             That was what I had gotten wrong. You are adding the
>             hashAlg field, not simply moving it (relative to v2). I
>             agree adding it at the end makes the most sense and it
>             needs a tag. 
>
>              
>
>             <mailto:[email-masked]>>, "Blumenthal, Uri -
>             0553 - MITLL" <[email-masked] <mailto:[email-masked]>>,
>             "Brockhaus, Hendrik" <[email-masked]
>             <[email-masked] <mailto:[email-masked]>>, John
>             Gray <[email-masked] <mailto:[email-masked]>>
>             1.       What Hendrik introduced as "David's proposal" was
>             meant by me just as potential a variant of John's
>             proposal, not something that I would actually like to propose.
>             Anyway interesting to learn from Russ that the fact that
>             two optional sequences after each other already make
>             parsing ambiguous -
>             I would have hoped that the parser looked deeper: as far
>             as to the first basic (non-sequence) field, where there is
>             more chance that field types/tags are sufficiently different.
>
>             3.       The change from v2 to v3 is not about changing
>             the order of fields, but where to add the new (v3) hashAlg
>             field: at the beginning or at the end.
>
>             ·         It is conceptually most clean: the presence and
>             value of the first field (hashAlg) determines the
>             interpretation of the following field (certHash);
>             there is no need to "go back" in the linear handling of
>             the fields after discovering that a hashAlg field is present.
>
>             ·         AFAICS, it is as backward compatible as John's
>             proposal: if a CMPv3 capable sender leaves out the new
>             optional hashAlg field (when it is not needed),
>             the overall structure would look identical to a CMPv2
>             structure, regardless whether the hashAlg fields was left
>             out at the beginning or the end, right?
>
>             David
>
>              
>
>                     On Aug 31, 2021, at 2:16 PM, Blumenthal, Uri -
>                     0553 - MITLL <[email-masked]>
>                     <mailto:[email-masked]> wrote:
>
>                      
>
>                     I would rather not leave the structure as-is, for
>                     several reasons. Also, given the amount of
>                     differences between v1 and v3, modifying
>                     hand-rolled implementations seems trivial enough. 
>
>                     --
>
>                     Regards,
>
>                     Uri
>
>                     / /
>
>                     /There are two ways to design a system. One is to
>                     make is so simple there are obviously no
>                     deficiencies./
>
>                     /The other is to make it so complex there are no
>                     obvious deficiencies./
>
>                     /                 
>                                                                                                                                        - 
>                     C. A. R. Hoare/
>
>                      
>
>                      
>
>                     For folks who use a compiler to update
>                     encoders/decoders to v3, this change is likely
>                     more or less a no-op (delta Russ’ tagging point
>                     about one of the options), since all you are doing
>                     is sliding the same fields around within a
>                     structure. For folks who hand roll their encoders
>                     and decoders, this change makes unnecessary work
>                     to align with v3. I’d just leave this structure as-is.
>
>                      
>
>                     <mailto:[email-masked]>, "Blumenthal,
>                     Uri - 0553 - MITLL" <[email-masked]>
>                     <mailto:[email-masked]>, Russ
>                     *Subject: *RE: [lamps] [CMP Updates] position of
>                     hashAlg in certStatus
>
>                      
>
>                     When I made the proposal, I was thinking in terms
>                     of backwards compatibility and making it easier
>                     for an existing CMP implementation to add the v3
>                     functionality.   I recognize that either way will
>                     technically work, and since the tagging is
>                     optional in Hendrik’s proposal that would be bit
>                     identical to CMPv2 when the hashAlg is not
>                     present.   The same is true if it goes at the end
>                     since it is tagged and is optional.  CertConf was
>                     a new message in CMPv2, so a pure CMPv1
>                     implementation would always fail.  However, it is
>                     possible an implementation may have modified a
>                     CMPv1 implementation to accept the CertConf which
>                     may continue working if hashAlg is at the end if
>                     they encounter a v3 server (which may be more
>                     desirable that failing and requiring the
>                     implementation to be updated).     Also, I was
>                     thinking as a CMP implementer, I would only need
>                     to append to the end of the parsing logic rather
>                     than muddling up the existing logic which may make
>                     So that was my rational for asking the question,
>                     but as I mentioned above, either way will work.   
>
>                      
>
>                     Cheers,
>
>                      
>
>                     John Gray
>
>                      
>
>                      
>
>                     *To:* Blumenthal, Uri - 0553 -
>                     MITLL <[email-masked]> <mailto:[email-masked]>;
>                     *Subject:* [EXTERNAL] Re: [lamps] [CMP Updates]
>                     position of hashAlg in certStatus
>
>                      
>
>                     I apologize for maybe having missing some bit of
>                     rationale in this thread, but what is the
>                     advantage of moving the hash alg field to the end?
>                     It definitely breaks backwards compatibility. What
>                     does it add?
>
>                      
>
>                     <mailto:[email-masked]>> on behalf of
>                     "Blumenthal, Uri - 0553 - MITLL" <[email-masked]
>                     <mailto:[email-masked]>>
>                     <mailto:[email-masked]>>, "Brockhaus,
>                     I have a mild preference for John's proposal
>                     because the bit on the wire are the same as CMPv1
>                     when the hashAlg field is absent.
>
>                      
>
>                     Also, I’m not sure it’s good if some of CMPv2
>                     messages parse OK by CMPv1 decoder, and others
>                     fail. That’s another argument in favor of Hendrik’s.
>
>                      
>
>                         On Aug 31, 2021, at 12:25 PM, Brockhaus,
>                         Hendrik <[email-masked]
>                         David's proposal will not compile.  The OSS
>                         compiler produces this error with that syntax:
>
>                          
>
>                            line 62 (TestModule): A0100E: Duplicate tag
>                         in type CertStatus: element 'statusInfo' (line
>                         61) and element 'hashAlg' (line 62).
>
>                          
>
>                         The reason for this error is that the two
>                         optional elements are both SEQUENCEs.  So,
>                         when decoding, if only one of the optional
>                         SEQUENCEs is present, it cannot figure out
>                         which one it is.
>
>                          
>
>                             On Aug 31, 2021, at 8:21 AM, Brockhaus,
>                             Hendrik <[email-masked]
>                             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:
>
>                             We are uncertain what the best approach
>                             from an ASN.1 syntax parsing perspective
>                             is. What is your opinion?
>
>                              
>
>                             Hendrik
>
>                              
>
>                              
>
>                                 *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:
>
>                                  
>
>                                 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
>                                 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.
>
>                                 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.
>
>                             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.
>                             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.
>
>                                  
>
>                             <https://urldefense.com/v3/__https:/eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Feur01.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm*26data*3D04*7C01*7Chendrik.brockhaus*40siemens.com*7C143aeb858f18456f4ef008d96c91b913*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637660195485199311*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000*26sdata*3D0zVGASW8q0wKP6L3y*2FDbArvhPZfu7N1dddePGJbIfHU*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!LoXbEbIyNev6LwqxU8VE7vr48hf8P9r65NL7ritq1xGlhzX0ww9Z6Z8rGDYc9yQx*24&data=04*7C01*7Chendrik.brockhaus*40siemens.com*7C0f53a2b88007496f716108d96edf4101*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637662727449199119*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=88KpSrVoiGaDMtBAJTCc6YZsfmiSUdXS0qccTphgud4*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqKiUlKioqKioqKioqKioqJSUqKiUlJSUlJSUlJSUlJSUlJSUl!!FJ-Y8qCqXTj2!Nz_C7tBrJ8IelJmdscBpLtz9VTsBCMoSHKyb2cH7sKIiqx5MWxovjd5F43tzKzrg$>
>
>                      
>
>                     Spasm mailing list [email-masked]
>                     <https://urldefense.com/v3/__https:/eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm__*3B!!FJ-Y8qCqXTj2!LoXbEbIyNev6LwqxU8VE7vr48hf8P9r65NL7ritq1xGlhzX0ww9Z6Z8rGOpMzia-*24&data=04*7C01*7Chendrik.brockhaus*40siemens.com*7C0f53a2b88007496f716108d96edf4101*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637662727449209115*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=IngMg4XxSQBzeq1J1PeYQR*2F6IeI9ipymAG8lOSMNqBk*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!Nz_C7tBrJ8IelJmdscBpLtz9VTsBCMoSHKyb2cH7sKIiqx5MWxovjd5F44j3tWy7$>
>
>                     /Any email and files/attachments transmitted with
>                     it are confidential and are intended solely for
>                     the use of the individual or entity to whom they
>                     are addressed. If this message has been sent to
>                     you in error, you must not copy, distribute or
>                     disclose of the information it contains. _Please
>                     notify Entrust immediately_ and delete the message
>                     from your system./
>
>                  
>
>                 <https://urldefense.com/v3/__https:/eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm&data=04*7C01*7Chendrik.brockhaus*40siemens.com*7C0f53a2b88007496f716108d96edf4101*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637662727449219116*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=pfhz*2Bph3xK4SN*2B9TAXHX5zoiV49xiIOssDmy6XcnaeI*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!FJ-Y8qCqXTj2!Nz_C7tBrJ8IelJmdscBpLtz9VTsBCMoSHKyb2cH7sKIiqx5MWxovjd5F43xZX7R3$>
>
>          
>
>  
>

---

From: Russ Housley <[email-masked]>
Date: Sun, 5 Sep 2021 10:00:47 -0400

Option 1 and 2 are both fine to me.  As I already said, I have a slight preference for option 2.  That is because the new field is at the end.

Russ

> On Sep 5, 2021, at 9:52 AM, David von Oheimb <[email-masked]> wrote:
> 
> John, Russ, Carl,
> 
> and proposal 1 has the clear conceptual advantage that the hashAlg field comes before the field that it governs: certHash.
> 
>     David
> 
> 
>> From: Brockhaus, Hendrik <[email-masked]> <mailto:[email-masked]> 
>> To: Russ Housley <[email-masked]> <mailto:[email-masked]>; David von Oheimb <[email-masked]> <mailto:[email-masked]>; Carl Wallace <[email-masked]> <mailto:[email-masked]>; Uri Blumenthal <[email-masked]> <mailto:[email-masked]>; John Gray <[email-masked]> <mailto:[email-masked]>
>> Cc: [email-masked] <mailto:[email-masked]>
>> Von: Spasm <[email-masked] <mailto:[email-masked]>> Im Auftrag von Russ Housley
>> On Sep 3, 2021, at 7:52 AM, David von Oheimb <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>>  
>> https://www.ietf.org/mailman/listinfo/spasm <https://urldefense.com/v3/__https:/eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Feur01.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm*26data*3D04*7C01*7Chendrik.brockhaus*40siemens.com*7C143aeb858f18456f4ef008d96c91b913*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637660195485199311*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000*26sdata*3D0zVGASW8q0wKP6L3y*2FDbArvhPZfu7N1dddePGJbIfHU*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!LoXbEbIyNev6LwqxU8VE7vr48hf8P9r65NL7ritq1xGlhzX0ww9Z6Z8rGDYc9yQx*24&data=04*7C01*7Chendrik.brockhaus*40siemens.com*7C0f53a2b88007496f716108d96edf4101*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637662727449199119*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=88KpSrVoiGaDMtBAJTCc6YZsfmiSUdXS0qccTphgud4*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqKiUlKioqKioqKioqKioqJSUqKiUlJSUlJSUlJSUlJSUlJSUl!!FJ-Y8qCqXTj2!Nz_C7tBrJ8IelJmdscBpLtz9VTsBCMoSHKyb2cH7sKIiqx5MWxovjd5F43tzKzrg$>
>>  
>> _______________________________________________ Spasm mailing list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/spasm <https://urldefense.com/v3/__https:/eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm__*3B!!FJ-Y8qCqXTj2!LoXbEbIyNev6LwqxU8VE7vr48hf8P9r65NL7ritq1xGlhzX0ww9Z6Z8rGOpMzia-*24&data=04*7C01*7Chendrik.brockhaus*40siemens.com*7C0f53a2b88007496f716108d96edf4101*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637662727449209115*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=IngMg4XxSQBzeq1J1PeYQR*2F6IeI9ipymAG8lOSMNqBk*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!Nz_C7tBrJ8IelJmdscBpLtz9VTsBCMoSHKyb2cH7sKIiqx5MWxovjd5F44j3tWy7$>
>> https://www.ietf.org/mailman/listinfo/spasm <https://urldefense.com/v3/__https:/eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fspasm&data=04*7C01*7Chendrik.brockhaus*40siemens.com*7C0f53a2b88007496f716108d96edf4101*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637662727449219116*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=pfhz*2Bph3xK4SN*2B9TAXHX5zoiV49xiIOssDmy6XcnaeI*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!FJ-Y8qCqXTj2!Nz_C7tBrJ8IelJmdscBpLtz9VTsBCMoSHKyb2cH7sKIiqx5MWxovjd5F43xZX7R3$>

---

From: Carl Wallace <[email-masked]>
Date: Sun, 5 Sep 2021 10:26:42 -0400

Option 2 plays nicer with EXTENSIBILITY IMPLIED (definition from X.680 is below). Not sure how often that is used though or how often folks manually insert extensibility markers at the end of definitions (I have on occasion but only in modules not controlled by a standard and to mixed results). 

‘ 12.4 The EXTENSIBILITY IMPLIED option is equivalent to the textual insertion of an extension marker ("...") in the definition of each type in the module for which it is permitted. The location of the implied extension marker is the last position in the type where an explicitly specified extension marker is allowed. The absence of EXTENSIBILITY IMPLIED means that extensibility is only provided for those types within the module where an extension marker is explicitly present.’

> On Sep 5, 2021, at 10:01 AM, Russ Housley <[email-masked]> wrote:
>

---

From: David von Oheimb <[email-masked]>
Date: Sun, 5 Sep 2021 16:49:13 +0200

On 05.09.21 16:26, Carl Wallace wrote:
> Option 2 plays nicer with EXTENSIBILITY IMPLIED (definition from X.680
> is below). Not sure how often that is used though or how often folks
> manually insert extensibility markers at the end of definitions (I
> have on occasion but only in modules not controlled by a standard and
> to mixed results). 
>
> ‘ 12.4 The EXTENSIBILITY IMPLIED option is equivalent to the textual
> insertion of an extension marker ("...") in the definition of each
> type in the module for which it is permitted. The location of the
> implied extension marker is the last position in the type where an
> explicitly specified extension marker is allowed. The absence of
> EXTENSIBILITY IMPLIED means that extensibility is only provided for
> those types within the module where an extension marker is explicitly
> present.’
Interesting. Yet the original definition (of CMPv2):

      }

does not have such an extensibility option.
So there is no advantage in terms of backward compatibility to have the
new optional hashAlg field at the end (over having it anywhere).

On 05.09.21 16:00, Russ Housley wrote:

> Option 1 and 2 are both fine to me.  As I already said, I have a
> slight preference for option 2.  That is because the new field is at
> the end.
I know you wrote that, but this does not explain why in your view it
would be (in total) slightly better to have the new field at the end,
although, as I just wrote again, it has the disadvantage that the fields
are not in logical order.
In other words: what do you see as the advantage(s) overweighing the
mentioned disadvantage?

      David

>>> On Sep 5, 2021, at 9:52 AM, David von Oheimb <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>>
>>> John, Russ, Carl,
>>>
>>> and proposal 1 has the clear conceptual advantage that the hashAlg
>>> field comes before the field that it governs: certHash.
>>>
>>>     David
>>>
>>>> You can add a ‘–‘ to proposal 3 from me as well.  It actually
>>>> changes the 4210 definition (when hashAlg) is not there, and would
>>>> add an extra bit of complexity in the ASN.1 parsing to handle
>>>> backwards compatibility for implementers that does not need to be
>>>> there…
>>>>  
>>>> Cheers,
>>>>  
>>>> John Gray
>>>>  
>>>>  
>>>>  
>>>> *To:* Russ Housley <[email-masked]>; David von
>>>> Oheimb <[email-masked]>; Carl
>>>> Wallace <[email-masked]>; Uri
>>>> *Subject:* [EXTERNAL] AW: [lamps] [CMP Updates] position of hashAlg
>>>> in certStatus
>>>>  
>>>> proposal 3, as it changes more than necessary and we look for
>>>> limited changes to CMP V2.
>>>>

---

From: Carl Wallace <[email-masked]>
Date: Sun, 5 Sep 2021 14:45:05 -0400

> On Sep 5, 2021, at 10:49 AM, David von Oheimb <[email-masked]> wrote:
> 
> 
> So there is no advantage in terms of backward compatibility to have the new optional hashAlg field at the end (over having it anywhere).
> 

Not per the definition in the spec. As with Russ I would favor adding to the end aside from the thin notion that it fits with non-standard extensibility marker usage.  

> I know you wrote that, but this does not explain why in your view it would be (in total) slightly better to have the new field at the end,
> although, as I just wrote again, it has the disadvantage that the fields are not in logical order. 
> In other words: what do you see as the advantage(s) overweighing the mentioned disadvantage?
> 
>       David
> 
>

---

From: David von Oheimb <[email-masked]>
Date: Sun, 5 Sep 2021 21:10:22 +0200

On 05.09.21 20:45, Carl Wallace wrote:
>>> Option 2 plays nicer with EXTENSIBILITY IMPLIED (definition from
>>> X.680 is below). Not sure how often that is used though or how often
>>> folks manually insert extensibility markers at the end of
>>> definitions (I have on occasion but only in modules not controlled
>>> by a standard and to mixed results). 
>>>
>>> those types within the module where an extension marker is
>>> explicitly present.’
>> So there is no advantage in terms of backward compatibility to have
>> the new optional hashAlg field at the end (over having it anywhere).
>>
>
> Not per the definition in the spec. As with Russ I would favor adding
> to the end aside from the thin notion that it fits with non-standard
> extensibility marker usage.
I see - then let's go for that since there was already a consensus on it.
Hendrik it also fine with proposal 2.

Cheers,

    David

>>>>>> changes the 4210 definition (when hashAlg) is not there, and
>>>>>> would add an extra bit of complexity in the ASN.1 parsing to
>>>>>> handle backwards compatibility for implementers that does not
>>>>>> need to be there…
>>>>>>  
>>>>>> Cheers,
>>>>>>  
>>>>>> John Gray

---

From: Russ Housley <[email-masked]>
Date: Sun, 5 Sep 2021 16:44:55 -0400

> In other words: what do you see as the advantage(s) overweighing the mentioned disadvantage?

I understand the situation.  I mildly prefer the new field at the end, but I am file with Options 1 and 2.

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 6 Sep 2021 15:49:36 +0000

*   So there is no advantage in terms of backward compatibility to have the new optional hashAlg field at the end (over having it anywhere).

Maybe not.  But there *is* a real advantage to writing the code.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 6 Sep 2021 15:56:42 +0000

> Maybe not.  But there *is* a real advantage to writing the code.
Having (probably) comparable amount of experience writing code and parsing (and encoding) ASN.1-based formats - respectfully disagree with the above. I see very little advantage there.