Internet Engineering Task Force 112, 11 Nov 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF112-ACME-20211111-1430

Description

ACME meeting session at IETF112
2021/11/11 1430

https://datatracker.ietf.org/meeting/112/proceedings/

A

I do like the preload of slides and then just pick from the list if it works, which it appeared to do this time.

B

I've been to other sessions where it didn't work so well.

A

It didn't work.

B

All right, it's not very dark.

A

A

Yeah not morning for you is it.

B

Now it's uh 4 30 in the afternoon.

B

um Which says that it's time to begin.

B

Okay might as well uh so yeah. We've got 32 people in the room. So why not? What we don't have is a note taker.

B

Oh russell is here: okay, good.

B

So welcome everyone. um This is the acme session at itf 112. That is not in madrid, so I think you've seen this thing, I'm not going to bother reading it out to you, and this is the other half so, and here's the new thing living with this coc we're not going to read that one out to you either, but um we've been asked to all working roof chairs have been asked to display these things at the start of meetings.

B

This is not any commentary on the dynamics of this particular group, which we think are just fine. So hopefully you've read this and if not, please do so now and follow it.

B

So with that, we can proceed to the agenda.

B

So there's the noteworld, the coc huh already done. We need a minute taker and russ housley. Have you volunteered for this to do this.

C

Did I'll be the note taker.

B

Thank you, and as for jet prescribe, we usually don't need those in virtual meetings, but just in case I am following the jabber room. So if you want anything relayed in on the well room mic whatever that means here and just prefix it with mick, and we will read it out so um we'll have the um traditional document update and followed by presentations for dta node id ari integration subdomains and then, if we have time any other business, any agenda bashing.

B

Okay, not only not in the job room either. So with that we can go to document update.

B

So we have a new rfc star delegation was published as rfc 1991-15.

B

So, um thank you all to joron, diego antonio and thomas, for doing the work see that uh pretty much none of them is here.

B

Yeah, oh well, not even thomas anyway,.

D

B

To them you can watch this uh watch me saying. Thank you on youtube. uh So the authority token draft zero, seven um draft zero seven was published at zero. Six there's a little additional text, some yana considerations.

B

It was broken into sections, whereas it was just one large section before and it's now in itf last call that lasts until next monday.

B

Right the authority. Token tnoth list was not modified since the last itf, the end user, client and code signing draft got two new revisions and didn't get a lot of discussion on the list that one review but well buy a chair. So that doesn't count um all right. So we've had two two updates of dtn node id. We have ongoing discussions with roman and they have a presentation.

B

So not a lot to say about that um integrations had one new version also have a presentation and subdomains also have a print station and they've been adopted and resubmitted as a working group draft, so zero zero draft any comments.

B

Anything I missed.

B

Okay, and with that, we can go to the presentation.

E

Hey yo, I just wanted to kind of repeat our working plan. We have one of the tn auth documents, the auth, token documents and last call we have the other one through last call, but we've had it parked now for a number of months waiting for the other one. So, when the when, uh when the authority token draft drops out of itf last call I'll be batching both of them and bringing them to the isg.

B

Okay, so with that it's time for the dtn node id draft, and I should have written who's doing them right, I guess yeah! So uh could you uh do you want to control the slides by yourself.

A

You can, if you click the little paper icon, you can there you go you did it perfect.

D

I think someone needs to authorize. Oh there. It goes great.

D

um This is uh gonna be short, which is good, and so there were two updates two document updates, but one set of updates since the last ietf and version04 and they're mostly related to the profile that this validation method is supporting the certificate profile.

D

So the dtn's tcpcl document is now almost in the off 48 state and thanks to russ hussley and others, we were able to get that document into a a good state with um a new um subject: alternative name uh oid allocation, and that is now reflected in the acme draft.

D

So before where it was using the uri san form, it is now using a specific bundle, eid, san and um so that was really a search and replace in the the acme document, just using a different certificate field and using a different acme identifier name to relate to that field, then there was another change that was made to clarify multi-perspective validation, to really make it a first class use of this validation method, in the same way that the htp and dns allow multi-perspective validation and provide some guidance about how to do that and requirements about what must be done.

D

In that case, there was a clarification of the the node id definition to be able to uh just make sure that the acme server is doing the right logic in the right places and uh cleaning up client inputs, and then the one structural change was that the previous version of this document updated a 2b rfc from the dtn working group and those updates have been now moved into a separate document.

D

That's awaiting the dtn working groups, adoption uh that will be discussed uh tomorrow actually, and so this acme document now is purely uh acme, and it's also at the experimental level just because this is new behavior, whereas the other updating document is at the standards level, and then there still are three remaining typo level issues in the document that I was waiting on after the itf.

D

One of them is a must not accidentally change to a must. That was a search and replace problem. Trying to claim the document.

D

There still are two uses of the uri name in the iana registrations that that need to be replaced by bundled eid, that's a simple fix, also and then the example bundles in appendix b. This is a very minor knit that they should use a different encoding form for um the array, a definite versus indefinite form in sibor terms, which is also it doesn't affect the interpretation it just affects the encoding form, so it's very minor and then one last open question. This is just in terms of the acme document um for for acme purposes.

D

uh Right now, the term dtn node id is used, but in the parlance of of dtn itself it's just called a node id. um This is a little bit different than the bundle endpoint id eid.

D

So it's just an open question of uh what makes the most sense for understanding what's happening. Dtn node id makes it more clear that it's a dtn term, but it could potentially be confusing because a node id can actually have two different uri forms, an ipn uri or a dtn uri. So dtn is a little overloaded in that represents both the broad topic area, the working group and a specific uri form.

D

um I don't have really strong feelings about this either way it's it's purely a terminology and making sure that people understand what is being referred to other than just saying. Node id.

D

And that's all I have on this topic.

B

C

How are you planning to resolve the last one.

D

uh For the moment, uh leaving it, as is just calling it a dtn, node id, so it's it's just qualifying dtn, as in the working group in the topic area, not anything else.

D

I just noticed that in other cases, the eid is called a bundle eid, and this is where uh the reason why it came up is because I was looking at the um uh the the challenge types and, like the other challenge, types aren't really qualified. In the same way, the email challenge type is just called email that the dns is just called dns.

D

um So this one's a little bit different in that the name is qualified, dtn, node id and not just node id, but it makes no difference other than extra characters.

B

Anything else anyone joining the queue.

F

Eric but as I was reading this draft and providing feedback on things like the multi-perspective, it was very helpful to me to have dtn node id every single time. It's just like right. It's just you that I, as an acme person, don't need to fully understand like I I could sort of encapsulate it and so that that nomenclature worked well for me, for whatever that's worth.

B

Okay, so I'm reading from.

B

Roman in the chat that um assuming everything is resolved and fixed, it could be in the chat as soon as december, 2nd so.

A

So I think that's for the for the star drafts.

E

Yeah, that's right. That was my comments, you're exactly right, yeah or for the authority token draft. So the etn after we get this straightforward thing resolved. Thank you for all the edits, brian. uh We can go last call, and so that's that's gonna be at least two week delay. So I haven't looked at the calendar. I think the december 16th telechat is more realistic.

B

Yeah, that's fine good, um so we might even have another rfc by by next itf.

D

The the only thing that would uh hold up the final approval is that this document now relies on the dtn working group document, which has not yet been adopted, so they would end up needing to be in the same cluster in the editor's queue.

B

Well, yeah clusters in the editors queue are a known issue.

D

So that's the only complexity.

B

Okay, so there's nothing else and thank you, and next up is aaron with the ari.

B

Can you do the sharing thing.

F

um I think the slides are up. Yep yeah awesome fantastic, uh so this draft is uh completely new from acme or from ietf 111. I did give a presentation about it at the interim, but I think we had a slightly smaller group there. uh So hopefully folks have have read this draft. I'm not gonna be going over the entire thing, like I did at the interim uh since that acne interim I've published a new version version zero one of the draft uh I'll go over.

F

What's in that, in just a moment, uh we've deployed an initial server implementation in let's encrypt staging environment, so uh code which implements uh this draft spec, is uh written and deployed. It's not particularly intelligent yet, but it does work and it does abide by the draft and an initial client implementation in cert bot has been, has been begun, but is not yet actually landed in cert bot uh trunk, so that piece is still in progress uh changes since uh version 0 that was presented at the interim, uh the based on feedback.

F

From that interim meeting, the renewal info url is now directly constructable from the subscriber certificate. I'll go over that in more detail in just a minute. Other smaller changes uh get is now the only supported protocol.

F

The majority of the acme endpoints uh require post as get uh even for item potent get like things, but we don't have to follow that with new extensions to the acme protocol, with with new endpoints being added and practical experience has shown that that's actually kind of a pain because it makes caching really difficult and so for things that don't require any authentication. There's no need to carry that forward, and so this says, hey we're.

F

Only going to use, get um I've added small pieces of clarifying behavior for how clients should behave in certain circumstances, for example, if they don't get a ari response at all, if they get a malformed ari response, if they get a response that doesn't mesh nicely with the frequency at which the client tends to wake up, because, as we know, many clients are implemented as cron jobs, not as long-running demons and a bunch of small formatting cleanups that are barely worth mentioning.

F

um So the renewal info url uh it used to be in draft zero, zero that a finalized order object. In addition to having a here's, where you should go download your certificate from url would also have a and here's where you should check for your renewal info url in it. So a acme client would finalize an order, save that renewal info url locally somewhere cache.

F

It write it to disk something like that and then would query that url over and over again, um however, feedback that we got said a caching that url is kind of a pain for certain kinds of clients, and also external monitoring. Services would like to be able to construct these urls directly and external monitoring services. Obviously, don't have access to order objects, so we've changed it so that the order resource is now completely untouched and unchanged.

F

Instead, we've added a new field to the directory uh renewal info listing the base url for the renewal info resource type. So any client can fetch the directory and see where renewal info will be surfaced and then the remainder of the renewal info url, which is just a a path blob effectively.

F

It could be query parameters or something like that, but we're going with a path blob for now uh is constructed from case insensitive hex encodings of the sha one hash of the issuer, key the sha1 hash of the issuer name and the certificate serial number.

F

These are the same components that we use for ocsp and in particular mandating sha-1.

F

Hashes is the uh oh, I'm forgetting the name of the rfc now, but it's the uh ocsp for resource constrained or for high volume environments, where it mandates sha-1, instead of allowing the the client to specify what hash it's using uh when it hashes the issue or key an issue or name so any client that is capable of requesting ocsp is capable of constructing these three parameters, and we have industry-wide acceptance that these three parameters are sufficient to uniquely identify a certificate and therefore that's what we're going with for uniquely identifying a certificate for this renewal info as well.

F

So you make a get request to the renewal info base path from the directory concatenated. With these three path, elements computed like ocsp and you get back the same uh renewal info uh object that the initial draft zero zero had um there's still some open questions.

F

uh Obviously more questions might arise as the initial client implementations are written and deployed, but right now the known, open questions that I would love feedback for at some point um are one pulling semantics right now, as you can see in this response, the renewal info response comes with a retry after header saying, hey I've, given you the renewal info, please don't check back for at least this long, um but that only gives us half of the semantics that we actually want.

F

We want to both say: hey, please don't check back for at least, for example, six hours, but then we also want to say, but please check back as quickly after six hours as you can, because part of the point of this is that we want clients to be checking in frequently, so they know instantaneously if their renewal info suggested renewal window has been updated.

F

um So thinking about changing the semantics of this, whether we want to continue doing it with a header or whether we want to incorporate the suggested polling window into the renewal info response, whether we want to incorporate it into like the meta section of the directory, or something like that. um So if people have feedback on that, I would love to hear it. um Yes, I see in chat, I see, there's been some discussion in chat.

F

I will read that in more detail momentarily, but yes, uh not quite instantaneously, but quickly as quickly as is reasonable. We've been talking about things like on the order of six hours or one hour. um The second consideration is a larger change. um We've been thinking about the idea of there being a callback, endpoint, uh basically a way for clients to say uh hey. You told me that I should renew this cert at this time.

F

That's done now. um One reason this would be helpful is because, in the use case, that is one of the motivating use cases for this extension uh in the use case. That is a ca, believes that it is about to revoke a cert, and it wants to give a subscriber an opportunity to renew that cert and have continuity of business before that certificate is revoked. uh Having this sort of callback endpoint would let the client say yes, it is safe to revoke this cert now or would let the ca determine yes, I know it.

F

This cert has been replaced. It is okay for me to revoke it now.

F

We're still just really thinking about this, we don't know if we definitely want to do it. We don't know what we want it to look like, but I would love discussion and feedback on how people think this should look and whether it's worth incorporating as well and then. Finally, uh I don't know how call for adoption works. This is the first document that I've brought to oregon group ever uh but after the acme interim, we did have one very kind and generous soul on the mailing.

G

F

Saying that they supported a call for adoption, and so I sort of wanted to put that out there, because I don't know how it actually works, um but yeah, that's it for me. I would love to take questions and I will catch up on the chat over here on the side.

B

So anybody queuing up with questions.

B

H

Hiya uh welcome to the itf um the uh recommendation and it can be handled once if the working group adopts us and makes changes right. Just so you know, adoption is means this document's a starting point right. So obviously it's not frozen.

H

um I don't see any reason not to just completely lose exactly and calculation is used for ocsp uh everyone's got an ocsp thing, particularly in places like let's encrypt, where there's no revocation. So I really strongly encourage that, but again that's more for a post-adoption thing. I think this is nice. The document is pretty well readable and you did a good job. Thank you.

H

B

Yes, anyone else.

B

Do we want to pull how many you read the draft other than which.

B

Okay, so rich read it and michael read it and.

A

I think they considered it right in the chat right. So if you've read it, yeah chat rather than running a real poll and yeah.

B

So um I think that's now that it's been presented in a real working group meeting. We can ask for uh people to read it today on the on the list and then do a proper adoption call. Rather than start it now.

F

Yeah, I'm definitely willing to put forward a new email on the list, opening list-based discussion for these two open questions and then one for adoption as well.

B

um It's good that people are seeing this.

H

The chairs will handle the adoption call. You don't have to do that right. Of course,.

B

Okay, so if there's nothing else, we can move to owen all right. Thank you. Thank you.

B

It's actually here.

C

A

A little paper document thing you can run your own slides.

A

On your little icon thing, there's a little thing that looks like a piece of paper.

B

Now, like the filing old windows, 3 or something.

A

Should be up at the top layer.

B

Yeah next to the hand icon between the hand, icon and the screen icon.

G

Oh, you mean just okay, so just click.

A

On it here, okay, I.

G

Gotta get so share me on slides. You should just like.

A

G

Yeah: okay, okay, yep.

A

I mean it's been there since last time, but it actually works today.

D

G

This would be really really quick, so draft five of acme integrations.

G

The only changes in stratfor um russ provided feedback on the mailer for draft four. That was a major issue with um which we knew we knew about, but we hadn't addressed um with roc 70 30 sees our attributes gap. We relied on using that for the um ra to tell the client what subject or sound to include um our c730 doesn't actually allow that. So there is a draft that rich or that might be presented at lamps um earlier on this week.

G

That will update rfc 7030 to specify how csr attributes can be used by an ra to tell a client attribute values that it expects to see included in the csr request, and so so. The integrations draft is now pointing to the draft and eventually allow us to specify how to handle um specifying a csr attributes, value and terminology change.

G

I just updated some of the terminology to align more with the rfc 8499 dns terminology draft, rather than to see a browser forum terminology. The reason for that being that this draft isn't um limited to web pki or ca browser use cases alone, and so it makes sense to align with the rfc terminology rather than the ceo browser technology.

G

And that is it, that's the only update, so we just need some more reviewers, and now that we've addressed one major issue, we can probably well the one major issue will be addressed once the lamb's draft progresses and we'll just ask the group for some further reviewers. That's it.

B

C

uh So I think we're gonna see speedy progress on on that uh csr attributes uh document, but this one's kinda stalled until we know what that one's going to say because right now, there's a bunch of placeholders in that document, as opposed to a full.

C

Update right, so my assumption is that that we're we really can't do a full review of this until that one uh gets done. Is that right, yeah.

G

That's fair, yeah, the um and the last draft is a very drafty draft.

C

Yes, like something needs to go here: drafty, yes, yes, okay, thanks.

A

A minute before we can really do another discover that it sounds like.

G

Well, like it is just one section like there is it's there's one section in the integrations drafts that refers to csr attributes draft, but I think the rest of the document, the power of that one section, can be reviewed.

B

Okay, anyone else.

B

Okay, so we'll send a message to the list that uh we really want people to review this, and um next up is also you, so you can switch here.

A

B

Can just switch it without.

A

G

Again, this will be a very short update.

G

So it's been changed since um the previous draft has been adopted. um We've made some terminology additions, not terminology changes, we've just referenced, we've included the rrc 8499 and we've also fixed up some editorial units. I think was iron provided a bunch of knits um on the mirror a while back. We fixed up all those and the big change. Really. The big thing I want to discuss really is, um and I think was, martin thompson provided some feedback on the adoption call mirror, and you said well, why are we using?

G

Why are we using domain space, the name domain name space and not sub domains, and actually the reason why we changed? That initially was because there was um some feedback on the meter that something means was a bit confusing, but uh so we changed to domain namespace to be more prescriptive, but it was based on the ceo browser definitions and I think, similar to active, integrations, acting sub domains is not restricted to web pki or ceo browser use cases.

G

So I think it probably makes sense to um align with the rfc8499 definitions and and therefore probably makes sense to change the field names in the json objects back to what you originally were and back to align with rfc 84.99. So that's that's the biggest thing that I'd like to discuss. We don't need to discuss it here, um but just some consensus on the mirror as to which terminology set to lean towards.

G

I think I'm actually leaning towards rot 84.99, not to see a browser stuff.

G

And that is it, that's the last slide very, very quick update the the biggest so there's no substantive changes.

G

The only thing you need to close on is terminology.

B

So I know this is a newly adopted thing, but it's actually a pretty old graph just stayed individual for a long time. How far do you think it is from completion.

G

um I don't think it's far from for completion at all. um It's it's it's! It's very close, uh like there's been a lot of discussion on the mailer over and back. It's been very bursty, but a lot of discussion on the meter about the details of the draft over the last 18 months. um So I think it's actually close to completion, but just the terminology is the one thing that you close on, but leaving the terminology aside.

G

I think the structures of the the structure of the protocol enhancements the actual fields we're adding to the json, I think is- is pretty close to complete. We haven't got any substantive feedback that needs to be changed or what's currently there, apart from maybe changing terminology.

B

Good, so any anyone else getting in the queue, no okay. So um thank you all.

H

Okay, thank you.

B

If you stop shining yeah, then I can go back to the chair, slides and I think we're done with our agenda.

B

B

A

So then the question is: do you want to talk about? um uh What do you call those things milestones that one that's the one.

B

Let's start with the, if there's any other of the business and then real aob.

A

B

We've got 25 minutes, so we're probably going to have time so anything else. Please get in the queue.

E

B

Seems like nothing and nobody uh there's one thing about the client certs and we tried to stir up interests and well. There was just nothing on the list.

I

It seemed like you were asking for me to speak with that, so um I have been working with a few people off list and there should be some text contributions to expand the use cases um or I'm sorry, not the use cases. The challenge types for a code signing certificate effort that has been.

I

um I guess it was announced um a few months back, but they used their own method instead of acme, and so this would allow them to switch over to acme and so not to create yet another automated certificate protocol that vendors would have to support. So you should see some more to come on that and- um and this was just raised in napa as well one of their use cases- they were trying to figure out a way to solve, um because that effort has very short. uh The code.

I

Signing cert effort has very short-lived certificates like in the matter of seconds, um so that they can only be used once and um that might work for gene app too. But that's we'll have to see what happens so you might see more and and we'll see um you know. Obviously, the draft should only go forward if there is real interest, but it seems like um a widely used effort in the linux consortium.

I

They are looking to switch over and extend this draft and use acme as a result.

I

So that would be a big implementation as well with many vendors.

I

B

I

Yep, thank you.

H

B

So now we I'll stop sharing the slides and start sharing the milestones.

B

B

B

B

Yeah, that's the milestones that we have, and uh obviously um all of the milestones that are not marked as done are marked with uh dates that are.

C

B

So should probably fix the uh april 2021 of uh delay, one network and the acme integration.

B

As for the user client and code signing well, we neither submitted it to the isg nor abandoned it. So it's kind of uh awaiting uh adoption, still so um roman d teddy say what you think we should do with this.

A

Can we just have people that are authoring? The drafts pick dates.

E

That's the kind of recommendation I'd be looking for.

B

Yeah I mean, I think.

E

B

Is uh really might as well pick december and uh as for the integrations.

B

Maybe next march and add the subdomains on top of that.

A

And integration drafts aren't linked together. Are they.

B

uh No they're not.

A

So you could do sub domains in the spring. It sounds like. The integration draft has a little bit to go with the lamps draft in tandem.

B

And then maybe well, it's too early to add them a milestone for ari, because we haven't decided that we want it still. But um that might be the next just before the next itf.

A

So what um kathleen do you have a date when you would expect to see the client or code signing thing solidified.

I

I would expect before the next meeting cycle, I'm supposed to get texts within the next week or two from this other effort, and- um and I can sync up with the gene app folks pretty easily to it- to see if it works for them once they have a little bit more time to review.

I

uh So I I think by the next meeting, we should be ready for working group last call if there's uh traction and it gets used for these use cases.

B

Some might as well set it to july 2022.

I

B

May as well.

A

Hopefully, yeah.

I

Hopefully we can overshoot it because the code for um for that other effort is, is coming soon. It's underway, so um yeah.

B

Okay, that sounds like a plan.

A

I mean: are these milestones more than just like sticking your finger in the air and making a guess, I mean what happens when you I mean. Obviously, we've missed them so.

I

Oh you just reset them, but I mean you try um that's why I'm I'm saying I'm hoping for working group last call by the next meeting, but um I guess uh you have has had experience that says it should go longer. So whatever you want to do is fine. I'm going to try to overshoot it.

B

Yeah, when the master is first submitting to the isg, so that obviously takes a little more time than just the um the work. The working group last call.

B

So unless I'm mistaken, I think this is all we have for today, so asking one more time. Is there anything else going once going twice? Thank you all for attending the meeting and I'll, hopefully see you next time.

A

Unless do you want to have an interim.

B

um That's a tough question um only if we have something very specific to discuss in the intern like if there's a lot more client content or something really new about aeri that comes up in in a potential adoption call.

B

A

B

Hey. Thank you all.

C

Okay, your notes are in the cody md.

A

Thank you very much for us.

C

Thanks for the people who augmented what I put in there.

B

Okay, so goodbye.