[hiprg] 答复: comments on draft-irtf-hiprg-revocation-02.txt

"Dacheng Zhang(Dacheng)" <zhangdacheng@huawei.com> Mon, 28 March 2011 16:19 UTC

Return-Path: <zhangdacheng@huawei.com>
X-Original-To: hiprg@core3.amsl.com
Delivered-To: hiprg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51C5B3A6A63 for <hiprg@core3.amsl.com>; Mon, 28 Mar 2011 09:19:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.923
X-Spam-Level:
X-Spam-Status: No, score=0.923 tagged_above=-999 required=5 tests=[AWL=-2.676, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_SUB_ENC_GB2312=1.345, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrOiHulYAtND for <hiprg@core3.amsl.com>; Mon, 28 Mar 2011 09:19:36 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9F3A33A6892 for <hiprg@irtf.org>; Mon, 28 Mar 2011 09:19:34 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIS00NH502Z2W@szxga04-in.huawei.com> for hiprg@irtf.org; Tue, 29 Mar 2011 00:20:59 +0800 (CST)
Received: from szxeml204-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIS00GPR02Z1P@szxga04-in.huawei.com> for hiprg@irtf.org; Tue, 29 Mar 2011 00:20:59 +0800 (CST)
Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml204-edg.china.huawei.com (172.24.2.56) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 29 Mar 2011 00:20:56 +0800
Received: from SZXEML501-MBX.china.huawei.com ([169.254.5.242]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Tue, 29 Mar 2011 00:20:58 +0800
Date: Mon, 28 Mar 2011 16:20:58 +0000
From: "Dacheng Zhang(Dacheng)" <zhangdacheng@huawei.com>
In-reply-to: <7CC566635CFE364D87DC5803D4712A6C4CED25B071@XCH-NW-10V.nw.nos.boeing.com>
X-Originating-IP: [172.24.2.41]
To: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>, "'dmitriy.kuptsov@hiit.fi'" <dmitriy.kuptsov@hiit.fi>, "shenshuo@cnnic.cn" <shenshuo@cnnic.cn>
Message-id: <C72CBD9FE3CA604887B1B3F1D145D05E7DC5C4@szxeml501-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-language: zh-CN
Content-transfer-encoding: 7BIT
Accept-Language: zh-CN, en-US
Thread-topic: comments on draft-irtf-hiprg-revocation-02.txt
Thread-index: AcvtUgr0JPTQnn+KSBOKCovcRAefjgAEHR4o
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
References: <7CC566635CFE364D87DC5803D4712A6C4CED25B071@XCH-NW-10V.nw.nos.boeing.com>
Cc: "hiprg@irtf.org" <hiprg@irtf.org>
Subject: [hiprg] =?gb2312?b?ILTwuLQ6IGNvbW1lbnRzIG9uIGRyYWZ0LWlydGYtaGlw?= =?gb2312?b?cmctcmV2b2NhdGlvbi0wMi50eHQ=?=
X-BeenThere: hiprg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <hiprg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/hiprg>
List-Post: <mailto:hiprg@irtf.org>
List-Help: <mailto:hiprg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Mar 2011 16:19:41 -0000

Thanks a lot, Tom. Please see the inline please.

>>Here are some comments on the latest version of your document.  I think that the draft could be improved by more careful definition of and distinction between the host identity and host identifier (see RFC4423), and to summarize  more >>clearly (in the introduction) the main issues that this draft is concerned with:

>>1) what does it mean for two or more different hosts to have the same host identifier?  Here there are two cases:  1a) there is a trusted third party who can resolve this, and 1b) there is no such arbitrator

>>2) what does it mean for one host to have multiple host identifiers associated with the same host identity; can these be associated together and can they be expired or deprecated similar to how locators are deprecated?

Will update it!

>>I think that the draft has some clear solutions for some of the above questions but less clear for others, so it would be useful to also summarize in section 1 which of the questions are well answered and which will require further study.

>>It is time to start filling in the terminology section more fully (Section 2).
Agree and will do it.

>>Where you say in Section 5:  "Until now, the ID to Locator mapping solution in HIP has not been standardized yet.  We argue that it is desired to integrate the implicit key revocation functionality into such systems."  I would suggest to >>clarify that you are not talking about DNS here but instead about something like the DHT lookup.

DNS is a "Locator to ID " mapping solution. Yes, when I mention "ID to Locator" mapping solution, I indicate the DHT solution.

>>In section 6 paragraph 2, I did not understand how this case could handle the situation when the reason to remove the HI was due to key compromise-- perhaps clarify this point here.

This paragraph introduce the CRL solution in PKI. I just try to indicate that when a HI is removed, the revocation information can be put a trusted third party for other interested hosts to query. Will update it!

>>In section 8, the end of this section ends prematurely.  The paragraph that starts "Because the HI of a HIP host acts as both the identity and the public key of the HIP host at the same time." does not contain complete sentences and has >>some of the terminology problems that I mentioned above.

Will update it!

>>In section 10 (Security considerations), I think you need to start filling it out, rather than the blanket statement that you have there.  Perhaps a way to start is to review this RFC:  http://www.ietf.org/rfc/rfc3552.txt

Will update it!

- Tom