Subject: [pkix] trust anchor management

From: zhipeng zhou <[email-masked]>
Date: Mon, 22 Feb 2010 22:28:02 +0800

Dear Chairs and all friends,
I was very happy that I had attended the last meeting in Japan and many thanks for your help on my presentation on "draft-zhipeng-pkix-drm-proxy-architecture".
While, I think I'd give some explainations on the purpose of this document and clarify what the problem is that is solved by this document.

When reviewing the charter of PKIX group, here blow is cited one paragraph:"
There is considerable interest in the PKI community to define a standard model for trust
  anchor management, and standard protocols to allow remote management.
  Thus a future work item for PKIX is the definition of such protocols
  and associated data models."

The key words in that part is "trust anchor management", right.

In fact, the problem that my document is towards is very obvious: if one entity wants to transfer the confidential information to the target entity via a third entity, meanwhile the third entity should be able to hold the plain information and hence can somehow monitor the information or take a proxy operation for the request, what method can be used to implement that scenario.
So, my draft has given the solution that a trust chain should be set up among these entities. To set up such a trust chain, a special certificate should be created and transferred to prove that one entity has authorized the proxy entity some rights for the special request.
So you can see, it is focusing on one implementation for trust anchor management.
And I feel such a trust relationship among three or more entities are exactly needed in security area, while my implementation in this draft is from DRM applications.
Hence, I will be very pleased to know from you that whether my understanding is accurate or not.
Also very welcome your kind recommendations.
Thanks very much.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 22 Feb 2010 13:17:45 -0500

At 10:28 PM +0800 2/22/10, zhipeng zhou wrote:
>I was very happy that I had attended the last meeting in Japan and 
>many thanks for your help on my presentation on 
>"draft-zhipeng-pkix-drm-proxy-architecture".
>While, I think I'd give some explainations on the purpose of this 
>document and clarify what the problem is that is solved by this 
>document.
>
>In fact, the problem that my document is towards is very obvious: if 
>one entity wants to transfer the confidential information to the 
>target entity via a third entity, meanwhile the third entity should 
>be able to hold the plain information and hence can somehow monitor 
>the information or take a proxy operation for the request, what 
>method can be used to implement that scenario.
>So, my draft has given the solution that a trust chain should be set 
>up among these entities. To set up such a trust chain, a special 
>certificate should be created and transferred to prove that one 
>entity has authorized the proxy entity some rights for the special 
>request.
>And I feel such a trust relationship among three or more entities 
>are exactly needed in security area, while my implementation in this 
>draft is from DRM applications.

The phrase "trust anchor" has a specific meaning in the PKI context, 
and it does not align precisely with the application  scenario you 
are describing. Thus your DRM document is still not suitable for PKIX.

Steve

---

From: zhipeng zhou <[email-masked]>
Date: Tue, 23 Feb 2010 11:43:12 +0800

Hi Steve, all,
Pls allow me add some explainations:
In fact,the core motivation of that document is to realize an inter-trust
among different entities. And this document should show a real application
for that requirement.By my knowledge, it is not a special requirement on a
speical application, so I am proposing for a general solution.
 
As for the "trust management", may we hold a flexible and scalable
understanding on the wording.
For example, may it be understood as "the trust relationship".
I know the PKIX group has developed many different and excellent issues that
are covered under the PKI system in the past years.  
Hence the idea to continue the PKI's promotion in my mind is consistent to
the target of the PKIX group.

Thanks for your consideration and welcome your kind experience sharing.
Zhipeng

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, February 23, 2010 2:18 AM
To: zhipeng zhou
Cc: [email-masked]
Subject: Re: [pkix] trust anchor management

At 10:28 PM +0800 2/22/10, zhipeng zhou wrote:
>I was very happy that I had attended the last meeting in Japan and many 
>thanks for your help on my presentation on 
>one entity wants to transfer the confidential information to the target 
>entity via a third entity, meanwhile the third entity should be able to 
>hold the plain information and hence can somehow monitor the 
>information or take a proxy operation for the request, what method can 
>be used to implement that scenario.
>So, my draft has given the solution that a trust chain should be set up 
>among these entities. To set up such a trust chain, a special 
>certificate should be created and transferred to prove that one entity 
>has authorized the proxy entity some rights for the special request.
>And I feel such a trust relationship among three or more entities are 
>exactly needed in security area, while my implementation in this draft 
>is from DRM applications.

The phrase "trust anchor" has a specific meaning in the PKI context, and it
does not align precisely with the application  scenario you are describing.
Thus your DRM document is still not suitable for PKIX.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Feb 2010 10:06:45 -0500

>speical application, so I am proposing for a general solution.

I have not seen a discussion of the general case in reading your 
material.  Perhaps you should try to reword the material to emphasize 
that.

>understanding on the wording.

no.  "flexible" meanings tend toward ambiguity. we try to avoid that.

>For example, may it be understood as "the trust relationship".

no. the term "trust anchor" is used in a well-defined, narrow fashion 
in RFC 5280, referring to the first cert in a chain used for path 
validation. It is defined in the recent PKIX documents dealing with 
TA management as a public key and associated data used to represent 
an authoritative entity for validation of certs or other signed 
objects.

Steve

---

From: zhipeng zhou <[email-masked]>
Date: Wed, 24 Feb 2010 11:24:32 +0800

Hi Stephen,
Very thanks for your guidance and I will try to take some restucture.
As for the term, in fact the key is not the "trust anchor" but the
"management".
Obviously the requirement is based on some service scenarios, it is in my
understanding accociated to the scenairo that involves multiple entities and
needs to verify the trust status or relationship of involved entities.
I like to follow your comments and keep my draft consistent with our group's
intent.
Thanks.
Zhipeng

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, February 23, 2010 11:07 PM
To: zhipeng zhou
Cc: [email-masked]
Subject: RE: [pkix] trust anchor management

At 11:43 AM +0800 2/23/10, zhipeng zhou wrote:
>In fact,the core motivation of that document is to realize an 
>inter-trust among different entities. And this document should show a 
>real application for that requirement.By my knowledge, it is not a 
>special requirement on a speical application, so I am proposing for a
general solution.

I have not seen a discussion of the general case in reading your material.
Perhaps you should try to reword the material to emphasize that.

>For example, may it be understood as "the trust relationship".

no. the term "trust anchor" is used in a well-defined, narrow fashion in RFC
5280, referring to the first cert in a chain used for path validation. It is
defined in the recent PKIX documents dealing with TA management as a public
key and associated data used to represent an authoritative entity for
validation of certs or other signed objects.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Feb 2010 09:30:17 -0500

>As for the term, in fact the key is not the "trust anchor" but the

OK.

>needs to verify the trust status or relationship of involved entities.

There are elements of TA management that address this concern. But, 
now that the WG has developed one standards track approach to 
providing such management, we will be reluctant to standardize other 
methods.

The document you wrote and the briefing you provided to the PKIX 
meeting focused on the DRM application. As Stefan noted, we don't 
tend to pursue application-specific PKI standards in PKIX. So, if 
your approach is DRM-focused, it is not appropriate for PKIX.  If it 
is generic, we would need to understand why we ought to pursue it, 
given the TAMP work.

Steve