Thanks to Cullen for taking detailed notes. Please followup with corrections.
/r$
-----Original Message-----
From: Cullen Jennings [mailto:[email protected]]
Sent: Wednesday, March 25, 2015 4:26 PM
To: Cullen Jennings; Salz, Rich
Subject: Notes from ACME BOF at IETF92
ACME BOF
March 25, 2015
Motivating Requirement - Eric Rescorla
--------------------------------------------------
Too many things to not use TLS that should.
Cullen Jennings can barely figure out how to get a cert. That's a bummer.
Let's Encrypt is going to offer automatic easy DV certificates (for free).
Need to have single time register, automatic verification of domain, automatic
re-issue
Current certs have long life with OSCP for revocation
Lots of talk about short lived automatic renewal certs
Automatic upgrade to new curves.
This makes DANE even more Wonderfull in ways the note taker did not understand.
Q: Why EST not the soln
A. Part of soln but does not do the validation part
Q. Can we use this for an internal CA
A. Not the main use case but a use case they want to support
Q. What about cert transparency
A. Yes, separate issue, any protocol would allow that
Q. What about non HTTP things (IMAP, POP)? And lights out boxes ?
A. On Lets Encrypt, web is first target A. On ACME, be very sad if it did not
work for non web services
Q. Not orthogonal to cert transparency. OSCP lets you have longer certs with
fewer certs in the log.
A. yes and there may be some ideas to mitigate this
Possible Requirements Phil Hallam-Baker
------------------------------------------------------
They have standard based cert enrollment. And they have easy enrollment. But
they are not the same.
Plugin's just don't deliver. Putting a plug in in your server takes even longer
and putting in multiple is a real nightmare you can't test.
Thus we have a need for a standards based mech.
So from point of view of major CA, want a frictionless experience. Just as easy
to do a secure and non secure.
Want short lived certs.
No new ASN.1 would be good.
Want JSON because that makes is easy to solve the upcoming requirements.
Need to interoperate with existing back ends and work with hardware that use
existing CSR.
Want a choice of CA and way to charge customer and way to support all products
(not just web with DV certs). Want to do TLS and S/MINE, EV, private label ....
Can't assume issue of cert if immediate
DNS CAA record might be a way to point at CA discovery.
Some DV schemes are covered by IPR
Review draft-barnes-acme - Richard Barnes
---------------------------------------------------------
apt-get install acme
Demonstrated the many things one gets asked for a free cert
Registrations cover who am I - credentials to use acme
Authorization - prove that you own the domain
- few different way to verify one owns the domain
- can work with types that are not domains
Cert - give a CSR and get a cert
Separation helps with certificate transparency in not publishing users private
info.
Extensible set of challenge messages to prove control of domain. Looking at
HTTPS, SNI in HTTPS, and DNS. Open to others.
Q. Assume I get owned for 1/2 hour but now he has cert for several years A.
Same problem any CA has
Q. Can we require weird content in .well-known A. lots of things to do
Q. like to have CA Forum limit emails address used A. yes - no email validation
right now
Q. is there a way for CA to specify what type of key to make A. few ideas how
to do this, not in draft today, but seems good to add ways to specify policy,
key types, lengths, extensions etc.
See
draft-barnes-acme-01
Discussion
---------------
- Love it - needed in industry
Q. Why is account key the auth mech for getting cert. Issue cloud deployment
might need the key on all the boxes in cloud.
A. idea was not to do that but have an intermedia
PHB - propose have two protocol direct, and LRA
Justin Richard - Q will get behind anything that makes me not have to write a
CSR. Would like to deal with apps with just a bare key.
Jan - How do people feel about wildcard certs
Max - this duplicates the work done in some old WG. Key problem was discovering
services. We should focus on discovering services and how to find CA.
Elliot Lear - This is very important problem. I think this is very nicely
constrained soln. Keep going. Have CA show interest.
? - There are properties of current CA business model that we do not want to
preserver. Qualities of intermediaries that don't like. If we do this we might
not get DANE. DANE gets rid of the CA business model.
Chair - 52 minutes into a BOF, we are already concerned about success
Richard Barnes - on topic of delegated and direct, it is worth looking at if
ACME can be used back back on both legs. On the topic of wildcards - this is a
top questions and would need WG to consider how to validate them. On DANE, I
think this is a supportive tech for DANE. It can be a use case for DNSSec and
use them to prove control of domain. This can provide a bridge to DANE by lower
cost of certs so removes cost of supporting legacy browsers if you also support
DANE
Mark Nottingham - Has some issues on how to use HTTP but will help fix that and
loves the. Mark is worried that EKR is behind him. Not nought time to discuss
DANE.
? - Like to add another use case of adding SIP certs for PBX.
Eric Rescorla - This is about allowing browser to talk to browser as much as
possible. On the topic of DANE, the problem with DANE is standard collective
action problem. Nothing accepts it, so no incentive to offer and visa versa.
ACME gives you a valuable reason to do DANE and at the same time allow things
that don't support DNAE yet to use security.
TED as chair asks some questions
How many people in room have read draft or intent too: pretty much everyone
How many people are on mail list or intent to join: most
How many people believe it is totally done and needs no work: close to zero
How feels work for IETF: pretty much total consensus
Now to AD to ask questions
Should we just get this going on list and write a charter in month or two and
form WG?
- some suggested AD sponsor. Author and AD disagreed.
Total consensus to just form a WG on the list in a few months.
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
