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

Continuing this thread...

>From the abstract I would be interested in hearing what

 "simple Public Key Infrastructure clients"

actually refer to.

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

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

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

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
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
> 