Skip to main content

Minutes IETF120: lamps
minutes-120-lamps-01

Meeting Minutes Limited Additional Mechanisms for PKIX and SMIME (lamps) WG
Date and time 2024-07-26 20:00
Title Minutes IETF120: lamps
State Active
Other versions markdown
Last updated 2024-08-05

minutes-120-lamps-01

LAMPS 120 Meeting
Wednesday July 24th, 2024

Scribe: John Gray

  • Started going over agenda bash. A couple minor changes to accomodate
    people that can't make Friday.
  • Went over the notewell
  • 8 groupings of documents

Published RFCS

  • 4 newly published

RFC Editor QUEUE

  • Kemri no updates
  • policy graph - no updates
  • e2e guiance - no updates
  • 5990-bis - Points to an algorithm ID, 5990 uses it but doesn't
    update the registry

    • output of KDF must be the side of the KEK
  • sh3 hash - no update

  • ocsp nonce - no update

IESG

  • cert binding for multi-auth

    • there was a discuss, just waiting on the discuss
  • 5019 bis - Just wait for approval for the author

  • Header protection draft:

    • now draft -23
    • changed mechanism for headers
    • guidance for safe handling of replies and forwards
    • renamed hcp's
    • Now a single scheme, not called header protectors
    • Risk of from header spoofing, we have some guidance on how to
      handle
    • Simplification: One Scheme
    • HP-Outer is simpler
    • Header Confidentiality Policy Refresh
    • Risk from spoofing: Draft opens a hole in protection. Draft now
      gives guidance
    • Draft gives guidance to avoid "From" spoofing. Draft needs
      people to look at this guidance and give feedback.
    • Hope document is ready for another WGLC
    • Q: Russ: Is this the last substantive update?
    • A: DKG: We believe we are ready at this point.
    • Q: Bernie: Don't agree with rendering of unprotected from. Sent
      and email and answer.
    • A: DKG: Question on weather it makes things worse, I don't think
      it does.
  • 8708bis - Hasn't reached IETF last call. No feedback.

  • Falco mitigation document - no Security area review yet.

CMCbis document

  • Call for adoption until the 30th
  • Adding KEM support into CMC

    • not doing same thing as CMP. Doesn't support indirect approach.
      Using the exisitng no signature algorithm. Flow back and fourth,
      added new section in appendix. Looks same as RSA one for KEMRI
      recipientInfo choice.
    • There was a typo, the POP is encrypted
    • Also need to update 6955 related text
    • Add pre-5378 boilerplate
  • Hendrik - Message protection - Renewal requests need to be looked
    at. Sean mentioned he hasn't look at it.

Key Attestation Draft

  • Draft covers "how you put this evidence into a CSR"
  • Started WGLC - ended June 3rd, got a lot of feedback, worked through
    a number of issues.
  • In regards to the evidenceStatement format: Should the RA/CA be
    available for parsing, or should it be dragged up through the UTF8
    hint.

    • feedback is appreciated
  • Still open issues - 139, 144, 150, 151

  • Discussion about RATS architecture and attestation language.
    • Mohammed : There are NIST definitions. Covering all kind of
      evidences, nothing on Trusted Execution Environments. It will
      support any custom format.

Nonce based Freshness for Remote Attestation for CMP and EST

  • This information is needed in certificate management protocols
  • Open issues, will added CMC information.
  • Henk: Is the markdown on lamps-wg? Not yet but it will be soon.

ML-DSA / ML-KEM Certificate IDs

  • Align ML-KEM with ML-DSA drafts

RFC 4210-bis and 6712

  • WGLC closed without change requests
  • No open issues
  • 4210 bis - See changes slide
  • Had WGLC closed on July 12th.
  • Waiting for last review, Russ thinks we are done. Unless authors
    want to wait for nonce request and nonce responce. Mainly on the POP
    section. Seans says to go ahead. Nonce request, Nonce response.
  • John: If nonce is going to take a while, lets not delay
  • Hendrik went over comments by Thom Wiggers
  • Message protection, establish shared secret. This is about POP

7030 CSR Attestation

  • Had a WGLC recently, added ability to use a CSR as a template to
    return the attributes. Carl Wallace has come up with other ASN.1
    that may be bit compatible.

X509 for Stateful Hash based signatures

  • Removed extra ASN.1 wrapping. Received IANA OIDS
  • Not touching anything regarding private key format
  • Certificate examples

draft-ietf-lamps-x509-slhdsa-01

  • Waiting for NIST OIDS - will only use pure and not -prehash
  • Sean: Prehash, verses non-prehash
  • Quynh: We are making 2 OIDS

Key Usage - Rohan

  • no updates

Composite Signatures

  • Explained updates

LAMPS SESSION II - Friday July 26th, 2024

  • Continuation of Composite Signatures

CMS Kyber

  • HKDF and KMAC - two choices
  • Next steps, wait for NIST, examples
  • Scott: Mandatory to implement - pick one as mandatory to implement
    and call it a day.
  • Happy to lock it down to HKDF
  • Quynh: Would prefer the KDF used is compliant with NIST
  • Mal-Bind properties - do we need to do anything here
  • Sophie: Reasons why ML-KEM is not fullfilling kCT or KPK properties.
    • Hashing in public key or ciphertext. s it a problem in practise?
      Not completely known.
    • Sophie went through a concrete example. Practical attack needs
      to be constructed, probably not a big deal, but maybe someone
      can produce a vulnerability. All attacks are based on forms on
      serialization of the private key.
    • Russ had comment about tranmitting the seed

CMS SPHINCS+

  • Draft updated for guidance for usage in CMS, when you hash content,
    and store it as a signed attribute, and sign that with SPHINCS+.
    Made recomendations about comparable strengths.
  • Waiting for NIST OIDS

Composite KEMS

  • Combiner was re-written, to get compliant with NIST 800-56C
  • Order of the shared secret did not matter
  • fixedInfo together with tradCT
  • A proof is needed for RSA-OAEP
  • Breaking binary op having a separate PKIX domain.

    • Daniel Van Geest thinks have a separate PKIX domain is bad.
    • Domain separate could align with XWing
  • We changed from RSA-KEM to RSA-OAEP. Not useful for backwards
    compatiblity

  • Removed references to DHKEM
  • New OIDs - not done as no implementations yet
  • CFRG KEM combiners - slide 17 needs it own mail list discussion
  • Question: Does smart card have access to its public key when it
    decrypts?
  • MikeStJohns - RSA and EC public key can be recomputed
  • Question about SHA3 vs SHA2. Will go to mailing list
  • Question on timing: Do we wait for CFRG. We prefer not.
  • Stable samples to come
  • | Quynh - Just a comment about clarity on the KDF(counter | | tradSS | | mlkemSS ... etc). |

Cert Binding Draft

  • Would like to defer the discussion on the List

Root CA Certificate Re-keying for Post Quantum

  • Idea seems to be using a one-way link certificate to extend to a new
    PQ certificate.
  • Did testing with openSSL.
  • A number of questions on the list
  • Scott: Hard problem is how you distrubute new CA certs. When you get
    a NewForOld, the device records the new CA as trusted as the old CA
    certificate.
  • Old CA certificate is still valid
  • John: How is this new
  • Guilin: Guidance on the mailing list is helpful

Other items:
John: Who is working on ML-DSA in CMS?