Re: [lamps] Draft LAMPS Recharter

"Panos Kampanakis (pkampana)" <> Wed, 02 May 2018 20:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C92A12DA23 for <>; Wed, 2 May 2018 13:36:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZYspQSeblPd1 for <>; Wed, 2 May 2018 13:36:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4315412DA19 for <>; Wed, 2 May 2018 13:36:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=16449; q=dns/txt; s=iport; t=1525293382; x=1526502982; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=fbqgIt3655hI0wb0ZSpNlkjQu9eJl4D2kfEBUfEs0Ok=; b=m2p0kHwUGSeqewjio633ycm7qOmRs3rvzZyDVU1oNMGYMpEp3tnjIrWu BDrAJrkvfUAg6bAtTS9tQ+VG1VszmW1LON33frUpJB6QLcnpwsZlcprdz h2dpmr4sHiNvr0nnmg8UGRxlOHNPmXV6wp7eBs3GiAhL7a5KvcVb1Fxsl w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.49,354,1520899200"; d="scan'208,217";a="389498877"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2018 20:36:20 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w42KaKbD026005 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 May 2018 20:36:20 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 2 May 2018 15:36:19 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Wed, 2 May 2018 15:36:19 -0500
From: "Panos Kampanakis (pkampana)" <>
To: Russ Housley <>, LAMPS <>
Thread-Topic: [lamps] Draft LAMPS Recharter
Thread-Index: AQHT4iO4lXvBuNLFt0WqtxjiqculPqQcmsPA
Date: Wed, 02 May 2018 20:36:19 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_ade6bc1e860a4739b3e271f4e4752683XCHALN010ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [lamps] Draft LAMPS Recharter
X-Mailman-Version: 2.1.22
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: Wed, 02 May 2018 20:36:25 -0000

Hi Russ,

Looks great. One minor correction:
s/they will probably not be used for signing X.509 certificates or S/MIME messages,/they might not be used for signing X.509 certificates or S/MIME messages,

And one question about 4. I think I didn't see many comments on this one in the recharter email thread. I have a concern that draft-housley-cms-mix-with-psk will not see great deployment. draft-ietf-ipsecme-qr-ikev2 is similar, but given the existing IKEv2 wide deployment, draft-ietf-ipsecme-qr-ikev2 had to exist as temporary solution in order to prevent downgrades to IKEv1 because of QC concerns. I don't see the same issue for CMS. And given the challenge with establishing the PSK, it will likely not see wide adoption before the NIST PQ Project standardizes on PQ algorithms that can go into CMS.


From: Spasm [] On Behalf Of Russ Housley
Sent: Wednesday, May 02, 2018 10:42 AM
To: LAMPS <>
Subject: [lamps] Draft LAMPS Recharter

Based on the discussion in London and the "Potential Topics for LAMPS Recharter" mail thread.  We propose the attached charter text.  Please review and comment.

Russ & Tim

= = = = = = = = =

The PKIX and S/MIME Working Groups have been closed for some time. Some
updates have been proposed to the X.509 certificate documents produced
by the PKIX Working Group and the electronic mail security documents
produced by the S/MIME Working Group.

The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working
Group is chartered to make updates where there is a known constituency
interested in real deployment and there is at least one sufficiently
well specified approach to the update so that the working group can
sensibly evaluate whether to adopt a proposal.

The LAMPS WG is now tackling these topics:

1. Specify a discovery mechanism for CAA records to replace the one
described in RFC 6844.  Implementation experience has demonstrated an
ambiguity in the handling of CNAME and DNAME records during discovery
in RFC 6844, and subsequent discussion has suggested that a different
discovery approach would resolve limitations inherent in that approach.

2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME.
Unlike the previous hashing standards, the SHA-3 family of functions are
the outcome of an open competition.  They have a clear design rationale
and have received a lot of public analysis, giving great confidence that
the SHA-3 family of functions are secure.  Also, since SHA-3 uses a very
different construction from SHA-2, the SHA-3 family of functions offers
an excellent alternative.  In particular, SHAKE128/256 and SHAKE256/512
offer security and performance benefits.

3. Specify the use of short-lived X.509 certificates for which no
revocation information is made available by the Certification Authority.
Short-lived certificates have a lifespan that is shorter than the time
needed to detect, report, and distribute revocation information, as a
result revoking them pointless.

4. Specify the use of a pre-shared key (PSK) along with other key
management techniques with supported by the Cryptographic Message
Syntax (CMS) as a near-term mechanism to protect present day
communication from the future invention of a large-scale quantum
computer.  The invention of a such a quantum computer would pose a
serious challenge for the key management algorithms that are widely
deployed, especially the key transport and key agreement algorithms
used today with the CMS to protect S/MIME messages.

5. Specify the use of hash-based signatures with the Cryptographic
Message Syntax (CMS).  A hash-based signature uses small private and
public keys, and it has low computational cost; however, the signature
values are quite large.  For this reason they will probably not be used
for signing X.509 certificates or S/MIME messages, but they are secure
even if a large-scale quantum computer is invented.  These properties
make hash-based signatures useful in some environments, such a the
distribution of software updates.

6. Specifies a certificate extension that is carried in a self-signed
certificate for a trust anchor, which is often called a Root
Certification Authority (CA) certificate, to identify the next
public key that will be used by the trust anchor.

In addition, the LAMPS WG may investigate other updates to documents
produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt
any of these potential work items without rechartering.


Mar 2018: Adopt a draft for rfc6844bis
Apr 2018: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512
Apr 2018: Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512
Jun 2018: Adopt a draft for short-lived certificate conventions
Jun 2018: Adopt a draft for the CMS with PSK
Jun 2018: Adopt a draft for hash-based signatures with the CMS
Jun 2018: Adopt a draft for root key rollover certificate extension
Jul 2018: rfc6844bis sent to IESG for standards track publication
Aug 2018: Root key rollover certificate extension sent to IESG for
            informational publication
Sep 2018: SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for
            standards track publication
Sep 2018: SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for
            standards track publication
Oct 2018: Short-lived certificate conventions sent to IESG for BCP
Oct 2018: The CMS with PSK sent to IESG for standards track publication
Dec 2018: Hash-based signatures with the CMS sent to IESG for standards
            track publication