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

David von Oheimb <David.von.Oheimb@siemens.com> Tue, 31 August 2021 18:56 UTC

Return-Path: <David.von.Oheimb@siemens.com>
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 4AB143A0D78 for <spasm@ietfa.amsl.com>; Tue, 31 Aug 2021 11:56:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.795
X-Spam-Level:
X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 Z4_LnWKAzZyc for <spasm@ietfa.amsl.com>; Tue, 31 Aug 2021 11:56:22 -0700 (PDT)
Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64F563A0D3D for <spasm@ietf.org>; Tue, 31 Aug 2021 11:56:21 -0700 (PDT)
Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id 17VIuBDO010957 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 31 Aug 2021 20:56:12 +0200
Received: from [139.22.32.95] ([139.22.32.95]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 17VIuAUq021565; Tue, 31 Aug 2021 20:56:10 +0200
To: Carl Wallace <carl@redhoundsoftware.com>, "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>, "Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com>, Russ Housley <housley@vigilsec.com>, John Gray <John.Gray@entrust.com>
Cc: spasm@ietf.org
References: <2CEBEA79-AFAA-4166-88D0-26AB49332750@ll.mit.edu> <F01F29B3-B086-4E7E-AA5F-5C504D4F3156@redhoundsoftware.com>
From: David von Oheimb <David.von.Oheimb@siemens.com>
X-Enigmail-Draft-Status: N11100
Message-ID: <4659b1fb-bf01-fd95-bf39-e5ac192a1741@siemens.com>
Date: Tue, 31 Aug 2021 20:56:10 +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: <F01F29B3-B086-4E7E-AA5F-5C504D4F3156@redhoundsoftware.com>
Content-Type: multipart/alternative; boundary="------------B1008054700099B01221EDF6"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/WEhbwzWLNvl1T_oITzxqUr8G8k0>
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: Tue, 31 Aug 2021 18:56:31 -0000

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> 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>
>> *Date: *Tuesday, August 31, 2021 at 14:03
>> *To: *John Gray <John.Gray@entrust.com>om>, Uri Blumenthal
>> <uri@ll.mit.edu>du>, Russ Housley <housley@vigilsec.com>om>, "Brockhaus,
>> Hendrik" <hendrik.brockhaus@siemens.com>
>> *Cc: *"spasm@ietf.org" <spasm@ietf.org>rg>,
>> "david.von.oheimb@siemens.com" <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>
>> *Date: *Tuesday, August 31, 2021 at 1:37 PM
>> *To: *Carl Wallace <carl@redhoundsoftware.com>om>, "Blumenthal, Uri -
>> 0553 - MITLL" <uri@ll.mit.edu>du>, Russ Housley <housley@vigilsec.com>om>,
>> "Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com>
>> *Cc: *"spasm@ietf.org" <spasm@ietf.org>rg>,
>> "david.von.oheimb@siemens.com" <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>
>> *Sent:* Tuesday, August 31, 2021 1:28 PM
>> *To:* Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu>du>; Russ Housley
>> <housley@vigilsec.com>om>; Brockhaus, Hendrik
>> <hendrik.brockhaus@siemens.com>
>> *Cc:* spasm@ietf.org; david.von.oheimb@siemens.com; John Gray
>> <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://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*7C143aeb858f18456f4ef008d96c91b913*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637660195485199311*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=0zVGASW8q0wKP6L3y*2FDbArvhPZfu7N1dddePGJbIfHU*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!LoXbEbIyNev6LwqxU8VE7vr48hf8P9r65NL7ritq1xGlhzX0ww9Z6Z8rGDYc9yQx$>
>>
>>  
>>
>> _______________________________________________ Spasm mailing list
>> Spasm@ietf.org <mailto:Spasm@ietf.org>
>> https://www.ietf.org/mailman/listinfo/spasm
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!LoXbEbIyNev6LwqxU8VE7vr48hf8P9r65NL7ritq1xGlhzX0ww9Z6Z8rGOpMzia-$>
>>
>>
>> /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
> https://www.ietf.org/mailman/listinfo/spasm