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

David von Oheimb <nl0@von-Oheimb.de> Fri, 03 September 2021 11:52 UTC

Return-Path: <nl0@von-Oheimb.de>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5482C3A1B94 for <spasm@ietfa.amsl.com>; Fri, 3 Sep 2021 04:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.797
X-Spam-Level:
X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDEZJ67UFpNc for <spasm@ietfa.amsl.com>; Fri, 3 Sep 2021 04:52:30 -0700 (PDT)
Received: from server8.webgo24.de (server8.webgo24.de [185.30.32.8]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEA7A3A1B78 for <spasm@ietf.org>; Fri, 3 Sep 2021 04:52:26 -0700 (PDT)
Received: from [192.168.8.100] (ip-109-40-3-152.web.vodafone.de [109.40.3.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by server8.webgo24.de (Postfix) with ESMTPSA id 93E48421908; Fri, 3 Sep 2021 13:52:22 +0200 (CEST)
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>, Russ Housley <housley@vigilsec.com>
Cc: "spasm@ietf.org" <spasm@ietf.org>, John Gray <John.Gray@entrust.com>, Carl Wallace <carl@redhoundsoftware.com>, "Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com>
References: <2CEBEA79-AFAA-4166-88D0-26AB49332750@ll.mit.edu> <F01F29B3-B086-4E7E-AA5F-5C504D4F3156@redhoundsoftware.com> <4659b1fb-bf01-fd95-bf39-e5ac192a1741@siemens.com> <EBD4A107-6E1D-4832-B050-8468D5F20681@redhoundsoftware.com> <AM0PR10MB241867FEC0AF8ED504546B56FECD9@AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM> <26092A46-708C-450A-BE81-A45380431239@ll.mit.edu> <77FCA0C1-F3C0-4D8D-9D21-B5A46E6B6B5A@vigilsec.com> <0F3E891F-7892-49CF-8F88-0C4484591EB0@ll.mit.edu>
From: David von Oheimb <nl0@von-Oheimb.de>
Message-ID: <db81b1c4-e2a7-060d-80a0-55b99b536f27@von-Oheimb.de>
Date: Fri, 3 Sep 2021 13:52:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <0F3E891F-7892-49CF-8F88-0C4484591EB0@ll.mit.edu>
Content-Type: multipart/alternative; boundary="------------4B4D493E89BBAA39C0F61E76"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/76FCpPbCGFhiwm8zuTjXnps53_4>
Subject: Re: [lamps] [CMP Updates] position of hashAlg in certStatus
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Sep 2021 11:52:43 -0000

> 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
>     <uri@ll.mit.edu <mailto:uri@ll.mit.edu>> 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" <hendrik.brockhaus@siemens.com
>     <mailto:hendrik.brockhaus@siemens.com>>
>     *Date: *Wednesday, September 1, 2021 at 11:01
>     *To: *Carl Wallace <carl@redhoundsoftware.com
>     <mailto:carl@redhoundsoftware.com>>, "david.von.oheimb@siemens.com
>     <mailto:david.von.oheimb@siemens.com>"
>     <david.von.oheimb@siemens.com
>     <mailto:david.von.oheimb@siemens.com>>, Uri Blumenthal
>     <uri@ll.mit.edu <mailto:uri@ll.mit.edu>>, Russ Housley
>     <housley@vigilsec.com <mailto:housley@vigilsec.com>>, John Gray
>     <John.Gray@entrust.com <mailto:John.Gray@entrust.com>>
>     *Cc: *"spasm@ietf.org <mailto:spasm@ietf.org>" <spasm@ietf.org
>     <mailto:spasm@ietf.org>>
>     *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 <spasm-bounces@ietf.org
>     <mailto:spasm-bounces@ietf.org>> *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 <David.von.Oheimb@siemens.com
>     <mailto:David.von.Oheimb@siemens.com>>
>     *Date: *Tuesday, August 31, 2021 at 2:56 PM
>     *To: *Carl Wallace <carl@redhoundsoftware.com
>     <mailto:carl@redhoundsoftware.com>>, "Blumenthal, Uri - 0553 -
>     MITLL" <uri@ll.mit.edu <mailto:uri@ll.mit.edu>>, "Brockhaus,
>     Hendrik" <hendrik.brockhaus@siemens.com
>     <mailto:hendrik.brockhaus@siemens.com>>, Russ Housley
>     <housley@vigilsec.com <mailto:housley@vigilsec.com>>, John Gray
>     <John.Gray@entrust.com <mailto:John.Gray@entrust.com>>
>     *Cc: *<spasm@ietf.org <mailto:spasm@ietf.org>>
>     *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 <uri@ll.mit.edu> <mailto:uri@ll.mit.edu> 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 <carl@redhoundsoftware.com>
>             <mailto:carl@redhoundsoftware.com>
>             *Date: *Tuesday, August 31, 2021 at 14:03
>             *To: *John Gray <John.Gray@entrust.com>
>             <mailto:John.Gray@entrust.com>, Uri
>             Blumenthal <uri@ll.mit.edu> <mailto:uri@ll.mit.edu>, Russ
>             Housley <housley@vigilsec.com>
>             <mailto:housley@vigilsec.com>, "Brockhaus,
>             Hendrik" <hendrik.brockhaus@siemens.com>
>             <mailto:hendrik.brockhaus@siemens.com>
>             *Cc: *"spasm@ietf.org"
>             <mailto:spasm@ietf.org> <spasm@ietf.org>
>             <mailto:spasm@ietf.org>, "david.von.oheimb@siemens.com"
>             <mailto:david.von.oheimb@siemens.com> <david.von.oheimb@siemens.com>
>             <mailto:david.von.oheimb@siemens.com>
>             *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 <John.Gray@entrust.com>
>             <mailto:John.Gray@entrust.com>
>             *Date: *Tuesday, August 31, 2021 at 1:37 PM
>             *To: *Carl Wallace <carl@redhoundsoftware.com>
>             <mailto:carl@redhoundsoftware.com>, "Blumenthal, Uri -
>             0553 - MITLL" <uri@ll.mit.edu> <mailto:uri@ll.mit.edu>,
>             Russ Housley <housley@vigilsec.com>
>             <mailto:housley@vigilsec.com>, "Brockhaus,
>             Hendrik" <hendrik.brockhaus@siemens.com>
>             <mailto:hendrik.brockhaus@siemens.com>
>             *Cc: *"spasm@ietf.org"
>             <mailto:spasm@ietf.org> <spasm@ietf.org>
>             <mailto:spasm@ietf.org>, "david.von.oheimb@siemens.com"
>             <mailto:david.von.oheimb@siemens.com> <david.von.oheimb@siemens.com>
>             <mailto:david.von.oheimb@siemens.com>
>             *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 <carl@redhoundsoftware.com>
>             <mailto:carl@redhoundsoftware.com> 
>             *Sent:* Tuesday, August 31, 2021 1:28 PM
>             *To:* Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu>
>             <mailto:uri@ll.mit.edu>; Russ
>             Housley <housley@vigilsec.com>
>             <mailto:housley@vigilsec.com>; Brockhaus,
>             Hendrik <hendrik.brockhaus@siemens.com>
>             <mailto:hendrik.brockhaus@siemens.com>
>             *Cc:* spasm@ietf.org
>             <mailto:spasm@ietf.org>; david.von.oheimb@siemens.com
>             <mailto:david.von.oheimb@siemens.com>; John
>             Gray <John.Gray@entrust.com> <mailto:John.Gray@entrust.com>
>             *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 <spasm-bounces@ietf.org
>             <mailto:spasm-bounces@ietf.org>> on behalf of "Blumenthal,
>             Uri - 0553 - MITLL" <uri@ll.mit.edu <mailto:uri@ll.mit.edu>>
>             *Date: *Tuesday, August 31, 2021 at 12:38 PM
>             *To: *Russ Housley <housley@vigilsec.com
>             <mailto:housley@vigilsec.com>>, "Brockhaus, Hendrik"
>             <hendrik.brockhaus@siemens.com
>             <mailto:hendrik.brockhaus@siemens.com>>
>             *Cc: *"spasm@ietf.org <mailto:spasm@ietf.org>"
>             <spasm@ietf.org <mailto:spasm@ietf.org>>,
>             "david.von.oheimb@siemens.com
>             <mailto:david.von.oheimb@siemens.com>"
>             <david.von.oheimb@siemens.com
>             <mailto:david.von.oheimb@siemens.com>>, John Gray
>             <John.Gray@entrust.com <mailto:John.Gray@entrust.com>>
>             *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
>                 <hendrik.brockhaus@siemens.com
>                 <mailto:hendrik.brockhaus@siemens.com>> 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)
>                 <hendrik.brockhaus@siemens.com
>                 <mailto:hendrik.brockhaus@siemens.com>>
>
>                  
>
>                 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
>                     <hendrik.brockhaus@siemens.com
>                     <mailto:hendrik.brockhaus@siemens.com>> 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 <John.Gray@entrust.com
>                     <mailto:John.Gray@entrust.com>>
>
>                     *Von:* David von Oheimb
>                     <David.von.Oheimb@siemens.com
>                     <mailto:David.von.Oheimb@siemens.com>> 
>                     *Gesendet:* Donnerstag, 26. August 2021 22:43
>                     *An:* John Gray <John.Gray@entrust.com
>                     <mailto:John.Gray@entrust.com>>
>
>                     On 26.08.21 11:26, Brockhaus, Hendrik (T RDA CST
>                     SEA-DE) wrote:
>
>                          
>
>                         *Von:* John Gray <John.Gray@entrust.com>
>                         <mailto:John.Gray@entrust.com> 
>                         *Gesendet:* Mittwoch, 25. August 2021 18:35
>                         *An:* von Oheimb, David (T RDA CST
>                         SEA-DE) <david.von.oheimb@siemens.com>
>                         <mailto:david.von.oheimb@siemens.com>;
>                         Brockhaus, Hendrik (T RDA CST
>                         SEA-DE) <hendrik.brockhaus@siemens.com>
>                         <mailto:hendrik.brockhaus@siemens.com>
>                         *Cc:* ietf-hendrikb@h.mailbouncer.info
>                         <mailto:ietf-hendrikb@h.mailbouncer.info>;
>                         Kretschmer, Andreas (T RDA CST
>                         SEA-DE) <andreas.kretschmer@siemens.com>
>                         <mailto:andreas.kretschmer@siemens.com>
>                         *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
>                     Spasm@ietf.org <mailto:Spasm@ietf.org>
>                     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 Spasm@ietf.org
>             <mailto:Spasm@ietf.org> 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
>
>         Spasm@ietf.org <mailto:Spasm@ietf.org>
>
>         https://www.ietf.org/mailman/listinfo/spasm <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C22b22e605bb74452459a08d96cb30447%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637660338422920390%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fzrs1wW9G%2BhCAtwNV9TTJridHaUW8yFLx2%2FNkuI4%2BHU%3D&reserved=0>
>
>  
>