Minutes IETF114: lamps: Wed 10:00
minutes-114-lamps-202207271000-00

LAMPS WG Agenda at IETF 114 -- 27 July 2022 at 10:00 EDT

0) Minute Taker, Jabber Scribe, Bluesheets

1) Agenda Bash

2) With the IESG or the RFC Editor
a) draft-ietf-lamps-documentsigning-eku (Tadahiko, Tomofumi, Sean)
b) draft-mtis-lamps-8410-ku-clarifications (Sean, Simon, Daniel,
Tadahiko)
c) draft-ietf-lamps-cmp-algorithms (Hendrik, Hans, Mike, John)
d) draft-ietf-lamps-cmp-updates (Hendrik, David)
e) draft-ietf-lamps-lightweight-cmp-profile (Hendrik, Steffen, David)

3) Active PKIX-related Documents
a) draft-ietf-lamps-rfc3709bis (Stefan, Russ, Trevor, Leonard)

4) Active S/MIME-related Documents
a) draft-ietf-lamps-header-protection (DKG, Alexey, Bernie)
b) draft-ietf-lamps-e2e-mail-guidance (DKG)

5) Under consideration for adoption
a) draft-richardson-lamps-rfc7030-csrattrs (Michael)
b) draft-housley-lamps-5g-nftypes (Russ, Sean, John, Daniel)
c) draft-wallace-lamps-key-attestation-ext (Carl, Sean)
d) draft-turner-lamps-nist-pqc-kem-certificates (Sean, Panos, Jake,
Bas)
e) draft-massimo-lamps-pq-sig-certificates (Jake, Panos, Sean, Bas)
f) draft-perret-prat-lamps-cms-pq-kem (Ludovic, Julien, Mike)
g) draft-ounsworth-pq-composite-keys (Mike, Max, Jan)
h) draft-ounsworth-pq-composite-sigs (Mike, Max)
i) draft-becker-guthrie-cert-binding-for-multi-auth (Alie, Rebecca,
Mike)
j) draft-uni-qsckeys (Christine, Silvio, Basil, Tamas, Michael, Dieter,
Joppe)
k) draft-kario-pkcs12-pbmac1 (Hubert)

6) Wrap up

Document signing:

CMP Algorithms: passed IESG review ready for publication

CMP updates: addressed IESG and AD comments, ready for publication

LW CMP profile: updated, waiting for AD review.

IESG requested RFC4210bis and RFC6712bis: Opens the scope of change to
the entire document. Russ: this is a document the protocol not redesign
the protocol effort. The original authors have to give the rights to
update the document (this is possibly already done?).

3709 bis: consensus has been called.

Header protection: DKG reported that there is a subtlety that has to be
addressed. DKG says he has the action to complete.

End to End Mail guidance: DKG is waiting for review/suggestions. He's
looking for contributers and lesson sharing. Russ and Alexi have agreed
to review. Alexi reported that he had reviewed an earlier draft, and
that terminology might need to be aligned. He will read again.

CSR Attributes (draft-richardson-lamps-rfc7030-csrattrs): There were
issues in the original draft and in the RFC, but that has all been
corrected. Insert ASN.1 here.... the goal was to fix the ASN.1 without
breaking what is in use today. Sean asked for adoption. Roy Williams @
Microsoft asked if UTF8 was going to be required. Russ/MCR answered that
the field was a choice where UTF8 was chosen. The authors asked for Roy
Williams @ Microsoft to provide an example that was not UTF8.

X509 Cert Extension for 5G Network Function Types (NFTypes)
(draft-housley-lamps-5g-nftypes): Sean Turner. Simple draft on how to
put 3GPP NFTypes in certificates, to support 3GPP. NFTypes are all ASCII
strings, listed in a 3GPP spec. Decision is to define a new extension
NFTypes which is a sequence of NFType objects. Asking for WG Adoption.
Russ Housley: NFTypes define in 3GPP specs are all 8 characters or less,
have 4x that for safety. John Mattsson: this is already done in a bad
way in 3GPP, don't think it's been discussed there. Sean: If 3GPP want
to do it themselves then that's fine. John: Next step is to get 3GPP
agreement and discussion. Rich Salz: Support adoption.
TimH: Seems like most are in favour of adoption. They will take it to
the list.

Key attestation: Carl Wallace (CW). Draft defines key attestation
extension. Uses WebAuthn Attestation Statement Format. Would like
adoption.
Thomas Fossati: Are you creating IANA registry in your draft? CW: That's
the plan.
TF: Will you coordinate with W3C? CW: Don't think that's necessary.
Stefan Santesson: There is overlap with ETSI mechanism in qualified
certificate statements extension, want to make you aware there's a
widely deployed function. (Link -
https://www.etsi.org/deliver/etsi_en/319400_319499/31941205/02.03.01_60/en_31941205v020301p.pdf)
CW: WebAuthn format is also widely deployed.
Monty Wiseman: Simple binary of hardware and software is going to be
hard for people to use. Appraiser will need more information than a bit.
CW: Can you post this to the mailing list?
Sean Turner: Worried we'll refer to SCEP and downref it and it'll become
standards track. Flagging to ADs.
Leif Johansson: Relying parties don't have a lot of experience in
processing WebAuthn format. Refers to NIST 800-63 and Vectors of Trust.
Advise taking a look at what's been used in digital identity industry as
alternative or addition to WebAuthn. Maybe define something that can
encompass WebAuthn and other things. Don't pick winners.
Michael Richardson: Have read draft. Does LAMPS want to fight RATS for
it? CW: No RATS in this draft. Russ: This points to attestation formats
that are already defined, if it was defining a new one it might be for
RATS.
Russ: Any objections to adoption? No objections, will take it to the
list.

PQ KEM Certs (draft-turner-lamps-kyber-certs): NIST only chose one KEM.
Draft will specify Kyber public/private key format, get OID from NIST
and not include parameters. Instead alg (OID) identifiers will specify
parameters. Sec considerations will point to algorithm specs.
John Mattsson: How will OIDs work for security levels? Sean: One OID per
security level. JM: Does NIST want our input? ST: We're not trying to
usurp NIST, will go with their decisions. Roman: Charter says we take
what NIST do.
Mike Ounsworth: Key Usage isn't straightforward. KeyTrans and KeyAgree
are both wrong, but we don't want a new EKU. We just need to agree.
Sean: Think we agreed on KeyTrans, will make sure it's consistent.
Paul Wouters: Please don't name anything with a dash or space because
that's awful for people who code in C.
Sean: Asking for adoption.
No one opposed to call for adoption, will go to list.
Mike Ounsworth: For PQ stuff can we adopt, do the work, and then pause
to wait for NIST? Sean: That's exactly what

we're doing.

PQ Signature Certs (draft-massimo-lamps-pq-sig-certificates): Jake
Massimo. Signature version of the above. Aimed at "pure" PQ certs, not
hybrid. Interest from industry who need long-term root of trust that's
difficult to re-issue. NIST has announced they will standardize
Dilithium, SPHINCS+, Falcon. This draft will define data structures for
use of quantum-safe Dilithium, OIDs will come from NIST. Key discussion
points: how many algs per draft? Suggest one. Which security levels to
include?
John Gray: Support this.
John Mattsson: Support this. LAMPS should do everything NIST
standardise. On OIDs, for LMS we have one OID for all security levels,
are we saying that was wrong? Russ Housley: Algorithm spec for LMS is
different, in LMS the key encodes the parameters. Doesn't seem that'll
be the case for PQC signatures.
Orie Steele: Support this.
Russ: One draft for all algorithms or one per algorithm? Sean: Separate
drafts for algorithms. John Gray: Separate. Orie Steele: Separate.
Roman: Personal opinion - separate, AD hat - will support consensus.
Poll: 41 in favour of splitting algorithms into separate drafts, 1 for
having them together.
Will have call for adoption for a Dilithium draft.

Composite keys: Admits that there might be an argument that hybrid isn't
required. The author thinks that there should be a standardized way to
do hybrid independent from the algorithm specifications for the
community that requires it. The author is asking for adoption for both
the composite keys and composite sigs drafts. There is a new composite
kem draft. DKG commented that these allow a wide range of choices and
why the is the flexability necessary. The author talked about OIDs and
the options for those. ST brought up the ECC integrations where there
were too many choices. The author's plan is to going participate in the
hackathon. Composite vs non-composite: the author argued they were
complementary, and they both might be necessary.
Jonathan Hammell: Would like to keep the combiner modes (OR, KofN mode)
separate, this draft should just include the AND mode.
DKG: I think this should be adopted. I agree we should just have the AND
mode in this draft. Mike Ounsworth: There are use cases for OR now.
Every time I take it out I get pushback.
Viktor Dukhovni: How does this play into TLSA records? Mike Ounsworth:
Is this different from RSA which can be used with a number of different
signing algorithms? Viktor: In TLS you negotiate signing algorithm on
the wire. Discussion goes to list.
Deb Cooley: Who do you envisage as the users of these things? I don't
see large PKIs using these tools. Mike Ounsworth: I don't have an answer
I can say publicly. We do have customers.
John Gray: We expect some changes based on what happens on the mailing
list. Think customers would appreciate this.
Roy Williams: Building this and hoping somebody comes to it is a
non-goal. Need someone who says they want to use this.
Russ Housley: Does anyone object to a call for adoption on composite
keys. TimH: Uri Blumenthal objects in chat. Russ: Will discuss further
on list.
Russ: Call for adoption on composite sigs? Jonathan Hammell: If the plan
is to significantly change from what it is now I object. Russ: At least
one person against adoption in chat.

Composite-KEM: Brand new. Contains two things that need crypto review 1.
Transforms to treat everything as a KEM. 2. Cominers to combine multiple
component shared secrets. Please review.

Related certificates for use in multiple authentications: Rebecca
Guthrie. -01 version uploaded in June. Changes from -00 draft: Title of
document changed, added section with use case, narrowed scope of
document to two certificate case. Have made changes to
relatedCertRequest Attribute including changing signature to include the
requestTime (concatenated with certID). RelatedCertificate Extension now
includes hash of entire certificate rather than just certID.
Is the time just a nonce? Rebecca: Included to prevent reuse.
Russ: Any objections to adoption? No objections so there will be a call
for adoption.

QSC key ID and serialization: Mike Osborne briefed. This draft is about
key storage issues wrt PQ keys. Asking for adoption.
Russ: Concerned that the direction you're taking is different from the
direction we've decided on. We can't get ahead of NIST so the way this
is structured we can't publish this until NIST has standardised all
algorithms. Mike: Happy to split this into four documents.
Michael Richardson: This document contains private key formats for
PKCS8. There might be a lot of commonality between documents. Do we need
to repeat ourselves? Russ: They're different enough, we need to repeat.

Sean Turner: I have private key format in my draft, so we need to decide
where this ends up. In the past having choices didn't help with
adoption.