Re: [lamps] LAMPS at IETF 105

"Dr. Pala" <> Thu, 02 May 2019 18:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 62F3B120075 for <>; Thu, 2 May 2019 11:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dAx5RAkr8YUA for <>; Thu, 2 May 2019 11:53:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 110AD120004 for <>; Thu, 2 May 2019 11:53:48 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTP id D4B113740876 for <>; Thu, 2 May 2019 18:53:47 +0000 (UTC)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id HImi9rEJty-G for <>; Thu, 2 May 2019 14:53:46 -0400 (EDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1F3083740828 for <>; Thu, 2 May 2019 14:53:46 -0400 (EDT)
References: <> <> <> <> <> <>
From: "Dr. Pala" <>
Message-ID: <>
Date: Thu, 2 May 2019 12:53:45 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------77FB2064BE172999C455BDDF"
Content-Language: en-US
Archived-At: <>
Subject: Re: [lamps] LAMPS at IETF 105
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 May 2019 18:53:51 -0000

Hi Russ,

I was just reviewing it [*] and I do not think it does. I was thinking 
that if the WG will be interested in the adoption of the document, then 
we will have to explicitly add a new entry to the list of items in the 

I am thinking that the entry might look like the following (but not 
proposing the re-chartering before the group reviews the combined draft):

    Specify the use of composite signatures and keys for PKIX. In recent years,
    the crypto communities have been very active in identifying new public key
    algorithms with different security properties and performances (e.g., ECC,
    Hash-Based, etc.). However, it is not always easy to establish if a new
    algorithm has been studied enough or if (and when) an old algorithm might
    fall apart. An example of this uncertainty, today, is related to quantum-resistant
    algorithms vs. "traditional" ones. The possibility for combining algorithms
    with different properties provides support for less risky transitioning strategies
    for deploying new algorithms by enabling deferred algorithm agility.

This is just an example of the required additional item for the charter 
to get the work in scope, I guess :D


[*] =

On 5/2/19 2:07 PM, Russ Housley wrote:
> Max:
> Do you believe that the current charter covers you proposed way forward?
> Russ
>> On May 2, 2019, at 1:04 PM, Dr. Pala < 
>> <>> wrote:
>> Hi Russ, Tim, all,
>> On the Composite Crypto discussion at the last IETF, I think we will 
>> be ready to present on the unified draft proposal that we would like 
>> to discuss in LAMPS and, if we are ready, look into asking for 
>> adoption of the document.
>> Cheers,
>> Max
>> On 4/23/19 5:10 PM, Russ Housley wrote:
>>> In the last few days before IETF 104, we got a flurry of requests to present in the LAMPS WG.  In an effort to learn about them sooner, we are asking whether anyone has topics to discuss in July at IETF 105.  The IESG is going through the re-charter process, so we can assume that the header protection work item will be approved by the time that we meet in July.
>>> Russ & Tim
> _______________________________________________
> Spasm mailing list
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo