Subject: WG Action: Rechartered Limited Additional Mechanisms for PKIX and SMIME (lamps)

From: The IESG <[email-masked]>
Date: Fri, 17 May 2019 10:53:13 -0700

The Limited Additional Mechanisms for PKIX and SMIME (lamps) WG in the
Security Area of the IETF has been rechartered. For additional information,
please contact the Area Directors or the WG Chairs.

Limited Additional Mechanisms for PKIX and SMIME (lamps)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
  Russ Housley <[email-masked]>
  Tim Hollebeek <[email-masked]>

Assigned Area Director:
  Roman Danyliw <[email-masked]>

Security Area Directors:
  Benjamin Kaduk <[email-masked]>
  Roman Danyliw <[email-masked]>

Mailing list:
  Address: [email-masked]
  To subscribe: https://www.ietf.org/mailman/listinfo/spasm
  Archive: https://mailarchive.ietf.org/arch/browse/spasm/

Group page: https://datatracker.ietf.org/group/lamps/

Charter: https://datatracker.ietf.org/doc/charter-ietf-lamps/

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 the approach
used in RFC 6844.

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 short-lived certificates is unnecessary and 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 mechanism to protect present day communication from
the future invention of a large-scale quantum computer.  The invention
of a large-scale quantum computer poses a serious challenge for the key
management algorithms that are widely deployed today, 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).  Hash-based signature use small private and
public keys, and they have low computational cost; however, the
signature values are quite large.  For this reason they might not be
used for signing X.509 certificates or S/MIME messages; however, since
hash-based signature algorithms are secure even if a large-scale
quantum computer is invented.  The low computational cost for
signature verification makes hash-based signatures attractive in the
Internt of Things environments, and the quantum resistance makes them
attractive for the distribution of software updates.

6. Specify 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.

7. Update the specification for the cryptographic protection of email
headers -- both for signatures and encryption -- to improve the
implementation situation with respect to privacy, security, usability
and interoperability in cryptographically-protected electronic mail.
Most current implementations of cryptographically-protected electronic
mail protect only the body of the message, which leaves significant
room for attacks against otherwise-protected messages.

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.

Milestones:

  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
  publication

  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