Subject: [wpkops] Trust Model

From: Bruce Morton <[email-masked]>
Date: Tue, 11 Jun 2013 17:09:52 +0000

The Trust Model document is available in draft, https://tools.ietf.org/html/draft-webpki-trustmodel-00.

Please provide comments and feedback as soon as possible. We would like to adopt or update this draft as the first WPKOPS working group draft by the end of June.

Please note that the draft was not named in accordance with the guidelines, but subsequent versions will be named correctly.

Thanks,

Bruce Morton

---

From: Tom Ritter <[email-masked]>
Date: Tue, 11 Jun 2013 19:31:16 -0400

Some thoughts on a first read-through:

each of which is under the control of a CA
    and managed in conformance with the certificate policy accepted by
    the certificate-using client supplier.

This confused the heck out of me on first read-through.  Also, in (2)
you say "certificate policy" meaning the policy created by the CA (I
think), in (2.1) you say "certificate policy" meaning the policy
created by the root store.  (At least, AFAICT)

The following graphic shows the
   relationship of the parties in the trust model.

There is no graphic.

"certificate-using client"

This seems to be used a lot - maybe we can define a term for this in
the beginning, e.g. "Client"

The root store provider stores and manages root
   certificates in its certificate-using client to support the trust
   model.

What trust model?  We're trying to define the trust model, did you
mean 'trust service'?

The root store provider determines how trust will be
   validated

It's not obvious to me what you mean by the noun 'trust' in this sentence.

The root CAs
   issue certificates for subordinate issuing CAs

It may be obvious, but perhaps we should specify here (and in the
following sentences) who signs whom?

The CA entity manages root, intermediate and issuing CAs in
   accordance with the certificate policy.  The CA entity operates the
   certificate issuance and management system in accordance with the
   certificate policy.  .

These sentences seem awkward because they have the same verb and
second half.  Also, stray period =)

   The CA entity operates a registration authority which authenticates
   requests for certificates in accordance with the certificate policy.

Which certificate policy?

Once the certificate request has been accepted,
   the subscriber will receive the certificate and will manage the
   certificate in accordance with the certificate policy.

Wait, now there's another certificate policy, this one applying to the
subscriber.

The relying party implicitly accepts the
   certificate policy by choosing to use a particular certificate-using
   client.

I guess technically they're implicitly accepting all three.... but the
ambiguity still bothers me.

 The certificate-using client does not use its own root store, but
   uses the root store managed by a separate root store provider.  The
   certificate-using client evaluates the subscriber's certificate and
   may check the certificate subject's domain name matches that
   requested by the subscriber.

The last sentence describes the checks done.  'evaluate' is super
ambiguous.  And nowhere does it say it actually uses the root store.
Obviously client behavior is all over the place, but I feel like there
should be a 'Usually, the client...'

As the cross-certified root CA is also recognized directly by
   the root store provider, it operates in accordance with the
   requirements of that certificate policy, regardless of any
   requirements placed upon it by the contract between it and the cross-
   certifying root CA.

This is another one of those "read it five times aloud slowly and I
think I got now" sentences. Also, I have no idea what those
requirements placed upon via contract might be.  Maybe an example
would help me?

-tom

---

From: "Rich Smith" <[email-masked]>
Date: Wed, 12 Jun 2013 09:29:23 -0400

In order to clarify many of Tom's points below, I suggest the following
terms/definitions:
Certificate Policy - The policy authored and followed by the Certificate
Authority
Trust Store Policy - The policy authored by the various Trust Store
operators governing CA certificate inclusion in their Trust Store
Subscriber Agreement - The terms and conditions placed upon the subscriber
of an end-entity certificate
Relying Party Agreement - The terms and conditions to which the relying
party/end-user either implicitly or explicitly agrees to when making use of
a particular end-entity certificate.

Regards,
Rich Smith
Validation Manager
Comodo

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tom Ritter
> Sent: Tuesday, June 11, 2013 7:31 PM
> To: Bruce Morton
> Cc: wpkops WG ([email-masked]) ([email-masked])
> Subject: Re: [wpkops] Trust Model
> 
> What trust model?  We're trying to define the trust model, did you mean
> 'trust service'?
> 
> These sentences seem awkward because they have the same verb and second
> half.  Also, stray period =)
> 
> requirements placed upon via contract might be.  Maybe an example would
> help me?
> 
> -tom
> _______________________________________________
> wpkops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wpkops

---

From: Chris Palmer <[email-masked]>
Date: Wed, 12 Jun 2013 14:30:41 -0700

> It's not obvious to me what you mean by the noun 'trust' in this sentence.

Agreed. I would say "...how trustworthiness will be established."

---

From: Bruce Morton <[email-masked]>
Date: Mon, 17 Jun 2013 18:12:14 +0000

Thank you for the feedback on the document.

If there are no objections, we will proceed with an update based on the following in this email.

There is some confusion about certificate policy. As such we can break this down into three items that may provide more clarification:

-          Root store policy - policy provided by the root store provider for the CA to follow

-          Certificate policy - policy developed by the CA which will incorporate applicable requirements for one or many root store policies

-          Subscriber agreement - agreement provided to the Subscriber which may include applicable requirements from the root store and the certificate policies. The definition will be taken from RFC 3647.

More responses to Tom's comments below.

Thanks, Bruce.

-----Original Message-----
From: Tom Ritter [mailto:[email-masked]]
Sent: Tuesday, June 11, 2013 7:31 PM
To: Bruce Morton
Cc: wpkops WG ([email-masked]) ([email-masked])
Subject: Re: [wpkops] Trust Model

[Bruce Morton] Will change the wording.

This confused the heck out of me on first read-through.  Also, in (2) you say "certificate policy" meaning the policy created by the CA (I think), in (2.1) you say "certificate policy" meaning the policy created by the root store.  (At least, AFAICT)

[Bruce Morton] Hopefully the changes above will clarify this item.

There is no graphic.

[Bruce Morton] Will have to understand how to include a graphic in the document. For now, the graphic and references will be removed.

This seems to be used a lot - maybe we can define a term for this in the beginning, e.g. "Client"

[Bruce Morton] I was trying to stay away from definitions and just use terms already accepted in RFC 5280. If this would help to clarify the Trust Model document, then it can be defined.

   model.

What trust model?  We're trying to define the trust model, did you mean 'trust service'?

[Bruce Morton] To avoid confusion, I will change this to 'the trust model' to 'trust'.

   validated

[Bruce Morton] Will change to 'how trustworthiness will be established' per Chris' suggestion.

The root CAs

It may be obvious, but perhaps we should specify here (and in the following sentences) who signs whom?

[Bruce Morton] Will change 'issue' to 'sign'.

   certificate policy.  .

These sentences seem awkward because they have the same verb and second half.  Also, stray period =)

[Bruce Morton] Will re-edit.

[Bruce Morton] This will be the certificate policy developed by the CA entity.

Wait, now there's another certificate policy, this one applying to the subscriber.

[Bruce Morton] We will change this to subscriber agreement.

   client.

I guess technically they're implicitly accepting all three.... but the ambiguity still bothers me.

[Bruce Morton] The relying party will implicitly accept the root store policy and the certificate policy.

The last sentence describes the checks done.  'evaluate' is super ambiguous.  And nowhere does it say it actually uses the root store.

Obviously client behavior is all over the place, but I feel like there should be a 'Usually, the client...'

[Bruce Morton] We can add  in 'Usually.'

   certifying root CA.

This is another one of those "read it five times aloud slowly and I think I got now" sentences. Also, I have no idea what those requirements placed upon via contract might be.  Maybe an example would help me?

[Bruce Morton] The point here is to say that the cross-certified root CA also directly follows then root store provider's certificate policy. I don't think an example of what would go in the contract is required here as we are saying the contract is not necessarily relevant.

-tom