Lamps Status PagesLimited Additional Mechanisms for PKIX and SMIME (Active WG)
Sec Area: Eric Rescorla, Benjamin Kaduk | 2016-Jul-01 —Chairs:
IETF-101 lamps minutes
Session 2018-03-23 1150-1320: Richm/Chels/Tower - Audio stream - lamps chatroom
LAMPS Session at IETF 101 23 March 2018 Executive Summary The documents related to internationalized email addresses in certificates are in the RFC Editor queue. The S/MIME 4.0 documents with the IESG, and concerts with them were discussed and resolved. Work on rfc6844bis is progressing, and the WG adopted an Internet-Draft. The addition of the SHAKE128/256 and SHAKE256/512 algorithms for PKIX and S/MIME is progressing, but the group recommend a simple approach that avoid algorithm identifier paramaters. 0) Minute Taker, Jabber Scribe, Bluesheets Stefan Santesson is taking notes. Melinda Shore 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 AD evaluation. Various issues need to be discussed today. Simplify requirements language in 5750-bis for SMIMECapabilites attribute: The current language is redundant, and no one felt that simplification would be a problem. Jim Schaad will propose language in an updated Internet-Draft. RFC 2119 language in 5750-bis for SMIMECapabilites attribute: It is unclear how the attribute should be processed by the recipient if the MUST statements are violated by the sender. It was noted that the current text has survived many versions of S/MIME, and it not created any known interoperability issues. The group decided that the SMIMECapabilites attribute SHOULD be ignored if the sender violates any of the requirements. Jim Schaad will update the Internet-Draft. Clarify the meaning of "weak crypto" in 5750-bis. The current wording is unclear as to what is actually meant by "weak". The statement was originally written about 40-bit encryption, but now that support for 3DES is being removed, the statement seems to be an exaggeration. Yet, something need to be said in the security considerations. Jim Schaad will propose language in an updated Internet-Draft. Support for PKCS#6 certificates in 5750-bis: The group decided that PKCS#6 certificate MUST NOT be used. The OPTIONAL field will not be removed from the ASN.1, but Jim Schaad will update the Internet-Draft to say that the field MUST NOT be present. Time for certificate validity checks: The SigningTime attribute found in an S/MIME message MUST NOT be used as use a source of reliable time for certification path validation. A countersignature from a timestamp authority (TSA) could be reliable time source. Jim Schaad will propose language in an updated Internet-Draft. 4) Active Working Group Documents a) draft-hoffman-andrews-caa-simplification Comments on the current Internet-Draft lead to discussion on the mail list and discussions within the CA/Browser Forum, and the document will include some guidance on things not to do. The next version of the Internet-Draft will be posted as draft-ietf-lamps-rfc6844bis-00. 4) Active Working Group Documents b) draft-ietf-lamps-pkix-shake c) draft-ietf-lamps-cms-shakes The group discussed the use of the SHAKE128/256 and SHAKE256/512 algorithms with RSASSA-PSS, and suggested that the approach used in PKCS#1 is too messy. The use of a single object identifier to name RSASSA-PSS and all of the parameters was greatly preferred. This would lead 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 will update both Internet-Drafts to take this approach. One question about requirements for salt generation it was clarified. No guidance needs to go into the document as the salt has no implication for security. 5) Other Business (if time allows) a) Trustico and the need for revocation requests A number of options and protocol choices exists for revocation requests. Is harmonization desired? The revocation request format is diverse and context specific. It is generally unclear who can request revocation. The purpose is also unclear. No one offered a good solution. Further discussion will be taken to the mail list. 5) Other Business (if time allows) b) draft-truskovsky-lamps-pq-hybrid-x509 A new certificate extension was proposed that holds additional public key material as well as additional certificate signatures. This is meant to provide a way to specify quantum-safe cryptographic keys and signatures in certificates that still can be processed and handled by legacy implementation that does not support quantum-safe cryptographic algorithms. Several issues and problems was raised and discussed. First, the size of the certificate may be a problem, especially in protocols like TLS. One way to handle this might be the inclusion of a pointer to the data and a hash to that data (as is done for logotypes). The pointer and hash would be much smaller than the quantum-safe cryptographic keys and signatures. Second, the semantics of multiple public keys and signatures is unclear. Third, even if the semantics is clear for a particular certificate, it may still be complex how such certificates should be used in protocols. Making use of the additional keys and signatures may require complex logic. 5) Other Business (if time allows) c) draft-housley-cms-mix-with-psk The chair made the group aware of draft-housley-cms-mix-with-psk-03. Review and comment was requested.