Minutes IETF99: acme
Automated Certificate Management Environment
||Minutes IETF99: acme
The draft passed a second WGLC and has gone for IESG review. There are
some minor editorial issues. No further work is expected.
There was no presenter or slides. The CAA draft says what authentication
mechanisms are available. It could also be used for non-acme mechanisms (eg
browser CAs). That would mean maintaining a registry of tokens for
authentication mechanisms and co-operation with the CA/B Forum. It is looking
at improving its authentication stuff and would probably be receptive. CA/B
Forum seems to lack focus though: might need them to commit to a deadline. The
CA/B Forum has concerns that new baseline requirements will be backwards
There was a unanimous hum for a solution that does acme and non-acme auth
The draft discusses auto-renewal mechanisms. It's not clear what
should be done when the certificate life and the Expire: header disagree.
Perhaps an absolute date could be used for killing the certificate even if an
acme client is renewing/refreshing lookups. Certificate revocation issues are
not yet fully worked out. It was suggested acme certificates could use three
values: is available from/is available until/drop dead date for automated
A new version of the draft should be done for IETF100 and would probably
go for WGLC.
This related draft was not discussed. It will probably get adopted as a WG
document at a future meeting.
Jon Peterson's slides are here:
Endpoints could have authentication tokens, though it's more likely to
be the intermediary (SIP proxy, SBC, etc) that holds these. Jon was/is trying
to be neutral on how these tokens would be stored and accessed. Current
thinking in the telco world is these would be in a database owned, operated
and controlled by the telco responsible for the number (block). An ENUM like
solution would be an obvious approach since both E.164 numbering and domain
names use hierarchical name spaces. However telcos seem to be hostile to a
Mary Barnes's slides are here:
The draft's been updated to account for the service provider code
token used by SHAKEN (signature-based handling of asserted information using
token), the specification adopted by two US telco bodies, ATIS and the SIP
Forum. Richard Barnes suggested this could become a generic identification
mechanism, not just for phone number sand SIP addresses.
6. draft-ietf-acme-email-smime and draft-ietf-acme-email-tls
Alexey Melnikov's slides:
Alexey said there's a demand for authenticating IMAP(S) servers. The
WG didn't have a clear consensus for any of the three options he proposed.
There was some objection to using a Service Name Indication in TLS. He agreed
to drop that and continue with the options of using DNS SRV records (or
similar) to specify the protocol and port number or adding extensions to SMTP
The WG noted Alexey's optimism for S/MIME. He claimed it is more
widely deployed than most people realise. Some Outlook users are forced to use
7. Recharter discussion
This was over in a few seconds. AD Kathleen Moriarty said the WG should
just update its milestones and charter and then inform the IESG. The WG did
not seem to want or need a long debate over what the revised milestones and
charter should be. The WG co-chairs will probably be responsible for updating
these and getting WG consensus.
Someone asked if CAs would issue ACME-based certificates for acme. Richard
Barnes said Digicert was still trying to work out what to do. They were
interested in principle.
Yoav Nir has replaced Ted Hardie as co-chair now that Ted has been
appointed to the IAB.