Subject: [pkix] EST trust anchor definition

From: M Jenkins <[email-masked]>
Date: Mon, 19 Nov 2012 15:24:11 -0500

I think that the current EST draft is weak when it comes to talking 
about trust anchors. Many of the right ideas are there, but a bit 
scattered about. Figure (Table) 3 has a lot of this information, but 
there's some fuzz in it, and it's not very explicit about how crucial TA 
initialization is to the security of the protocol.

A specific concern is a perception that *any* trust anchor that happens 
to be in a trust anchor store might be used to terminate a certificate 
validation chain. The use of the phrase "third party Trust Anchor 
Database" is worrisome. Who cares if the TA comes from any (acceptable) 
third party - if you can't ensure that your validation chain is going to 
terminate in that TA in the first place? The present state of TA store 
management doesn't inherently provide this selectability. I think that 
explicit text is needed here.

I would suggest that table in Figure 3 be replaced with something like 
the following:

Trust Anchors
+--------------------------------------------------------------+
| NOTE: EST Servers and Clients must be initialized to know    |
|       which specific public keys in their trust anchor       |
|       stores correspond to which function from this table.   |
+---------------+----------------------------------------------+
| CA Root       | * End of validation path of all CA certs     |
|  public key   | * End of validation path of Device Cert      |
|               | * May be identical to EST Server TA          |
|               | * May be identical to EST Client TA
|               | * Obtainable by /CACerts command             |
+---------------+----------------------------------------------+
| EST Server TA | * End of validation path of EST Server cert  |
|               | * Must be securely installed to EST Client   |
|               | * Must be obtained securely, out-of-band     |
+---------------+----------------------------------------------+
| EST Client TA | * End of valid. path of EST Client init cert |
|               | * Must be securely installed to EST Server   |
|               | * Must be obtained securely, out-of-band     |
+---------------+----------------------------------------------+

Certificates
+---------------+----------------------------------------------+
| CA Signing    | * Crsp. private key signs Device Cert        |
|  Certificate  | * Intermediate CA certs may exist in path    |
|               | * Obtainable by /CACerts command             |
|               | * Must be validated against CA Root
+---------------+----------------------------------------------+
| EST Server    | * Used by EST Client during TLS handshake    |
|  Certificate  | * Must be validated against EST Server TA    |
+---------------+----------------------------------------------+
| EST Client    | * Used by EST Server during initial enroll   |
|  Init Cert    |    (if certificate TLS auth used)            |
|               | * Must be validated against EST Client TA
+---------------+----------------------------------------------+
| Device Cert   | * Any certificate returned as a result of    |
|               |    /simpleEnroll, /simpleReEnroll, /fullCMC, |
|               |    or /serverKeyGen                          |
|               | * May be used for subsequent EST sessions    |
+---------------+----------------------------------------------+
| NOTE: The CA, EST Server, EST Client, and other servers may  |
|       have other certificates for other purposes, including  |
|       inter-server communication during EST sessions.        |
+--------------------------------------------------------------+

Mike

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Mon, 19 Nov 2012 20:56:54 +0000

Thanks for all the feedback. We've already updated the table similar to what you recommend below so its good to see we're on the same page.

Below is the current table in our working copy. I'll read through your suggestions carefully to see if additional clarity can be gained.

Similarly I'll go through you other email of specific feedback and merge them to the revisions we've made since the ietf85 meeting.

- max

Current table in our working revision (best viewed in monospaced font):

   Certificates and their corresponding uses:
   +--------------+--------------------+-------------------------------+
   | Certificate  | Issuer             | Use and section references    |
   +==============+====================+===============================+
   | EST server   | The CA served by   | Presented by the EST server   |
   | certificate  | the EST server     | during the TLS handshake      |
   |              |                    |                               |
   |              |                    | Section 3.3.1.1               |
   +--------------+--------------------+-------------------------------+
   | EST server   | A CA               | Presented by the EST server   |
   | certificate  | authenticatable by | during the TLS handshake      |
   |              | a third-party TA   |                               |
   |              |                    | Section 3.3.1.1, and          |
   |              |                    | Security Considerations       |
   +--------------+--------------------+-------------------------------+
   | EST client   | A CA               | Presented by the EST client   |
   | certificate  | authenticatable by | to the EST server by clients  |
   |              | a third-party TA   | that have not yet enrolled    |
   |              | e.g., a device     |                               |
   |              | manufacturer       | Section 3.3.1.2               |
   +--------------+--------------------+-------------------------------+
   | EST client   | The CA served by   | Presented by the EST client   |
   | certificate  | the EST server     | to PKI End Entities.          |
   |              |                    | Including to the EST server   |
   |              |                    | during future EST operations  |
   |              |                    |                               |
   |              |                    | Section 3.3.1.2               |
   +--------------+--------------------+-------------------------------+
   | EST client   | The CA served by   | Presented by the EST client   |
   | certificate  | the EST server     | to PKI End Entities.          |
   |              |                    | Clients can obtain certs      |
   |              |                    | that can not be used for EST  |
   |              |                    | client authentication         |
   |              |                    |                               |
   |              |                    | Section 4.4.1                 |
   +--------------+--------------------+-------------------------------+

                                 Figure 3

Pritikin, et al.          Expires May 21, 2013                 [Page 12]
Internet-Draft                     EST                     November 2012

   Trust Anchor databases and their corresponding uses:
   +--------------+----------------------------------------------------+
   | TA database  | Use and section references                         |
   +==============+====================================================+
   | EST server   | EST servers use this TA database to authenticate   |
   | TA database  | certificates issued by the CA, including EST       |
   |              | client certificates during enroll/re-enroll        |
   |              | operations                                         |
   |              |                                                    |
   |              | Section 3.3.1.2                                    |
   +--------------+----------------------------------------------------+
   | EST server   | EST servers use this TA database to authenticate   |
   | Third-Party  | certificates issued by third-party TAs.            |
   | TA database  | e.g., EST client certificates issued by a device   |
   |              | manufacturer                                       |
   |              |                                                    |
   |              | Section 3.3.1.2                                    |
   +--------------+----------------------------------------------------+
   | EST client   | EST clients use this TA database to authenticate   |
   | EST CA       | certificates issued by the EST CA, including EST   |
   | TA database  | server certificates.                               |
   |              |                                                    |
   |              | Section 3.3.1.1 and                                |
   |              | Section 4.3                                        |
   +--------------+----------------------------------------------------+
   | EST client   | EST clients use this trust anchor database to      |
   | Third-Party  | authenticate an EST server that uses an externally |
   | TA database  | issued certificate.                                |
   |              |                                                    |
   |              |                                                    |
   |              | Section 3.3.1.1 and                                |
   |              | Security Considerations                            |
   +--------------+----------------------------------------------------+

                                 Figure 4

On Nov 19, 2012, at 1:24 PM, M Jenkins <[email-masked]<mailto:[email-masked]>>
 wrote:

I think that the current EST draft is weak when it comes to talking about trust anchors. Many of the right ideas are there, but a bit scattered about. Figure (Table) 3 has a lot of this information, but there's some fuzz in it, and it's not very explicit about how crucial TA initialization is to the security of the protocol.

A specific concern is a perception that *any* trust anchor that happens to be in a trust anchor store might be used to terminate a certificate validation chain. The use of the phrase "third party Trust Anchor Database" is worrisome. Who cares if the TA comes from any (acceptable) third party - if you can't ensure that your validation chain is going to terminate in that TA in the first place? The present state of TA store management doesn't inherently provide this selectability. I think that explicit text is needed here.

I would suggest that table in Figure 3 be replaced with something like the following:

Trust Anchors

Certificates

Mike