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

From: Alexander Truskovsky <[email-masked]>
Date: Wed, 25 Apr 2012 22:34:36 +0000

Max,

I have been implementing the current SCEP draft, and have come across several issues that we are glad to see addressed in EST, specifically:

1) The use of a certificate issued by another PKI to authenticate the initial request is optional in SCEP.  This is now a MUST requirement in EST (A3).
2) The GetCACaps response is not signed in SCEP.  This is not a problem in EST because of the TLS use.
3) The SCEP draft mentions that RSA is the only algorithm supported by the current implementations.  Although there is no technical limitation that prevents the usage of ECC in SCEP and some implementations do support ECC, we are glad to see that algorithm agility is a MUST requirement in EST (K1).

EST is a specification we would also consider deploying.  There is an additional use case we would like to see supported by EST.  When renewing an email protection certificate, it cannot be used to authenticate the request using the TLS client authentication.  Although this can be achieved by using a full CMC operation, it would be better if it were handled by plain EST.  Wrapping the PKCS10 in PKCS7 and signing it with the email protection key would work without having to use a full CMC operation.

We think the use of TLS client authentication, although elegant, makes it inconvenient to use in some cases because a full CMC operation needs to be used.  We propose to continue using PKCS7 to wrap the PKCS10 to support this and similar use cases.

Thanks for your consideration,
   Alex

Alexander Truskovsky
BlackBerry OS Security | Research In Motion

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Max Pritikin <[email-masked]>
Date: Wed, 25 Apr 2012 17:19:39 -0600

Thank you for the feedback on EST (and SCEP). 

In regards for your request for EST functionality:

I agree that dealing with clients that can't use their certificates for digitalSignature is a problem -- but doesn't the same problem exist if the client's key usage is such that they shouldn't be signing PKCS7/CMS either? 

"CMC provides a method to prove the client's identity based on a client/server shared-secret" [RFC5272] ... but I don't believe it provides an exception to the problem you're discussing.

Is there general interest in finding another approach? I've hesitated to suggest an exception to the RFC5280 key usage restrictions but haven't been able to think of a different approach. 

Do you have any suggestions? It is very possible I'm missing something,

- max

---

From: Max Pritikin <[email-masked]>
Date: Wed, 25 Apr 2012 17:19:39 -0600

- max

---

From: Alexander Truskovsky <[email-masked]>
Date: Fri, 27 Apr 2012 13:46:23 +0000

Max,

You are correct, the same problem exists if CMS is used.  I think an exception to the RFC 5280 key usage restrictions is reasonable in the case of certificate renewal only.  When verifying certificates you have never seen before, I believe it is important to ensure the key usage is appropriate and EST should perform full certificate verification when authenticating the initial CSRs using certificates issued by another PKI.  In the case of certificate renewal the EST server will be verifying certificates that it issued, and I think ignoring the key usage here does not really degrade security.

We are interested in deploying a solution that will work for Client Authentication and Email Protection certificates (enrollment and renewal).  I don't think that mobile devices have the need to support enrollment for certificates with any other extended key usage.

I don't have any other suggestions right now.  Perhaps the TLS client authentication can still be used if it is more convenient to some clients and CMS can be used as a secondary option.  It is certainly easier to override the key usage warning in the EST server implementation when using CMS.

Regards,
Alex

-----Original Message-----
From: Max Pritikin [mailto:[email-masked]] 
Sent: Wednesday, April 25, 2012 7:20 PM
To: Alexander Truskovsky
Cc: [email-masked]; Matthew Campagna; Chris Bender
Subject: Re: Some comments on draft-ietf-pkix-est-01

- max