From nobody Fri Oct 2 03:15:53 2015 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19691A1B59 for ; Fri, 2 Oct 2015 03:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfXqqQhvpMbi for ; Fri, 2 Oct 2015 03:15:50 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5251A1AFB for ; Fri, 2 Oct 2015 03:15:49 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-fd-560e5953a0ca Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 81.9B.05274.3595E065; Fri, 2 Oct 2015 12:15:48 +0200 (CEST) Received: from [131.160.36.127] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.248.2; Fri, 2 Oct 2015 12:15:47 +0200 References: <20150922105852.742.47701.idtracker@ietfa.amsl.com> From: Gonzalo Camarillo To: Samu Varjonen Message-ID: <560E5953.90002@ericsson.com> Date: Fri, 2 Oct 2015 13:15:47 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150922105852.742.47701.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUyM+JvjW5IJF+YwarJHBZTF01mtrjxcwa7 A5NH/8r97B5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4cX4iY8FplYrmjVvZGxgPynQxcnJICJhI 7FpziB3CFpO4cG89WxcjF4eQwFFGiU3f5jFBOKsZJebdvMYEUiUs4Cyx8tFjNhBbSMBeYvvk eUA2BwezgKjE9llVIGE2AQuJLbfus4DYIgK6Eivu7GAFsXkFNCU6f78GG8MioCJxffFGsDGi AjESPb82sEHUCEqcnPkErJdTwEHi15y1zCA2s4CBxJFFc1ghbHmJ7W/nMEOcoC2x/FkLywRG wVlI2mchaZmFpGUBI/MqRtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMBwPbjlt+oOxstvHA8x CnAwKvHwKjzlDRNiTSwrrsw9xCjNwaIkztvM9CBUSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dU A2N4wvKu7splb3srtaa2O4jf62FwWD2xaU1LZV/irM7Oh6lfF3ttO6z9+kFyJ+/qtJvzN31/ HsAwWzH9/3WFrQ0K9yZca7b9mP2xzUNz75QNPwzlNONuHvqwonzq5ZM+HRFfZxit8o+fOGsr 9+dQhv232qaHztr+5HNRKOOs2zVSyU+j5l4wvLZMiaU4I9FQi7moOBEASXN1kDgCAAA= Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-rfc6253-bis-04.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 10:15:52 -0000 Hi Samu, thanks for revising the draft. There are still a few things that need to be fixed before I can request its publication. From the output of the nits tool: https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-hip-rfc6253-bis-04.txt > -- The abstract seems to indicate that this document obsoletes RFC6253, but > the header doesn't have an 'Obsoletes:' line to match this. You need to add an Obsoletes: header to the header part at the beginning of the draft. Additionally, you also need to add an Updates header as follows: Obsoletes: 6253 Updates: 7401 Note that the original RFC updated RFC 5201 and, thus, had an Updates header: https://tools.ietf.org/html/rfc6253 > == The document seems to contain a disclaimer for pre-RFC5378 work, but was > first submitted on or after 10 November 2008. The disclaimer is usually > necessary only for documents that revise or obsolete older RFCs, and that > take significant amounts of text from those RFCs. If you can contact all > authors of the source material and they are willing to grant the BCP78 > rights to the IETF Trust, you can and should remove the disclaimer. > Otherwise, the disclaimer is needed and you can ignore this comment. > (See the Legal Provisions document at > http://trustee.ietf.org/license-info for more information.) You are the same authors as in the original RFC. Do you both agree to remove the disclaimer? > == Unused Reference: 'RFC4843' is defined on line 349, but no explicit > reference was found in the text Does this reference need to be removed or used somewhere in the text? > ** Downref: Normative reference to an Experimental RFC: RFC 2693 RFC 6232bis is intended to be a Proposed Standard. Can we reference a Standards Track RFC instead of this one? Otherwise, we will need to talk with our AD so make sure it is OK to normatively reference an Experimental RFC. > ** Obsolete normative reference: RFC 4843 (Obsoleted by RFC 7343) > ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Could you please update the two references above? > ** Downref: Normative reference to an Experimental RFC: RFC 6253 This downref is obviously OK... but what about making it an Informational reference instead? Could you please revise the draft addressing all the comments above? Thanks, Gonzalo On 22/09/2015 1:58 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Host Identity Protocol Working Group of the IETF. > > Title : Host Identity Protocol Certificates > Authors : Tobias Heer > Samu Varjonen > Filename : draft-ietf-hip-rfc6253-bis-04.txt > Pages : 11 > Date : 2015-09-22 > > Abstract: > The Certificate (CERT) parameter is a container for digital > certificates. It is used for carrying these certificates in Host > Identity Protocol (HIP) control packets. This document specifies the > certificate parameter and the error signaling in case of a failed > verification. Additionally, this document specifies the > representations of Host Identity Tags in X.509 version 3 (v3) and > Simple Public Key Infrastructure (SPKI) certificates. > > The concrete use cases of certificates, including how certificates > are obtained, requested, and which actions are taken upon successful > or failed verification, are specific to the scenario in which the > certificates are used. Hence, the definition of these scenario- > specific aspects is left to the documents that use the CERT > parameter. > > This document extends RFC7401 and obsoletes RFC6253. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-hip-rfc6253-bis-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc6253-bis-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From nobody Mon Oct 12 01:59:12 2015 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0241A9145 for ; Mon, 12 Oct 2015 01:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K93kbZjOXa2Z for ; Mon, 12 Oct 2015 01:59:08 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 402731A9136 for ; Mon, 12 Oct 2015 01:59:07 -0700 (PDT) Received: from [128.214.10.115] (hpf-7.cs.helsinki.fi [128.214.10.115]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id t9C8x3Q9028545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 12 Oct 2015 11:59:04 +0300 To: Gonzalo Camarillo References: <20150922105852.742.47701.idtracker@ietfa.amsl.com> <560E5953.90002@ericsson.com> From: Samu Varjonen Message-ID: <561B7657.4020004@helsinki.fi> Date: Mon, 12 Oct 2015 11:59:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <560E5953.90002@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-rfc6253-bis-04.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 08:59:11 -0000 Hi Gonzalo & all, all but one of the nits are easily fixed. The one downref to RFC2693 is the only harder one as I do not think it will ever proceed to anything more than experimental. The work on RFC 2693 stopped in 1999. Over 114 papers have been written about it since. Even few this year but all point to that experimental RFC. Moreover, it seems (in my opinion) that currently there is little or no interest in continuing SPKI work nor there is any interest in the industry to implement SPKI as it basically provides the functionality of X509v3 with different syntax. One option would be to remove the examples and mentions about SPKI in the RFC6253bis. What do you guys think? BR, Samu Varjonen On 02/10/15 13:15, Gonzalo Camarillo wrote: > Hi Samu, > > thanks for revising the draft. There are still a few things that need to > be fixed before I can request its publication. From the output of the > nits tool: > > https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-hip-rfc6253-bis-04.txt > >> -- The abstract seems to indicate that this document obsoletes RFC6253, but >> the header doesn't have an 'Obsoletes:' line to match this. > You need to add an Obsoletes: header to the header part at the beginning > of the draft. Additionally, you also need to add an Updates header as > follows: > > Obsoletes: 6253 > Updates: 7401 > > Note that the original RFC updated RFC 5201 and, thus, had an Updates > header: > > https://tools.ietf.org/html/rfc6253 > >> == The document seems to contain a disclaimer for pre-RFC5378 work, but was >> first submitted on or after 10 November 2008. The disclaimer is usually >> necessary only for documents that revise or obsolete older RFCs, and that >> take significant amounts of text from those RFCs. If you can contact all >> authors of the source material and they are willing to grant the BCP78 >> rights to the IETF Trust, you can and should remove the disclaimer. >> Otherwise, the disclaimer is needed and you can ignore this comment. >> (See the Legal Provisions document at >> http://trustee.ietf.org/license-info for more information.) > You are the same authors as in the original RFC. Do you both agree to > remove the disclaimer? > >> == Unused Reference: 'RFC4843' is defined on line 349, but no explicit >> reference was found in the text > Does this reference need to be removed or used somewhere in the text? > >> ** Downref: Normative reference to an Experimental RFC: RFC 2693 > RFC 6232bis is intended to be a Proposed Standard. Can we reference a > Standards Track RFC instead of this one? Otherwise, we will need to talk > with our AD so make sure it is OK to normatively reference an > Experimental RFC. > >> ** Obsolete normative reference: RFC 4843 (Obsoleted by RFC 7343) >> ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) > Could you please update the two references above? > >> ** Downref: Normative reference to an Experimental RFC: RFC 6253 > This downref is obviously OK... but what about making it an > Informational reference instead? > > Could you please revise the draft addressing all the comments above? > > Thanks, > > Gonzalo > > > On 22/09/2015 1:58 PM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Host Identity Protocol Working Group of the IETF. >> >> Title : Host Identity Protocol Certificates >> Authors : Tobias Heer >> Samu Varjonen >> Filename : draft-ietf-hip-rfc6253-bis-04.txt >> Pages : 11 >> Date : 2015-09-22 >> >> Abstract: >> The Certificate (CERT) parameter is a container for digital >> certificates. It is used for carrying these certificates in Host >> Identity Protocol (HIP) control packets. This document specifies the >> certificate parameter and the error signaling in case of a failed >> verification. Additionally, this document specifies the >> representations of Host Identity Tags in X.509 version 3 (v3) and >> Simple Public Key Infrastructure (SPKI) certificates. >> >> The concrete use cases of certificates, including how certificates >> are obtained, requested, and which actions are taken upon successful >> or failed verification, are specific to the scenario in which the >> certificates are used. Hence, the definition of these scenario- >> specific aspects is left to the documents that use the CERT >> parameter. >> >> This document extends RFC7401 and obsoletes RFC6253. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-hip-rfc6253-bis-04 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc6253-bis-04 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >> From nobody Mon Oct 12 02:42:13 2015 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A7D1A6F27 for ; Mon, 12 Oct 2015 02:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcAVU7nXgbU3 for ; Mon, 12 Oct 2015 02:42:09 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0063B1AC39E for ; Mon, 12 Oct 2015 02:42:08 -0700 (PDT) Received: from [127.0.0.1] (mannerheim.cs.hut.fi [130.233.193.8]) by mail.cs.hut.fi (Postfix) with ESMTP id 4448923CAF for ; Mon, 12 Oct 2015 12:42:03 +0300 (EEST) To: hipsec@ietf.org References: <20150922105852.742.47701.idtracker@ietfa.amsl.com> <560E5953.90002@ericsson.com> <561B7657.4020004@helsinki.fi> From: Miika Komu Message-ID: <561B806B.1080109@cs.hut.fi> Date: Mon, 12 Oct 2015 12:42:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <561B7657.4020004@helsinki.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-rfc6253-bis-04.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 09:42:12 -0000 Hi, I don't have a strong opinion, but I guess SPKI should be dropped since the HIP CERT work is going proceed to the standards track. On 10/12/2015 11:59 AM, Samu Varjonen wrote: > Hi Gonzalo & all, > > all but one of the nits are easily fixed. The one downref to RFC2693 is > the only harder one as I do not think it will ever proceed to anything > more than experimental. The work on RFC 2693 stopped in 1999. Over 114 > papers have been written about it since. Even few this year but all > point to that experimental RFC. Moreover, it seems (in my opinion) that > currently there is little or no interest in continuing SPKI work nor > there is any interest in the industry to implement SPKI as it basically > provides the functionality of X509v3 with different syntax. One option > would be to remove the examples and mentions about SPKI in the > RFC6253bis. What do you guys think? > > BR, > Samu Varjonen > > On 02/10/15 13:15, Gonzalo Camarillo wrote: >> Hi Samu, >> >> thanks for revising the draft. There are still a few things that need to >> be fixed before I can request its publication. From the output of the >> nits tool: >> >> https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-hip-rfc6253-bis-04.txt >> >> >>> -- The abstract seems to indicate that this document obsoletes >>> RFC6253, but >>> the header doesn't have an 'Obsoletes:' line to match this. >> You need to add an Obsoletes: header to the header part at the beginning >> of the draft. Additionally, you also need to add an Updates header as >> follows: >> >> Obsoletes: 6253 >> Updates: 7401 >> >> Note that the original RFC updated RFC 5201 and, thus, had an Updates >> header: >> >> https://tools.ietf.org/html/rfc6253 >> >>> == The document seems to contain a disclaimer for pre-RFC5378 >>> work, but was >>> first submitted on or after 10 November 2008. The disclaimer >>> is usually >>> necessary only for documents that revise or obsolete older >>> RFCs, and that >>> take significant amounts of text from those RFCs. If you can >>> contact all >>> authors of the source material and they are willing to grant >>> the BCP78 >>> rights to the IETF Trust, you can and should remove the >>> disclaimer. >>> Otherwise, the disclaimer is needed and you can ignore this >>> comment. >>> (See the Legal Provisions document at >>> http://trustee.ietf.org/license-info for more information.) >> You are the same authors as in the original RFC. Do you both agree to >> remove the disclaimer? >> >>> == Unused Reference: 'RFC4843' is defined on line 349, but no explicit >>> reference was found in the text >> Does this reference need to be removed or used somewhere in the text? >> >>> ** Downref: Normative reference to an Experimental RFC: RFC 2693 >> RFC 6232bis is intended to be a Proposed Standard. Can we reference a >> Standards Track RFC instead of this one? Otherwise, we will need to talk >> with our AD so make sure it is OK to normatively reference an >> Experimental RFC. >> >>> ** Obsolete normative reference: RFC 4843 (Obsoleted by RFC 7343) >>> ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) >> Could you please update the two references above? >> >>> ** Downref: Normative reference to an Experimental RFC: RFC 6253 >> This downref is obviously OK... but what about making it an >> Informational reference instead? >> >> Could you please revise the draft addressing all the comments above? >> >> Thanks, >> >> Gonzalo >> >> >> On 22/09/2015 1:58 PM, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Host Identity Protocol Working >>> Group of the IETF. >>> >>> Title : Host Identity Protocol Certificates >>> Authors : Tobias Heer >>> Samu Varjonen >>> Filename : draft-ietf-hip-rfc6253-bis-04.txt >>> Pages : 11 >>> Date : 2015-09-22 >>> >>> Abstract: >>> The Certificate (CERT) parameter is a container for digital >>> certificates. It is used for carrying these certificates in Host >>> Identity Protocol (HIP) control packets. This document specifies >>> the >>> certificate parameter and the error signaling in case of a failed >>> verification. Additionally, this document specifies the >>> representations of Host Identity Tags in X.509 version 3 (v3) and >>> Simple Public Key Infrastructure (SPKI) certificates. >>> >>> The concrete use cases of certificates, including how certificates >>> are obtained, requested, and which actions are taken upon successful >>> or failed verification, are specific to the scenario in which the >>> certificates are used. Hence, the definition of these scenario- >>> specific aspects is left to the documents that use the CERT >>> parameter. >>> >>> This document extends RFC7401 and obsoletes RFC6253. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-hip-rfc6253-bis-04 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc6253-bis-04 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/hipsec >>> > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From nobody Mon Oct 12 02:52:03 2015 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834A21AC3E7 for ; Mon, 12 Oct 2015 02:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id il5H1T2NvUxo for ; Mon, 12 Oct 2015 02:52:00 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCAC51AC3E6 for ; Mon, 12 Oct 2015 02:51:59 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-e7-561b82bda6fb Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C3.98.29154.DB28B165; Mon, 12 Oct 2015 11:51:57 +0200 (CEST) Received: from [131.160.36.125] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.248.2; Mon, 12 Oct 2015 11:51:56 +0200 To: Miika Komu , References: <20150922105852.742.47701.idtracker@ietfa.amsl.com> <560E5953.90002@ericsson.com> <561B7657.4020004@helsinki.fi> <561B806B.1080109@cs.hut.fi> From: Gonzalo Camarillo Message-ID: <561B82BD.7020506@ericsson.com> Date: Mon, 12 Oct 2015 12:51:57 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <561B806B.1080109@cs.hut.fi> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+Jvje7eJukwg1WXbCymLprMbNG87Tmb A5PHq/61zB5LlvxkCmCK4rJJSc3JLEst0rdL4MqY+iml4IJZRduCDewNjDO1uxg5OSQETCRO 7j7EAmGLSVy4t56ti5GLQ0jgKKPEsflbGSGcNYwSi7+/ZwWpEhZwllj56DEbiC0iYCxx8O8W qKK5jBJPH55kB0mwCVhIbLl1H2gsBwevgLbEg1YnkDCLgKrE5n+LwXpFBWIken5tALN5BQQl Ts58AlbOKaAp0XAzCiTMLGAgcWTRHFYIW15i+9s5zCC2ENDE5c9aWCYwCsxC0j0LScssJC0L GJlXMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgQG5cEtv612MB587niIUYCDUYmH98FtqTAh 1sSy4srcQ4zSHCxK4rzNTA9ChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTA6s89u67iVxcz/ 2Jgn5Kmje+sT117jOzJyB+48bRN8xrr56EbOTcI+LcaZsQybu3/ozGguerbffPfcea9NW/Yq rbzWzGQ0d9XymslrOH895UrePHnrildBn+vUbxU8a9I6Od3xwMS6zG1Ci+/bLU6sUtuX7slf VMfKtPX7xl+NUjdzAq8cDmNSYinOSDTUYi4qTgQAILqEaCsCAAA= Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-rfc6253-bis-04.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 09:52:02 -0000 Hi Miika, right, that is exactly the discussion we need to have. In general, standards track documents should not reference Experimental specs. We can remove the reference, as suggested by Samu below, find an alternative reference, or figure out whether in this case it could be acceptable to keep the reference... but if nobody intends to implement or deploy SPKI, then removing the reference would be the obviously right thing to do. Any other opinions? Cheers, Gonzalo On 12/10/2015 12:42 PM, Miika Komu wrote: > Hi, > > I don't have a strong opinion, but I guess SPKI should be dropped since > the HIP CERT work is going proceed to the standards track. > > On 10/12/2015 11:59 AM, Samu Varjonen wrote: >> Hi Gonzalo & all, >> >> all but one of the nits are easily fixed. The one downref to RFC2693 is >> the only harder one as I do not think it will ever proceed to anything >> more than experimental. The work on RFC 2693 stopped in 1999. Over 114 >> papers have been written about it since. Even few this year but all >> point to that experimental RFC. Moreover, it seems (in my opinion) that >> currently there is little or no interest in continuing SPKI work nor >> there is any interest in the industry to implement SPKI as it basically >> provides the functionality of X509v3 with different syntax. One option >> would be to remove the examples and mentions about SPKI in the >> RFC6253bis. What do you guys think? >> >> BR, >> Samu Varjonen >> >> On 02/10/15 13:15, Gonzalo Camarillo wrote: >>> Hi Samu, >>> >>> thanks for revising the draft. There are still a few things that need to >>> be fixed before I can request its publication. From the output of the >>> nits tool: >>> >>> https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-hip-rfc6253-bis-04.txt >>> >>> >>> >>>> -- The abstract seems to indicate that this document obsoletes >>>> RFC6253, but >>>> the header doesn't have an 'Obsoletes:' line to match this. >>> You need to add an Obsoletes: header to the header part at the beginning >>> of the draft. Additionally, you also need to add an Updates header as >>> follows: >>> >>> Obsoletes: 6253 >>> Updates: 7401 >>> >>> Note that the original RFC updated RFC 5201 and, thus, had an Updates >>> header: >>> >>> https://tools.ietf.org/html/rfc6253 >>> >>>> == The document seems to contain a disclaimer for pre-RFC5378 >>>> work, but was >>>> first submitted on or after 10 November 2008. The disclaimer >>>> is usually >>>> necessary only for documents that revise or obsolete older >>>> RFCs, and that >>>> take significant amounts of text from those RFCs. If you can >>>> contact all >>>> authors of the source material and they are willing to grant >>>> the BCP78 >>>> rights to the IETF Trust, you can and should remove the >>>> disclaimer. >>>> Otherwise, the disclaimer is needed and you can ignore this >>>> comment. >>>> (See the Legal Provisions document at >>>> http://trustee.ietf.org/license-info for more information.) >>> You are the same authors as in the original RFC. Do you both agree to >>> remove the disclaimer? >>> >>>> == Unused Reference: 'RFC4843' is defined on line 349, but no >>>> explicit >>>> reference was found in the text >>> Does this reference need to be removed or used somewhere in the text? >>> >>>> ** Downref: Normative reference to an Experimental RFC: RFC 2693 >>> RFC 6232bis is intended to be a Proposed Standard. Can we reference a >>> Standards Track RFC instead of this one? Otherwise, we will need to talk >>> with our AD so make sure it is OK to normatively reference an >>> Experimental RFC. >>> >>>> ** Obsolete normative reference: RFC 4843 (Obsoleted by RFC 7343) >>>> ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) >>> Could you please update the two references above? >>> >>>> ** Downref: Normative reference to an Experimental RFC: RFC 6253 >>> This downref is obviously OK... but what about making it an >>> Informational reference instead? >>> >>> Could you please revise the draft addressing all the comments above? >>> >>> Thanks, >>> >>> Gonzalo >>> >>> >>> On 22/09/2015 1:58 PM, internet-drafts@ietf.org wrote: >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Host Identity Protocol Working >>>> Group of the IETF. >>>> >>>> Title : Host Identity Protocol Certificates >>>> Authors : Tobias Heer >>>> Samu Varjonen >>>> Filename : draft-ietf-hip-rfc6253-bis-04.txt >>>> Pages : 11 >>>> Date : 2015-09-22 >>>> >>>> Abstract: >>>> The Certificate (CERT) parameter is a container for digital >>>> certificates. It is used for carrying these certificates in Host >>>> Identity Protocol (HIP) control packets. This document specifies >>>> the >>>> certificate parameter and the error signaling in case of a failed >>>> verification. Additionally, this document specifies the >>>> representations of Host Identity Tags in X.509 version 3 (v3) and >>>> Simple Public Key Infrastructure (SPKI) certificates. >>>> >>>> The concrete use cases of certificates, including how certificates >>>> are obtained, requested, and which actions are taken upon >>>> successful >>>> or failed verification, are specific to the scenario in which the >>>> certificates are used. Hence, the definition of these scenario- >>>> specific aspects is left to the documents that use the CERT >>>> parameter. >>>> >>>> This document extends RFC7401 and obsoletes RFC6253. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis/ >>>> >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ietf-hip-rfc6253-bis-04 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc6253-bis-04 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> Hipsec mailing list >>>> Hipsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/hipsec >>>> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From nobody Mon Oct 12 22:04:11 2015 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEFE1B3779 for ; Mon, 12 Oct 2015 22:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ldYFSXXpisH for ; Mon, 12 Oct 2015 22:04:09 -0700 (PDT) Received: from mxout26.s.uw.edu (mxout26.s.uw.edu [140.142.234.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DECC1B3778 for ; Mon, 12 Oct 2015 22:04:09 -0700 (PDT) Received: from hymn02.u.washington.edu (hymn02.u.washington.edu [140.142.8.71]) by mxout26.s.uw.edu (8.14.4+UW14.03/8.14.4+UW15.02) with ESMTP id t9D50ZGo017987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Oct 2015 22:00:36 -0700 Received: from hymn02.u.washington.edu (localhost [127.0.0.1]) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+UW14.04) with ESMTP id t9D50Vnc005602 for ; Mon, 12 Oct 2015 22:00:31 -0700 Received: from localhost (Unknown UID 20280@localhost) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id t9D50VAL005599 for ; Mon, 12 Oct 2015 22:00:31 -0700 X-Auth-Received: from [73.181.150.17] by hymn02.u.washington.edu via HTTP; Mon, 12 Oct 2015 22:00:31 PDT Date: Mon, 12 Oct 2015 22:00:31 -0700 (PDT) From: Tom Henderson To: hipsec@ietf.org Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.10.13.45417 X-PMX-Server: mxout26.s.uw.edu X-Uwash-Spam: Gauge=X, Probability=10%, Report=' TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_300_399 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0' Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-rfc6253-bis-04.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 05:04:10 -0000 On 10/12/2015 02:42 AM, Miika Komu wrote: > Hi, > > I don't have a strong opinion, but I guess SPKI should be dropped since > the HIP CERT work is going proceed to the standards track. > I feel the same way (no strong opinion, but suggest to drop unless someone strongly argues to keep it). - Tom From nobody Mon Oct 19 06:18:40 2015 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3F71A90AA for ; Mon, 19 Oct 2015 06:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDs3zCSEmbuJ for ; Mon, 19 Oct 2015 06:18:37 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94EA61A90AD for ; Mon, 19 Oct 2015 06:18:36 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-8d-5624edaad99e Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3F.C5.05274.AADE4265; Mon, 19 Oct 2015 15:18:34 +0200 (CEST) Received: from [147.214.22.248] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.248.2; Mon, 19 Oct 2015 15:18:34 +0200 To: Samu Varjonen References: <20150922105852.742.47701.idtracker@ietfa.amsl.com> <560E5953.90002@ericsson.com> <561B7657.4020004@helsinki.fi> From: Gonzalo Camarillo Message-ID: <5624EDAA.6060303@ericsson.com> Date: Mon, 19 Oct 2015 15:18:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <561B7657.4020004@helsinki.fi> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUyM+Jvje6qtyphBpOOGltMXTSZ2eLGzxns Dkwe/Sv3s3ssWfKTKYApissmJTUnsyy1SN8ugStj+81pTAXP9So+3N7J0sB4QKWLkZNDQsBE ov//A2YIW0ziwr31bF2MXBxCAkcZJXpu9LFDOGsYJe59/80OUiUs4Cyx8tFjNhBbREBXYsWd HawgtpBAncTBt5uYuhg5OJgFRCW2z6oCCbMJWEhsuXWfBcTmFdCW2PVsEZjNIqAq8eXgA7CR ogIxEj2/NrBB1AhKnJz5BKyGE6j+6vx7YDazgIHEkUVzWCFseYntb+cwQ6zVllj+rIVlAqPg LCTts5C0zELSsoCReRWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYLge3PJbdQfj5TeOhxgF OBiVeHgftKmECbEmlhVX5h5ilOZgURLnbWZ6ECokkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB sWt3vJyVpPOZt/H8aY2ry6cdSvrjVhGTbiCs9WA2+3I9xyfBSZWX6u7H2ri+3BTDX6UQWX/C kEtjo84+H+bfYswG/7/MD7aWrvUJkM8pdGJKFrY48Nb140K3gJc5d++wROhc7k1xNgqpOmmZ OiVx3tEHdxQ8d56sFpNd31j14mGd4vVqZRMlluKMREMt5qLiRAB/NSQ6OAIAAA== Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-rfc6253-bis-04.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 13:18:39 -0000 Hi Samu, nobody seems to care about SPKI, then. Could you please go ahead revise the draft removing it? Thanks, Gonzalo On 12/10/2015 10:59 AM, Samu Varjonen wrote: > Hi Gonzalo & all, > > all but one of the nits are easily fixed. The one downref to RFC2693 is > the only harder one as I do not think it will ever proceed to anything > more than experimental. The work on RFC 2693 stopped in 1999. Over 114 > papers have been written about it since. Even few this year but all > point to that experimental RFC. Moreover, it seems (in my opinion) that > currently there is little or no interest in continuing SPKI work nor > there is any interest in the industry to implement SPKI as it basically > provides the functionality of X509v3 with different syntax. One option > would be to remove the examples and mentions about SPKI in the > RFC6253bis. What do you guys think? > > BR, > Samu Varjonen > > On 02/10/15 13:15, Gonzalo Camarillo wrote: >> Hi Samu, >> >> thanks for revising the draft. There are still a few things that need to >> be fixed before I can request its publication. From the output of the >> nits tool: >> >> https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-hip-rfc6253-bis-04.txt >> >> >>> -- The abstract seems to indicate that this document obsoletes >>> RFC6253, but >>> the header doesn't have an 'Obsoletes:' line to match this. >> You need to add an Obsoletes: header to the header part at the beginning >> of the draft. Additionally, you also need to add an Updates header as >> follows: >> >> Obsoletes: 6253 >> Updates: 7401 >> >> Note that the original RFC updated RFC 5201 and, thus, had an Updates >> header: >> >> https://tools.ietf.org/html/rfc6253 >> >>> == The document seems to contain a disclaimer for pre-RFC5378 >>> work, but was >>> first submitted on or after 10 November 2008. The disclaimer >>> is usually >>> necessary only for documents that revise or obsolete older >>> RFCs, and that >>> take significant amounts of text from those RFCs. If you can >>> contact all >>> authors of the source material and they are willing to grant >>> the BCP78 >>> rights to the IETF Trust, you can and should remove the >>> disclaimer. >>> Otherwise, the disclaimer is needed and you can ignore this >>> comment. >>> (See the Legal Provisions document at >>> http://trustee.ietf.org/license-info for more information.) >> You are the same authors as in the original RFC. Do you both agree to >> remove the disclaimer? >> >>> == Unused Reference: 'RFC4843' is defined on line 349, but no explicit >>> reference was found in the text >> Does this reference need to be removed or used somewhere in the text? >> >>> ** Downref: Normative reference to an Experimental RFC: RFC 2693 >> RFC 6232bis is intended to be a Proposed Standard. Can we reference a >> Standards Track RFC instead of this one? Otherwise, we will need to talk >> with our AD so make sure it is OK to normatively reference an >> Experimental RFC. >> >>> ** Obsolete normative reference: RFC 4843 (Obsoleted by RFC 7343) >>> ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) >> Could you please update the two references above? >> >>> ** Downref: Normative reference to an Experimental RFC: RFC 6253 >> This downref is obviously OK... but what about making it an >> Informational reference instead? >> >> Could you please revise the draft addressing all the comments above? >> >> Thanks, >> >> Gonzalo >> >> >> On 22/09/2015 1:58 PM, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Host Identity Protocol Working >>> Group of the IETF. >>> >>> Title : Host Identity Protocol Certificates >>> Authors : Tobias Heer >>> Samu Varjonen >>> Filename : draft-ietf-hip-rfc6253-bis-04.txt >>> Pages : 11 >>> Date : 2015-09-22 >>> >>> Abstract: >>> The Certificate (CERT) parameter is a container for digital >>> certificates. It is used for carrying these certificates in Host >>> Identity Protocol (HIP) control packets. This document specifies >>> the >>> certificate parameter and the error signaling in case of a failed >>> verification. Additionally, this document specifies the >>> representations of Host Identity Tags in X.509 version 3 (v3) and >>> Simple Public Key Infrastructure (SPKI) certificates. >>> >>> The concrete use cases of certificates, including how certificates >>> are obtained, requested, and which actions are taken upon successful >>> or failed verification, are specific to the scenario in which the >>> certificates are used. Hence, the definition of these scenario- >>> specific aspects is left to the documents that use the CERT >>> parameter. >>> >>> This document extends RFC7401 and obsoletes RFC6253. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-hip-rfc6253-bis-04 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc6253-bis-04 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/hipsec >>> > From nobody Tue Oct 20 07:25:22 2015 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEF91A1A56 for ; Tue, 20 Oct 2015 07:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOqcl81ogjEx for ; Tue, 20 Oct 2015 07:25:17 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD57C1A21B9 for ; Tue, 20 Oct 2015 07:25:16 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-d7-56264ecac9c3 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D2.A1.29154.ACE46265; Tue, 20 Oct 2015 16:25:15 +0200 (CEST) Received: from m46.nomadiclab.com (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.248.2; Tue, 20 Oct 2015 16:25:13 +0200 To: Gonzalo Camarillo , Miika Komu , References: <20150922105852.742.47701.idtracker@ietfa.amsl.com> <560E5953.90002@ericsson.com> <561B7657.4020004@helsinki.fi> <561B806B.1080109@cs.hut.fi> <561B82BD.7020506@ericsson.com> From: =?UTF-8?Q?Ari_Ker=c3=a4nen?= Message-ID: <56264EC9.6020900@ericsson.com> Date: Tue, 20 Oct 2015 17:25:13 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <561B82BD.7020506@ericsson.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyM+Jvje5pP7Uwg78TeSymLprMbNG87Tmb A5PHq/61zB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4saCyYKtVRVf7F6YGxjl6XYycHBICJhK3 Pu1ihLDFJC7cW8/WxcjFISRwlFHi48qHrBDOOkaJT2tns4FUCQs4S6x89BjMFhHIlOi6sheq Yy+jxJJvp5hAEmwCthK/2/eA2bwC2hJ3+z6zdzFycLAIqErMPGMLEhYVSJM4fO0DK0SJoMTJ mU9YQGxOAR2JlSf+MoOUMwvYSzzYWgYSZhaQl9j+dg4ziC0ENOXqv1eMExgFZiHpnoXQMQtJ xwJG5lWMosWpxcW56UZGeqlFmcnFxfl5enmpJZsYgSF5cMtvqx2MB587HmIU4GBU4uF9kK4a JsSaWFZcmXuIUZqDRUmct5npQaiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxtiy2A8Zq39c 22jSodTH7Gw998sOHb+2ovfpQttilLnMUxdeapulKPZPhkv7mNxdj2AmhQgthYz9Nu3fNvBm nmi9uWnSh9KPQa7Rd2ZUnPJacmZGe/7atAnHlFewh6cF7i4/WVlwpkLL52mPtv5+p9hdSwqe O6x+M3X+0azymafOHerc5uripcRSnJFoqMVcVJwIADNI668qAgAA Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-rfc6253-bis-04.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 14:25:21 -0000 Hi, For the record, +1 for removing SPKI. Cheers, Ari On 12/10/15 12:51, Gonzalo Camarillo wrote: > Hi Miika, > > right, that is exactly the discussion we need to have. In general, > standards track documents should not reference Experimental specs. We > can remove the reference, as suggested by Samu below, find an > alternative reference, or figure out whether in this case it could be > acceptable to keep the reference... but if nobody intends to implement > or deploy SPKI, then removing the reference would be the obviously right > thing to do. > > Any other opinions? > > Cheers, > > Gonzalo > > On 12/10/2015 12:42 PM, Miika Komu wrote: >> Hi, >> >> I don't have a strong opinion, but I guess SPKI should be dropped since >> the HIP CERT work is going proceed to the standards track. >> >> On 10/12/2015 11:59 AM, Samu Varjonen wrote: >>> Hi Gonzalo & all, >>> >>> all but one of the nits are easily fixed. The one downref to RFC2693 is >>> the only harder one as I do not think it will ever proceed to anything >>> more than experimental. The work on RFC 2693 stopped in 1999. Over 114 >>> papers have been written about it since. Even few this year but all >>> point to that experimental RFC. Moreover, it seems (in my opinion) that >>> currently there is little or no interest in continuing SPKI work nor >>> there is any interest in the industry to implement SPKI as it basically >>> provides the functionality of X509v3 with different syntax. One option >>> would be to remove the examples and mentions about SPKI in the >>> RFC6253bis. What do you guys think? >>> >>> BR, >>> Samu Varjonen >>> >>> On 02/10/15 13:15, Gonzalo Camarillo wrote: >>>> Hi Samu, >>>> >>>> thanks for revising the draft. There are still a few things that need to >>>> be fixed before I can request its publication. From the output of the >>>> nits tool: >>>> >>>> https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-hip-rfc6253-bis-04.txt >>>> >>>> >>>> >>>>> -- The abstract seems to indicate that this document obsoletes >>>>> RFC6253, but >>>>> the header doesn't have an 'Obsoletes:' line to match this. >>>> You need to add an Obsoletes: header to the header part at the beginning >>>> of the draft. Additionally, you also need to add an Updates header as >>>> follows: >>>> >>>> Obsoletes: 6253 >>>> Updates: 7401 >>>> >>>> Note that the original RFC updated RFC 5201 and, thus, had an Updates >>>> header: >>>> >>>> https://tools.ietf.org/html/rfc6253 >>>> >>>>> == The document seems to contain a disclaimer for pre-RFC5378 >>>>> work, but was >>>>> first submitted on or after 10 November 2008. The disclaimer >>>>> is usually >>>>> necessary only for documents that revise or obsolete older >>>>> RFCs, and that >>>>> take significant amounts of text from those RFCs. If you can >>>>> contact all >>>>> authors of the source material and they are willing to grant >>>>> the BCP78 >>>>> rights to the IETF Trust, you can and should remove the >>>>> disclaimer. >>>>> Otherwise, the disclaimer is needed and you can ignore this >>>>> comment. >>>>> (See the Legal Provisions document at >>>>> http://trustee.ietf.org/license-info for more information.) >>>> You are the same authors as in the original RFC. Do you both agree to >>>> remove the disclaimer? >>>> >>>>> == Unused Reference: 'RFC4843' is defined on line 349, but no >>>>> explicit >>>>> reference was found in the text >>>> Does this reference need to be removed or used somewhere in the text? >>>> >>>>> ** Downref: Normative reference to an Experimental RFC: RFC 2693 >>>> RFC 6232bis is intended to be a Proposed Standard. Can we reference a >>>> Standards Track RFC instead of this one? Otherwise, we will need to talk >>>> with our AD so make sure it is OK to normatively reference an >>>> Experimental RFC. >>>> >>>>> ** Obsolete normative reference: RFC 4843 (Obsoleted by RFC 7343) >>>>> ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) >>>> Could you please update the two references above? >>>> >>>>> ** Downref: Normative reference to an Experimental RFC: RFC 6253 >>>> This downref is obviously OK... but what about making it an >>>> Informational reference instead? >>>> >>>> Could you please revise the draft addressing all the comments above? >>>> >>>> Thanks, >>>> >>>> Gonzalo >>>> >>>> >>>> On 22/09/2015 1:58 PM, internet-drafts@ietf.org wrote: >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Host Identity Protocol Working >>>>> Group of the IETF. >>>>> >>>>> Title : Host Identity Protocol Certificates >>>>> Authors : Tobias Heer >>>>> Samu Varjonen >>>>> Filename : draft-ietf-hip-rfc6253-bis-04.txt >>>>> Pages : 11 >>>>> Date : 2015-09-22 >>>>> >>>>> Abstract: >>>>> The Certificate (CERT) parameter is a container for digital >>>>> certificates. It is used for carrying these certificates in Host >>>>> Identity Protocol (HIP) control packets. This document specifies >>>>> the >>>>> certificate parameter and the error signaling in case of a failed >>>>> verification. Additionally, this document specifies the >>>>> representations of Host Identity Tags in X.509 version 3 (v3) and >>>>> Simple Public Key Infrastructure (SPKI) certificates. >>>>> >>>>> The concrete use cases of certificates, including how certificates >>>>> are obtained, requested, and which actions are taken upon >>>>> successful >>>>> or failed verification, are specific to the scenario in which the >>>>> certificates are used. Hence, the definition of these scenario- >>>>> specific aspects is left to the documents that use the CERT >>>>> parameter. >>>>> >>>>> This document extends RFC7401 and obsoletes RFC6253. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis/ >>>>> >>>>> There's also a htmlized version available at: >>>>> https://tools.ietf.org/html/draft-ietf-hip-rfc6253-bis-04 >>>>> >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc6253-bis-04 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> Hipsec mailing list >>>>> Hipsec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/hipsec >>>>> >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/hipsec >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From nobody Thu Oct 22 15:55:49 2015 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACDFE1B2F9C for ; Thu, 22 Oct 2015 15:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8BZWFfuDSGy for ; Thu, 22 Oct 2015 15:55:45 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1BF51B2F9B for ; Thu, 22 Oct 2015 15:55:45 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 4CBC3D789C for ; Thu, 22 Oct 2015 15:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=date:from :to:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=SjPo2YXvdVwO3yMhh+Px4NR2mFk=; b=om B5x9vtrQygKTA4jJ9ho+eNNGxf0EGkGVMFoMWmslNtA1qRHmHO/6tBYKv1f0K8XI jRQfwhkSswCBTtNXlKT+LO7JHecmtNVn8RtCer2RIh4gXRhjqGGCdXcHamCKx8vo DrhqbgFpUZteImVyEg9yR3YHoE4vzBoR9mcNl/O/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=date:from :to:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=selector1; b=YhrzAOEVz+Sk80GgiuNIaD0W/FRb C9MeeafnZTnA75pwJxIm3mkV695c6DJedFIgJwGAWN6q23pQn/AiKQoq17Fx6wAq 8hz+6zpwJenws7Qv/qnlaWPHbnpqkiXdf7MKL5l4bHEw4M84GcD/ZI8DCw8rdY54 YhkCHvTZh/CN1A0= Received: by cowbell.employees.org (Postfix, from userid 1736) id 3EC5AD7892; Thu, 22 Oct 2015 15:55:45 -0700 (PDT) Date: Thu, 22 Oct 2015 23:55:45 +0100 From: Derek Fawcus To: hipsec@ietf.org Message-ID: <20151022225545.GC31636@cowbell.employees.org> Mail-Followup-To: hipsec@ietf.org References: <20150922105852.742.47701.idtracker@ietfa.amsl.com> <560E5953.90002@ericsson.com> <561B7657.4020004@helsinki.fi> <561B806B.1080109@cs.hut.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <561B806B.1080109@cs.hut.fi> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-rfc6253-bis-04.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 22:55:47 -0000 On Mon, Oct 12, 2015 at 12:42:03PM +0300, Miika Komu wrote: > > I don't have a strong opinion, but I guess SPKI should be dropped since > the HIP CERT work is going proceed to the standards track. IMO it'd be a pity to drop the SPKI stuff, as I found it easier to understand and parse than the x509 encoding, but if no one is using it... DF