Session 1 - Tuesday 22nd July
Note-Taker: Flo D.
SESSION 2, SEE WAY BELOW.
We now have numbers for the last three of these. Expect all of these to
be RFCs by next meeting.
a) draft-ietf-lamps-rfc7030-csrattrs
This is now in the editor's queue
b) draft-ietf-lamps-dilithium-certificates
c) draft-ietf-lamps-kyber-certificates
d) draft-ietf-lamps-x509-slhdsa
e) draft-ietf-lamps-rfc{5272,5273,5274}bis
f) draft-ietf-lamps-private-key-stmt-attr
g) draft-ietf-lamps-cms-ml-dsa
h) draft-ietf-lamps-x509-alg-none
No issues with any of these.
Hannes Tschofenig, Mike Ounsworth
Responding to feedback:
MSJ says the hint is defined vaguely and should be locked down or
removed. The authors put this in for the case where this is a
container and the CA/RA don't need to know what is in it so this
allows abstraction. We think there's a valid use case and this
solves a necessary problem.
MSJ: This is not what I said. I said the hint is at the top level of
this so will be in every single evidence statemet. So it needs to be
normative. So you can't define it vaguely and expect an implementer
to understand this. I suggested that you put the hint down in the
container in the evidence statement. This is at the top level of the
evidence statement not in the thing referred to as the evidence
statement type. Serialise it to binary, put it in an octet string in
the structure that contains the hint.
Mike Ounsworth (MO): That's what we're doing. The typefield is an
OID.
MSJ: The statement type is identified by the OID.
MSJ: You should have it in informative information that no one has
to implement unless they're doing your thing.
Hannes: I think this should be a URL to make the type more strict.
If you recall the passport model, there an attester needs to be
configured with the URL. Having a URL which would be tighter and
more restrictive would solve that problem.
Hannes: TPM based attestation, there's one format, it's TPM.
Mike Ounsworth: WebAuthn is another example.
Hannes: TPM could be used by different companies. They transition
from the EK to the AK, and you are signing with the AK for a
different vendor.
MSJ: It's the same format, it may be different set of certs.
Hannes: That's the point. I don't want to register TPM for all
different companies.
MSJ: Why not? That's the way we do that. I think the way this is
being done is problematic. But with regards to the hint, it's
normative now and it doesn't have enough information.
Hannes: You don't have to implement this.
MSJ: But it's normative, how do I know if I populate it or not.
Hannes: There's lots of text that says you don't have to. If you go
to the RATS meeting you'll see that lots of people worry about
configuration with many attesters. So if you don't have to worry
about this you don't have to populate it. It's optional.
MSJ: You need guidance on how to populate this field. This is vague,
vague on purpose is lazy.
Hannes: We've changed the text lots of times in response to this.
Russ: I asked on the list if there was a need for hints of various
structures or if this is the only one. No one answered on the list.
I want to know if Mike is in the rough.
POLL: Do you have a need for a hint that cannot be represented in
the URI without a scheme?
Yes: 2, No: 5, No Opinion: 39
Russ: It's very clear that most people don't care. Can the other
person who has a need come to the mic to tell us what it is?
MO: MSJ says he doesn't need a hint, he needs an AuxData. A piece of
data that comes in three parts such as a blob, a signature and a
cert chain.
MSJ: That's one example.
MO: Hint could be a type of AuthData
MO: Why don't you define yourself an ASN.1 object for this?
MSJ: Why couldn't you do serialisation for your container stuff.
MO: This document doesn't own WebAuthn. It's much more reasonable to
ask you to wrap your own data.
MSJ: How many container based things are there?
MO: I don't know, this is just a container. It's not our job to
categorise every thing that exists in the world.
MSJ: My idea is backwards compatible and doesn't break your stuff.
Why are you fighting it?
Hannes: Because you're making things complicated for an unknown use
case.
MSJ: I've been making attestation systems for smart cards etc. for
15 years.
MO: If we have an AuxData field you'll still need to define an OID,
I don't understand how it's saving any work.
MSJ: Going back to hint. For a given OID, someone parsing the ASN.1
won't know if the hint is there or not.
MO: It's valid to ignore the hint.
MSJ: From a compliance point of view it would be good to know if the
hint is meant to be there.
MO: That doesn't match the use case.
MSJ: If you're saying hint is required or hint should be present...
MO: We're not saying that.
MSJ: This is a change I've suggested, it's not more complicated. You
don't care about the hint field.
Hannes: How did the TPM implement remote attestation.
Russ: At the time you define the OID, the way you define the class
tells you whether the field is mandatory or optional.
Martin Wiseman: There is one for the TPM to certify, that tells the
verifier what to do. There is more than one way to verify the
attributes of the key. That would tell the verifier how to interpret
it. In my use case I want to tell the verifier what to look for. I
don't want to be required to specify in the OID whether or not
there's a hint and what the format of the hint is because that's
going to be domain specific. I would oppose the OID being a
requirement (?) because that would put the burden on TCG and it's
domain specific.
MSJ: Choice is the enemy of security. There are too many choices in
this, so how do you make a secure solution?
MO: Ignore the hint if you want.
Hannes: Sometimes we have to face reality that different
technologies have come up with different ways. We have to navigate
this ecosystem.
MO: I can't take WebAuthn payloads from one device and feed it to a
different parser.
MSJ: Why aren't you using different OIDs?
MO: That's a criticism for W3C not us because the WebAuthn OID has
been registered.
MSJ: That's the type of the field, but the evidence statement type
is different.
MO: We could require that the OID is unique.
Draft is in WGLC.
MSJ: This isn't ready.
Russ: I don't have advice because there are two ways of solving this but
the bulk of the room doesn't care which one is picked. We need to pick a
mechanism. I could flip a coin but that won't satisfy anyone. Can we
work through the WebAuthn example with the W3C assigned OID?
MO: Understood.
Hannes
Joe added a big missing piece yesterday.
Joe Mandel - I added support of CMC, a generic way to request the nonce
from the server.
Hannes - I think that deals with the remaining discuss. I think we can
move forward on the document fairly quickly. That's what's been holding
us up. We're going to merge the PR. Wait until we resolve the other
issues. I'll send a message to the list.
Corey Bonnel
Recap from IETF 121: CAs can delegate the signing of CRLs to other
entities. Entities are issued an EE certificate with the cRLSign bit in
the keyUsage extension. (see slides)
Proposal for this meeting is to change language on keyUsage extension
verification to verify that the keyUsage extension is present and well
as verifying that the cRLsign bit is set.
Document is currently is WGLC. Michael StJohns provided very useful
feedback that we incorporated in this version. Also useful comments from
Carl Wallace. We'd like to encourage additional comments and feedback.
No comments on this document. MSJ is happy with proposed change.
Russ: We'll wrap up the last call next week or so.
Corey Bonnell, Joe Mandel
Successfully adopted in Bangkok.
This usees the subjectInfoAccess accessMethod to allow a certificate to
point to another certificate. Allows for cross-linking end entity and
potentially CA certificates. Can contain a URL so the related
certificate is easy to fetch. Backwards compatibility and hybrid
security are not automatic but clever verifiers could use this to
achieve them.
Comparison with RFC 5697 - this is an X.509 extension that allows for
pointers by hash to another certificate. This doesn't have a URL to
fetch the certificate so a client would need to know how to do this in
advance. Also this doesn't allow you to simultaneously issue related
certs.
Comparison with RFC 9763 - also uses hash value of related certificate.
Does not have a URL for the client to realise that retrieval. Has
dependency where one cert with always only point to the other.
Since Bangkok we've added support for direct or indirect certificate
references. Direct embeds the entire certificate, indirect includes a
URI. We've also added DiscoveryPurposeIds which allow tagging of purpose
of certificate relationship.
Next steps - looking for feedback and comments.
Viktor Dukhovni: Is discovery ever necessary to process the cert or is
it always optional?
Corey: It's a supplement to normal cert validation. We see this as
useful if you have an ML-DSA signing cert but you want someone's ML-KEM
cert. If you don't need the information you can ignore it.
Henry Birge-Lee
CAA security tag is a new CA tag. The tag allows domain owners to
request that a more cryptographically secure mode of issuing
certificates is used to issue certificates for their domain. Protect
against man in the middle attacks. SC-085 passed at the CA/Browser forum
requiring all CAs validate DNSSEC for DCV and CAA DNS lookups. This
allows security properties in the tag to be upheld. We get downgrade
protection even if not all CAs adopt this tag.
We've modified the security considerations, removing those inherited
from CAA tags in general and adding some about the use of recursive to
authoratitive DoH. We've also added additional examples of DNS records.
Next steps - we need more WG feedback, looking at implementation in
OpenMPIC, implementation in Let's Encrypt codebase.
Russ: Thank you for the good work
Postponed until Wednesday
Postponed until Wednesday
Joe Mandel
WGLC ended some time last month, no comments.
Michael Richardson
We've had this conversation in ACME. You know when it will expire, but
you don't know when you're allowed to renew it. In ACME they'd like a
mechanism that tells you different. In IoT it's often useful to have a
dashboard of certs eligible for early renewal. Some devices are
air-gapped/offline so you might only have limited times you can update
them. ACME has RFC 9773 to do this and we want to do the same for EST.
That's basically it. It should be straightforward to port the ACME RFC
9773 to EST. We want exactly what they have.
Deb Cooley: Do you want the same as ACME's RFC for EST? For the client
to tell the server when it wants to renew?
Mike Richardson (MR): You want to update certs not just at 50% point but
over wider time. Some certs have really short life times so they want to
update at the last possible moment. The over side is that you might want
to issue a ten year cert but you actually want it to renew in one year,
but should something bad happen you are not going to deal with lots of
systems expiring. The other part is come and visit me every year because
I need to tell you something.
Deb: That's not what ARI does. Why not just configure the EST client to
go more often without a change to the protocol.
MR: You could do that but then you have different products configured
differently.
Deb: As you want.
MR: But you don't want to configure these clients specifically, you want
the CA to say what's going on.
Deb: Architecturally why should the CA be dictating? The CA should just
be responding to CSR.
Mike Ounsworth (MO): Dashboard use case. In that case it's not the
person holding the cert who has the requirement, it's the dashboard. ARI
does that, ARI allows you to query by serial number. To me that's the
interesting use case, to allow a third party to query who is eligible
for renewal.
Sean Turner: Central Key Manager might be the one who wants the updates.
Sean: I did a doc on cert extensions a few years ago, we had...(missed
this) ... rfc8295. I don't think this sounds like a crazy idea.
MR: The policy is centrally managed by the enterprise, we don't have to
go to a variety of devices to tell them the policy.
Scott Fluhrer: When a client does renewal, can one of the responses from
the CA be that you don't need to renew now but should check back soon?
MR: There's a retry message, but that's mostly about the CA being busy
and saying the client should check back in 60 seconds. Maybe it could do
this, but I don't know that clients should respect that. That may be a
problem. It would be nicer if we could schedule it rather than error it.
Scott: One of the use cases you mentioned was that the CA might say that
in a month it might change its policy in a month so you should come
back. This should allow the policy not to change.
MR: That might be a reasonable addition. You might also start reducing
the time periods.
MR: Any major objections or misunderstandings?
Valery Smyslov: Can a device come early or will it be rejected?
MR: That was Deb's question, do we have an error code that says you came
to early. Maybe, maybe we need a clearer error code. We could have
ignorant devices that don't know this extension, not clear what to do
with devices that don't know this for policy.
Rich Salz: I think the use cases are real. But using ARI is like turning
it on its side. This doesn't tell you want the maintenance windows are.
MR: The proposal is to do exactly what ARI does. It tells you the
windows to come back in. The side conversation is what if it comes back
too soon.
RS: What if my cert is good for 6 months, but knowing if the truck comes
in one month or four months, it doesn't address that situation. The
question isn't do I have to replace the cert, it's can I replace the
cert. I've put more on my issue in the chat.
John Gray: What if a device is told they can't renew, but if they know
the next time they come in the cert will have expired.
MR: In that case you've misconfigured your lifetimes.
John: What if something changes on the client and the server doesn't
know.
MR: Today you'd start trying at 50% and that may be too late for some
things and too early for some things. Rifaat has a customer that wants 4
days certs.
Session 2 - Wednesday 23nd July
Note-Taker: Michael Richardson
MO: reports that the examples are now generated by running code!
((brief discussion that the "Use In CMS" sections have been removed from
both composite documents and will be submitted as standalone documents
once these ones ship. Since this is a section removed from an adopted
document, the Chairs will short-cut the call-for-adoption.))
MIC (Sophie): when will the breaking changes stop? I value a stable
document more than any of the things being bike-shedded.
MO/JG: we think that we are done with changes!
JM: I like the change to SHAKE256 for EdDSA. The randomizer r removes
the problem that some combinations lose the CMA properties of both
pieces, but this resolves that?
MO: that was not the reason we added it (might be true), we were looking
at whether or not one could decompose (or recompose) in order to trick a
verifier. A similiar thing, if you have two composites (2+2 keys), can
you swap among the four keys to trick a verifier.
Bas: for better or worse, people look at LAMPS and copy what we do. Not
sure if the randomizer is helpful, but if people copy this, it might not
ad value for them.
---> topic taken to ML.
Explaines why are not mixing the public key into the signature combiner,
and decided not to make a change.
Dan vG: My request to include the entire PK in the signature combiner
would allow you to reuse, for example, the ML-DSA key between two
composites.
MO: You can, if you wish, stuff the public key into the CTX at the
application layer and this acheives the same thing.
Discussion about SHA384 vs SHA512, but since SHA384 is truncated SHA512,
there is no point in having SHA384, even if some parameters are
different.
Question about how it works HMAC vs truncating.
MO: Pseudo-code for combiner: So it's do HMAC-SHA512, and then truncate,
because it's not more work than 384.
ViktorD: mic concern without explicit lengths.
MO: do not make this generic (message from WG). So what do we want to
future-proof? Would like specific instructions.
SeanTurner: TLS has not yet adopted this tech, and is waiting.
?: at the crypto layer, to treat this as a monolithic thing, it won't
work, because you need to split it up to feed to multiple HSM? PKCS11
version 3.2(?), is out, and there are no composites...
MO: but a new PKCS11 version with composites is imminent.
MO: is trying to avoid ASN.1 in the public key so that other users will
not want that...
Discussion about fixed length things here, so no need.
MIC: prefers not to have to sandbox their ASN.1 parser.
VD: not asking for ASN.1 length, a simple length would be fine. 3-4 byte
integer.
MO/JG: this was in the previous version.
CONSENSUS: 3 or 4 byte length tag (not asn.1 encoded)
.. objection from MIC? What VALUE does it add?
VD: for the private keys, it means that you can split them apart without
knowing anything about the details of the private keys. And for the
public key, you can also split them up, and hand them off, and you don't
have to write special code for each algo.
Thom Wiggers: you don't need special code, you need to recognize the
combination coded, so you don't need length.
MO: can we do a poll?
defer until later
POLL: Do you want to include an explicit length into the public key
encoding?
results: y:8, No:31, no opinion: 16. Overwhelming support for not having
explicit lengths.
Deirdre: including the domain separator already includes the lengths,
it's not parsed out, it's right in the separator, so the lengths are
implicit and already there. (We still have future-proofing already)
Discussion about whether or not HSM modules do not support (and has no
plans to support), seed.
DB: there are existing keys whose seeds were lost. This was the concern.
Since we forbid key re-use, and we have an upgrade path, there should be
no issue.
VD: people bought modules, dont know how to upgrade, and we had
stand-alone keys, so can we have a length?
DennisJackson: we had consensus in Bangkok, so close this issue.
POLL: Can you live with the seed-only private key format?
Y: 42, NO: 1, NoOpinion: 7. VD is in the rough.
RichSalz: openssl downplays compressed format (for ECPoint), so if
hardware prefers uncompressed, then go with that.
ScottFluhrer: what new interoperability issues are we introducing? This
seems like an existing interoperability problem.
MO: if we say that a composite key with an uncompressed key is not
allowed, then if we see one, we fail.
SF: if we have an existing system that isn't broken, then it won't be
broken in the future.
VD: IETF for optimize for interoperability first. Interop with existing
implementations, make it possible to use in the most number of
situations. So everyone has to support compressed and uncompressed (EC).
Everyone does both, or we have to pick one.
MO: We could do what Viktor and Scott wants, we could say that when it
goes into the combiner, you have to use (un?)compressed.
ThomWiggers: can't we convert from one format to another for modules
that care?
StavrosKousidis: would go for uncompressed. These are new algorithms, so
let's make things simpler.
JG: we haven't seen any issues at hackathon, so if we lock this down,
are there really going to be new problems?
DennisJackson: simple choice,
propsal from chat for classic key:
X25519 - [u8; 32]
X448 - [u8; 56]
P-curves - use uncompressed
RSA - use d
RB: we want a single calculation for the combiner, so the document needs
to be clearer here. Thus we have preferred format, and we can convert
between formats internally.
MO: does your comment apply to private keys too?
RB: the hash/combiner concern does not apply. Disagrees that supporting
everything contributes to inteoperability. Would prefer a single private
key format.
SF: agrees with RB. Public key format needs to be fixed.
POLL: Can you live with the document authors picking a single format for
the public values?
Y: 43, No: 1, No-opinion: 5. AUTHORS will pick A format (and not an
ASN.1 one. And not X962)
POLL: Can you live with the document authors picking a single format for
private keys?
Y: 42 N: 2 NoOpinion: 10. AUTHORS will pick A0. AUTHORS will pick A
DeirdreConnolly: Is this proposing a single EC format for all formats
that have been proposed everywhere, ...
Russ: each hybrid combination that the document details.
HenryCohen: mic not working?
UriBlementhal: Depends upon which format is picked... (Authors ask for
feedback)
ViktorD: forbid multi-prime RSA.
ACTION: chairs will do a Consensus Call on the key formats, and then
move on to WGLC.
draft-liu-lamps-mechanism-updates-to-rfc-5280(-07)
Path Verification Process.... section 3.x
SeanTurner: scan of first draft... thanks for the OLD/NEW, you are just
updating the references?
Not sure that we need to do this.
Discussion continues on list.
d) draft-ietf-lamps-keyusage-crl-validation (Corey)
e) draft-ietf-lamps-certdiscovery (Corey)
f) draft-ietf-lamps-caa-security (Henry)
6) Active S/MIME-related Documents
b) draft-ietf-lamps-pkcs8-prikeyinfo-contenttypes (Joe)