From dpquigl@tycho.nsa.gov Mon Aug 2 07:37:56 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 385453A6BE3 for ; Mon, 2 Aug 2010 07:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vrigZSNq2X5r for ; Mon, 2 Aug 2010 07:37:54 -0700 (PDT) Received: from msux-gh1-uea01.nsa.gov (msux-gh1-uea01.nsa.gov [63.239.65.39]) by core3.amsl.com (Postfix) with ESMTP id B64A33A6BE1 for ; Mon, 2 Aug 2010 07:34:58 -0700 (PDT) Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id o72EYsXs028292 for ; Mon, 2 Aug 2010 14:34:54 GMT Received: from [144.51.25.2] (moss-terrapins [144.51.25.2]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id o72EYveV032027 for ; Mon, 2 Aug 2010 10:34:57 -0400 From: "David P. Quigley" To: saag@ietf.org Content-Type: text/plain Organization: National Security Agency Date: Mon, 02 Aug 2010 10:24:32 -0400 Message-Id: <1280759072.2673.98.camel@moss-terrapins.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) Content-Transfer-Encoding: 7bit Subject: [saag] Label Format Selector Draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 14:37:56 -0000 Hello Everyone, I have been working for a while on protocol extensions to NFSv4 to allow for the use of security labels in various aspects of the protocol. Recently I've been working with the people proposing labeling extensions to IPSec as well. Over the course of this work we have developed a mechanism which allows protocols to be defined without being bogged down worrying about security label format. This mechanism is outlined in the document located at the url below[1]. I would appreciate any comments and feedback you may have on the document. Dave Quigley [1]http://www.ietf.org/id/draft-quigley-label-format-registry-00.txt From stefw@gnome.org Mon Aug 2 08:44:24 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE8303A6936 for ; Mon, 2 Aug 2010 08:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 8lPSLwMPi63u for ; Mon, 2 Aug 2010 08:44:23 -0700 (PDT) Received: from memberwebs.com (memberwebs.com [94.75.203.95]) by core3.amsl.com (Postfix) with ESMTP id 4BB123A6AEF for ; Mon, 2 Aug 2010 08:44:22 -0700 (PDT) Received: from [85.17.253.231] (unknown [85.17.253.231]) by memberwebs.com (Postfix) with ESMTP id D7CE983E4BA; Mon, 2 Aug 2010 15:44:42 +0000 (UTC) Message-ID: <4C56E7EA.5020701@gnome.org> Date: Mon, 02 Aug 2010 17:44:42 +0200 From: Stef Walter User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Jan Pechanec References: <4C5515AD.9020603@gnome.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Darren.Moffat@Oracle.COM, saag@ietf.org, Nikos Mavrogiannopoulos Subject: Re: [saag] I-D on PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 15:44:25 -0000 On 08/02/2010 04:04 PM, Jan Pechanec wrote: > I'm also cc'ing Nikos who raised the similar question on the > encoding just a few days ago. > >> I work on gnome-keyring which is based around PKCS#11. We're working on >> an effort to use PKCS#11 as a common key and certificate storage >> standard for the GNOME Desktop. >> >> I'm interested in the PKCS#11 URI [1] RFC that you proposed. However, >> several questions come up about encoding. > > I'm very glad that you might be interested in using this. I hope > we can agree on a common specification. Yes that would be great. > the BNF code in the I-D uses UTF-8 for most of the attribute > values so all other characters were supposed to stand for themselves. > However, I think that using the percent encoding is better, please see > below. Cool. >> Secondly, would it perhaps make sense to use percent encoding for the >> id= attribute? PKCS#11 URIs as proposed are introducing a colon style >> encoding. I noticed it's not defined whether there may be one hex >> character between colons or not. Percent encoding is a well defined >> encoding which removes such ambiguities. > > it seems to me it would be logical to use the percent encoding > for the 'id' attribute as well. > > there is a minor issue though. From RFC 2068 I can see that in > the HTTP url, '%' can not stand for itself as $ in shell can, for > example. So, "http://www.abc.com/page%" is not a correct URL. What do we > do here? > > we have two options. (a) We can say that in those attributes > with UTF-8 character set '%' is supposed to be an escape if followed by > two hexa characters. That way I could just reference 'UTF8-octets' > defined in RFC3629. It would mean that: > > pkcs11:object=abc% > > would constitute a valid PKCS#11 URI. An application would have > to choose what to do with that. For example, Firefox even accepts > "http://www.abc.com/page%" but Apache returns BAD_REQUEST no matter that > there is a page literally named "page%". > > alternatively, (b) we could exclude such URIs using the BNF code > and give '%' a special meaning. I'd have to do something similar to what > I do now - put the UTF-8 definition there and modify it. I'd propose the third option (c) that a percent character on its own is invalid, and that percent characters must be encoded using percent encoding. This would mirror the above apache behavior. This is far easier and consistent for an application or library to implement. Perhaps this is similar to what you meant by option (a) but is further defined. > I assume that %hh would be allowed only in values so if there is > literal ';' it is an attribute delimiter. Yes correct. We could also mention that > using the percent encoding for anything else than ';' and possibly '%' > is optional, mostly based on what other characters need to be escaped > from the system using the URI instances. What about spaces and new lines? It seems to me that there are many characters which would require encoding. Or am I misunderstanding? > as mentioned, I'd also replace the current ck_id encoding with > the %hh encoding. Perfect. I'm currently working on implementing this in gnome-keyring, and hopefully will have some code to try out PKCS#11 URIs soon. Another question to follow in another thread... Thanks again. Stef From stefw@gnome.org Mon Aug 2 11:45:14 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67F9C3A69C0 for ; Mon, 2 Aug 2010 11:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.506 X-Spam-Level: X-Spam-Status: No, score=-1.506 tagged_above=-999 required=5 tests=[AWL=1.093, BAYES_00=-2.599] 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 mMUV0221qqCN for ; Mon, 2 Aug 2010 11:45:13 -0700 (PDT) Received: from memberwebs.com (memberwebs.com [94.75.203.95]) by core3.amsl.com (Postfix) with ESMTP id CBC183A6972 for ; Mon, 2 Aug 2010 11:45:12 -0700 (PDT) Received: from [192.168.1.9] (a82-92-233-51.adsl.xs4all.nl [82.92.233.51]) by memberwebs.com (Postfix) with ESMTP id 95DDF83E4BA; Mon, 2 Aug 2010 18:45:32 +0000 (UTC) Message-ID: <4C57124B.3020403@gnome.org> Date: Mon, 02 Aug 2010 20:45:31 +0200 From: Stef Walter User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Jan Pechanec References: <4C5515AD.9020603@gnome.org> <4C56E7EA.5020701@gnome.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Darren.Moffat@Oracle.COM, saag@ietf.org, Nikos Mavrogiannopoulos Subject: Re: [saag] I-D on PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 18:45:14 -0000 On 08/02/2010 06:03 PM, Jan Pechanec wrote: > On Mon, 2 Aug 2010, Stef Walter wrote: >> I'd propose the third option (c) that a percent character on its own is >> invalid, and that percent characters must be encoded using percent >> encoding. This would mirror the above apache behavior. This is far >> easier and consistent for an application or library to implement. >> Perhaps this is similar to what you meant by option (a) but is further >> defined. > > that would be fine with me but if we say that a percent > character MUST NOT be present in the URI, the UTF-8 BNF definition must > be copied over, changed and put it into the I-D. That's how the BNF code > is there now and it brings more complexity without really giving any > real benefit. Given that it's encoding of the attribute value, I'm > wondering if we could get away with just stating that the percent > encoding SHOULD be used for ';', '%' and other characters like new lines > or spaces but the final value interpretation is up to the consumer. It seems to me that the complexity in the BNF definition is traded for complexity in a conforming URI parser. RFC 3986 does indicate that percent should not be allowed unless percent encoded as %25. [1] My opinion on this matter is not a strong one, but I had planned to use url unescape functions available in glib which expect properly encoded URI segments, and as such reject raw percent signs. > strictly speaking, we should also limit what %hh could be used > for. It should not be anything above 128 otherwise it could corrupt the > UTF-8 encoding. That's why I'd like to avoid this in the BNF code. Well, in cases of escaped CKA_ID it would be any arbitrary byte value from 0 - 256. In addition UTF-8 characters are typically encoded one byte at a time in URIs. When encoded as percent encoding, the french word 'défaut' would be encoded as 'd%C3%A9faut'. More info toward the end of section 2.5 in RFC 3986 [2]. Therefore accepting percent encoded characters higher than the byte 128 is necessary. Such URIs would be produced by the GNOME implementation. >>> I assume that %hh would be allowed only in values so if there is >>> literal ';' it is an attribute delimiter. >> >> Yes correct. >> >> We could also mention that >>> using the percent encoding for anything else than ';' and possibly '%' >>> is optional, mostly based on what other characters need to be escaped >>> from the system using the URI instances. >> >> What about spaces and new lines? It seems to me that there are many >> characters which would require encoding. Or am I misunderstanding? > > no, just those characters do not have to be escaped. In shell, > we can put a newline into the string easily but it could be used. Of > course, they MAY be escaped. Okay, so this is different than RFC 3986, where whitespace (unless percent encoded) is to be ignored by a parser. That said, in practice many (most?) URI parsers preserve whitespace, so I agree that we can be more lenient in the encoding of newlines or spaces. >>> as mentioned, I'd also replace the current ck_id encoding with >>> the %hh encoding. FWIW, the hex encoding of a URI is defined as upper case in RFC 3986 [3]. I realize I keep pointing to RFC 3986, but that's because we're calling it a 'URI'. If we choose to differ from the definition of URI in the above aspects, I think it would be important to note these differences in the PKCS#11 URI specification. Cheers, Stef [1] http://tools.ietf.org/html/rfc3986#section-2.4 [2] http://tools.ietf.org/html/rfc3986#section-2.5 [3] http://tools.ietf.org/html/rfc3986#section-2.1 From stefw@gnome.org Tue Aug 3 23:25:21 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0E173A6A46 for ; Tue, 3 Aug 2010 23:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.779 X-Spam-Level: X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[AWL=0.820, BAYES_00=-2.599] 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 U0kgpP1ly-Vs for ; Tue, 3 Aug 2010 23:25:20 -0700 (PDT) Received: from memberwebs.com (memberwebs.com [94.75.203.95]) by core3.amsl.com (Postfix) with ESMTP id E51B33A688E for ; Tue, 3 Aug 2010 23:25:19 -0700 (PDT) Received: from [192.168.1.9] (a82-92-233-51.adsl.xs4all.nl [82.92.233.51]) by memberwebs.com (Postfix) with ESMTP id B39DD83E4CB; Wed, 4 Aug 2010 06:25:39 +0000 (UTC) Message-ID: <4C5907E2.1070303@gnome.org> Date: Wed, 04 Aug 2010 08:25:38 +0200 From: Stef Walter User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Jan Pechanec References: <4C5515AD.9020603@gnome.org> <4C56E7EA.5020701@gnome.org> <4C57124B.3020403@gnome.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Darren.Moffat@oracle.com, saag@ietf.org, Nikos Mavrogiannopoulos Subject: Re: [saag] I-D on PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 06:25:21 -0000 > On Mon, 2 Aug 2010, Stef Walter wrote: >> Jan Pechanec wrote: >> as mentioned, I'd also replace the current ck_id encoding with >> the %hh encoding. > > FWIW, the hex encoding of a URI is defined as upper case in RFC 3986 [3]. I've been thinking about the CKA_ID encoding further, and because it's arbitrary binary data percent encoding may not be the best fit... I realize I suggested percent encoding, and perhaps percent encoding could work, but it may be out of the ordinary to use percent encoding for predominantly binary data. For example the data: URI uses base64 encoding instead. It seems that a straight forward hex encoding or base64 encoding is more common to use in a URI when raw binary data is encoded. But I'm fine with any of these approaches to encoding the CKA_ID. Technically they would all work. Cheers, Stef From Jan.Pechanec@Sun.COM Mon Aug 2 07:05:23 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D4E3A6855 for ; Mon, 2 Aug 2010 07:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] 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 apierJXbaBMn for ; Mon, 2 Aug 2010 07:05:21 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) by core3.amsl.com (Postfix) with ESMTP id 1B2B43A67F0 for ; Mon, 2 Aug 2010 07:05:20 -0700 (PDT) Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o72E5lFR026603 for ; Mon, 2 Aug 2010 14:05:47 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L6J00K003409R00@fe-emea-13.sun.com> for saag@ietf.org; Mon, 02 Aug 2010 15:05:27 +0100 (BST) Received: from rejewski ([unknown] [10.18.138.121]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L6J00JTQ353POC0@fe-emea-13.sun.com>; Mon, 02 Aug 2010 15:05:27 +0100 (BST) Date: Mon, 02 Aug 2010 16:04:38 +0200 (CEST) From: Jan Pechanec In-reply-to: <4C5515AD.9020603@gnome.org> Sender: Jan.Pechanec@Sun.COM X-X-Sender: jp161948@rejewski To: Stef Walter Message-id: References: <4C5515AD.9020603@gnome.org> X-Mailman-Approved-At: Thu, 05 Aug 2010 08:04:39 -0700 Cc: Darren.Moffat@Oracle.COM, saag@ietf.org, Nikos Mavrogiannopoulos Subject: Re: [saag] I-D on PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 14:05:23 -0000 On Sun, 1 Aug 2010, Stef Walter wrote: hi Stef, I'm also cc'ing Nikos who raised the similar question on the encoding just a few days ago. >I work on gnome-keyring which is based around PKCS#11. We're working on >an effort to use PKCS#11 as a common key and certificate storage >standard for the GNOME Desktop. > >I'm interested in the PKCS#11 URI [1] RFC that you proposed. However, >several questions come up about encoding. I'm very glad that you might be interested in using this. I hope we can agree on a common specification. >The standard states that semi-colons and backslashes should be escaped >with back slashes. That fixes the problem of allowing semi-colons to be >specified in object=xxx labels. > >However if there are spaces, tabs, or other special characters in the >PKCS#11 URI should these be percent encoded? This is not made clear in >the spec, but perhaps it's an assumption because of the reference to >other URI RFCs. the BNF code in the I-D uses UTF-8 for most of the attribute values so all other characters were supposed to stand for themselves. However, I think that using the percent encoding is better, please see below. >That said, one implementation I found in OpenSolaris libcryptoutil does >not handle percent encoding or even the backslash style escaping [2]. correct. It was a dependency for another project I've been working on so I just wrote the code in a way that was enough for the URI use in Solaris. >I question the need for backslash style escaping of semi-colon >suggested in the PKCS#11 URI proposal. In my opinion PKCS#11 URIs should >just use percent encoding for semi-colons, similar to how you would >percent encode a '?' character or space in a http: URL. I agree. >Secondly, would it perhaps make sense to use percent encoding for the >id= attribute? PKCS#11 URIs as proposed are introducing a colon style >encoding. I noticed it's not defined whether there may be one hex >character between colons or not. Percent encoding is a well defined >encoding which removes such ambiguities. it seems to me it would be logical to use the percent encoding for the 'id' attribute as well. there is a minor issue though. From RFC 2068 I can see that in the HTTP url, '%' can not stand for itself as $ in shell can, for example. So, "http://www.abc.com/page%" is not a correct URL. What do we do here? we have two options. (a) We can say that in those attributes with UTF-8 character set '%' is supposed to be an escape if followed by two hexa characters. That way I could just reference 'UTF8-octets' defined in RFC3629. It would mean that: pkcs11:object=abc% would constitute a valid PKCS#11 URI. An application would have to choose what to do with that. For example, Firefox even accepts "http://www.abc.com/page%" but Apache returns BAD_REQUEST no matter that there is a page literally named "page%". alternatively, (b) we could exclude such URIs using the BNF code and give '%' a special meaning. I'd have to do something similar to what I do now - put the UTF-8 definition there and modify it. I prefer (a). We can clearify that if % is not followed by two hexa characters it's up to the consumer of the URI to decide what to do. We do not have to say more since in UTF-8, any character <=128 stands for itself so the consumer would be expected to reparse the attribute values and replace %hh with the correct characters and possibly leave values ending with sequences like '%h' as they are (or return an error). I assume that %hh would be allowed only in values so if there is literal ';' it is an attribute delimiter. We could also mention that using the percent encoding for anything else than ';' and possibly '%' is optional, mostly based on what other characters need to be escaped from the system using the URI instances. as mentioned, I'd also replace the current ck_id encoding with the %hh encoding. what do you think? thanks for the feedback, J. >Looking forward to your comments. > >Cheers, > >Stef > > >[1] http://tools.ietf.org/html/draft-pechanec-pkcs11uri-01 > >[2] >http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libcryptoutil/common/pkcs11_uri.c#126 > -- Jan Pechanec http://blogs.sun.com/janp From Jan.Pechanec@Sun.COM Mon Aug 2 09:03:59 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF2AC3A6B42 for ; Mon, 2 Aug 2010 09:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[AWL=1.900, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 6DwaATQHjqXI for ; Mon, 2 Aug 2010 09:03:58 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) by core3.amsl.com (Postfix) with ESMTP id 63EEE3A6998 for ; Mon, 2 Aug 2010 09:03:57 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o72G4OQw018325 for ; Mon, 2 Aug 2010 16:04:24 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L6J003008IZYX00@fe-emea-10.sun.com> for saag@ietf.org; Mon, 02 Aug 2010 17:04:08 +0100 (BST) Received: from rejewski ([unknown] [10.18.138.121]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L6J00LWY8MVXU70@fe-emea-10.sun.com>; Mon, 02 Aug 2010 17:04:08 +0100 (BST) Date: Mon, 02 Aug 2010 18:03:18 +0200 (CEST) From: Jan Pechanec In-reply-to: <4C56E7EA.5020701@gnome.org> Sender: Jan.Pechanec@Sun.COM X-X-Sender: jp161948@rejewski To: Stef Walter Message-id: References: <4C5515AD.9020603@gnome.org> <4C56E7EA.5020701@gnome.org> X-Mailman-Approved-At: Thu, 05 Aug 2010 08:04:40 -0700 Cc: Darren.Moffat@Oracle.COM, saag@ietf.org, Nikos Mavrogiannopoulos Subject: Re: [saag] I-D on PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 16:04:00 -0000 On Mon, 2 Aug 2010, Stef Walter wrote: >> there is a minor issue though. From RFC 2068 I can see that in >> the HTTP url, '%' can not stand for itself as $ in shell can, for >> example. So, "http://www.abc.com/page%" is not a correct URL. What do we >> do here? >> >> we have two options. (a) We can say that in those attributes >> with UTF-8 character set '%' is supposed to be an escape if followed by >> two hexa characters. That way I could just reference 'UTF8-octets' >> defined in RFC3629. It would mean that: >> >> pkcs11:object=abc% >> >> would constitute a valid PKCS#11 URI. An application would have >> to choose what to do with that. For example, Firefox even accepts >> "http://www.abc.com/page%" but Apache returns BAD_REQUEST no matter that >> there is a page literally named "page%". >> >> alternatively, (b) we could exclude such URIs using the BNF code >> and give '%' a special meaning. I'd have to do something similar to what >> I do now - put the UTF-8 definition there and modify it. > >I'd propose the third option (c) that a percent character on its own is >invalid, and that percent characters must be encoded using percent >encoding. This would mirror the above apache behavior. This is far >easier and consistent for an application or library to implement. >Perhaps this is similar to what you meant by option (a) but is further >defined. that would be fine with me but if we say that a percent character MUST NOT be present in the URI, the UTF-8 BNF definition must be copied over, changed and put it into the I-D. That's how the BNF code is there now and it brings more complexity without really giving any real benefit. Given that it's encoding of the attribute value, I'm wondering if we could get away with just stating that the percent encoding SHOULD be used for ';', '%' and other characters like new lines or spaces but the final value interpretation is up to the consumer. strictly speaking, we should also limit what %hh could be used for. It should not be anything above 128 otherwise it could corrupt the UTF-8 encoding. That's why I'd like to avoid this in the BNF code. given that "http://www.abc.com/page%" is an invalid http URL I'd expect Firefox to refuse it right away. That's why I don't think we need to do that in the BNF code. >> I assume that %hh would be allowed only in values so if there is >> literal ';' it is an attribute delimiter. > >Yes correct. > >We could also mention that >> using the percent encoding for anything else than ';' and possibly '%' >> is optional, mostly based on what other characters need to be escaped >> from the system using the URI instances. > >What about spaces and new lines? It seems to me that there are many >characters which would require encoding. Or am I misunderstanding? no, just those characters do not have to be escaped. In shell, we can put a newline into the string easily but it could be used. Of course, they MAY be escaped. "Anything with an ASCII code 1-128 MAY be escaped using the % character." >> as mentioned, I'd also replace the current ck_id encoding with >> the %hh encoding. > >Perfect. > >I'm currently working on implementing this in gnome-keyring, and >hopefully will have some code to try out PKCS#11 URIs soon. Another >question to follow in another thread... cool. Cheers, J. > >Thanks again. > >Stef > -- Jan Pechanec http://blogs.sun.com/janp From Jan.Pechanec@Sun.COM Mon Aug 2 17:52:06 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF2E03A67F1 for ; Mon, 2 Aug 2010 17:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 BcfQ7H470aLk for ; Mon, 2 Aug 2010 17:52:05 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) by core3.amsl.com (Postfix) with ESMTP id 456643A6A03 for ; Mon, 2 Aug 2010 17:52:03 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o730qUvI002717 for ; Tue, 3 Aug 2010 00:52:30 GMT MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_VF4/PAOnzF6/yi8Mfb3tTg)" Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L6J00M00X176Y00@fe-emea-10.sun.com> for saag@ietf.org; Tue, 03 Aug 2010 01:52:18 +0100 (BST) Received: from rejewski ([unknown] [10.18.138.121]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L6J00G51X36XS20@fe-emea-10.sun.com>; Tue, 03 Aug 2010 01:52:18 +0100 (BST) Date: Tue, 03 Aug 2010 02:51:29 +0200 (CEST) From: Jan Pechanec In-reply-to: <4C57124B.3020403@gnome.org> Sender: Jan.Pechanec@Sun.COM X-X-Sender: jp161948@rejewski To: Stef Walter Message-id: References: <4C5515AD.9020603@gnome.org> <4C56E7EA.5020701@gnome.org> <4C57124B.3020403@gnome.org> X-Mailman-Approved-At: Thu, 05 Aug 2010 08:04:42 -0700 Cc: Darren.Moffat@oracle.com, saag@ietf.org, Nikos Mavrogiannopoulos Subject: Re: [saag] I-D on PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 00:52:07 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --Boundary_(ID_VF4/PAOnzF6/yi8Mfb3tTg) Content-type: TEXT/PLAIN; charset=ISO-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE On Mon, 2 Aug 2010, Stef Walter wrote: =09hi Stef, >> =09that would be fine with me but if we say that a percent=20 >> character MUST NOT be present in the URI, the UTF-8 BNF definition= must=20 >> be copied over, changed and put it into the I-D. That's how the BN= F code=20 >> is there now and it brings more complexity without really giving a= ny=20 >> real benefit. Given that it's encoding of the attribute value, I'm= =20 >> wondering if we could get away with just stating that the percent= =20 >> encoding SHOULD be used for ';', '%' and other characters like new= lines=20 >> or spaces but the final value interpretation is up to the consumer= . > >It seems to me that the complexity in the BNF definition is traded f= or >complexity in a conforming URI parser. > >RFC 3986 does indicate that percent should not be allowed unless per= cent >encoded as %25. [1] > >My opinion on this matter is not a strong one, but I had planned to = use >url unescape functions available in glib which expect properly encod= ed >URI segments, and as such reject raw percent signs. =09they must be able to return an error on an improperly encoded=20 string :-) Anyway, I understand the problem, it's when to catch the= =20 errors. The closer to the user, the better. I'll have a look what wou= ld=20 the BNF code look like. >> =09strictly speaking, we should also limit what %hh could be used= =20 >> for. It should not be anything above 128 otherwise it could corrup= t the=20 >> UTF-8 encoding. That's why I'd like to avoid this in the BNF code. > >Well, in cases of escaped CKA_ID it would be any arbitrary byte valu= e >from 0 - 256. =09sure, CKA_ID is easy. >In addition UTF-8 characters are typically encoded one byte at a tim= e in >URIs. When encoded as percent encoding, the french word 'd=E9faut' w= ould >be encoded as 'd%C3%A9faut'. More info toward the end of section 2.5= in >RFC 3986 [2]. =09aha, got it. The percent encoding would be representing the=20 UTF-8 encoding so any UTF-8 character above 128 if represented by the= =20 percent encoding would be encoded in at least two %hh sequences. That= 's=20 fine with me. >> =09no, just those characters do not have to be escaped. In shell,= =20 >> we can put a newline into the string easily but it could be used. = Of=20 >> course, they MAY be escaped. > >Okay, so this is different than RFC 3986, where whitespace (unless >percent encoded) is to be ignored by a parser. That said, in practic= e >many (most?) URI parsers preserve whitespace, so I agree that we can= be >more lenient in the encoding of newlines or spaces. =09I think I have to take a closer look at the RFC but I think we= =20 should allow spaces as spaces. >>>> =09as mentioned, I'd also replace the current ck_id encoding wit= h=20 >>>> the %hh encoding. > >FWIW, the hex encoding of a URI is defined as upper case in RFC 3986= [3]. =09ok >I realize I keep pointing to RFC 3986, but that's because we're call= ing >it a 'URI'. If we choose to differ from the definition of URI in the >above aspects, I think it would be important to note these differenc= es >in the PKCS#11 URI specification. =09I think we should follow RFC 3986 as much as possible, I'll read= =20 through it properly and get back to you. =09thanks, J. >[1] http://tools.ietf.org/html/rfc3986#section-2.4 > >[2] http://tools.ietf.org/html/rfc3986#section-2.5 > >[3] http://tools.ietf.org/html/rfc3986#section-2.1 > --=20 Jan Pechanec http://blogs.sun.com/janp --Boundary_(ID_VF4/PAOnzF6/yi8Mfb3tTg)-- From kent@bbn.com Mon Aug 9 13:54:10 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC9BD3A69B8; Mon, 9 Aug 2010 13:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.229 X-Spam-Level: X-Spam-Status: No, score=-101.229 tagged_above=-999 required=5 tests=[AWL=-1.045, BAYES_40=-0.185, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 w2NStG+BcTK5; Mon, 9 Aug 2010 13:54:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id D1D003A6969; Mon, 9 Aug 2010 13:54:09 -0700 (PDT) Received: from dhcp89-089-110.bbn.com ([128.89.89.110]:49206) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OiZMk-000IME-2r; Mon, 09 Aug 2010 16:54:38 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 9 Aug 2010 16:54:31 -0400 To: Sam Hartman From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-930735219==_ma============" Cc: Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman , Sam Hartman Subject: Re: [saag] [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 20:54:11 -0000 --============_-930735219==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 4:14 AM -0400 7/29/10, Sam Hartman wrote: > >>>>> "Stephen" == Stephen Kent writes: > > Stephen> I agree that the primary motivation for CGAs arose in the > Stephen> SeND context, and that privacy is an independent > Stephen> feature. But, the context in which CGAs were intended to > Stephen> provide an ability to establish a binding to an IPv6 > Stephen> address was local. When one moves beyond this local > Stephen> context, and one advocates having more distant nodes > Stephen> challenge a host, this creates privacy questions. > >I think we've been looking at CGAs that have non-local scope for a >while. Section 7.4 of RFC 3972 seems to anticipate CGAs used with other >protocols. It's my understanding that shim6 supports both HBAs and CGAs >for non-local contexts. I also believe the MIP6 context for CGA use is >non-local. I don't know about MIP6, but when I read the second paragraph of section 7.4 in the CGA RFC, I get a different impression. The fact that the paragraph begins with "Finally, a strong cautionary note has to be made about using CGA signatures for purposes other than SEND." suggests to me that the authors anticipated that others might want to use CGAs elsewhere. They provided a list of comments about why CGAs were designed for and well-suited to the SeND context (which is local), and warnings about the limitations that arise if one tries to use CGAs elsewhere. Steve --============_-930735219==_ma============ Content-Type: text/html; charset="us-ascii" Re: [saag] [secdir] Interest in draft-dong-savi-cga-heade
At 4:14 AM -0400 7/29/10, Sam Hartman wrote:
>>>>> "Stephen" == Stephen Kent <kent@bbn.com> writes:

    Stephen> I agree that the primary motivation for CGAs arose in the
    Stephen> SeND context, and that privacy is an independent
    Stephen> feature. But, the context in which CGAs were intended to
    Stephen> provide an ability to establish a binding to an IPv6
    Stephen> address was local. When one moves beyond this local
    Stephen> context, and one advocates having more distant nodes
    Stephen> challenge a host, this creates privacy questions.

I think we've been looking at CGAs that have non-local scope for a
while.  Section 7.4 of RFC 3972 seems to anticipate CGAs used with other
protocols.  It's my understanding that shim6 supports both HBAs and CGAs
for non-local contexts.  I also believe the MIP6 context for CGA use is
non-local.

I don't know about MIP6, but when I read the second paragraph of section 7.4 in the CGA RFC, I get a different impression. The fact that the paragraph begins with "Finally, a strong cautionary note has to be made about using CGA signatures for purposes other than SEND." suggests to me that the authors anticipated that others might want to use CGAs elsewhere. They provided a list of comments about why CGAs were designed for and well-suited to the SeND context (which is local), and warnings about the limitations that arise if one tries to use CGAs elsewhere.

Steve
--============_-930735219==_ma============-- From hannes.tschofenig@nsn.com Wed Aug 11 03:41:35 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 615D13A6944 for ; Wed, 11 Aug 2010 03:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 2hc2gAI66Zcj for ; Wed, 11 Aug 2010 03:41:34 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id E3DA13A687D for ; Wed, 11 Aug 2010 03:41:33 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o7BAg92t008020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 11 Aug 2010 12:42:09 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7BAg39W025777 for ; Wed, 11 Aug 2010 12:42:08 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Aug 2010 12:42:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB3941.D61282A1" Date: Wed, 11 Aug 2010 13:42:03 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502E5D294@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback solicited for Privacy and Identity Management Terminology Thread-Index: Acs5Pbrtc0mnhCSWQKKlv5j+0VBcfA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 11 Aug 2010 10:42:05.0034 (UTC) FILETIME=[D6D82CA0:01CB3941] Subject: [saag] Feedback solicited for Privacy and Identity Management Terminology X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 10:41:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB3941.D61282A1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 we have just submitted a new version of the privacy and identity management terminology document: http://www.ietf.org/internet-drafts/draft-hansen-privacy-terminology-01. txt =20 The full document titel is "Terminology for Talking about Privacy by Data Minimization: Anonymity, Unlinkability, Undetectability, Unobservability, Pseudonymity, and Identity Management" and here is the abstract:=20 This document is an attempt to consolidate terminology in the field privacy by data minimization. It motivates and develops definitions for anonymity/identifiability, (un)linkability, (un)detectability, (un)observability, pseudonymity, identity, partial identity, digital identity and identity management. Starting the definitions from the anonymity and unlinkability perspective and not from a definition of identity (the latter is the obvious approach to some people) reveals some deeper structures in this field. =20 Please let us know whether the terminology is useful and complete. Your input is highly appreciated! Ciao Hannes ------_=_NextPart_001_01CB3941.D61282A1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Feedback solicited for Privacy and Identity Management = Terminology

Hi all,

we have just submitted a new = version of the privacy and identity management terminology = document:
http://www.ietf.org/internet-drafts/draft-hansen-privacy-terminology= -01.txt
 
The full document titel is = "Terminology for Talking about Privacy by Data Minimization: = Anonymity, Unlinkability, Undetectability, Unobservability, = Pseudonymity, and Identity Management" and here is the abstract: =

   This document is an = attempt to consolidate terminology in the field
   privacy by data = minimization.  It motivates and develops definitions
   for = anonymity/identifiability, (un)linkability, (un)detectability,
   (un)observability, = pseudonymity, identity, partial identity, digital
   identity and = identity management.  Starting the definitions from the
   anonymity and = unlinkability perspective and not from a definition of
   identity (the = latter is the obvious approach to some people) reveals
   some deeper = structures in this field.
  
Please let us know whether the = terminology is useful and complete. Your input is highly = appreciated!

Ciao
Hannes


------_=_NextPart_001_01CB3941.D61282A1-- From Jan.Pechanec@Sun.COM Tue Aug 10 06:36:55 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C3CC3A69D2 for ; Tue, 10 Aug 2010 06:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.966 X-Spam-Level: X-Spam-Status: No, score=-5.966 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 FMJhxOzeParN for ; Tue, 10 Aug 2010 06:36:54 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) by core3.amsl.com (Postfix) with ESMTP id 860AB3A6A02 for ; Tue, 10 Aug 2010 06:36:52 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o7ADbQD9020010 for ; Tue, 10 Aug 2010 13:37:26 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L6X00J00UZ4CA00@fe-emea-10.sun.com> for saag@ietf.org; Tue, 10 Aug 2010 14:37:05 +0100 (BST) Received: from rejewski ([unknown] [10.18.138.121]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L6X00K7GV5SG100@fe-emea-10.sun.com>; Tue, 10 Aug 2010 14:37:05 +0100 (BST) Date: Tue, 10 Aug 2010 15:36:12 +0200 (CEST) From: Jan Pechanec In-reply-to: Sender: Jan.Pechanec@Sun.COM X-X-Sender: jp161948@rejewski To: Stef Walter Message-id: References: <4C5515AD.9020603@gnome.org> <4C56E7EA.5020701@gnome.org> <4C57124B.3020403@gnome.org> X-Mailman-Approved-At: Thu, 12 Aug 2010 08:01:51 -0700 Cc: Darren.Moffat@oracle.com, saag@ietf.org, Nikos Mavrogiannopoulos Subject: Re: [saag] I-D on PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 13:36:55 -0000 On Tue, 3 Aug 2010, Jan Pechanec wrote: >>Okay, so this is different than RFC 3986, where whitespace (unless >>percent encoded) is to be ignored by a parser. That said, in practice >>many (most?) URI parsers preserve whitespace, so I agree that we can be >>more lenient in the encoding of newlines or spaces. hi Stef, I'm fine with all the suggestions and would like to generate a new draft that I'd sent here before filing it. I'm not sure about one thing though - the space. I hope we can use it literarily in the PKCS#11 URI. However, you mention it should be ignored by the parser unless encoded as %20. when reading RFC 3968, it's not in reserverd characters (section 2.2), it's not in unreserved (2.3). I found this: Appendix C. Delimiting a URI in Context In some cases, extra whitespace (spaces, line-breaks, tabs, etc.) may have to be added to break a long URI across lines. The whitespace should be ignored when the URI is extracted. Using <> angle brackets around each URI is especially recommended as a delimiting style for a reference that contains embedded whitespace. does "embedded whitespace" means a space that is part of the attribute value? BTW, Firefox allows to use a literal space in URL. It encodes all spaces in the HTTP request though. given that the space is not in unreserved characters, I tend to think it must be used as %20... cheers, J. > I think I have to take a closer look at the RFC but I think we >should allow spaces as spaces. > >>>>> as mentioned, I'd also replace the current ck_id encoding with >>>>> the %hh encoding. >> >>FWIW, the hex encoding of a URI is defined as upper case in RFC 3986 [3]. > > ok > >>I realize I keep pointing to RFC 3986, but that's because we're calling >>it a 'URI'. If we choose to differ from the definition of URI in the >>above aspects, I think it would be important to note these differences >>in the PKCS#11 URI specification. > > I think we should follow RFC 3986 as much as possible, I'll read >through it properly and get back to you. > > thanks, J. > >>[1] http://tools.ietf.org/html/rfc3986#section-2.4 >> >>[2] http://tools.ietf.org/html/rfc3986#section-2.5 >> >>[3] http://tools.ietf.org/html/rfc3986#section-2.1 >> > > -- Jan Pechanec http://blogs.sun.com/janp From Jan.Pechanec@Sun.COM Tue Aug 10 06:38:29 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECBE43A69DB for ; Tue, 10 Aug 2010 06:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.124 X-Spam-Level: X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 0XA-j0TQt1MY for ; Tue, 10 Aug 2010 06:38:26 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) by core3.amsl.com (Postfix) with ESMTP id 9BDA43A69C6 for ; Tue, 10 Aug 2010 06:38:25 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o7ADcxQO020168 for ; Tue, 10 Aug 2010 13:38:59 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L6X00B00UY1L700@fe-emea-09.sun.com> for saag@ietf.org; Tue, 10 Aug 2010 14:38:45 +0100 (BST) Received: from rejewski ([unknown] [10.18.138.121]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L6X00E8WV8LVBB0@fe-emea-09.sun.com>; Tue, 10 Aug 2010 14:38:45 +0100 (BST) Date: Tue, 10 Aug 2010 15:37:52 +0200 (CEST) From: Jan Pechanec In-reply-to: <4C5907E2.1070303@gnome.org> Sender: Jan.Pechanec@Sun.COM X-X-Sender: jp161948@rejewski To: Stef Walter Message-id: References: <4C5515AD.9020603@gnome.org> <4C56E7EA.5020701@gnome.org> <4C57124B.3020403@gnome.org> <4C5907E2.1070303@gnome.org> X-Mailman-Approved-At: Thu, 12 Aug 2010 08:01:51 -0700 Cc: Darren.Moffat@oracle.com, saag@ietf.org, Nikos Mavrogiannopoulos Subject: Re: [saag] I-D on PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 13:38:29 -0000 On Wed, 4 Aug 2010, Stef Walter wrote: >> On Mon, 2 Aug 2010, Stef Walter wrote: >>> Jan Pechanec wrote: >>> as mentioned, I'd also replace the current ck_id encoding with >>> the %hh encoding. >> >> FWIW, the hex encoding of a URI is defined as upper case in RFC 3986 [3]. > >I've been thinking about the CKA_ID encoding further, and because it's >arbitrary binary data percent encoding may not be the best fit... I >realize I suggested percent encoding, and perhaps percent encoding could >work, but it may be out of the ordinary to use percent encoding for >predominantly binary data. > >For example the data: URI uses base64 encoding instead. It seems that a >straight forward hex encoding or base64 encoding is more common to use >in a URI when raw binary data is encoded. > >But I'm fine with any of these approaches to encoding the CKA_ID. >Technically they would all work. hi Stef, I'd prefer the percent encoding since that can be done by hand. One needs another tool to encode data into the base64 form. J. -- Jan Pechanec http://blogs.sun.com/janp From Jan.Pechanec@Sun.COM Mon Aug 16 08:30:21 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F09B53A69F1 for ; Mon, 16 Aug 2010 08:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.919 X-Spam-Level: X-Spam-Status: No, score=-5.919 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_50=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 wdkPGB38Vwvi for ; Mon, 16 Aug 2010 08:30:14 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) by core3.amsl.com (Postfix) with ESMTP id EFFD63A67F1 for ; Mon, 16 Aug 2010 08:30:10 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o7GFUj2j024555 for ; Mon, 16 Aug 2010 15:30:46 GMT MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_5KNNr+YWPN+DTJbJ6OI4dQ)" Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L7900L004AHVP00@fe-emea-10.sun.com> for saag@ietf.org; Mon, 16 Aug 2010 16:30:26 +0100 (BST) Received: from rejewski ([unknown] [10.18.138.121]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L7900BFH4ENQ930@fe-emea-10.sun.com>; Mon, 16 Aug 2010 16:30:23 +0100 (BST) Date: Mon, 16 Aug 2010 18:29:28 +0200 (CEST) From: Jan Pechanec Sender: Jan.Pechanec@Sun.COM X-X-Sender: jp161948@rejewski To: Stef Walter , Nikos Mavrogiannopoulos , saag@ietf.org Message-id: Content-id: X-Mailman-Approved-At: Tue, 17 Aug 2010 08:14:45 -0700 Cc: Darren.Moffat@oracle.com Subject: [saag] new I-D on the PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 15:30:21 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --Boundary_(ID_5KNNr+YWPN+DTJbJ6OI4dQ) Content-id: Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT hi, attached is a new draft. I haven't filed that yet, if you have any comments or issues, I'd like to incorporated those before filing the 02 version. thanks, Jan. -- Jan Pechanec http://blogs.sun.com/janp --Boundary_(ID_5KNNr+YWPN+DTJbJ6OI4dQ) Content-id: Content-type: TEXT/PLAIN; CHARSET=US-ASCII; name=draft-pechanec-pkcs11uri-02.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-pechanec-pkcs11uri-02.txt Content-description: Network Working Group J. Pechanec Internet-Draft Sun Microsystems, Inc. Intended status: Standards Track D. Moffat Expires: February 17, 2011 Oracle Corporation August 16, 2010 The PKCS#11 URI Scheme draft-pechanec-pkcs11uri-02 Abstract This memo specifies a PKCS#11 Uniform Resource Identifier (URI) Scheme for identifying PKCS#11 objects stored in PKCS#11 tokens, or for identifying PKCS#11 tokens themselves. The URI is based on how PKCS#11 objects and tokens are identified in the PKCS#11 Cryptographic Token Interface Standard. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 17, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Pechanec & Moffat Expires February 17, 2011 [Page 1] Internet-Draft The PKCS#11 URI Scheme August 2010 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. PKCS#11 URI Scheme Definition . . . . . . . . . . . . . . . . . 3 2.1. PKCS#11 URI Scheme Name . . . . . . . . . . . . . . . . . . 3 2.2. PKCS#11 URI Scheme Status . . . . . . . . . . . . . . . . . 3 2.3. PKCS#11 URI Scheme Syntax . . . . . . . . . . . . . . . . . 3 3. Examples of PKCS#11 URI Schemes . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Pechanec & Moffat Expires February 17, 2011 [Page 2] Internet-Draft The PKCS#11 URI Scheme August 2010 1. Introduction The PKCS #11: Cryptographic Token Interface Standard [pkcs11_spec] specifies an API, called Cryptoki, for devices which hold cryptographic information and perform cryptographic functions. Cryptoki, pronounced crypto-key and short for cryptographic token interface, follows a simple object-based approach, addressing the goals of technology independence (any kind of device may be used) and resource sharing (multiple applications may access multiple devices), presenting applications with a common, logical view of the device - a cryptographic token. It is desirable for applications or libraries that work with PKCS#11 tokens to accept a common identifier that consumers could use to identify an existing PKCS#11 object in a PKCS#11 token, or an existing token itself. The set of object types that can be stored in a PKCS#11 token includes a public key, a private key, a certificate, a secret key, and a data object. These objects can be uniquely identifiable via the PKCS#11 URI scheme defined in this document. The set of attributes that identifies a PKCS#11 token can contain a token label, a manufacturer name, a serial number, and a token model. Note that the PKCS#11 URI is not intended to be used to create new PKCS#11 objects in tokens, or to create PKCS#11 tokens. It is solely to be used to identify existing objects or existing tokens. 2. PKCS#11 URI Scheme Definition In accordance with [RFC4395], this section provides the information required to register the PKCS#11 URI scheme. 2.1. PKCS#11 URI Scheme Name pkcs11 2.2. PKCS#11 URI Scheme Status Permanent. 2.3. PKCS#11 URI Scheme Syntax The PKCS#11 URI scheme is a sequence of attribute value pairs. Most attributes allow for an UTF-8 string to be used as an value. In accordance with [RFC3986], the data should first be encoded as octets according to the UTF-8 character encoding [RFC3629]; then only those octets that do not correspond to characters in the unreserved set or to permitted characters from the reserved set should be percent- Pechanec & Moffat Expires February 17, 2011 [Page 3] Internet-Draft The PKCS#11 URI Scheme August 2010 encoded. Rules "unreserved" and "pct-encoded" in the PKCS#11 URI specification below were imported from [RFC3986]. As a special case, note that according to [RFC3986], a space must be percent-encoded. A PKCS#11 URL takes the form (for explanation of Augmented BNF, see [RFC5234]): pk11-URI = "pkcs11" ":" pk11-identifier pk11-identifier = *1( pk11-attr *( ";" pk11-attr ) ) pk11-attr = pk11-token / pk11-manufacturer / pk11-serial / pk11-model / pk11-object / pk11-objecttype / pk11-id / pk11-pinfile ; Section 2.2 of RFC 3986 specifies that all potentially reserved ; characters that do not conflict with actual delimiters of the URI ; do not have to be percent-encoded. So, we just removed ";". pk11-reserved-avail = ":" / "/" / "?" / "#" / "[" / "]" / "@" / "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / "=" pk11-value = *( unreserved / pk11-reserved-avail / ; pct-encoded ) ; The "pk11-ck-char" rule contains a complete list of characters ; of the CK_CHAR type as defined in the PKCS#11 specification. Those ; are a-z, A-Z, 0-9, a space, and all special characters from the ; following list: !"#%&'()*+,-./:;<=>?[\]^_{|}~. Note that some ; special characters not part of the reserved and unreserved sets ; must be percent-encoded. pk11-ck-char = unreserved / "%20" / "!" / "%22" / "#" / "%25" / "&" / "'" / "(" / ")" / "*" / "+" / "," / "-" / "." / "/" / ":" / "%3B" / "%3C" / "=" / "%3E" / "?" / "[" / "%5C" / "]" / "%5E" / "_" / "%7B" / "%7C" / "%7D" / "~" ; Corresponds to the label field of the CK_TOKEN_INFO structure. pk11-token = "token" "=" pk11-value ; Corresponds to the manufacturerID field of the CK_TOKEN_INFO ; structure. pk11-manufacturer = "manufacturer" "=" pk11-value ; Corresponds to the serialNumber field of the CK_TOKEN_INFO structure. pk11-serial = "serial" "=" *pk11-ck-char ; Corresponds to the model field of the CK_TOKEN_INFO structure. pk11-model = "model" "=" pk11-value ; Corresponds to the CKA_LABEL object attribute. pk11-object = "object" "=" pk11-value ; Corresponds to the CKA_CLASS object attribute. pk11-objecttype = "objecttype" "=" ( "public" / "private" / "cert" / "secretkey" / "data" ) ; Corresponds to the CKA_ID object attribute. pk11-id = "id" "=" *pct-encoded Pechanec & Moffat Expires February 17, 2011 [Page 4] Internet-Draft The PKCS#11 URI Scheme August 2010 pk11-pinfile = "pinfile" "=" pk11-value While the PKCS#11 specification limits the length of some fields, eg. the manufacturer label can be up to thirty-two characters long, the PKCS#11 URI does not impose such limitations. It is up to the consumer of the PKCS#11 URI to perform any necessary sanity length checks. The attribute "token" represents a token label, the attribute "manufacturer" represents a manufacturer ID, the attribute "serial" represents a token serial number, the attribute "model" represents a token model, the attribute "object" represents a PKCS#11 object label, the attribute "objecttype" represents the type of the object, the attribute "id" represents the object ID, and the attribute "pinfile" specifies where the application or library should find the token PIN, if needed. Application could overload this attribute. For example, "pinfile=%7Cprog-name" could mean to read a PIN from an external application (%7C denotes a pipe '|' character). Note that an application can always ask for a PIN by any means it decides to. 3. Examples of PKCS#11 URI Schemes This section contains some examples of how PKCS#11 tokens or PKCS#11 token objects can be identified using the PKCS#11 URI scheme. Note that in some of the following examples, newlines and spaces were inserted for better readability which is allowed by [RFC3986]. Also note that all spaces as part of the URI are percent-encoded, as required by [RFC3986]. An empty PKCS#11 URI might be useful to PKCS#11 consumers: pkcs11: One of the simplest and most useful forms might be a PKCS#11 URI that specifies only an object label and its type. The default token is used so the URI does not specify it. Note that when specifying public objects, a token PIN might not be required. pkcs11:object=my-pubkey;objecttype=public When a private key is specified either the "pinfile" attribute or an application specific method must be used: pkcs11:object=my-key;objecttype=private;pinfile=/etc/ssh/token_pin Pechanec & Moffat Expires February 17, 2011 [Page 5] Internet-Draft The PKCS#11 URI Scheme August 2010 The following example identifies a certificate in the software token. Note that all attributes aside from "objecttype" may have an empty value. In our case, "serial" is empty. It is up to the consumer of the URI to perform necessary checks if that is not allowed. Note the notation of the "id" attribute value which is entirely percent- encoded. pkcs11:token=The%20Software%20PKCS#11%20softtoken; manufacturer=Snake%20Oil,%20Inc.; serial=; model=1.0; object=my-certificate; objecttype=cert; id=%69%95%3e%5c%f4%bd%ec%91; pinfile=/etc/ssh/token_pin The token alone can be identified without specifying any PKCS#11 objects. A PIN may still be needed to list all objects, for example. pkcs11:token=Software%20PKCS#11%20softtoken; manufacturer=Snake%20Oil,%20Inc.; pinfile=/etc/ssh/token_pin The following example shows that the attribute value can contain a semicolon. In such case, it is percent-encoded. We can also have capital letters in the "id" attribute value. pkcs11:token=My%20token%25%20created%20by%20Joe; object=my-certificate; objecttype=cert; id=69:95:3E:5C:F4:BD:EC:91; pinfile=/etc/ssh/token_pin And if there is any need to include literal '%;' substring, for example, we must escape both characters. The token value must be read as "The token name with a strange substring '\;'" then. pkcs11:token=A%20name%20with%20a%20strange%20substring%'%25%3B'; object=my-certificate; objecttype=cert; pinfile=/etc/ssh/token_pin The next example includes a small A with acute in the token name. We must encode it in octets according to the UTF-8 character encoding and then use the percent-encoding. Given that a small A with acute is U+225 unicode code point, the UTF-8 encoding is 195 161 in decimal, which is "%C3%A1" in the percent-encoding. Pechanec & Moffat Expires February 17, 2011 [Page 6] Internet-Draft The PKCS#11 URI Scheme August 2010 pkcs11:token=Name%20with%20a%20small%20A%20with%20acute:%20%C3%A1; object=my-certificate; objecttype=cert; 4. IANA Considerations This document registers a URI scheme. The registration template can be found in Section 2 of this document. 5. Security Considerations There are many security considerations for URI schemes discussed in [RFC3986]. Given that the PKCS#11 URI is also supposed to be used in command line arguments to running programs, and those arguments can be world readable on some systems, the URI intentionaly does not allow for specifying the PKCS#11 token PIN as a URI attribute. 6. Normative References [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, STD 63, November 2003. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, January 2005. [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", RFC 4395, February 2006. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. [pkcs11_spec] RSA Laboratories, "PKCS #11: Cryptographic Token Interface Standard v2.20", June 2004. Pechanec & Moffat Expires February 17, 2011 [Page 7] Internet-Draft The PKCS#11 URI Scheme August 2010 Authors' Addresses Jan Pechanec Sun Microsystems, Inc. The Park, building 3 V parku 2308/8 Prague 14800 CZ Phone: +420 233 009 380 Email: Jan.Pechanec@Sun.COM URI: http://www.sun.com Darren J. Moffat Oracle Corporation Guillemont Park Building 3 Camberley GU17 9QG UK Email: Darren.Moffat@Oracle.COM URI: http://www.oracle.com Pechanec & Moffat Expires February 17, 2011 [Page 8] --Boundary_(ID_5KNNr+YWPN+DTJbJ6OI4dQ)-- From Darren.Moffat@oracle.com Mon Aug 16 09:19:30 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA50B3A69EC for ; Mon, 16 Aug 2010 09:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Y0i9TidlX9Q0 for ; Mon, 16 Aug 2010 09:19:29 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id A03053A6820 for ; Mon, 16 Aug 2010 09:19:29 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7GGJenO016227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Aug 2010 16:19:42 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7G8xx5W017812; Mon, 16 Aug 2010 16:19:38 GMT Received: from abhmt003.oracle.com by acsmt355.oracle.com with ESMTP id 521044641281975487; Mon, 16 Aug 2010 09:18:07 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 Aug 2010 09:18:06 -0700 Message-ID: <4C6964BA.1010406@Oracle.COM> Date: Mon, 16 Aug 2010 17:18:02 +0100 From: Darren J Moffat Organization: Oracle Solaris Security User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.4) Gecko/20100719 Lightning/1.0b2 OracleBeehiveExtension/1.0.0.0pre10-Champion Thunderbird/3.1 MIME-Version: 1.0 To: Jan Pechanec References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 17 Aug 2010 08:14:40 -0700 Cc: saag@ietf.org, Nikos Mavrogiannopoulos Subject: Re: [saag] new I-D on the PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 16:25:24 -0000 On 16/08/2010 17:29, Jan Pechanec wrote: > hi, attached is a new draft. I haven't filed that yet, if you > have any comments or issues, I'd like to incorporated those before > filing the 02 version. I'm fairly sure the use of the ';' sub-separator may have come from me but I'm now wondering if we should be using '?' instead since essentially these are query components since they are in many cases going to be passed to the PKCS#11 C_FindObjects*() set of functions (or their equivalent). The pinfile though I think should be ';' separated since it isn't actually part of the tokens that identify the object. For example: pkcs11:object=my-pubkey?objecttype=public pkcs11:object=my-key?objecttype=private;pinfile=/secrets/mytoken_pin I don't think we would have a '?' after the ':' just like currently we don't have a ';' after the ':'. I don't really have a strong preference, more just throwing it out for discussion. I'm pretty sure our lack of "//" after the ':' is correct since there isn't an authority to specify here. -- Darren J Moffat From Jan.Pechanec@Sun.COM Mon Aug 16 12:52:18 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 359C03A6A2B for ; Mon, 16 Aug 2010 12:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 LQkT9pM8rit2 for ; Mon, 16 Aug 2010 12:52:17 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) by core3.amsl.com (Postfix) with ESMTP id 0D1A33A6A74 for ; Mon, 16 Aug 2010 12:52:15 -0700 (PDT) Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o7GJqpGJ010679 for ; Mon, 16 Aug 2010 19:52:51 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L7900G00GEWX100@fe-emea-13.sun.com> for saag@ietf.org; Mon, 16 Aug 2010 20:52:30 +0100 (BST) Received: from rejewski ([unknown] [10.18.138.121]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L7900GUJGJIQH10@fe-emea-13.sun.com>; Mon, 16 Aug 2010 20:52:30 +0100 (BST) Date: Mon, 16 Aug 2010 22:51:34 +0200 (CEST) From: Jan Pechanec In-reply-to: <4C6964BA.1010406@Oracle.COM> Sender: Jan.Pechanec@Sun.COM X-X-Sender: jp161948@rejewski To: Darren J Moffat Message-id: References: <4C6964BA.1010406@Oracle.COM> X-Mailman-Approved-At: Tue, 17 Aug 2010 08:14:48 -0700 Cc: saag@ietf.org, Nikos Mavrogiannopoulos Subject: Re: [saag] new I-D on the PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 19:52:18 -0000 On Mon, 16 Aug 2010, Darren J Moffat wrote: > On 16/08/2010 17:29, Jan Pechanec wrote: >> hi, attached is a new draft. I haven't filed that yet, if you >> have any comments or issues, I'd like to incorporated those before >> filing the 02 version. > > I'm fairly sure the use of the ';' sub-separator may have come from me but I'm > now wondering if we should be using '?' instead since essentially these are > query components since they are in many cases going to be passed to the PKCS#11 > C_FindObjects*() set of functions (or their equivalent). > > The pinfile though I think should be ';' separated since it isn't actually part > of the tokens that identify the object. > > For example: > > pkcs11:object=my-pubkey?objecttype=public > pkcs11:object=my-key?objecttype=private;pinfile=/secrets/mytoken_pin so object would be part of the path and anything else is part of the query? That does not seem to be complete to me. If there is to be a path and a query then the token attributes should be part of the path as well, I think. we should be also able to reference tokens aside from referencing objects so the "object" attribute may be missing. On the other hand, if we use a query then all attributes aside from a pinfile may be part of it since all such attributes can be used in the C_Findbject*() functions. And the pinfile attr does not fit anywhere. Anyway, I think it might be more complicated than needed. path does not have to be hierarchical so we can put all attributes into the path as it is now, including the pinfile. Also, only "?" or "/" can separate data within the query component (at least that's what I understand from "3.4 Query" section). That would mean that the pinfile attribute could not be separated by ";" in the query. I think there is a thin line between a path and a query. A path with wildcards can be easily seen as a query, for example: /etc/* > I don't think we would have a '?' after the ':' just like currently we don't > have a ';' after the ':'. > > I don't really have a strong preference, more just throwing it out for > discussion. I'd rather keep the current approach, it seems simpler to me. > I'm pretty sure our lack of "//" after the ':' is correct since there isn't an > authority to specify here. yes, I agree. the draft is probably lacking a section that would discuss what components from the generic URI are used and why. J. -- Jan Pechanec http://blogs.sun.com/janp From n.mavrogiannopoulos@gmail.com Tue Aug 17 01:23:25 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE3613A68C5 for ; Tue, 17 Aug 2010 01:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 y73EWT9ihAbF for ; Tue, 17 Aug 2010 01:23:25 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 116233A6784 for ; Tue, 17 Aug 2010 01:23:24 -0700 (PDT) Received: by qyk9 with SMTP id 9so3239797qyk.10 for ; Tue, 17 Aug 2010 01:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=bYpZuqZR1vg8i3XAP7w4RzO36RCN3PPKeDaxp8xj1Gc=; b=e7MgidgemEqay/YE11s07IG64G/nnScp9qRBZPM+xqWvH4Fyrd0Fh+e7kZqQnjxEbU drNnEGEGDw/VFn9aXnjbX3HDh1+EFdIBtIGeAj41fZEsHhe+xu43QHd7MFnwyp41odEl hmDUyayKnbIpAp5vY6RbVvBIpwrD7csRa9ESA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=aaDkl/bpfte/OdhwtTcrFyJrEUgugVxR8wrPXdzMUj9WxvcqkDCZYvGTF+/H3SYWtj Mesmos9dk8eNJ2VAPf6fx+chsM36+ogRveH+iaCOBssVo5HuH4WvOvIWSMA+lUKWdL3e CQy/YbShKqwxZ0PgPauDaO51HkPCjTSFE3JRg= MIME-Version: 1.0 Received: by 10.224.29.1 with SMTP id o1mr4084628qac.77.1282033440490; Tue, 17 Aug 2010 01:24:00 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.31.205 with HTTP; Tue, 17 Aug 2010 01:24:00 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 Aug 2010 10:24:00 +0200 X-Google-Sender-Auth: 3MSkz2Jk-e1N_bUa0O1ZRDeLAe4 Message-ID: From: Nikos Mavrogiannopoulos To: Jan Pechanec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 17 Aug 2010 08:14:51 -0700 Cc: Darren.Moffat@oracle.com, saag@ietf.org Subject: Re: [saag] new I-D on the PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 08:23:26 -0000 Hello, I like the changes. May I suggest the addition of the following fields: ; The CK_INFO manufacturer ID field pk11-lib-manufacturer =3D "library-manufacturer" "=3D" pk11-value ; The CK_INFO library version field pk11-version-value =3D [0-9]+ "." [0-9]+ pk11-lib-version =3D "library-version" "=3D" pk11-version-value ; The CK_INFO library description field pk11-lib-description =3D "library-description" "=3D" pk11-value Those would allow to uniquely identify an object across a system with several pkcs #11 providers. best regards, Nikos On Mon, Aug 16, 2010 at 6:29 PM, Jan Pechanec wrote: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0hi, attached is a new draft. I haven't filed t= hat yet, if you > have any comments or issues, I'd like to incorporated those before > filing the 02 version. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0thanks, Jan. > > -- > Jan Pechanec > http://blogs.sun.com/janp > From Jan.Pechanec@Sun.COM Tue Aug 17 04:10:30 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE3463A68E7 for ; Tue, 17 Aug 2010 04:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.285 X-Spam-Level: X-Spam-Status: No, score=-6.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 VwhFz5BdaILk for ; Tue, 17 Aug 2010 04:10:16 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) by core3.amsl.com (Postfix) with ESMTP id D93953A687C for ; Tue, 17 Aug 2010 04:10:11 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o7HBAkKx026543 for ; Tue, 17 Aug 2010 11:10:46 GMT MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_1Nq+L5V/FKX/TjJv4dAoKw)" Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L7A00000MREAA00@fe-emea-09.sun.com> for saag@ietf.org; Tue, 17 Aug 2010 12:10:21 +0100 (BST) Received: from rejewski ([unknown] [10.18.138.121]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L7A00J3CN182K20@fe-emea-09.sun.com>; Tue, 17 Aug 2010 12:10:21 +0100 (BST) Date: Tue, 17 Aug 2010 13:10:21 +0200 (CEST) From: Jan Pechanec In-reply-to: Sender: Jan.Pechanec@Sun.COM X-X-Sender: jp161948@rejewski To: Nikos Mavrogiannopoulos Message-id: References: X-Mailman-Approved-At: Tue, 17 Aug 2010 08:14:49 -0700 Cc: Darren.Moffat@oracle.com, saag@ietf.org Subject: Re: [saag] new I-D on the PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 11:10:31 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --Boundary_(ID_1Nq+L5V/FKX/TjJv4dAoKw) Content-type: TEXT/PLAIN; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE On Tue, 17 Aug 2010, Nikos Mavrogiannopoulos wrote: >Hello, > I like the changes. May I suggest the addition of the following fie= lds: > > ; The CK_INFO manufacturer ID field > pk11-lib-manufacturer =3D "library-manufacturer" "=3D" pk11-v= alue > ; The CK_INFO library version field > pk11-version-value =3D [0-9]+ "." [0-9]+ > pk11-lib-version =3D "library-version" "=3D" pk11-version-val= ue > ; The CK_INFO library description field > pk11-lib-description =3D "library-description" "=3D" pk11-val= ue > >Those would allow to uniquely identify an object across a system wit= h >several pkcs #11 providers. =09I agree, that seems reasonable. The syntax of the version will= =20 be using 1*DIGIT but that's just a technical point. =09Darren? =09J. >best regards, >Nikos > >On Mon, Aug 16, 2010 at 6:29 PM, Jan Pechanec = wrote: >> >> =A0 =A0 =A0 =A0hi, attached is a new draft. I haven't filed that y= et, if you >> have any comments or issues, I'd like to incorporated those before >> filing the 02 version. >> >> =A0 =A0 =A0 =A0thanks, Jan. >> >> -- >> Jan Pechanec >> http://blogs.sun.com/janp >> > --=20 Jan Pechanec http://blogs.sun.com/janp --Boundary_(ID_1Nq+L5V/FKX/TjJv4dAoKw)-- From Darren.Moffat@oracle.com Tue Aug 17 04:15:20 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EE563A693A for ; Tue, 17 Aug 2010 04:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 iq2s7xggghYQ for ; Tue, 17 Aug 2010 04:15:19 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id A36393A68B0 for ; Tue, 17 Aug 2010 04:15:19 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7HBFQ7F021222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Aug 2010 11:15:28 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7FNSQi2027517; Tue, 17 Aug 2010 11:15:25 GMT Received: from abhmt003.oracle.com by acsmt353.oracle.com with ESMTP id 502954551282043679; Tue, 17 Aug 2010 04:14:39 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 17 Aug 2010 04:14:39 -0700 Message-ID: <4C6A6F1C.7070502@Oracle.COM> Date: Tue, 17 Aug 2010 12:14:36 +0100 From: Darren J Moffat Organization: Oracle Solaris Security User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.4) Gecko/20100719 Lightning/1.0b2 OracleBeehiveExtension/1.0.0.0pre10-Champion Thunderbird/3.1 MIME-Version: 1.0 To: Jan Pechanec References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 17 Aug 2010 08:14:43 -0700 Cc: saag@ietf.org, Nikos Mavrogiannopoulos Subject: Re: [saag] new I-D on the PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 11:15:20 -0000 On 17/08/2010 12:10, Jan Pechanec wrote: > On Tue, 17 Aug 2010, Nikos Mavrogiannopoulos wrote: > >> Hello, >> I like the changes. May I suggest the addition of the following fields: >> >> ; The CK_INFO manufacturer ID field >> pk11-lib-manufacturer = "library-manufacturer" "=" pk11-value >> ; The CK_INFO library version field >> pk11-version-value = [0-9]+ "." [0-9]+ >> pk11-lib-version = "library-version" "=" pk11-version-value >> ; The CK_INFO library description field >> pk11-lib-description = "library-description" "=" pk11-value >> >> Those would allow to uniquely identify an object across a system with >> several pkcs #11 providers. > > I agree, that seems reasonable. The syntax of the version will > be using 1*DIGIT but that's just a technical point. > > Darren? Looks perfectly reasonable addition to me. -- Darren J Moffat From Jan.Pechanec@Sun.COM Tue Aug 17 04:59:44 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE18E3A693A for ; Tue, 17 Aug 2010 04:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.324 X-Spam-Level: X-Spam-Status: No, score=-7.324 tagged_above=-999 required=5 tests=[AWL=1.275, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 c8MgpFV97AF2 for ; Tue, 17 Aug 2010 04:59:42 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) by core3.amsl.com (Postfix) with ESMTP id 578F83A67F4 for ; Tue, 17 Aug 2010 04:59:42 -0700 (PDT) Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o7HC0Eh6001281 for ; Tue, 17 Aug 2010 12:00:15 GMT MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_X4CwetglJmO+pcD4tCiHcg)" Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L7A00E00P5SER00@fe-emea-13.sun.com> for saag@ietf.org; Tue, 17 Aug 2010 12:59:54 +0100 (BST) Received: from rejewski ([unknown] [10.18.138.121]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L7A00D1IPBTP2E0@fe-emea-13.sun.com>; Tue, 17 Aug 2010 12:59:54 +0100 (BST) Date: Tue, 17 Aug 2010 13:59:51 +0200 (CEST) From: Jan Pechanec In-reply-to: Sender: Jan.Pechanec@Sun.COM X-X-Sender: jp161948@rejewski To: Nikos Mavrogiannopoulos Message-id: Content-id: References: X-Mailman-Approved-At: Tue, 17 Aug 2010 08:14:50 -0700 Cc: Darren.Moffat@oracle.com, saag@ietf.org Subject: Re: [saag] new I-D on the PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 11:59:44 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --Boundary_(ID_X4CwetglJmO+pcD4tCiHcg) Content-id: Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Tue, 17 Aug 2010, Jan Pechanec wrote: >On Tue, 17 Aug 2010, Nikos Mavrogiannopoulos wrote: > >>Hello, >> I like the changes. May I suggest the addition of the following fields: >> >> ; The CK_INFO manufacturer ID field >> pk11-lib-manufacturer = "library-manufacturer" "=" pk11-value >> ; The CK_INFO library version field >> pk11-version-value = [0-9]+ "." [0-9]+ >> pk11-lib-version = "library-version" "=" pk11-version-value >> ; The CK_INFO library description field >> pk11-lib-description = "library-description" "=" pk11-value >> >>Those would allow to uniquely identify an object across a system with >>several pkcs #11 providers. > > I agree, that seems reasonable. The syntax of the version will >be using 1*DIGIT but that's just a technical point. attached is a modified draft. I added three attributes listed above and also one example that shows that the URI can be used to identify the library alone without any objects. if I understand the spec correctly: typedef struct CK_VERSION { CK_BYTE major; /* integer portion of version number */ CK_BYTE minor; /* 1/100ths portion of version number */ } CK_VERSION; then the minor version must be 0-99, so the lib version attribute is defined as: pk11-lib-ver = "library-version" "=" 1*DIGIT "." 1*2DIGIT in theory we should limit the major version to 0-255 (CK_BYTE) but I'm not sure it's worth it. Is it? J. -- Jan Pechanec http://blogs.sun.com/janp --Boundary_(ID_X4CwetglJmO+pcD4tCiHcg) Content-id: Content-type: TEXT/PLAIN; CHARSET=US-ASCII; name=draft-pechanec-pkcs11uri-02.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-pechanec-pkcs11uri-02.txt Content-description: Network Working Group J. Pechanec Internet-Draft Sun Microsystems, Inc. Intended status: Standards Track D. Moffat Expires: February 18, 2011 Oracle Corporation August 17, 2010 The PKCS#11 URI Scheme draft-pechanec-pkcs11uri-02 Abstract This memo specifies a PKCS#11 Uniform Resource Identifier (URI) Scheme for identifying PKCS#11 objects stored in PKCS#11 tokens, or for identifying PKCS#11 tokens themselves. The URI is based on how PKCS#11 objects and tokens are identified in the PKCS#11 Cryptographic Token Interface Standard. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 18, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Pechanec & Moffat Expires February 18, 2011 [Page 1] Internet-Draft The PKCS#11 URI Scheme August 2010 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. PKCS#11 URI Scheme Definition . . . . . . . . . . . . . . . . . 3 2.1. PKCS#11 URI Scheme Name . . . . . . . . . . . . . . . . . . 3 2.2. PKCS#11 URI Scheme Status . . . . . . . . . . . . . . . . . 3 2.3. PKCS#11 URI Scheme Syntax . . . . . . . . . . . . . . . . . 3 3. Examples of PKCS#11 URI Schemes . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Pechanec & Moffat Expires February 18, 2011 [Page 2] Internet-Draft The PKCS#11 URI Scheme August 2010 1. Introduction The PKCS #11: Cryptographic Token Interface Standard [pkcs11_spec] specifies an API, called Cryptoki, for devices which hold cryptographic information and perform cryptographic functions. Cryptoki, pronounced crypto-key and short for cryptographic token interface, follows a simple object-based approach, addressing the goals of technology independence (any kind of device may be used) and resource sharing (multiple applications may access multiple devices), presenting applications with a common, logical view of the device - a cryptographic token. It is desirable for applications or libraries that work with PKCS#11 tokens to accept a common identifier that consumers could use to identify an existing PKCS#11 object in a PKCS#11 token, or an existing token itself, or an existing Cryptoki library. The set of object types that can be stored in a PKCS#11 token includes a public key, a private key, a certificate, a secret key, and a data object. These objects can be uniquely identifiable via the PKCS#11 URI scheme defined in this document. The set of attributes describing an object can contain an object label, its type, and its ID. The set of attributes that identifies a PKCS#11 token can contain a token label, a manufacturer name, a serial number, and a token model. Attributes that can identify a Cryptoki library are a library manufacturer, a library description, and a library version. Note that the PKCS#11 URI is not intended to be used to create new PKCS#11 objects in tokens, or to create PKCS#11 tokens. It is solely to be used to identify existing objects or existing tokens. 2. PKCS#11 URI Scheme Definition In accordance with [RFC4395], this section provides the information required to register the PKCS#11 URI scheme. 2.1. PKCS#11 URI Scheme Name pkcs11 2.2. PKCS#11 URI Scheme Status Permanent. 2.3. PKCS#11 URI Scheme Syntax The PKCS#11 URI scheme is a sequence of attribute value pairs. Most attributes allow for an UTF-8 string to be used as an value. In Pechanec & Moffat Expires February 18, 2011 [Page 3] Internet-Draft The PKCS#11 URI Scheme August 2010 accordance with [RFC3986], the data should first be encoded as octets according to the UTF-8 character encoding [RFC3629]; then only those octets that do not correspond to characters in the unreserved set or to permitted characters from the reserved set should be percent- encoded. Rules "unreserved" and "pct-encoded" in the PKCS#11 URI specification below were imported from [RFC3986]. As a special case, note that according to [RFC3986], a space must be percent-encoded. A PKCS#11 URL takes the form (for explanation of Augmented BNF, see [RFC5234]): pk11-URI = "pkcs11" ":" pk11-identifier pk11-identifier = *1( pk11-attr *( ";" pk11-attr ) ) pk11-attr = pk11-token / pk11-manuf / pk11-serial / pk11-model / pk11-lib-manuf / pk11-lib-ver / pk11-lib-desc / pk11-object / pk11-objecttype / pk11-id / pk11-pinfile ; Section 2.2 of RFC 3986 specifies that all potentially reserved ; characters that do not conflict with actual delimiters of the URI ; do not have to be percent-encoded. So, we just removed ";". pk11-reserved-avail = ":" / "/" / "?" / "#" / "[" / "]" / "@" / "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / "=" pk11-value = *( unreserved / pk11-reserved-avail / ; pct-encoded ) ; The "pk11-ck-char" rule contains a complete list of characters ; of the CK_CHAR type as defined in the PKCS#11 specification. Those ; are a-z, A-Z, 0-9, a space, and all special characters from the ; following list: !"#%&'()*+,-./:;<=>?[\]^_{|}~. Note that some ; special characters not part of the reserved and unreserved sets ; must be percent-encoded. pk11-ck-char = unreserved / "%20" / "!" / "%22" / "#" / "%25" / "&" / "'" / "(" / ")" / "*" / "+" / "," / "-" / "." / "/" / ":" / "%3B" / "%3C" / "=" / "%3E" / "?" / "[" / "%5C" / "]" / "%5E" / "_" / "%7B" / "%7C" / "%7D" / "~" ; Corresponds to the label field of the CK_TOKEN_INFO structure. pk11-token = "token" "=" pk11-value ; Corresponds to the manufacturerID field of the CK_TOKEN_INFO ; structure. pk11-manuf = "manufacturer" "=" pk11-value ; Corresponds to the serialNumber field of the CK_TOKEN_INFO structure. pk11-serial = "serial" "=" *pk11-ck-char ; Corresponds to the model field of the CK_TOKEN_INFO structure. pk11-model = "model" "=" pk11-value ; Corresponds to the manufacturerID field of the CK_INFO structure. pk11-lib-manuf = "library-manufacturer" "=" pk11-value Pechanec & Moffat Expires February 18, 2011 [Page 4] Internet-Draft The PKCS#11 URI Scheme August 2010 ; Corresponds to the libraryDescription field of the CK_INFO structure. pk11-lib-desc = "library-description" "=" pk11-value ; Corresponds to the libraryVersion field of the CK_INFO structure. pk11-lib-ver = "library-version" "=" 1*DIGIT "." 1*2DIGIT ; Corresponds to the CKA_LABEL object attribute. pk11-object = "object" "=" pk11-value ; Corresponds to the CKA_CLASS object attribute. pk11-objecttype = "objecttype" "=" ( "public" / "private" / "cert" / "secretkey" / "data" ) ; Corresponds to the CKA_ID object attribute. pk11-id = "id" "=" *pct-encoded pk11-pinfile = "pinfile" "=" pk11-value While the PKCS#11 specification limits the length of some fields, eg. the manufacturer label can be up to thirty-two characters long, the PKCS#11 URI does not impose such limitations. It is up to the consumer of the PKCS#11 URI to perform any necessary sanity length checks. The attribute "token" represents a token label, the attribute "manufacturer" represents a token manufacturer ID, the attribute "serial" represents a token serial number, the attribute "model" represents a token model, the attribute "library-manufacturer" represents the Cryptoki library manufacturer, the attribute "library- description" represents the character string description of the library, the attribute "library-version" represents the Cryptoki library version, the attribute "object" represents a PKCS#11 object label, the attribute "objecttype" represents the type of the object, the attribute "id" represents the object ID, and the attribute "pinfile" specifies where the application or library should find the token PIN, if needed. Application could overload this attribute. For example, "pinfile=%7Cprog-name" could mean to read a PIN from an external application (%7C denotes a pipe '|' character). Note that an application can always ask for a PIN by any means it decides to. 3. Examples of PKCS#11 URI Schemes This section contains some examples of how PKCS#11 tokens or PKCS#11 token objects can be identified using the PKCS#11 URI scheme. Note that in some of the following examples, newlines and spaces were inserted for better readability which is allowed by [RFC3986]. Also note that all spaces as part of the URI are percent-encoded, as required by [RFC3986]. An empty PKCS#11 URI might be useful to PKCS#11 consumers: pkcs11: Pechanec & Moffat Expires February 18, 2011 [Page 5] Internet-Draft The PKCS#11 URI Scheme August 2010 One of the simplest and most useful forms might be a PKCS#11 URI that specifies only an object label and its type. The default token is used so the URI does not specify it. Note that when specifying public objects, a token PIN might not be required. pkcs11:object=my-pubkey;objecttype=public When a private key is specified either the "pinfile" attribute or an application specific method must be used: pkcs11:object=my-key;objecttype=private;pinfile=/etc/ssh/token_pin The following example identifies a certificate in the software token. Note that all attributes aside from "objecttype" may have an empty value. In our case, "serial" is empty. It is up to the consumer of the URI to perform necessary checks if that is not allowed. Note the notation of the "id" attribute value which is entirely percent- encoded. pkcs11:token=The%20Software%20PKCS#11%20softtoken; manufacturer=Snake%20Oil,%20Inc.; serial=; model=1.0; object=my-certificate; objecttype=cert; id=%69%95%3e%5c%f4%bd%ec%91; pinfile=/etc/ssh/token_pin The token alone can be identified without specifying any PKCS#11 objects. A PIN may still be needed to list all objects, for example. pkcs11:token=Software%20PKCS#11%20softtoken; manufacturer=Snake%20Oil,%20Inc.; pinfile=/etc/ssh/token_pin The Cryptoki library alone can be also identified without specifying any PKCS#11 objects. pkcs11:library-manufacturer=Snake%20Oil,%20Inc.; library-description=Soft%20Token%20Library; library-description=2.34 Pechanec & Moffat Expires February 18, 2011 [Page 6] Internet-Draft The PKCS#11 URI Scheme August 2010 The following example shows that the attribute value can contain a semicolon. In such case, it is percent-encoded. We can also have capital letters in the "id" attribute value. pkcs11:token=My%20token%25%20created%20by%20Joe; object=my-certificate; objecttype=cert; id=69:95:3E:5C:F4:BD:EC:91; pinfile=/etc/ssh/token_pin And if there is any need to include literal '%;' substring, for example, we must escape both characters. The token value must be read as "The token name with a strange substring '\;'" then. pkcs11:token=A%20name%20with%20a%20strange%20substring%'%25%3B'; object=my-certificate; objecttype=cert; pinfile=/etc/ssh/token_pin The next example includes a small A with acute in the token name. We must encode it in octets according to the UTF-8 character encoding and then use the percent-encoding. Given that a small A with acute is U+225 unicode code point, the UTF-8 encoding is 195 161 in decimal, which is "%C3%A1" in the percent-encoding. pkcs11:token=Name%20with%20a%20small%20A%20with%20acute:%20%C3%A1; object=my-certificate; objecttype=cert; 4. IANA Considerations This document registers a URI scheme. The registration template can be found in Section 2 of this document. 5. Security Considerations There are many security considerations for URI schemes discussed in [RFC3986]. Given that the PKCS#11 URI is also supposed to be used in command line arguments to running programs, and those arguments can be world readable on some systems, the URI intentionaly does not allow for specifying the PKCS#11 token PIN as a URI attribute. Pechanec & Moffat Expires February 18, 2011 [Page 7] Internet-Draft The PKCS#11 URI Scheme August 2010 6. Normative References [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, STD 63, November 2003. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, January 2005. [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", RFC 4395, February 2006. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. [pkcs11_spec] RSA Laboratories, "PKCS #11: Cryptographic Token Interface Standard v2.20", June 2004. Authors' Addresses Jan Pechanec Sun Microsystems, Inc. The Park, building 3 V parku 2308/8 Prague 14800 CZ Phone: +420 233 009 380 Email: Jan.Pechanec@Sun.COM URI: http://www.sun.com Darren J. Moffat Oracle Corporation Guillemont Park Building 3 Camberley GU17 9QG UK Email: Darren.Moffat@Oracle.COM URI: http://www.oracle.com Pechanec & Moffat Expires February 18, 2011 [Page 8] --Boundary_(ID_X4CwetglJmO+pcD4tCiHcg)-- From n.mavrogiannopoulos@gmail.com Tue Aug 17 05:30:54 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 208783A694A for ; Tue, 17 Aug 2010 05:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 PfA-FTtH01uh for ; Tue, 17 Aug 2010 05:30:53 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 2DF243A67A7 for ; Tue, 17 Aug 2010 05:30:53 -0700 (PDT) Received: by qwc9 with SMTP id 9so6565942qwc.31 for ; Tue, 17 Aug 2010 05:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=hDOAYH8OgGlbIybv9QcMMLdczX6OyULMwMolcdaE+Gk=; b=Po4fTms+eraIwXFZp/+rWsLZWKIBLRYCZIWoihJ6zKoLwTCfjL5rvZB8bvTXQIbekK wy0NQ4g2WauLumclP6pDOPJaGf4unomkVrH1uXfvxYQJ6wQsgbKYyBJQXfrhe9hhTaJK C1eyzSGBVxOt+l/BE1mYD1PFwCdAkI50FK0jU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=DXxEv7WX7+x5++kQ5eaoKGhVLeXJMoOwyRmh8PF8lMFon9r0YUkQTrJfySB6Ex0ewT 9kDYn1nBVrdVSgfT9VaZi/QXC8itGGM0QcbZPH8im5JtADW+e+ATUdIJEp9Z/kOJFWhe QwuswPWy0vqnAQLo1T2fwbltjbGJuN8XICsnI= MIME-Version: 1.0 Received: by 10.224.112.215 with SMTP id x23mr4273293qap.37.1282048285365; Tue, 17 Aug 2010 05:31:25 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.31.205 with HTTP; Tue, 17 Aug 2010 05:31:24 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 Aug 2010 14:31:24 +0200 X-Google-Sender-Auth: udjVK2P12B7ePNWPcR4PJeyba2E Message-ID: From: Nikos Mavrogiannopoulos To: Jan Pechanec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 17 Aug 2010 08:14:51 -0700 Cc: Darren.Moffat@oracle.com, saag@ietf.org Subject: Re: [saag] new I-D on the PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 12:30:54 -0000 On Tue, Aug 17, 2010 at 1:59 PM, Jan Pechanec wrote: > =C2=A0 =C2=A0 =C2=A0 =C2=A0attached is a modified draft. I added three at= tributes listed > above and also one example that shows that the URI can be used to > identify the library alone without any objects. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0if I understand the spec correctly: > > typedef struct CK_VERSION { > =C2=A0CK_BYTE =C2=A0 =C2=A0 =C2=A0 major; =C2=A0/* integer portion of ver= sion number */ > =C2=A0CK_BYTE =C2=A0 =C2=A0 =C2=A0 minor; =C2=A0/* 1/100ths portion of ve= rsion number */ > } CK_VERSION; > =C2=A0 =C2=A0 =C2=A0 =C2=A0then the minor version must be 0-99, so the li= b version > attribute is defined as: > pk11-lib-ver =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D "library-versio= n" "=3D" 1*DIGIT "." 1*2DIGIT > =C2=A0 =C2=A0 =C2=A0 =C2=A0in theory we should limit the major version to= 0-255 (CK_BYTE) > but I'm not sure it's worth it. Is it? I wouldn't add any limitation for the numbers. Those are returned by the library itself and might not be really scrutinised. Would we really want to fail calculating a URL on a library that returns 2.101 as a version number? regards, Nikos From Jan.Pechanec@Sun.COM Tue Aug 17 05:39:40 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F4A3A693A for ; Tue, 17 Aug 2010 05:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vPxJl89miTZl for ; Tue, 17 Aug 2010 05:39:39 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) by core3.amsl.com (Postfix) with ESMTP id 7F5493A687E for ; Tue, 17 Aug 2010 05:39:39 -0700 (PDT) Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o7HCeEXa007442 for ; Tue, 17 Aug 2010 12:40:14 GMT MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_xMUq4v+GpeslndqVUoeLfw)" Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L7A00E00QVFQI00@fe-emea-13.sun.com> for saag@ietf.org; Tue, 17 Aug 2010 13:39:53 +0100 (BST) Received: from rejewski ([unknown] [10.18.138.121]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L7A00EIMR6HIA50@fe-emea-13.sun.com>; Tue, 17 Aug 2010 13:39:53 +0100 (BST) Date: Tue, 17 Aug 2010 14:39:51 +0200 (CEST) From: Jan Pechanec In-reply-to: Sender: Jan.Pechanec@Sun.COM X-X-Sender: jp161948@rejewski To: Nikos Mavrogiannopoulos Message-id: Content-id: References: X-Mailman-Approved-At: Tue, 17 Aug 2010 08:14:51 -0700 Cc: Darren.Moffat@oracle.com, saag@ietf.org Subject: Re: [saag] new I-D on the PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 12:39:40 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --Boundary_(ID_xMUq4v+GpeslndqVUoeLfw) Content-id: Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE On Tue, 17 Aug 2010, Nikos Mavrogiannopoulos wrote: >> =A0 =A0 =A0 =A0attached is a modified draft. I added three attributes li= sted >> above and also one example that shows that the URI can be used to >> identify the library alone without any objects. >> >> =A0 =A0 =A0 =A0if I understand the spec correctly: >> >> typedef struct CK_VERSION { >> =A0CK_BYTE =A0 =A0 =A0 major; =A0/* integer portion of version number */ >> =A0CK_BYTE =A0 =A0 =A0 minor; =A0/* 1/100ths portion of version number *= / >> } CK_VERSION; >> =A0 =A0 =A0 =A0then the minor version must be 0-99, so the lib version >> attribute is defined as: >> pk11-lib-ver =A0 =A0 =A0 =A0 =A0 =A0=3D "library-version" "=3D" 1*DIGIT = "." 1*2DIGIT >> =A0 =A0 =A0 =A0in theory we should limit the major version to 0-255 (CK_= BYTE) >> but I'm not sure it's worth it. Is it? > >I wouldn't add any limitation for the numbers. Those are returned by >the library itself and might not be really scrutinised. Would we >really want to fail calculating a URL on a library that returns 2.101 >as a version number? =09hmm, that seems right, this is what Solaris soft token library=20 returns: $ ./a.out=20 library manuf ID: Sun Microsystems, Inc. =20 library description: Sun Crypto Softtoken =20 library version: 1.184 =09shall we relax a need for the minor version as well? pk11-lib-ver =3D "library-version" "=3D" 1*DIGIT "." 1*2DIGIT =09or pk11-lib-ver =3D "library-version" "=3D" 1*DIGIT *( "." 1*2DIGIT) =09we relaxed the number of digits so I'd support the latter=20 attribute definition. =09J. --=20 Jan Pechanec http://blogs.sun.com/janp= --Boundary_(ID_xMUq4v+GpeslndqVUoeLfw)-- From Jan.Pechanec@Sun.COM Tue Aug 17 05:58:39 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 206E03A696D for ; Tue, 17 Aug 2010 05:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vaWlR6X+CdS2 for ; Tue, 17 Aug 2010 05:58:37 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) by core3.amsl.com (Postfix) with ESMTP id 7653A3A696C for ; Tue, 17 Aug 2010 05:58:37 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o7HCxCm3010105 for ; Tue, 17 Aug 2010 12:59:12 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L7A00000RRVLM00@fe-emea-10.sun.com> for saag@ietf.org; Tue, 17 Aug 2010 13:58:54 +0100 (BST) Received: from rejewski ([unknown] [10.18.138.121]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L7A00BQ5S24ZTF0@fe-emea-10.sun.com>; Tue, 17 Aug 2010 13:58:53 +0100 (BST) Date: Tue, 17 Aug 2010 14:58:51 +0200 (CEST) From: Jan Pechanec In-reply-to: Sender: Jan.Pechanec@Sun.COM X-X-Sender: jp161948@rejewski To: Nikos Mavrogiannopoulos Message-id: References: X-Mailman-Approved-At: Tue, 17 Aug 2010 08:14:51 -0700 Cc: Darren.Moffat@oracle.com, saag@ietf.org Subject: Re: [saag] new I-D on the PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 12:58:39 -0000 On Tue, 17 Aug 2010, Jan Pechanec wrote: > pk11-lib-ver = "library-version" "=" 1*DIGIT *( "." 1*2DIGIT) > > we relaxed the number of digits so I'd support the latter >attribute definition. latest version with the above mentioned attribute definition: http://www.devnull.cz/tmp/draft-pechanec-pkcs11uri-02.txt -- Jan Pechanec http://blogs.sun.com/janp From ondrej.sury@nic.cz Wed Aug 18 00:43:12 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EFF13A6849; Wed, 18 Aug 2010 00:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 2MJTabt5gVsV; Wed, 18 Aug 2010 00:43:11 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id CB06D3A6A28; Wed, 18 Aug 2010 00:43:10 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 5307D73440F; Wed, 18 Aug 2010 09:43:45 +0200 (CEST) Message-ID: <4C6B8F30.6050101@nic.cz> Date: Wed, 18 Aug 2010 09:43:44 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: dnsop@ietf.org, tls@ietf.org, pkix@ietf.org, saag@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [saag] FYI: New Non-WG Mailing List: keyassure -- Key Assurance With DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 07:43:12 -0000 Hi, this is the mailing list for discussing and proposing new ways how to use the fact that we have a DNSSEC @ root zone. You may want to read: The problem statement I and Warren wrote: http://www.ietf.org/mail-archive/web/keyassure/current/msg00000.html New I-D by Jakob, Paul, Warren and Adam: http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-00.txt Slightly older CERT RR (which we already have): http://tools.ietf.org/html/rfc4398 And various older proposals which didn't make it: (Jakob's) http://stupid.domain.name/ietf/draft-schlyter-pkix-dns-02.txt (RR TYPE request I did) http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg00421.html This is just to summarize the ideas which were floating around for some time. The basis on our work will be in the most recent I-D. Ondrej -------- Original Message -------- Subject: New Non-WG Mailing List: keyassure -- Key Assurance With DNSSEC Date: Tue, 17 Aug 2010 11:36:02 -0700 (PDT) From: IETF Secretariat To: IETF Announcement list CC: keyassure@ietf.org, ondrej.sury@nic.cz, warren@kumari.net A new IETF non-working group email list has been created. List address: keyassure@ietf.org Archive: http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html To subscribe: https://www.ietf.org/mailman/listinfo/keyassure Description: This list is for discussion relating to using DNSSEC-protected DNS queries to get greater assurance for keys and certificates that are passed in existing IETF protocols. The main idea is that a relying party can get additional information about a domain name to eliminate the need for using a certificate in a protocol, to eliminate the need for sending certificates in the protocol if they are optional, and/or to assure that the certificate given in a protocol is associated with the domain name used by the application. In all three cases, the application associates the key or key fingerprint securely retrieved from the DNS with the domain name that was used in the DNS query. For additional information, please contact the list administrators. -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- LaboratoÅ™e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From stefw@gnome.org Wed Aug 18 01:13:59 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C42E03A6A51 for ; Wed, 18 Aug 2010 01:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 9wQcufJJRm+h for ; Wed, 18 Aug 2010 01:13:58 -0700 (PDT) Received: from memberwebs.com (memberwebs.com [94.75.203.95]) by core3.amsl.com (Postfix) with ESMTP id 739263A67A5 for ; Wed, 18 Aug 2010 01:13:52 -0700 (PDT) Received: from [192.168.1.102] (dslb-092-075-144-080.pools.arcor-ip.net [92.75.144.80]) by memberwebs.com (Postfix) with ESMTP id 5D7BAA34B; Wed, 18 Aug 2010 08:14:19 +0000 (UTC) Message-ID: <4C6B965A.6020001@gnome.org> Date: Wed, 18 Aug 2010 10:14:18 +0200 From: Stef Walter User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Jan Pechanec References: <4C6964BA.1010406@Oracle.COM> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Darren J Moffat , saag@ietf.org, Nikos Mavrogiannopoulos Subject: Re: [saag] new I-D on the PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 08:13:59 -0000 On 08/16/2010 10:51 PM, Jan Pechanec wrote: >> I don't think we would have a '?' after the ':' just like currently we don't >> have a ';' after the ':'. >> >> I don't really have a strong preference, more just throwing it out for >> discussion. > > I'd rather keep the current approach, it seems simpler to me. > I agree with keeping the current approach and not trying to match this too much to a query or a path. A PKCS#11 URI like the following can sometimes represent a token, other times all the objects on that token, depending on the application using it and the context in which it is used: pkcs11:token=Token%20Name Cheers, Stef From Jan.Pechanec@Sun.COM Wed Aug 18 01:27:08 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 208F83A6A5A for ; Wed, 18 Aug 2010 01:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 rkxEAnbB1WPR for ; Wed, 18 Aug 2010 01:27:06 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) by core3.amsl.com (Postfix) with ESMTP id 308873A6A5C for ; Wed, 18 Aug 2010 01:27:05 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o7I8RdUS013677 for ; Wed, 18 Aug 2010 08:27:39 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L7C00A009QO4900@fe-emea-09.sun.com> for saag@ietf.org; Wed, 18 Aug 2010 09:27:16 +0100 (BST) Received: from rejewski ([unknown] [10.18.138.121]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L7C0066LA4M87E0@fe-emea-09.sun.com>; Wed, 18 Aug 2010 09:26:46 +0100 (BST) Date: Wed, 18 Aug 2010 10:26:45 +0200 (CEST) From: Jan Pechanec In-reply-to: <4C6B965A.6020001@gnome.org> Sender: Jan.Pechanec@Sun.COM X-X-Sender: jp161948@rejewski To: Stef Walter Message-id: References: <4C6964BA.1010406@Oracle.COM> <4C6B965A.6020001@gnome.org> X-Mailman-Approved-At: Thu, 19 Aug 2010 07:34:01 -0700 Cc: Darren J Moffat , saag@ietf.org, Nikos Mavrogiannopoulos Subject: Re: [saag] new I-D on the PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 08:27:08 -0000 On Wed, 18 Aug 2010, Stef Walter wrote: hi Stef, >On 08/16/2010 10:51 PM, Jan Pechanec wrote: >>> I don't think we would have a '?' after the ':' just like currently we don't >>> have a ';' after the ':'. >>> >>> I don't really have a strong preference, more just throwing it out for >>> discussion. >> >> I'd rather keep the current approach, it seems simpler to me. >> > >I agree with keeping the current approach and not trying to match this >too much to a query or a path. technically, all current attributes are in the path section now. >A PKCS#11 URI like the following can sometimes represent a token, other >times all the objects on that token, depending on the application using >it and the context in which it is used: > >pkcs11:token=Token%20Name agreed, this is also one of the examples in the I-D. Now it can represent a Cryptoki library as well. I'll publish a new draft version as it is now: http://www.devnull.cz/tmp/draft-pechanec-pkcs11uri-02.txt Darren, is that OK with you? cheers, J. -- Jan Pechanec http://blogs.sun.com/janp From Darren.Moffat@Oracle.COM Wed Aug 18 01:47:48 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 249F73A6A5C for ; Wed, 18 Aug 2010 01:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 rX4G023tw6Lw for ; Wed, 18 Aug 2010 01:47:47 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id EA6693A6822 for ; Wed, 18 Aug 2010 01:47:46 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7I8lu4U007127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Aug 2010 08:47:57 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7I8ltnA026584; Wed, 18 Aug 2010 08:47:55 GMT Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 506767401282121249; Wed, 18 Aug 2010 01:47:29 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 18 Aug 2010 01:47:28 -0700 Message-ID: <4C6B9E0F.1040502@Oracle.COM> Date: Wed, 18 Aug 2010 09:47:11 +0100 From: Darren J Moffat Organization: Oracle Solaris Security User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.4) Gecko/20100719 Lightning/1.0b2 OracleBeehiveExtension/1.0.0.0pre10-Champion Thunderbird/3.1 MIME-Version: 1.0 To: Jan Pechanec References: <4C6964BA.1010406@Oracle.COM> <4C6B965A.6020001@gnome.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 19 Aug 2010 07:34:00 -0700 Cc: saag@ietf.org, Nikos Mavrogiannopoulos Subject: Re: [saag] new I-D on the PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 08:47:48 -0000 On 18/08/2010 09:26, Jan Pechanec wrote: > agreed, this is also one of the examples in the I-D. Now it can > represent a Cryptoki library as well. > > I'll publish a new draft version as it is now: > > http://www.devnull.cz/tmp/draft-pechanec-pkcs11uri-02.txt > > Darren, is that OK with you? Yes I'm happy with it as is. -- Darren J Moffat From Nicolas.Williams@oracle.com Thu Aug 19 10:10:26 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECDBC3A6993 for ; Thu, 19 Aug 2010 10:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 BumDvyS56cpj for ; Thu, 19 Aug 2010 10:10:25 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 18F3B3A6971 for ; Thu, 19 Aug 2010 10:10:25 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7JHAaSW030221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Aug 2010 17:10:37 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7JH4Dpd023953; Thu, 19 Aug 2010 17:10:35 GMT Received: from abhmt003.oracle.com by acsmt355.oracle.com with ESMTP id 512708281282237777; Thu, 19 Aug 2010 10:09:37 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Aug 2010 10:09:35 -0700 Date: Thu, 19 Aug 2010 12:09:28 -0500 From: Nicolas Williams To: Jan Pechanec Message-ID: <20100819170927.GO14409@oracle.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: Darren.Moffat@oracle.com, saag@ietf.org, Nikos Mavrogiannopoulos Subject: Re: [saag] new I-D on the PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:10:26 -0000 The thought occurred to me that an authority part would be useful, but then I realized that an authority part cannot be mapped to a PKCS#11 API call. I think it'd be useful to: - State, in the Abstract and/or Introduction, that this URI scheme is designed specifically with a mapping to the PKCS#11 API in mind. You'd think this would be obvious, but it's not. It's one thing to map a PKCS#11 URI to PKCS#11 concepts; it's another to map it to API elements. - Explain that an authority part cannot be mapped to PKCS#11 API elements, therefore there is no authority part in the PKCS#11 URI scheme. - [maybe] Provide some example C code snippets showing how to open a session with a token identified by various URI elements. (But don't include code for parsing a URI, of course.) Also, a PKCS#11 version would be useful. Not just a provider version but an actual PKCS#11 version. This would allow the addition of new URI elements in the future that cannot be understood by older implementations, but with older implementations able to detect version mismatch. Nico -- From Jan.Pechanec@Sun.COM Fri Aug 20 04:35:46 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1263A6A08 for ; Fri, 20 Aug 2010 04:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 7CZS3dcP3TPL for ; Fri, 20 Aug 2010 04:35:45 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) by core3.amsl.com (Postfix) with ESMTP id D43A83A6A86 for ; Fri, 20 Aug 2010 04:35:43 -0700 (PDT) Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o7KBaHYg016774 for ; Fri, 20 Aug 2010 11:36:17 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L7G0050080R4G00@fe-emea-13.sun.com> for saag@ietf.org; Fri, 20 Aug 2010 12:36:04 +0100 (BST) Received: from rejewski ([unknown] [10.18.138.121]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L7G005MQ8834F00@fe-emea-13.sun.com>; Fri, 20 Aug 2010 12:36:04 +0100 (BST) Date: Fri, 20 Aug 2010 13:36:00 +0200 (CEST) From: Jan Pechanec In-reply-to: <20100819170927.GO14409@oracle.com> Sender: Jan.Pechanec@Sun.COM X-X-Sender: jp161948@rejewski To: Nicolas Williams Message-id: References: <20100819170927.GO14409@oracle.com> X-Mailman-Approved-At: Sun, 22 Aug 2010 18:40:54 -0700 Cc: Darren.Moffat@oracle.com, saag@ietf.org, Nikos Mavrogiannopoulos Subject: Re: [saag] new I-D on the PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 11:35:46 -0000 On Thu, 19 Aug 2010, Nicolas Williams wrote: >The thought occurred to me that an authority part would be useful, but >then I realized that an authority part cannot be mapped to a PKCS#11 API >call. hi Nico, thanks for feedback, I'll take a look at it the next week. meanwhile, I filed the new 02 version since the ABNF definition is quite different from the version 01 and there was a general agreement on 02. http://www.ietf.org/id/draft-pechanec-pkcs11uri-02.txt cheers, J. >I think it'd be useful to: > > - State, in the Abstract and/or Introduction, that this URI scheme is > designed specifically with a mapping to the PKCS#11 API in mind. > > You'd think this would be obvious, but it's not. It's one thing to > map a PKCS#11 URI to PKCS#11 concepts; it's another to map it to API > elements. > > - Explain that an authority part cannot be mapped to PKCS#11 API > elements, therefore there is no authority part in the PKCS#11 URI > scheme. > > - [maybe] Provide some example C code snippets showing how to open a > session with a token identified by various URI elements. (But don't > include code for parsing a URI, of course.) > >Also, a PKCS#11 version would be useful. Not just a provider version >but an actual PKCS#11 version. This would allow the addition of new URI >elements in the future that cannot be understood by older >implementations, but with older implementations able to detect version >mismatch. > >Nico > -- Jan Pechanec http://blogs.sun.com/janp From narten@us.ibm.com Wed Aug 25 06:21:07 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 572813A697A for ; Wed, 25 Aug 2010 06:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.272 X-Spam-Level: X-Spam-Status: No, score=-106.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 wxIa46GaRMsx for ; Wed, 25 Aug 2010 06:21:06 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id 0FFDF3A6AED for ; Wed, 25 Aug 2010 06:21:05 -0700 (PDT) Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o7PDLJva024684 for ; Wed, 25 Aug 2010 09:21:19 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o7PDL9qW123066 for ; Wed, 25 Aug 2010 09:21:09 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o7PDL8Jp007552 for ; Wed, 25 Aug 2010 09:21:08 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-249-38.mts.ibm.com [9.65.249.38]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o7PDKwAo006756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Aug 2010 09:20:59 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id o7PDKvI3030865 for ; Wed, 25 Aug 2010 09:20:58 -0400 Message-Id: <201008251320.o7PDKvI3030865@cichlid.raleigh.ibm.com> To: saag@ietf.org Date: Wed, 25 Aug 2010 09:20:57 -0400 From: Thomas Narten Subject: [saag] IPv6 Node Requirements: Updated IPsec/IKEv2 text X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 13:21:07 -0000 To recap, I presented on the issue of updating the IPsec/IKEv2 text at the 6man meeting in Maastricht, as well as at the SAAG meeting. My sense of both of those discussions is that there is support for changing the general recommendation to a SHOULD. I got some good feedback in SAAG about the wording (refer to the security architecture generally rather than IKEv2, etc.). New proposed text below. This text would go into draft-ietf-ipv6-node-requirements, which updates RFC 4294. Comments? Thomas 10. Security This section describes the specification for security for IPv6 nodes. Achieving security in practice is a complex undertaking. Operational procedures, protocols, key distribution mechanisms, certificate management approaches, etc. are all components that impact the level of security actually achieved in practice. More importantly, deficiencies or a poor fit in any one individual component can significantly reduce the overall effectiveness of a particular security approach. IPsec provides channel security at the Internet layer, making it possible to provide secure communication for all (or a subset of) communication flows at the IP layer between pairs of internet nodes. IPsec provides sufficient flexibility and granularity that individual TCP connections can (selectively) be protected, etc. Although IPsec can be used with manual keying in some cases, such usage has limited applicability and is not recommended. A range of security technologies and approaches proliferate today (e.g., IPsec, TLS, SSH, etc.) No one approach has emerged as an ideal technology for all needs and environments. Moreover, IPsec is not viewed as the ideal security technology in all cases and is unlikely to displace the others. Previously, IPv6 mandated implementation of IPsec and recommended the key management approach of IKE. This document updates that recommendation by making support of the IP Security Architecture [RFC 4301] a SHOULD for all IPv6 nodes. Note that the IPsec Architecture requires (e.g., Sec. 4.5 of RFC 4301) the implementation of both manual and automatic key management. Currently the default automated key management protocol to implement is IKEv2. This document recognizes that there exists a range of device types and environments where other approaches to security than IPsec can be justified. For example, special-purpose devices may support only a very limited number or type of applications and an application- specific security approach may be sufficient for limited management or configuration capabilities. Alternatively, some devices my run on extremely constrained hardware (e.g., sensors) where the full IP Security Architecture is not justified. 10.1. Requirements "Security Architecture for the Internet Protocol" [RFC4301] SHOULD be supported by all IPv6 nodes. Note that the IPsec Architecture requires (e.g., Sec. 4.5 of RFC 4301) the implementation of both manual and automatic key management. Currently the default automated key management protocol to implement is IKEv2. 10.2. Transforms and Algorithms The current set of mandatory-to-implement algorithms for the IP Security Architcture are defined in 'Cryptographic Algorithm Implementation Requirements For ESP and AH' [RFC4835]. IPv6 nodes implementing the IP Security Architecture MUST conform to the requirements in [RFC4835]. Preferred cryptographic algorithms often change more frequently than security protocols. Therefore implementations MUST allow for migration into new algorithms, as RFC4835 is replaced or updated in the future. From touch@isi.edu Wed Aug 25 12:55:45 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60EF43A69E7 for ; Wed, 25 Aug 2010 12:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 IBsJGvaT81gL for ; Wed, 25 Aug 2010 12:55:44 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 2DA2F3A692C for ; Wed, 25 Aug 2010 12:55:44 -0700 (PDT) Received: from [172.35.1.127] (pc3.shinagawaphvod2-unet.ocn.ne.jp [220.110.141.59]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o7PJtVdv016885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Aug 2010 12:55:42 -0700 (PDT) Message-ID: <4C75752F.5020409@isi.edu> Date: Wed, 25 Aug 2010 12:55:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Thomas Narten References: <201008251320.o7PDKvI3030865@cichlid.raleigh.ibm.com> In-Reply-To: <201008251320.o7PDKvI3030865@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: o7PJtVdv016885 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: saag@ietf.org Subject: Re: [saag] IPv6 Node Requirements: Updated IPsec/IKEv2 text X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 19:55:45 -0000 Hi, Tom, On 8/25/2010 6:20 AM, Thomas Narten wrote: > To recap, I presented on the issue of updating the IPsec/IKEv2 text > at the 6man meeting in Maastricht, as well as at the SAAG meeting. My > sense of both of those discussions is that there is support for > changing the general recommendation to a SHOULD. > > I got some good feedback in SAAG about the wording (refer to the > security architecture generally rather than IKEv2, etc.). > > New proposed text below. > > This text would go into draft-ietf-ipv6-node-requirements, which > updates RFC 4294. > > Comments? First, this seems to override Sec 10 of RFC4301, so it would need to update RFC4301 as well. Some other comments below. Joe > Thomas > > 10. Security > > This section describes the specification for security for IPv6 nodes. > > Achieving security in practice is a complex undertaking. Operational > procedures, protocols, key distribution mechanisms, certificate > management approaches, etc. are all components that impact the level > of security actually achieved in practice. More importantly, > deficiencies or a poor fit in any one individual component can > significantly reduce the overall effectiveness of a particular > security approach. > > IPsec provides channel security at the Internet layer, making it > possible to provide secure communication for all (or a subset of) > communication flows at the IP layer between pairs of internet nodes. > IPsec provides sufficient flexibility and granularity that individual > TCP connections can (selectively) be protected, etc. IPsec can protect down to the socket pair (src addr/src port/dst addr/dst port) granularity, but there are two important issues. First, this is rarely done; it is more common to protect services (i.e., at least letting the src port of incoming SYNs float). Second, such granularity would reuse an SA for different TCP connections that reuse the port pair. I.e., there is no way I am aware of to ensure that IPsec changes SA keys for a socket pair for each TCP connection that reuses that socket. TCP-AO can achieve this, however. So it is not individual TCP connections that are protected; it is individual socket pairs (at best), and more likely all connections between two specific endpoints for a given service. [FWIW, this might be a good opportunity for the IPsec doc to crossref TCP-AO, and to have at least a short note as to when each is preferred, or to refer to that discussion in the TCP-AO document] > Although IPsec can be used with manual keying in some cases, such > usage has limited applicability and is not recommended. > > A range of security technologies and approaches proliferate today > (e.g., IPsec, TLS, SSH, etc.) It might be useful to add TCP-AO here. > No one approach has emerged as an > ideal technology for all needs and environments. Moreover, IPsec is > not viewed as the ideal security technology in all cases and is > unlikely to displace the others. It's important to note, however, that although any of these protects the user data, only IPsec and TCP-AO protect TCP connections from disruption attacks. > Previously, IPv6 mandated implementation of IPsec and recommended the > key management approach of IKE. This document updates that > recommendation by making support of the IP Security Architecture [RFC > 4301] a SHOULD for all IPv6 nodes. Note that the IPsec Architecture > requires (e.g., Sec. 4.5 of RFC 4301) the implementation of both > manual and automatic key management. Currently the default automated > key management protocol to implement is IKEv2. > > This document recognizes that there exists a range of device types > and environments where other approaches to security than IPsec can be > justified. For example, special-purpose devices may support only a > very limited number or type of applications and an application- > specific security approach may be sufficient for limited management > or configuration capabilities. Alternatively, some devices my run on > extremely constrained hardware (e.g., sensors) where the full IP > Security Architecture is not justified. > > 10.1. Requirements > > "Security Architecture for the Internet Protocol" [RFC4301] SHOULD be > supported by all IPv6 nodes. Note that the IPsec Architecture > requires (e.g., Sec. 4.5 of RFC 4301) the implementation of both > manual and automatic key management. Currently the default automated > key management protocol to implement is IKEv2. > > 10.2. Transforms and Algorithms > > The current set of mandatory-to-implement algorithms for the IP > Security Architcture are defined in 'Cryptographic Algorithm > Implementation Requirements For ESP and AH' [RFC4835]. IPv6 nodes > implementing the IP Security Architecture MUST conform to the > requirements in [RFC4835]. Preferred cryptographic algorithms often > change more frequently than security protocols. Therefore > implementations MUST allow for migration into new algorithms, as > RFC4835 is replaced or updated in the future. This might also be a good opportunity to revisit the issue of recommendations for tunnel and transport mode inclusion. During the revision of RFC4301, IMO the recommendations on transport mode were vague with respect to routers (RFC4301, end of section 4.1). I feel it is important to indicate the following: --- Any device that acts like a host (i.e., sources packets with IP addresses assigned to their own interfaces) and implements IPsec MUST implement transport mode. All devices (hosts and gateways) that implement IPsec MUST implement tunnel mode. Because gateways always act as hosts for some protocols (as noted in RFC 1812), the conclusion is that all devices that implement IPsec MUST implement both tunnel and transport mode. In summary, a) A host implementation of IPsec MUST support both transport and tunnel mode. This is true for native, BITS, and BITW implementations for hosts. b) A security gateway MUST support both transport and tunnel mode. Transport mode should be used only when the security gateway is acting as a host, e.g., for network management, or to provide security between two intermediate systems along a path, as to secure a tunnel whose encapsulation is not provided by IPsec tunnel mode. --- From touch@isi.edu Wed Aug 25 13:20:18 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0BAA3A6903 for ; Wed, 25 Aug 2010 13:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 47mWUypTXgsU for ; Wed, 25 Aug 2010 13:20:16 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 396333A6927 for ; Wed, 25 Aug 2010 13:20:13 -0700 (PDT) Received: from [172.35.1.127] (pc3.shinagawaphvod2-unet.ocn.ne.jp [220.110.141.59]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o7PKKDoi021490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Aug 2010 13:20:24 -0700 (PDT) Message-ID: <4C757AF9.9030506@isi.edu> Date: Wed, 25 Aug 2010 13:20:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Michael Richardson References: <201008251320.o7PDKvI3030865@cichlid.raleigh.ibm.com> <4C75752F.5020409@isi.edu> <24957.1282767389@marajade.sandelman.ca> In-Reply-To: <24957.1282767389@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: o7PKKDoi021490 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Thomas Narten , saag@ietf.org Subject: Re: [saag] IPv6 Node Requirements: Updated IPsec/IKEv2 text X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 20:20:19 -0000 On 8/25/2010 1:16 PM, Michael Richardson wrote: >>>>>> "Joe" == Joe Touch writes: > Joe> I feel it is important to indicate the following: > > Joe> --- > > Joe> Any device that acts like a host (i.e., sources packets with IP > Joe> addresses assigned to their own interfaces) and implements > Joe> IPsec MUST implement transport mode. All devices (hosts and > Joe> gateways) that implement IPsec MUST implement tunnel > Joe> mode. Because gateways always act as hosts for some protocols > Joe> (as noted in RFC 1812), the conclusion is that all devices that > Joe> implement IPsec MUST implement both tunnel and transport mode. > > I agree. > > Joe> In summary, > > Joe> a) A host implementation of IPsec MUST support both > Joe> transport and tunnel mode. This is true for native, BITS, and > Joe> BITW implementations for hosts. > > But, I think that this is too much detail. > This is a requirement for IPv6 *native* *host* implementations. Yes, for 6man it might be unnecessary to do this in this doc. (is there any plan to update 4301? if so, would it be preferable to say most of this in that doc?) Joe From paul.hoffman@vpnc.org Wed Aug 25 14:38:49 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6203A6B46; Wed, 25 Aug 2010 14:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.049 X-Spam-Level: X-Spam-Status: No, score=-101.049 tagged_above=-999 required=5 tests=[AWL=0.997, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] 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 0h3f7i7yAYL7; Wed, 25 Aug 2010 14:38:33 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 10FAD3A6B36; Wed, 25 Aug 2010 14:37:15 -0700 (PDT) Received: from [75.101.18.87] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o7PLZn8J043192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Aug 2010 14:35:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C75752F.5020409@isi.edu> References: <201008251320.o7PDKvI3030865@cichlid.raleigh.ibm.com> <4C75752F.5020409@isi.edu> Date: Wed, 25 Aug 2010 14:35:47 -0700 To: Joe Touch , Thomas Narten From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG , saag@ietf.org Subject: Re: [saag] IPv6 Node Requirements: Updated IPsec/IKEv2 text X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 21:38:50 -0000 First off, Thomas gave the wrong pointer. The draft under discussion is draft-ietf-6man-node-req-bis, not draft-ietf-ipv6-node-requirements; the latter became RFC 4294. At 12:55 PM -0700 8/25/10, Joe Touch wrote: >Hi, Tom, > >On 8/25/2010 6:20 AM, Thomas Narten wrote: >>To recap, I presented on the issue of updating the IPsec/IKEv2 text >>at the 6man meeting in Maastricht, as well as at the SAAG meeting. My >>sense of both of those discussions is that there is support for >>changing the general recommendation to a SHOULD. >> >>I got some good feedback in SAAG about the wording (refer to the >>security architecture generally rather than IKEv2, etc.). >> >>New proposed text below. >> >>This text would go into draft-ietf-ipv6-node-requirements, which >>updates RFC 4294. >> >>Comments? > >First, this seems to override Sec 10 of RFC4301, so it would need to update RFC4301 as well. I am quite hesitant to have an Informational RFC update a Proposed Standard RFC. Further, it does not "override" anything: it is suggestions for developers. > >Some other comments below. > >Joe > >>Thomas >> >>10. Security >> >> This section describes the specification for security for IPv6 nodes. >> >> Achieving security in practice is a complex undertaking. Operational >> procedures, protocols, key distribution mechanisms, certificate >> management approaches, etc. are all components that impact the level >> of security actually achieved in practice. More importantly, >> deficiencies or a poor fit in any one individual component can >> significantly reduce the overall effectiveness of a particular >> security approach. >> >> IPsec provides channel security at the Internet layer, making it >> possible to provide secure communication for all (or a subset of) >> communication flows at the IP layer between pairs of internet nodes. >> IPsec provides sufficient flexibility and granularity that individual >> TCP connections can (selectively) be protected, etc. > >IPsec can protect down to the socket pair (src addr/src port/dst addr/dst port) granularity, but there are two important issues. First, this is rarely done; it is more common to protect services (i.e., at least letting the src port of incoming SYNs float). Second, such granularity would reuse an SA for different TCP connections that reuse the port pair. > >I.e., there is no way I am aware of to ensure that IPsec changes SA keys for a socket pair for each TCP connection that reuses that socket. TCP-AO can achieve this, however. > >So it is not individual TCP connections that are protected; it is individual socket pairs (at best), and more likely all connections between two specific endpoints for a given service. > >[FWIW, this might be a good opportunity for the IPsec doc to crossref TCP-AO, and to have at least a short note as to when each is preferred, or to refer to that discussion in the TCP-AO document] I would prefer that this sentence in draft-ietf-6man-node-req-bis be removed and not to confuse IPsec documents with TCP-AO. > >> Although IPsec can be used with manual keying in some cases, such >> usage has limited applicability and is not recommended. >> >> A range of security technologies and approaches proliferate today >> (e.g., IPsec, TLS, SSH, etc.) > >It might be useful to add TCP-AO here. Please don't: it could easily confuse readers into thinking that it does more than authentication. > > > No one approach has emerged as an >> ideal technology for all needs and environments. Moreover, IPsec is >> not viewed as the ideal security technology in all cases and is >> unlikely to displace the others. > >It's important to note, however, that although any of these protects the user data, only IPsec and TCP-AO protect TCP connections from disruption attacks. ...somewhat protect... > >> Previously, IPv6 mandated implementation of IPsec and recommended the >> key management approach of IKE. This document updates that >> recommendation by making support of the IP Security Architecture [RFC >> 4301] a SHOULD for all IPv6 nodes. Note that the IPsec Architecture >> requires (e.g., Sec. 4.5 of RFC 4301) the implementation of both >> manual and automatic key management. Currently the default automated >> key management protocol to implement is IKEv2. >> >> This document recognizes that there exists a range of device types >> and environments where other approaches to security than IPsec can be >> justified. For example, special-purpose devices may support only a >> very limited number or type of applications and an application- >> specific security approach may be sufficient for limited management >> or configuration capabilities. Alternatively, some devices my run on >> extremely constrained hardware (e.g., sensors) where the full IP >> Security Architecture is not justified. >> >>10.1. Requirements >> >> "Security Architecture for the Internet Protocol" [RFC4301] SHOULD be >> supported by all IPv6 nodes. Note that the IPsec Architecture >> requires (e.g., Sec. 4.5 of RFC 4301) the implementation of both >> manual and automatic key management. Currently the default automated >> key management protocol to implement is IKEv2. >> >>10.2. Transforms and Algorithms >> >> The current set of mandatory-to-implement algorithms for the IP >> Security Architcture are defined in 'Cryptographic Algorithm >> Implementation Requirements For ESP and AH' [RFC4835]. IPv6 nodes >> implementing the IP Security Architecture MUST conform to the >> requirements in [RFC4835]. Preferred cryptographic algorithms often >> change more frequently than security protocols. Therefore >> implementations MUST allow for migration into new algorithms, as >> RFC4835 is replaced or updated in the future. > >This might also be a good opportunity to revisit the issue of recommendations for tunnel and transport mode inclusion. During the revision of RFC4301, IMO the recommendations on transport mode were vague with respect to routers (RFC4301, end of section 4.1). > >I feel it is important to indicate the following: > >--- > >Any device that acts like a host (i.e., sources packets with IP addresses assigned to their own interfaces) and implements IPsec MUST implement transport mode. Gateways "source packets with IP addresses assigned to their own interfaces". I would strongly object efforts to reverse the IPsec WG's decision to reduce the demands for transport mode. >All devices (hosts and gateways) that implement IPsec MUST implement tunnel mode. Because gateways always act as hosts for some protocols (as noted in RFC 1812), the conclusion is that all devices that implement IPsec MUST implement both tunnel and transport mode. > > In summary, > > a) A host implementation of IPsec MUST support both transport and > tunnel mode. This is true for native, BITS, and BITW > implementations for hosts. > > b) A security gateway MUST support both transport and tunnel mode. > Transport mode should be used only when the security gateway > is acting as a host, e.g., for network management, or to > provide security between two intermediate systems along a path, > as to secure a tunnel whose encapsulation is not provided > by IPsec tunnel mode. Joe: what has changed since the IPsec WG decided the other way years ago that would require this change? --Paul Hoffman, Director --VPN Consortium From mcr@sandelman.ca Wed Aug 25 14:51:24 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD5A73A6964 for ; Wed, 25 Aug 2010 14:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 sDPJCZuKFBBT for ; Wed, 25 Aug 2010 14:51:23 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 98B023A69ED for ; Wed, 25 Aug 2010 14:51:23 -0700 (PDT) Received: from marajade.sandelman.ca (66-78-101-3.access.ripnet.com [66.78.101.3]) by relay.sandelman.ca (Postfix) with ESMTPS id 0DB323460A; Wed, 25 Aug 2010 17:51:56 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 3471A98A94; Wed, 25 Aug 2010 17:51:55 -0400 (EDT) From: Michael Richardson To: Joe Touch In-Reply-To: <4C75752F.5020409@isi.edu> References: <201008251320.o7PDKvI3030865@cichlid.raleigh.ibm.com> <4C75752F.5020409@isi.edu> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Wed, 25 Aug 2010 17:51:55 -0400 Message-ID: <27736.1282773115@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: Thomas Narten , saag@ietf.org Subject: Re: [saag] IPv6 Node Requirements: Updated IPsec/IKEv2 text X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 21:51:25 -0000 >>>>> "Joe" == Joe Touch writes: Joe> I feel it is important to indicate the following: Joe> --- Joe> Any device that acts like a host (i.e., sources packets with IP Joe> addresses assigned to their own interfaces) and implements Joe> IPsec MUST implement transport mode. All devices (hosts and Joe> gateways) that implement IPsec MUST implement tunnel Joe> mode. Because gateways always act as hosts for some protocols Joe> (as noted in RFC 1812), the conclusion is that all devices that Joe> implement IPsec MUST implement both tunnel and transport mode. I agree. Joe> In summary, Joe> a) A host implementation of IPsec MUST support both Joe> transport and tunnel mode. This is true for native, BITS, and Joe> BITW implementations for hosts. But, I think that this is too much detail. This is a requirement for IPv6 *native* *host* implementations. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@sandelman.ca Wed Aug 25 14:51:31 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14453A6B1A for ; Wed, 25 Aug 2010 14:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.024 X-Spam-Level: X-Spam-Status: No, score=-1.024 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 ud+0mFTtl8+L for ; Wed, 25 Aug 2010 14:51:30 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id C6ED33A69ED for ; Wed, 25 Aug 2010 14:51:30 -0700 (PDT) Received: from marajade.sandelman.ca (66-78-101-3.access.ripnet.com [66.78.101.3]) by relay.sandelman.ca (Postfix) with ESMTPS id 735D83474D; Wed, 25 Aug 2010 17:52:03 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id BF48A98A94; Wed, 25 Aug 2010 17:52:02 -0400 (EDT) From: Michael Richardson To: saag@ietf.org In-Reply-To: <201008251320.o7PDKvI3030865@cichlid.raleigh.ibm.com> References: <201008251320.o7PDKvI3030865@cichlid.raleigh.ibm.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Wed, 25 Aug 2010 17:52:02 -0400 Message-ID: <27747.1282773122@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: Thomas Narten Subject: Re: [saag] IPv6 Node Requirements: Updated IPsec/IKEv2 text X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 21:51:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas, I agree with your text, and I agree with the reasoning for doing this. I am sad that we have to write it, that we still have no useful key distribution system. I'm also sad that we still have no published API for IPsec. I think that the get-out-of-jail-free last paragraph: This document recognizes that there exists a range of device types and environments where other approaches to security than IPsec can be justified. For example, special-purpose devices may support only a very limited number or type of applications and an application- specific security approach may be sufficient for limited management or configuration capabilities. Alternatively, some devices my run on extremely constrained hardware (e.g., sensors) where the full IP Security Architecture is not justified. needs some refinement. What I want to have stated is that an IPsec system SHOULD be available on all general purpose *HOSTS* (and that should include tunnel mode, and automatic keying). I do not want to dilute the message we have had about IPsec, to the audience of operating system vendors (*BSDs, Linux distros, Microsoft, Wind River, QNX, etc...), and general purpose network protocol stacks. Having said that, I think the right "out" is that while IPsec SHOULD be available on the *platform*, it does not need to be shipped in the resulting binary image if there is no application actually invokes it. I don't know really how to write this. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Finger me for keys iQEVAwUBTHV7p4CLcPvd0N1lAQJGkwgAk9BJJQqtBQ7Qz/VL+T8u8dk2me++czoo by6oaoHpEjP14jLqbCn4Aylu7dHu+2k1CkA38NIL38QYibDGV+VgMKFbjsWb7Bjl 70FCyG2Q5j7M8uG9qWfcPczLGRrXpBzRusf6kw+B/EnTj47VOcQbWCtOkVwKaJbq Ml7bHip65D8VhzVfB/68P+6ZZC1PDf0SaCCvWDAqifl5XTMddDruze7eFhYkapqp Gb/wIWbCdS6XXSEWXrSoQC3UMGXGlag8EXFkL4VqPEm8ngVCqogHDOEufYH2SxoK JoDwgSH9602J8SkO9W8fm3r5A+lP+xxUjh+cS7+QhGZ+mf8+WiMHeA== =qWms -----END PGP SIGNATURE----- From Nicolas.Williams@oracle.com Wed Aug 25 15:01:53 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 309493A6837 for ; Wed, 25 Aug 2010 15:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 qn3lsrqYXPIJ for ; Wed, 25 Aug 2010 15:01:52 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id E99983A63C9 for ; Wed, 25 Aug 2010 15:01:51 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7PM2M82028856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Aug 2010 22:02:23 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7PM2LeZ008210; Wed, 25 Aug 2010 22:02:21 GMT Received: from abhmt006.oracle.com by acsmt353.oracle.com with ESMTP id 532150481282773705; Wed, 25 Aug 2010 15:01:45 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Aug 2010 15:01:45 -0700 Date: Wed, 25 Aug 2010 17:01:40 -0500 From: Nicolas Williams To: Michael Richardson Message-ID: <20100825220140.GH17097@oracle.com> References: <201008251320.o7PDKvI3030865@cichlid.raleigh.ibm.com> <27747.1282773122@marajade.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27747.1282773122@marajade.sandelman.ca> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: Thomas Narten , saag@ietf.org Subject: Re: [saag] IPv6 Node Requirements: Updated IPsec/IKEv2 text X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 22:01:53 -0000 On Wed, Aug 25, 2010 at 05:52:02PM -0400, Michael Richardson wrote: > I think that the get-out-of-jail-free last paragraph: > > This document recognizes that there exists a range of device types > and environments where other approaches to security than IPsec can be > justified. For example, special-purpose devices may support only a > very limited number or type of applications and an application- > specific security approach may be sufficient for limited management > or configuration capabilities. Alternatively, some devices my run on > extremely constrained hardware (e.g., sensors) where the full IP > Security Architecture is not justified. > > needs some refinement. What I want to have stated is that an IPsec > system SHOULD be available on all general purpose *HOSTS* > (and that should include tunnel mode, and automatic keying). > I do not want to dilute the message we have had about IPsec, to the > audience of operating system vendors (*BSDs, Linux distros, Microsoft, > Wind River, QNX, etc...), and general purpose network protocol stacks. > > Having said that, I think the right "out" is that while IPsec SHOULD be > available on the *platform*, it does not need to be shipped in the > resulting binary image if there is no application actually invokes it. > I don't know really how to write this. If we're going to have "get-out-of-jail-free" text, might as well "require" or "recommend" connection latching [RFC5660] for hosts' native IPsec, while we're at it. Nico -- From touch@isi.edu Wed Aug 25 15:11:58 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ED1B3A6B61; Wed, 25 Aug 2010 15:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 DeZSECNA8ecz; Wed, 25 Aug 2010 15:11:30 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 7A6593A695E; Wed, 25 Aug 2010 15:11:22 -0700 (PDT) Received: from [172.35.1.127] (pc3.shinagawaphvod2-unet.ocn.ne.jp [220.110.141.59]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o7PMBEcZ011586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Aug 2010 15:11:25 -0700 (PDT) Message-ID: <4C7594ED.5000403@isi.edu> Date: Wed, 25 Aug 2010 15:10:53 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Paul Hoffman References: <201008251320.o7PDKvI3030865@cichlid.raleigh.ibm.com> <4C75752F.5020409@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: o7PMBEcZ011586 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Thomas Narten , IPsecme WG , saag@ietf.org Subject: Re: [saag] IPv6 Node Requirements: Updated IPsec/IKEv2 text X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 22:11:59 -0000 On 8/25/2010 2:35 PM, Paul Hoffman wrote: > First off, Thomas gave the wrong pointer. The draft under discussion is draft-ietf-6man-node-req-bis, not draft-ietf-ipv6-node-requirements; the latter became RFC 4294. > > At 12:55 PM -0700 8/25/10, Joe Touch wrote: >> Hi, Tom, >> >> On 8/25/2010 6:20 AM, Thomas Narten wrote: >>> To recap, I presented on the issue of updating the IPsec/IKEv2 text >>> at the 6man meeting in Maastricht, as well as at the SAAG meeting. My >>> sense of both of those discussions is that there is support for >>> changing the general recommendation to a SHOULD. >>> >>> I got some good feedback in SAAG about the wording (refer to the >>> security architecture generally rather than IKEv2, etc.). >>> >>> New proposed text below. >>> >>> This text would go into draft-ietf-ipv6-node-requirements, which >>> updates RFC 4294. >>> >>> Comments? >> >> First, this seems to override Sec 10 of RFC4301, so it would need to update RFC4301 as well. > > I am quite hesitant to have an Informational RFC update a Proposed Standard RFC. Further, it does not "override" anything: it is suggestions for developers. An suggestion for developers to ignore a standard (esp. using RFC2119 language) necessarily updates that standard. > >> >> Some other comments below. >> >> Joe >> >>> Thomas >>> >>> 10. Security >>> >>> This section describes the specification for security for IPv6 nodes. >>> >>> Achieving security in practice is a complex undertaking. Operational >>> procedures, protocols, key distribution mechanisms, certificate >>> management approaches, etc. are all components that impact the level >>> of security actually achieved in practice. More importantly, >>> deficiencies or a poor fit in any one individual component can >>> significantly reduce the overall effectiveness of a particular >>> security approach. >>> >>> IPsec provides channel security at the Internet layer, making it >>> possible to provide secure communication for all (or a subset of) >>> communication flows at the IP layer between pairs of internet nodes. >>> IPsec provides sufficient flexibility and granularity that individual >>> TCP connections can (selectively) be protected, etc. >> >> IPsec can protect down to the socket pair (src addr/src port/dst addr/dst port) granularity, but there are two important issues. First, this is rarely done; it is more common to protect services (i.e., at least letting the src port of incoming SYNs float). Second, such granularity would reuse an SA for different TCP connections that reuse the port pair. >> >> I.e., there is no way I am aware of to ensure that IPsec changes SA keys for a socket pair for each TCP connection that reuses that socket. TCP-AO can achieve this, however. >> >> So it is not individual TCP connections that are protected; it is individual socket pairs (at best), and more likely all connections between two specific endpoints for a given service. >> >> [FWIW, this might be a good opportunity for the IPsec doc to crossref TCP-AO, and to have at least a short note as to when each is preferred, or to refer to that discussion in the TCP-AO document] > > I would prefer that this sentence in draft-ietf-6man-node-req-bis be > removed and not to confuse IPsec documents with TCP-AO. If you mean removing the sentence "IPsec provides sufficient flexibility and granularity that individual TCP connections can (selectively) be protected, etc.", that would be fine, however it requires removing the text below too. >>> Although IPsec can be used with manual keying in some cases, such >>> usage has limited applicability and is not recommended. >>> >>> A range of security technologies and approaches proliferate today >>> (e.g., IPsec, TLS, SSH, etc.) >> >> It might be useful to add TCP-AO here. > > Please don't: it could easily confuse readers into thinking that it does more than authentication. In that case, TLS and SSH are inappropriate, as including them might confuse readers into thinking they protect the TCP connection (a common mistake already). If this is similarly removed, then that would make sense. ... >> This might also be a good opportunity to revisit the issue of >> recommendations for tunnel and transport mode inclusion. During the >> revision of RFC4301, IMO the recommendations on transport mode were >> vague with respect to routers (RFC4301, end of section 4.1). ... >> In summary, >> >> a) A host implementation of IPsec MUST support both transport and >> tunnel mode. This is true for native, BITS, and BITW >> implementations for hosts. >> >> b) A security gateway MUST support both transport and tunnel mode. >> Transport mode should be used only when the security gateway >> is acting as a host, e.g., for network management, or to >> provide security between two intermediate systems along a path, >> as to secure a tunnel whose encapsulation is not provided >> by IPsec tunnel mode. > > Joe: what has changed since the IPsec WG decided the other way years > ago that would require this change? Hopefully the appreciatoin of the security community that routers *always* act like hosts for at least some of their traffic ;-) Joe From narten@us.ibm.com Thu Aug 26 06:03:52 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 707793A67E2; Thu, 26 Aug 2010 06:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.316 X-Spam-Level: X-Spam-Status: No, score=-106.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 3dhYrnKp1juo; Thu, 26 Aug 2010 06:03:50 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 6E6483A6873; Thu, 26 Aug 2010 06:03:50 -0700 (PDT) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e2.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o7QCo3bZ017144; Thu, 26 Aug 2010 08:50:03 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o7QD4KmF1716294; Thu, 26 Aug 2010 09:04:20 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o7QD4JJr029701; Thu, 26 Aug 2010 10:04:20 -0300 Received: from cichlid.raleigh.ibm.com (sig-9-65-245-223.mts.ibm.com [9.65.245.223]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o7QD4IkB029567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Aug 2010 10:04:19 -0300 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id o7QD4Fs4007247; Thu, 26 Aug 2010 09:04:15 -0400 Message-Id: <201008261304.o7QD4Fs4007247@cichlid.raleigh.ibm.com> To: Paul Hoffman In-reply-to: References: <201008251320.o7PDKvI3030865@cichlid.raleigh.ibm.com> <4C75752F.5020409@isi.edu> Comments: In-reply-to Paul Hoffman message dated "Wed, 25 Aug 2010 14:35:47 -0700." Date: Thu, 26 Aug 2010 09:04:15 -0400 From: Thomas Narten Cc: IPsecme WG , saag@ietf.org Subject: Re: [saag] [IPsec] IPv6 Node Requirements: Updated IPsec/IKEv2 text X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 13:03:52 -0000 Paul Hoffman writes: > First off, Thomas gave the wrong pointer. The draft under discussion > is draft-ietf-6man-node-req-bis, not > draft-ietf-ipv6-node-requirements; the latter became RFC 4294. Thanks for clarifying... > At 12:55 PM -0700 8/25/10, Joe Touch wrote: > >Hi, Tom, > > > >On 8/25/2010 6:20 AM, Thomas Narten wrote: > >>To recap, I presented on the issue of updating the IPsec/IKEv2 text > >>at the 6man meeting in Maastricht, as well as at the SAAG meeting. My > >>sense of both of those discussions is that there is support for > >>changing the general recommendation to a SHOULD. > >> > >>I got some good feedback in SAAG about the wording (refer to the > >>security architecture generally rather than IKEv2, etc.). > >> > >>New proposed text below. > >> > >>This text would go into draft-ietf-ipv6-node-requirements, which > >>updates RFC 4294. > >> > >>Comments? > > > >First, this seems to override Sec 10 of RFC4301, so it would need > >to update RFC4301 as well. Oddly enough, I did not receive Joe's message, so I'll respond to a followup. Section 10 of RFC 4301 says: > 10. Conformance Requirements > > All IPv4 IPsec implementations MUST comply with all requirements of > this document. All IPv6 implementations MUST comply with all > requirements of this document. Yes, this document is essentially updating that statement. Note, however, that the RFC 4294 already does that, because it says IKEv2 is a SHOULD, which contradicts this statement. Also, I think we are recognizing that the above wording is too strong and needs to be updated. Finally, the node requirements document is essentially an applicability statement. Whether it will be Informational or BCP is a bit of a TBD, but in any case there are plenty of applicability statements that are informational. On Applicability Statements, RFC 2026 says: > An AS identifies the relevant TSs and the specific way in which they > are to be combined, and may also specify particular values or ranges > of TS parameters or subfunctions of a TS protocol that must be > implemented. An AS also specifies the circumstances in which the use > of a particular TS is required, recommended, or elective (see section > 3.3). My conclusion is that an AS can make take individual RFCs and say they are required (or not), etc. And also add (or revoke) some requirements that arguably update the spec. But (IMO) this should be done only at a high level (i.e., requiring certain features or modes or profiles) rather than making actual technical changes to a protocol. So I do not believe there is any issue with having this document override Section 10 of 4301. > >IPsec can protect down to the socket pair (src addr/src port/dst > >addr/dst port) granularity, but there are two important > >issues. First, this is rarely done; it is more common to protect > >services (i.e., at least letting the src port of incoming SYNs > >float). Second, such granularity would reuse an SA for different > >TCP connections that reuse the port pair. The point of my text was just to point out that there are filters that can be applied that determine what (and how) sessions are covered by IPsec. Without getting into a lot of detail. And I certainly don't want to get into differences between what the specs allow and what the common usages are. If someone has better text to propose... > >I.e., there is no way I am aware of to ensure that IPsec changes SA > >keys for a socket pair for each TCP connection that reuses that > >socket. TCP-AO can achieve this, however. > > > >So it is not individual TCP connections that are protected; it is > >individual socket pairs (at best), and more likely all connections > >between two specific endpoints for a given service. > > > >[FWIW, this might be a good opportunity for the IPsec doc to > >crossref TCP-AO, and to have at least a short note as to when each > >is preferred, or to refer to that discussion in the TCP-AO > >document] > I would prefer that this sentence in draft-ietf-6man-node-req-bis be > removed and not to confuse IPsec documents with TCP-AO. Which specific sentence? I don't see how anything in the node-req-bis document can be confused with TCP-A0. > > > >> Although IPsec can be used with manual keying in some cases, such > >> usage has limited applicability and is not recommended. > >> > >> A range of security technologies and approaches proliferate today > >> (e.g., IPsec, TLS, SSH, etc.) > > > >It might be useful to add TCP-AO here. > Please don't: it could easily confuse readers into thinking that it > does more than authentication. I don't believe TCP-AO is relevant to the IPv6 Node Requirements document. > > > > > No one approach has emerged as an > >> ideal technology for all needs and environments. Moreover, IPsec is > >> not viewed as the ideal security technology in all cases and is > >> unlikely to displace the others. > > > >It's important to note, however, that although any of these > >protects the user data, only IPsec and TCP-AO protect TCP > >connections from disruption attacks. > ...somewhat protect... This is presumably covered in the IPSec/TCP-A0 documents, and doesn't need to go into the nod-requirements doc.. > >This might also be a good opportunity to revisit the issue of > >> recommendations for tunnel and transport mode > >> inclusion. During the revision of RFC4301, IMO the > >> recommendations on transport mode were vague with respect to > >> routers (RFC4301, end of section 4.1). > > > >I feel it is important to indicate the following: > > > >--- > > > >Any device that acts like a host (i.e., sources packets with IP > >> addresses assigned to their own interfaces) and implements > >> IPsec MUST implement transport mode. IMO, this is for the IPsecME WG to figure out, not the IPv6 Node Requirements doc. One of the the things node requrirements will now do is just point to the "IP Security Architecture" document and defer to it for all the details. Thomas From turners@ieca.com Fri Aug 27 12:21:05 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B78F33A6ABB for ; Fri, 27 Aug 2010 12:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.539 X-Spam-Level: X-Spam-Status: No, score=-101.539 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_05=-1.11, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] 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 2w5nhdi9-FTe for ; Fri, 27 Aug 2010 12:21:04 -0700 (PDT) Received: from smtp113.biz.mail.mud.yahoo.com (smtp113.biz.mail.mud.yahoo.com [209.191.68.78]) by core3.amsl.com (Postfix) with SMTP id 5A9F73A6A76 for ; Fri, 27 Aug 2010 12:21:04 -0700 (PDT) Received: (qmail 64053 invoked from network); 27 Aug 2010 19:21:30 -0000 Received: from thunderfish.local (turners@96.241.9.17 with plain) by smtp113.biz.mail.mud.yahoo.com with SMTP; 27 Aug 2010 12:21:30 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 9t2ziTMVM1lGDIDdmjFPeIy0pa..hUY10EZp3v6sDj5Hw2A NmDWZNqRLdSTp7JMIOK7.ZMNvy2uq9RZIX0JCVjz3YwDlUekA7PHTQ5XAcRC 45ESwnXikj149dQEFPnhASCqiL5uQcp2ZTcW3cZRKXY8DLJTaMUB1OWWb4Wl 6FhVtM4hWLA8zWnSAMUZxWfJUMUxB_4AZSrs96X0RBjoC_SZePIkGy_tfpPp jnRURK3YicnRNHtbIWwhm8tDOtvSV_8eS7b6b5PdXtwmz7c_JFD1GGr3W4CQ XGmunlGry6WYbZTq2rYhLGw9im9IrQ19YgSEdi0_jyyiNF9NxfqhGVQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C78103A.3090000@ieca.com> Date: Fri, 27 Aug 2010 15:21:30 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Cipher suite proliferation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 19:21:06 -0000 At SAAG, I gave a short presentation about how Tim and I were thinking about a change to what track we put "how to use those algorithms with a particular protocol" drafts: http://www.ietf.org/proceedings/78/slides/saag-4.pdf. I'd like to hear the community's thoughts on whether we should continue with the status quo or whether we should make a change (see below). The current status quo is for the algorithm documents to go on the informational track and for the how to use algorithm x with protocol y on standards track. Recently, at least one WG has declined to adopt as WG items drafts that specify how to use algorithm x with their particular protocol. Obviously, the authors then come to the ADs. Tim and I have been thinking that most of these drafts should go on informational. We thought that the following would be how we'd decide what track to put a draft on: 1) Submit an individual I-D documenting the how to use algorithm x with protocol y (document the cryptographic algorithm somewhere else). 2) Ask the WG for adoption. If the answer is no, then jump to #5. 3) Proceed as WG document. WG selects and requests the track. 4) AD processes the document normally. In general, this means progressing on the requested track. If the WG proposed standards track, then the AD will consider whether there is broad international support, there is a need, and there are implementations. The AD may decide to request publication as Informational if support is not broad support, there is no need, and if there are no implementations. 5) Authors ask for AD sponsorship of I-D. 6) AD will ask the following question: Is there broad international support, is there a need, and are there implementations? If the answer is no, then jump to #8. 7) AD will sponsor the document for publication on standards track. 8) AD will sponsor the document on either informational or experimental track. We'd like to hear whether we should keep the status quo (either because you like it or think we're making a mountain out of mole hill) or whether the steps above should be used. Thanks, spt From ynir@checkpoint.com Fri Aug 27 13:47:36 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13DFD3A67B5 for ; Fri, 27 Aug 2010 13:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] 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 zbPJ6sRIUfVY for ; Fri, 27 Aug 2010 13:47:34 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 251B93A6828 for ; Fri, 27 Aug 2010 13:47:33 -0700 (PDT) X-CheckPoint: {4C7831D2-F-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o7RKm1SP014788; Fri, 27 Aug 2010 23:48:01 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 27 Aug 2010 23:48:42 +0300 From: Yoav Nir To: Sean Turner Date: Fri, 27 Aug 2010 23:47:58 +0300 Thread-Topic: [saag] Cipher suite proliferation Thread-Index: ActGKTr9wPg8ur9pTcmvSPKE+9pKUg== Message-ID: References: <4C78103A.3090000@ieca.com> In-Reply-To: <4C78103A.3090000@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "saag@ietf.org" Subject: Re: [saag] Cipher suite proliferation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 20:47:36 -0000 Hi Sean In most cases, I think steps 2-5 are superfluous. I don't think the workin= g group has much to contribute. If I submit a draft called "ROT13 and its use in IPsec", assuming that an i= nformational RFC already exists for ROT13, there's really very little for t= he working group to do. They can't change ROT13, and they wouldn't want to.= There's usually very little interaction between the protocol and the algo= rithm. Of course there are some things to consider, like how big the IV is = for ROT13, and what kind of padding is required, but I think the high road = should be getting it published as an individual. IOW, unless there's some v= ery unique interaction between the algorithm and the protocol, the authors = shouldn't need to ask the WG for adoption. Instead, the authors go straight= to the AD, and the AD asks on the protocol mailing list whether people the= re think this should go through the WG. Yoav On Aug 27, 2010, at 10:21 PM, Sean Turner wrote: > At SAAG, I gave a short presentation about how Tim and I were thinking=20 > about a change to what track we put "how to use those algorithms with=20 > a particular protocol" drafts:=20 > http://www.ietf.org/proceedings/78/slides/saag-4.pdf. I'd like to=20 > hear the community's thoughts on whether we should continue with the=20 > status quo or whether we should make a change (see below). >=20 > The current status quo is for the algorithm documents to go on the=20 > informational track and for the how to use algorithm x with protocol y=20 > on standards track. >=20 > Recently, at least one WG has declined to adopt as WG items drafts=20 > that specify how to use algorithm x with their particular protocol.=20 > Obviously, the authors then come to the ADs. >=20 > Tim and I have been thinking that most of these drafts should go on=20 > informational. We thought that the following would be how we'd decide=20 > what track to put a draft on: >=20 > 1) Submit an individual I-D documenting the how to use algorithm x=20 > with protocol y (document the cryptographic algorithm somewhere else). >=20 > 2) Ask the WG for adoption. If the answer is no, then jump to #5. >=20 > 3) Proceed as WG document. WG selects and requests the track. >=20 > 4) AD processes the document normally. In general, this means=20 > progressing on the requested track. If the WG proposed standards=20 > track, then the AD will consider whether there is broad international=20 > support, there is a need, and there are implementations. The AD may=20 > decide to request publication as Informational if support is not broad=20 > support, there is no need, and if there are no implementations. >=20 > 5) Authors ask for AD sponsorship of I-D. >=20 > 6) AD will ask the following question: Is there broad international=20 > support, is there a need, and are there implementations? If the=20 > answer is no, then jump to #8. >=20 > 7) AD will sponsor the document for publication on standards track. >=20 > 8) AD will sponsor the document on either informational or=20 > experimental track. >=20 > We'd like to hear whether we should keep the status quo (either=20 > because you like it or think we're making a mountain out of mole hill)=20 > or whether the steps above should be used. >=20 > Thanks, >=20 > spt > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 > Scanned by Check Point Total Security Gateway. From bernard_aboba@hotmail.com Sat Aug 28 21:41:23 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D16E3A6784 for ; Sat, 28 Aug 2010 21:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.645 X-Spam-Level: X-Spam-Status: No, score=-101.645 tagged_above=-999 required=5 tests=[AWL=0.953, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 ayBkpm221L9P for ; Sat, 28 Aug 2010 21:41:21 -0700 (PDT) Received: from blu0-omc1-s24.blu0.hotmail.com (blu0-omc1-s24.blu0.hotmail.com [65.55.116.35]) by core3.amsl.com (Postfix) with ESMTP id 7EF653A6783 for ; Sat, 28 Aug 2010 21:41:21 -0700 (PDT) Received: from BLU137-W14 ([65.55.116.9]) by blu0-omc1-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 28 Aug 2010 21:41:53 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_487e43f9-caf6-4b9a-a056-767723107001_" X-Originating-IP: [64.134.138.11] From: Bernard Aboba To: , Date: Sat, 28 Aug 2010 21:41:52 -0700 Importance: Normal In-Reply-To: References: <4C78103A.3090000@ieca.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 29 Aug 2010 04:41:53.0202 (UTC) FILETIME=[809FD120:01CB4734] Cc: saag@ietf.org Subject: Re: [saag] Cipher suite proliferation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2010 04:41:23 -0000 --_487e43f9-caf6-4b9a-a056-767723107001_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Yoav -- these kind of documents should in most cases be inform= ational. =20 In general=2C I do not feel that ADs should be sponsoring a large number of= Standards Track documents outside of WGs. The situation where there is wi= despread international interest=2C and yet no WG exists or can be created t= o handle the item seems like a contradiction. Something is badly broken if= this becomes a regular occurrence (as it seems to have). Either we have I= ANA allocation policies that require standards documents in situations wher= e this should not be necessary=2C or we are rewarding behavior that should= be discouraged.=20 > From: ynir@checkpoint.com > To: turners@ieca.com > Date: Fri=2C 27 Aug 2010 23:47:58 +0300 > CC: saag@ietf.org > Subject: Re: [saag] Cipher suite proliferation >=20 > Hi Sean >=20 > In most cases=2C I think steps 2-5 are superfluous. I don't think the wo= rking group has much to contribute. >=20 > If I submit a draft called "ROT13 and its use in IPsec"=2C assuming that = an informational RFC already exists for ROT13=2C there's really very little= for the working group to do. They can't change ROT13=2C and they wouldn't = want to. There's usually very little interaction between the protocol and = the algorithm. Of course there are some things to consider=2C like how big = the IV is for ROT13=2C and what kind of padding is required=2C but I think = the high road should be getting it published as an individual. IOW=2C unles= s there's some very unique interaction between the algorithm and the protoc= ol=2C the authors shouldn't need to ask the WG for adoption. Instead=2C the= authors go straight to the AD=2C and the AD asks on the protocol mailing l= ist whether people there think this should go through the WG. >=20 > Yoav >=20 >=20 > On Aug 27=2C 2010=2C at 10:21 PM=2C Sean Turner wrote: >=20 > > At SAAG=2C I gave a short presentation about how Tim and I were thinkin= g=20 > > about a change to what track we put "how to use those algorithms with=20 > > a particular protocol" drafts:=20 > > http://www.ietf.org/proceedings/78/slides/saag-4.pdf. I'd like to=20 > > hear the community's thoughts on whether we should continue with the=20 > > status quo or whether we should make a change (see below). > >=20 > > The current status quo is for the algorithm documents to go on the=20 > > informational track and for the how to use algorithm x with protocol y= =20 > > on standards track. > >=20 > > Recently=2C at least one WG has declined to adopt as WG items drafts=20 > > that specify how to use algorithm x with their particular protocol.=20 > > Obviously=2C the authors then come to the ADs. > >=20 > > Tim and I have been thinking that most of these drafts should go on=20 > > informational. We thought that the following would be how we'd decide= =20 > > what track to put a draft on: > >=20 > > 1) Submit an individual I-D documenting the how to use algorithm x=20 > > with protocol y (document the cryptographic algorithm somewhere else). > >=20 > > 2) Ask the WG for adoption. If the answer is no=2C then jump to #5. > >=20 > > 3) Proceed as WG document. WG selects and requests the track. > >=20 > > 4) AD processes the document normally. In general=2C this means=20 > > progressing on the requested track. If the WG proposed standards=20 > > track=2C then the AD will consider whether there is broad international= =20 > > support=2C there is a need=2C and there are implementations. The AD may= =20 > > decide to request publication as Informational if support is not broad= =20 > > support=2C there is no need=2C and if there are no implementations. > >=20 > > 5) Authors ask for AD sponsorship of I-D. > >=20 > > 6) AD will ask the following question: Is there broad international=20 > > support=2C is there a need=2C and are there implementations? If the=20 > > answer is no=2C then jump to #8. > >=20 > > 7) AD will sponsor the document for publication on standards track. > >=20 > > 8) AD will sponsor the document on either informational or=20 > > experimental track. > >=20 > > We'd like to hear whether we should keep the status quo (either=20 > > because you like it or think we're making a mountain out of mole hill)= =20 > > or whether the steps above should be used. > >=20 > > Thanks=2C > >=20 > > spt > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > >=20 > > Scanned by Check Point Total Security Gateway. >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag = --_487e43f9-caf6-4b9a-a056-767723107001_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Yoav -- these kind of documents should in most cases be inform= ational. =3B

In general=2C I do not feel that ADs should be spo= nsoring a large number of Standards Track documents outside of WGs. =3B= The situation where there is widespread international interest=2C and yet = no WG exists or can be created to handle the item seems like a contradictio= n. =3B Something is badly broken if this becomes a regular occurrence (= as it seems to have). =3B Either we have IANA allocation policies that = require standards documents in situations where this should not =3B be = necessary=2C or we are rewarding behavior that should be discouraged.
<= br>
>=3B From: ynir@checkpoint.com
>=3B To: turners@ieca.com
&= gt=3B Date: Fri=2C 27 Aug 2010 23:47:58 +0300
>=3B CC: saag@ietf.org>=3B Subject: Re: [saag] Cipher suite proliferation
>=3B
>= =3B Hi Sean
>=3B
>=3B In most cases=2C I think steps 2-5 are sup= erfluous. I don't think the working group has much to contribute.
>= =3B
>=3B If I submit a draft called "ROT13 and its use in IPsec"=2C a= ssuming that an informational RFC already exists for ROT13=2C there's reall= y very little for the working group to do. They can't change ROT13=2C and t= hey wouldn't want to. There's usually very little interaction between the = protocol and the algorithm. Of course there are some things to consider=2C = like how big the IV is for ROT13=2C and what kind of padding is required=2C= but I think the high road should be getting it published as an individual.= IOW=2C unless there's some very unique interaction between the algorithm a= nd the protocol=2C the authors shouldn't need to ask the WG for adoption. I= nstead=2C the authors go straight to the AD=2C and the AD asks on the proto= col mailing list whether people there think this should go through the WG.<= br>>=3B
>=3B Yoav
>=3B
>=3B
>=3B On Aug 27=2C 2010= =2C at 10:21 PM=2C Sean Turner wrote:
>=3B
>=3B >=3B At SAAG= =2C I gave a short presentation about how Tim and I were thinking
>= =3B >=3B about a change to what track we put "how to use those algorithms= with
>=3B >=3B a particular protocol" drafts:
>=3B >=3B ht= tp://www.ietf.org/proceedings/78/slides/saag-4.pdf. I'd like to
>=3B= >=3B hear the community's thoughts on whether we should continue with th= e
>=3B >=3B status quo or whether we should make a change (see belo= w).
>=3B >=3B
>=3B >=3B The current status quo is for the al= gorithm documents to go on the
>=3B >=3B informational track and fo= r the how to use algorithm x with protocol y
>=3B >=3B on standards= track.
>=3B >=3B
>=3B >=3B Recently=2C at least one WG has = declined to adopt as WG items drafts
>=3B >=3B that specify how to = use algorithm x with their particular protocol.
>=3B >=3B Obviously= =2C the authors then come to the ADs.
>=3B >=3B
>=3B >=3B Ti= m and I have been thinking that most of these drafts should go on
>= =3B >=3B informational. We thought that the following would be how we'd = decide
>=3B >=3B what track to put a draft on:
>=3B >=3B >=3B >=3B 1) Submit an individual I-D documenting the how to use algor= ithm x
>=3B >=3B with protocol y (document the cryptographic algori= thm somewhere else).
>=3B >=3B
>=3B >=3B 2) Ask the WG for a= doption. If the answer is no=2C then jump to #5.
>=3B >=3B
>= =3B >=3B 3) Proceed as WG document. WG selects and requests the track.>=3B >=3B
>=3B >=3B 4) AD processes the document normally. I= n general=2C this means
>=3B >=3B progressing on the requested trac= k. If the WG proposed standards
>=3B >=3B track=2C then the AD wil= l consider whether there is broad international
>=3B >=3B support= =2C there is a need=2C and there are implementations. The AD may
>=3B= >=3B decide to request publication as Informational if support is not br= oad
>=3B >=3B support=2C there is no need=2C and if there are no im= plementations.
>=3B >=3B
>=3B >=3B 5) Authors ask for AD spo= nsorship of I-D.
>=3B >=3B
>=3B >=3B 6) AD will ask the foll= owing question: Is there broad international
>=3B >=3B support=2C i= s there a need=2C and are there implementations? If the
>=3B >=3B = answer is no=2C then jump to #8.
>=3B >=3B
>=3B >=3B 7) AD w= ill sponsor the document for publication on standards track.
>=3B >= =3B
>=3B >=3B 8) AD will sponsor the document on either information= al or
>=3B >=3B experimental track.
>=3B >=3B
>=3B >= =3B We'd like to hear whether we should keep the status quo (either
>= =3B >=3B because you like it or think we're making a mountain out of mole= hill)
>=3B >=3B or whether the steps above should be used.
>= =3B >=3B
>=3B >=3B Thanks=2C
>=3B >=3B
>=3B >=3B s= pt
>=3B >=3B _______________________________________________
>= =3B >=3B saag mailing list
>=3B >=3B saag@ietf.org
>=3B >= =3B https://www.ietf.org/mailman/listinfo/saag
>=3B >=3B
>=3B = >=3B Scanned by Check Point Total Security Gateway.
>=3B
>=3B = _______________________________________________
>=3B saag mailing list=
>=3B saag@ietf.org
>=3B https://www.ietf.org/mailman/listinfo/sa= ag
= --_487e43f9-caf6-4b9a-a056-767723107001_-- From tobias.gondrom@gondrom.org Sun Aug 29 16:59:18 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 629FD3A683E for ; Sun, 29 Aug 2010 16:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.771 X-Spam-Level: X-Spam-Status: No, score=-94.771 tagged_above=-999 required=5 tests=[AWL=0.590, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] 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 pewOO4D7fzAg for ; Sun, 29 Aug 2010 16:59:16 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 864233A67BE for ; Sun, 29 Aug 2010 16:59:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=PsOHVk9hmkPbteqMazBSV55zCmx4PCja3V40LizQnqhvOj40x4QFcUx9tqWRXE2QT+H8+CJgyz4gdPwOvlUOPUCzoINQxRg6xdcRc0o73MZahAGjXg2u7NUPn3OSxj1F; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 20186 invoked from network); 30 Aug 2010 01:59:05 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Aug 2010 01:59:05 +0200 Message-ID: <4C7AF467.6000103@gondrom.org> Date: Mon, 30 Aug 2010 00:59:35 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 SUSE/3.1.2 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: saag@ietf.org References: <4C78103A.3090000@ieca.com>, In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------010609010406040306080100" Subject: Re: [saag] Cipher suite proliferation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2010 23:59:18 -0000 This is a multi-part message in MIME format. --------------010609010406040306080100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I tend to agree with Bernard on the argument that standards track docs should be in WGs. (reasoning "international interest/need/multiple implementations => WG involvement") In general obviously protocols should be specified with algorithm agility (algorithms can be replaced easily, e.g. load by name/identifier). In a perfect case (if the parameter interface is interchangeable) this would mean you wouldn't even need an info doc for how to use it in the specific protocol and only need the algorithm info doc. However in the real world we know new algorithms frequently require certain interpretation of fields in the protocol which can be done in a short and simple info document. In which case it definitely would be good to ask the WG for review (so that you don't get (mis-)interpretation conflicts) and if the WG declines to adopt this item for any other reasons than time/resource constraints (which wouldn't be a good reason) the AD should consider to send the authors back to the WG to sort things out. To talk about the process: this would replace step #7 with: 7) AD will ask the authors (and WG) the following question: Then why has the WG rejected to adopt the document and are there ways to mitigate these reasons so that it will be adopted? If yes go back to 3) otherwise consider informational status, rejection or under special circumstances make exception and AD will sponsor the document for publication on standards track. just my 5 cents, Tobias On 08/29/2010 05:41 AM, Bernard Aboba wrote: > I agree with Yoav -- these kind of documents should in most cases be > informational. > > In general, I do not feel that ADs should be sponsoring a large number > of Standards Track documents outside of WGs. The situation where > there is widespread international interest, and yet no WG exists or > can be created to handle the item seems like a contradiction. > Something is badly broken if this becomes a regular occurrence (as it > seems to have). Either we have IANA allocation policies that require > standards documents in situations where this should not be necessary, > or we are rewarding behavior that should be discouraged. > > > > From: ynir@checkpoint.com > > To: turners@ieca.com > > Date: Fri, 27 Aug 2010 23:47:58 +0300 > > CC: saag@ietf.org > > Subject: Re: [saag] Cipher suite proliferation > > > > Hi Sean > > > > In most cases, I think steps 2-5 are superfluous. I don't think the > working group has much to contribute. > > > > If I submit a draft called "ROT13 and its use in IPsec", assuming > that an informational RFC already exists for ROT13, there's really > very little for the working group to do. They can't change ROT13, and > they wouldn't want to. There's usually very little interaction between > the protocol and the algorithm. Of course there are some things to > consider, like how big the IV is for ROT13, and what kind of padding > is required, but I think the high road should be getting it published > as an individual. IOW, unless there's some very unique interaction > between the algorithm and the protocol, the authors shouldn't need to > ask the WG for adoption. Instead, the authors go straight to the AD, > and the AD asks on the protocol mailing list whether people there > think this should go through the WG. > > > > Yoav > > > > > > On Aug 27, 2010, at 10:21 PM, Sean Turner wrote: > > > > > At SAAG, I gave a short presentation about how Tim and I were > thinking > > > about a change to what track we put "how to use those algorithms with > > > a particular protocol" drafts: > > > http://www.ietf.org/proceedings/78/slides/saag-4.pdf. I'd like to > > > hear the community's thoughts on whether we should continue with the > > > status quo or whether we should make a change (see below). > > > > > > The current status quo is for the algorithm documents to go on the > > > informational track and for the how to use algorithm x with > protocol y > > > on standards track. > > > > > > Recently, at least one WG has declined to adopt as WG items drafts > > > that specify how to use algorithm x with their particular protocol. > > > Obviously, the authors then come to the ADs. > > > > > > Tim and I have been thinking that most of these drafts should go on > > > informational. We thought that the following would be how we'd decide > > > what track to put a draft on: > > > > > > 1) Submit an individual I-D documenting the how to use algorithm x > > > with protocol y (document the cryptographic algorithm somewhere else). > > > > > > 2) Ask the WG for adoption. If the answer is no, then jump to #5. > > > > > > 3) Proceed as WG document. WG selects and requests the track. > > > > > > 4) AD processes the document normally. In general, this means > > > progressing on the requested track. If the WG proposed standards > > > track, then the AD will consider whether there is broad international > > > support, there is a need, and there are implementations. The AD may > > > decide to request publication as Informational if support is not > broad > > > support, there is no need, and if there are no implementations. > > > > > > 5) Authors ask for AD sponsorship of I-D. > > > > > > 6) AD will ask the following question: Is there broad international > > > support, is there a need, and are there implementations? If the > > > answer is no, then jump to #8. > > > > > > 7) AD will sponsor the document for publication on standards track. > > > > > > 8) AD will sponsor the document on either informational or > > > experimental track. > > > > > > We'd like to hear whether we should keep the status quo (either > > > because you like it or think we're making a mountain out of mole > hill) > > > or whether the steps above should be used. > > > > > > Thanks, > > > > > > spt > > > _______________________________________________ > > > saag mailing list > > > saag@ietf.org > > > https://www.ietf.org/mailman/listinfo/saag > > > > > > Scanned by Check Point Total Security Gateway. > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --------------010609010406040306080100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I tend to agree with Bernard on the argument that standards track docs should be in WGs. (reasoning "international interest/need/multiple implementations => WG involvement")

In general obviously protocols should be specified with algorithm agility (algorithms can be replaced easily, e.g. load by name/identifier). In a perfect case (if the parameter interface is interchangeable) this would mean you wouldn't even need an info doc for how to use it in the specific protocol and only need the algorithm info doc. However in the real world we know new algorithms frequently require certain interpretation of fields in the protocol which can be done in a short and simple info document. In which case it definitely would be good to ask the WG for review (so that you don't get (mis-)interpretation conflicts) and if the WG declines to adopt this item for any other reasons than time/resource constraints (which wouldn't be a good reason) the AD should consider to send the authors back to the WG to sort things out.

To talk about the process: this would replace step #7 with:
7) AD will ask the authors (and WG) the following question: Then why has the WG rejected to adopt the document and are there ways to mitigate these reasons so that it will be adopted? If yes go back to 3) otherwise consider informational status, rejection or under special circumstances make exception and AD will sponsor the document for publication on standards track.

just my 5 cents, Tobias



On 08/29/2010 05:41 AM, Bernard Aboba wrote:
I agree with Yoav -- these kind of documents should in most cases be informational. 

In general, I do not feel that ADs should be sponsoring a large number of Standards Track documents outside of WGs.  The situation where there is widespread international interest, and yet no WG exists or can be created to handle the item seems like a contradiction.  Something is badly broken if this becomes a regular occurrence (as it seems to have).  Either we have IANA allocation policies that require standards documents in situations where this should not  be necessary, or we are rewarding behavior that should be discouraged.


> From: ynir@checkpoint.com
> To: turners@ieca.com
> Date: Fri, 27 Aug 2010 23:47:58 +0300
> CC: saag@ietf.org
> Subject: Re: [saag] Cipher suite proliferation
>
> Hi Sean
>
> In most cases, I think steps 2-5 are superfluous. I don't think the working group has much to contribute.
>
> If I submit a draft called "ROT13 and its use in IPsec", assuming that an informational RFC already exists for ROT13, there's really very little for the working group to do. They can't change ROT13, and they wouldn't want to. There's usually very little interaction between the protocol and the algorithm. Of course there are some things to consider, like how big the IV is for ROT13, and what kind of padding is required, but I think the high road should be getting it published as an individual. IOW, unless there's some very unique interaction between the algorithm and the protocol, the authors shouldn't need to ask the WG for adoption. Instead, the authors go straight to the AD, and the AD asks on the protocol mailing list whether people there think this should go through the WG.
>
> Yoav
>
>
> On Aug 27, 2010, at 10:21 PM, Sean Turner wrote:
>
> > At SAAG, I gave a short presentation about how Tim and I were thinking
> > about a change to what track we put "how to use those algorithms with
> > a particular protocol" drafts:
> > http://www.ietf.org/proceedings/78/slides/saag-4.pdf. I'd like to
> > hear the community's thoughts on whether we should continue with the
> > status quo or whether we should make a change (see below).
> >
> > The current status quo is for the algorithm documents to go on the
> > informational track and for the how to use algorithm x with protocol y
> > on standards track.
> >
> > Recently, at least one WG has declined to adopt as WG items drafts
> > that specify how to use algorithm x with their particular protocol.
> > Obviously, the authors then come to the ADs.
> >
> > Tim and I have been thinking that most of these drafts should go on
> > informational. We thought that the following would be how we'd decide
> > what track to put a draft on:
> >
> > 1) Submit an individual I-D documenting the how to use algorithm x
> > with protocol y (document the cryptographic algorithm somewhere else).
> >
> > 2) Ask the WG for adoption. If the answer is no, then jump to #5.
> >
> > 3) Proceed as WG document. WG selects and requests the track.
> >
> > 4) AD processes the document normally. In general, this means
> > progressing on the requested track. If the WG proposed standards
> > track, then the AD will consider whether there is broad international
> > support, there is a need, and there are implementations. The AD may
> > decide to request publication as Informational if support is not broad
> > support, there is no need, and if there are no implementations.
> >
> > 5) Authors ask for AD sponsorship of I-D.
> >
> > 6) AD will ask the following question: Is there broad international
> > support, is there a need, and are there implementations? If the
> > answer is no, then jump to #8.
> >
> > 7) AD will sponsor the document for publication on standards track.
> >
> > 8) AD will sponsor the document on either informational or
> > experimental track.
> >
> > We'd like to hear whether we should keep the status quo (either
> > because you like it or think we're making a mountain out of mole hill)
> > or whether the steps above should be used.
> >
> > Thanks,
> >
> > spt
> > _______________________________________________
> > saag mailing list
> > saag@ietf.org
> > https://www.ietf.org/mailman/listinfo/saag
> >
> > Scanned by Check Point Total Security Gateway.
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

--------------010609010406040306080100-- From housley@vigilsec.com Tue Aug 31 13:18:22 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62883A6AA9 for ; Tue, 31 Aug 2010 13:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=-0.959, BAYES_20=-0.74, USER_IN_WHITELIST=-100] 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 Yo6ucnRrjHjY for ; Tue, 31 Aug 2010 13:18:21 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 794253A69C2 for ; Tue, 31 Aug 2010 13:18:21 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id D39DC9A479D; Tue, 31 Aug 2010 16:18:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id qo7cfEg0Rlgo; Tue, 31 Aug 2010 16:18:50 -0400 (EDT) Received: from [192.168.2.100] (pool-96-231-149-87.washdc.fios.verizon.net [96.231.149.87]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id D2AD59A4792; Tue, 31 Aug 2010 16:18:53 -0400 (EDT) Message-ID: <4C7D63A8.9060700@vigilsec.com> Date: Tue, 31 Aug 2010 16:18:48 -0400 From: Russ Housley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: IETF SAAG , IRTF CFRG X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: [saag] Request for Comments - NIST Draft SP 800-135: Recommendation for Application-Specific Key Derivation Functions X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 20:18:22 -0000 -------- Original Message -------- Subject: Request for Comments - NIST Draft SP 800-135: Recommendation for Application-Specific Key Derivation Functions NIST requests comments on Draft SP 800-135, Recommendation for Application-Specific Key Derivation Functions. The document specifies security requirements for existing application-specific key derivation functions in: American National Standard (ANS) X9.42-2001-Public Key Cryptography for the Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography, American National Standard (ANS) X9.63-2001-Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography, Internet Key Exchange, Secure Shell, Transport Layer Security, The Secure Real-time Transport Protocol, User-based Security Model for version 3 of the Simple Network Management Protocol , and Trusted Platform Module. The document is available at http://csrc.nist.gov/publications/drafts/800-135/draft-sp800-135.pdf. Please provide comments by September 30th 2010 to quynh.dang@nist.gov with “Comments on Draft SP 800-135” in the subject line. For additional questions, please do not use reply. Contact Quynh Dang (quynh.dang@nist.gov)