Subject: [wpkops] ID on Trust model

From: "Ben Wilson" <[email-masked]>
Date: Thu, 3 Oct 2013 10:45:15 -0600

Bruce, Iñigo and Karen,

I recently reviewed your internet draft on Trust Model.  I agree with some
who have commented about the section on security considerations  -- it seems
it may open a Pandora’s Box of issues, considerations, etc. to be considered
and discussed—books could be written if they haven’t already.

I don’t know how best to scope or organize all of the content in the
security considerations area.  I certainly wouldn’t want to present the
trust model in 3-4 pages and then discuss all of the issues in another
300-400 pages.

Here are some additional suggestions:

Definition of  Root store – I think it should say, “a set of root
certificates embedded in a certificate-using client that anchors the
certificate chains of end entity certificates.”  (This definition cold go on
to explain this further, but I’m assuming that taking the minimalist
approach in the definitions is better because it raises less room for debate
about whether a particular implementation falls within the definition.)

I would replace this sentence with two sentences -  “The root store provider
determines how trustworthiness will be established and provides a trust
indication through its certificate-using client to the relying parties.”  

Suggested:  “The root store provider sets requirements for  inclusion of
root certificates in the root store and manages trust indications (i.e.
client behavior) for various certificate-related system behaviors and
environmental conditions.  These are communicated  through its
certificate-using client to relying parties.”  

By mentioning trust indicators, client behavior, etc. for system behavior
and environmental conditions we are providing context that leads into the
work of the others in this working group who will discuss these topics.  

In the section discussing hierarchy, here is a sample diagram to help (I
hope these pipes come through OK):
                                        +---------+
                  + -----------| Root CA |---------+
                  |                    +---------+              |
           +-----------------+                               |
         | Intermediate CA |-----+                 |
           +-----------------+            |                 |
                  |                                 |                |
                  v                                 v                v
              +---------+      +---------+       +---------+
             | Issuing |      | Issuing |       | Issuing |
         +--|   CA    |-+    |   CA     |---+ |     CA     |------+
         |  +---------+ |    +---------+   |  +---------+          |
         |         |          |           |            |         |        |
|
         v         v          v           v           v          v        v
v
      +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
      | EE | | EE | | EE | | EE | | EE | | EE | | EE | | EE |
      +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+

Finally, in section 3.2, I think it helps to explain how each model is
different than the preceding one.

So, in 3.2.2, it would say " Unlike the situation in section 3.2.1, the
subordinate issuing CA is not recognized independently by any direct
relationship with  the root store provider."

In 3.2.3 you might say, "Unlike the situation presented in section 3.2.2,
the third party registration authority is not identified in a CA certificate
as an issuing CA."  

And in 3.2.6, you might say, "This is also sometimes referred to as an
enterprise subordinate CA, however the difference between this arrangement
and that described in section 3.2.5 is that the entity operating the root CA
has immediate operational control of the CA and physical possession of the
CA private key."

Cheers,
Ben

---

From: Chris Palmer <[email-masked]>
Date: Thu, 3 Oct 2013 11:03:26 -0700

> about whether a particular implementation falls within the definition.)

I think it's better to say "trust anchor store" and "trust anchor"
instead of, specifically, "root". (Throughout.)

---

From: "Ben Wilson" <[email-masked]>
Date: Thu, 3 Oct 2013 14:00:20 -0600

What about this?

Key store – an application’s collection of keys and certificates that may also identify the purposes for which they may be used, including the root certificate and associated public key that the application may use as a trust anchor.

Key store governance policy – the policy adopted by a key store manager that sets forth rules governing the key store, including requirements for root CAs and subordinate components and entities, such as keys, certificates, subordinate CAs, and registration  authorities.

Root CA – a CA with a self-signed certificate and whose public key is included as a trust anchor in a key store.

-----Original Message-----
From: Chris Palmer [mailto:[email-masked]] 
Sent: Thursday, October 03, 2013 12:03 PM
To: Benjamin T. Wilson
Cc: Bruce Morton; Iñigo Barreira; Karen O'Donoghue; [email-masked]
Subject: Re: [wpkops] ID on Trust model

On Thu, Oct 3, 2013 at 9:45 AM, Ben Wilson <[email-masked]> wrote:

> certificate chains of end entity certificates.”  (This definition cold 
> go on to explain this further, but I’m assuming that taking the 
> minimalist approach in the definitions is better because it raises 
> less room for debate about whether a particular implementation falls 
> within the definition.)

---

From: Stephen Kent <[email-masked]>
Date: Mon, 07 Oct 2013 09:46:50 -0400

Ben,
> Key store – an application’s collection of keys and certificates that may also identify the purposes for which they may be used, including the root certificate and associated public key that the ap…
A trust anchor is defined as a public key and optional, associated data, 
so the definition
above is not quite right. I suggest removing all use of the term "root" 
in this doc, to
avoid confusion.
> Key store governance policy – the policy adopted by a key store manager that sets forth rules governing the key store, including requirements for root CAs and subordinate components and entities, s…
again, kill "root CA" and replace it with "trust anchor."
> Root CA – a CA with a self-signed certificate and whose public key is included as a trust anchor in a key store.
see comments above re the problem with this definition.

Steve

---

From: Bruce Morton <[email-masked]>
Date: Mon, 7 Oct 2013 16:56:43 +0000

We are trying to get a draft prepared to help with discussion at the next IETF meeting.

If you don't mind, we would like to table these comments until the draft is released and address this and other items through the mail list.

Please let us know if this is an issue.

Thanks, Bruce.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, October 07, 2013 9:47 AM
To: [email-masked]
Cc: 'Chris Palmer'; 'Iñigo Barreira'; Bruce Morton; [email-masked]; 'Karen O'Donoghue'
Subject: Re: [wpkops] ID on Trust model

Ben,
> What about this?
>
> Key store - an application's collection of keys and certificates that may also identify the purposes for which they may be used, including the root certificate and associated public key that the application may use as a trust anchor.
A trust anchor is defined as a public key and optional, associated data, so the definition above is not quite right. I suggest removing all use of the term "root" 
in this doc, to
avoid confusion.
> Key store governance policy - the policy adopted by a key store manager that sets forth rules governing the key store, including requirements for root CAs and subordinate components and entities, such as keys, certificates, subordinate CAs, and registration  authorities.
> Root CA - a CA with a self-signed certificate and whose public key is included as a trust anchor in a key store.

Steve