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.