LAMPS WG Agenda at IETF 122

Wednesday March 19 at 13:00 ThaiTime
Friday 21 March at 9:30 ThaiTime

Minute Taker, Jabber Scribe

Rich Salz
Mike Ounsworth
Jean-Pierre Fiset

Agenda Bash

No changes.

Recently Published RFCs

a) draft-ietf-lamps-rfc5990bis (RFC 9690)
b) draft-ietf-lamps-cms-sha3-hash (RFC 9688)
c) draft-ietf-lamps-cms-cek-hkdf-sha256 (RFC 9709)
d) draft-ietf-lamps-rfc8708bis (RFC 9708)
e) draft-ietf-lamps-im-keyusage (RFC 9734)

RFC Editor

a) draft-ietf-lamps-e2e-mail-guidance (DKG) (the Moby Dick of RFCs)
b) draft-ietf-lamps-rfc5019bis (Tadahiko)
c) draft-ietf-lamps-cert-binding-for-multi-auth
d) draft-ietf-lamps-header-protection
f) draft-ietf-lamps-x509-shbs
g) draft-ietf-lamps-rfc4210bis
h) draft-ietf-lamps-rfc6712bis

With IESG

a) draft-ietf-lamps-rfc7030-csrattrs (Michael) -- just had revised
examples, WG is done
b) draft-ietf-lamps-rfc9579bis (Alicja)
c) draft-ietf-lamps-cms-sphincs-plus (Russ, Scott, Panos, Bas)

Active PKIX-related Documents

a) draft-ietf-lamps-dilithium-certificates (Jake, Panos, Sean, Bas)
b) draft-ietf-lamps-kyber-certificates (Sean, Panos, Jake, Bas)

• Acknowledges large e-mail discussions about private key war
• Presents ASN.1 relating to SEED, EXPANDED and SEED+EXPANDED

• Tiru: Question about wording SHOULD vs MUST... Can we live with the
  presented text?

  • Deb: if "SHOULD" is used, then better wording about what/why it
    is not done
  • Monty, Mike: suggestions about where to put the SHOULD
    rationale; a security-related SHOULD deserves some explanation.

• DavidBen: Is there any text saying which choice option to use?
  Answer: no, up to implementation

• MLDSA will have some changes as MLKEM

• Do we need to have text addressing public key derivation (ML-DSA)
  from private key? Sean does not feel like adding more text if it is
  not required.

  • Viktor: Performing the public key derivation from the private
    offers a consistency check.
  • Does not really apply to ML-KEM
  • Let's not add the text

• Welcome to the ExternalMu portion of the presentation...

  • The issue has to do with the whether the external mu approach
    prevents a system as a whole to be FIPS validatable.
  • There was a meeting with NIST
  • Do we need to talk about this in the draft?
  • Quynh: external Mu NIST is likely to allow explicitely the use
    of external Mu.
  • Andrei: Do we need adoption? Russ: yes
  • Tim: This will not be allowed unless NIST makes updates to the
    specs. We should not publish something depending on external
    work to happen.
  • Viktor: Not sure about the validation of the system where two
    modules are used to perform a signature.
  • Mike: How do we move forward from here? We need to decouple the
    hashing of large content from the signature itself. If we can
    not move forward on this, then we need to revisit a lot.
  • Scott: Why is NIST preventing this approach?
  • David: there are questions whether or not our assumptions are
    correct. But it sounds like NIST is going to move forward. We
    can always defined new OIDs... not well received.
  • Quynh: Resolution on this is imminent. We are not ready for this
    meeting, but we had a lot of internal discussions. It will be
    out soon.
  • John: Move forward as is. There is prior art that is similar.
  • Tim: Remains skeptical. (re-iterates previous comment) Finds
    adoptioin is pre-mature
  • Mike: Specifies that this applies to CA objects.
    MLKEM is done. MLDSA we will try to wait for the NIST
    update.
    Friday update: NIST announcement made, draft is compliant,
    WGLC/objections now.

c) draft-ietf-lamps-csr-attestation (Mike)

• Few fixes to make things ready for submission for WGLC
• Why the change from UTF8String to IA5String? Because it is a FQDN
  that is meant as a hint to the parsing tool. Not meant for human
  consumption.
• Need a few minutes with co-author to get new version which is ready
  for WGLC

d) draft-ietf-lamps-x509-slhdsa (Kaveh, Scott, Stefan-Lukas, Daniel,
Stavros)

• Updated draft since last meeting
• All WGLC comments were addressed
• Ready to go to IESG; will confirm on the list

e) draft-ietf-lamps-attestation-freshness (Hannes, Hendrik)

• Waiting for next draft of CSR attestation, then will post a new
  draft of this. (Hannes is co-author on both drafts.)

f) draft-ietf-lamps-pq-composite-sigs (Mike, John, Max, Jan, Scott)

• Probably the first-time we had a prsesentation from a hospital bed
• More algorithms are alwayys requested. Russ: it is up to the authors
  to decide when to draw the line. This affects reaching WGLC

• Added a prefix to message during signature generation/validation

  • BAS: Why was it added?
  • Falko: Set of measures to help in case of people not following
    guidance relating to key re-use

• Removed ASN.1 wrapping on public keys, private keys and ciphertexxt
  values

• Simplified KEM combiner by removing expansion
• SHA3 is not currently allowed in CNSA 2.0; adjustements for that

• 4-byte length prefix on signatures and KEMs; help separating
  components

  • Bas: given an algorithm, we already know the sizes. Why need a
    prefix? John: for consistency.
  • Mike: Not fully justified
  • John: Future proofing
  • Thom: Falcon may have variable length signatures, so the prefix
    might be relevant
  • David: We do not need to future proof these algorithms
  • Viktor: Concerns with CMS where security levels must be matched.
    Why are we enforcing the matching of the security model with a
    MUST as opposed to a SHOULD? Mike: talk on the list... Can
    someone from CMS comment? Ben: on strong opinion on MUST vs
    SHOULD
  • Jean-Pierre: we can just do one size for key, since nobody has
    generated them yet.
  • Daniel: not sure if we can do that with keys in HSMs
  • Mike: our design constraint is we cannot change the component
    parts.
  • Tim: should be consistent with the private key format
  • Jean-Pierre: unconstrained by legacy, no need to be consistent
  • DavidB: we're not in a messy private-key-type situation, so do
    the simple thing
  • PHB: Doing the union for compatibility, consistency is not a
    good reason to carry forward a bad way of doing things. Taking
    private key is a malware vector, bad idea.
  • Scott: There is a private key format issue with PureMLDSA
    composite brand-new and we say "generate new keys" for hygiene
    anyway
  • Viktor: do we
  • Rich: Understand argument of consistency. However, simplicity
    should be favoured.

• Encoding of sigs and KEM, ASN.1 vs concatenation

  • Should it apply only to private keys?
  • Viktor: This is an ASN.1 context, we already have parsers. Wish
    to keep ASN.1 encoding
  • Mike: Other groups want to re-use the same work (public keys,
    sigatures), but do not have ASN.1 parser.
  • John: We should take this to the list Russ: No, pick one,
    cast-call it and see if people can live with it.
  • Mike: might move CMS to separate doc if it takes too long so
    that raw sig formnat isn't held up

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

• Few outstanding PRs to resolve, then ask for WGLC

• MTI algo changes

  • Sean: Keep it easy and simple; select few matching algorithms

• Look into freshness issues: need to define another request type

• One rev, WGLC this week

h) draft-ietf-lamps-private-key-stmt-attr

• "It is more a statement of possession as opposed to a proof of
  possession"
• Same subject deaing with the same CA.
• Ready for WGLC; anyone disagree?
• Mike: need to read again to ensure that the context in which the CA
  must make a decision is sufficient for honouring the request.
• Russ: please review security considerations.

i) draft-ietf-lamps-x509-alg-none

• Adopted during publication blackout, will soon post a draft, and
  list the (three) open items

Active S/MIME-related Documents

a) draft-ietf-lamps-cms-kyber (Ludovic, Julien, Mike)

• Version 8: minor editorial changes
• WGLC? Collisions with other work
• Next: Request to support intermediate values
• Viktor: why MUST we align security levels? Maybe RECOMMEND (Russ:
  RECOMMENDED and SHOULD are the same)
• Russ: we do not have an external mu issue with KYBER, I'd like to
  see this through soon
• Mike+Viktor: Discussion about aligning security levels. Victor
  wishes to mix and match.

b) draft-ietf-lamps-pq-composite-kem (Mike, John)

• See (f) above, presented then

c) draft-ietf-lamps-cms-ml-dsa (Ben, Adam, Daniel)

• SHA-512 is a MUST (removed SHAKE recommendation)
• ASN.1 formats sent to dilithium-certs
• Added test vectors

• Should we specify SHAKE256 as a SHOULD? Really can not as SHA-512 is
  compulsory

  • Viktor: OpenSSL has issues with supporting SHAKE
  • Quynh: SHOULD would be good if we did not have a MUST

• Do we need a LC again? Russ: no. Just need to make necessary edits

Under consideration for adoption

• Not ready yet. Let's push to Friday.

b) draft-vangeest-lamps-cms-euf-cma-signeddata

• Presented during virtual interim
• Reviewed signed attributes usage
• Falko: presents an example where an attack is possible on naive
  signature request
• Russ: a number of things in the table that do not comply. Encourages
  to go down the BCP path.
• Michael: confused by first bullet where id-data OID should not be
  used. Will send update.
• Rich: if it is a BCP (and it should), it would be interesting to
  have a BCP that points out which RFCs are incorrect because BCP
  cannot upate standards-track RFCs

Wrap up

FRIDAY SESSION

• NIST has alrady released the statement on external mu that we were
  waiting for.

a) draft-birglee-lamps-caa-security

• Describing attacks on domain control validation.
• Marginal improvement: does not mitigate attacks against adversary
  with global reach
• Focus of work is an attacker that can insert itself between CA and
  domain requesting issuance
• DNS is leveraged with the use of CAA records; take advantage of
  DNSSEC
• Henry is presenting this at CA/B forum, next week and there is a
  proposed ballot.
• Proposes a new CAA security tag
• Henry goes over use cases that demonstrate problems with approach
  and related specifications
• Bob: Discussion on additional validation methods. Bob is interesting
  in collaborating.

• Tim Hollebeek: "Existing certificate" previously existed in the BRs,
  and was removed. You might want to go back and look at the CAB/F
  history.

  • Henry: these proposals are not CAB/F compliant, so they would
    need to be coupled with a compliant method. These proposals
    provide enhanced security but not CAB/F compliance.

• Viktor: What about domains that want to be authenticated via TLSA
  records?

  • Henry: Provide umbrella approach to complement other methods.
    Might lead to interesting TLSA integrations.
  • Viktor is ready to help

• Rich: In ACME group?

  • Henry: No, dispatched to LAMPS

• Bob: Discussion on clarification on scope of approach

• Adoption?
  • Russ: Is it ready?
  • Henry: We could take some more pointers from community
  • Russ: Henry to start e-mail thread

b) draft-mandel-lamps-pkcs8-prikeyinfo-contenttypes

• Joe: Basically, adding a content type for PrivateKeyInfo and
  EncryptedPrivateKeyInfo
• Sean: Simply adding a wrapper around PKCS#8
• Adoption objections? no...

c) draft-lamps-okubo-certdiscovery-05

• John is presenting remotely
• Mike: This was already presented in January 2025 (we have one new
  slide...)

• Basically, adding a pointer to a X.509 certificate to point to
  another

  • Discovery mechanism
  • Designed for flexibility

• Might be a good complement to "statement of possession" that is
  proposed

• Viktor: Intended consumer?

  • Initial use case: S/MIME posture after an upgrade to PQC
    certificates. Since, become more generic.

• Tiru: Elaborate the presented use case. Intended in WebPKI?

  • Mike: could be used to cross reference different certificate for
    a given subject (one traditional, one quantum safe)
  • Mike not provide backward compatibility nor hybrid security

• Andrei: Many use cases. Should we use different pointers to
  distinguish between them. Would prefer constraint to a specific use.

• Henry: Not sure about the security properties associated with this
  approach.

  • John: Could be used for operational redundancy

• Thom: What is the use case, exactly? (assuming that one of the
  algorithm is broken)

  • Mike: There is an existing relationship between two users. After
    an upgrade, tooling discover new certificate based on extension.

• Rich: Likes the work but some changes probably needed after adoption

  • Mike: after adoption, we can add purpose or other signals

• Gullin: Verifies understanding of the provided approach. Compares to
  Multi-Auth cert draft.

  • Mike: Multi-Auth prevents bi-drectional links
  • Gullin: will both drafts be combined? Mike: no

• Viktor: multiple purposes should have multiple extensions

  • Mike: these issues can go after adoption

• Russ: adoption now or wait for one more rev

  • Mike: adoption
  • Any objections? no