Alexey hasn't posted yet an updated version, and I edited the first part
of the minutes (the STAR portion only), now attached with my changes.
Chairs, please take a look, some of the changes are potentially
important, as they refer to action items (I went through the YouTube video).
Alexey, can you please merge them with your changes.
Thanks,
Yaron
On 09/11/2018 5:28, Salz, Rich wrote:
Nitpicking is why I posted so quickly :) Please post an edited version!
On 11/9/18, 9:51 AM, "Alexey Melnikov" <[email protected]> wrote:
Sorry for nitpicking, but below are my corrections to the minutes. I can
just send the updated version instead of a patch.
> ## Email TLS certs and EMAIL end-user certs, 15 minutes
> Who will read? Ready for WGLC?
>
> Paul Hofman: I don't understand the proposed change
> Alexey: At the moment service/port are single. If you wanted to issue
multiple
> ports (IMAP/IMAPS) it needs to be multiple requests.
> Paul: I see no reason not to have multiple services.
> Chaair: One array or two?
> Alexey: One array
> Richard: I'm confused. This document is talking about authenticating
> DNS, but what would go into a certificate is a Domain.
> Alexey: In theory you could issue SRV based IDs. In the most common use
cases
> that won't be used.
Change to: In the most common use cases DNS IDs would be issued instead.
> Richard: I think this should be updated to cover SRV.
Insert: Alexey: SRV is already covered in the document.
> DKG: I want to agree with Richard. If it's just on name, this is too complex.
> Several steps need including
> Alexey: For DNS there will be slightly specific service name.
Change to: For DNS challenge, there service name is included in the DNS
name used for the ACME challenge.
(_<port>._<service>._acme-challenge.<domain> TXT record.)
I think Richard also suggested to create a new DNS-based ACME challenge
type.
> DKG: If the cert being requested isn't specifically for the service, this
> could open an attack to other services for other protocols
> AI: Alexey to add some clarifying text, Richard to send some
> AI: After next draft, WGLC; READ
>
> Paul Hoffman: These details aren't clear in the current draft.
> Richard: We have a copy of layers of indirection, what I am least clear
on is
> the mapping of service to certificate. CA's may want to include SRV into
the
> cert if you show control of the domain.
> Alexey: I'm hoping they'll issue certs with the port
Change to: I'm hoping they'll issue certs with the service name
> Richard: I suggest you implement SRV service IDs
> Tim: SRV has been discussed but not implemented
> Tim: The assumption all zones in a domain are controlled by the same
identity is no longer true.
> Alexey: I am developing software that could develop software to validate
these, but first I need CAs to issue certs against this.
Change to: I am developing client side software that validate these, but
first I need CAs to issue certs against this.
>
>
I think it is worth pointing out here that now we moved on to the S/MIME
document:
> Yaron: Are you expecting end user to perform this challenge?
> Alexey: Yes, possibly through copy/pasting the challenge.
Change the above 2:
Yaron: Are you expecting end user to perform this challenge or email client?
Alexey: Both. If email client doesn't support this natively, it is
possible to copy&past the challenge to an external program and then
create a reply with the calculated result.
> Chair: Is there any provisiion for multiple clients?
Alexey: yes
> AI: Tim H and dkg said they would review
ACME at IETF 103
# ACME is meeting at IETF 103 in the last session, Thursday II. 16:10-18:10
Agenda is as follows:
## Administrivia, 10 minutes
Note well, jabber, minute-takers
dkg for Jabber,
Thomas Peterson for Minutes
## Brief updates, 10 minutes
ACME, CAA challenge, IP identifier challenge, ALPN challenge
Richard: I am still waiting for my co-worker to read an outstanding PR,
I will probably merge it later tonight
Chair: We will open another 2 week WGLC
STAR, 30 min
- ACME-STAR: Update as a result of the last-minute ACME changes, etc.
Was already in WGLC; seeking a doc shepherd
AI: Chairs to redo WGLC after the meeting (2 weeks), seek shepherd, and then
send to IESG
- START-delegation; now is an ACME profile, after feedback
Call for adoption
Richard: This is what is set to the IdO for DNS challenge? Yaron: Yes.
Thomas Fossati: No, the DNS challenge is run just on the regular identifier
name (the "value" of the CNAME), it is run by the IdO.
Yaron: the CNMAE part i soptional, simplifies synchronization of provisioning.
Richard: What CNAME is provisioned as a result of this?
Yaron Sheffer: CNAME points from DNO to NDC.
Richard: I'll take a look at the draft and provide feedback
Yaron: This could be used for long-term certs.
Richard: This could be used for short term use case, but I don't see a
reason to join this with long-term.
Chris: If someone finds a solution where they are using them for long term,
more power to them, we should encourage them.
Yoav: What if we don't find such a use case? Right now we don't have any use
cases
Daniel Kahn Gilmore: If you are going to restrict delegation to STAR, how are
you going to restrict
it? What cut line would you use? Expiration or other?
Yaron Sheffer: The document could restrict with a MUST.
Tim Hollebeek: That (making delegation depend on lifetime) makes things more
complicated, as this confuses delegation
is for short term, but not for long term. It's more useful in short term, but
generally useful, should not restict.
Yoav: will want to take to the list.
Chair: Are you requesting this be adopted?
Yaron: That's on the next slide
Rich: put it (restriction to STAR) in the draft as an open issue.
Richard: If a CNAME has been delegated, the NDC "owns" it can do the
HTTP challenge (maybe not the DNS challenge) just by having the record pointed
at it.
Jon Peterson: How does base ACME work when resolving the challenge?
Richard: There are some CDNs today that do this today, for ACME issuance.
Richard: It appears the CNAME here is confusing, but the rest of the document
is sound. There is a scoping question if the CNAME connection is suitable.
Jon: If you only have an account with the NDC, but not the IdO then yeah, you
wouldn't be able to prove ownership.
Richard: ACME accounts are cheap. Except where CA is imposing
conditions. You may, e.g. lock a domain to an account but I'm unsure if that's
being done in practice.
Chris Wendt: Are you locking this to DNS type or open to other identifier
types? Might want other identifiers in STIR.
Yaron: Once this is a WG document, this is a WG decision, but I don't see a
reason to lock it to DNS.
Sanjay Mishra: The CNAME used here, the NDC is asking IdO to use it?
Yaron: Yes.
Hum on whether this area is of interest to the group - yes.
AI: Chairs to issue call for adoption in 1-2 weeks, to give people time to read.
## Email TLS certs and EMAIL end-user certs, 15 minutes
Who will read? Ready for WGLC?
Paul Hofman: I don't understand the proposed change
Alexey: At the moment service/port are single. If you wanted to issue multiple
ports (IMAP/IMAPS) it needs to be multiple requests.
Paul: I see no reason not to have multiple services.
Chaair: One array or two?
Alexey: One array
Richard: I'm confused. This document is talking about authenticating
DNS, but what would go into a certificate is a Domain.
Alexey: In theory you could issue SRV based IDs. In the most common use cases
that won't be used.
Richard: I think this should be updated to cover SRV.
DKG: I want to agree with Richard. If it's just on name, this is too complex.
Several steps need including
Alexey: For DNS there will be slightly specific service name.
DKG: If the cert being requested isn't specifically for the service, this
could open an attack to other services for other protocols
AI: Alexey to add some clarifying text, Richard to send some
AI: After next draft, WGLC; READ
Paul Hoffman: These details aren't clear in the current draft.
Richard: We have a copy of layers of indirection, what I am least clear on is
the mapping of service to certificate. CA's may want to include SRV into the
cert if you show control of the domain.
Alexey: I'm hoping they'll issue certs with the port
Richard: I suggest you implement SRV service IDs
Tim: SRV has been discussed but not implemented
Tim: The assumption all zones in a domain are controlled by the same identity
is no longer true.
Alexey: I am developing software that could develop software to validate these,
but first I need CAs to issue certs against this.
Yaron: Are you expecting end user to perform this challenge?
Alexey: Yes, possibly through copy/pasting the challenge.
Chair: Is there any provisiion for multiple clients?
AI: Tim H and dkg said they would review
## TN Authority Token documents, 20 minutes
Updates
AI: Another rev then WGLC
ADJOURN
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
