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

[Max Pritikin <[e-mail]>]

On Apr 3, 2012, at 7:45 AM, Anders Rundgren wrote:

> On 2012-04-03 01:48, Max Pritikin wrote:
>> 
>> 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. 
> 
> 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.

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. 

>>> "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. 
> 
> 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?

>>> "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.
> 
> 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.

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?

>>> "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. 
> 
> 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

>> 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). 
> 
> OK.
> 
>> 
>>> 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,
> 
> thanx,
> Anders
> 
>> 
>> - 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/pkix
>>>> 
>>> 
>>> _______________________________________________
>>> pkix mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/pkix
>> 
>> 
>