Subject: [pkix] I-D Action: draft-ietf-pkix-est-00.txt

From: [email-masked]
Date: Sun, 08 Jan 2012 07:06:22 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title           : Enrollment over Secure Transport
	Author(s)       : Max Pritikin
                          Peter E. Yee
	Filename        : draft-ietf-pkix-est-00.txt
	Pages           : 25
	Date            : 2012-01-06

   This document profiles certificate enrollment for clients using
   Certificate Management over CMS (CMC) messages over a secure
   transport.  This profile, called Enrollment over Secure Transport
   (EST), describes a simple yet functional certificate management
   protocol targeting simple Public Key Infrastructure clients that need
   to acquire client certificate(s) and associated Certification
   Authority (CA) certificate(s).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-est-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-est-00.txt

---

From: Max Pritikin <[email-masked]>
Date: Wed, 11 Jan 2012 11:09:26 -0700

Folks,

Many thanks to Peter Yee who is now a co-author!

The -00 release of the WG version has various clarifications from previously drafts but is substantially the same. For example we now re-use existing mime types in all cases, etc. Interested folks might want to examine the newly organized and clarified discussion concerning 'proof-of-possession' and 'linking identity and POP information' (sections 3.6 and 3.7).

We have already received feedback on this version and are actively responding and updating for the -01 release. Any additional questions or comments are of course appreciated and would be timely. (And my sincere apologies if we have yet to address an outstanding concern you have). 

I look forward to seeing you all at the next meeting.

Thanks,

- max

On Jan 8, 2012, at 8:06 AM, [email-masked] wrote:

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 16 Jan 2012 21:13:40 +0100

> targeting simple Public Key Infrastructure clients that need
> Authority (CA) certificate(s)

I just returned from a PKI install in a large bank where they (among
many things), intend to issue certificates to Androids and iPhones
using SCEP.   When they told me that they required PIN-protected keys,
I had to bring them the bad news that no existing or emerging PKIX
enrollment protocol actually support two-factor authentication tokens.

It takes shelving out tons of legacy junk to move things forward.
This is particularly easy if you have no legacy :-)

http://www.google.com/wallet

The details are somewhat sketchy (big understatement), but off-list I
have gotten the information that it is based on GlobalPlatform which
can be fully configured using end-to-end-security protocol mechanisms.

-- Anders

---

From: Max Pritikin <[email-masked]>
Date: Thu, 19 Jan 2012 10:24:49 -0700

Anders,

I'd like to address your concerns but their exact nature is not clearly represented in your note. Two-factor authentication using a password/PIN along with a certificate (which  may be stored in a token) is of course supported to meet EST Section 2, Requirement A5. 

I suspect you're concerned with how the server might determine that the certificate is physically contained within a specific cryptographic token. As we've discussed previously this is an important concept that is available, today, only by tokens that enforce implementation of the enrollment protocol internally. In a previous thread I suggested possible future extensions to the CSR that might serve to assert this status in a way that can be transported over the existing protocols -- but that I thought that work should likely proceed in a distinct draft. 

I see a couple of ways you can help to move your concern forward,

1. If you feel this is something we can address immediately then please provide a concrete textual suggestion for the EST draft. Using normative language please feel free to suggest a section, extension, message, paragraph etc for inclusion into the EST document that would address your concern. It is significantly easier to evaluate an idea when it has been laid out clearly and concisely in such a fashion.

2. Another option is to provide a personal submission draft. Similar to the above this provides a single document folks can read to help grok your idea. This is similar to my suggestion of a distinct draft above but since you'd be writing the first version you'd have editorial control and could better ensure it meets your concerns.

Although I appreciate the link to Goole wallet marketing videos, and the insight that they are using GlobalPlatform, there is a significant "impedance mismatch" between this high level "somewhat sketchy" description of a problem and the type of detail oriented discussion necessary for an RFC.

I look forward to reading your suggested text as either feedback for EST or a new document,

- max

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 20 Jan 2012 00:18:14 +0100

On 2012-01-19 18:24, Max Pritikin wrote:
> 
> Anders,
> 
> I'd like to address your concerns but their exact nature is not 
> clearly represented in your note. Two-factor authentication using
> a password/PIN along with a certificate (which  may be stored in a
> token) is of course supported to meet EST Section 2, Requirement A5.

This section does not mention anything about the actual usage of
enrolled certificates or maybe it is just a bit vague on this point?

The bank I mentioned where thinking about how bank cards are used
(at least outside of the USA...), i.e. with a PIN.  They felt that on-
line-enrolled credentials should follow this time-proven pattern as well.

Anyway, deploying a PIN to a key is quite different from authenticating
to a CA with PIN.  I may be dumb but I don't see how PIN deployment could
be squeezed into EST without more or less starting over from scratch.

BTW, the GlobalPlatform specification is public.

-- Anders

---

From: Max Pritikin <[email-masked]>
Date: Mon, 23 Jan 2012 10:14:30 -0700

Inlines,

> enrolled certificates or maybe it is just a bit vague on this point?

Why would an enrollment protocol document "mention anything about the actual usage of enrolled certificates"? I suppose there are some key usage discussion that would be appropriate but those are generally covered in the CSR and certificate extensions not the enrollment protocol itself (since their assertions need to persist after the enrollment protocol terminates). 

> to a CA with PIN.

"[D]eploying a PIN to a key" does sound vaguely like something that might occur during enrollment. Would it be fair to characterize this as a request/assertion from the CA that the client MUST encrypt/protect the private key using a PIN to ensure authorized access? Or is this actual deployment of the PIN where the CA has a hand in choosing an appropriate PIN value (according to some CA policy)? 

Or do you mean that during the "actual usage of the enrolled certificate" the use of a PIN is proven by some subsequent protocol enhancements (e.g. some extension to TLS or something).

>  I may be dumb but I don't see how PIN deployment could

One possible way to see if this idea could be squeezed into an existing document would be for you to suggest exact document text. Or, alternatively, to provide a new draft that specifically addresses your concern. That way you can provide the exact normative text that meets your concern and, in the process of writing it all down using normative language sufficient for implementors to understand, will also generate sufficiently detailed text that I might follow your thoughts as well.

> BTW, the GlobalPlatform specification is public.

There is still an "impedance mismatch" in that the GlobalPlatform specification 2.2.1 is 283 pages long and covers a whole lot of material which is not likely to be applicable to an enrollment protocol. If you wish you present the GlobalPlatform use of PINs as an example I suspect you can provide a more direct reference. If your concerns are addressed in this document, and  are so obviously stated that you expect a casual reader to be able to find them quickly, then it should be easy for you to quote the appropriate sections. 

I look forward to reading your upcoming(?) draft/text on "deploying a PIN to a key". 

Thanks,

- max

---

From: Russ Housley <[email-masked]>
Date: Mon, 23 Jan 2012 15:11:40 -0500

> Or do you mean that during the "actual usage of the enrolled certificate" the use of a PIN is proven by some subsequent protocol enhancements (e.g. some extension to TLS or something).

I think it is the other way round.  A PIN / password / passphrase is given  by the RA want a person completes face-to-face proofing, and this is used in a one-time fashion during the enrollment process as proof that that proofing has taken place with the party that is presenting the certificate request.

Russ

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 24 Jan 2012 18:59:36 +0100

Max et al,

Please read the following as "constructive criticism" because that is
what the intent was at least.

On 2012-01-23 18:14, Max Pritikin wrote:
<snip>
> "[D]eploying a PIN to a key" does sound vaguely like something that 
> might occur during enrollment.

Vague or not, several billions of chip-cards (EMV, PIV, SIM) have already
passed through PIN deployment/enrollment processes.  Now we are facing a
situation where cards are becoming "virtual" which calls for new enrollment
solutions that also work in the field.

> Would it be fair to characterize this 
> as a request/assertion from the CA that the client MUST encrypt/protect
> the private key using a PIN to ensure authorized access? Or is this
> actual deployment of the PIN where the CA has a hand in choosing an
> appropriate PIN value (according to some CA policy)?

My only reason for bringing this up was for improving the scoping:
EST is a fine protocol but it doesn't address the "bank use-case".

Since not even Microsoft have bothered with the "bank use-case" this
probably isn't particularly relevant for PKIX either, or is it?

That Google and I have come to another conclusion is because we indeed
(but in profoundly different ways...), target the financial sector.

> Or do you mean that during the "actual usage of the enrolled certificate" 
> the use of a PIN is proven by some subsequent protocol enhancements 
> (e.g. some extension to TLS or something).

EMV, PIV, SIM, and the Google wallet all rely on *local* PINs so I
would consider this as the primary scope for "PINs deployed to keys".

> One possible way to see if this idea could be squeezed into an 
> existing document would be for you to suggest exact document text.
> Or, alternatively, to provide a new draft that specifically addresses
> your concern.

As already mentioned, I have no idea of how you could add this to EST.

Although probably of no interest to PKIX, I consider SM (known as
Secure Messaging by the smart card community), as a more extensible
concept than wrapping CMS-based data in TLS, at least in a context
where you want to perform *multiple and intimately related operations*
possibly including user interactions, while still keeping the
"footprint" of the cryptographic module reasonable.

SM is also the common denominator between the Google wallet and
my SKS/KeyGen2 scheme.  Everything else differ :-) :-)

> That way you can provide the exact normative text that meets 
> your concern and, in the process of writing it all down using
> normative language sufficient for implementors to understand,
> will also generate sufficiently detailed text that I might
> follow your thoughts as well.

Well, as you know, I don't believe the PKIX approach to enrollment
represents the way ahead for an on-line world where credentials are
delivered directly to moderately tech- or security-savvy end-users.

This is [currently] rather Apple's and Google's hunting grounds
which also makes it extremely hard succeeding without having a
very good solution as well as a matching strategy for adoption.

If you take the number of groups (platform, browser, protocol,
middleware, smart cards, etc.), needed to create a functioning
system, you pretty soon realize that this simply isn't going to
happen the traditional (preferred?) way.

Due to this, I have spent considerable energy and time on developing
an on-line scheme that as far as is possible "emulates" off-line
enrolled and physically distributed smart cards.  In this work I
used GlobalPlatform as *one* source of "inspiration".

Unlike most other folks I had no ambition to be compatible with
existing standards because that would create an almost infinitely
complex interoperability matrix.  Going for the second-best,
"profiling" the 500p+ GP, ISO-7816, and ETSI standards also
didn't look like a realistic project, so I early on decided
defining the whole caboodle from scratch.  The latter shouldn't
be interpreted as "all new" but rather as selective "borrowing".

It is possible that I in that process have violated considerable
amounts of IPR but I only see this as a way getting more attention :-)

BTW, I wouldn't consider casting my "colorful" and (IMO) rather
nice SKS/KeyGen2 architecture and API document into an RFC-format.
None of our (mutual?) competitors do that either.

Regards,
Anders

http://webpki.org/papers/keygen2/sks-api-arch.pdf

---

From: Max Pritikin <[email-masked]>
Date: Fri, 27 Jan 2012 14:05:47 -0700

Inlines,

> As already mentioned, I have no idea of how you could add this to EST.

Perhaps you could respond to the exchange between Russ and myself and clarify what you mean by "deploy a PIN to a key". Are you asking for the PIN deployment to be part of the protocol operation or not?

> my SKS/KeyGen2 scheme.  Everything else differ :-) :-)

You should be well positioned to answer the questions then or to provide text explaining your thoughts. 

> None of our (mutual?) competitors do that either.

If you're not willing, or unable, to extract the core ideas from the colorful formatting then we're going to have a hard time communicating over email about RFC text.

- max

---

From: Max Pritikin <[email-masked]>
Date: Fri, 27 Jan 2012 14:05:49 -0700

Russ, 

I'm having some trouble parsing your sentence but I think you and I agree about this use: A PIN/password/passphrase is given by the RA to a person at the completion of some out-of-protocol "proofing", and this is used in a one-time fashion during the enrollment process as proof of prior proofing. 

I thought that Anders has a different vision based on his discussion of "deploying a PIN to a key" which is why I asked for clarification from him. In his response he didn't answer the question. I'll work from yours and mines shared understanding.

- max

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 28 Jan 2012 09:31:27 +0100

I don't think that people involved in the "bank use-case" have much difficulties
understanding what a "PIN deployed to a key" could possibly be.

In fact, this discussion clarifies why PKIX isn't the right forum for addressing
the needs of the mobile connected world where virtual smart cards will be the norm.

 http://channel9.msdn.com/Events/BUILD/BUILD2011/HW-462T

Anders

---

From: Stephen Wilson <[email-masked]>
Date: Sun, 29 Jan 2012 09:36:33 +1100

I for one don't know what "PIN deployed to a key" really means.
It sounds like it might be wordplay.  In general there are many ways of 
password protecting a resource and managing the password. In the world 
of SIMs and Chip-and-PIN cards, there are several common conventional 
ways of implementing PINs, like match-on-card, and different processes 
for setting initial PINs and subsequently changing them or resetting them.
Anders: What do your specifically mean?
We need no ambiguity in these technology discussions.
Cheers,
Steve Wilson.

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 29 Jan 2012 07:17:53 +0100

Stephen,
feel free coming up with a better term.

"Deploy a PIN to a key" is my short-form of describing what SKS/KeyGen2
does when it assigns a PIN policy object to a set of keys.  The initial
PIN value(s) may subsequently either be supplied through the protocol
or be requested from the user (while still in the enrollment process).

See 3.2 Key Protection Objects in:
http://webpki.org/papers/keygen2/sks-api-arch.pdf

Anyway, IMO the virtual bank card use-case cannot be crammed into EST
without a complete rewrite including nuking CMS.

Talking about terminology, maybe you know what a "Simple PKI client"
is?  This is what EST is targeting.

Anders

---

From: Patrick Patterson <[email-masked]>
Date: Mon, 30 Jan 2012 08:07:16 -0500

Hi Anders:

Now, I am not fully cognisant of all of the details of the bank and credit card use cases, but my understanding is that there are roughly two or three ways that these organisations handle secondary authentications to activate and use the cards (i.e. PIN).

The first is that, when the card is initialized in the service bureau, a PIN is generated and programmed into a card, which is subsequently locked. The PIN and card are then sent out via two channels, with the PIN usually being sent in a tamper evident, blinded envelope. Once the cardholder gets both card and PIN (or sometimes just the card), they call some sort of customer service number, and the card is activated. In this case, there is a "match on card" for the PIN, and, past the point of printing, the Bank or CC company doesn't know the PIN (although they can cause it to be reset).

The second is essentially identical to the first, except that the PIN isn't encoded on the card, but is produced and sent to the cardholder, and, during day to day use, must be matched to some sort of Database at the Bank or CC Company. (i.e. no match on card) My understanding is the the companies involved would like to solely use the first method, but must support the second in some circumstances due to braindead terminals / processing facilities.

The third model encodes the card, but no PIN, sends the locked card to the cardholder, and then forces the cardholder to go into some location where a face-to-face proofing is done and a PIN is set (this probably matches most closely to a number of more familiar PKI use cases). Again, in this case, like the first, match on card is done, and the Bank or issuing company doesn't know the PIN.

Now, not having read the draft in detail, but having been involved in a few deployments, I would say that the protocol involved here is between the card management system and the CA. The Card Management System, though, is responsible for using some protocol to talk to the card (Secure Channel, or similar, such as is used today by a number of the current Card Management System vendors), lock/unlock the card, and perform PIN functions. I see these as working at a two different layers. They aren't mutually exclusive, and the fact that the current draft doesn't involve any communication of activation data doesn't necessarily mean that it is fatally broken.

Is there a reason for the CA itself to tie the activation data and the keys together, or can that function be safely handled by a carefully managed card management system (like it is today for most PIV, PIV-I, and other smartcard based PKI deployments)?

If my understanding is flawed here, please let me know - as I said - I'm not fully aware of the intricacies of PKI inside of financial institutions, but I'm a firm believer in not re-inventing wheels, and if the rest of the PKI world can learn from a sector that has a wide deployed base, then please enlighten us :)

Cheers,

Patrick.

>>>>> I think it is the other way round.  A PIN / password / passphrase is given  by the RA want a person completes face-to-face proofing, and this is used in a one-time fashion during the enrollment…

---
Patrick Patterson
Chief PKI Architect
Carillon Information Security Inc.
http://www.carillon.ca

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 30 Jan 2012 22:40:03 +0100

Hi Patrick,
It was nice to see someone who have actually worked with smart cards comment on this!

Just to set the record straight: I never said that EST is "fatally broken", only that it
doesn't satisfy the bank use-case. 

A complication is that probably none of the (very few) people who take interest in this
topic have bothered reading the SKS/KeyGen2 specification although is at least shows
one person's view of what may be needed including the Secure Channel you mention.

In addition, the PKIX WG seem unaware of that Microsoft and Apple have added (entirely
proprietary) protocol bootstrap messages in their adaption of PKIX enrollment protocols.
These are fundamental because they effectively form the foundation for the CSR.
This means that it is the *server* that asks the client to generate keys of the kind that
the server wants, possibly including some variations for different client platforms.

SKS/KeyGen2 takes this notion to another level by letting the server (after an initial
session setup including user interaction), control the entire process.  This is AFAICT
also *a prerequisite for achieving true end-to-end security*.

Regarding Card Management Systems, they do not mix well with mobile phones.
Using SKS/KeyGen2 and a new bread of smart cards, you may eliminate the client-
side of this part as well.

Regards,
Anders Rundgren
http://webpki.org/auth-token-4-the-cloud.html

---

From: Patrick Patterson <[email-masked]>
Date: Mon, 30 Jan 2012 19:13:27 -0500

Hi Anders:

> It was nice to see someone who have actually worked with smart cards comment on this!

Oh, I don't know - there are a number of folks in the mailing list with a fair bit more experience than I.

> doesn't satisfy the bank use-case. 

Ok - which part of the use case does it not satisfy? As I indicated in my mail, there appears to be room for EST for the CMS to CA part of the conversation. If we DO require "end to end", then how do we merge the enrolment protocols with the card management protocols???

> one person's view of what may be needed including the Secure Channel you mention.

Let's start by asking the question why the classic "CMS + CA" (where, for disambiguation, CMS == Card Management System/Service) is insufficient for the "Bank" use case?

> the server wants, possibly including some variations for different client platforms.

Ok - I agree with you here - there are some (rather nice) additions to the Microsoft cert enrolment stuff that allow a developer / CA to control the CSP, crypto strength, etc. that isn't afforded by the rather spartan (but more widely deployed) <Keygen /> tag.

I DO agree that what we probably need to add to any enrolment protocol is a way for the CA to say that "If you are going to request a cert from me, you have to be able to support X, Y or Z capability").

> also *a prerequisite for achieving true end-to-end security*.

In the mobile space, I suppose (although I am not at all familiar with all of the issues) it is important to eliminate the CMS (or, at least that is what you are implying), and go direct to the device. I can see several ways to do this with some of the widely deployed tech (including some rather simple extensions to the keygen tag without adding an entire new protocol). I can also see several drawbacks (including the fact that , in at least the mobile space, the time for approval / certification is greater than that useful lifetime of the product). Please explain further the requirements here, and how the current capability needs to be augmented to address these requirements.

Best Regards,

---
Patrick Patterson
Chief PKI Architect

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 31 Jan 2012 22:28:13 +0100

IMO, the people who brought EST to PKIX need to specify what
EST-00's stated target "Simple PKI clients" actually means,
preferably by listing a few concrete examples.

Now over to your specific questions and comments...

On 2012-01-31 01:13, Patrick Patterson wrote:
> Ok - which part of the use case does it not satisfy? As I indicated in my mail, 
> there appears to be room for EST for the CMS to CA part of the conversation.

Absolutely, but why would the CMS vendors replace their perfectly working CMP
solutions with EST?

> If we DO require "end to end", then how do we merge the enrolment protocols with the card management protocols???

End-to-end of the kind you and I are referring to isn't known by the
the PKIX WG at large and therefore this discussion (early on) went south.

Anyway, my take on this topic is creating a united solution where
certificate enrollment has morphed into or token management.

> Let's start by asking the question why the classic "CMS + CA" (where, for disambiguation, CMS == Card Management System/Service) is insufficient for the "Bank" use case?

If you go back to my initial posting it was about iPhone/Android.
The bank wanted to have PIN-protected keys which PKIX enrollment
protocols doesn't support.

> Ok - I agree with you here - there are some (rather nice) additions to 
> the Microsoft cert enrolment stuff that allow a developer / CA to control
> the CSP, crypto strength, etc. that isn't afforded by the rather spartan
> (but more widely deployed) <Keygen /> tag.

The CertEnroll "concept" is good but unfortunately the implementation is built
on a severely broken trust and security model which have created a virtual
industry of writing proprietary enrollment software.  Just about every country
in the EU have been forced doing that.

> I DO agree that what we probably need to add to any enrolment protocol is a way for
> the CA to say that "If you are going to request a cert from me, you have to be able to
> support X, Y or Z capability").
> 
> In the mobile space, I suppose (although I am not at all familiar with all of
> the issues) it is important to eliminate the CMS (or, at least that is what
> you are implying), and go direct to the device.

Yes.

> I can see several ways to do this with some of the widely deployed tech 
> (including some rather simple extensions to the keygen tag without
> adding an entire new protocol).

When Google designed their Wallet they didn't want to be bogged-down by
technology that was conceived in another time for another purpose.
They did exactly what I would do: built a new system from scratch.

> I can also see several drawbacks (including the fact that , in at 
> least the mobile space, the time for approval / certification is
> greater than that useful lifetime of the product). Please explain
> further the requirements here, and how the current capability needs
> to be augmented to address these requirements.

I don't have any solutions to the certification requirement except
that vendors keep outdated models available for those who insist
having it.  I may be better that vendors use certified building
and testing processes than having external certification of
every mobile terminal.  Automatic updates also helps.

The BYOD phenomena makes this topic even more interesting :-)

Anders