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

[Anders Rundgren <[e-mail]>]

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.

> 
>>
>>  "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.
I guess the upgraded AnyConnect client will take care of server preferences?

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

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

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