* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Lamps Status Pages

Limited Additional Mechanisms for PKIX and SMIME (Active WG)
Sec Area: Eric Rescorla, Benjamin Kaduk | 2016-Jul-01 —  

IETF-101 lamps minutes

Session 2018-03-23 1150-1320: Richm/Chels/Tower - Audio stream - lamps chatroom


minutes-101-lamps-01 minutes

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

Generated from PyHt script /wg/lamps/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -