Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols

From: Suomela Tero <[email-masked]>
Date: Fri, 1 Apr 2011 11:20:28 +0300

> From: [email-masked] [mailto:[email-masked]] On Behalf Of max pritikin

>> http://www.ietf.org/proceedings/80/slides/pkix-3.pdf

> An important element of the EST proposal is to move the transport
> security from the message layer (PKCS#7 or CMS) and instead to use TLS.
> This is why we decided to call it Enrollment over Secure Transport.
> TLS is well established as a transport layer security within the broader
> community. 

How does this really differ from CMP then? It has the same PKCS#10 and CRMF
formats and can as well be used over TLS. I suppose the EST would be simpler,
but are there any real conceptual differences? Why choose this instead of CMP?

- Tero

---

From: Stephen Kent <[email-masked]>
Date: Fri, 1 Apr 2011 04:36:27 -0400

At 8:53 AM +0200 4/1/11, Anders Rundgren wrote:
>Dear List,
>
>In a serious attempt keeping the discussion at a constructive
>level, let me begin by scratching the surface of the enrollment
>topic with a rather mundane requirement stated by banks: They
>more or less always deploy a PIN to an issued credential.

what does the phrase "deploy a PIN to an issued credential" mean.
Do you mean a CA sends a PIN to a user, along with a cert issued to that user,
in a sort of unilateral cert issuance model? or, do you mean
requiring a user to send a PIN to a CA (a shared secret between the 
CA and the user) as part of a user requesting a cert?

Steve

---

From: Tomas Gustavsson <[email-masked]>
Date: Fri, 01 Apr 2011 11:35:03 +0200

> but are there any real conceptual differences? Why choose this instead of CMP?

Because the packaging around CMP is complex with lots and lots of
options. Creating the PKCS#10 or CRMF are the easy parts, the tricky
part with CMP comes after. Just passing them through TLS is trivial.

Cheers,
Tomas

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 01 Apr 2011 23:09:22 +1300

Tomas Gustavsson <[email-masked]> writes:

>Because the packaging around CMP is complex with lots and lots of options.
>Creating the PKCS#10 or CRMF are the easy parts, the tricky part with CMP
>comes after. Just passing them through TLS is trivial.

You're being polite :-).  A more succint way of putting it would be "Almost
anything is less painful than trying to work with CMP".  This is (presumably)
one reason why SCEP, which is rather a kludge, remains so popular.

Peter.

---

From: Tomas Gustavsson <[email-masked]>
Date: Fri, 01 Apr 2011 17:05:17 +0200

> one reason why SCEP, which is rather a kludge, remains so popular.

Succinct is a new work in my dictionary, thanks :-)

Agree on SCEP, I though it horrid when I first implemented it, but now
it kind of does the job, easier to grasp than CMP.

I'd say CMP almost works with the 1 or 2 options that are actually in
the wild. Stripping the standard leaving only the few options actually
used would make it almost usable. The ones I've seen are enrollment,
revocation (and possibly keyrecovery) using PasswordBaseHMAC
authentication and enrollment (includes renewal) using digital signature
authentication.
Always exciting when you encounter a new CMP client and have to make
some small adjustments :-)

Cheers,
Tomas

---

From: max pritikin <[email-masked]>
Date: Fri, 1 Apr 2011 16:50:13 -0600

I agree with these comments. 

A sufficiently restricted profile of CMP would be an improvement regarding interoperability but would still be significantly more complex than simply depending on TLS as a secure transport.

- max

On Apr 1, 2011, at 9:05 AM, Tomas Gustavsson wrote:

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

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 02 Apr 2011 15:12:06 +1300

Tomas Gustavsson <[email-masked]> writes:

>I'd say CMP almost works with the 1 or 2 options that are actually in the
>wild. Stripping the standard leaving only the few options actually used would
>make it almost usable. 

I've actually tried this in the past, during the 2000/2001 (non-)interop (I
still have to notes somewhere, from late 2000).  The problem is that once you
remove the options that are unnecessary, the options that are incomprehensible
(there were things in there that even the RFC authors couldn't explain when
asked), and the options that no-one can agree on, what's left is something
that isn't anything like CMP any more.  For example many of the
unnecessary/incomprehensible options are mandatory, so you have to invent non-
values to put in there to fill them up, and conversely some of the optional
options, if they're not present, will cause things to break... actually I've
said all this before:

http://www.cs.auckland.ac.nz/~pgut001/pubs/usenix03.pdf

So to "fix" CMP you end up re-doing it into something that isn't CMP any more.
Every now and then I look at my code and think "yeah, I could probably get
away with that", but then given that it's pretty much dead anyway (there are
what, 3? 4? implementations left) I'm not sure that it's worth the effort.

How much interest would there really be in creating (sigh, yet another) cert
management protocol based on a rewrite of CMP that actually works?  My "let's
actually do it properly" itch would get scratched, but would anyone notice?

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Sat, 2 Apr 2011 04:44:14 -0400

At 4:50 PM -0600 4/1/11, max pritikin wrote:
>A sufficiently restricted profile of CMP would be an improvement 
>regarding interoperability but would still be significantly more 
>complex than simply depending on TLS as a secure transport.
>
>- max

Max,

As I noted during the PKIX meeting, one concern about relying on TLS is
that most TLS implementations are pretty poor re PKI details. Thus using
TLS as a building block for cert issuance will have to be very 
carefully vetted.

Steve

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 02 Apr 2011 11:10:13 +0200

On 2011-04-01 10:36, Stephen Kent wrote:
> in a sort of unilateral cert issuance model?

Yes, that's one way banks and governments deal with PIN-codes.
The "unilateral issuance model" as you appropriately called it,
also typically only cares about the public key in a CSR.

> or, do you mean

No, I didn't mean anything related to the user authenticating to the CA.
Authentication is BTW, not even a part of the proprietary enrollment
protocols referred to since they are without exception browser-based
using all-over-the-map web-methods and procedures for user authentication.

In addition, there's a widely implemented variant of PIN deployment
which is based on the user defining a PIN locally while still
(also locally) enforcing that it adheres to the issuer's policy.

Many PIN deployment schemes support a PIN covering multiple credentials.

IMO, multi-step enrollment systems should use "Secure Messaging" where
you establish a TLS-like channel between the cryptographic container
and the issuer.  This is where the industry is going AFAICT.

A recent IETF standard that deals with PIN-codes during provisioning:
http://datatracker.ietf.org/wg/keyprov

Anders Rundgren
Invited Expert member TrustedComputingGroup

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 02 Apr 2011 22:33:27 +1300

Stephen Kent <[email-masked]> writes:

>As I noted during the PKIX meeting, one concern about relying on TLS is that
>most TLS implementations are pretty poor re PKI details. Thus using TLS as a
>building block for cert issuance will have to be very carefully vetted.

If you use TLS-PSK or -SRP, you're getting the same security as CMP.  With
both protocols you can then bootstrap further requests with the certs you've
got (or continue with the PSK if you prefer).

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Sat, 2 Apr 2011 05:39:56 -0400

>also typically only cares about the public key in a CSR.

For this use case, CMP and CMC both have that capability.

Also, in the U.S. DoD PKI, the public key is NOT the only the cert request
value of interest. So, that's one example of a government-issued credential
that runs counter to your assertion.

>No, I didn't mean anything related to the user authenticating to the CA.

I had personal experience am with CAs that used a PIN sent to a user
as part of authenticating the user before allowing him to retrieve an
issued cert. So, that model is not unknown, even if is not what you 
had in mind when you used the ambiguous phrase "deploy a PIN to an 
issued credential."

>...

Are you suggesting using a "TLS-like" channel between a chip on a 
smart card and an HSM at an issuer? Again, it's not clear from the 
terms you are using. If so, then you should be talking to some ISO 
committee, because they deal with smart card standards.

>http://datatracker.ietf.org/wg/keyprov

KEYPROV (now concluded) dealt with symmetric keys. Also, BTW, your URL
does not point to any specific doc, but rather the full set of WG 
docs. Presumably the doc you had in mind is other than  RFC 6031, 
since that one
uses CMS :-).

Steve

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 02 Apr 2011 11:44:06 +0200

> got (or continue with the PSK if you prefer).

And by using embedded device certificates you get full end-to-end
security without requiring a major server upgrade which TLS-PSK or
TlS-SRP presumes.

Anders

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 02 Apr 2011 23:59:35 +1300

Anders Rundgren <[email-masked]> writes:

>And by using embedded device certificates you get full end-to-end security
>without requiring a major server upgrade which TLS-PSK or TlS-SRP presumes.

And you get your device certificates by ...... ?

(More to the point, if you've already got device certs then you can just use
them to move CMS blobs around, and don't need either CMP or TLS).

Peter.

---

From: Sean Turner <[email-masked]>
Date: Sat, 02 Apr 2011 13:44:45 +0200

> A sufficiently restricted profile of CMP would be an improvement regarding interoperability but would still be significantly more complex than simply depending on TLS as a secure transport.

The same could be said of CMC.

spt

>>> Tomas Gustavsson<[email-masked]>  writes:
>>>

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 02 Apr 2011 13:47:00 +0200

> And you get your device certificates by ...... ?

If we assume that we are still talking about a potential new
effort (?) it seems that companies like Cisco ought to be able
deploying a device certificate during manufacturing.
In fact, one of my day-job's customers have reportedly produced
*hundreds of millions* of device certificates!

For the IMO considerably less interesting use-case, creating a
new enrollment system for dated operating systems and hardware,
it should a zero problem creating a self-signed certificate
during installation of the enrollment software.

By doing that you can reduce the number of security options by
at least a factor 2 which is a major boon for interoperability.

> them to move CMS blobs around, and don't need either CMP or TLS).

Or, even better, use them as a foundation for secure messaging
which is way more powerful than CMS.

Anders

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 02 Apr 2011 14:36:55 +0200

> For this use case, CMP and CMC both have that capability.

Would it be possible providing a reference? I can't find any
PIN deployment support at least...  Revocation passphrase is
close but not the same.

> that runs counter to your assertion.

I have never claimed that my take on this topic is universal but
for the web-based model, there is no point in providing anything
certificate-related in a CSR beyond a public key.  FWIW, my
proposal (sorry no I-D, just an open specification and equally
open working code), have zero support for DNs, key extensions, etc.

> had in mind when you used the ambiguous phrase "deploy a PIN to an 

It is probably a fairly clear phrase for people who deal with
enrollment issues on a daily basis.

> terms you are using.

Secure messaging is the AFAIK established term in this context.
The "quality" of the cryptographic containers may vary since
this is a policy/cost issue.

> If so, then you should be talking to some ISO 

That's seems more to be a task for Max and PKIX in case smart
cards is a part of "as many devices as possible". Is it?

Personally, I don't want to build on technology and standards
that were created in an entirely different time when hardware
had 1/100 the power it has today, and on-line was equivalent
to a 56kbit/s dial-up modem.

> docs. Presumably the doc you had in mind is other than  RFC 6031, 

I was thinking about the combination DSKPP/PSKC which has a
specific XML-based mechanism for dealing with PIN-codes.
Section 10.2 of http://www.rfc-editor.org/rfc/rfc6030.txt

Anders

---

From: Tom Gindin <[email-masked]>
Date: Sat, 2 Apr 2011 10:35:01 -0400

I don't think there's supposed to be PIN support in the protocol, 
as distinct from the data structures.  In PKCS#10, for example, the 
equivalent of extensions go into the attributes.  There is a "challenge 
password" in PKCS#9 (RFC 2985), but no "PIN" or anything like that.  Are 
you proposing that an attribute called either "initial password" or 
"enrollment password" (depending on whether it's used with the server 
after enrollment) be added?  If so, should that attribute be encrypted or 
should it be UTF-8?  If it's UTF-8, I think that a warning to the 
following effect would be appropriate - "PKCS#10 structures containing 
challenge passwords or initial passwords should only be transmitted over 
encrypted links".  I'm not sure why there's no warning like that now, at 
least in 2985's Security Considerations (right next to the one about not 
putting challenge password unencrypted into a directory).  If it's 
encrypted, should it use EnvelopedData from CMS which CMP and CRMF use in 
some similar cases?

                Tom Gindin

From:
Anders Rundgren <[email-masked]>
To:
"[email-masked]" <[email-masked]>
Date:
04/01/2011 02:55 AM
Subject:
[pkix] PIN support in PKIX enrollment protocols
Sent by:
[email-masked]

Dear List,

Maybe the banks and I have difficulties reading RFCs, but none
of us seems to have found any support for PINs in PKIX-related
protocols.  Due to this fact (right or wrong), banks in EU and
Asia yearly spend hundreds of millions of dollars on maintaining
entirely proprietary on-line credential enrollment systems.

There's little point going further down in stack until we have
cleared this hopefully fairly trivial issue.

Anders

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 02 Apr 2011 16:47:39 +0200

I didn't really ask for "solution" but whether the deployment
of a a PIN to lets say a smart card-based credential is a part
of any existing PKIX enrollment protocol.  According to Steve it
is already specified in CMC and CMP so I guess you and I are
at a loss reading RFCs :-)

Anders

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 4 Apr 2011 08:25:44 -0400

> to a 56kbit/s dial-up modem.

I think Stephen's point was that secure channels between cryptomodules is essentially a solved problem *under the condition* that at least one module can be securely provisioned by or register a key with the other (whether that key be symmetric or asymmetric).  In the smartcard arena, the token manager does this either at manufacture or at some other time prior to issuance; once done, all subsequent interactions between parties inherits the assurance of the union between the initial provision/registry assurance and the inherent assurance of the smartcard.

You can layer as many levels of indirection around this as you want, but I think this is a fundamental interaction that can't be escaped.

I've looked at your work before, and correct me if I'm wrong, but I don't think your approach does anything to lift this constraint.  Enabling third parties to manage this provisioning/registration operation and attest it to others is fine and dandy as far as it goes, but isn't the end-all, be-all of cryptomodule management.

-- Tim

---

From: max pritikin <[email-masked]>
Date: Mon, 4 Apr 2011 10:07:05 -0600

> The same could be said of CMC.

Oddly I actually meant to type CMC. :) Yes, we are in agreement. 
- max

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Apr 2011 10:45:26 -0400

>And you get your device certificates by ...... ?

in fairness to Anders, note that Cisco has shipped VoIP phones with embedded
certs for several years, so they are capable of doing that for products.
WiMax products ship with embedded device certs too.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Apr 2011 10:43:54 -0400

>got (or continue with the PSK if you prefer).

I don't what Max had in mind;  max what did you envision? Did you 
anticipate using pre-shared keys or passwords? Also, -SRP is 
informational, which would
not be an appropriate downref for a standards track cert management protocol.

Finally, -SRP seems to focus on one-way (client to server) auth, but
cert enrollment requires 2-way auth.

Steve

---

From: max pritikin <[email-masked]>
Date: Mon, 4 Apr 2011 10:10:53 -0600

> *hundreds of millions* of device certificates!

I was the editor of IEEE 802.1AR Device Identity. I agree that manufacturing installed certificates have an important role to play.

- max

---

From: max pritikin <[email-masked]>
Date: Mon, 4 Apr 2011 10:21:30 -0600

On Apr 4, 2011, at 8:43 AM, Stephen Kent wrote:

> I don't what Max had in mind;  max what did you envision? Did you anticipate using pre-shared keys or passwords? Also, -SRP is informational, which would

I brought up -SRP to help start that aspect of the conversation. I see the following methods as being interesting:

- a username/password used for client authentication (and subsequent authorization)
- an existing certificate (manufacturing installed or otherwise) used for client authentication (and subsequent authorization)
- a PIN w/o username use for ...
- an existing certificate plus a username/password or PIN used for ...

My hope & expectation is that these forms of client authentication are not limited to PKIX certificate enrollment and that many of the interesting protocol work can be, or has already been done, at the TLS/HTTPS layers. Where it has not been done I'd propose we work with the correct wg to get a general purpose ciphersuite/solution in place.

Ideally it should not be necessary to include a PKIX specific element for these issues. If they are realistic authentication method then I imagine they are necessary for non-PKI centric solutions as well. 

- max

---

From: Thomas Pornin <[email-masked]>
Date: Mon, 04 Apr 2011 12:32:42 -0400

On Mon, 2011-04-04 at 10:43 -0400, Stephen Kent wrote:
> Finally, -SRP seems to focus on one-way (client to server) auth

No, SRP is two-ways: the client and the server are mutually
authenticated with regards to the shared secret (i.e. the password). SRP
is a PAKE (Password Authenticated key Exchange) which adds protection
against offline dictionary attacks: an attacker trying to guess the
shared secret must interact with either the client or the server for
each guess; he never learns enough to try potential passwords "at home".
That's why the shared secret can be of relatively low entropy (e.g.
something which fits in the brain of a human being, colloquially known
as a "password").

Where SRP is asymmetric is in secret data storage: what the server
stores is not the shared secret, but some data derived from the shared
secret. This is additional security: an attacker who has read access to
the complete server memory does not learn the shared secret (he does
learn enough to be able to masquerade as the server, but not as the
client; also, he learns enough to make an offline dictionary attack on
the shared secret).

	--Thomas Pornin

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Apr 2011 13:31:52 -0400

>PIN deployment support at least...  Revocation passphrase is

Neither CMP nor CMC refer to PINs per say, as they are just examples
of a shared secret between an issuer and a subject. But both protocols
include provision for transport of such data.  Just search for "passwords"
in the docs.

in CMC the relevant text is in Section 6.2 (6.2.  Identification and 
Identity Proof Controls).

In CMP, Section 5.1.3.1.  (Shared Secret Information) is one area where this
topic is discussed.

Certainly you're not suggesting that the word "PIN" needs to be used 
here, right?

>open working code), have zero support for DNs, key extensions, etc.

thanks for the clarification of your position. as for the "no I-D just ..."
that's fine, but not really relevant to PKIX. For any SDO, if one chooses to
not submit a doc to that SDO, one ought not expect to have an impact on
that SDO.

>... So, that model is not unknown, even if is not what you

PKIX members deal with general PKI issues, and that larger context, 
the phrase was vague. Again one needs to adopt the terminology of the 
context in which one wants to be heard, ...

>this is a policy/cost issue.

"Secure messaging" is a broad term in the security community. In
the IETF it nominally refers to S/MIME. If this is ISO (smart card)
terminology, then you ought not expect it to be recognized in PKIX.

>cards is a part of "as many devices as possible". Is it?

The phrase "as many devices as possible" is not mine :-). If operating
on a smart card does not impose undue constraints on protocols, then
I'm comfortable with including them.  But, we have a broad constituency
for PKI, and it would not be appropriate to skew solutions to one
particular technology.

>to a 56kbit/s dial-up modem.

If this is an obtuse way of saying that you don't want to work
in the PKIX/IETF context, please, just go away.

>Section 10.2 of http://www.rfc-editor.org/rfc/rfc6030.txt

thanks for identifying specific doc from that WG.

I see the 6.5 pages of XML schema in this RFC, of which about 8-10 
lines make reference to a PIN. So what? Certainly you're not 
suggesting that we adopt
XML for this protocol just because there is a tiny amount of 
potentially relevant syntax this standard, right?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Apr 2011 13:15:00 -0400

>client; also, he learns enough to make an offline dictionary attack on

Thanks for the clarification.

Steve

---

From: max pritikin <[email-masked]>
Date: Mon, 4 Apr 2011 12:56:56 -0600

> but are there any real conceptual differences? Why choose this instead of CMP?

Given the lack to interoperable PKI enrollment/deployment and use mechanisms I feel that "simpler" is not to be understated. 

CMP [RFC4210] describes transport as being handled by an external "CMPTrans" document of which the current draft is draft-ietf-pkix-cmp-transport-protocols-10 (expired 2 days ago but I suspect an update will happen soon). As such CMP provides an optional "PKI Message protection" methods where "In the future, if/when external mechanisms are modified to accommodate boot-strapping scenarios, the use of PKIProtection may become rare or non-existent".

I believe the future is now. Sufficient external mechanisms are currently available and we need to leverage them (in addition to encouraging improvements in those areas as necessary). Doing so allows us to simplify by removing many options and focusing only on the core enrollment methods actually necessary. 

- max

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 04 Apr 2011 22:41:34 +0200

On 2011-04-04 14:25, Miller, Timothy J. wrote:
> I think Stephen's point was that secure channels between
> cryptomodules is essentially a solved problem
> *under the condition* that at least one module can be securely
> provisioned by or register a key with the other (whether
> that key be symmetric or asymmetric).

Tim,

Sure, but that doesn't make deployment of PINs automatically
become a part of CMC, CMP, SCEP or EST.

> In the smartcard arena, the token manager does this
> either at manufacture or at some other time prior to
> issuance; once done, all subsequent interactions between
> parties inherits the assurance of the union between the
> initial provision/registry assurance and the inherent
> assurance of the smartcard.

Absolutely.

> You can layer as many levels of indirection around this as
> you want, but I think this is a fundamental interaction that
> can't be escaped.

100% agreed.

> I've looked at your work before, and correct me if I'm wrong, 
> but I don't think your approach does anything to lift this
> constraint.

The intention is enabling working provisioning solutions
for consumers who buy (or receive) a cryptomodule (be it
embedded in a phone or a separate token), where issuers
may discriminate cryptomodules vendors to their liking.

A few related pointers worth following:

http://www.globalplatform.org/medianewsletterarchives.asp?id=mednew201101

"GlobalPlatform Announces the Formation of a Consumer-centric Working Group"
"the technical foundations are in place to address this 'white card' concept"

http://www.digitaltrends.com/mobile/devices/google-teams-with-mastercard-and-citigroup-for-nfc-testing

Regardless of if my take on this topic succeeds or not, I'm
pretty convinced that the larger part of the consumer market
will rely on on-line provisioning based on secure messaging
and that IMHO, limits the scope of a new PKIX enrollment
effort since all the tech *seems* to have been fixed before
a more thorough use-case analysis has been carried out.

I wouldn't underestimate the difficulties:

http://www.craigburton.com/?p=3131

Although MSFT refers to all kinds of misfortunes
("the world wasn't ready"), the true culprit behind this
epic failure is that MSFT does not have a consumer PKI
enrollment solution that meets even the most basic requirements
which has created a whole industry of IMO fairly redundant
makers of "browser PKI clients".  I always thought that
the idea was that the browser did the PKI-ops itself!!!

I think the following guys could have an instrumental role
(if they want...) in the creation of consumer PKI technology:

http://www.nist.gov/nstic

--Anders

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 06 Apr 2011 17:34:02 +1200

Stephen Kent <[email-masked]> writes:

>Also, -SRP is informational, which would not be an appropriate downref for a
>standards track cert management protocol.

-PSK is standards-track.

>Finally, -SRP seems to focus on one-way (client to server) auth, but cert
>enrollment requires 2-way auth.

Both -SRP and -PSK provide true mutual auth.  In fact they're the only
mechanisms in TLS that do.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 06 Apr 2011 18:49:03 +1200

max pritikin <[email-masked]> writes:

>CMP [RFC4210] describes transport as being handled by an external "CMPTrans"

Note that in effect "CMP transport" just means "use HTTP", it's about as
simple as that.

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Apr 2011 11:22:51 -0400

>>standards track cert management protocol.

  I didn't say otherwise.

>mechanisms in TLS that do.

pre-shared keys/passwords do not scale well, and thus are a 
questionable basis for other than trivial deployment contexts. I 
don't consider either to be a
viable basis for what Max is proposing, for that reason.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 6 Apr 2011 10:02:26 -0700

On Apr 6, 2011, at 8:22 AM, Stephen Kent wrote:

> pre-shared keys/passwords do not scale well, and thus are a questionable basis for other than trivial deployment contexts. I don't consider either to be a

While the "do not scale well" part is true for some scenarios, it is not necessarily correct for enrollment of machine certs. That is, it is perfectly reasonable to have a long preshared key printed on the label on the bottom of the bottom of a hardware system and use that as the preshared key. This scales just fine for certs that will be issued by the hardware manufacturer.

--Paul Hoffman

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Apr 2011 13:40:13 -0400

At 10:02 AM -0700 4/6/11, Paul Hoffman wrote:
>While the "do not scale well" part is true for some scenarios, it is 
>not necessarily correct for enrollment of machine certs. That is, it 
>is perfectly reasonable to have a long preshared key printed on the 
>label on the bottom of the bottom of a hardware system and use that 
>as the preshared key. This scales just fine for certs that will be 
>issued by the hardware manufacturer.

My perception is that certs that are provisioned by a manufacturer 
are generated
and installed prior to shipping a product, not when the product is deployed
at a customer's site.  Are you discussing manufacture-time provisioning?

Another issue is that if we say that we plan to support a broad range 
of scenarios, as Max did, then it is inappropriate to rely on 
pre-shared keys for TLS as a base for the protocol. Yes, they may be 
appropriate for some, limited
contexts, but not overall. So, we might have to specify a range of 
context assumptions and matching TLS key management capabilities, and 
hope that folks
can pair these appropriately.  That is doable, but it may not be preferable,
since we all know how well users follow such guidance :-).

Steve

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 06 Apr 2011 19:56:46 +0200

On 2011-04-06 19:02, Paul Hoffman wrote:
>> pre-shared keys/passwords do not scale well, and thus are
>> a questionable basis for other than trivial deployment contexts.
>> I don't consider either to be a viable basis for what
>> Max is proposing, for that reason.
>
>
> While the "do not scale well" part is true for some scenarios,
> it is not necessarily correct for enrollment of machine certs.
> That is, it is perfectly reasonable to have a long preshared
> key printed on the label on the bottom of the bottom of a
> hardware system and use that as the preshared key. This scales
> just fine for certs that will be issued by the hardware manufacturer.

For hardware systems there is no need for such measures.  Certificates
are deployed as an integral part of the [secure] production process.

Anders

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 6 Apr 2011 11:37:49 -0700

On Apr 6, 2011, at 10:40 AM, Stephen Kent wrote:

> My perception is that certs that are provisioned by a manufacturer are generated

I am discussing different deployment options for different manufacturers, not a one-size-must-fit-all limitation.

> Another issue is that if we say that we plan to support a broad range of scenarios, as Max did, then it is inappropriate to rely on pre-shared keys for TLS as a base for the protocol. Yes, they may be appropriate for some, limited
> contexts, but not overall. So, we might have to specify a range of context assumptions and matching TLS key management capabilities, and hope that folks

If your concern is scalability, then it should be completely up to the CA to measure that. If your concern is security of the enrollment messages, then clearly listing the concerns and specifying how to make preshared secrets strong enough is both easy and sufficient.

--Paul Hoffman

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 6 Apr 2011 15:04:06 -0600

A manufacturer with a sufficiently secure implementation of manufacturing installed certificates is selling a product that can be easier and/or more secure to deploy. The CA can verify device identity in addition to (2 factor) or even instead of user identity. The purchased HW provides value (if the CA wishes to leverage it). 

As always the CA may require a preshared secret or other password based mechanism to be used. The security concerns for the out-of-band distribution of that key material are entirely handled by the customer. 

These are captured in the Authorization 1-3 requirements I outlined in the other thread. 

- max

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Apr 2011 17:28:02 -0400

At 11:37 AM -0700 4/6/11, Paul Hoffman wrote:
>O...
>
>I am discussing different deployment options for different 
>manufacturers, not a one-size-must-fit-all limitation.

I was worried that we might say that TLS cert processing concerns
would be avoided by using SRP/PSK, and thus TLS is OK for all cases.
if your comment was meant to convey the notion that SRP/PSK is OK for 
some environments, no problem.

>  > Another issue is that if we say that we plan to support a broad 
>range of scenarios, as Max did, then it is inappropriate to rely on 
>>context assumptions and matching TLS key management capabilities, 
>>and hope that folks
>If your concern is scalability, then it should be completely up to 
>the CA to measure that. If your concern is security of the 
>enrollment messages, then clearly listing the concerns and 
>specifying how to make preshared secrets strong enough is both easy 
>and sufficient.

I don't understand these last 2 comments.

We're developing a standard. We need to specify the scope for which 
the standard is applicable. So far the suggestions of scope are not 
restricting this standard to only those contexts where SRP/PSK is 
viable, because scaling is not an issue. I don't think that it's 
reasonable to suggest that we can  make pre-shared secrets "strong 
enough" for all of the contexts that have been proposed.

Does that explanation help clarify my concerns?

Steve

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 07 Apr 2011 15:58:21 +1200

Stephen Kent <[email-masked]> writes:

> pre-shared keys/passwords do not scale well,

"... and we'll keep asserting this until you cry Uncle, dammit!". 
PSKs/passwords are the basis of the most complex, scalable systems ever 
designed.  Just one of these, Facebook, has half a billion users using non- 
scalable PSKs, and exactly zero using scalable PKI.  Gmail, Yahoo, Youtube, 
Flickr, all of these operate on a planetary scale using non-scalable PSKs.  So 
could I make the following modest suggestion, whenever someone wants to say 
"PSKs don't scale", could they either qualify it with "... beyond planetary 
scale" or alternatively "... and I'll keep asserting this while saying 
LALALALALAI'MNOTLISTENING until you go away".

Thanks,
Peter.

---

From: max pritikin <[email-masked]>
Date: Wed, 6 Apr 2011 22:20:24 -0600

Peter, it is interesting to note that Facebook and other similar examples are a hybrid model involving PSKs _and_ PKI, since all these password exchanges occur over HTTPS. I think the most important lesson from your example is that such hybrids are valuable and should not be summarily dismissed.

- max

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 07 Apr 2011 06:25:15 +0200

> LALALALALAI'MNOTLISTENING until you go away".

It is possible that you guys are talking about different things.
If containers should be capable of authenticating themselves it
seems that PSKs would be a very stupid (non-scalable) solution.

For users and operators that in some way invoke the enrollment
process, a one-time/short-lived password is entirely appropriate.

However, building on non-standard (generally implemented) TLS
variants is not what I would do.

Anders

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 7 Apr 2011 07:59:50 -0400

On Apr 6, 2011, at 12:02 PM, Paul Hoffman wrote:

> While the "do not scale well" part is true for some scenarios, it is not necessarily correct for enrollment of machine certs. That is, it is perfectly reasonable to have a long preshared key printed on the label on the bottom of the bottom of a hardware system and use that as the preshared key.

Which anyone can read and claim, thus mooting the binding.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 7 Apr 2011 08:03:58 -0400

The problem with manufacturer provisioning is in the consumer space the potential for privacy violation is high.  That's why TCG's Privacy CA rigamarole looks the way it does; it prevents collusion between the manufacturer and the identity consumers.  Within an enterprise this isn't a concern (or more accurately, it's a concern that can be signed away in the employee contract).

-- T

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 7 Apr 2011 08:39:21 -0400

Also note a comment on the last page of
http://wwwcsif.cs.ucdavis.edu/~congdon/ecs235a-f07-poster.pdf:

  - TPM initialization process to support IDevID is
    cumbersome and expensive for manufacturers.
  - 802.1AR should consider loosening mandate to ship
    with IDevID and allow postmanufacturing provisioning.

Apparently manufacturers of security-oriented devices don't want to be
bothered with the inconvenience of actually having to generate a
keypair!  I don't know what to make of this - just another data point to
consider.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Miller, Timothy J.
Sent: Thursday, April 07, 2011 8:04 AM
To: Max Pritikin (pritikin)
Cc: [email-masked]; Paul Hoffman
Subject: Re: [pkix] IETF 80: The future ofPKIX certificate
enrollmentprotocols

The problem with manufacturer provisioning is in the consumer space the
potential for privacy violation is high.  That's why TCG's Privacy CA
rigamarole looks the way it does; it prevents collusion between the
manufacturer and the identity consumers.  Within an enterprise this
isn't a concern (or more accurately, it's a concern that can be signed
away in the employee contract).

-- T

On Apr 6, 2011, at 4:04 PM, Max Pritikin (pritikin) wrote:

> A manufacturer with a sufficiently secure implementation of
manufacturing installed certificates is selling a product that can be
easier and/or more secure to deploy. The CA can verify device identity
in addition to (2 factor) or even instead of user identity. The
purchased HW provides value (if the CA wishes to leverage it). 
> 
> As always the CA may require a preshared secret or other password
based mechanism to be used. The security concerns for the out-of-band
distribution of that key material are entirely handled by the customer. 
>>>>> questionable basis for other than trivial deployment contexts. I
don't consider either to be a viable basis for what Max is proposing,
for that reason.
>>>> 
>>>> While the "do not scale well" part is true for some scenarios, it
is not necessarily correct for enrollment of machine certs. That is, it
is perfectly reasonable to have a long preshared key printed on the
label on the bottom of the bottom of a hardware system and use that as
the preshared key. This scales just fine for certs that will be issued
by the hardware manufacturer.
>>> are generated and installed prior to shipping a product, not when 
>>> the product is deployed at a customer's site.  Are you discussing
manufacture-time provisioning?

>>> appropriate for some, limited contexts, but not overall. So, we
might have to specify a range of context assumptions and matching TLS
key management capabilities, and hope that folks can pair these
appropriately.  That is doable, but it may not be preferable, since we
all know how well users follow such guidance :-).
>> If your concern is scalability, then it should be completely up to
the CA to measure that. If your concern is security of the enrollment
messages, then clearly listing the concerns and specifying how to make
preshared secrets strong enough is both easy and sufficient.

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 07 Apr 2011 16:54:21 +0200

On 2011-04-07 14:03, Miller, Timothy J. wrote:
> The problem with manufacturer provisioning is in the consumer
> space the potential for privacy violation is high.  That's
> why TCG's Privacy CA rigamarole looks the way it does; it
> prevents collusion between the manufacturer and the
> identity consumers.

As a long-time member of TCG I'm aware of this but I actually
disagree with this conclusion which I believe was based on the
rather overblown idea that you need to attest the trustworthiness
of your computer to essentially any site on the internet.

For identity provisioning I claim that an e-mail address which is
sort of the bare-bone minimum for identity vetting, is much more
privacy-impeding than a fairy short-lived machine identity.
That the machine identity is "certified" does not make a difference
from a privacy point of view, it has only implications from a legal
perspective in case of a criminal investigation and then your privacy
is [more or less] gone anyway.

Privacy should IMHO also be put it in a real-world context
ranging from Cloud services, DNA, E-mail addresses, Mobile phone
networks (they know WHO and WHEN you talk to and from WHERE!),
Surveillance cameras, GPS-based Apps, to Social media like Facebook.

TCG will have a hard time getting the Privacy CA going.
The 200-400 million TPMs shipped have rather little to do and
I think the root of the problem is that putting policy in silicon
was a pretty bad idea.  It was apparently a promise to BSI...
As I understand, the mobile group have effectively nuked the
privacy concept although they don't dare to say it in clear...

In my take on this, the *user* makes the decision to enroll or
not with information that his/her machine ID may be stored by
the identity provider.  This is similar to how other privacy
threats are dealt with today so it feels alright :-)

Anders

 Within an enterprise this isn't a
> concern (or more accurately, it's a concern that can be
> signed away in the employee contract).
> 
> -- T
> 
>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 7 Apr 2011 17:59:24 -0400

>LALALALALAI'MNOTLISTENING until you go away".

Peter,

What on earth are you talking about?

None of the cited systems use PSKs. They allow a user to select any 
PW and they associate that PW woth the asserted user ID, having not 
verified the user ID in any fashion at all. The user relies on the 
(seriously-flawed) browser PKI implementation (or on the DNS) to 
confirm that he/she is connected to the proper web site.

None of these systems seem relevant to our discussion of cert 
enrollment, unless the goal is to allow cert enrollment to be as 
secure as widely-used systems that permit any user to select any name 
he/she desires.

Steve

---

From: max pritikin <[email-masked]>
Date: Thu, 7 Apr 2011 15:24:35 -0700

(I consider this a little off topic, but interesting) 

>    cumbersome and expensive for manufacturers.

Yes, implementing the 802.1AR specification on existing TPM hardware is cumbersome but possible. One could always design hardware that was better at providing the IDevID functionalities but this particular off-the-shelf solution was worth understanding. Paul Congdon (the author of this paper) took time to understand that issue during 802.1AR specification, which was much appreciated then and now. 

>    with IDevID and allow postmanufacturing provisioning.

I think the definitions of "ship" and "postmanufacturing" are sufficiently vague to make this a non-issue. Would it violate something to 'ship' a device to an organization that performs a 'postmanufacturing' insertion of an IDevID? 

I suppose one could argue that 802.1AR should support an LDevID w/o an IDevID. I think that would be too loose but could see the point. I'll have to think about that approach. 

None of this really effects how we use existing credentials during an enrollment protocol. 

> keypair!  I don't know what to make of this - just another data point to

Yup. I think we can make this worth their time/effort.

- max

---

From: max pritikin <[email-masked]>
Date: Thu, 7 Apr 2011 15:34:15 -0700

I continued:
>> As such CMP provides an optional "PKI Message protection" methods where "In the future, if/when external mechanisms are modified to accommodate boot-strapping scenarios, the use of PKIProtection may become rare or non-existent".

Meaning that the different is that EST uses HTTPS (e.g. TLS) thus allowing dramatic simplification of the messages. Is that a 'dramatic profile of CMC' vs a new protocol? Shrug. Lets leave that semantic discussion aside.

The end result should be much simpler protocol resulting in greater interoperability. There are other aspects borrowed from CMP (such as the CA rekey discussion) and a more completely specified transport discussion... so I find it easiest to think of this as a "unification of good ideas" proposal.

(I'd like to limit it to ideas that currently have traction plus some extensibility agility, rather than throwing a million more options out there and seeing what sticks). 

- max

---

From: Tom Gindin <[email-masked]>
Date: Thu, 7 Apr 2011 21:18:22 -0400

Peter:

        After reading Anders' and Max's messages, I'm convinced that 
people are indeed talking past each other.  A shared secret doesn't scale 
to large numbers of peers for a given entity.  However, all the popular 
systems which use passwords have a star or wheel topology.  The servers in 
the center do need authenticators recognized by large numbers of clients, 
so shared secrets would not work for them and they have certificates from 
public CA's.  The clients on the boundary need to be authenticated against 
a central repository, so they have effectively only a single peer and thus 
passwords for them may pose a memorization or privacy problem but not a 
scaling one.
        I'd describe this difference between shared secrets and published 
certificates as one of "recognition scope".   Having limited recognition 
scope, as self-signed certificates and bare public keys also do, doesn't 
really matter when a central authentication repository is used.  Is there 
a term in use today to describe this property, or is this term useful?

                Tom Gindin

From:
Peter Gutmann <[email-masked]>
To:
[email-masked], [email-masked]
Cc:
[email-masked]
Date:
04/06/2011 11:58 PM
Subject:
Re: [pkix] IETF 80: The future of PKIX certificate      enrollment 
protocols
Sent by:
[email-masked]

"... and we'll keep asserting this until you cry Uncle, dammit!". 
PSKs/passwords are the basis of the most complex, scalable systems ever 
designed.  Just one of these, Facebook, has half a billion users using 
non- 
scalable PSKs, and exactly zero using scalable PKI.  Gmail, Yahoo, 
Youtube, 
Flickr, all of these operate on a planetary scale using non-scalable PSKs. 
 So 
could I make the following modest suggestion, whenever someone wants to 
say 
"PSKs don't scale", could they either qualify it with "... beyond 
planetary 
scale" or alternatively "... and I'll keep asserting this while saying 
LALALALALAI'MNOTLISTENING until you go away".

Thanks,
Peter.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 11 Apr 2011 13:21:59 -0400

At 3:04 PM -0600 4/6/11, Max Pritikin (pritikin) wrote:
>manufacturing installed certificates is selling a product that can 
>be easier and/or more secure to deploy. The CA can verify device 
>identity in addition to (2 factor) or even instead of user identity. 
>The purchased HW provides value (if the CA wishes to leverage it).
>
>based mechanism to be used. The security concerns for the 
>out-of-band distribution of that key material are entirely handled 
>by the customer.
>

max,

I think we have gotten way off target here, and I apologize for any 
contribution to this distraction that I may have made.

If a manufacturer installs a cert in a product, it probably can do so 
in an acceptably secure fashion, relative to its perception of what 
is secure enough. It could use pre-shared keys, or it could just 
declare that the cable between the device and a co-located A system 
is physically secured, and be done with it.

The manufacturer need not use any standard in this provisioning 
process, if it takes place purely inside of the manufacturing 
context.  There are benefits to using a standard here, e.g., the 
manufacturer might be able to use a CA system that adheres to the 
standard, instead of rolling its own. But, I don't see this as 
critical, and if this were the only (or even the primary) use case, I 
would suggest it is not worth developing the standard in PKIX.

I think you have  proposed a broader scope for this 
enrollment/management protocol. But, you also suggested that we use 
TLS to secure the connection between a cert requester and a CA. I 
asked whether we are comfortable with
that assumption, because of concerns over how well TLS specifies use of certs.

Citing examples where one need not use certs with TLS (e.g., using 
pre-shared keys) does not address the concern that I raised, unless 
we believe that such modes of TLS use cover ALL of the scope for this 
protocol.  THus we need not spend any more time discussing whether 
factory initialization of a device can be made adequately secure via 
pre-shared keys.  This is not a context in which scaling issues for 
pre-shared keys arise.

If a device with a factory-installed cert is going to communicate 
with a CA that has no relationship to the vendor, then we are 
entering a different realm.  We need to address how the device knows 
what CA it is talking to, to the satisfaction of the owner of the 
device. We also need to discuss how this CA knows that it is 
communicating with the device in question, since verification of the 
device cert requires interaction with the vendor (or the vendor's CA).

Does this help?

Steve

---

From: max pritikin <[email-masked]>
Date: Mon, 11 Apr 2011 11:33:07 -0700

On Apr 11, 2011, at 10:21 AM, Stephen Kent wrote:

> I think we have gotten way off target here, and I apologize for any contribution to this distraction that I may have made.
> 
> If a manufacturer installs a cert in a product, it probably can do so in an acceptably secure fashion, relative to its perception of what is secure enough. It could use pre-shared keys, or it could just declare that the cable between the device and a co-located A system is physically secured, and be done with it.
> 
> The manufacturer need not use any standard in this provisioning process, if it takes place purely inside of the manufacturing context.  There are benefits to using a standard here, e.g., the manufacturer might be able to use a CA system that adheres to the standard, instead of rolling its own. But, I don't see this as critical, and if this were the only (or even the primary) use case, I would suggest it is not worth developing the standard in PKIX.

Agreed. Manufacturing installed certs are "off topic" and I think they should be on a different thread.

> I think you have  proposed a broader scope for this enrollment/management protocol.

The scope of the enrollment protocol includes how the client is authenticated.

> But, you also suggested that we use TLS to secure the connection between a cert requester and a CA. I asked whether we are comfortable with

TLS specifies some limitations on certificates involved but does not go into detail concerning the authentication/authorization model (TLS 1.2 D.2 pretty much just punts this). Using HTTPS provides us a bit of guidance for server authentication, but the EST document is intended to flesh this out fully for enrollment protocols. I don't see this as a concern so much as a requirement: this needs to be specified. 

> Citing examples where one need not use certs with TLS (e.g., using pre-shared keys) does not address the concern that I raised, unless we believe that such modes of TLS use cover ALL of the scope for this protocol.  THus we need not spend any more time discussing whether factory initialization of a device can be made adequately secure via pre-shared keys.  This is not a context in which scaling issues for pre-shared keys arise.

Agreed. The text of EST is focuses on these issues not factory installation issues.

> If a device with a factory-installed cert is going to communicate with a CA that has no relationship to the vendor, then we are entering a different realm.  We need to address how the device knows what CA it is talking to, to the satisfaction of the owner of the device. We also need to discuss how this CA knows that it is communicating with the device in question, since verification of the device cert requires interaction with the vendor (or the vendor's CA).

Yup. 

> Does this help?

I think we're on the same page,

- max

---

From: Stephen Kent <[email-masked]>
Date: Mon, 11 Apr 2011 15:55:55 -0400

Max,

based on your reply, I think we're heading in the right direction.

Thanks,

Steve