Subject: Re: [pkix] EST trust anchor definition

From: Michael Jenkins <[email-masked]>
Date: Tue, 4 Dec 2012 23:55:16 -0500

I think that the tables, broken out according to TAs and Certs, are a big
improvement. However, the TA table has really taken a hard turn /away/ from
the ability to specify a single TA as the one to use for EST. Without
digging through a lot of cert guts over and over, I'll never know if any
particular validation is terminating in the selected TA, be it a provided
vendor-supplied initialization root, or a "public" CA, or a locally
supplied root. I'm not prejudiced toward one or the other of those options,
as long as it's the one I've initially configured - that is, as long as I
have a way of expressing which TA must terminate my EST transactions.

Ideally that would happen through some kind of labeling, but I don't think
that there's anything that does that now, natively, in a system trust
anchor store. Other solutions would be to remove all trust anchors /except/
the selected one (drastic, but might work for some specific-use devices),
or to configure the EST client app with a keyID for the selected trust
anchor (and then check that it's the one used).

The draft does say that the client needs to be configured with the correct
trust anchor (through out-of-band means), but after that all references to
TAs are "TA Database". If I can't guarantee that I'm using the TA that I
configured, there was no point in configuring one.

Hope that makes sense. If I'm interpreting the table incorrectly, let me
know where I went wrong.

Mike

On Mon, Nov 19, 2012 at 3:56 PM, Max Pritikin (pritikin) <[email-masked]
> wrote:

>  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]>
>  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
> +--------------------------------------------------------------+
> | 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: Wed, 5 Dec 2012 22:50:58 +0000

On Dec 4, 2012, at 9:55 PM, Michael Jenkins <[email-masked]> wrote:

> I think that the tables, broken out according to TAs and Certs, are a big improvement. However, the TA table has really taken a hard turn /away/ from the ability to specify a single TA as the one to use for EST.

What prevents the client from having a "Third-Party TA Database" that contains only TA's (or a single TA) to be used for EST?

> Without digging through a lot of cert guts over and over, I'll never know if any particular validation is terminating in the selected TA, be it a provided vendor-supplied initialization root, or a "public" CA, or a locally supplied root. I'm not prejudiced toward one or the other of those options, as long as it's the one I've initially configured - that is, as long as I have a way of expressing which TA must terminate my EST transactions.
> 
> Ideally that would happen through some kind of labeling, but I don't think that there's anything that does that now, natively, in a system trust anchor store. Other solutions would be to remove all trust anchors /except/ the selected one (drastic, but might work for some specific-use devices), or to configure the EST client app with a keyID for the selected trust anchor (and then check that it's the one used).
> 
> The draft does say that the client needs to be configured with the correct trust anchor (through out-of-band means), but after that all references to TAs are "TA Database". If I can't guarantee that I'm using the TA that I configured, there was no point in configuring one.

We can make this the "selected TA Database" and we can indicate that:

"The Client MUST support a configurable option to enable checking all or
a subset of either the EST client Third-Party TA database or the EST
client TA database."

Would that address your concerns?

- max

> 
> Hope that makes sense. If I'm interpreting the table incorrectly, let me know where I went wrong.
> 
> Mike
> 
> 
> On Mon, Nov 19, 2012 at 3:56 PM, Max Pritikin (pritikin) <[email-masked]> wrote:
> 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
> 
>> 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

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 5 Dec 2012 22:52:27 +0000

(I corrected Peter Yee's email address)

---

From: Michael Jenkins <[email-masked]>
Date: Thu, 6 Dec 2012 11:13:48 -0500

I suppose that helps - but it's more wordy and less clear, and therefore
more prone to error. It's not that the system supporting the EST client
can't have a TA database - I'm assuming it will. It's that the database is
irrelevant to the protocol. I don't unlock the lock on my front door with a
keyring, I do it with a key. Whether I only have one key, or whether I have
100, and whether I keep my 100 on a ring or in a box, is irrelevant.

Crucially, I have to make sure the wrong thing doesn't happen. Say that I
have a key to my neighbor's house. I want to enter my house. If my
neighbor's house and mine look alike, and I walk up to his house by
mistake, and I "use my keyring" to unlock the lock on the door - it works!
Which is unfortunate for me, because his rabid dog just bit my leg.

The problem I'm having with "TA Database" is that such databases are
generally designed to make things work, not to make things work only in
certain circumstances, as defined by the operator or local admin. It's no
accident that most consumer systems come with a laundry-list of trust
anchors, and there generally isn't any notification to the operator that
any particular one was used during any particular transaction.

Saying "use the TA Database" requires me to think up all of the ways that
applying the entire database to my protocol might fail, and say how to
prevent them. Saying "use only the XYZ trust anchor" is much more clear and
precise. How to ensure that that particular trust anchor gets used is up to
the system designer - which is a good thing, because I don't think it's
desired that EST be limited to any one particular type of client system.

On Wed, Dec 5, 2012 at 5:52 PM, Max Pritikin (pritikin)
<[email-masked]>wrote:

> >> I think that the tables, broken out according to TAs and Certs, are a
> big improvement. However, the TA table has really taken a hard turn /away/
> from the ability to specify a single TA as the one to use for EST.
> >
> > What prevents the client from having a "Third-Party TA Database" that
> contains only TA's (or a single TA) to be used for EST?
> >
> >> Without digging through a lot of cert guts over and over, I'll never
> know if any particular validation is terminating in the selected TA, be it
> a provided vendor-supplied initialization root, or a "public" CA, or a
> locally supplied root. I'm not prejudiced toward one or the other of those
> options, as long as it's the one I've initially configured - that is, as
> long as I have a way of expressing which TA must terminate my EST
> transactions.
> >>
> >> Ideally that would happen through some kind of labeling, but I don't
> think that there's anything that does that now, natively, in a system trust
> >> The draft does say that the client needs to be configured with the
> correct trust anchor (through out-of-band means), but after that all
> references to TAs are "TA Database". If I can't guarantee that I'm using
> the TA that I configured, there was no point in configuring one.
> >
> >> 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
> >>
> >>> 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
> >>> 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.
> >>>

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 6 Dec 2012 10:01:42 -0800 (PST)

Hello,

  Perhaps I'm missing something but the "selected TA database" is allowing
the client to verify the trustworthiness of the EST server's certificate. The
client is still supposed to decide whether this is the _correct_ EST
server by
checking the contents of the certificate against whatever policy might
be configured as well as performing the TLS handshake and ensuring
that the EST server holds the private analog to the authenticated public
key it now holds.

  To stretch your analogy, the "selected TA database" is allowing you to
determine whether this is a bonafide Schlage deadbolt lock that you're
looking at. Whether it's _your_ bonafide Schlage deadbolt lock is the
next step you have to do by putting your key into the lock and seeing
whether it opens the door. If your neighbor's rabid dog bites you then
it's a sign that 2 keys open the same door which is a failure of a different
kind.

  Dan.

On Thu, December 6, 2012 8:13 am, Michael Jenkins wrote:
>> |
>> >>   |              |                    | Section 3.3.1.1
>> |
>> >>   |              | a third-party TA   |
>> |
>> >>   |              | e.g., a device     |
>> |
>> |
>> >>   |              |                    | Section 3.3.1.2
>> |
>> |
>> >>   |              |                    | Section 4.4.1
>> |
>> >>   |              | operations
>> |
>> >>   |              |
>> |
>> >>   |              | Section 3.3.1.2
>> |
>> >>   |              | manufacturer
>> |
>> >>   |              |
>> |
>> >>   |              | Section 3.3.1.2
>> |
>> >>   |              |
>> |
>> >>   |              | Section 3.3.1.1 and
>> |
>> >>   |              | Section 4.3
>> |
>> >>   |              |
>> |
>> >>   |              |
>> |
>> >>   |              | Section 3.3.1.1 and
>> |
>> >>> I would suggest that table in Figure 3 be replaced with something
>> like
>> the following:
>> >>>
>> >>> Trust Anchors

---

From: M Jenkins <[email-masked]>
Date: Tue, 11 Dec 2012 08:57:51 -0500

Sorry, hadn't noticed that I didn't send this to the list.

Hi Dan. I'm concerned that the client can trust the contents of the cert 
(know that it has validated the correct cert) before it starts using the 
contents to check the server name. Likewise for the server, if the 
client has been initialized with an "enrollment certificate" (say by the 
vendor; the trust anchor would be provided by the vendor separately to 
the EST server operator).

On 12/06/2012 01:01 PM, Dan Harkins wrote:
>>> On Dec 5, 2012, at 3:50 PM, Max Pritikin<[email-masked]>  wrote:
>>>
>>>> On Dec 4, 2012, at 9:55 PM, Michael Jenkins<[email-masked]>  wrote:
>>>>
>>>>> On Mon, Nov 19, 2012 at 3:56 PM, Max Pritikin (pritikin)<
>>> [email-masked]>  wrote:
>>>>> On Nov 19, 2012, at 1:24 PM, M Jenkins<[email-masked]>
>>>>> wrote:
>>>>>

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 11 Dec 2012 12:00:10 -0800

I agree with you that some of the details about how the client trusts the
server certificate are irrelevant to the protocol.
I think that the draft should just specify the attributes of a trustworthy
server certificate and leave the details of how that trustworthiness is
determined to the client implementation.

Whether it is done using local TA database, a local TA certificate or by
sending the request to a DPV server is irrelevant.

There may be scenarios where client may want to apply different server
certificate validation policy depending on which EST server it is talking to
(Getting a personal certificate from a public CA vs. getting a VPN client
certificate from the enterprise. Bundling both the public CA root and the
enterprise CA root in the same TA database should not be done in this case.

-Piyush
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> M Jenkins
> Sent: Tuesday, December 11, 2012 5:58 AM
> Cc: [email-masked]
> Subject: Re: [pkix] EST trust anchor definition
> 
(know
> that it has validated the correct cert) before it starts using the
contents to
> check the server name. Likewise for the server, if the client has been
> initialized with an "enrollment certificate" (say by the vendor; the trust
> anchor would be provided by the vendor separately to the EST server
> operator).
> 
> >    Perhaps I'm missing something but the "selected TA database" is
> > allowing the client to verify the trustworthiness of the EST server's
> > certificate. The client is still supposed to decide whether this is
> > the _correct_ EST server by checking the contents of the certificate
> > against whatever policy might be configured as well as performing the
> > TLS handshake and ensuring that the EST server holds the private
> > analog to the authenticated public key it now holds.
> >
> >    To stretch your analogy, the "selected TA database" is allowing you
> > to determine whether this is a bonafide Schlage deadbolt lock that
> > you're looking at. Whether it's _your_ bonafide Schlage deadbolt lock
> > is the next step you have to do by putting your key into the lock and
> > seeing whether it opens the door. If your neighbor's rabid dog bites
> > you then it's a sign that 2 keys open the same door which is a failure
> > of a different kind.
> >
> >    Dan.
> >
> >> I suppose that helps - but it's more wordy and less clear, and
> >> therefore more prone to error. It's not that the system supporting
> >> the EST client can't have a TA database - I'm assuming it will. It's
> >> that the database is irrelevant to the protocol. I don't unlock the
> >> lock on my front door with a keyring, I do it with a key. Whether I
> >> only have one key, or whether I have 100, and whether I keep my 100
> >> on a ring or in a box, is irrelevant.
> >>
> >> Crucially, I have to make sure the wrong thing doesn't happen. Say
> >> that I have a key to my neighbor's house. I want to enter my house.
> >> If my neighbor's house and mine look alike, and I walk up to his
> >> house by mistake, and I "use my keyring" to unlock the lock on the door
-
> it works!
> >> generally designed to make things work, not to make things work only
> >> in certain circumstances, as defined by the operator or local admin.
> >> It's no accident that most consumer systems come with a laundry-list
> >> of trust anchors, and there generally isn't any notification to the
> >> operator that any particular one was used during any particular
> transaction.
> >>
> >> Saying "use the TA Database" requires me to think up all of the ways
> >> that applying the entire database to my protocol might fail, and say
> >> how to prevent them. Saying "use only the XYZ trust anchor" is much
> >> more clear and precise. How to ensure that that particular trust
> >> anchor gets used is up to the system designer - which is a good
> >> thing, because I don't think it's desired that EST be limited to any
> >> one particular type of client system.
> >>
> >>
> >>> big improvement. However, the TA table has really taken a hard turn
> >>> /away/ from the ability to specify a single TA as the one to use for
> >>> EST.
> >>> know if any particular validation is terminating in the selected TA,
> >>> be it a provided vendor-supplied initialization root, or a "public"
> >>> CA, or a locally supplied root. I'm not prejudiced toward one or the
> >>> other of those options, as long as it's the one I've initially
> >>> configured - that is, as long as I have a way of expressing which TA
> >>> must terminate my EST transactions.
> >>> think that there's anything that does that now, natively, in a
> >>> system trust anchor store. Other solutions would be to remove all
> >>> trust anchors /except/ the selected one (drastic, but might work for
> >>> some specific-use devices), or to configure the EST client app with
> >>> a keyID for the selected trust anchor (and then check that it's the
> >>> one used).
> >>> references to TAs are "TA Database". If I can't guarantee that I'm
> >>> using the TA that I configured, there was no point in configuring one.
> >>>> "The Client MUST support a configurable option to enable checking
> >>>> all
> >>> or
> >>>> a subset of either the EST client Third-Party TA database or the
> >>>> EST client TA database."
> >>>>
> >>>>> Hope that makes sense. If I'm interpreting the table incorrectly,
> >>>>> let
> >>> me know where I went wrong.
> >>>>> Mike
> >>>>>
> >>>>>
> >>>>> Thanks for all the feedback. We've already updated the table
> >>>>> similar
> >>> to
> >>>>>    | certificate  | authenticatable by | to the EST server by
> >>>>> clients
> >>> |
> >>>>>    |              |                    | during future EST
operations
> >>>>>    |              |                    | that can not be used for
EST
> >>>>>    | TA database  | e.g., EST client certificates issued by a
> >>>>> device
> >>> |
> >>>>>    |              | manufacturer
> >>> |
> >>>>>    |              |
> >>> |
> >>>>>    |              | Section 3.3.1.2
> >>> |
> >>>>>
> >>>>>    | Third-Party  | authenticate an EST server that uses an
> >>>>> externally
> >>> |
> >>> 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.
> >>> 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.
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix