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

From: Sean Turner <[email-masked]>
Date: Tue, 27 Mar 2012 11:25:05 +0200

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

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 27 Mar 2012 12:49:33 +0200

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:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 28 Mar 2012 11:17:50 +0200

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.

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.".
Can /CACerts only return a single certificate? Kind of against the name, 
or can "trust anchor information" mean multiple independent certificate 
chains?

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

Regards,
Tomas