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

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

> 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://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 [e-mail]
>             <mailto:[e-mail]> 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
>
>         [e-mail] <mailto:[e-mail]>
>
>         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>
>
>  
>