Skip to main content

Limited Additional Mechanisms for PKIX and SMIME
charter-ietf-lamps-02-01

The information below is for an older proposed charter
Document Proposed charter Limited Additional Mechanisms for PKIX and SMIME WG (lamps) Snapshot
Title Limited Additional Mechanisms for PKIX and SMIME
Last updated 2018-07-06
State External Review (Message to Community, Selected by Secretariat) Rechartering
WG State Active
IESG Responsible AD Deb Cooley
Charter edit AD Eric Rescorla
Send notices to (None)

charter-ietf-lamps-02-01

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