LAMPS WG Agenda at IETF 121

Tuesday, 5 November 2024 at 1:00pm (13:00)

Minute Taker, Jabber Scribe, Bluesheets

Minutes: Rich, etc.

Agenda Bash (7 page agenda!)

Recently Published RFCs

a)  draft-ietf-lamps-ocsp-nonce-update (RFC 9654)
b)  draft-ietf-lamps-x509-policy-graph (RFC 9618)
c)  draft-ietf-lamps-cms-kemri (RFC 9629)

RFC Editor

In queue, waiting to be published:

a)  draft-ietf-lamps-e2e-mail-guidance (DKG) --
Waiting for header-protection draft to advance
b)  draft-ietf-lamps-rfc5990bis (Russ)
c)  draft-ietf-lamps-cms-sha3-hash (Russ)
d)  draft-ietf-lamps-cms-cek-hkdf-sha256 (Russ)         
e)  draft-ietf-lamps-rfc8708bis (Russ)              
f)  draft-ietf-lamps-rfc5019bis (Tadahiko)

With IESG

a) draft-ietf-lamps-cert-binding-for-multi-auth (Alie, Rebecca, Mike) --
Has a discuss, has a response, AD will review

b) draft-ietf-lamps-header-protection (DKG, Alexey, Bernie) -- Added
details about inner/outer From disagreeing (from spoofing attacks;
phishing). See slides, p5. Bernie points out it wasn't unianimous among
the authors, no editor was happy but this is the best given the state of
SMTP. Also issues of CC and
delivery of them are an issue.

c) draft-ietf-lamps-im-keyusage (Rohan) -- LC comments addressed, no
other update.

d) draft-ietf-lamps-x509-shbs (Kaveh, Scott, Stefan-Lukas, Daniel,
Stavros) -- No update

e) draft-ietf-lamps-rfc4210bis (Hendrik, David O, Mike, John) --
Addressed review comments, new versions uploaded to GitHub, other
clarifications (see slides for details).

f) draft-ietf-lamps-rfc6712bis (Hendrik, David O, Mike, John) -- Many
comments from HTTPDIR, in progress responding; also addressed SECDIR
OPSDIR ARTART reviews. Issue about what to do if the CMP app rejects the
message, include an HTTP response error? Will be talking to HTTPDIR for
this. Mike O: Entrust does this. OpenSSL (as a library) doesn't return
payload to the caller unless HTTP 200 is returned. Sean: Sec 4.6 of 9205
probably gives guidance.

g) draft-ietf-lamps-rfc7030-csrattrs (Michael) -- Missed one PR, will be
merged then pub request.

Active PKIX-related Documents

See the various slides for details on changes.

a+b) draft-ietf-lamps-dilithium-certificates,
draft-ietf-lamps-kyber-certificates (Sean, Panos, Jake, Bas) -- (Really
ML-KEM) MikeO: I will be presenting on seeds and private keys on PQUID,
please attend. Need to get 'lint-free' examples added, then done. JohnG:
Please do interop testing. Big open issue ML-DSA: pre-hash? Sophie:
Please don't do it, can just do pure; point to the FIPS spec with
section and line. Russ: Should also not do context arg. MikeO: Agree to
not do it. Consensus to not do it. Some work, finish examples, rev, and
then probably ready for WGLC.

c) draft-ietf-lamps-x509-slhdsa (Kaveh, Scott, Stefan-Lukas, Daniel,
Stavros) -- SLHDSA doesn't have similar issue for pre-hash (a+b), so
should we do prehash or not? Scott: entire implementation must be in one
module so we need pre-hash. Russ: so certificates do not need pre-hash,
but other data (documents) could be large so do need it, they don't have
the "two modules" escape clause. SLHDSA only defines 512SHA2 (no SHA3
modes) for digest. This isn't quite right, Qyunh points out
John,Tim,Russ: by doing this we're adding a requirement for indirect
CRL's and we need to make that explicit in the doc; PRs welcome. :)
Scott: If we do allow pre-hash, we need to tell verifiers what to use;
Qyunh, etc., the multiple choices you are concerned about is not
possible.

d) draft-ietf-lamps-csr-attestation (Mike, Hannes) -- Many changes; five
versions submitted, still have some open issues. Removed multiple
evidence bundles, which had ripple effects through the doc.
Monty,Mike,Hannes: discussion of evidence typing. A detail being worked
throug. MikeStJ: hints are complex and weird which is why I wanted it
another document. Maybe wrap-up by end of year; people are waiting for
this.

e) draft-ietf-lamps-attestation-freshness (Hannes, Hendrik) --
Description of the protocol that adds nonce to messages and, eventually,
the certificate that attests to the attestation. Will align with CSR
attestation draft.

f) draft-ietf-lamps-pq-composite-sigs (Mike, John, Max, Jan, Scott),
draft-ietf-lamps-cms-ml-dsa (Ben, Adam, Daniel) -- Lots of changes; see
the slides or detailed change logs in the drafts. Mike,John,Sohpie:
suggest leave the context parameter empty. DKG: Don't stick with old
APIs which have security issues, keep the context, tell old APIs they
are broken.

BREAK INTO SESSION II BEFORE LAST ITEM ABOVE WAS FINISHED

g) draft-ietf-lamps-rfc{5272,5273,5274}bis (Joseph, Sean)

h) draft-ietf-lamps-rfc9579bis (Alicja)

Active S/MIME-related Documents

a) draft-ietf-lamps-cms-kyber (Ludovic, Julien, Mike)
b) draft-ietf-lamps-cms-sphincs-plus (Russ, Scott, Panos, Bas)

Special Topic: EUF-CMA for CMS SignedData

Under consideration for adoption

a) draft-wang-lamps-root-ca-cert-rekeying (Guilin)
b) draft-harvey-cfrg-mtl-mode (John)
c) draft-lamps-okubu-certdiscovery (John)
d) draft-lamps-bonnell-keyusage-crl-validation (Corey)
e) draft-brockhaus-lamps-automation-keyusages (Hendrik)
f) draft-davidben-x509-alg-none (David)
g) draft-sun-lamps-hybrid-scheme (Shuzhou)

Wrap up

Session 2

Composite ML-DSA

• Falko Strenzke: Mike asks an issue to be created on github
• Deirdre suggests not to include context in signatures. Mike argues
  what we do today should not be what we do in the future.
• Britta argues adding context does not include any security.
• Burt Kaliski supports the design, as he mentioned on the list.
• Sophie has no strong opinion on context.
• Mike encourages everyone to have a look at security considerations.
• Scott (one of the editors on draft) argues adding context does add
  security.
• Daniel proposes to keep context.
• Bas: 2 different things: Do we support context? or do we use it?

pq-composite-kem

• Russ asks detailed question about implementation. Mike says they are
  not written down yet.
• Sophie: Start with empty list and only add if someone asks for it.
  Don't include something which is not needed.
• John says Ericsson uses Ed448.
• Currenly the list is not FIPS compliant
• Alicja: Mike answers there are still constraints.
• Quynh: Key is fixed length.
• Sean proposes to use option 2 without size.
• Deirdre
• David also proposes to use only seed.

CMCbis I-Ds

• Jonathan proposes to include contentEncryptionAlgorithm field
  specifying AES in the example Direct POP flow.
• Mike proposes not to include attestation in this draft. Sean will
  only add PRs to attested CSR draft.

rfc9579bis

draft-ietf-lamps-cms-ml-dsa

• No dependencies; will make changes and ask for WGLC

draft-ietf-lamps-cms-kyber

• Quynh: Will follow up within NIST regarding validation of HKDF
  Extract-then-Expand

Special Topic

• Sophie: agrees with position of Bas: distinguish between having
  context and using it.
• Scott: Getting context wrong will break interoperability.