Minutes IETF102: lamps
minutes-102-lamps-00

LAMPS Session at IETF 102
Thursday, 19 July 2019 at 15:50

Executive Summary

The documents related to internationalized email addresses in
certificates have been published as standards-track RFCs.  The
S/MIME 4.0 documents with the IESG, and the last open issues were
resolved; tesy should be sent to the RFC Editor soon.  Work on
rfc6844bis is progressing.  The addition of the SHAKE128/256 and
SHAKE256/512 algorithms for PKIX and S/MIME is progressing is ready
for WG Last Call.  Four new work items were chartered, a call for
adoption is under way for each of them.


0)  Minute Taker, Jabber Scribe, Bluesheets

Russ Housley is taking notes.
Rich Salz is Jabber Scribe.


1)  Agenda Bash

No agenda changes.


2)  Documents in the RFC Editor's Queue
    a)  draft-ietf-lamps-rfc5280-i18n-update
    b)  draft-ietf-lamps-eai-addresses

No concerns were raised on these documents.


3)  Documents that have been sent to the IESG
    a)  draft-ietf-lamps-rfc5750-bis
    b)  draft-ietf-lamps-rfc5751-bis

These documents received comments as part of IESG evaluation; all of
them have been addressed.  The Security AD has been asked to push the
documents to the RFC Editor.


3)  Active Working Group Documents
    a)  draft-ietf-lamps-rfc6844bis (Jacob and Phillip)

Once approved, this document will obsolete RFC 6844.  It modifies the
tree climbing algorithm, and it specifies a simplified processing
algorithm that only performs tree climbing on the domain being
processed, leaving processing of CNAMEs and DNAMEs to the CA's
recursive resolver.  Also, the ABNF grammer for issue and issuewild
are clarified.

There is a proposal on the mail list to resurrect the policy tag;
the discussion will continue on the mail list.


3)  Active Working Group Documents
    b)  draft-ietf-lamps-pkix-shake (Panos and Quynh)
    c)  draft-ietf-lamps-cms-shakes (Quynh and Panos)

Updated Internet-Drafts implement the discussion from the last meeting
in London: the use of a single object identifier to name RSASSA-PSS and
all of the associated parameters.  This approach leads to the assignment
of just two object identifiers, one for RSASSA-PSS with SHAKE128/256,
and another one for RSASSA-PSS with SHAKE256/512.

Quynh Dang asked for WG Last Call.  NIST will assign the needed object
identifiers once the document is approved.


4)  Documents Related to the Recharter
    a)  draft-housley-cms-mts-hash-sig (Russ)

A WG call for adoption is underway.  This document specifies the CMS
conventions for using the hash-based signature algorithm that is
specified in draft-mcgrew-hash-sigs-11.  The CFRG has completed RG
Last Call on that document, and it should go to the RFC Editor soon.

Since Russ is the author of this document, Tim will make all LAMPS WG
consensus calls related to this document.


4)  Documents Related to the Recharter
    b)  draft-housley-cms-mix-with-psk (Russ)

A WG call for adoption is underway.  This document specifies the CMS
conventions for two quantum-resistant ways to establish encryption
keys.  In both cases, a pre-shared key (PSK) is distributed to the
sender and all of the recipients by some out-of-band means that does
not make it vulnerable to the future invention of a large-scale
quantum computer, and an identifier must be assigned to the PSK.
The document supports key transport (for RSA-like algorithms) and
key agreement (for Diffie-Hellman-like algorithms).

Since Russ is the author of this document, Tim will make all LAMPS WG
consensus calls related to this document.


4)  Documents Related to the Recharter
    c)  draft-housley-hash-of-root-key-cert-extn (Russ)

A WG call for adoption is underway.  This document specifies a
certificate extension carried in the self-signed certificate for a
trust anchor to identify the next public key that will be used by
the trust anchor.  The slides show an overview of the technique and
the ASN.1 syntax of the extension.

The pros and cons associated with the certificate extension were
discussed.  The conclusions from that discussion should be captured
in the next version of the document.

Since Russ is the author of this document, Tim will make all LAMPS WG
consensus calls related to this informational document.


4)  Documents Related to the Recharter
    d)  draft-nir-saag-star (Yoav)

A WG call for adoption is underway.  This document is about Short-Term
Auto-Renewed (STAR) certificates.  There is no revocation information
for these certificates, and the short validity period of makes this
acceptable.  The automatic issuance of replacement certificates
overcomes the operational challenges of short-term certificates.
Two use cases are driving this work: IPsec VPNs and software-defined
storage.  These certificate might not be suitable for the Web PKI.

Many people in the room felt that an extension for that tells the
relying party that no revocation information is available is needed.
The authors feel that such an extension should be defined in another
document; this document should remain a BCP.

Some people felt that these certificates should point to an empty CRL
and a similar OCSP responder so that anyone looking for revocation
information would not get a failure.

Some people felt that the WG should not adopt this document until
it addresses thes two topics.


5)  Other Business (if time allows)
    a)  Header protection and S/MIME (Alexey)

Most S/MIME implementations do not encrypt or sign the message header.
The message header fields can contain sensitive information that needs
hiding, integrity protection, or both.  RFC 5751 and rfc5751-bis say
that header protection can be done with a message/rfc822 wrapper, which
puts the "true" message header fields inside the protected message.
Minor problem: there is no way of distinguishing header protection from
a forwarded message.  Major problem: no S/MIME implementation other than
Isode Harrier seems to implement header protection.  Also, this leads to
email clients that present ugly/confusing user interfaces when header
protection is used.  Three possible fixes were presented, and the pros
and cons of each were discussed.  Alexey asked for assistance aggressing
this problem.