ACME at IETF 105

Thanks to Robin Wilton for the minutes.

==>Action items/requests are indicated with this prefix

Telephony update (Jon Peterson): 

Telephony drafts revised (during IETF week last year); some dependencies on
STIR WG (e.g. on JWT constraints).
RFC 8226 refers.

==>Chair requested an update from Jon after the STIR meeting.


STAR Delegation (Diego Lopez):

Use case recap: 
Name Delegation Client (NDC) might be e.g. a Content Delivery Network may be
the desired termination point of an https connection. Goal is to allow an IdO
(Identity owner) to delegate use of a name, without having to share the
corresponding private key.

==>Jon Peterson: Requests discussion with STIR about use cases, on how to
   interoperate between STIR identifier delegation and STAR cert delegation.

E Rescorla: Would like to hear from a potential implementer... as a
precondition to this work continuing.

==>D Lopez: Will ask for a statement from CDNI.


ACME Integrations (Owen Friel)

Use of sub-domains is proposed, to facilitate large-scale issue of
client-device certificates. This seems to offer functionality of benefit to
EST and TEAP, without requiring changes to their respective specifications.

==> If interested, pleaes come to side meeting, Weds 9am, Coller Rm

==>K Moriarty: Please document the functions described, because if they exist
but aren't documented, potential adopters may assume they don't exist.

D Lopez: +1 to this work

R Sleevi: this use of sub-domains is in line with the existing pattern of CA
issuance of public certs. Mild caveat: increased automation in this subject
domain *might*, over a number of years, mean this feature is superseded/
profiled out.


Extensions to ACME for S/MIME (Alexey Melnikov)

Use-case recap: to make it possible for ACME to issue certs for email clients.

==>Some open questions on which feedback is welcomed via the mailing list -
e.g. how to process mail client prefixes in the Subject: line of emails (esp.
bearing in mind they are often language-specific, such as Re: vs AW: etc.)

R Daniliw: any prospective implementers? 

Yes, Digicert

D Kahn Gilmor: Note that "implementers" covers a variety of roles - e.g.
implementers of client functionality vs implementers of CA functionality. If
there's a CA planning to implement, that would be of interest.


ACME Client draft (Kathleen Moriarty)

Codesigning Certificates - 
Existing EV certificate issue requirements (such as existence of an account;
CA validation; Authorization from 1 of 2 administrators, etc.) would need to
be supplemented for code-signing certificates.

Based on feedback in the room/Jabber, there are at least 4 expressions of
interest in this work.

D Cooley (NSA): will check to see if there's interest in e.g. a PIV-compliant
implementation.


ACME Overview proposal (K Moriarty)

Awareness of ACME often seems limited to LetsEncrypt and RFC8555. 

This proposal is for a document aimed at providing an informational overview
of ACME, interfaces to other cert mgmt protocols (EST/BRSKI, KMIP, etc etc).

E Rescorla: an RFC is an odd way to do this, as opposed to e.g. a FAQ

R Barnes: draft contains useful stuff, but not convinced this needs IETF
consensus or the archival/permanence it would get from being an RFC.

KM: people do need to be able to find the information for it to be useful,
though

Yoav Nir (hatless): A few years ago an "IPSEC roadmap" was created, and isn't
really used; this work might be similarly underused.

R Daniliw: Aside re: "do we know if anyone's using the IPSEC roadmap?" If we
had web analytics on the IETF site, we'd know.  Is there an applicability
statement in this draft?
KM: it's answers to FAQs

Liang Xia: Useful to me as a newcomer to this group; not wedded to publishing
it as an RFC specifically. Does the doc talk about cert issue for network
devices?
KM: Evolution is really on the basis of questions asked.

D Cooley: Could it be documented in the form of "use" cases?
KM: not a popular approach

Alexey M: suggests adoption as a WG work item, and think later about what to
do with the resulting artefact.

==>Chairs: path is open to do that as a WG draft or an Individual Draft, either to be discussed in ACME.


Way forward (Chairs)

Is ACME really needed, when the implementers aren't usually in the room, and
the drafts are poorly reviewed.

R Barnes: WG could be put on the path to closure.

EKR: "Always Be Closing"

K Moriarty: value in getting the client pieces finalised, given that ACME's
work extends beyond just web certs.

R Daniliw: are there any drafts out there that should be in ACME but aren't?

Sean Turner: It took 18 years to shut PKIX down. As long as there's a WG open
doing stuff on PKI, people will keep showing up.

Alexey: whatever you do, don't shut down the mailing list.