Subject: Re: [pkix] some comments on draft-ietf-pkix-est-01

From: Max Pritikin <[email-masked]>
Date: Mon, 2 Apr 2012 17:48:16 -0600

Comments inline, 

On Mar 27, 2012, at 4:49 AM, Anders Rundgren wrote:

> Continuing this thread...
> 
> From the abstract I would be interested in hearing what
> 
> "simple Public Key Infrastructure clients"
> 
> actually refer to.

The first paragraph of the introduction notes that: "EST is designed to be easily implemented by clients and servers using common "off the shelf" PKI, HTTP, and TLS components". This also relates to the use of the "simple" messages defined in CMC. 

> 
>  "This profile, called Enrollment over Secure Transport (EST),
>   describes a simple yet functional certificate management protocol"
> 
> If you combine all the options, it is not that simple anymore.
> Is a client and server assumed to support all the options?
> If not, how are they supposed to know which subset that can be used?
> Looks like a rather configuration-dependent scheme IMHO.

If you can think of any options which can be removed please indicate them and suggest their removal. Although I feel we've done a good job ensuring there are very few options I'd happily hear of ones that can go away. 

>  "K1 "Algorithm agility".  The protocol MUST support algorithm agility"
> 
> The author's opinion on what that means is flawed.  Although supporting
> a bunch of TLS ciphers may be interesting, algorithm agility regarding
> generated keys is a parameter that most (if not all) issuers care about.

The authors opinion is irrelevant as we're discussing the actual wording of the text. 
I agree that K1 should also reference the type of key material being enrolled. 

>  "5.3 Distribution of CA certificates
>      Before engaging in enrollment operations, clients MUST request trust
>      anchor information (in the form of certificates) by sending an HTTPS
>      GET message to the EST base URI with the relative path extension
>      '/CACerts'"
> 
> This mandatory requirement isn't particularly universal. A more
> common method is that the user rather gets an option "accepting" the
> root of the distributed certificate path.

I think you are excessively combining the server authentication discussion (sections 5.2 and 4.3.1.1) and the distribution of CA certificates. 

There is value in the "MUST" here because then the client has any possible CA key rollover certificates which might be necessary for chain building etc that might be encountered during the enrollment operations. (e.g. if the client is issued a certificate using the CA's new certificate the client has sufficient information to know what happened and to successfully use its new certificate). 

>  In today's server-centric
> world the CA of a *client certificate* often doesn't have any
> meaning for the client/user at all.

IF the PKI is performing key rollover on the CA certificate then this is not true. For example when acting as a TLS client the client must build an appropriate chain to send to the server. In the interest of limiting options and capability exchanges the client MUST perform this operation even if it is only useful in some re-enrollment scenarios. 

Thanks for your feedback,

- max

> Anders
> PS. By thinking out loud I got an idea for KeyGen2!  Add an option
> to the install certificate part of the protocol where the issuer may
> claim that this root may be of interest to user.  By doing that KeyGen2
> doesn't have to bother users with (for example) accepting VISA's EMV-root
> since this a thing for the merchants/acquirers to care about. DS.
> 
> On 2012-03-27 11:25, Sean Turner wrote:
>> Just a couple of comments the WG should consider:
>> 
>> Technical:
>> 
>> 1. the /simpleEnroll, /simpleReEnroll, and /serverKeyGen use PKCS#10s 
>> for the request and return the certificate(s) in a mime media type.  In 
>> many instances, the "normal" query/response for a certificate is a 
>> PKCS#10 request followed by a PKCS#7 response, where the PKCS#7 is the 
>> degenerate certs-only message.  Does anyone see any benefit in reusing 
>> the PKCS#10/PKCS#7 model instead of PKCS#10/certificate?  Changing it 
>> would align nicely/exactly with the simple PKI request/response from CMC.
>> 
>> 2. in s5.6.2, just use application/pkcs8 instead of 
>> application/pkix-privkey.
>> 
>> Not so technical:
>> 
>> 1. appendix D really ought to be in its own document or in part of 
>> draft-nourse-scep.
>> 
>> spt
>> _______________________________________________
>> pkix mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pkix
>> 
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Max Pritikin <[email-masked]>
Date: Mon, 2 Apr 2012 18:08:41 -0600

(I've updated the subject on this thread)

On Mar 28, 2012, at 3:17 AM, Tomas Gustavsson wrote:

> 
> You comment made me realize something Anders.
> 
> * Support for multiple CAs
> 
> Imho new protocols should support the function where the EST/CA server contains multiple CAs. Think of one EST front end with multiple CA backends. Most CA software today runs multiple CAs in a single instance, and with cloud computing this only grows.
> 
> Multiple CAs can be handled with virtual hosts, but it's simpler if there is protocol suppport.

Hmm. I'd imagined either virtual hosts or differing BASEPATHs in the URLs so that these would be three distinct EST servers offering CACerts for different CAs:

a) https://example1.org/arbitrary/base/path/CACerts
b) https://example2.org/arbitrary/base/path/CACerts
c) https://example2.org/DIFFERENT/base/path/CACerts

In practice I expect this implies the use of Section 5.2 method 1. 

For (a) and (b) the TLS SNI extension could be used to decide on which server cert to use thus allowing limited use of Section 5.2 method 2 although there is no text in the draft discussing this. Method 2 isn't an option for (b) and (c) differentiation since there is no way to determine the BASEPATH within the SNI extension. Should there be such text? I tend to think this is more of a common HTTPS issue and is supported by TLS (although not commonly?) and that nothing needs to be discussed. 

> Section 5.3 and 5.3.1 does not make it clear how this should work. In fact section 5.3 is very cryptic. The URL ending is /CACerts but section 5.3.1 says "CA trust anchor information in the form of a certificate.".

Thanks for the catch. This should be plural as multiple certificates are in the response. 

> Can /CACerts only return a single certificate? Kind of against the name, or can "trust anchor information" mean multiple independent certificate chains?

Section 5.3.1 paragraph 1, second sentence: "Additionally the server MUST include any "Root CA Key Update" CMP certificates". The remainder of this section details exactly what these certificates are -- but they are all for the same CA.

> For enrollment, ways of identifying the target CA is also desired. For CRMF this is usually embedded in the request, but for PKCS#10 it is not...

As discussed above the URI can accurately describe which CA.

Does this all work for you?

Thanks,

- max

> Regards,
> Tomas
> 
> On 03/27/2012 12:49 PM, Anders Rundgren wrote:
>> root of the distributed certificate path.  In today's server-centric

---

From: Tomas Gustavsson <[email-masked]>
Date: Tue, 03 Apr 2012 10:10:57 +0200

> c) https://example2.org/DIFFERENT/base/path/CACerts

Different baspaths is something I like!

> Does this all work for you?

Yes. Example descriptions of different basepaths and the clarification 
regarding CA certificates works fine for me.

Cheers,
Tomas

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 03 Apr 2012 15:45:28 +0200

> The first paragraph of the introduction notes that: "EST is designed to be easily implemented by clients and servers using common "off the shelf" PKI, HTTP, and TLS components". This also relates t…

That's one way of expressing it.  I'm a hands-on guy so I am rather
thinking about how well it fits things like this:

http://www.pcworld.com/businesscenter/article/252584/ibm_cio_discusses_big_blues_byod_strategy.html

IMO EST doesn't address this market without adding non-standard
"bootstrap" steps like Cisco's AnyConnect.  I find AnyConnect pretty
quirky and (undocumented...) compared to Apple's bootstrap profile scheme.

It seems that you actually must be a device/OS vendor in order to implement
things the way Apple do since no "mere mortals" can get under the hood or
dump arbitrary junk in SYSTEM32 like we did during the Windows days.

> If you can think of any options which can be removed please indicate them and suggest their removal. Although I feel we've done a good job ensuring there are very few options I'd happily hear of on…

In theory "simple" respectively "full" requests could be viewed as flexibility but in reality it forces you to implement both in order to claim compliance.
I guess the upgraded AnyConnect client will take care of server preferences?

> I agree that K1 should also reference the type of key material being enrolled.

Isn't the bigger question then how to get it in the protocol?

Quite a bunch of PKIX enrollment protocols have acquired this ability
through proprietary protocol bootstrap schemes.  AFAIK none of the
protocols have it natively.  This was BTW one of the (numerous)
motivations behind KeyGen2; creating *true* interoperability.

> I think you are excessively combining the server authentication discussion (sections 5.2 and 4.3.1.1) and the distribution of CA certificates. 

That's quite possible.  I just read the text "as is".

> There is value in the "MUST" here because then the client has any possible CA key rollover certificates which might be necessary for chain building etc that might be encountered during the enrollme…

OK.

> Thanks for your feedback,

thanx,
Anders

---

From: Max Pritikin <[email-masked]>
Date: Wed, 4 Apr 2012 12:08:30 -0600

> dump arbitrary junk in SYSTEM32 like we did during the Windows days.

A general purpose bootstrapping system that works for a variety of solutions ranging from Anyconnect products to the Iphone is a great idea. I'd happily provide input on such a working group. EST within pkix is not the proper venue for those ideas though. 

For extensibility we did make it clear that additional functionalities could be support (at new URIs). Once you get a standard together for your bootstrapping ideas above we should be able to easily integrate with the EST extensibility. 

> In theory "simple" respectively "full" requests could be viewed as flexibility but in reality it forces you to implement both in order to claim compliance.

Multiple points in the document /fullCMC transport is indicated as optional. Although there is not a clear specification of the error code to respond with if it is not available. I'll add clarification.

> I guess the upgraded AnyConnect client will take care of server preferences?

I don't know anything about the AnyConnect team's product plans. 

Is there something about server preferences that you feel should be included in the EST protocol exchange?

> motivations behind KeyGen2; creating *true* interoperability.

This would be a lot easier if you would provide constructive feedback along the lines of suggesting improvements. As it is I'm trying to guess from your vague statement what you really want. Generally communication works better when both parties are straightforward and direct about what they are looking for.

If we added something like a "/enrollBootstrap" what sort of response are you envisioning? What would its mime-type be and is there an already existing format for the response that you have in mind? If there isn't such a thing what would serve this role?

For example would it be appropriate to have the server distribute an example pkcs10 with some of the fields already filled out? Is that the sort of thing you have in mind?

> That's quite possible.  I just read the text "as is".

If there is "as is" text that is confusing it would help if you reference the exact text. I'm and editor not a mind reader, Jim!

Thanks,

- max

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 05 Apr 2012 10:41:32 +0200

On 2012-04-04 20:08, Max Pritikin wrote:
> A general purpose bootstrapping system that works for a variety of solutions
> ranging from Anyconnect products to the Iphone is a great idea. I'd happily
> provide input on such a working group. EST within pkix is not the proper
> venue for those ideas though.

PKIX is indeed the wrong place for creating a new mainstream enrollment system
since all bootstrapping systems I have seen are based on XML.

Unfortunately none of "The big three" are interested in standardization efforts
regarding enrollment; they rather have, or are in the process of creating such
things on their own.  Given the lack of interest among SDOs, I think this is
the only reasonable decision.

In addition, I can hardly imagine Cisco and Checkpoint cooperating on VPM BYOD enrollment
so those who (like me) actually have to deploy stuff at customer sites probably gain
most by one of the big three coming out as winner although it will take a while.

Regards,
Anders

---

From: Tomas Gustavsson <[email-masked]>
Date: Thu, 05 Apr 2012 10:56:27 +0200

> most by one of the big three coming out as winner although it will take a while.

That's really painting a dark future. Those big ones have generally done 
a lot to make things harder for us techies, and indeed things are very 
hard today, much harder than it would have needed to be if they had 
cooperated in something like IETF.

Cheers,
Tomas

<snip>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 5 Apr 2012 14:44:33 +0300

> cooperated in something like IETF.

Who are these "big three" of which you speak?

Yoav

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 05 Apr 2012 18:11:59 +0200

> Who are these "big three" of which you speak?

Yoav,

It was I who mentioned "the big three".  They are also known as
Google, Apple and Microsoft.  Together they define 99% of our mobile
devices.  Most of these are out of reach for third-party enrollment
software.  Cisco's AnyConnect to take one example isn't possible
to install on a stock Android phones.

Since the big three nowadays rollout entire global ecosystems with everything
from devices to services, the motives for standardization are fewer than before.
The SDO camp haven't noticed this "paradigm shift", which probably requires
fundamentally different constellations in order to generate value.

A rather peculiar thing with standardization projects is that these unlike
other development activities, hardly ever are subject to interim reviews,
or have to revise the charter due to changes in the market.

The discussion around enrollment of PIN-protected credentials was extremely
silly. Have anybody heard about a bank credential *not* using PIN-codes?

Anders

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 10 Apr 2012 10:52:33 +0200

> cooperated in something like IETF.

Hi Tomas,

The problem is that there was never any money in strong authentication
software for consumers which is the reason why the market leader in
desktop OSes never bothered much about it.

In addition, it is (as we have seen on this very list), not particularly
easy discussing what such solutions should possibly do.  PIN-protected
credentials which is a standard feature for banks were considered as a
"strange" requirement by all but me.

Anyway, the new "Super Providers" Apple and Google do not only produce
devices (or OSes for devices), they are also heavily engaged in services
which means that they (in contrast to the 100 000 banks around the globe),
not only have the vehicles but also the *motives* needed for establishing
strong authentication solutions for consumers.

I think this is much more important than fixing the SSL PKI since even
if you login to "badbank.com" (through a mistake or through an active
attack), with a client-certificate, "badbank.com" will not be able to
reuse that login at "goodbank.com".

If the IETF is interested in participating in this space, I think they
need to come up with a plan, and that pretty soon as well!

Anders