Subject: [pkix] Using "CMC Simple PKI Response" rather than "certificate" (was: Re: some comments on draft-ietf-pkix-est-01)

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

(I've updated the subject on this thread)

My thoughts on this have not solidified yet. A couple of initial questions,

a) this requires the server to build and sign this response. Coding that is relatively simple with off the shelf libraries but it will require additional ASN1 and crypto operations that are effectively ignored. Is this then an effective use of server (and client!) resources?

b) Should the signature on this PKCS#7 be ignored? What if the CA has moved on to a new key? How does it know to use an old key for this signing? 

c) The Simple PKI Response section 4.1 [RFC5272] includes a variety of "MAY" statements (options!). If we move in this direction would there be support for profiling these to a more restrictive set of options? For each of the following statements from paragraph 2 I'm thinking:

 "Servers SHOULD include all intermediate certificates needed to form complete certification paths to one or more trust anchors, not just the newly issued certificate(s)."
Change to MUST NOT. 
Justification: this is not a trust anchor management protocol, thus this type of flexibility isn't warranted here. 

"The server MAY additionally return CRLs in the CRL bag."
Change to MUST NOT.
Justification: This is not a CRL distribution protocol, thus the best the server can do is provide a CRL appropriate for this client's certificate at this point in time which is of minimal use. Also not including anything specific to the client allows the PKCS#7 to be pre-generated for /CACerts.

"Servers MAY include the self-signed certificates."
(I"m assuming this means including its own self-signed certificate?)
Change to MUST (and add "In addition the Root CA Key Update certificates SHOULD be included.").
Justification: The CA certs MUST be included for /CACerts so make them always included (reducing options). This would allow clients to skip calling /CACerts for re-enroll since they'd always receive any new CA certs in the response.  

"In the event clients receive a new self-signed certificate from the server, clients SHOULD provide a mechanism to enable the user to use the certificate as a trust anchor"
Change to MUST (and make this automatic). 
Justification: Although not doing general trust anchor management we want to make sure CA key renewal works seamlessly. 

Thanks for continued discussion,

- max

On Mar 28, 2012, at 3:04 AM, Dan Harkins wrote:

> 
>  Hi,
> 
> On Tue, 27 Mar 2012 at 11:25:05 Sean Turner said:
>> 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.
> 
>  Yes, I see value in reusing the PKCS#10/PKCS#7 model. EST is supposed
> to implement "simple CMC" and that should use a PKCS#7 as the simple
> response.
> 
>  regards,
> 
>  Dan.
> 
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 4 Apr 2012 10:40:55 -0700 (PDT)

Hi Max,

On Mon, April 2, 2012 5:34 pm, Max Pritikin wrote:
> a) this requires the server to build and sign this response. Coding that
> is relatively simple with off the shelf libraries but it will require
> additional ASN1 and crypto operations that are effectively ignored. Is
> this then an effective use of server (and client!) resources?

  I don't think the building will be ignored. The server can deliver
the client's certificate and the CA certificate in one nice package.
Regarding the additional crypto operations, given the other resource use
necessary to execute this protocol I think it's noise. And this is
something of a one-off protocol too.

> b) Should the signature on this PKCS#7 be ignored? What if the CA has
> moved on to a new key? How does it know to use an old key for this
> signing?

  Yes, I believe it's ignored.

> c) The Simple PKI Response section 4.1 [RFC5272] includes a variety of
> "MAY" statements (options!). If we move in this direction would there be
> support for profiling these to a more restrictive set of options? For each
> of the following statements from paragraph 2 I'm thinking:
>
>  "Servers SHOULD include all intermediate certificates needed to form
> complete certification paths to one or more trust anchors, not just the
> newly issued certificate(s)."
> Change to MUST NOT.
> Justification: this is not a trust anchor management protocol, thus this
> type of flexibility isn't warranted here.

  I agree that this isn't a "trust anchor management protocol" but for
the protocol to be generally useful it would really help for the client
to have all the intermediate certificates it needs to form a complete
certification path.

  You're talking about an absolute prohibition on providing useful
information. That just doesn't sound right. SHOULD sounds fine.

> Justification: This is not a CRL distribution protocol, thus the best the
> server can do is provide a CRL appropriate for this client's certificate
> at this point in time which is of minimal use. Also not including anything
> specific to the client allows the PKCS#7 to be pre-generated for /CACerts.

  MAY means "[o]ne vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that it
enhances the product...." Seems like it would be an enhancement to
provide more useful information if the market deems it necessary or
a vendor believes it enhances his product.

  Again, you're talking about an absolute prohibition on providing
useful information. You think this is of minimal use. Fine. The text
that follows  the ellipses above is "while another vendor may omit the
same item." You may omit a CRL because you feel it is of minimal use.

> Justification: The CA certs MUST be included for /CACerts so make them
> always included (reducing options). This would allow clients to skip
> calling /CACerts for re-enroll since they'd always receive any new CA
> certs in the response.
>
> "In the event clients receive a new self-signed certificate from the
> server, clients SHOULD provide a mechanism to enable the user to use the
> certificate as a trust anchor"
> Justification: Although not doing general trust anchor management we want
> to make sure CA key renewal works seamlessly.
>

  And thank you!

  Dan.

---

From: Sean Turner <[email-masked]>
Date: Fri, 06 Apr 2012 09:34:38 -0400

> something of a one-off protocol too.

There's no signature on a certs-only message.  There's no signerInfo, 
which is where the signatures would go.  See 3.6 of RFC 2311.

Get two certs in pem format (cert1.pem and cert2.pem) and use openssl:

openssl crl2pkcs7 -nocrl -certfile cert1.pem -certfile cert2.pem -out p7.pem

My MacBook has OpenSSL 0.9.8r 8 Feb 2011.

>    Yes, I believe it's ignored.

See previous answer.

> information. That just doesn't sound right. SHOULD sounds fine.

Max - I like the way you think, but somebody will argue that MUST NOT in 
this case would be against Sec 6 of 2119.  It's not an interop issue or 
put another way what bad thing will happen if they do include it?

> same item." You may omit a CRL because you feel it is of minimal use.

See previous answer.

>> calling /CACerts for re-enroll since they'd always receive any new CA

I think SHOULD would be better here.  And, the reason is that 
self-signed certificates aren't always the TA format - granted it's 
likely the format 99.99999% of the time.  See Sec 3 of RFC 5914.  SHOULD 
means do this unless you got a really, really good reason not to.  The 
only reason I could think of is that you used on of the other two 
options in 5914.

>> to make sure CA key renewal works seamlessly.

See previous answer.

spt