# LAMPS WG Agenda at IETF 118   {#lamps-wg-agenda-at-ietf-118}

## Monday, 6 November 2023 at 17:30 local   {#monday-6-november-2023-at-1730-local}

### Recently Published RFCs   {#recently-published-rfcs}

Recently Published RFCs:

*   draft-ietf-lamps-caa-issuemail published as RFC 9495
*   draft-ietf-lamps-cmp-algorithms published as RFC 9481
*   draft-ietf-lamps-cmp-updates published as RFC 9480
*   draft-ietf-lamps-lightweight-cmp-profile as RFC 9483

### Documents with the IESG or RFC Editor   {#documents-with-the-iesg-or-rfc-editor}

With the IESG or the RFC Editor:

*   draft-ietf-lamps-nf-eku
*   draft-ietf-lamps-cms-kemri

Mike Ounsworth: The cms-kemri might be moving to fast. Why is this not
using HPKE?

Russ: HPKE does not accomdate the split bwtween KEMRecipientInfo and
EncryptedContentInfo, which is used to distribute the same encryption
key to each recipient so that one copy of the ciphertext can be
processed by all recipients.

Roman: Plenty of time to address any concerns.

### Active PKIX-related Documents   {#active-pkix-related-documents}

#### draft-ietf-lamps-rfc4210bis and draft-ietf-lamps-rfc6712bis   {#draft-ietf-lamps-rfc4210bis-and-draft-ietf-lamps-rfc6712bis}

Hendrik: The authors ask for review of the newly introduced KEM message
protection. Specifically feedback is welecome if all proposed fields in
the kemOtherInfo are required.

Russ: This should be discussed after the presentation on cms-kemri on
Wednesday.

#### draft-ietf-lamps-pkcs12-pbmac1   {#draft-ietf-lamps-pkcs12-pbmac1}

Russ: This document is in WGLC.

Sean Turner: Need to check the ASN.1; I am willing to help add an ASN.1
to this document.

#### draft-ietf-lamps-cert-binding-for-multi-auth   {#draft-ietf-lamps-cert-binding-for-multi-auth}

This document is in WGLC. Three issues were raised and they will be
addressed in the next version.

#### draft-ietf-lamps-rfc7030-csrattrs   {#draft-ietf-lamps-rfc7030-csrattrs}

No issues to raise.

#### draft-ietf-lamps-dilithium-certificates   {#draft-ietf-lamps-dilithium-certificates}

No issues to raise. Waiting for NIST to assign the OIDs.

#### draft-ietf-lamps-x509-policy-graph   {#draft-ietf-lamps-x509-policy-graph}

Russ: Ready to procced to WGLC.

#### draft-ietf-lamps-csr-attestation   {#draft-ietf-lamps-csr-attestation}

Henk B: I will submit PRs on nonces and freshness.

#### draft-tschofenig-lamps-nonce-cmp-est   {#draft-tschofenig-lamps-nonce-cmp-est}

Russ: Regarding Slide 3, can you talk to network seperation on an air
gapped network?

Hendrik: you can "ship" CMP messages offline.

Thomas: You might want to add an API for nonce. The RA add a new nonce
for the template.

Hendrik: All feedabck is welcome. This was a first take at a solution.

#### draft-ietf-lamps-rfc5019bis   {#draft-ietf-lamps-rfc5019bis}

Russ: Any concerns with going to WGLC in the next few weeks?

No concerns raised.

#### draft-ietf-lamps-kyber-certificates   {#draft-ietf-lamps-kyber-certificates}

Sean will make the changes to us the NIST assigned name, ML-KEM. Want to
also include the private key format.

Russ: Review draft-uni-qsckeys; it suggests private key formats.

Sean: The -03 document will come in the next few weeks.

John Gray: Work was done on the private key formats at the hackaton. We
just use an octet string. Could be helpful here.

DKG: OpenPGP will be using an octet string as well.

### Active S/MIME-related Documents   {#active-smime-related-documents}

#### draft-ietf-lamps-cms-kyber   {#draft-ietf-lamps-cms-kyber}

Scott F: You might want to use AES with a 256-bit key.

John G: Agrees with Scott. Also, use the NIST-assigned name, ML-KEM.

Mike O: We need to work on naming convention with other WGs, and we want
to have a consistant level of strength.

#### draft-ietf-lamps-cms-sphincs-plus   {#draft-ietf-lamps-cms-sphincs-plus}

Russ: We will post a new version that uses the NIST-assigned name,
SLH-DSA. Waiting for NIST to assign the OIDs.

#### draft-ietf-lamps-rfc5990bis   {#draft-ietf-lamps-rfc5990bis}

This document is in WGLC.

Russ: Please review and provide any comments.

#### draft-dkg-mail-cleartext-copy   {#draft-dkg-mail-cleartext-copy}

Russ: BCC recipients get a seperate submission.

DKG: BCC can "hit reply all".

DKG: Can we adpot this draft? We would like people who work on MUA to
give some input.

Russ: Does anyone object to call for adoption in the next few weeks?

No objections raised.

## Wednesday, 8 November 2023 at 14:30 local   {#wednesday-8-november-2023-at-1430-local}

### Special Topic   {#special-topic}

#### AEAD-to-CBC Downgrade Attacks on CMS   {#aead-to-cbc-downgrade-attacks-on-cms}

John Gray: How many garbage blocks do you need?

Falco: You need one for each of your guesses.

John: What clients have you tested? How practical is the attack?

Falco: There is no defence against it, as long as you can forward the
bad data to the client.

Orie: Other areas to be looking?

Russ: This attack applies to CMS, JOSE, and COSE. JOSE and COSE has a
little bit more protection since they were designed to be used only with
AEAD, but AES-CBC and AES-CTR were recently added to COSE to meet the
requirements from the SUIT WG.

#### An alternative mitigation   {#an-alternative-mitigation}

Nike StJohns: This is a good approach. In the examples, it would be good
to include some CMS-specific context as an input to the HKDF.

Rich Salz - Agrees with CMS-specific context. We have an unprotected
attributes, but we need to update sender and reciever software to use
it.

DKG: What is the difference from Falko's approach.

Russ: Instead of doing this for just KEMRecipeintInfo, we are able to
mitigate this attack for all flavores of RecipeintInfo.

DKG: All recipents update their software and put this new OID in the
SMIMECapabilities in certificates. We do not have an answer for first
message?

Russ: This has the same problem as the introduction of any new key
management algorithm.

Orie: What is the guidance for developers?

Russ: Its not nailed down yet. JOSE and COSE has these issues too.

### Resume Active S/MIME-related Documents   {#resume-active-smime-related-documents}

#### draft-ietf-lamps-header-protection and draft-ietf-lamps-e2e-mail-guidance   {#draft-ietf-lamps-header-protection-and-draft-ietf-lamps-e2e-mail-guidance}

These documents are in WGLC.

DKG: Would like to advance these documents.

Russ: Have the authors addressed the comments?

DKG: Looks like no comments.

Russ: Chairs will send to IESG.

#### draft-ietf-lamps-rfc8398bis and draft-ietf-lamps-rfc8399bis   {#draft-ietf-lamps-rfc8398bis-and-draft-ietf-lamps-rfc8399bis}

Corey: WGLC ended and no additional comments.

#### draft-ietf-lamps-pq-composite-kem and draft-ounsworth-lamps-cms-dhkem   {#draft-ietf-lamps-pq-composite-kem-and-draft-ounsworth-lamps-cms-dhkem}

Russ: The list of algorithms seems long. Can we shorten it.

Mike: No idea how to do it yet. Do we need to parameterize SHA3?

Chris Patton: Why are we keeping RSA in this use case?

Mike: We keep RSA because it has been "battle tested" and we keep it
while we are learning new crypto.

Michael: Can we add the various algorithm structures here, reduces the
pointers to other documets?

Mike: We can add an appendix that includes the structure.

### Under consideration for adoption   {#under-consideration-for-adoption}

#### draft-housley-lamps-norevavail   {#draft-housley-lamps-norevavail}

Mike StJohns: This is useful, why limit it to shortlived certificates?
Let's apply this to long lived device certificates too.

Russ: The change that was just approved in X.509 allows this extension
to be used in public key cetificates as well as attribute certificates.

Mike StJohns: No expiry language should be addressed.

Guillin W: What should the validity be for a certificate that uses it?

Tomofumi: The CA and will state expiration that in the CP/CPS.

Micheal: You should provide status information for IDevID and LDevID
certificates.

Action: Start a call for adoption.

#### CMC-bis   {#cmc-bis}

This covers three drafts:

*   draft-mandel-lamps-rfc5272bis
*   draft-mandel-lamps-rfc5273bis
*   draft-mandel-lamps-rfc5274bis

Motivation is to remove the SHA-1 and HMAC-SHA-1 as defaults, and to
process errata. Will ask for a call for adoption after the next version
is posted.

#### draft-gazdag-x509-hash-sigs   {#draft-gazdag-x509-hash-sigs}

Russ: Does anyone think this document is not ready for adoption?

Hendrick B: Propose looking at addtional recommendations beyond just
NIST.

Sean: Let's get this in the WG, and then figure out the text.  
There might be a call for proposals for how to handle state management.

#### draft-ounsworth-pq-composite-sigs   {#draft-ounsworth-pq-composite-sigs}

Mike O: Does the Strong Non-Separability addition allow us to relax the
requirement that you MUST NOT re-use component keys between composite
certs and single-algorithm certs?

Britta Hale: Actually, given the choice between an OID-based signature
domain separation, and a cert-based key binding, I think the cert-based
key binding is stronger, so I would not remove that requirement. I will
be presenting a draft on this topic at PQUIP later this week.

Tim H: Any objections to a call for adoption?

Rich: Willing to adopt.

#### draft-ounsworth-lamps-pq-external-pubkeys   {#draft-ounsworth-lamps-pq-external-pubkeys}

Russ: I would like more discussion around this on the list.

Scott F: Would this make sense other use cases? Will put a question in
the mailing list.

Max pala: supports the work and might use it.

#### draft-housley-lamps-cms-sha3-hash   {#draft-housley-lamps-cms-sha3-hash}

A call for adoption call is in progress.

Mike StJohns: Even if this is not needed for the composite documents,
having the SHA3 OIDs will be helpful.

#### draft-lamps-okubo-certdiscovery   {#draft-lamps-okubo-certdiscovery}

There was no time to talk about this document.