Subject: [wpkops] Web PKI - Trust Models

From: Bruce Morton <[email-masked]>
Date: Wed, 13 Mar 2013 16:08:02 +0000

Please find attached a draft of the Web PKI Trust Models document.

I plan to review the document in the meeting tomorrow. Iñigo and I would appreciate any comments on the document plan and the content.

Thanks,

Bruce Morton
+1 613.270.3743

---

From: "Ben Wilson" <[email-masked]>
Date: Wed, 13 Mar 2013 12:06:05 -0600

Here are some comments.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bruce Morton
Sent: Wednesday, March 13, 2013 10:08 AM
To: wpkops WG ([email-masked])
Subject: [wpkops] Web PKI - Trust Models

I plan to review the document in the meeting tomorrow. Iñigo and I would
appreciate any comments on the document plan and the content.

Thanks,

Bruce Morton

+1 613.270.3743

---

From: Michael Jenkins <[email-masked]>
Date: Wed, 13 Mar 2013 15:35:17 -0400

some other comments.

On Wed, Mar 13, 2013 at 2:06 PM, Ben Wilson <[email-masked]> wrote:

> Here are some comments.****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Bruce Morton
> *Sent:* Wednesday, March 13, 2013 10:08 AM
> *To:* wpkops WG ([email-masked])
> *Subject:* [wpkops] Web PKI - Trust Models****
>
> ** **
>
> Please find attached a draft of the Web PKI Trust Models document.****
>
> ** **
>
> appreciate any comments on the document plan and the content.****
>
> ** **
>
> Thanks,****
>
> ** **
>
> Bruce Morton****
>
> +1 613.270.3743****
>
> _______________________________________________
> wpkops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wpkops
>
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 13 Mar 2013 16:07:05 -0400

I reviewed just the definitions section, and it has a LOT of problems.

Comments on that section below.

Steve
------

1.2.  Definitions

Why are not all most of these terms taken from X.509 or RFC 5280, with
appropriate cites?

       Certificate: The public key of a user, together with some other
       information, rendered unforgeable by encipherment with the private
       key of the certification authority which issued it.

This is an RSA-centric view of how a signature is computed; it fails to 
describe how
a DSA-based sig is computed. Also, it ignores the use of a hash function 
as is common
ptractice.

       Certification Authority (CA) - An entity trusted by one or more
       users to create and assign certificates.

       Certificate holder - A natural or legal person who is identified
       as the subject in a certificate.
or a device, or organization, or ...

       Certificate policy: A named set of rules that indicates the
       applicability of a certificate to a particular community and/or
       class of application with common security requirements.
cite 3647?

       Certification Practice Statement (CPS): A statement of the
       practices that a Certification Authority employs in issuing,
       managing, revoking and renewing or re-keying certificates.
cite 3647?

       Certificate subject - The certificate holder as represented in the
       certificate.
the holder of the private key that corresponds to the public key in the 
cert.

       Certificate user - A natural person who operates a certificate
       using product.
relying party?

       Certificate-using product - A product that evaluates a certificate
       or certificate chain and adjusts its behavior according to the
       result.

       End entity: A certificate subject which uses its public key for
       purposes other than signing certificates.
since a public key IS never used to sign anything ...

       Intermediate CA - A CA that issues certificates to issuing CAs
       and/or other intermediate CAs.
this def will overlap with that of a TA, so not very useful.

       Issuing CA - A CA that issues certificates to certificate holders.
is there any other kind of CA?

Barreira & Morton          Expires May 4, 2013 [Page 3]

Internet-Draft         Trust models of the Web PKI          October 2012

       Policy management authority - A natural or legal person who
       administers the certificate policy by which one or more
       certification authorities operate.

       Public-key infrastructure (PKI) - is a system for the creation,
       storage, and distribution of certificates which are used to verify
       that a particular public key belongs to a certain entity.
not revocation too?

       Relying party: A user or agent that relies on the data in a
       certificate in making decisions.
decisions about what?

       Registration authority (RA): An entity that is responsible for
       identification and authentication of certificate subjects, but
       that does not sign or issue certificates (i.e., an RA is delegated
       certain tasks on behalf of a CA).

       Root certificate - is either an unsigned public key certificate or
       a self-signed certificate that identifies the Root Certificate
       Authority (CA).  A root certificate is part of a public key
       infrastructure scheme.
no mention of the relation to the more formal term, TA?

       Root CA - The trust anchor for a digital certificate is the Root
       Certificate Authority (CA).  A CA whose public key is included in
       a root store.

       Root store - A set of certification authority public keys that is
       embedded in a certificate-using product.
not just Root CA public keys?

       Self-signed certificate: A certificate for one CA signed by that
       CA.
we have expanded the def in PKIX to include certs signed by EEs, to more 
closely
match common practice. do you mean to exclude this case?

       Trust anchor - is an authoritative entity represented via a public
       key and associated data.
if the "authoritative" part were true, the problems faced by this model 
would
be much less severe :-). The problem is that almost none of the TAs embedded
in browsers are authoritative for the certs they issue!

       Trust model - The roles, and the relationships between those
       roles, that are relevant to the management and evaluation of
       certificates.

       Trust service - Service which enhances trust and confidence in
       electronic transactions.
vacuous def.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 Mar 2013 20:57:57 -0400

Steve Kent was faster than I was about posting some of the problems with the definitions. But he stopped there, so let me continue with the "basic trust model".

Just a reminder from our WG charter: The working group's goal is to describe how the Web PKI "actually" works in the set of browsers and servers that are in common use today.

Given that, I believe the following is fairly flawed.

   In the basic Web PKI trust model, a certificate-using product
   includes a root store that contains one or more root certification
   authority public keys, each of which is under the control of a CA and
   managed in conformance with the certificate policy prescribed and
   administered by the certificate using product supplier.  Each such
   root certification authority issues a certificate to one or more
   issuing CAs that are under the control of the same commercial CA.
   Each issuing CA accepts and responds to certificate requests from one
   or more certificate applicants via one or more registration
   authorities that are under the control of the same CA.  If the
   request is granted, then the certificate applicant becomes a
   certificate holder.  The role of the registration authority is to
   confirm the accuracy of the information provided in the certificate
   request.

- Some web browsers have a root store, but others use the OS's root store

- Some of these root stores have public keys associated with an enterprise; those keys are often not managed in conformance with anything

- "Commercial" is just plain wrong: many trust anchors are run by governments

- Many trust anchors in the root store issue end entity certificates directly

- Many trust anchors in the root store do not have registration authorities

In summary: this definition does not represent how the Web PKI actually works. The text that follows seems based on these assumptions, and thus has similar problems.

--Paul Hoffman