Subject: [pkix] Welcome comments.

From: zhipeng zhou <[email-masked]>
Date: Tue, 09 Mar 2010 21:55:27 +0800

Dear all,
I have drafted a new version of my document.
I am a little sorry that I miss the date for uploading the I-D, so just send
it as the attachment in this email.
You can see I like to move the DRM example in the appendix.
Welcome your comments and I can imcorporate them in next version.
Thanks.
Zhipeng

-----------------------------------------------------

Huawei Software Technologies Co.,Ltd.

Floor 2, Building A, NO.48，Ning Nan AV.,Nanjing, P.R.of China
Zipcode:210012
E-Mail:  <mailto:[email-masked]> [email-masked]
Phone:(+86) 25-82276771
Fax:(+86) 25-82276760

Mobile:(+86) 13404162849
-----------------------------------------------------

****************************************************************************
***********************************
　　本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或
群组。禁止任何其他人以任何形式使用

（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。

    如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
****************************************************************************
***********************************

****************************************************************************
***********************************
    This e-mail and its attachments contain confidential information from
HUAWEI, which is intended only for the

person or entity whose address is listed above. Any use of the information
contained herein in any way(including,

but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended

recipient(s) is prohibited. 

    If you receive this e-mail in error, please notify the sender by phone
or email immediately and delete it!
****************************************************************************
***********************************

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Mar 2010 13:39:04 -0500

Zhipeng,

I have not read most of your new document, but when I began reviewing 
the text in section one I did have some observations/questions:

	You use banking as a motivating example, but I question this 
example.  In general a payee (e.g., the electric utility) wants only 
to be paid and will accept payment from any source that successfully 
effects a transfer of funds. Thus there is no need for the payee to 
verify that the bank has been authorized by the client. The fact that 
a bank asserts that it is paying the payee on behalf of the client 
suffices. In the U.S. (and Europe?) it is common to effect e-payments 
directly from a bank, without using a proxy of any sort.  In the U.S. 
there is a company called CheckFree that effects bill payment for 
many folks, via Quicken software. In general I can instruct my bank 
(online) to allow a 3rd party to make withdrawals. So, I don't see a 
need for any proxy function here.

The home network server example is also not one that motivates (for 
me) the use of PKI proxies.  If the intent is for the home gateway to 
be the only machine  (in the customer premises) authorized to 
request services, then make it be the only machine holding the 
credentials to do so. don't put these credentials in other machines. 
Because the device in question is the home gateway, all of the other 
devices (behind it) MUST go through it to request services, so the 
gateway is in an ideal position to mediate such requests. It may act 
as a proxy in that respect, from a protocol perspective, but that 
does not imply that it needs to act as a PKI proxy per se. Again, 
this example does not provide suitable motivation (in my eyes) for a 
PKI proxy. Perhaps a different description of this problem would 
provide better motivation, but so far it odes not.

Later text in Section 1 says: "In the proxy service, to verify the 
service subscription or service acquisition, the Service Provider 
(Service Server) SHOULD verify the trusted relationship between the 
request device and the proxy device."  If by "trusted relationship" 
you mean that the requesting device has authorized to act on behalf 
of other credential holders just say so.  The wording here is 
ambiguous, at best. Also note that authorization delegation was 
already explored in RFC 3820 (a standards track PKIX RFC), so any 
other proposals for such delegation have to show why the mechanisms 
defined there are inadequate.

Steve

---

From: zhipeng zhou <[email-masked]>
Date: Mon, 15 Mar 2010 17:33:08 +0800

Steve,
Thanks for your kind comments.Pls see my rough understanding below inline.
Thanks and welcome further comments. 
Zhipeng

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Saturday, March 13, 2010 2:39 AM
To: zhipeng zhou
Cc: 'pkix'
Subject: Re: [pkix] Welcome comments.

Zhipeng,

I have not read most of your new document, but when I began reviewing the
text in section one I did have some observations/questions:

	You use banking as a motivating example, but I question this
example.  In general a payee (e.g., the electric utility) wants only to be
paid and will accept payment from any source that successfully effects a
transfer of funds. Thus there is no need for the payee to verify that the
bank has been authorized by the client. The fact that a bank asserts that it
is paying the payee on behalf of the client suffices. In the U.S. (and
Europe?) it is common to effect e-payments directly from a bank, without
using a proxy of any sort.  In the U.S. 
there is a company called CheckFree that effects bill payment for many
folks, via Quicken software. In general I can instruct my bank
(online) to allow a 3rd party to make withdrawals. So, I don't see a need
for any proxy function here.

//zhipeng: I do not support the sentence that "Thus there is no need for the
payee to verify that the bank has been authorized by the client. " since in
the business each deal should be recorded correctly and can be checked by
the relavant goverments(e.g. the tax ministry,  or the security ministry for
"washing money").
Similarly for the bank, it should also keep all the records correct and
consistent in case for the  query or check by the clients or the goverment.
If the bank has transfer some money from the client's account to another
business unit's account, it should have the proof that the operation is
instructed by the user, i.e. the bank has owned the authority before the
operation.
It is very common now that the bank support the e-payment while the bank
should have the authority of the clients. In China, by my experience, the
client should go to the bank branch and sign a contract with the bank (as
the authority to the bank and the payee).//

The home network server example is also not one that motivates (for
me) the use of PKI proxies.  If the intent is for the home gateway to be the
only machine  (in the customer premises) authorized to request services,
then make it be the only machine holding the credentials to do so. don't put
these credentials in other machines. 
Because the device in question is the home gateway, all of the other devices
(behind it) MUST go through it to request services, so the gateway is in an
ideal position to mediate such requests. It may act as a proxy in that
respect, from a protocol perspective, but that does not imply that it needs
to act as a PKI proxy per se. Again, this example does not provide suitable
motivation (in my eyes) for a PKI proxy. Perhaps a different description of
this problem would provide better motivation, but so far it odes not.

//zhipeng: As for the case in Home Network, it can be used to constraint the
conduct of the requesting device. It is like the "parent mechnism"
Provided the gateway is controlled by the parent, only the parent can open
and operate the gateway, the parent can configure that only the limited
service request from the home device(children device) can be accepted by the
gatway.
Another possiblity is that, if the client only has a  authorized device  got
from the SP, it can assign any gateway to do the proxy work. that will be
very convenient to the clients. For example the client can assign a SP's
server to get some service when the client's device is not ON.//

Later text in Section 1 says: "In the proxy service, to verify the service
subscription or service acquisition, the Service Provider (Service Server)
SHOULD verify the trusted relationship between the request device and the
proxy device."  If by "trusted relationship" 
you mean that the requesting device has authorized to act on behalf of other
credential holders just say so.  The wording here is ambiguous, at best.
Also note that authorization delegation was already explored in RFC 3820 (a
standards track PKIX RFC), so any other proposals for such delegation have
to show why the mechanisms defined there are inadequate.

//zhipeng: my meaning is that all the three entities should be aware the
proxy relationship clearly, i.e. which entity has authorized which entity to
apply for what service.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Mar 2010 07:38:03 -0800

It is pretty clear that this discussion is not about PKIX, but about differing views of how various industries are supposed to use PKIX certificates. It doesn't seem fruitful here.

---

From: zhipeng zhou <[email-masked]>
Date: Tue, 16 Mar 2010 09:24:16 +0800

Not exactly,Paul.
It is to cover the trust among three entities under the PKI system, hence it
is to "support X.509-based Public Key Infrastructures (PKIs)" .
Since this draft has proposed a new certificate( authorization document), it
is somehow the extension of PKIX certificate.
 Thanks.
Zhipeng

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Monday, March 15, 2010 11:38 PM
To: zhipeng zhou; 'Stephen Kent'
Cc: 'pkix'
Subject: Re: [pkix] Welcome comments.

It is pretty clear that this discussion is not about PKIX, but about
differing views of how various industries are supposed to use PKIX
certificates. It doesn't seem fruitful here.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Mar 2010 10:28:21 -0400

Zhipeng,

An "authorization document" is not, per se, a cert. An obvious 
example of a signed object that confers authorization that is not 
cert is the Route Origination Authorization (ROA).

This example is important because it illustrates several principles:
	- it is an authorization object for use with a PKI, but it is 
not a cert
	- it was developed in the SIDR WG, not in PKIX
	- it is application-specific

I am not convinced that it makes sense to try to develop a totally 
generic authorization document format. Application-specific 
authorization objects, even if they are used in conjunction with to a 
PKI, are best developed in WGs that are developing the applications 
where the objects will be used.

Steve

---

From: zhipeng zhou <[email-masked]>
Date: Wed, 17 Mar 2010 09:37:43 +0800

Hi Steve,
Thanks for your kind reminding, I have taken a view at the ROA. Here I like
to address that I am not focusing on a specific application.
My intent is to clarify the requirement and solution to set up a fully
transparent trust relationship among multiple entities.
So I believe it is a general description and is a common foundation for
differnt services.
Somehow, this concept is like the feature as "Non-Repudiation" and etc. I
mean it is popular and basic.
As for  the specific application, it is not needed to be constrained.  
As for the term 'cert', I am not sure whether we can think it as a cert
issued by a user to another.Anyway, it is a kind a document for legitimate
verfication.
Totally, this document is giving a model for this kind of problem and
requirement.
Hence it can be extended on specific applications.
Thanks.
Zhipeng

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, March 16, 2010 10:28 PM
To: zhipeng zhou
Cc: 'Paul Hoffman'; 'pkix'
Subject: Re: [pkix] Welcome comments.

At 9:24 AM +0800 3/16/10, zhipeng zhou wrote:
>  Not exactly,Paul.
>It is to cover the trust among three entities under the PKI system, 
>hence it is to "support X.509-based Public Key Infrastructures (PKIs)" .
>Since this draft has proposed a new certificate( authorization 
>document), it is somehow the extension of PKIX certificate.
>  Thanks.
>Zhipeng
>

Zhipeng,

An "authorization document" is not, per se, a cert. An obvious example of a
signed object that confers authorization that is not cert is the Route
Origination Authorization (ROA).

This example is important because it illustrates several principles:
	- it is an authorization object for use with a PKI, but it is not a
cert
	- it was developed in the SIDR WG, not in PKIX
	- it is application-specific

I am not convinced that it makes sense to try to develop a totally generic
authorization document format. Application-specific authorization objects,
even if they are used in conjunction with to a PKI, are best developed in
WGs that are developing the applications where the objects will be used.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Mar 2010 16:45:25 -0400

>transparent trust relationship among multiple entities.

Try to be clear on you goals.  You recently talked about 
authorization.  That is a reasonably well-understood, technical goal. 
The  phrase "trust relationship among multiple entities" is vague.

>mean it is popular and basic.

Bad choice for an analogy :-). Non-repudiaition is an example of a 
security service that relates to legal issues and about which we 
never seem to reach consensus.

>issued by a user to another.Anyway, it is a kind a document for legitimate

We have two forms of certs in our standards: PKCs ad ACs. I don't 
think we have seen an argument for another type of cert. A signed 
object (document) is a not a cert, per se.  Again, try to avoid use 
of vague, technically imprecise terms.

>Totally, this document is giving a model for this kind of problem and

In a general authorization model, there is not a universal need for 
the sort of protocol you cite in your document in sections 3 & 4. The 
holder of rights (authorizations) can issue a capability (e.g., an 
AC) to a intermediary (e.g., a proxy) conferring a subset of these 
rights to the intermediary. Later the intermediary interacts with a 
service provider (target) and needs to express the rights conferred 
to it, e.g., to effect an operation on behalf of the rights holder. 
The intermediary presents the capability and demonstrates that the 
capability is bound to the intermediary, and that convinces the 
service provider to provide the service to the intermediary, on 
behalf of the rights holder.

That is one way to authorize a proxy to act on behalf of a user, 
making  use of existing standards. You have spoken of a general 
authorization approach, but you failed to show why what we can 
already do is inadequate. The ROA example I cited illustrates that 
specific application contexts may choose to use other approaches to 
granting authorization in a PKI context. In this case there was no 
need for a proxy, and so the solution does not entail that model. I 
think the important lesson here is that different application 
contexts can and will adopt different approaches to managing 
authorization data. There is no indication that we need a universal 
solution, nor is there are indication that the model presented in 
your document is an example of such a solution.

Steve

---

From: zhipeng zhou <[email-masked]>
Date: Thu, 18 Mar 2010 12:06:20 +0800

Steve, 
With regards to your comments, I can understand that we should pursue the
simple and clear description.
Via our discussions, the best thing is that we can confirm the service flow
is concise enough and hence we move our focus on the possible solutions.
As for the possible value of this work, may we believe that extracting the
general model of this kind of problems and giving the general solution model
is good for different services. For example, does any service need to give a
work respectively, or just give some an extension in a common base for each
service. I believe the latter choice is efficient for the industry. And can
be the benefit for the PKIX group.
Thanks.
Zhipeng

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Thursday, March 18, 2010 4:45 AM
To: zhipeng zhou
Cc: 'pkix'
Subject: RE: [pkix] Welcome comments.

At 9:37 AM +0800 3/17/10, zhipeng zhou wrote:
>Hi Steve,
>Thanks for your kind reminding, I have taken a view at the ROA. Here I 
>like to address that I am not focusing on a specific application.

Try to be clear on you goals.  You recently talked about authorization.
That is a reasonably well-understood, technical goal. 
The  phrase "trust relationship among multiple entities" is vague.

>Somehow, this concept is like the feature as "Non-Repudiation" and etc. 
>I mean it is popular and basic.

Bad choice for an analogy :-). Non-repudiaition is an example of a security
service that relates to legal issues and about which we never seem to reach
consensus.

>issued by a user to another.Anyway, it is a kind a document for 
>legitimate verfication.

We have two forms of certs in our standards: PKCs ad ACs. I don't think we
have seen an argument for another type of cert. A signed object (document)
is a not a cert, per se.  Again, try to avoid use of vague, technically
imprecise terms.

>Totally, this document is giving a model for this kind of problem and 

In a general authorization model, there is not a universal need for the sort
of protocol you cite in your document in sections 3 & 4. The holder of
rights (authorizations) can issue a capability (e.g., an
AC) to a intermediary (e.g., a proxy) conferring a subset of these rights to
the intermediary. Later the intermediary interacts with a service provider
(target) and needs to express the rights conferred to it, e.g., to effect an
operation on behalf of the rights holder. 
The intermediary presents the capability and demonstrates that the
capability is bound to the intermediary, and that convinces the service
provider to provide the service to the intermediary, on behalf of the rights
holder.

That is one way to authorize a proxy to act on behalf of a user, making  use
of existing standards. You have spoken of a general authorization approach,
but you failed to show why what we can already do is inadequate. The ROA
example I cited illustrates that specific application contexts may choose to
use other approaches to granting authorization in a PKI context. In this
case there was no need for a proxy, and so the solution does not entail that
model. I think the important lesson here is that different application
contexts can and will adopt different approaches to managing authorization
data. There is no indication that we need a universal solution, nor is there
are indication that the model presented in your document is an example of
such a solution.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 18 Mar 2010 11:52:30 -0400

>be the benefit for the PKIX group.

Sorry, but I don't really understand the arguments you made above, 
and the word "believe" appears too often :-).

You need to address the specific issues in my message before any 
progress can be made.

Steve