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 |
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
- not doing same thing as CMP. Doesn't support indirect approach.
-
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.
- Mohammed : There are NIST definitions. Covering all kind of
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
- Hashing in public key or ciphertext. s it a problem in practise?
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?