Time: Monday, 18 March 2024 at 15:00
Location: P3
Hannes: suggested the WG also discuss nonce for CSR freshness over
CMP?
Russ: it will be added to the end of the Under consideration for
adoption section of the agenda.
Some people suggested changin the document to a BCP, but the authors
are leaning towards an Informational RFC
Roman: He will push it forwards after this session unless someone
speaks now
Ron: Informational is the right thing
Thomas Gustavsson asked to remove normative language from section
4.2.2.
Three different options if to tackle the headline and retaining
backward compatability, updating headlines and remove normative
language, or address also Sections 3, 4, and 6 to modernize the
document (the authors do not really suggest the third option,
though).
Mike Ounsworth: Isn't the issue is related to direct vs. RA-brokered
connection?
Hendrik: The change seems related to having to support profile 2
rather than not being able to implement other profiles. The
discussion needs to be taken to the mail list.
Issues on section 4.4 also from Thomas Gustavsson. Three updates
requested by Thomas.
Russ: It makes sense to remove the dependencies on LDAP, but we need
to keep the OldWithNew/NewWithOld because RFC 4210 is the only place
that is written down.
John Gray: Need to keep the link certificate language.
Clear up incompatibility issues of RFC 4210 section 5.1.3.1 with
RFC4211 section 4.4 suggested by John Gray.
Russ: Anyone worried about the size of the key
Russ: We are only updating RFC 4210, there does not seem to be any
apetite to update RFC 4211.
Thomas requested to provide the optionality for the CA key update
announcement message. If the change is fine Hendrik will merge.
Mike Ounsworth: Request for the review of KEM combiner. How do I get
the review?
Russ: You ask for review like you just did.
Sean Turner: Same issue with the CMCbis documents. Anybody with the
expertise, please help.
Tim Hollebeek: Perhaps have a separate document that explains it.
Russ: Everyone please review the items on the slide and send
concerns.
EvidenceStatement now includes an optional hint that is defined as a
general name (most likely a URI or domain name)
Rich Salz: Just pick one format from the GeneralName
Lots of discussion on freshness
Hannes and Hendrik have an Internet-Draft for CMP about freshness
There is a code written at the Hackathon that uses TPM2.0
Russ: How do the other SDOs know to add their OID to the second
registry? This works for an OID that is public known but not private
ones. I am guessing that additions to the registry requires an
expert review.
Michael Richard: Usually companies have a PEN for their OIDs. Make
it clear for implementers that the registry is a list of OIDs to
expect.
Russ: Ask IANA if they would be be able this approach.
Rich Salz: This is not that usual.
This document is close to WG Last Call. Once the sample is complete,
it is ready.
Issue to be discussed the Keccak implementation at CMS level
John Gray: SHA2 is widely deployed. SHA3 isn't as much deployed.
There is no reason not to use SHA2.
Scott Fluhrer: SHA3 should be safe to use.
John Gray: The CMS layer may have access to SHA2, but not SHA3
because it is buried inside the Kyber implementation. Having SHA2 as
an option may make this easier to deploy.
Daniel: The point from Deb at last IETF seemed to be related to the
availability of implementation, not the trust in the algorithm.
Mike Ounsworth: Was the change to KMAC for some security reasons?
Daniel: That is a good question.
Should a section regarding KEMRecepientinfo be removed?
Sean Turner: Let's coordinate.
The draft is likely to change to align with other work.
Roman: it is not a bad thing. Not sure if we should get ahead of the
academic folks.
Russ: Academic folks don't study the algorithms unless we don't give
them a strawman.
Quynh: This room is not tasked with crypto analysis and crypto
review. I recommend it to be reviewed at CFRG. We have to cover all
angles. I recommend to ask them to help.
UKM is one of the issues to be studied in CFRG
Russ: If you are doing DH in a certain way it requires an UKM, and
this document is combining DH and ML-KEM.
The documents is stable and not finished, implementations are
growing (OQS is implementing the I-D).
Roman: I will continue to push the documents that are with me, no
envisioned delay in the process for AD transitioning.
Russ: Roman, congratulations on your selection as the next IETF
Chair.
Time: Wednesday, 20 March 2024 at 15:00
Location: M2
The new OID (assigned yesterday) does not change the test vectors
because only the parameters go into the KDF.
Russ (responding to Daniel van Geest): I would use it everywhere. I
can't think of an environment that wouldn't be vulnerable to this
attack, but maybe if you're not vulnerable then you could skip
implementation.
Sean Turner: I am working on a 8551bis with Blake Ramsdell.
Mike StJohns: This will work, but is it in the right place? Would
the context field of the KDF later on be a better place?
Russ: To me this looks like the sweet spot because one single change
works across all content types and RecipientInfo types.
Scott Fluhrer: Why "TLS 1.2" and not "1.3"?
Sean Turner: It is "1.2 or later", which is ok as per UTA BCP (BCP 195 /
RFC 9325).
Mike Ounsworth: Putting DER(OID) as a signature domain separator makes
this CMS-specific and therefore not re-usable across other protocols --
JOSE, COSE, etc.
Russ / Alexey: Nope. There is precedent for embedding OIDs inside, for
example PKCS#1. Other protocols just treat the DER-encoded OID as an
opaque octet string.
Sean Turner: Provide registry expert instructions to disallow MLS+NULL,
i.e., stop the silly.
Quynh: If you want to make the list smaller, I suggest taking out the
ML-DSA-65.
Jonathan Hammell: Do we need the RSA-PSS? The argument for including
them is old code; does any of that old code actually support PSS?
Guilin Wang: Why are there three hashes? The OID and M' could be hashed
once.
Scott: ML-DSA requires a hash with a specific prefix and that is
different than the yellow one.
Mike O: There are only two hashes. If you reduce it to one, you don't
get the non-separability property.
John Gray: Hashes are cheap.
Rohan Mahy: In many registries, there is a RECOMMENDED column. We could
introduce one here and mark a bunch of them as NOT RECOMMENDED.
Mike O: There was a RECOMMENDED column four drafts ago, but it was taken
out because CMS leaves the MUST and SHOULD statements to the protocol
that makes use of CMS. For example, S/MIME 4.0 uses CMS, and it makes
the MUST and SHOULD statements.
John Mattson: MLDSA-EdDSA uses SHAKE. Wouldn't it make sense to use
SHAKE?
Mike O: All the prehashes here are SHA2. We don't want SHA3 at this
level.
John Gray: At the crypto layer, it uses SHA3, but at the CMS layer we
are using SHA2.
Kris: Still unclear what the use case is for composites. Why not use
SLH-DSA?
Mike O: Even the biggest signature on this list is smaller and faster
than SPHINCS+.
John Gray: I learned in the OpenPGP WG the ML-DSA authors recommend
using ML-DSA in hybrid. That is what this is.
Poll: Should we do a call for adoption?
RESULTS: Yes (24), No (1), No Opinion (12).
When asked for an explanation, the "No" did not come to the mic.
Chairs will start an adoption call after the meeting.
Russ: Please indicate whether you would like to support adoption in the
mail thread on the list:
https://mailarchive.ietf.org/arch/msg/spasm/ueD9NVydcLV_8m05PTljCNDYM6c/
Russ: Any objection to defining an EKU for IM?
Result: No objections
Russ: Will start adoption call on list.
Mike StJohns: Think about how are you going to carry a nonce in the CSR.
It may not be something kept around.
Hannes: In the hackathon, there was a question of DoS resistance. You
need to keep the state around, keeping a mapping between a session and
verifier. DoS mitigation techniques, e.g. tickets, exist.
Sean Turner: Why didn't you support CMC? Would you be willing to accept
text?
Hannes: Absolutely.
Sean Turner: Don't need a mandatory-to-implement (MTI). I support
adoption.
Dan Harkins: In EST, the challenge password is from the TLS
establishment. Why is that not fresh enough? Why do you need a nonce?
Hannes: It comes from a different party.
Dan Harkins: You could put the nonce in the CSR attributes.
Hannes: We use a different approach in the -00. In the hackathon, it
didn't work well to open the messages. So switched to an independent
message approach. Also added a hint. RATS architecture document explains
some of the considerations. Open to suggestions of a better place to put
it.
Hendrik Brochaus: We started with the overloading of the CSR attributes,
but it is interesting for the RA to know the evidence and some info may
be needed from the end-entity. That motivated the change to the response
message.
Muhammad Usama Sardar: Will the draft be limited to TPM and Arm PSA? In
confidential computing context, we don't have trusted time and this
would be very useful. Is that out of scope? Is there something in the
implementation which cannot be carried over to Trusted Execution
Environments?
Hannes: The two examples are just illustrations. Should work fine on
other attestation technologies.
Ned Smith: Does this draft define how the nonce flows from the verifier
to the CA? Is that in scope?
Hannes: So far, it hasn't been included. Naively, it might be defined in
RATS.
Chairs: Issue call for adoption!
Dan Harkins: Do we need some kind of signal to indicate who the nonce
should come from?
Hannes: Didn't get an answer from RATS, but it used a hint. The attester
has some API that is uses to talk to the system.
Mike O.: It's already there!
Mike StJohns: You don't need to have the RP request the nonce from the
verifier.
Mike O: (on behalf of Carl Wallace in chat): The Hint is in the nonce
request, and then again in the Evidence / CSR. It could also be in the
Response so that the Attester can simply echo it into the Evidence and
does not need to keep state.