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

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

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:
>
> 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 <[e-mail]>
> *Sent:* Friday, September 3, 2021 11:25 AM
> *To:* Russ Housley <[e-mail]>; David von Oheimb
> <[e-mail]>; Carl Wallace <[e-mail]>; Uri
> Blumenthal <[e-mail]>; John Gray <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* [EXTERNAL] AW: [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.
>
> ------------------------------------------------------------------------
>
> 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):
>
>    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
>       }
>
> Proposal 3 (preferred by Uri):
>
>    CertStatus ::= SEQUENCE {
>       certHash       OCTET STRING,
>       certReqId      INTEGER,
>       statusInfo [0] PKIStatusInfo OPTIONAL,
>       hashAlg    [1] AlgorithmIdentifier OPTIONAL
>       }
>
> 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 <[e-mail] <mailto:[e-mail]>>
> *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
>
>  
>
>  
>
>     On Sep 3, 2021, at 7:52 AM, David von Oheimb <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>      
>
>      
>
>         I think the fields that carry forward from CMPv1 should have
>         the same tags that they do in CMPv1.
>
>      
>
>         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
>
>              CertStatus ::= SEQUENCE {
>
>                 certHash    OCTET STRING,
>
>                 certReqId   INTEGER,
>
>                 statusInfo  PKIStatusInfo OPTIONAL
>
>              }
>
>      
>
>     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 <[e-mail] <mailto:[e-mail]>> wrote:
>
>              
>
>             Here’s my preference:
>
>              
>
>                CertStatus ::= SEQUENCE {
>
>                   certHash        OCTET STRING,
>
>                   certReqId       INTEGER,
>
>                   statusInfo [0]  PKIStatusInfo OPTIONAL,
>
>                   hashAlg    [1]  AlgorithmIdentifier OPTIONAL
>
>                }
>
>              
>
>              
>
>             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"
>             <[e-mail]
>             <mailto:[e-mail]>>
>             *Date: *Wednesday, September 1, 2021 at 11:01
>             *To: *Carl Wallace <[e-mail]
>             <mailto:[e-mail]>>,
>             "[e-mail]
>             <mailto:[e-mail]>"
>             <[e-mail]
>             <mailto:[e-mail]>>, Uri Blumenthal
>             <[e-mail] <mailto:[e-mail]>>, Russ Housley
>             <[e-mail] <mailto:[e-mail]>>, John
>             Gray <[e-mail] <mailto:[e-mail]>>
>             *Cc: *"[e-mail] <mailto:[e-mail]>"
>             <[e-mail] <mailto:[e-mail]>>
>             *Subject: *AW: [lamps] [CMP Updates] position of hashAlg
>             in certStatus
>
>              
>
>             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 <[e-mail]
>             <mailto:[e-mail]>> *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 <[e-mail]
>             <mailto:[e-mail]>>
>             *Date: *Tuesday, August 31, 2021 at 2:56 PM
>             *To: *Carl Wallace <[e-mail]
>             <mailto:[e-mail]>>, "Blumenthal, Uri -
>             0553 - MITLL" <[e-mail] <mailto:[e-mail]>>,
>             "Brockhaus, Hendrik" <[e-mail]
>             <mailto:[e-mail]>>, Russ Housley
>             <[e-mail] <mailto:[e-mail]>>, John
>             Gray <[e-mail] <mailto:[e-mail]>>
>             *Cc: *<[e-mail] <mailto:[e-mail]>>
>             *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 <[e-mail]>
>                     <mailto:[e-mail]> 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 <[e-mail]>
>                     <mailto:[e-mail]>
>                     *Date: *Tuesday, August 31, 2021 at 14:03
>                     *To: *John Gray <[e-mail]>
>                     <mailto:[e-mail]>, Uri
>                     Blumenthal <[e-mail]>
>                     <mailto:[e-mail]>, Russ
>                     Housley <[e-mail]>
>                     <mailto:[e-mail]>, "Brockhaus,
>                     Hendrik" <[e-mail]>
>                     <mailto:[e-mail]>
>                     *Cc: *"[e-mail]"
>                     <mailto:[e-mail]> <[e-mail]>
>                     <mailto:[e-mail]>, "[e-mail]"
>                     <mailto:[e-mail]> <[e-mail]>
>                     <mailto:[e-mail]>
>                     *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 <[e-mail]>
>                     <mailto:[e-mail]>
>                     *Date: *Tuesday, August 31, 2021 at 1:37 PM
>                     *To: *Carl Wallace <[e-mail]>
>                     <mailto:[e-mail]>, "Blumenthal,
>                     Uri - 0553 - MITLL" <[e-mail]>
>                     <mailto:[e-mail]>, Russ
>                     Housley <[e-mail]>
>                     <mailto:[e-mail]>, "Brockhaus,
>                     Hendrik" <[e-mail]>
>                     <mailto:[e-mail]>
>                     *Cc: *"[e-mail]"
>                     <mailto:[e-mail]> <[e-mail]>
>                     <mailto:[e-mail]>, "[e-mail]"
>                     <mailto:[e-mail]> <[e-mail]>
>                     <mailto:[e-mail]>
>                     *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 <[e-mail]>
>                     <mailto:[e-mail]> 
>                     *Sent:* Tuesday, August 31, 2021 1:28 PM
>                     *To:* Blumenthal, Uri - 0553 -
>                     MITLL <[e-mail]> <mailto:[e-mail]>;
>                     Russ Housley <[e-mail]>
>                     <mailto:[e-mail]>; Brockhaus,
>                     Hendrik <[e-mail]>
>                     <mailto:[e-mail]>
>                     *Cc:* [e-mail]
>                     <mailto:[e-mail]>; [e-mail]
>                     <mailto:[e-mail]>; John
>                     Gray <[e-mail]>
>                     <mailto:[e-mail]>
>                     *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 <[e-mail]
>                     <mailto:[e-mail]>> on behalf of
>                     "Blumenthal, Uri - 0553 - MITLL" <[e-mail]
>                     <mailto:[e-mail]>>
>                     *Date: *Tuesday, August 31, 2021 at 12:38 PM
>                     *To: *Russ Housley <[e-mail]
>                     <mailto:[e-mail]>>, "Brockhaus,
>                     Hendrik" <[e-mail]
>                     <mailto:[e-mail]>>
>                     *Cc: *"[e-mail] <mailto:[e-mail]>"
>                     <[e-mail] <mailto:[e-mail]>>,
>                     "[e-mail]
>                     <mailto:[e-mail]>"
>                     <[e-mail]
>                     <mailto:[e-mail]>>, John Gray
>                     <[e-mail] <mailto:[e-mail]>>
>                     *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 <[e-mail]
>                         <mailto:[e-mail]>> 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)
>                         <[e-mail]
>                         <mailto:[e-mail]>>
>
>                          
>
>                         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 <[e-mail]
>                             <mailto:[e-mail]>> 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 <[e-mail]
>                             <mailto:[e-mail]>>
>
>                             *Von:* David von Oheimb
>                             <[e-mail]
>                             <mailto:[e-mail]>> 
>                             *Gesendet:* Donnerstag, 26. August 2021 22:43
>                             *An:* John Gray <[e-mail]
>                             <mailto:[e-mail]>>
>
>                             On 26.08.21 11:26, Brockhaus, Hendrik (T
>                             RDA CST SEA-DE) wrote:
>
>                                  
>
>                                 *Von:* John
>                                 Gray <[e-mail]>
>                                 <mailto:[e-mail]> 
>                                 *Gesendet:* Mittwoch, 25. August 2021
>                                 18:35
>                                 *An:* von Oheimb, David (T RDA CST
>                                 SEA-DE) <[e-mail]>
>                                 <mailto:[e-mail]>;
>                                 Brockhaus, Hendrik (T RDA CST
>                                 SEA-DE) <[e-mail]>
>                                 <mailto:[e-mail]>
>                                 *Cc:* [e-mail]
>                                 <mailto:[e-mail]>;
>                                 Kretschmer, Andreas (T RDA CST
>                                 SEA-DE) <[e-mail]>
>                                 <mailto:[e-mail]>
>                                 *Betreff:* RE: [EXTERNAL] Re: CMP
>                                 Updates and Lightweight CMP Profile
>
>                                  
>
>                                 Thanks for the updates.
>
>                                  
>
>                                 I continued to review the document
>                                 today as well.   Here are some more
>                                 comments:
>
>                                  
>
>                                 Section 2.10 -  CertStatus update.  I
>                                 was wondering if adding the optional
>                                 tagged element as the last element
>                                 **might** make a difference:
>
>                                  
>
>                                 For now it is defined as:
>
>                                  
>
>                                 Replace the ASN.1 Syntax of CertStatus
>                                 with the following text:
>
>                                  
>
>                                       CertStatus ::= SEQUENCE {
>
>                                          hashAlg [0]
>                                 AlgorithmIdentifier OPTIONAL,
>
>                                          certHash    OCTET STRING,
>
>                                          certReqId   INTEGER,
>
>                                          statusInfo  PKIStatusInfo
>                                 OPTIONAL
>
>                                       }
>
>                                  
>
>                                  
>
>                                 I would have expected that adding
>                                 something new would be added like this:
>
>                                  
>
>                                 Replace the ASN.1 Syntax of CertStatus
>                                 with the following text:
>
>                                  
>
>                                       CertStatus ::= SEQUENCE {
>
>                                          certHash    OCTET STRING,
>
>                                          certReqId   INTEGER,
>
>                                          statusInfo  PKIStatusInfo
>                                 OPTIONAL,
>
>                                          hashAlg [0]
>                                 AlgorithmIdentifier OPTIONAL
>
>                                       }
>
>                                  
>
>                                 If a CMPv2 server received the hashAlg
>                                 as the last element, it might still
>                                 work, but would fail in the first
>                                 case.   However, I know you say if the
>                                 hashAlg is included then it must use
>                                 the pvno of version 3, so the order
>                                 doesn’t really matter.   I just
>                                 thought that for someone implementing
>                                 it, it might be a bit easier to check
>                                 if the tag exists after the existing
>                                 parsing (at the end), rather than
>                                 checking if it exists on the first
>                                 element.  It would mean no parsing
>                                 logic has to change until it reaches
>                                 the last element.   However, I suppose
>                                 the counter argument would be that if
>                                 hashAlg is included first, but it
>                                 isn’t supported then an older server
>                                 would fail faster which is probably a
>                                 desirable property.       
>
>                                  
>
>                                 [Bro] This is a interesting point we
>                                 also thought about. Here are some
>                                 thoughts we had.
>
>                                 First of all, we think the binary
>                                 ASN.1 of a certConf message produced
>                                 by a client only knowing the original
>                                 cmp2000 without hashAlg does not
>                                 differ between from a client knowing
>                                 the hashAlg field, but not using it. 
>                                 This should be the case when placing
>                                 the hashAlg field at the first as well
>                                 as at the last position of the sequence.
>
>                                 Second, we took the OOBCertHash type
>                                 as an example and therefore decided
>                                 for placing the hashAlg field also at
>                                 the first position.
>
>                                         OOBCertHash ::= SEQUENCE {
>
>                                             hashAlg     [0]
>                                 AlgorithmIdentifier     OPTIONAL,
>
>                                             certId      [1]
>                                 CertId                  OPTIONAL,
>
>                                             hashVal         BIT STRING
>
>                                         }
>
>                                 Third, the hash algorithm OID is
>                                 required before calculating the hash
>                                 value. Therefore, it is the logical
>                                 order to have hashAlg first.
>
>                                 Theses were the thoughts we had for
>                                 placing hashAlg in the first position,
>                                 but they are no strict reasons to do
>                                 it this way round. 
>                                 I cannot say, if your arguments still
>                                 hold true from an implementation
>                                 perspective. @David, maybe you can
>                                 comment on the more implementation
>                                 related issues.
>
>                             I am not an ASN.1 expert, but as far as I
>                             understand from using its OpenSSL
>                             implementation, it should not make much
>                             difference whether to fail earlier or
>                             later in case the bits do not fit with the
>                             expected structure.
>                             At least for the CMP implementation, which
>                             simply uses the ASN.1 parser, there would
>                             be no noticeable difference since either
>                             the parsing of the whole structure
>                             (including its total sequence length)
>                             succeeds or not.
>                             If a receiver expects a structure encoded
>                             as in CMPv2 but gets an encoding for
>                             CMPv3, I think due to the presence of the
>                             "[0]" tag, parsing will fail even if the
>                             hashAlg fields is at the end with not
>                             value being present.
>                             A backward-compatible definition might
>                             look like this:
>
>                                   CertStatus ::= SEQUENCE {
>
>                                      certHash    OCTET STRING,
>
>                                      certReqId   INTEGER,
>
>                                      statusInfo  PKIStatusInfo OPTIONAL,
>
>                                      hashAlg     AlgorithmIdentifier
>                             OPTIONAL
>
>                                   }
>
>                             but supposedly we cannot do this because
>                             it would be ambiguous whether the optional
>                             statusInfo or hashAlg field is present.
>                             To me, the main point is a conceptual one:
>                             the hashAlg needs to "seen" before the
>                             certHash, so it is logical to have them in
>                             this order.
>
>                             [Bro] I am also no ASN.1 expert, but Russ
>                             is. Therefore, I will forward the question
>                             to him to get his advice. As statusInfo
>                             and hashAlg have different types, it may
>                             also work without tagging.
>
>                                  
>
>                             _______________________________________________
>                             Spasm mailing list
>                             [e-mail] <mailto:[e-mail]>
>                             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 [e-mail]
>                     <mailto:[e-mail]> 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
>
>                 [e-mail] <mailto:[e-mail]>
>
>                 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$>
>
>          
>
>  
>