Subject: [Acme] Fwd: New Version Notification for draft-mattsson-acme-use-cases-00.txt

From: John Mattsson <[email-masked]>
Date: Mon, 9 Mar 2015 20:37:21 +0000

Hi all,

I strongly support the ACME work. Certificate management is something that really benefits from standardization and automatization.

We have some additional use cases that we think should be included and that clearly falls into the ACME use case "obtaining certificates for Web sites".

I wrote a short draft that illustrates the scenarios. Please comment. Would be happy to give a short (5min?) presentation at the BoF.

Cheers,

John

Begin forwarded message:

From: <[email-masked]<mailto:[email-masked]>>
To: John Mattsson <[email-masked]<mailto:[email-masked]>>, John Mattsson <[email-masked]<mailto:[email-masked]>>, Robert Skog <[email-masked]<mailto:[email-masked]>>, "Robert Skog" <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-mattsson-acme-use-cases-00.txt
Date: 9 Mar 2015 20:57:54 CET

A new version of I-D, draft-mattsson-acme-use-cases-00.txt
has been successfully submitted by John Mattsson and posted to the
IETF repository.

Name: draft-mattsson-acme-use-cases
Revision: 00
Title: Additional Use Cases for Automatic Certificate Management (ACME)
Document date: 2015-03-09
Group: Individual Submission
Pages: 6
URL:            http://www.ietf.org/internet-drafts/draft-mattsson-acme-use-cases-00.txt
Status:         https://datatracker.ietf.org/doc/draft-mattsson-acme-use-cases/
Htmlized:       http://tools.ietf.org/html/draft-mattsson-acme-use-cases-00

Abstract:
  Contacting a CA is just one way in which a newly deployed HTTPS
  server can get hold of the certificate to use.  This document
  describes additional (and common) use cases that fall into the major
  guiding use case for ACME as stated by [I-D.barnes-acme], "obtaining
  certificates for Web sites".

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: Rob Stradling <[email-masked]>
Date: Mon, 09 Mar 2015 21:37:44 +0000

John, how would a "newly deployed HTTPS server replacing or 
complementing an existing HTTPS server" obtain a copy of the private key 
that is associated with the "existing certificate" that it desires to 
"import" ?

IINM, whilst the current ACME draft handles proving possession of a 
private key, there's no mechanism for backing up a private key to an 
ACME server and/or for transferring a private key from one ACME client 
to another ACME client.
Do you think ACME should provide these facilities?
If not, is there any real gain to adding your proposed "Certificate 
Download" function, given that there would presumably be just as many 
"people flying back and forth just to manually transfer" private keys?

Thanks.

On 09/03/15 20:37, John Mattsson wrote:
> Hi all,
>
> I strongly support the ACME work. Certificate management is something
> that really benefits from standardization and automatization.
>
> We have some additional use cases that we think should be included
> and that clearly falls into the ACME use case "obtaining certificates
> for Web sites".
>
> I wrote a short draft that illustrates the scenarios. Please
> comment. Would be happy to give a short (5min?) presentation at the BoF.
>
> Cheers,
>
> John
>
>> Begin forwarded message:
>>
>> *From: *<[email-masked] <mailto:[email-masked]>>
>> *To: *John Mattsson <[email-masked]
>> <mailto:[email-masked]>>, John Mattsson
>> <[email-masked] <mailto:[email-masked]>>,
>> Robert Skog <[email-masked]
>> <mailto:[email-masked]>>, "Robert Skog"
>> <[email-masked] <mailto:[email-masked]>>
>> *Subject: **New Version Notification for
>> draft-mattsson-acme-use-cases-00.txt*
>> *Date: *9 Mar 2015 20:57:54 CET
>>
>>
>> Name:draft-mattsson-acme-use-cases
>> Revision:00
>> Title:Additional Use Cases for Automatic Certificate Management (ACME)
>> Document date:2015-03-09
>> Group:Individual Submission
>> Pages:6
>> URL:
>> http://www.ietf.org/internet-drafts/draft-mattsson-acme-use-cases-00.txt
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Bernd Eckenfels <[email-masked]>
Date: Tue, 10 Mar 2015 01:04:15 +0100

Hello,

I don't think it is a good idea to add any functionality which tries to
move/copy the private key (and with some hardware protection it should
also not possible). And it is not really needed. Just request a new one.

The ACME credentials might be transported, but I am not sure you want
to do that via untrusted (ACME) servers...

Gruss
Bernd

 Am Mon, 09 Mar 2015 21:37:44 +0000 schrieb Rob Stradling
<[email-masked]>:

> complementing an existing HTTPS server" obtain a copy of the private
> key that is associated with the "existing certificate" that it
> desires to "import" ?
> 
> ACME server and/or for transferring a private key from one ACME
> client to another ACME client.
> > I strongly support the ACME work. Certificate management is
> > something that really benefits from standardization and
> > automatization.
> >
> > and that clearly falls into the ACME use case "obtaining
> >> *From: *<[email-masked]
> >> <mailto:[email-masked]>> *To: *John Mattsson
> >> John Mattsson <[email-masked]
> >> <mailto:[email-masked]>>, Robert Skog
> >> <[email-masked] <mailto:[email-masked]>>,
> >> "Robert Skog" <[email-masked]
> >> <mailto:[email-masked]>> *Subject: **New Version
> >> Notification for draft-mattsson-acme-use-cases-00.txt*
> >> Title:Additional Use Cases for Automatic Certificate Management
> >> (ACME) Document date:2015-03-09
> >> Status:
> >> https://datatracker.ietf.org/doc/draft-mattsson-acme-use-cases/
> >> Htmlized:
> >> http://tools.ietf.org/html/draft-mattsson-acme-use-cases-00
> >>
> >>
> >> Abstract:
> >>   describes additional (and common) use cases that fall into the
> >> major guiding use case for ACME as stated by [I-D.barnes-acme],
> >> "obtaining certificates for Web sites".
> >>
> >>
> >>
> >>

---

From: Rob Stradling <[email-masked]>
Date: Tue, 10 Mar 2015 10:50:22 +0000

> to do that via untrusted (ACME) servers...

Hi Bernd.  I agree, but I'd be interested to hear John's point of view.

IIUC, John's motivation is (emphasis mine)...
   "A newly deployed HTTPS server replacing or complementing an existing
    HTTPS server should import an existing certificate *instead of buying
    a new*"

I'd like to think that there could be better ways (than moving/copying 
private keys) to avoid having to buy a new cert for each server.  e.g. 
Perhaps some CAs might be willing to charge you for your first cert for 
x.y.com, but then let you have additional certs for the same domain name 
for free (as long as you authenticate with the same ACME credentials 
each time).

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Mar 2015 08:04:08 -0400

> to do that via untrusted (ACME) servers...

Copying a private key is not a use case, it is (or isn't) a requirement.

A use case is 'Fred wants to start a new server and avoid re-validation'

There are use cases in which it makes sense for private key material to
come from a third party. In particular you don't want to be generating RSA
key pairs on a machine in the cloud that is shared with another party.

A similar problem comes up with stored encryption keys. Alice wants to be
able to read her email on her iPhone and her Surface tablet. So she needs
both to have the same decryption key.

Whether these use cases are in or out of scope is another matter. But
usually you want to discuss the use case and decide according to how much
implementation complexity the solution adds.

OBDisclaimer: Comodo has pending IPR claims that cover new approaches to
solving some of these use cases. At this point all rights are reserved.

---

From: John Mattsson <[email-masked]>
Date: Wed, 25 Mar 2015 15:05:23 +0000

Hi,

> On 09 Mar 2015, at 11:37, Rob Stradling <[email-masked]> wrote:
> 
> John, how would a "newly deployed HTTPS server replacing or complementing an existing HTTPS server" obtain a copy of the private key that is associated with the "existing certificate" that it desires to "import" ?

My meaning was not that the CA stores the private key, the ACME Server in the CertDownload case would be operated by the domain owner as illustrated in Figure 2.

> On 09 Mar 2015, at 14:04, Bernd Eckenfels <[email-masked]> wrote:
> 

I don’t think the suggestion that newly deployed HTTPS servers should always request new certificates from the CA is very practical or realistic. In fact, I would not even want my newly spawned cloud based HTTPS server to have the credentials to request new certificates from the ACME CA. Being able to request new certificates is a much higher level of trust than having possession of a single certificate (+ private key).

Importing certificates is how certificate management works in practice. In the best case, certificates are imported from a central certificate storage. See for example Microsoft ISS or Akamai’s SSL content delivery network:

https://technet.microsoft.com/en-us/magazine/jj937171.aspx
http://www.csoandy.com/files/whitherHSMs.html

In the worst case, certificates and private keys are imported in a number of ad hoc ways, USB sticks, e-mail, uploaded to internal web servers, etc…

> On 10 Mar 2015, at 02:04, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> Whether these use cases are in or out of scope is another matter. But usually you want to discuss the use case and decide according to how much implementation complexity the solution adds.

The current name and draft suggest the broad scope of certificate management for HTTPS servers. I think this is the right scope and I think this scope must include certificate import. If certificate import is not in scope, then the work is not the currently stated certificate management for HTTPS servers, then is just Interface to Certificate Authority (I2CA)...

Cheers,
John