Subject: [pkix] status update

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Aug 2011 15:55:40 -0400

Folks,

On 7/25 I requested a show of interest for adopting two new WG items:
	- Enrollment over Secure Transport (EST) (which I misspelled as ETS)

	- extending CMC to accommodate scenarios in which a CA/AR 
generates the key pair for the subject

The PKIX list had several messages in favor of EST, and no 
significant objections, so I declare EST to be a new WG item.

I am still waiting for comments on the CMC topic.

Steve

---

From: <[email-masked]>
Date: Wed, 10 Aug 2011 17:42:04 -0400

I'm in favor of pursuing CMC extensions for accommodating authority-
generated key pairs.  I've already worked customer scenarios where such
extensions would have been useful.

		-Peter Yee

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Stephen Kent
>Sent: Wednesday, August 10, 2011 12:56 PM
>To: [email-masked]
>Subject: [pkix] status update
>
>Folks,
>
>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 11 Aug 2011 09:02:53 +0200

"EST is a certificate enrollment protocol that operates
    over HTTPS, and thus should be trivially accessible by
    modern clients"

This is essentially the rationale in the current I-D (02).

"Modern clients" presumably (?) does not include the
most popular client of all, the Internet browser.

It seems that the most appropriate description of EST is
"A SCEP upgrade and RFC effort".  That's fine with me.
If the implicit ambition is something else, I would be
somewhat cautious.

Anders

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Aug 2011 12:45:44 -0400

>If the implicit ambition is something else, I would be

Max has characterized EST as a simple cert enrollment protocol,
a successor to SCEP, suitable for use with simple clients.
I'm comfortable with that. The fact that EST is not tailored to
browsers is not an issue.

Steve

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Aug 2011 02:43:24 +0200 (MEST)

>   generates the key pair for the subject

There seem to be various scenarios in productive use where the
the keypair is created centrally and the entire credentials
distributed.

Company-internal, we originally used PKCS#12 and now use Active Directory.

In electronic data exchange in Germany, there is a standard for
taxes (Elster) and for social security data, and the credentials
are also centrally created by the CA and distributed as PKCS#12
(one PKCS#12 with two keypairs, one for signing the other for encryption).

Something similar is done in other countries as well (I usually only
learn about such scenarios when the existing functionality is
insufficient to implement the customer or legal requirement and
I have to add new features at the lower-level abstract APIs
for pkcs7/cms and WSSec.)

Who is acutally doing this with CMS (or wants to do this with CMS)?

-Martin

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 12 Aug 2011 07:08:15 +0200

> browsers is not an issue.

Max, are you OK with mobile phones "iPads", and similar devices
[soon] having embedded hardware keystores, being out of scope?

HTML5's browser enrollment solution:
http://www.w3.org/TR/html-markup/keygen.html

Anders

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Aug 2011 12:07:38 -0400

>...

I presume you are directing this question to the authors of the I-D.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Aug 2011 12:10:47 -0400

>[soon] having embedded hardware keystores, being out of scope?

I'd rather you not take what someone else (e.g., me) says, and apply 
your interpretation to it, in the fashion illustrated above.

Steve

---

From: Max Pritikin <[email-masked]>
Date: Fri, 12 Aug 2011 11:04:23 -0600

>> "A SCEP upgrade and RFC effort".  That's fine with me.

Importantly it is focussed on alignment/profile of CMC. 
I am very aware of http://xkcd.com/927/ and would like to avoid such proliferation. 

> [soon] having embedded hardware keystores, being out of scope?

There is nothing within EST or CMC or SCEP or otherwise that would _preclude_ a browser or a mobile device. The protocol components should be easy to implement using the codebases available to such clients. I have already implemented both SCEP and EST against a hardware keystore so I don't perceive those as being 'out of scope' either. As a simplification/profile of CMC it does not make sense to limit the focus specifically to only those clients.

- max

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 12 Aug 2011 19:19:15 +0200

On 2011-08-12 19:04, Max Pritikin wrote:
<snip>

> There is nothing within EST or CMC or SCEP or otherwise that 
> would _preclude_ a browser or a mobile device.

That's what the KEYPROV guys said as well.  However, they forgot
a tiny detail: how to bind their protocol to a browser.

<snip>

Anders

---

From: Wan-Teh Chang <[email-masked]>
Date: Fri, 12 Aug 2011 11:11:51 -0700

> a tiny detail: how to bind their protocol to a browser.

I am interested in implementing a certificate enrollment protocol in
Firefox and Google Chrome to replace <keygen>.  I am studying
KeyGen2 and EST.  I have a question about Anders' comment
above.

By "binding a certificate enrollment protocol to a browser", do you
mean specifying an HTML element or JavaScript function for a
server to kick off the key generation and certificate request
generation in the browser?

For importing a newly issued certificate into a browser, draft-pritikin-est-02
specifies the MIME-type "application/x-est-x509" for the HTTP
response carrying the new certificate, which is the moral equivalent
of "application/x-x509-user-cert" used for <keygen>.  So it's not
clear to me if any other "browser binding" is necessary for this
operation.  Perhaps a JavaScript function similar to Mozilla's
crypto.importUserCertificates function?
https://developer.mozilla.org/en/JavaScript_crypto/importUserCertificates

The handling of an HTTP 202 response in Section 5.2.2 of
draft-pritikin-est-02 does seem to be intended for an automated
client (such as one running on an unattended network
appliance) rather than a web browser.

Wan-Teh Chang

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 13 Aug 2011 07:31:39 +0200

On 2011-08-12 20:11, Wan-Teh Chang wrote:
> Firefox and Google Chrome to replace <keygen>. 

That's absolutely fantastic!

If somebody manages creating and implementing an enrollment solution
that is useful for everything from small enterprises to social media
and on-line banking it would be no less than a REVOLUTION!

> I am studying KeyGen2 and EST.

That should be quite challenging since they address this space from
entirely different "value propositions".  PKIX's enrollment standards
(all pf them) deal with certificate provisioning which is only a subset
of token provisioning.

The latter among many things includes PIN-code provisioning based on
the *issuer's policy*.

To make this realistic on a major scale KeyGen2 actually depends on
a *specific token architecture and API* since current middleware like
PKCS #11 does not address on-line token provisioning.

Microsoft is trying to do similar things with their "MiniDriver".
IMO, that's a very difficult approach.  A short peek in
http://www.opensc-project.org/pipermail/opensc-devel verifies my
claim that *abstracting token APIs is a never-ending story*.
It is much easier pushing a fixed API on the token vendors,
at least if you're Google :-)

One middleware driver/platform and a single JUnit test suite is
the real boon of this (admittedly a bit unusual) idea.

I doubt that http://www.nist.gov/nstic will ever get their baby of the
ground unless token provisioning becomes as simple as password ditto.

>I have a question about Anders' comment above.
> 

Exactly.  In KeyGen2 the kick off is the start of a 6-10 pass
protocol running inside of the browser.

> https://developer.mozilla.org/en/JavaScript_crypto/importUserCertificates

For <keygen> this function is (almost) redundant.  In KeyGen2 the final
phase holds certificates (and then some...) but it is also the end
of an *end-to-end-secured transaction* that if successful returns a
signed receipt to the issuer.

> appliance) rather than a web browser.

Indeed.  A browser scheme would return a page saying something to the
user in case of a server/issuer error.

Anders

---

From: Max Pritikin <[email-masked]>
Date: Mon, 15 Aug 2011 17:23:11 -0600

> https://developer.mozilla.org/en/JavaScript_crypto/importUserCertificates

This matches my thinking and I'm very appreciative of the feedback from a browser oriented perspective. 

> appliance) rather than a web browser.

You are correct that I was thinking of unattended network appliances during that discussion. I am very open to suggestions concerning how to handle this case (and what sort of "human readable content" should be returned). 

- max

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 15 Aug 2011 18:52:16 -0700

Please clarify - do you mean CMS or CMC

> Martin Rex
> Sent: Thursday, August 11, 2011 5:43 PM
> To: Stephen Kent
> Cc: [email-masked]
> Subject: Re: [pkix] status update
> 
> Stephen Kent wrote:
> >
> There seem to be various scenarios in productive use where the the keypair
> is created centrally and the entire credentials distributed.
> 
> In electronic data exchange in Germany, there is a standard for taxes
(Elster)
> and for social security data, and the credentials are also centrally
created by
> the CA and distributed as PKCS#12 (one PKCS#12 with two keypairs, one for
> signing the other for encryption).
> 
> Something similar is done in other countries as well (I usually only learn
about
> such scenarios when the existing functionality is insufficient to
implement
> the customer or legal requirement and I have to add new features at the
> lower-level abstract APIs for pkcs7/cms and WSSec.)
> 
>

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 16 Aug 2011 06:26:51 +0200

IMHO the browser use-case is so large in terms of potential users,
and has to date been much less successful than for example SCEP
for network devices, that it deserves a dedicated solution.

The browser use case has quite a bunch of unique characteristics like:
- User authentication on the web level rather than in the protocol
- It is rather the server that requests keys to be generated
- The user is effectively a part of the protocol
- Last but not the least: a variant set of key containers

It is possible that by creating a scheme with a gazillion options
you could address the entire enrollment universe.  My belief is that
CMP will appear completely trivial when you're done :-)

It has in this context been mentioned that upgrading CAs end is very
difficult: It is actually extremely simple compared to upgrading
billions of client platforms using dozens of operating systems.

http://ejbca.org is a example of a CA that has "plugins" for a huge
number of standard as well as proprietary enrollment and management
protocols.  The perceived XML vs ASN.1 issue doesn't exist in *any*
CA product worth mentioning.

Anders

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Aug 2011 11:47:16 -0400

>for network devices, that it deserves a dedicated solution.

Max didn't sign up to do that.

If Max wants to make some accommodations for browsers, and he
can still retain the simplicity that motivates EST, then that's
fine.

Steve

---

From: Martin Rex <[email-masked]>
Date: Tue, 16 Aug 2011 19:11:10 +0200 (MEST)

> > >   generates the key pair for the subject

"to accomodate scenarios in which CA/AR generates the key pair for the
 subject" sounds like a usage scenario which is currently covered
by PKCS#12.

Scenarios I know have been either using PKCS#12 exclusively
or been offering PKCS#12 as an option.
And often, they're also used to bootstrap trust along the way.

-Martin

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 16 Aug 2011 19:26:44 +0200

> can still retain the simplicity that motivates EST, then that's

Yes, if Max also can retain that simplicity when the browser's
target key-container is a smart card, he has outsmarted the entire
computer security industry.

Anders