* 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: Roman Danyliw, Benjamin Kaduk | 2016-Jul-01 —  
Chairs
 
 


IETF-109 lamps minutes

Session 2020-11-17 1600-1800: Room 6 - lamps chatroom

Minutes

minutes-109-lamps-00 minutes



          LAMPS WG at Virtual IETF 109
          
          Minutes: Jonathan Hammell
          Jabber Scribe: Tim Hollebeek
          
          
          AGENDA
          
          1)  Agenda Bash
          2)  Documents with the RFC Editor
              a)  draft-ietf-lamps-ocsp-nonce
              b)  draft-ietf-lamps-rfc7030est-clarify
          3)  Active Working Group Documents
              a)  draft-ietf-lamps-cmp-updates
              b)  draft-ietf-lamps-cmp-algorithms
              c)  draft-ietf-lamps-lightweight-cmp-profile
              d)  draft-ietf-lamps-header-protection
          4)  Prospective Active Working Group Documents
              a)  draft-dkg-lamps-e2e-mail-guidance
              b)  draft-housley-lamps-crmf-update-algs
              c)  draft-housley-lamps-cms-aes-gmac-alg
          5)  Wrap Up
          
          
          MINUTES
          
          1) Agenda bash: No agenda changes were requested.
          
          2) Documents with the RFC Editor
          
          a) draft-ietf-lamps-ocsp-nonce is in AUTH48; no known issues.
          
          b) draft-ietf-lamps-rfc7030est-clarify is in AUTH48; no known issues.
          
          3) Active Working Group Documents
          
          a) Hendrik Brockhaus presented on draft-ietf-lamps-cmp-algorithms.
          (https://datatracker.ietf.org/meeting/109/materials/slides-109-lamps-lightweight-cmp-profile-and-updates-cmp-00)
          
          Currently only message digest algorithms are the SHA-2 family, but plan
          is to add SHAKE.  No additional message digest algorithms suggested.
          
          Use of content encryption is intended for certificates and passphrases.
          Currently only content-encryption algorithms are AES-CCM and AES-GCM,
          but could add AES-CBC or ChaCha20-Poly1305.  Russ Housley pointed out
          that AES-CCM and AES-GCM require AuthEnvelopedData rather than
          EnvelopedData as currently used in CMP. Hendrik plans to move to
          AES-CBC.
          
          Current MAC algorithms include PasswordBasedMAC, PBMAC1, DHBasedMAC, and
          HMAC_SHA-2. Hendrik plans to add AES-GMAC and KMAC.  Mailing list thread
          suggested preference for AES-GMAC versus AES-CMAC.
          
          Current signature algorithms include DSA, RSA, ECDSA with SHA-2 and
          RSASSA-PSS. Russ mentioned that signing with Ed25519 (uses Curve25519)
          is gaining support.  Russ (and several in chat) suggested dropping DSA.
          No objections.
          
          Current key agreement algorithms are Diffie-Hellman and ECDH. Daniel
          Khan Gilmore (DKG) suggested explicitly discourage use of static-static
          variants of Diffie-Hellman and ECDH.
          
          Current key transport algorithms is PKCS#1 V1.5 and RSAES-OAEP. Russ has
          not seen RSAES-OAEP in the wild. Hendrik will remove RSAES-OAEP.
          
          Symmetric key-encryption algorithm is AES-KEYWRAP.
          
          Key derivation algorithm is PBKDF2.
          
          b) draft-ietf-lamps-cmp-updates (Hendrik)
          (https://datatracker.ietf.org/meeting/109/materials/slides-109-lamps-lightweight-cmp-profile-and-updates-cmp-00)
          
          All issues from IETF 108 and subsequent discussion on mailing list have
          been addressed in the current I-D.
          
          In order to handle PKIs with multiple root CA certificates, new OID is
          used to include certificate in the request.
          
          If PKI supports more than one certificate profile, request to CA for
          certificate request template is ambiguous. Agreement to add an
          InfoTypeValue in the PKIHeader.generalInfo.
          
          Reuse of AttributeTypeValues controls in context of certificate request
          template. No objection. Once the document is stable, the WG will ask
          IANA to make early assignment for the needed OID.
          
          DKG asked the authors to get feedback from Mark Nottingham on use of
          .well-known.  In chat, several people suggested use .well-known/cmp and
          the IANA registry to use.
          
          The ASN.1 module should be an update to RFC 5912.
          
          c) draft-ietf-lamps-lightweight-cmp-profile
          (https://datatracker.ietf.org/meeting/109/materials/slides-109-lamps-lightweight-cmp-profile-and-updates-cmp-00)
          
          All issues from IETF 108 and subsequent discussion on mailing list have
          been addressed in the current I-D.
          
          GitHub.com/Siemens includes a reference lightweight RA implementation.
          No suggestions on better TLS cipher suite for use of PSKs.
          
          d) draft-ietf-lamps-header-protection
          (https://datatracker.ietf.org/meeting/109/materials/slides-109-lamps-header-protection-00)
          
          Summary of changes since IETF 108 were presented.  Then, the list of
          still open issues was given.
          
          The I-D will be overhauled to focus on implementation guidance. In
          particular how to handle reception for the the two header protection
          schemes found in the wild.
          
          The authors are requesting feedback for message composition. A table
          that captures the way that user agents handle the various situations
          will help the WG choose the best way forward regarding message
          composition.
          
          DKG proposed a header confidentiality policy (HCP) for encrypted
          messages. This I-D will recommend one default HCP, but more could be
          added in future I-Ds. Bernie Hoeneisen wondered how much we lose with
          hcp_strong option (see slides). Alexey Melnikov pointed out an impact
          to MUAs that support message threading without downloading the entire
          message. Tim Hollebeek pointed out the HCP definition works in a
          header-by-header method, which makes some wholistic policy statements
          impossible. DKG agreed, and he observed that HCP is also stateless.
          Need discussion on the mailing list to select the default HCP. Also,
          there may need a signaling mechanism to say which HCPs are supported by
          the MUA, but that should be done in future I-D. Russ pointed out that
          SMIMECapabilities was intended to be such a signaling mechanism, but it
          hasn't been a significant success in altering behaviour. Bernie said
          that hcp_strong is implemented in PeP without any problems. Looking for
          feedback on some more subtleties.
          
          4) Prospective Active Working Group Documents
          
          a) draft-dkg-lamps-e2e-mail-guidance
          (https://datatracker.ietf.org/meeting/109/materials/slides-109-lamps-end-to-end-mail-guidance-00)
          
          DKG talked about End-to-End Cryptographic E-mail Guidance. Russ said
          that adopting this document may require a WG re-charter. DKG said it
          should not be lumped under header protection.
          
          DKG requested review and to contribute suggestions. The I-D is on
          gitlab, and DKG is happy to accept PRs.
          
          No objections raised for this work item topic, despite it covering user
          experience. No concerns from Roman as Security AD.
          
          DKG will propose re-charter text on the mailing list.
          
          b) draft-housley-lamps-crmf-update-algs
          (https://datatracker.ietf.org/meeting/109/materials/slides-109-lamps-draft-housley-lamps-crmf-update-algs-02)
          
          Russ talked about updates to the cryptographic mandatory-to-implement
          algorithms in CRMF (RFC 4211) for the Password-based MAC. The proposed
          replacements are based on mailing list discussion. Plan to do WG call
          for adoption, followed immediately by WG Last Call. No objections.
          
          Tim will start WG adoption call on the mailing list.
          
          c) draft-housley-lamps-cms-aes-gmac-alg
          (https://datatracker.ietf.org/meeting/109/materials/slides-109-lamps-draft-housley-lamps-cms-aes-gmac-alg-01)
          
          At Russ' request, NIST assigned three OIDs for AES-GMAC. This I-D
          specifies the OIDs and GMACParameters.
          
          Tim has already started WG adoption call on the mailing list.
          If adopted, then WG Last Call will follow immediately.
          
          5) Wrap Up: no other business.
          
          



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