From nobody Wed Sep 2 15:29:04 2015 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BC21B4F44 for ; Wed, 2 Sep 2015 15:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8b0K5ThGDkR3 for ; Wed, 2 Sep 2015 15:29:00 -0700 (PDT) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD56B1B4EA2 for ; Wed, 2 Sep 2015 15:29:00 -0700 (PDT) Received: from [192.168.2.3] ([96.232.183.194]) by vms173017.mailsrvcs.net (Oracle Communications Messaging Server 7.0.5.32.0 64bit (built Jul 16 2014)) with ESMTPA id <0NU20030CMFQ1E40@vms173017.mailsrvcs.net> for pkix@ietf.org; Wed, 02 Sep 2015 17:28:39 -0500 (CDT) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=btqxfxui c=1 sm=1 tr=0 a=5ZXnV2Q94l8MeMpHIT5/oQ==:117 a=o1OHuDzbAAAA:8 a=oR5dmqMzAAAA:8 a=IkcTkHD0fZMA:10 a=ff-B7xzCdYMA:10 a=NojBvPlNQhcZeHcMvRAA:9 a=QEXdDO2ut3YA:10 To: pkix@ietf.org From: Joel Kazin Message-id: <55E77815.9080703@verizon.net> Date: Wed, 02 Sep 2015 18:28:37 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit Archived-At: Subject: [pkix] RSA -CRT Key Leaks X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: joel.kazin1@verizon.net List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 22:29:03 -0000 Has anyone seen today's RedHat announcement regarding "RSA-CRT Key Leaks"? Regards, Joel From nobody Wed Sep 2 21:40:34 2015 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E311B325E for ; Wed, 2 Sep 2015 21:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wy4jPm55ymQ9 for ; Wed, 2 Sep 2015 21:40:32 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E76A01B303F for ; Wed, 2 Sep 2015 21:40:31 -0700 (PDT) Received: by wibz8 with SMTP id z8so85301727wib.1 for ; Wed, 02 Sep 2015 21:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:cc:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=gtMJZ/iHscRKEL1xXw27PrTK/BMgQOoFerilszxI/e4=; b=rXBayplPgLc+z5rm3uUvH5MDQQjnFt0yotrN7FH+9+JHgD/6Hxr+k4pBp+7KycegeE q/euh5E1CKcb6R65uyW+DrTqtyPgbB2tCQYrN0NvdaKbe+0u2ImaVSR0fqHp0/n/wGQc CgSnZ7WDc4dKWMN3CBoOU1kcZ8mNzJrxU1/Xr7zwrbGNos2uYgbAfSZGHpXBTcpWpj6c UEYqZfg5ez4QXMjggHpOilZHr2wBhMCEWgOPJXJdBmsLwcdkX0M8FpHh1cTAopkxcYYK /eGFbJy23bz06G3CadexMEaZAFgZIXPljqR4p+89uO4zc4EM+boo6Bq8F5YFrq83s3ut +7Ag== X-Received: by 10.180.104.68 with SMTP id gc4mr10768682wib.67.1441255230481; Wed, 02 Sep 2015 21:40:30 -0700 (PDT) Received: from [192.168.1.79] (240.196.130.77.rev.sfr.net. [77.130.196.240]) by smtp.googlemail.com with ESMTPSA id ul1sm35646805wjc.30.2015.09.02.21.40.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Sep 2015 21:40:29 -0700 (PDT) To: "pkix@ietf.org" From: Anders Rundgren Message-ID: <55E7CF30.9000006@gmail.com> Date: Thu, 3 Sep 2015 06:40:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [pkix] X.509 client certificates on Web - Deprecated by Google X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 04:40:33 -0000 https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack/discussion "While a use case exists for provisioning TLS client certificates for authentication, such a use case is inherently user-hostile for usability, and represents an authentication scheme that does not work well for the web. An alternative means for addressing this use case is to employ the work of the FIDO Alliance [12], which has strong positive signals from Microsoft and Google (both in the WG), is already supported via extensions in Chrome [13], with Mozilla evaluating support via similar means [14]. This offers a more meaningful way to offer strong, non-phishable authentication, in a manner that is more privacy preserving, offers a better user experience, better standards support, and more robust security capabilities" W3C.org spokesmen are now speaking the same language: https://lists.w3.org/Archives/Public/www-tag/2015Sep/0011.html "There have been several high-profile attacks on client certificates (see for example "Triple Hand-shake" [1]) that make client certificates a not suitable for authentication systems. X.509 is also problematic to parse, leading to security issues [2]. While FIDO is not perfect (the privacy community needs to look at the channel ID work too), its definitely best of breed right now and I think will solve your use-case over the course of the next year" -- Anders From nobody Thu Sep 3 01:36:02 2015 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B1D1B3F71 for ; Thu, 3 Sep 2015 01:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLA4Py1rZERw for ; Thu, 3 Sep 2015 01:35:59 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D292D1B335E for ; Thu, 3 Sep 2015 01:35:58 -0700 (PDT) Received: by wibz8 with SMTP id z8so90473967wib.1 for ; Thu, 03 Sep 2015 01:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=o2+MvZD8jlTpXmdrphMOGw/djP0BVUyHPLwFRw68jwI=; b=hLHQtNsZcqYWE2SDCXL6GItE9bAoWh5+RgKFrJcF+DjYupWkSrkLS5GX06JrM+c/ct jfNAeAA8IRxYSuRneJrXpx5dlS4o03Tm+c6Qp3xnp+tiq228DL+vnT5QxC2ngDuE2g25 QzW6dfutwFQ08UFjvNxUGF4OWaLxnFyVAKeqOGALEHeHkT9Pxts+9ljmQYYAL1xFheUp YyL8BynRFbw7BoN/fTsMktvDEEDAPv/HF43cg9BbfLyaZak2gF4qmlL/Eh9z4X9eZ612 Pob+Q9OqpWx4CzeGSzIj7N8BlRaX7nRGkrBfP+w0FSsVk3IIfWSuKVzhQzqjFroffOyi NeXw== X-Received: by 10.180.108.35 with SMTP id hh3mr11651152wib.48.1441269357431; Thu, 03 Sep 2015 01:35:57 -0700 (PDT) Received: from [172.24.250.167] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id 4sm36523963wjt.46.2015.09.03.01.35.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Sep 2015 01:35:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Yoav Nir In-Reply-To: <55E7CF30.9000006@gmail.com> Date: Thu, 3 Sep 2015 11:35:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <867FF7DA-C849-4535-A28A-14D475656A65@gmail.com> References: <55E7CF30.9000006@gmail.com> To: Anders Rundgren X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "pkix@ietf.org" Subject: Re: [pkix] X.509 client certificates on Web - Deprecated by Google X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 08:36:01 -0000 Hi, Anders. I think at least the title of this message is misleading. Google is not = deprecating client certificates. They=E2=80=99re deprecating the keygen = attribute in forms (which could be used in enrollment, but there are = other ways). These are very different things. Yoav > On Sep 3, 2015, at 7:40 AM, Anders Rundgren = wrote: >=20 > = https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xa= ck/discussion >=20 > "While a use case exists for provisioning TLS client certificates for = authentication, such a use case is inherently user-hostile for = usability, and represents an authentication scheme that does not work = well for the web. An alternative means for addressing this use case is = to employ the work of the FIDO Alliance [12], which has strong positive = signals from Microsoft and Google (both in the WG), is already supported = via extensions in Chrome [13], with Mozilla evaluating support via = similar means [14]. This offers a more meaningful way to offer strong, = non-phishable authentication, in a manner that is more privacy = preserving, offers a better user experience, better standards support, = and more robust security capabilities" >=20 > W3C.org spokesmen are now speaking the same language: > https://lists.w3.org/Archives/Public/www-tag/2015Sep/0011.html >=20 > "There have been several high-profile attacks on client certificates = (see > for example "Triple Hand-shake" [1]) that make client certificates a = not > suitable for authentication systems. X.509 is also problematic to = parse, > leading to security issues [2]. While FIDO is not perfect (the privacy > community needs to look at the channel ID work too), its definitely = best of > breed right now and I think will solve your use-case over the course = of the > next year" >=20 > -- Anders >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From nobody Thu Sep 3 04:53:05 2015 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D0B1A90AC for ; Thu, 3 Sep 2015 04:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggIiF-REgSCV for ; Thu, 3 Sep 2015 04:53:02 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5F0B1B2AA7 for ; Thu, 3 Sep 2015 04:53:01 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so5237900wic.1 for ; Thu, 03 Sep 2015 04:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=NMgmzfEDGyZRZzFB8y0dZsE+Tjl2DuCvgXfnDVmnkhU=; b=IpnKTTh4KWmVym/wdegvi/ykHEJK871QqyXpmRql3N+bDvp2vwdyTwj8/v9qR0v2OJ 1MbU3GkXScr9/PbMyRu9lW/3kpvNSAswWNBjXbxIiwqKx6u+PVi89OLygBRhlCy56Tla QP11d1GAKTNocsncciLiTz/Dyl1JY9am0tRYz1nghoxp9MGoNHZeKrDrGDuwau4xeON4 9NIFbtsDqKn9VrNZpxrJd+H/rDhJRyOBA7MGltoqMaVu13nRjp6yQTlYatwGJCIOtOy1 hkYT4W/hDSyQT/4FiA2HnpBc5xI1Ir/LilxlWUM8fa71Cz+wUHcCnJ8Ap8DXNwtGrg2S jRrw== X-Received: by 10.194.174.201 with SMTP id bu9mr55545864wjc.73.1441281180422; Thu, 03 Sep 2015 04:53:00 -0700 (PDT) Received: from [192.168.1.79] (240.196.130.77.rev.sfr.net. [77.130.196.240]) by smtp.googlemail.com with ESMTPSA id p5sm8626267wiy.17.2015.09.03.04.52.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Sep 2015 04:52:59 -0700 (PDT) To: Yoav Nir References: <55E7CF30.9000006@gmail.com> <867FF7DA-C849-4535-A28A-14D475656A65@gmail.com> From: Anders Rundgren Message-ID: <55E8349A.1050502@gmail.com> Date: Thu, 3 Sep 2015 13:52:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <867FF7DA-C849-4535-A28A-14D475656A65@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "pkix@ietf.org" Subject: Re: [pkix] X.509 client certificates on Web - Deprecated by Google X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 11:53:04 -0000 On 2015-09-03 10:35, Yoav Nir wrote: > Hi, Anders. > > I think at least the title of this message is misleading. Google is not > deprecating client certificates. They’re deprecating the keygen attribute > in forms (which could be used in enrollment, but there are other ways). > > These are very different things. I have followed these discussions in other contexts but I believe that the subject line properly reflects the following words by the Google spokesman: >> While a use case exists for provisioning TLS client certificates for authentication, >> such a use case is inherently user-hostile for usability, and represents an authentication >> scheme that does not work well for the web. A more interesting discussion is, how did we end up here? IMO, Google have come to a logical conclusion. For example, if you insert an empty PKI-card in a machine running the leading desktop OS, typically nothing happens! FIDO U2F tokens OTOH are (or will be) usable as is. Unlike traditional smart cards FIDO tokens does not require a unique driver that some obscure third-party is supposed to supply and maintain over OS/browser generations. That is, it is not FIDO alliance that won due to a superior concept, but the USG + MSFT who never managed creating a useful product that also could work for other people than a handful of rather deep-pocketed governments. Anders > > Yoav > >> On Sep 3, 2015, at 7:40 AM, Anders Rundgren wrote: >> >> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack/discussion >> >> "While a use case exists for provisioning TLS client certificates for authentication, >> such a use case is inherently user-hostile for usability, and represents an authentication >> scheme that does not work well for the web. An alternative means for addressing this use case is to employ the work of the FIDO Alliance [12], which has strong positive signals from Microsoft and Google (both in the WG), is already supported via extensions in Chrome [13], with Mozilla evaluating support via similar means [14]. This offers a more meaningful way to offer strong, non-phishable authentication, in a manner that is more privacy preserving, offers a better user experience, better standards support, and more robust security capabilities" >> >> W3C.org spokesmen are now speaking the same language: >> https://lists.w3.org/Archives/Public/www-tag/2015Sep/0011.html >> >> "There have been several high-profile attacks on client certificates (see >> for example "Triple Hand-shake" [1]) that make client certificates a not >> suitable for authentication systems. X.509 is also problematic to parse, >> leading to security issues [2]. While FIDO is not perfect (the privacy >> community needs to look at the channel ID work too), its definitely best of >> breed right now and I think will solve your use-case over the course of the >> next year" >> >> -- Anders >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > From nobody Fri Sep 4 08:15:20 2015 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8051B3ECC for ; Fri, 4 Sep 2015 08:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.512 X-Spam-Level: X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeRkwcTnvwFH for ; Fri, 4 Sep 2015 08:15:17 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ADBA1B3F1E for ; Fri, 4 Sep 2015 08:15:14 -0700 (PDT) From: Ben Wilson To: "pkix@ietf.org" Thread-Topic: [cabfpub] "Authorized Port" Thread-Index: AQHQ5ux/4R6DBWINQ0uXBg5MSibV1Z4sd45QgAAA2jA= Date: Fri, 4 Sep 2015 15:15:11 +0000 Message-ID: <3ceb014355e543358b89447e5d989996@EX2.corp.digicert.com> References: <35eec2f189bd4a89a4b16ce46a378ddc@EX2.corp.digicert.com> <55E95788.6030505@mozilla.org> <2e76c8bbafe641acaefa036d17c5ea75@EX2.corp.digicert.com> In-Reply-To: <2e76c8bbafe641acaefa036d17c5ea75@EX2.corp.digicert.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.137.52.8] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001B_01D0E6F2.332262B0" MIME-Version: 1.0 Archived-At: Subject: [pkix] FW: [cabfpub] "Authorized Port" X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 15:15:19 -0000 ------=_NextPart_000_001B_01D0E6F2.332262B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Forwarding to this list for additional input. -----Original Message----- From: public-bounces@cabforum.org [mailto:public-bounces@cabforum.org] = On Behalf Of Ben Wilson Sent: Friday, September 4, 2015 9:03 AM To: Gervase Markham ; Ryan Sleevi (sleevi@google.com) = ; CABFPub Subject: Re: [cabfpub] "Authorized Port" This is good discussion. Let's keep it up. We need more people to = chime in. -----Original Message----- From: Gervase Markham [mailto:gerv@mozilla.org] Sent: Friday, September 4, 2015 2:34 AM To: Ben Wilson ; CABFPub Subject: Re: [cabfpub] "Authorized Port" >On 03/09/15 18:06, Ben Wilson wrote: >> The Validation Working Group is considering amendments to the domain=20 >> validation processes. Two of those processes use the concept of an=20 >> =E2=80=9Cauthorized port=E2=80=9D in order to limit the threat of = approvals occurring=20 >> through ports that are not =E2=80=9Cwell-known=E2=80=9D. > Why would one want to permit approvals for an SSL certificate through = a port=20 > which was well-known for not being SSL? > Is this because of STARTTLS and equivalents? > I also agree with Ryan that control of any port over 1024 should not = be considered to=20 > be the same as control of the server or the FQDN which points to it. > Gerv >>> All, >>> The Validation Working Group is considering amendments to the domain = validation processes. =20 >>> Two of those processes use the concept of an =E2=80=9Cauthorized = port=E2=80=9D in order to limit the threat of=20 >>> approvals occurring through ports that are not = =E2=80=9Cwell-known=E2=80=9D. =20 >>> Here is the relevant language of the draft ballot: >>> >>> 6. Having the Applicant demonstrate control over the requested FQDN = by installing a Random Value=20 >>> (contained in the name of the file, the content of a file, on a web = page in the form of a meta tag, or=20 >>> any other format as determined by the CA) under = "/.well-known/validation" directory on an Authorized=20 >>> Domain Name that can be validated over an Authorized Port; >>> =E2=80=A6=20 >>> 9. Having the Applicant demonstrate control over the FQDN by the = Applicant requesting and then=20 >>> installing a Test Certificate issued by the CA on the FQDN which is = accessed and then validated via=20 >>> https by the CA over an Authorized Port; >>> I have argued in support of at least the following ports: >>> Authorized Ports Not SSL/TLS SSL/TLS=09 =09 >>> ftp 20-21 989-990=09 >>> ssh 22 =09 >>> telnet 23 992=09 >>> smtp 25, 587 465=09 >>> http 80 443=09 >>> pop 110 995=09 >>> nntp 119 563=09 >>> imap 143 993=09 >>> irc 194 994=09 >>> ldap 389 636=09 >>> sip 5060 5061=09 =09 >>> Sample of ports that wouldn't be included (among 1,000s of others) = =09 >>> sftp 115 =09 >>> active-directory 445 =09 >>> rfs 556 =09 >>> filemaker 591 =09 >>> rpc-over-http 593 =09 >>> ieee-mms-ssl 695 =09 >>> kerberos 749-752 =09 >>> brocade-ssl 898 =09 >>> vmware 901-904 =09 >>> ibm 1364 =09 >>> c-panel 2083 =09 =09 >>> In a written list I included port 24 (private mail) and 991 (network = news) because=20 >>> they were consecutive within a series below for the definition of = =E2=80=9CAuthorized Port=E2=80=9D=E2=80=93=20 >>> >>> =E2=80=9C =E2=80=9CAuthorized Port=E2=80=9D means ports 20-25, 80, = 110, 119, 143, 194, 389, 443, 465,=20 >>> 563, 587, 636, 989-995.=E2=80=9D >>> I=E2=80=99ve told the Validation Working Group that I think we need = to reach outside=20 >>> the Validation WG to confirm whether this limited list is of the = right scope. =20 >>> If you have any opinions, please respond. >>> Thanks, >>> Ben ------=_NextPart_000_001B_01D0E6F2.332262B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPbTCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVcMIIERKADAgECAhAMG2qF 18Knj+K2cgPYZemjMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA4MTgwMDAwMDBaFw0xNzExMTUxMjAwMDBaMHsxCzAJBgNV BAYTAlVTMQ0wCwYDVQQIEwRVdGFoMQ0wCwYDVQQHEwRMZWhpMREwDwYDVQQKEwhEaWdpQ2VydDET MBEGA1UEAxMKQmVuIFdpbHNvbjEmMCQGCSqGSIb3DQEJARYXYmVuLndpbHNvbkBkaWdpY2VydC5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvBF9t5KSCVpI5mOksdt4LXSVlGe0e 8c4rRjarjYUULH1Xir7dP6b0XXPk0irY+fJENLUNQSElLjo6+WweE3iAqKFDK8kc0PfEJWu0pCsE RF+mLckqmZfr43PibltF/eQMdGh42Htd6Q/syx5mxk7psDX8WzYtv49RHjv7SFppdbGg/5zC6L1l rgoT3dMOAsuBMb92OgbJdDhCHoW0wMNTG9pAQIqD/+nHe9A1YAaqy8/AvpFmiHy6aG08A/P8MKxr NADbTRcdw8c/MbHzER5BNeNBZJoX/KIDtTP4Z3tjs0CVFQES2GteciA5aea3EQyBUX400Vw2hE1K t3Tx3gKXAgMBAAGjggHwMIIB7DAfBgNVHSMEGDAWgBTnAiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNV HQ4EFgQUlCtMKwyNpE/klJJs717TGjQbVCMwIgYDVR0RBBswGYEXYmVuLndpbHNvbkBkaWdpY2Vy dC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCBiAYD VR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1 cmVkSURDQS1nMS5jcmwwPaA7oDmGN2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNI QTJBc3N1cmVkSURDQS1nMS5jcmwwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAECMCowKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMweQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYIKwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRz LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS5jcnQwDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQsFAAOCAQEAiaAF3ci5gYviMPYpn0gymye+BT9oQPvmThKJt2Hgwl/NTLwUkBip Tq+9ZTFroiF397/ZWMo5aZciqswFuRVWW9L+5RCBKDZ0vcUvHu+TCAtHMLzXC8UbXdGdw7HEyQzt IAb1PuiI/Ow9MX6uqvteD6Rc3v25OESWJs1zDD16GAxXYoKFmdHSoZ/3NcJOqhy5ctJfow5dNGkF k/jrFYCDG2FeYSWbwteEaLHuo4hXAMYfjP65T1JXKNOVv3dx9T9eD32dPu6mz0bogfniP007Rl+n xS05cWcL1YwuElHVhn27KlUqXB5dGRmAXjkjkS3uaVmK1cXiic3hSqfoc7/46DCCBk4wggU2oAMC AQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGln aUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFow ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO 3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBa GAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVt mc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXG m+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC +DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAm MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaG NGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmww HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQG CCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0 AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4A YwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBk ACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQA IAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQBy AGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYA ZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAU Reuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8Qov yTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtag AT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn 7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIE bNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3 CUnP1fhls+DibsIxggOvMIIDqwIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIg QXNzdXJlZCBJRCBDQQIQDBtqhdfCp4/itnID2GXpozAJBgUrDgMCGgUAoIICCzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA5MDQxNTE1MTBaMCMGCSqGSIb3DQEJ BDEWBBRL65qPv+KOD7eU/LDgBpmVYNKnGzCBiAYJKwYBBAGCNxAEMXsweTBlMQswCQYDVQQGEwJV UzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYD VQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAwbaoXXwqeP4rZyA9hl6aMwgYoGCyqG SIb3DQEJEAILMXugeTBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYD VQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQg Q0ECEAwbaoXXwqeP4rZyA9hl6aMwgZMGCSqGSIb3DQEJDzGBhTCBgjALBglghkgBZQMEASowCwYJ YIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEw DQYJKoZIhvcNAQEBBQAEggEASl8KVpZQfPnHnMaBZF3uj3WWgzEk6UM5YfCXSmNWXxFyv8O24q/E EYjxD5Z2wc5K6X3eBofQqWq6IY6cN49DIX0bJb56Y8yjufNlwaUPoOMLiZ/AlA4hHuwmt9KG5B8q BOJCCrY19+uyMM8EIJLgd1AhArE/59WIbQoHFtgT3zn+OXNo1raCRKBKf2VwkmWq/MrsTb5p1nPV 4TTkLs9RuQikOA/7DSylm3XWOelnhKo996jz9vBUktKqbMrEfQiMmxiLOn7/CIChOw925JgWlCCN 8ZrVozrNrN5+4cvvSQ22I8ApTmLtNCrCcsq80u2QVgz+AV8TyYwyBXacQHTXlwAAAAAAAA== ------=_NextPart_000_001B_01D0E6F2.332262B0-- From nobody Sat Sep 5 07:23:40 2015 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BED1B49E2; Sat, 5 Sep 2015 07:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8iJ3lKP9yTL; Sat, 5 Sep 2015 07:23:35 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6311B474B; Sat, 5 Sep 2015 07:23:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1A5CEBE32; Sat, 5 Sep 2015 15:23:33 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnasG8XDktBC; Sat, 5 Sep 2015 15:23:30 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.21.56]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 73551BDF9; Sat, 5 Sep 2015 15:23:30 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1441463010; bh=J4EbKohn3CqLQ2cN2qYfuF+w1HdSBlAkiCrv1aIgz/4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=XGBBQEcZtvSzBwzm0J5kUGjskA1EWV3Fhn88AWKq92cembZ9cTT2S3GFU0kjA2jV8 hbDufHqbyDGPsX2hdJnv762ame6jE7cUW7se5X52vtn+CGub+I95WuHjzGG7Toh8UV ctkpOBjjQtoYcxO8U9jbvOKLBL4SJ1RiZmXOaFEU= To: Sean Leonard , pkix@ietf.org, saag@ietf.org References: <20141113051500.12824.67140.idtracker@ietfa.amsl.com> <8FF19ABF-17F7-4A83-ABF9-DF84C93528A8@seantek.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <55EAFAE2.9040107@cs.tcd.ie> Date: Sat, 5 Sep 2015 15:23:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <8FF19ABF-17F7-4A83-ABF9-DF84C93528A8@seantek.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [pkix] (it updates RFC 2585) New Version Notification for draft-seantek-certfrag-02.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2015 14:23:37 -0000 Hi, Sean has asked me if I'd be ok with AD sponsoring this one. While it seems reasonable as a thing one might want to do, I haven't seen that it is something anyone else wants to use so I'm not convinced for now. If you would use this or especially if you would implement this, please speak up now. If you think doing this is a bad plan, now is also a fine time to speak up. My plan is to decide in a couple of weeks (Sep 19th). The default if we get silence is that I'd not be sponsoring this one. If the response is that a bunch of folks would use or implement, I'd be fine with AD sponsoring it. Thanks, S. On 13/11/14 05:23, Sean Leonard wrote: > draft-seantek-certfrag-02 has been posted. > > Among other nits, I think that this draft needs to be Standards Track with IETF Consensus because it updates RFC 2585, which is Standards Track, and application/pkix-cert and application/pkix-crl are in the standards tree [RFC 6838]. > > (Thanks Sean T.) > > Sean > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-seantek-certfrag-02.txt >> Date: November 12, 2014 at 7:15:00 PM HST > > A new version of I-D, draft-seantek-certfrag-02.txt > has been successfully submitted by Sean Leonard and posted to the > IETF repository. > > Name: draft-seantek-certfrag > Revision: 02 > Title: URI Fragment Identifiers for the application/pkix-cert Media Type > Document date: 2014-11-12 > Group: Individual Submission > Pages: 4 > URL: http://www.ietf.org/internet-drafts/draft-seantek-certfrag-02.txt > Status: https://datatracker.ietf.org/doc/draft-seantek-certfrag/ > Htmlized: http://tools.ietf.org/html/draft-seantek-certfrag-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-seantek-certfrag-02 > > Abstract: > This memo describes Uniform Resource Identifier (URI) fragment > identifiers for PKIX certificates, which are identified with the > Internet media type application/pkix-cert. > > > The IETF Secretariat > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From nobody Tue Sep 8 13:08:31 2015 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27A81A6FF8; Tue, 8 Sep 2015 11:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sj5p-uICgZtn; Tue, 8 Sep 2015 11:33:19 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7FE1A7113; Tue, 8 Sep 2015 11:33:19 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t88IPAvT029603; Tue, 8 Sep 2015 11:33:00 -0700 Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0a-0016f401.pphosted.com with ESMTP id 1wqwrk0vtv-2 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 08 Sep 2015 11:33:00 -0700 Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 8 Sep 2015 11:32:59 -0700 Received: from SC-EXCH03.marvell.com ([fe80::6cb0:4dfa:f3f3:b8b6]) by SC-EXCH03.marvell.com ([fe80::6cb0:4dfa:f3f3:b8b6%21]) with mapi id 15.00.1044.021; Tue, 8 Sep 2015 11:32:59 -0700 From: Paul Lambert To: Stephen Farrell , Sean Leonard , "pkix@ietf.org" , "saag@ietf.org" Thread-Topic: [saag] [pkix] (it updates RFC 2585) New Version Notification for draft-seantek-certfrag-02.txt Thread-Index: AQHQ5+aJJoI9xQUJuE+O4MuCRoB4eJ4y+cQA Date: Tue, 8 Sep 2015 18:32:59 +0000 Message-ID: References: <20141113051500.12824.67140.idtracker@ietfa.amsl.com> <8FF19ABF-17F7-4A83-ABF9-DF84C93528A8@seantek.com> <55EAFAE2.9040107@cs.tcd.ie> In-Reply-To: <55EAFAE2.9040107@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.94.250.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1430FAA412BE884E81DB4D16342902EF@marvell.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-09-08_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1509080257 Archived-At: X-Mailman-Approved-At: Tue, 08 Sep 2015 13:08:30 -0700 Subject: Re: [pkix] [saag] (it updates RFC 2585) New Version Notification for draft-seantek-certfrag-02.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 18:33:23 -0000 >Sean has asked me if I'd be ok with AD sponsoring this one. While it >seems reasonable as a thing one might want to do, I haven't seen that >it is something anyone else wants to use so I'm not convinced for now. The application and semantics of this RFC is unclear. The only text describing a use case is: "For example, a user agent may wish to draw attention to the "notAfter" time for an expired certificate.=B2 This seems broken in that the semantics of any one field needs to include a notion of the validity of the certificate. "A URI that identifies a certificate will likely be used by an application or user for some security-related service, such as to retrieve the certificate as part of a validation procedure. When a fragment identifies a part of a certificate, the application will define the behavioral semantics. " > >If you would use this or especially if you would implement this, please >speak up now. If you think doing this is a bad plan, now is also a >fine time to speak up. > >My plan is to decide in a couple of weeks (Sep 19th). The default if we >get silence is that I'd not be sponsoring this one. If the response is >that a bunch of folks would use or implement, >=20 Not interested and usage appears to be potentially problematic. Paul >I'd be fine with AD >sponsoring it. > >Thanks, >S. > >On 13/11/14 05:23, Sean Leonard wrote: >> draft-seantek-certfrag-02 has been posted. >>=20 >> Among other nits, I think that this draft needs to be Standards Track >>with IETF Consensus because it updates RFC 2585, which is Standards >>Track, and application/pkix-cert and application/pkix-crl are in the >>standards tree [RFC 6838]. >>=20 >> (Thanks Sean T.) >>=20 >> Sean >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for draft-seantek-certfrag-02.txt >>> Date: November 12, 2014 at 7:15:00 PM HST >>=20 >> A new version of I-D, draft-seantek-certfrag-02.txt >> has been successfully submitted by Sean Leonard and posted to the >> IETF repository. >>=20 >> Name: draft-seantek-certfrag >> Revision: 02 >> Title: URI Fragment Identifiers for the application/pkix-cert Media >>Type >> Document date: 2014-11-12 >> Group: Individual Submission >> Pages: 4 >> URL: =20 >>http://www.ietf.org/internet-drafts/draft-seantek-certfrag-02.txt >> Status: https://datatracker.ietf.org/doc/draft-seantek-certfrag/ >> Htmlized: http://tools.ietf.org/html/draft-seantek-certfrag-02 >> Diff: =20 >>http://www.ietf.org/rfcdiff?url2=3Ddraft-seantek-certfrag-02 >>=20 >> Abstract: >> This memo describes Uniform Resource Identifier (URI) fragment >> identifiers for PKIX certificates, which are identified with the >> Internet media type application/pkix-cert. >>=20 >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >>=20 > >_______________________________________________ >saag mailing list >saag@ietf.org >https://www.ietf.org/mailman/listinfo/saag From nobody Wed Sep 9 15:34:30 2015 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991D41B3570; Wed, 9 Sep 2015 15:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puAi4V5f_Vit; Wed, 9 Sep 2015 15:34:26 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ACE31B35C4; Wed, 9 Sep 2015 15:34:26 -0700 (PDT) Received: from smize.t-mobile.com (unknown [162.248.119.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9B69F509BB; Wed, 9 Sep 2015 18:34:23 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_94E96916-09B6-4E6C-81C0-2DB42CD2DB32"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: Date: Wed, 9 Sep 2015 15:33:47 -0700 Message-Id: <860D66D4-6D96-4BAA-9869-ED5091CB4DB3@seantek.com> References: <20141113051500.12824.67140.idtracker@ietfa.amsl.com> <8FF19ABF-17F7-4A83-ABF9-DF84C93528A8@seantek.com> <55EAFAE2.9040107@cs.tcd.ie> To: Paul Lambert X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "pkix@ietf.org" , "saag@ietf.org" Subject: Re: [pkix] [saag] (it updates RFC 2585) New Version Notification for draft-seantek-certfrag-02.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 22:34:27 -0000 --Apple-Mail=_94E96916-09B6-4E6C-81C0-2DB42CD2DB32 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello: On Sep 8, 2015, at 11:32 AM, Paul Lambert wrote: >=20 >=20 >=20 >> Sean has asked me if I'd be ok with AD sponsoring this one. While it >> seems reasonable as a thing one might want to do, I haven't seen that >> it is something anyone else wants to use so I'm not convinced for = now. >=20 > The application and semantics of this RFC is unclear. The only text > describing a use case is: > "For example, a user agent may wish to draw > attention to the "notAfter" time for an > expired certificate.=B2 >=20 >=20 > This seems broken in that the semantics of any one field needs to = include > a notion of the validity of the certificate. Not really, or at least, that was not the intent. notAfter is just a = field in the certificate. The purpose of the example was to motivate a = use case, namely, if the certificate is expired in some validation = context, the user agent can generate a URI like: view-source://internal/checkcert?cert=3Dfoo#na so that the modular certificate viewing component can highlight that = particular data field. An equally potent example could be given if the certificate is valid, to = highlight when the certificate expires. Yet another example could be = given is nobody has done a validation check; the user agent just wants = to point out the notAfter time. To reduce confusion, I can change that sentence to: =93For example, a user agent may wish to draw attention to the = "notAfter" field of a certificate.=94 -Sean --Apple-Mail=_94E96916-09B6-4E6C-81C0-2DB42CD2DB32 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUwOTA5MjIzNDIzWjAjBgkqhkiG9w0BCQQxFgQUMqo5/59UzYycoHGhD4l6dnb2EIswgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAAtXRuPWpOVd5JWI7kmCwFJgEc/mGFeyRCCDLYLZfUG0GqsHOZuKwYJDHJQYC5pt8147 e8RiaeG/IRBslnGiRFnIvPuBe/I37oK2ep0Jbtbk7Cbkp8KcHI05MBC3xN1whTw+pkeu/MzodflG A2x+hVuWGoUA5glNGnSBRPvWfaBcNcuL9Zv3EH0zFxT8lgx4DFwtX6Gx3KIMtelogOkk654XCMPT Ney+43aLWk7cg7KFWhkhsMIGO6M6qtSmM+rqOwzrarD4KQgi/IVc77MCdB4SPxBlccrHKkzc/sGX vxfYVi6zpC9DDrch+tj7SWe3FZltzfZUfPu0u9I9NI14bC4AAAAAAAA= --Apple-Mail=_94E96916-09B6-4E6C-81C0-2DB42CD2DB32-- From nobody Wed Sep 16 00:18:34 2015 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2A91B3814 for ; Wed, 16 Sep 2015 00:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QQeD_WmyQGy for ; Wed, 16 Sep 2015 00:18:32 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7311B3813 for ; Wed, 16 Sep 2015 00:18:31 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so59046862wic.1 for ; Wed, 16 Sep 2015 00:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=hbYcGAQjqVut8X8GgoXIYr5AvYSOo+F4lBhIgantlI4=; b=mWXNwua0YrTIvYRxuw3z5SbR8NOrW3hEK+Ll7sK6fCS+dUFQAgZNSqXjuIv2GF8IlG ydCy6KgLDUgBjhTiQn+ky0SeL7QZulq/lgLikA7RNL17Knr+BHUOsEOlpagaLVEFbLAA DDmF6ZxeFtLHOk5LE5pGY92ftlg/jDMB1EcmwFwn/mT+YVheF4y71BAExQu194uB+Dmd rqDesZC4cwLo9YrSJ5FOWcqwTh2DFatE25ju3Y8GrBUNEnemYF57c/140PunSZIOyrv8 2WTa2P+hugGrnX8IJHEooItRVeXMO6y5q41s8n5lyLUtHlu2rLkL8GorDXgIaw1RnQt+ yu3A== X-Received: by 10.180.182.107 with SMTP id ed11mr15830805wic.52.1442387910268; Wed, 16 Sep 2015 00:18:30 -0700 (PDT) Received: from [192.168.1.79] (240.196.130.77.rev.sfr.net. [77.130.196.240]) by smtp.googlemail.com with ESMTPSA id fs2sm2867117wib.12.2015.09.16.00.18.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Sep 2015 00:18:29 -0700 (PDT) To: "pkix@ietf.org" From: Anders Rundgren Message-ID: <55F917BC.2060600@gmail.com> Date: Wed, 16 Sep 2015 09:18:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [pkix] More on the deprecation of X.509 client certificates on the Web X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 07:18:33 -0000 Bard Hill (Facebook security expert): https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0093.html "and it puts authentication at a layer (the TLS handshake) where it is fundamentally problematic to the commonplace scalability and performance architecture of anything but hobbyist-level applications" I agree with this [somewhat exaggerated] statement but taken literally it means that PIV won't (or shouldn't) be used on the Web since HTTPS CCA (Client Certificate Authentication) is the [currently] only solution available. From nobody Wed Sep 23 01:33:47 2015 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323BB1A90B9; Wed, 23 Sep 2015 01:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCPfeh5jPcsF; Wed, 23 Sep 2015 01:33:43 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 399831A90B2; Wed, 23 Sep 2015 01:33:43 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t8N8XUkT021975 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 23 Sep 2015 10:33:31 +0200 X-Hashcash: 1:22:150923:pkix@ietf.org::jAU7Y69C4DrSexDc:2yzV X-Hashcash: 1:22:150923:tls@ietf.org::vBH60bfgnUawp94b:1Rz3 From: Simon Josefsson To: pkix@ietf.org, tls@ietf.org OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt Date: Wed, 23 Sep 2015 10:33:29 +0200 Message-ID: <878u7xtu06.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: [pkix] Updated EdDSA/Ed25519 PKIX document X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 08:33:45 -0000 --=-=-= Content-Type: text/plain Hi all, I have pushed out a new version of the document describing EdDSA public keys, signatures and certificates for PKIX. The change in -03 include the addition of the prehash mode, test vectors generated by GnuTLS, and a section recommending certain human readable names. https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-03 I've started a thread to discuss whether it is wortwhile to be able to use the same Ed25519 key for both PureEdDSA mode and HashEdDSA signing, and I'd appreciate feedback on whether people are interested in this and generally if it is a good idea or not. The complexity involved make me shy away a bit from it, but it is fun to consider. The thread is here: https://moderncrypto.org/mail-archive/curves/2015/000630.html /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWAmPZAAoJEIYLf7sy+BGd4hIH/2WL9dTkGnh5iK4Bpqbckc0O RDaIHxJefE0qcKjvIbmGUJr02+8LE3dHMxSbDQ4oOc4ewsOIHD9dt2jDXjPQqtWs 60XzY7nvgZcdZi9S1uDa4LuVRwUdr/H51Qzic81e+M46RAMdAbNohuSQ6vaDbI7p 8DHg4odKXNKiCTHr8j0wzqFBtaF1Fd/2cLAUKVR2GO3MBH0fqbp4obObR8ngzRz+ NQiO/JzJkeaRGmRH+yrlspV/Nyb/zlf0D0q9uJ4Zipz7yfCvhEp/P3E2+Cbcg01M 5YUYMVosUEdyXzzgsVzHez4JSEX/uE9HGmOLyFUIf1DKoKS1mcONKVFH1DYzX5k= =YNAk -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Sep 23 20:23:51 2015 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC551B367A; Wed, 23 Sep 2015 20:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXv4JGBzxwW6; Wed, 23 Sep 2015 20:23:48 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id C72511B3679; Wed, 23 Sep 2015 20:23:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.17,579,1437400800"; d="scan'208";a="119105769" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 24 Sep 2015 13:23:46 +1000 X-IronPort-AV: E=McAfee;i="5700,7163,7933"; a="25869545" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcdvi.tcif.telstra.com.au with ESMTP; 24 Sep 2015 13:23:46 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Thu, 24 Sep 2015 13:23:46 +1000 From: "Manger, James" To: Simon Josefsson , "pkix@ietf.org" , "tls@ietf.org" Date: Thu, 24 Sep 2015 13:23:45 +1000 Thread-Topic: [pkix] Updated EdDSA/Ed25519 PKIX document Thread-Index: AdD12pVU/mpM/hKjSpWqsOnwHJSkkQAm4V3A Message-ID: <255B9BB34FB7D647A506DC292726F6E13BAE1499A2@WSMSG3153V.srv.dir.telstra.com> References: <878u7xtu06.fsf@latte.josefsson.org> In-Reply-To: <878u7xtu06.fsf@latte.josefsson.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [pkix] Updated EdDSA/Ed25519 PKIX document X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 03:23:50 -0000 Hi Simon, two technical typos: The example cert in 8.2 has the wrong OID for the signature. Cert has { 1 3 101 100 1 } [encoding 06 04 2B656401] Text has { 1 3 101 101 } [encoding 06 03 2B6565] for id-EdDSASignature OIDs use space-separated (not dot-separated) numbers in ASN.1. Section 4: Wrong { 1.3.101.100 } Right { 1 3 101 100 } Section 7 Wrong { 1.3.101.101 } Right { 1 3 101 101 } The cert's notBefore field is a UTCTime value (2-digit year), while the not= After field is a GeneralizedTime value (4-digit year). I don't think I has = seen that before, but it is valid. -- James Manger -----Original Message----- From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Simon Josefsson Sent: Wednesday, 23 September 2015 6:33 PM To: pkix@ietf.org; tls@ietf.org Subject: [pkix] Updated EdDSA/Ed25519 PKIX document Hi all, I have pushed out a new version of the document describing EdDSA public key= s, signatures and certificates for PKIX. The change in -03 include the add= ition of the prehash mode, test vectors generated by GnuTLS, and a section = recommending certain human readable names. https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-03 I've started a thread to discuss whether it is wortwhile to be able to use = the same Ed25519 key for both PureEdDSA mode and HashEdDSA signing, and I'd= appreciate feedback on whether people are interested in this and generally= if it is a good idea or not. The complexity involved make me shy away a b= it from it, but it is fun to consider. The thread is here: https://moderncrypto.org/mail-archive/curves/2015/000630.html /Simon From nobody Thu Sep 24 04:04:47 2015 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE651A1ACC; Thu, 24 Sep 2015 04:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhmiTjYff2GS; Thu, 24 Sep 2015 04:04:43 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8B21A1B05; Thu, 24 Sep 2015 04:04:42 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t8OB4Tjt012982 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 24 Sep 2015 13:04:30 +0200 From: Simon Josefsson To: "Manger\, James" References: <878u7xtu06.fsf@latte.josefsson.org> <255B9BB34FB7D647A506DC292726F6E13BAE1499A2@WSMSG3153V.srv.dir.telstra.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150924:pkix@ietf.org::iaDt6CdqSOa0wwMD:9okn X-Hashcash: 1:22:150924:james.h.manger@team.telstra.com::UqTr615ggexAQeBH:AEvI X-Hashcash: 1:22:150924:tls@ietf.org::iEVc5xOz7cFNUBvB:WIGj Date: Thu, 24 Sep 2015 13:04:28 +0200 In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BAE1499A2@WSMSG3153V.srv.dir.telstra.com> (James Manger's message of "Thu, 24 Sep 2015 13:23:45 +1000") Message-ID: <87zj0coz7n.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "pkix@ietf.org" , "tls@ietf.org" Subject: Re: [pkix] Updated EdDSA/Ed25519 PKIX document X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 11:04:45 -0000 --=-=-= Content-Type: text/plain "Manger, James" writes: > Hi Simon, two technical typos: > > The example cert in 8.2 has the wrong OID for the signature. > Cert has { 1 3 101 100 1 } [encoding 06 04 2B656401] > Text has { 1 3 101 101 } [encoding 06 03 2B6565] for id-EdDSASignature Hi James. Good catch -- I believe that is a typo in the implementation. I'll let Nikos fix that, but we'll update the examples in the document. > OIDs use space-separated (not dot-separated) numbers in ASN.1. > Section 4: > Wrong { 1.3.101.100 } > Right { 1 3 101 100 } > Section 7 > Wrong { 1.3.101.101 } > Right { 1 3 101 101 } Fixed, thank you. > The cert's notBefore field is a UTCTime value (2-digit year), while > the notAfter field is a GeneralizedTime value (4-digit year). I don't > think I has seen that before, but it is valid. I suspect the logic in GnuTLS to pick one encoding over the other looks at the date to see if it fits in a UTCTime value or not. It shouldn't be related to EdDSA. /Simon > -- > James Manger > > > -----Original Message----- > From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Simon Josefsson > Sent: Wednesday, 23 September 2015 6:33 PM > To: pkix@ietf.org; tls@ietf.org > Subject: [pkix] Updated EdDSA/Ed25519 PKIX document > > Hi all, > > I have pushed out a new version of the document describing EdDSA public keys, signatures and certificates for PKIX. The change in -03 include the addition of the prehash mode, test vectors generated by GnuTLS, and a section recommending certain human readable names. > > https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-03 > > I've started a thread to discuss whether it is wortwhile to be able to use the same Ed25519 key for both PureEdDSA mode and HashEdDSA signing, and I'd appreciate feedback on whether people are interested in this and generally if it is a good idea or not. The complexity involved make me shy away a bit from it, but it is fun to consider. The thread is here: > https://moderncrypto.org/mail-archive/curves/2015/000630.html > > /Simon > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWA9i8AAoJEIYLf7sy+BGd93UH/2rA+/WX8ypXBomLceg6tUIb HtFu6zvSGSKq+jTsvSTe/nSxek1W6/vSxp0auM5hss96dxae1RREhUM/ddUD6AWJ 4YbLFxVD0WLztFWAlMEjty7pApxWZH1rAVjw79y75LuVGP10wN9iJ2bdgtUvQKC3 QkonDbbOkocR84XxKSvaZDYW2U41vWnwYIeeHlXuaLAW8tnTwnmiUCKtbrkloe93 GbSwaTcydHKKLS8x4Z8n29kCpcWVljc20LaI6qx07LqzMktXCqzsY6/AaE/kq21j d2PnAVUYXmCesQEcBmEm3bC2njcLgNX6KNRveMV177LoxbKEBecfqIbz98CFybw= =PR4q -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 24 05:01:26 2015 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E92A1A909C; Thu, 24 Sep 2015 05:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94woLdJqfBBV; Thu, 24 Sep 2015 05:01:18 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C4B1A9084; Thu, 24 Sep 2015 05:01:18 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 681DE461E3; Thu, 24 Sep 2015 12:01:17 +0000 (UTC) Received: from dhcp-10-40-3-77.brq.redhat.com (dhcp-10-40-3-77.brq.redhat.com [10.40.3.77]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8OC1ECs006662 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 24 Sep 2015 08:01:15 -0400 Message-ID: <1443096074.20825.7.camel@redhat.com> From: Nikos Mavrogiannopoulos To: "Manger, James" , Simon Josefsson , "pkix@ietf.org" , "tls@ietf.org" Date: Thu, 24 Sep 2015 14:01:14 +0200 In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BAE1499A2@WSMSG3153V.srv.dir.telstra.com> References: <878u7xtu06.fsf@latte.josefsson.org> <255B9BB34FB7D647A506DC292726F6E13BAE1499A2@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Subject: Re: [pkix] [TLS] Updated EdDSA/Ed25519 PKIX document X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 12:01:24 -0000 On Thu, 2015-09-24 at 13:23 +1000, Manger, James wrote: > The cert's notBefore field is a UTCTime value (2-digit year), while > the notAfter field is a GeneralizedTime value (4-digit year). I don't > think I has seen that before, but it is valid. Hi, Thanks for the comments, they should be addressed in the next update. About the times, that's an RFC5280 requirement. "CAs conforming to this profile MUST always encode certificate validity dates through the year 2049 as UTCTime; certificate validity dates in 2050 or later MUST be encoded as GeneralizedTime." The notAfter is a date over 2050 (in fact its the 'no well defined expiration date'). regards, Nikos From nobody Tue Sep 29 09:39:14 2015 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2FE1A6F3C; Tue, 29 Sep 2015 09:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kh_CbAqSLzK3; Tue, 29 Sep 2015 09:39:09 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC7D1B47B6; Tue, 29 Sep 2015 09:39:08 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 04C04509C4; Tue, 29 Sep 2015 12:39:06 -0400 (EDT) To: pkix@ietf.org, saag@ietf.org References: <20141113051500.12824.67140.idtracker@ietfa.amsl.com> <8FF19ABF-17F7-4A83-ABF9-DF84C93528A8@seantek.com> From: Sean Leonard Message-ID: <560ABE89.3080000@seantek.com> Date: Tue, 29 Sep 2015 09:38:33 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <8FF19ABF-17F7-4A83-ABF9-DF84C93528A8@seantek.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000907060207060409040404" Archived-At: Subject: Re: [pkix] (it updates RFC 2585) New Version Notification for draft-seantek-certfrag-02.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 16:39:10 -0000 This is a cryptographically signed message in MIME format. --------------ms000907060207060409040404 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable By the way: I wanted to point out that this certfrag draft is sliced out of a much=20 larger proposal, which is ways to uniquely and securely identify=20 certificates in text strings (i.e., URIs / URNs) for storage and=20 interchange. This was not just a proposal out of thin air or whatever.=20 To the extent that a certificate is uniquely identified, it is just as=20 useful to identify a specific part of the certificate of interest. The certfrag portion came out of draft-seantek-certspec-03.=20 draft-seantek-certspec-04 refers to this draft (draft-seantek-certfrag). Since draft-seantek-certspec-04, the URN proposal has hit some snags,=20 mainly due to the glacially slow (and occasionally retrograde) progress=20 of the URNBIS WG. Therefore I am pursuing a different line of attack=20 with that one. I am hoping that we can at least see progress on some of=20 these parts. My main fear is becoming that the apps people don't see the = security angles, and vice-versa. Sean On 11/12/2014 9:23 PM, Sean Leonard wrote: > draft-seantek-certfrag-02 has been posted. > > Among other nits, I think that this draft needs to be Standards Track w= ith IETF Consensus because it updates RFC 2585, which is Standards Track,= and application/pkix-cert and application/pkix-crl are in the standards = tree [RFC 6838]. > > (Thanks Sean T.) > > Sean > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-seantek-certfrag-02.txt >> Date: November 12, 2014 at 7:15:00 PM HST > A new version of I-D, draft-seantek-certfrag-02.txt > has been successfully submitted by Sean Leonard and posted to the > IETF repository. > > Name: draft-seantek-certfrag > Revision: 02 > Title: URI Fragment Identifiers for the application/pkix-cert Media Ty= pe > Document date: 2014-11-12 > Group: Individual Submission > Pages: 4 > URL: http://www.ietf.org/internet-drafts/draft-seantek-certf= rag-02.txt > Status: https://datatracker.ietf.org/doc/draft-seantek-certfrag= / > Htmlized: http://tools.ietf.org/html/draft-seantek-certfrag-02 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-seantek-certfr= ag-02 > > Abstract: > This memo describes Uniform Resource Identifier (URI) fragment > identifiers for PKIX certificates, which are identified with the > Internet media type application/pkix-cert. > > > The IETF Secretariat > --------------ms000907060207060409040404 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA5 MjkxNjM4MzNaMC8GCSqGSIb3DQEJBDEiBCCPL2hXKac+zXV2oKmzF+tLxNZ/iDB3kztrb+Gj 07r4LTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQAIvMFikOvmkwUYXiRj 2l8PtgplwrvAcyCwZBrviNV6ADO0AokqvB5pGb/NJzjfUmoFOOFlmnsaUnpaq/VbNY34MwYr qP2+YBzeoLBsjdkr4Chx7V3drILBiCH+POnWFGQ1qvhNx3HBEght2oqSNdjr3rp1AU7bi9HL Vq2o8Ndb4gCcNmljKQptvm7mJjfeVeJRdOHK1JlmMTKvg8tZFEVDSQIR+LPZYVfY3MEycIgF tgLSxvK+C7KxIGwbRktVHe7vq3P2LKBBWuDX8L/3an7NyA/bV0jW4ztmEG51b/srYFvEFJf4 df8Wwk1OV3IWPr2BfRrobBxX+lIzxj10FKbQAAAAAAAA --------------ms000907060207060409040404-- From nobody Wed Sep 30 03:47:15 2015 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3361B59B7 for ; Wed, 30 Sep 2015 03:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2R0ZqYztw1ih for ; Wed, 30 Sep 2015 03:47:13 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BF1C1B59B0 for ; Wed, 30 Sep 2015 03:47:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9A6EBBE2C; Wed, 30 Sep 2015 11:47:11 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgbVECZmyX8e; Wed, 30 Sep 2015 11:47:11 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BF239BDD0; Wed, 30 Sep 2015 11:47:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1443610031; bh=GxMHHsLzZoiCBd3pfaO8Rsz6Pqsqgfn7kCHaCQqG3B0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=yjtNwjPeCskwlOIce9WKp5zxJYREVyLpY+cKdyvW5Kug2A0IY9uK9lRs29EWyW9wM KEeziAXkVfDqG3kzJEeFAn/z5bRDKAOINoXbSwWAAGxQ5AQ4M/J7Pz55r1imNb9MPH N1MemNoAwmcEdkDaK3VjFkt4jLrezZHVSjLPmlJ4= To: PKIX References: <20150803183532.30514.2647.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <560BBDAE.9070606@cs.tcd.ie> Date: Wed, 30 Sep 2015 11:47:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [pkix] FW: New Version Notification for draft-wallace-est-alt-challenge-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 10:47:15 -0000 Folks, Carl and Max have asked me to AD sponsor this draft. Since it seems like it's almost a bug fix, I'll probably go ahead and do that if there are no significant objections here in the next couple of weeks (say by Oct 15). So if you care about EST, please take a look (it's only 8 pages) and say what you think. Thanks, Stephen. On 04/08/15 12:34, Carl Wallace wrote: > The draft referenced below may be of interest to some on this list. It > defines some new OIDs to disambiguate existing EST challengePassword > attribute usage from PKCS #9/legacy usage and defines a new OID to convey > a one-time password as an additional value or alternative to the > tls-unique mechanism defined in EST. > > On 8/3/15, 2:35 PM, "internet-drafts@ietf.org" > wrote: > >> >> A new version of I-D, draft-wallace-est-alt-challenge-00.txt >> has been successfully submitted by Carl Wallace and posted to the >> IETF repository. >> >> Name: draft-wallace-est-alt-challenge >> Revision: 00 >> Title: Alternative Challenge Password Attributes for Enrollment over >> Secure Transport >> Document date: 2015-08-03 >> Group: Individual Submission >> Pages: 9 >> URL: >> https://www.ietf.org/internet-drafts/draft-wallace-est-alt-challenge-00.tx >> t >> Status: >> https://datatracker.ietf.org/doc/draft-wallace-est-alt-challenge/ >> Htmlized: >> https://tools.ietf.org/html/draft-wallace-est-alt-challenge-00 >> >> >> Abstract: >> This document defines a set of new Certificate Signing Request >> attributes for use with the Enrollment over Secure Transport (EST) >> protocol. These attributes provide disambiguation of the existing >> overloaded uses for the PKCS #9 challengePassword attribute. Uses >> include the original certificate revocation password, common >> authentication password uses, and EST defined linking of transport >> security identity. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > > > > From nobody Wed Sep 30 19:16:14 2015 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072411ACEA5 for ; Wed, 30 Sep 2015 19:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDUMj8LORO4O for ; Wed, 30 Sep 2015 19:16:11 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F77B1ACEA4 for ; Wed, 30 Sep 2015 19:16:11 -0700 (PDT) Received: by qkas79 with SMTP id s79so26446124qka.0 for ; Wed, 30 Sep 2015 19:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qCVTFKep3OYj4vgPOEQfIZpD+n4NrmAaTY/k4UATOcM=; b=DyWuufW5rRlp/z8tCXLctEMdVj87ct0TW8NJ3LfdZ/dh00zCuaWjLRHvyOVCogAeas GypKpTc1MbF0YqxW20zSgiccvMSG7NBjsIKrXzNV95UexZw97ypu4UjhDpq+2aadpPUz YjesTWXeoaaBGSOCBZWSVj0ig/lMDtSPrDnTg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=qCVTFKep3OYj4vgPOEQfIZpD+n4NrmAaTY/k4UATOcM=; b=Y+qUs14MwsbyFdILJhx17E6RhOi2Ky4vf+F55OcvurdJtKzJIYPTIGL8lTYHwtTRST PDw/fXlGih2PUBZwAq7eOZA0pEGsMpJwpELrsxTfF6P3e5uMAhhnWQbTHO/8D+dFsb0H jN81iJD7kD64+OAwrfg9ChSYXmZ/6e+O+oBpzNHJipSinan43WhYT2YN1MEZGIPfKRzD Ez3ZoKMli9NQtd6IWOIjKOSi5dk0c5BYztCG0N/PTapNb6/yLK9tGBTrf9wdgR8cim77 ji5d//BYIfTvLOFfb7a0HaUNtZ2iEPnBxO2bn/Pqwt4cDYzBnde4nZVUfvajcLbvcdhd YYWg== X-Gm-Message-State: ALoCoQkNfKfFK3jrzGsZx2ei+is/xesIyE2lCqXzStJm3VoQcxKfY0Avz6pjxpX3/2Vq+DSrEdqj X-Received: by 10.55.209.196 with SMTP id o65mr8683265qkl.98.1443665770383; Wed, 30 Sep 2015 19:16:10 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-126-188.washdc.east.verizon.net. [173.73.126.188]) by smtp.gmail.com with ESMTPSA id 128sm1510588qhe.9.2015.09.30.19.16.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Sep 2015 19:16:09 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <560BBDAE.9070606@cs.tcd.ie> Date: Wed, 30 Sep 2015 22:16:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <82D82A48-424A-4080-9538-84A2375DAA10@sn3rd.com> References: <20150803183532.30514.2647.idtracker@ietfa.amsl.com> <560BBDAE.9070606@cs.tcd.ie> To: IETF PKIX X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [pkix] New Version Notification for draft-wallace-est-alt-challenge-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 02:16:13 -0000 Short to the point - seems like a fine candidate to AD sponsor. Only = one question/comment:=20 Don't you need to say which of the DirectoryString choices you=92ve got = to support. In other words, don=92t you need to include something along = the following lines (similar to what=92s in RFC 2985): These attribute values generated in accordance this document SHOULD use the PrintableString encoding whenever possible. If internationalization issues make this impossible, the UTF8String alternative SHOULD be used. Attribute processing systems MUST be able to recognize and process all string types in DirectoryString values. Note I=92m not suggesting the above is correct just that it=92s similar = to what=92s in RFC 2985. spt On Sep 30, 2015, at 06:47, Stephen Farrell = wrote: >=20 > Folks, >=20 > Carl and Max have asked me to AD sponsor this draft. Since it > seems like it's almost a bug fix, I'll probably go ahead and > do that if there are no significant objections here in the next > couple of weeks (say by Oct 15). >=20 > So if you care about EST, please take a look (it's only 8 pages) > and say what you think. >=20 > Thanks, > Stephen. >=20 > On 04/08/15 12:34, Carl Wallace wrote: >> The draft referenced below may be of interest to some on this list. = It >> defines some new OIDs to disambiguate existing EST challengePassword >> attribute usage from PKCS #9/legacy usage and defines a new OID to = convey >> a one-time password as an additional value or alternative to the >> tls-unique mechanism defined in EST. >>=20 >> On 8/3/15, 2:35 PM, "internet-drafts@ietf.org" = >> wrote: >>=20 >>>=20 >>> A new version of I-D, draft-wallace-est-alt-challenge-00.txt >>> has been successfully submitted by Carl Wallace and posted to the >>> IETF repository. >>>=20 >>> Name: draft-wallace-est-alt-challenge >>> Revision: 00 >>> Title: Alternative Challenge Password Attributes for = Enrollment over >>> Secure Transport >>> Document date: 2015-08-03 >>> Group: Individual Submission >>> Pages: 9 >>> URL: =20 >>> = https://www.ietf.org/internet-drafts/draft-wallace-est-alt-challenge-00.tx= >>> t >>> Status: =20 >>> https://datatracker.ietf.org/doc/draft-wallace-est-alt-challenge/ >>> Htmlized: =20 >>> https://tools.ietf.org/html/draft-wallace-est-alt-challenge-00 >>>=20 >>>=20 >>> Abstract: >>> This document defines a set of new Certificate Signing Request >>> attributes for use with the Enrollment over Secure Transport (EST) >>> protocol. These attributes provide disambiguation of the existing >>> overloaded uses for the PKCS #9 challengePassword attribute. Uses >>> include the original certificate revocation password, common >>> authentication password uses, and EST defined linking of transport >>> security identity. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From nobody Wed Sep 30 20:08:05 2015 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F9B1A0119 for ; Wed, 30 Sep 2015 20:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZhoxigbHR4t for ; Wed, 30 Sep 2015 20:08:02 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F1651A010C for ; Wed, 30 Sep 2015 20:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4000; q=dns/txt; s=iport; t=1443668882; x=1444878482; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=W7JtNH4TPfZugPeLKlTFqEubmXM+ikGZug7K/KoiLnI=; b=GkOu3/RTnBqvQANhJgkq3RBEQuIU3maIdH9KuSyA+aMQws946lUuuur9 ZDM2mubwmGofChKUn3dfz5HNq2anQrbGG8Rds6oim6rzVcPeRvRg4uZJ3 r8wxVE/n0/rCAbUXJHYfEQy8NOd9vHOToaVNphhgXfMISvXxrm1F4d5Fu M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ADAgDlogxW/4wNJK1VCYMnVG0GvWsBDYFxDIV3AoE+OBQBAQEBAQEBgQqEJAEBAQMBAQEBawkCBQsCAQgYGBYnCyUCBA4FiCYIDctjAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4kCgm6EMSkzBxmCf4EUBY0DiHUBhRWHfYFPRoNwlUoBHwEBQoIRHYFUcQGIdIEFAQEB X-IronPort-AV: E=Sophos;i="5.17,615,1437436800"; d="scan'208";a="193213354" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP; 01 Oct 2015 03:08:01 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t913814B026760 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Oct 2015 03:08:01 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 30 Sep 2015 22:08:00 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Wed, 30 Sep 2015 22:08:00 -0500 From: "Max Pritikin (pritikin)" To: Sean Turner Thread-Topic: [pkix] New Version Notification for draft-wallace-est-alt-challenge-00.txt Thread-Index: AQHQ++9VCspeK4dhjkyNzUy+E2WRqZ5WSLQA Date: Thu, 1 Oct 2015 03:08:00 +0000 Message-ID: <2792C6B1-FF3B-4536-BFA4-49FD18DFE11E@cisco.com> References: <20150803183532.30514.2647.idtracker@ietfa.amsl.com> <560BBDAE.9070606@cs.tcd.ie> <82D82A48-424A-4080-9538-84A2375DAA10@sn3rd.com> In-Reply-To: <82D82A48-424A-4080-9538-84A2375DAA10@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.8] Content-Type: text/plain; charset="Windows-1252" Content-ID: <792D8B95EA756743962D75E410A24BFC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IETF PKIX Subject: Re: [pkix] New Version Notification for draft-wallace-est-alt-challenge-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 03:08:04 -0000 > On Sep 30, 2015, at 8:16 PM, Sean Turner wrote: >=20 > Short to the point - seems like a fine candidate to AD sponsor. Only one= question/comment:=20 >=20 > Don't you need to say which of the DirectoryString choices you=92ve got t= o support. In other words, don=92t you need to include something along the= following lines (similar to what=92s in RFC 2985): >=20 > These attribute values generated in accordance this document > SHOULD use the PrintableString encoding whenever possible. > If internationalization issues make this impossible, the UTF8String > alternative SHOULD be used. Attribute processing systems MUST > be able to recognize and process all string types in DirectoryString > values. >=20 > Note I=92m not suggesting the above is correct just that it=92s similar t= o what=92s in RFC 2985. RFC7030 states that "the resulting string is placed in the certification re= quest challenge-password field ([RFC2985], Section 5.4.1)=94 which includes= a copy of this paragraph (with very slight variations).=20 I see no problem either repeating this text or making the reference to RFC2= 985 more explicit. - max >=20 > spt >=20 > On Sep 30, 2015, at 06:47, Stephen Farrell wr= ote: >=20 >>=20 >> Folks, >>=20 >> Carl and Max have asked me to AD sponsor this draft. Since it >> seems like it's almost a bug fix, I'll probably go ahead and >> do that if there are no significant objections here in the next >> couple of weeks (say by Oct 15). >>=20 >> So if you care about EST, please take a look (it's only 8 pages) >> and say what you think. >>=20 >> Thanks, >> Stephen. >>=20 >> On 04/08/15 12:34, Carl Wallace wrote: >>> The draft referenced below may be of interest to some on this list. It >>> defines some new OIDs to disambiguate existing EST challengePassword >>> attribute usage from PKCS #9/legacy usage and defines a new OID to conv= ey >>> a one-time password as an additional value or alternative to the >>> tls-unique mechanism defined in EST. >>>=20 >>> On 8/3/15, 2:35 PM, "internet-drafts@ietf.org" >>> wrote: >>>=20 >>>>=20 >>>> A new version of I-D, draft-wallace-est-alt-challenge-00.txt >>>> has been successfully submitted by Carl Wallace and posted to the >>>> IETF repository. >>>>=20 >>>> Name: draft-wallace-est-alt-challenge >>>> Revision: 00 >>>> Title: Alternative Challenge Password Attributes for Enrollment over >>>> Secure Transport >>>> Document date: 2015-08-03 >>>> Group: Individual Submission >>>> Pages: 9 >>>> URL: =20 >>>> https://www.ietf.org/internet-drafts/draft-wallace-est-alt-challenge-0= 0.tx >>>> t >>>> Status: =20 >>>> https://datatracker.ietf.org/doc/draft-wallace-est-alt-challenge/ >>>> Htmlized: =20 >>>> https://tools.ietf.org/html/draft-wallace-est-alt-challenge-00 >>>>=20 >>>>=20 >>>> Abstract: >>>> This document defines a set of new Certificate Signing Request >>>> attributes for use with the Enrollment over Secure Transport (EST) >>>> protocol. These attributes provide disambiguation of the existing >>>> overloaded uses for the PKCS #9 challengePassword attribute. Uses >>>> include the original certificate revocation password, common >>>> authentication password uses, and EST defined linking of transport >>>> security identity. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>>=20 >>>> The IETF Secretariat >>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix