From kent@bbn.com Thu Feb 2 08:35:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D3121F860B for ; Thu, 2 Feb 2012 08:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.522 X-Spam-Level: X-Spam-Status: No, score=-106.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRj44u6QmKfs for ; Thu, 2 Feb 2012 08:35:46 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D065D21F8609 for ; Thu, 2 Feb 2012 08:35:46 -0800 (PST) Received: from dhcp89-089-190.bbn.com ([128.89.89.190]:49207) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RszdR-0000AO-TW; Thu, 02 Feb 2012 11:35:46 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4F285CED.9000802@telia.com> References: <20120108150622.31042.3072.idtracker@ietfa.amsl.com> <4F1484F4.6020202@telia.com> <4F18A4B6.3060701@telia.com> <07123142-C9D7-493F-8681-548096731043@cisco.com> <8E4D80C3-1BFC-4A3C-977B-9D5D828C3D2A@vigilsec.com> <9BDA4869-A40C-4DDC-997A-D7CE67E8DCF0@cisco.com> <4F23B25F.5010101@telia.com> <4F247871.4080205@lockstep.com.au> <4F24E491.6080106@telia.com> <525748F0-2BC1-4A2A-92EF-9430ECEC5C57@carillon.ca> <4F270E33.7060909@telia.com> <4F285CED.9000802@telia.com> Date: Thu, 2 Feb 2012 11:01:34 -0500 To: Anders Rundgren From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] I-D Action: draft-ietf-pkix-est-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 16:35:47 -0000 Anders, >... >End-to-end of the kind you and I are referring to isn't known by the >the PKIX WG at large and therefore this discussion (early on) went south. > >Anyway, my take on this topic is creating a united solution where >certificate enrollment has morphed into or token management. EST was not approved as a WG item with the understanding that it would focus on token management. That functionality is not on the table. Since your message of 1/28 included the statement: >In fact, this discussion clarifies why PKIX isn't the right forum >for addressing the needs of the mobile connected world where virtual >smart cards will be the norm. let's discontinue this thread and return to comments on EST relative to the functions that is claims to offer. Steve From kent@bbn.com Thu Feb 2 11:28:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F15A21F8613 for ; Thu, 2 Feb 2012 11:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mb-OOKjktmB5 for ; Thu, 2 Feb 2012 11:28:18 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id E3F6B21F860B for ; Thu, 2 Feb 2012 11:28:17 -0800 (PST) Received: from dhcp89-089-190.bbn.com ([128.89.89.190]:49227) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rt2KP-0003ff-A7 for pkix@ietf.org; Thu, 02 Feb 2012 14:28:17 -0500 Mime-Version: 1.0 Message-Id: Date: Thu, 2 Feb 2012 14:24:29 -0500 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] WGLC for draft-ietf-pkix-cmp-transport-protocols-15.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 19:28:18 -0000 I have seen no comments since this WGLC began on 1/10, so I declare it completed. Steve From turners@ieca.com Thu Feb 2 15:54:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB3A21F86B9 for ; Thu, 2 Feb 2012 15:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.852 X-Spam-Level: X-Spam-Status: No, score=-101.852 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28PqC+UODLOJ for ; Thu, 2 Feb 2012 15:54:45 -0800 (PST) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [67.18.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE2B21F86B8 for ; Thu, 2 Feb 2012 15:54:45 -0800 (PST) Received: by gateway11.websitewelcome.com (Postfix, from userid 5011) id BB5B6B65255DF; Thu, 2 Feb 2012 17:54:43 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway11.websitewelcome.com (Postfix) with ESMTP id AC8E1B65255B9 for ; Thu, 2 Feb 2012 17:54:43 -0600 (CST) Received: from [71.191.4.110] (port=38798 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Rt6UF-0001QL-6o for pkix@ietf.org; Thu, 02 Feb 2012 17:54:43 -0600 Message-ID: <4F2B2243.8070309@ieca.com> Date: Thu, 02 Feb 2012 18:54:43 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: pkix@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-71-191-4-110.washdc.east.verizon.net (thunderfish.local) [71.191.4.110]:38798 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [pkix] AD review of draft-ietf-pkix-cmp-transport-protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 23:54:47 -0000 I've reviewed draft-ietf-pkix-cmp-transport-protocols and have the following comments I'd like to see addressed prior to IETF LC: 1) s1: r/Certificate Authorities (CAs)/Certification Authorities (CAs) 2) s1: r/an own polling/its own polling 3) s1: remove the following because it sounds like marketing: HTTP transport is generally easy to implement, traverses network borders utilizing ubiquitous proxies and is already commonly found in existing implementations. 4) s3.1/s9: references for RFCs 1945 and 2616 are normative because there is 2119 language associated with them in s3.1. Also: - I think what you're trying say is that either protocol can be used by clients so I think you need to be specific about that and a MUST is needed (saying MAY for both seems odd to me). - But, I've been told that HTTP 1.1 is more widely implemented so can we make it the preferred version and then make 1.0 a MAY? OLD: Either HTTP/1.0 as described in [RFC1945] or HTTP/1.1 as in [RFC2616] MAY be used. Server implementations SHOULD be able to interact with counterparts utilizing either HTTP protocol version. NEW: Clients and servers MUST support HTTP/1.1 [RFC2616]. Clients and server MAY also support HTTP/1.0 [RFC1945]. 5) s3.2: Not sure I can parse the following: HTTP permits to reuse a connection for subsequent requests. Implementations may use this functionality for messages within the same transaction but MUST NOT rely on that as e.g. intermediate HTTP proxies might terminate the connection after each request/response pair. did you mean to say: ... MUST NOT rely on this because intermediate HTTP proxies might terminate the connection after each request/response pair. 6) s3.3: Not sure the DER-encoded part is necessary isn't that already covered in CMP: ? OLD: An ASN.1 DER-encoded PKIMessage NEW: A PKIMessage 7) s3.3: I think response is better than reply: OLD: the server returns the CMP reply NEW: the server returns the CMP response 8) s3.3: I think you need to be clear that you're talking about the HTTP status codes because there are also CMP status codes: OLD: The response status NEW: The HTTP response status 9) s3.3: Please be specific about the announcement types: OLD: HTTP responses to pushed CMP Announcement messages utilize the status codes 201 and 202 to identify whether the received information was processed. NEW: HTTP responses to pushed CMP Announcement messages (i.e., CA Certificate Announcement, Certificate Announcement, Revocation Announcement, and CRL Announcement) utilize the status codes 201 and 202 to identify whether the received information was processed. 10) s3.3: Do you need to say anything about redirection? Like is it allowed or should the client not follow them? I note there's some text in the security considerations but it might be worth also adding in this section. 11) s3.4/s9: RFC 2510 is a normative reference because that's where application/pkixcmp is defined. This is going to force a downref because RFC 2510 is obsoleted - not a big deal but something I need to remember when I do the IETF LC (hint if you don't see it in the LC make sure to tell me so I can fix it). 12) s3.6: r/pop/POP 13) s3.6: Are you saying that the request is directed to something like POST cmp/0 or POST http://example.com/cmp/0 HTTP/1.1 for initialization requests (i.e., the ASN.1 tag indicates the directory)? 14) s3.7: r/No request message for is specified,/No request message is specified, 15) s3.7: r/ASN.1 encoded structures/PKIMessage structures 16) s6: Why isn't this part of s5? Are you trying to say that there's no confidential information included in a PKIMessage and if there you ought to use HTTPS? spt PS Based on these comments I've placed the document in the following state: AD Evaluation::Revised ID Needed. From mrex@sap.com Thu Feb 2 16:19:29 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C2B21F8688 for ; Thu, 2 Feb 2012 16:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.124 X-Spam-Level: X-Spam-Status: No, score=-10.124 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyomtRRYgAdh for ; Thu, 2 Feb 2012 16:19:29 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id B595121F8681 for ; Thu, 2 Feb 2012 16:19:28 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q130JPBh007775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Feb 2012 01:19:25 +0100 (MET) From: Martin Rex Message-Id: <201202030019.q130JPW2019942@fs4113.wdf.sap.corp> To: turners@ieca.com (Sean Turner) Date: Fri, 3 Feb 2012 01:19:25 +0100 (MET) In-Reply-To: <4F2B2243.8070309@ieca.com> from "Sean Turner" at Feb 2, 12 06:54:43 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] AD review of draft-ietf-pkix-cmp-transport-protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 00:19:29 -0000 Sean Turner wrote: > > - But, I've been told that HTTP 1.1 is more widely implemented so can we > make it the preferred version and then make 1.0 a MAY? > > OLD: > > Either HTTP/1.0 as described in [RFC1945] or HTTP/1.1 as in [RFC2616] > MAY be used. Server implementations SHOULD be able to interact with > counterparts utilizing either HTTP protocol version. > > NEW: > > Clients and servers MUST support HTTP/1.1 [RFC2616]. Clients and > server MAY also support HTTP/1.0 [RFC1945]. Unless the protocol is vitally dependent on features that exist only in HTTP/1.1 (which the original text suggests is not the case), a "MUST support HTTP/1.1" is in clear violation of rfc2119 Section 6 http://tools.ietf.org/html/rfc2119#section-6 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For *> example, they must not be used to try to impose a particular method *> on implementors where the method is not required for *> interoperability. -Martin From anders.rundgren@telia.com Thu Feb 2 22:45:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7653521F84C4 for ; Thu, 2 Feb 2012 22:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.061 X-Spam-Level: X-Spam-Status: No, score=-3.061 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJ7IruRKB9pR for ; Thu, 2 Feb 2012 22:45:17 -0800 (PST) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 1C69321F84C2 for ; Thu, 2 Feb 2012 22:45:16 -0800 (PST) Received: from [192.168.0.200] (81.232.141.73) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4EFC3D3500CE78B8; Fri, 3 Feb 2012 07:45:09 +0100 Message-ID: <4F2B8273.2060200@telia.com> Date: Fri, 03 Feb 2012 07:45:07 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Stephen Kent References: <20120108150622.31042.3072.idtracker@ietfa.amsl.com> <4F1484F4.6020202@telia.com> <4F18A4B6.3060701@telia.com> <07123142-C9D7-493F-8681-548096731043@cisco.com> <8E4D80C3-1BFC-4A3C-977B-9D5D828C3D2A@vigilsec.com> <9BDA4869-A40C-4DDC-997A-D7CE67E8DCF0@cisco.com> <4F23B25F.5010101@telia.com> <4F247871.4080205@lockstep.com.au> <4F24E491.6080106@telia.com> <525748F0-2BC1-4A2A-92EF-9430ECEC5C57@carillon.ca> <4F270E33.7060909@telia.com> <4F285CED.9000802@telia.com> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] I-D Action: draft-ietf-pkix-est-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 06:45:18 -0000 On 2012-02-02 17:01, Stephen Kent wrote: > Anders, > >> ... >> End-to-end of the kind you and I are referring to isn't known by the >> the PKIX WG at large and therefore this discussion (early on) went south. >> >> Anyway, my take on this topic is creating a united solution where >> certificate enrollment has morphed into or token management. > > EST was not approved as a WG item with the understanding that it would > focus on token management. That functionality is not on the table. > > Since your message of 1/28 included the statement: > >> In fact, this discussion clarifies why PKIX isn't the right forum >> for addressing the needs of the mobile connected world where virtual >> smart cards will be the norm. > > let's discontinue this thread and return to comments on EST relative to > the functions that is claims to offer. Sure we can drop this thread. I was just a bit more interested in hearing what possible "markets" and "use-cases" that PKIX had in mind. The KEYPROV WG which several PKIXers participated in took 3.5 years completing as a standard, and then nobody cared :-( Anders > > Steve > > From turners@ieca.com Fri Feb 3 05:42:08 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A239D21F8681 for ; Fri, 3 Feb 2012 05:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.259 X-Spam-Level: X-Spam-Status: No, score=-102.259 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBSV5bO16yc5 for ; Fri, 3 Feb 2012 05:42:07 -0800 (PST) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [70.85.130.5]) by ietfa.amsl.com (Postfix) with ESMTP id B532F21F8677 for ; Fri, 3 Feb 2012 05:42:07 -0800 (PST) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 842D2A72A3F23; Fri, 3 Feb 2012 07:42:06 -0600 (CST) Received: from ham03.websitewelcome.com (ham.websitewelcome.com [173.192.100.229]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 6E3F3A72A3EBF for ; Fri, 3 Feb 2012 07:42:06 -0600 (CST) Received: by ham03.websitewelcome.com (Postfix, from userid 666) id 5FFE8ACF92AC; Fri, 3 Feb 2012 07:42:06 -0600 (CST) X-Spam-Flag2999: NO X-Spam-Level2999: X-Spam-Status2999: "No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=ham version=3.3.1 Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by ham03.websitewelcome.com (Postfix) with ESMTP id 17EB2ACF9220 for ; Fri, 3 Feb 2012 07:42:06 -0600 (CST) Received: from [96.231.119.150] (port=46646 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RtJOv-00084k-Qj; Fri, 03 Feb 2012 07:42:06 -0600 Message-ID: <4F2BE42E.1000508@ieca.com> Date: Fri, 03 Feb 2012 08:42:06 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: mrex@sap.com References: <201202030019.q130JPW2019942@fs4113.wdf.sap.corp> In-Reply-To: <201202030019.q130JPW2019942@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-96-231-119-150.washdc.east.verizon.net (thunderfish.local) [96.231.119.150]:46646 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 162 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: pkix@ietf.org Subject: Re: [pkix] AD review of draft-ietf-pkix-cmp-transport-protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 13:42:08 -0000 On 2/2/12 7:19 PM, Martin Rex wrote: > Sean Turner wrote: >> >> - But, I've been told that HTTP 1.1 is more widely implemented so can we >> make it the preferred version and then make 1.0 a MAY? >> >> OLD: >> >> Either HTTP/1.0 as described in [RFC1945] or HTTP/1.1 as in [RFC2616] >> MAY be used. Server implementations SHOULD be able to interact with >> counterparts utilizing either HTTP protocol version. >> >> NEW: >> >> Clients and servers MUST support HTTP/1.1 [RFC2616]. Clients and >> server MAY also support HTTP/1.0 [RFC1945]. > > > Unless the protocol is vitally dependent on features that exist only > in HTTP/1.1 (which the original text suggests is not the case), > a "MUST support HTTP/1.1" is in clear violation of rfc2119 Section 6 > > > http://tools.ietf.org/html/rfc2119#section-6 > > 6. Guidance in the use of these Imperatives > > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > *> example, they must not be used to try to impose a particular method > *> on implementors where the method is not required for > *> interoperability. I was shooting for less to implement. Regardless, I think the first sentence needs to be explicit about the client requirements so I could live with the following: Clients MUST support either HTTP/1.0 [RFC1945] or HTTP/1.1 [RFC2616]. Servers SHOULD support both HTTP versions. spt From wwwrun@rfc-editor.org Mon Feb 6 05:54:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477BB21F8497 for ; Mon, 6 Feb 2012 05:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ksnYcEiFJZG for ; Mon, 6 Feb 2012 05:54:39 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 22A6921F8495 for ; Mon, 6 Feb 2012 05:54:35 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 2C12462176; Mon, 6 Feb 2012 05:50:22 -0800 (PST) To: stefans@microsoft.com, wpolk@nist.gov, magnus@rsasecurity.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20120206135022.2C12462176@rfc-editor.org> Date: Mon, 6 Feb 2012 05:50:22 -0800 (PST) X-Mailman-Approved-At: Mon, 06 Feb 2012 07:16:20 -0800 Cc: pkix@ietf.org, rfc-editor@rfc-editor.org, loic.etienne@tech.swisssign.com Subject: [pkix] [Technical Errata Reported] RFC3739 (3108) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 13:54:44 -0000 The following errata report has been submitted for RFC3739, "Internet X.509 Public Key Infrastructure: Qualified Certificates Profile". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3739&eid=3108 -------------------------------------- Type: Technical Reported by: Loïc Etienne Section: C.1.1.1. Original Text ------------- GeneralizedTime : "197110141200Z" Corrected Text -------------- GeneralizedTime : "19711014120000Z" Notes ----- X.690 11 Restrictions on BER employed by both CER and DER 11.7 GeneralizedTime 11.7.2 The seconds element shall always be present. In rfc 3739, C.3 DER-encoding, the second-zeroes are present: ... ..313937 31313031 34313230 3030305A ... They are just missing in the string representation above. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3739 (draft-ietf-pkix-sonof3039-06) -------------------------------------- Title : Internet X.509 Public Key Infrastructure: Qualified Certificates Profile Publication Date : March 2004 Author(s) : S. Santesson, M. Nystrom, T. Polk Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From kent@bbn.com Mon Feb 6 09:52:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A885121F8699 for ; Mon, 6 Feb 2012 09:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.137 X-Spam-Level: X-Spam-Status: No, score=-106.137 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xz8K95ejz46T for ; Mon, 6 Feb 2012 09:52:57 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBBF21F8693 for ; Mon, 6 Feb 2012 09:52:57 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:41141 helo=[10.120.130.185]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RuSkI-000Jnq-P2; Mon, 06 Feb 2012 12:52:54 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20120103200025.6720.30648.idtracker@ietfa.amsl.com> <48EA5D1A-410E-471A-9B39-B282ADF78763@vigilsec.com> Date: Mon, 6 Feb 2012 12:22:38 -0500 To: denis.pinkas@bull.net From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: IETF PKIX Subject: Re: [pkix] I-D Action: draft-ietf-pkix-cmc-serverkeygeneration-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 17:52:57 -0000 At 9:22 AM +0100 1/18/12, denis.pinkas@bull.net wrote: >Steve, > >In this case, POP does not counter a threat. Saying in the security >considerations section it is important and necessary >does not make sense. It is certainly possible add controls which are >not necessary. > >If you really want to maintain for whatever reason (already existing >implementation ?), then it, it should clearly be an option >that any compliant implementation is NOT mandated to implement. > >Denis Denis, Sorry to be so slow to reply. In the CMC keygen context, there is a major benefit for the central keygen facility to have an app-level confirmation that the private key has been delivered successfully. I agree that this is a different motivation than we envisioned for PoP originally, but it is still relevant and useful. Steve From hallam@gmail.com Mon Feb 6 11:16:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B1F21F86C5 for ; Mon, 6 Feb 2012 11:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vq4jpj7D-16f for ; Mon, 6 Feb 2012 11:16:36 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 44CC421F869A for ; Mon, 6 Feb 2012 11:16:36 -0800 (PST) Received: by obbwd15 with SMTP id wd15so8739935obb.31 for ; Mon, 06 Feb 2012 11:16:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=ghCQ72yiwn2FP5L0kTX/r46KDrnMyAmx2akQpwudwQY=; b=lvifZPKYJrzdl9NzTLrMoTI3rgeMTqMwBlondLI477/bFT6WQJShFzq6JQNCHxTcc2 CtKppwrvXsgfPy2rJ+en0/f+RdxL/r1WAHr7tL0Utq/r87rXBN7Z/+0KuxsICJcdrLUm cK5Xo3C7XQeflVY2voELEloQ9DposoOmIqXl0= MIME-Version: 1.0 Received: by 10.182.41.5 with SMTP id b5mr17846911obl.79.1328555795954; Mon, 06 Feb 2012 11:16:35 -0800 (PST) Received: by 10.182.42.227 with HTTP; Mon, 6 Feb 2012 11:16:35 -0800 (PST) Date: Mon, 6 Feb 2012 14:16:35 -0500 Message-ID: From: Phillip Hallam-Baker To: pkix@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 19:16:37 -0000 Discussions on the utility of various revocation mechanisms in another place arrived at the following problem identified in OCSP: While OCSP stapling is good for performance, it does nothing to address the problems that cause current browsers to (mostly) avoid hard-fail when a valid OCSP token is not returned since the client has no way to know if a TLS connection should have delivered the stapled cert or not. Proposal: Introduce a certificate extension that says 'valid OCSP token must be stapled when used with TLS'. Mechanism: If a browser supporting the extension sees a certificate presented in a TLS session it ignores any OCSP distribution point published in the cert and will only accept the cert if supported by a valid OCSP token using the TLS stapling mechanism. The extension SHOULD NOT be marked critical, legacy browsers will be unaffected and fail in the ordinary way. The extension would normally be generated in response to the extension being published in a CSR. A CSR generating app should only insert the extension if the server is configured to use OCSP stapling. A server should provide an operator warning if use of a certificate with the extension is attempted without stapling being enabled or alternatively turn on stapling automatically. -- Website: http://hallambaker.com/ From ryan.hurst@globalsign.com Mon Feb 6 11:42:12 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9620E21F8734 for ; Mon, 6 Feb 2012 11:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kX-y-t-X7tD1 for ; Mon, 6 Feb 2012 11:42:11 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C117B21F8733 for ; Mon, 6 Feb 2012 11:42:11 -0800 (PST) Received: by ggnq2 with SMTP id q2so3529504ggn.31 for ; Mon, 06 Feb 2012 11:42:11 -0800 (PST) Received: by 10.50.217.129 with SMTP id oy1mr27480715igc.4.1328557331205; Mon, 06 Feb 2012 11:42:11 -0800 (PST) Received: from [192.168.255.68] (74-92-226-109-Washington.hfc.comcastbusiness.net. [74.92.226.109]) by mx.google.com with ESMTPS id us2sm2271279igb.7.2012.02.06.11.42.07 (version=SSLv3 cipher=OTHER); Mon, 06 Feb 2012 11:42:09 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Mon, 06 Feb 2012 11:42:44 -0800 From: Ryan Hurst To: Phillip Hallam-Baker , Message-ID: Thread-Topic: [pkix] Certificate flag for 'always stapled' In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 19:42:12 -0000 Phillip, While I think its unfortunate such an extension needs to exist (inclusion of revocation pointers should be all that is necessary for an issuer to make that statement) I acknowledge that it is needed given where we are. I for one am supporting of an extension with the semantics you suggest, that said I think it might make more sense to make it generic, e.g. Not specific to OCSP and stapling but generic for revocation checking (OCSP with or without stapling or CRLs). Ryan On 2/6/12 11:16 AM, "Phillip Hallam-Baker" wrote: >Discussions on the utility of various revocation mechanisms in another >place arrived at the following problem identified in OCSP: While OCSP >stapling is good for performance, it does nothing to address the >problems that cause current browsers to (mostly) avoid hard-fail when >a valid OCSP token is not returned since the client has no way to know >if a TLS connection should have delivered the stapled cert or not. > >Proposal: Introduce a certificate extension that says 'valid OCSP >token must be stapled when used with TLS'. > > >Mechanism: > >If a browser supporting the extension sees a certificate presented in >a TLS session it ignores any OCSP distribution point published in the >cert and will only accept the cert if supported by a valid OCSP token >using the TLS stapling mechanism. > >The extension SHOULD NOT be marked critical, legacy browsers will be >unaffected and fail in the ordinary way. > > >The extension would normally be generated in response to the extension >being published in a CSR. A CSR generating app should only insert the >extension if the server is configured to use OCSP stapling. A server >should provide an operator warning if use of a certificate with the >extension is attempted without stapling being enabled or alternatively >turn on stapling automatically. > > >-- >Website: http://hallambaker.com/ >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From housley@vigilsec.com Mon Feb 6 15:36:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917E121F85FD for ; Mon, 6 Feb 2012 15:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEr6mCpXGyIK for ; Mon, 6 Feb 2012 15:36:31 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 15C2921F85EF for ; Mon, 6 Feb 2012 15:36:31 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 62191F240B3; Mon, 6 Feb 2012 18:36:39 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id IW+O9kTjGal2; Mon, 6 Feb 2012 18:36:24 -0500 (EST) Received: from dhcp-222-246.meetings.nanog.org (dhcp-222-246.meetings.nanog.org [199.187.222.246]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id B4C81F240B0; Mon, 6 Feb 2012 18:36:38 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Mon, 6 Feb 2012 18:36:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <92919CEB-C81F-470A-B59C-74C17610C9D8@vigilsec.com> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 23:36:31 -0000 Phill: > Proposal: Introduce a certificate extension that says 'valid OCSP > token must be stapled when used with TLS'. You really just want the check made by the relying party before making = use of the certificate. Why do you care who makes the request to the = OCSP responder? Russ= From mrex@sap.com Mon Feb 6 16:52:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8034411E80CB for ; Mon, 6 Feb 2012 16:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.826 X-Spam-Level: X-Spam-Status: No, score=-9.826 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyhaBzEN6HqE for ; Mon, 6 Feb 2012 16:52:15 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id D09BE11E80B3 for ; Mon, 6 Feb 2012 16:52:12 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q170qAej021363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Feb 2012 01:52:10 +0100 (MET) From: Martin Rex Message-Id: <201202070052.q170q99L024465@fs4113.wdf.sap.corp> To: housley@vigilsec.com (Russ Housley) Date: Tue, 7 Feb 2012 01:52:09 +0100 (MET) In-Reply-To: <92919CEB-C81F-470A-B59C-74C17610C9D8@vigilsec.com> from "Russ Housley" at Feb 6, 12 06:36:27 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 00:52:15 -0000 Russ Housley wrote: > > Phill: > > > Proposal: Introduce a certificate extension that says 'valid OCSP > > token must be stapled when used with TLS'. > > You really just want the check made by the relying party before > making use of the certificate. Why do you care who makes the request > to the OCSP responder? I assume Phillip wants a means for a server (admin) to request a "hard fail" from clients when not obtaining (stapled) OCSP responses. Clients may not want to perform OCSP requests for arbitrary server certs, like for privacy reasons, and more importantly, clients may _not_ want to perform a hard fail in case that they do attempt OCSP for a server certificate but fail at the network layer doing that request. A client that supports the TLS extension for OCSP response stapling will reliably be able to obtain OCSP responses from a server that supports&uses that TLS extension, completely independent of the client's network connectivity to other places. -Martin From stephen.farrell@cs.tcd.ie Mon Feb 6 16:58:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C1421F8642 for ; Mon, 6 Feb 2012 16:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQ6Gzy2HNcKn for ; Mon, 6 Feb 2012 16:58:03 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 17D1B21F862D for ; Mon, 6 Feb 2012 16:58:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 17311153C18; Tue, 7 Feb 2012 00:58:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1328576281; bh=RzIeKDaLPciw9k KQJDn8OZ3H9l++d4ABU9s8BOvH83M=; b=BmhoapBIOf0JvMCcoCo6dPUexZhCN+ dwC3HRdFmZjJMzG8h1Gt/P+C7+KK+5Qw+LZ8dE3gNnypJaehQjJrLVAMCic+c89A lpIKi3YFDAgd/OVQqWyiQeq/N3f+E0DY7KbiP5jzYG7Q4mElGyan8H1Y2Uh+HU+F B2ENSJ7/Jy/sF+mdEZXVB4quHOqaQH0wdLvOAqUo42tM4d/4JXJTvYHw6rqejiTB iN/OmLI/Pu9TToYcele4+hftiWvO+bIH7WgHoHQs9aRc7T2hCFRmFtZtskN82ybp wpd8zM3b785NKwsqehZZfmMO3Vzej7jfdgRU4W+cJH9TOllZurqwBfvA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id iCBpyhBLR3X3; Tue, 7 Feb 2012 00:58:01 +0000 (GMT) Received: from [10.87.48.9] (unknown [86.41.7.174]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 99BFC153C17; Tue, 7 Feb 2012 00:58:01 +0000 (GMT) Message-ID: <4F307719.9080905@cs.tcd.ie> Date: Tue, 07 Feb 2012 00:58:01 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 00:58:04 -0000 I'm not necessarily disagreeing with doing this, but... Isn't this getting very close to a short-lived cert? Presumably an RP would hard-fail with that with no code or config changes and it'd be simpler all 'round with no need for new RFCs or code even on the TLS server or CA. (Well, maybe some business logic or billing code would need to change.) So, I guess it'd be good to be clear why this is better than just short-lived certs, but I'm not at all sure I know of a good answer for that question. S On 02/06/2012 07:16 PM, Phillip Hallam-Baker wrote: > Discussions on the utility of various revocation mechanisms in another > place arrived at the following problem identified in OCSP: While OCSP > stapling is good for performance, it does nothing to address the > problems that cause current browsers to (mostly) avoid hard-fail when > a valid OCSP token is not returned since the client has no way to know > if a TLS connection should have delivered the stapled cert or not. > > Proposal: Introduce a certificate extension that says 'valid OCSP > token must be stapled when used with TLS'. > > > Mechanism: > > If a browser supporting the extension sees a certificate presented in > a TLS session it ignores any OCSP distribution point published in the > cert and will only accept the cert if supported by a valid OCSP token > using the TLS stapling mechanism. > > The extension SHOULD NOT be marked critical, legacy browsers will be > unaffected and fail in the ordinary way. > > > The extension would normally be generated in response to the extension > being published in a CSR. A CSR generating app should only insert the > extension if the server is configured to use OCSP stapling. A server > should provide an operator warning if use of a certificate with the > extension is attempted without stapling being enabled or alternatively > turn on stapling automatically. > > From mrex@sap.com Mon Feb 6 17:45:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B543B11E80B5 for ; Mon, 6 Feb 2012 17:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.823 X-Spam-Level: X-Spam-Status: No, score=-9.823 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVZG0eBhB7SX for ; Mon, 6 Feb 2012 17:45:33 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E27E211E80AF for ; Mon, 6 Feb 2012 17:45:32 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q171jTwE025880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Feb 2012 02:45:29 +0100 (MET) From: Martin Rex Message-Id: <201202070145.q171jTZW027707@fs4113.wdf.sap.corp> To: stephen.farrell@cs.tcd.ie (Stephen Farrell) Date: Tue, 7 Feb 2012 02:45:29 +0100 (MET) In-Reply-To: <4F307719.9080905@cs.tcd.ie> from "Stephen Farrell" at Feb 7, 12 00:58:01 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 01:45:34 -0000 Stephen Farrell wrote: > > Isn't this getting very close to a short-lived cert? Short-lived TLS server certs is an entirely different can'o'worms and I believe short-lived X.509 certs are a very bad idea. There currently is no workable scheme for key continuity management in X.509, so short lived certs break certificate pinning pretty badly. Many servers will need a full restart to switch their certificate (loss of service) and a failure in the complex X.509 certificate management process will take out the entire server, so it is effectively time-bombing your own server and requiring someone to constantly watch and reset the timer before the cert expires. No thank you. > > Presumably an RP would hard-fail with that with no code or > config changes PHB was proposing a new non-critical certificate extension. Such a change will not affect any moderately reasonable RP at all. If an RP adopts the code for supporting this extension (and such support will require the client to offer the TLS extension and parse the servers stapled OCSP responses from ExtendedServerHello, then it will simple work without requiring any configuration nor any additional network connectivity. > > and it'd be simpler all 'round with no need for new RFCs or code > even on the TLS server or CA. (Well, maybe some business logic > or billing code would need to change.) If you believe in OCSP _at_all_ for online authentication, then the only sensible approach outside of a small closed group without privacy concerns is for each communication peer to convey the OCSP responses for his own certificates in-band with the communication protocol. > > So, I guess it'd be good to be clear why this is better than > just short-lived certs, but I'm not at all sure I know of a > good answer for that question. The only real-world scenarion in PKIX where short-lived certs are supported in a sensible fashion is OCSP signing, when the OCSP response includes the short-lived OCSP responder cert. The same thing already does not work for CRLs, because of the lack of a standized CRL extension to include a short-lived CRL signer cert. And for other scenarios, any kind of short-lived credential that is issued by a completely seperate organizational entity is IMHO screaming for trouble. -Martin From ryan.hurst@globalsign.com Mon Feb 6 18:27:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D9D21F872B for ; Mon, 6 Feb 2012 18:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Apbzit80WDxe for ; Mon, 6 Feb 2012 18:27:02 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D839321F871C for ; Mon, 6 Feb 2012 18:27:02 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so2629101pbc.31 for ; Mon, 06 Feb 2012 18:26:58 -0800 (PST) Received: by 10.68.223.199 with SMTP id qw7mr53155555pbc.79.1328581618388; Mon, 06 Feb 2012 18:26:58 -0800 (PST) Received: from rmhlaptop ([50.46.232.231]) by mx.google.com with ESMTPS id d1sm26052471pbg.13.2012.02.06.18.26.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Feb 2012 18:26:57 -0800 (PST) From: "Ryan Hurst" To: "'Stephen Farrell'" , "'Phillip Hallam-Baker'" References: <4F307719.9080905@cs.tcd.ie> In-Reply-To: <4F307719.9080905@cs.tcd.ie> Date: Mon, 6 Feb 2012 18:26:55 -0800 Message-ID: <0dc301cce53f$f719b820$e54d2860$@globalsign.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKcs09H9CD5Ub3n7bhCZyBJzTC5cQEg4V/+lIgN7CA= Content-Language: en-us Cc: pkix@ietf.org Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 02:27:03 -0000 Short lived certificates are great, I used them successfully in a design for some work I have done in the past. The problem is that most enrollment clients don't reconfigure servers to use the new certificate and most applications don't deal with the certificate change automatically -- the net of which is that without changes to servers and/or enrollment clients this won't work. And while I think application vendors/providers could (and should IMHO) change to deal with these cases better (can you imagine how much time is wasted dealing with this today) the adoption curve for new servers is significantly slower than of browsers, I saw a recent article that suggested that almost 60% of browsers are updated within a year due to the forced update semantics within it. My takeaway is this work would be complimentary to improvements in the enrollment clients/certificate supporting servers and address a near term problem in a practical way. Ryan -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: Monday, February 06, 2012 4:58 PM To: Phillip Hallam-Baker Cc: pkix@ietf.org Subject: Re: [pkix] Certificate flag for 'always stapled' I'm not necessarily disagreeing with doing this, but... Isn't this getting very close to a short-lived cert? Presumably an RP would hard-fail with that with no code or config changes and it'd be simpler all 'round with no need for new RFCs or code even on the TLS server or CA. (Well, maybe some business logic or billing code would need to change.) So, I guess it'd be good to be clear why this is better than just short-lived certs, but I'm not at all sure I know of a good answer for that question. S On 02/06/2012 07:16 PM, Phillip Hallam-Baker wrote: > Discussions on the utility of various revocation mechanisms in another > place arrived at the following problem identified in OCSP: While OCSP > stapling is good for performance, it does nothing to address the > problems that cause current browsers to (mostly) avoid hard-fail when > a valid OCSP token is not returned since the client has no way to know > if a TLS connection should have delivered the stapled cert or not. > > Proposal: Introduce a certificate extension that says 'valid OCSP > token must be stapled when used with TLS'. > > > Mechanism: > > If a browser supporting the extension sees a certificate presented in > a TLS session it ignores any OCSP distribution point published in the > cert and will only accept the cert if supported by a valid OCSP token > using the TLS stapling mechanism. > > The extension SHOULD NOT be marked critical, legacy browsers will be > unaffected and fail in the ordinary way. > > > The extension would normally be generated in response to the extension > being published in a CSR. A CSR generating app should only insert the > extension if the server is configured to use OCSP stapling. A server > should provide an operator warning if use of a certificate with the > extension is attempted without stapling being enabled or alternatively > turn on stapling automatically. > > _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From ryan.hurst@globalsign.com Mon Feb 6 18:40:04 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52EA511E80C2 for ; Mon, 6 Feb 2012 18:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQj6ydJDIWWm for ; Mon, 6 Feb 2012 18:40:03 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B698911E80BE for ; Mon, 6 Feb 2012 18:40:03 -0800 (PST) Received: by dakl33 with SMTP id l33so6186775dak.31 for ; Mon, 06 Feb 2012 18:40:03 -0800 (PST) Received: by 10.68.200.65 with SMTP id jq1mr53894832pbc.54.1328582403548; Mon, 06 Feb 2012 18:40:03 -0800 (PST) Received: from rmhlaptop ([50.46.232.231]) by mx.google.com with ESMTPS id e10sm43103129pbv.0.2012.02.06.18.40.01 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Feb 2012 18:40:03 -0800 (PST) From: "Ryan Hurst" To: , "'Russ Housley'" References: <92919CEB-C81F-470A-B59C-74C17610C9D8@vigilsec.com> from "Russ Housley" at Feb 6, 12 06:36:27 pm <201202070052.q170q99L024465@fs4113.wdf.sap.corp> In-Reply-To: <201202070052.q170q99L024465@fs4113.wdf.sap.corp> Date: Mon, 6 Feb 2012 18:39:58 -0800 Message-ID: <0dc501cce541$cb1b7130$61525390$@globalsign.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL10MVwwpjkZhylzF0y8Z+VM9M60ZPe3wkA Content-Language: en-us Cc: pkix@ietf.org Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 02:40:04 -0000 I believe Phillip is suggesting that a standardized way be established for a certificate issuer to indicate that for a given certificate a successful OCSP response is needed before the relying party trusts it. Not for a server admin to specify, via say a TLS extension; a server operator (or bad guy) would never say "please fail to connect to me", an issuer on the other-hand may have a warranty or other similar rational that would require the client to do such a check. That said its unfortunate such an extension would be required, absence of a revocation indicator should mean no revocation check is necessary (this is one of the presumptions behind short-lived certificates being a means to side-step the need for a revocation check) but the reality is what it is, such an extension would help. Ryan -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Martin Rex Sent: Monday, February 06, 2012 4:52 PM To: Russ Housley Cc: pkix@ietf.org Subject: Re: [pkix] Certificate flag for 'always stapled' Russ Housley wrote: > > Phill: > > > Proposal: Introduce a certificate extension that says 'valid OCSP > > token must be stapled when used with TLS'. > > You really just want the check made by the relying party before making > use of the certificate. Why do you care who makes the request to the > OCSP responder? I assume Phillip wants a means for a server (admin) to request a "hard fail" from clients when not obtaining (stapled) OCSP responses. Clients may not want to perform OCSP requests for arbitrary server certs, like for privacy reasons, and more importantly, clients may _not_ want to perform a hard fail in case that they do attempt OCSP for a server certificate but fail at the network layer doing that request. A client that supports the TLS extension for OCSP response stapling will reliably be able to obtain OCSP responses from a server that supports&uses that TLS extension, completely independent of the client's network connectivity to other places. -Martin _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From hallam@gmail.com Mon Feb 6 19:32:26 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE7411E80C9 for ; Mon, 6 Feb 2012 19:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXi3nTzqk6B5 for ; Mon, 6 Feb 2012 19:32:25 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AEEA911E80B0 for ; Mon, 6 Feb 2012 19:32:25 -0800 (PST) Received: by obbwd15 with SMTP id wd15so9334641obb.31 for ; Mon, 06 Feb 2012 19:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=w4lxffPZ3Vau1CB16AO8k3Wea83QM3TTpIcuGHgQ+wc=; b=SFwh4Y38kk+Pli4/6rU+34xOoFz4vpriUEKB11Rf8oUo3rt0oZ2WQIKz+O4WWy9zxL xRYGS6BWIecfQOErnVx4qXTxgSAmqnbQLQQC3eghPcL0PUnJBDmiwMcCBahOU7FOLbuy MeQGOO8ZFpRY6HTEVLybtENRpfX54sOBjKvZc= MIME-Version: 1.0 Received: by 10.182.47.10 with SMTP id z10mr19300265obm.19.1328585545368; Mon, 06 Feb 2012 19:32:25 -0800 (PST) Received: by 10.182.42.227 with HTTP; Mon, 6 Feb 2012 19:32:25 -0800 (PST) In-Reply-To: <92919CEB-C81F-470A-B59C-74C17610C9D8@vigilsec.com> References: <92919CEB-C81F-470A-B59C-74C17610C9D8@vigilsec.com> Date: Mon, 6 Feb 2012 22:32:25 -0500 Message-ID: From: Phillip Hallam-Baker To: Russ Housley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 03:32:26 -0000 On Mon, Feb 6, 2012 at 6:36 PM, Russ Housley wrote: > Phill: > >> Proposal: Introduce a certificate extension that says 'valid OCSP >> token must be stapled when used with TLS'. > > You really just want the check made by the relying party before making us= e of the certificate. =A0Why do you care who makes the request to the OCSP = responder? > > Russ No, thats not the point. The point is that the server is always going to provide the token stapled so if there is no stapled token there is no need to look elsewhere. The motivation for this is that the Google people are proposing to not look elsewhere if there is no stapled token. At the moment most of the browsers will try to pull the OCSP token but give up if it is not found (soft fail). So the revocation mechanism is effectively nullified. What is needed therefore is not merely the statement 'OCSP is supported', that is what the distribution point says and we have been told 'really check OCSP and hardfail if not found' is not likely to be implemented so it really has to be 'if you did not get the OCSP token in the TLS session then you are being MITM'd and must hardfail'. --=20 Website: http://hallambaker.com/ From hallam@gmail.com Mon Feb 6 19:37:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3CF21F846E for ; Mon, 6 Feb 2012 19:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNrvOvUNwF88 for ; Mon, 6 Feb 2012 19:37:41 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9274A21F847D for ; Mon, 6 Feb 2012 19:37:41 -0800 (PST) Received: by obbwd15 with SMTP id wd15so9341785obb.31 for ; Mon, 06 Feb 2012 19:37:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OKBHCXMhJOPSeim2Lc2+5OGOAdhplztUWED1eoPPGEo=; b=c2fgOqJ0g0pIb26Gy+Ti89blRfEyYaTA6fpGlsWbDbPssuSoFRU6wS5PQ/U9cdVNYl /6AxkkSykIIyWfh7lmmgGdpX9tao8SqX/zUF3G39UHpjJK9LwrYaTr35G4tWLqvdYJu3 Doa3vy9gCllK3rbipZqtWgMJYc2qivxZR+tsM= MIME-Version: 1.0 Received: by 10.182.54.114 with SMTP id i18mr15390380obp.49.1328585861235; Mon, 06 Feb 2012 19:37:41 -0800 (PST) Received: by 10.182.42.227 with HTTP; Mon, 6 Feb 2012 19:37:41 -0800 (PST) In-Reply-To: <4F307719.9080905@cs.tcd.ie> References: <4F307719.9080905@cs.tcd.ie> Date: Mon, 6 Feb 2012 22:37:41 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Cc: pkix@ietf.org Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 03:37:48 -0000 I like the idea of short lived certs, but we really need to have the servers implement a common protocol to ensure that they maintain a fresh cert before it is going to be viable deployment wise. On Mon, Feb 6, 2012 at 7:58 PM, Stephen Farrell wrote: > > I'm not necessarily disagreeing with doing this, but... > > Isn't this getting very close to a short-lived cert? Presumably > an RP would hard-fail with that with no code or config changes > and it'd be simpler all 'round with no need for new RFCs or code > even on the TLS server or CA. (Well, maybe some business logic > or billing code would need to change.) > > So, I guess it'd be good to be clear why this is better than > just short-lived certs, but I'm not at all sure I know of a > good answer for that question. > > S > > > On 02/06/2012 07:16 PM, Phillip Hallam-Baker wrote: >> >> Discussions on the utility of various revocation mechanisms in another >> place arrived at the following problem identified in OCSP: While OCSP >> stapling is good for performance, it does nothing to address the >> problems that cause current browsers to (mostly) avoid hard-fail when >> a valid OCSP token is not returned since the client has no way to know >> if a TLS connection should have delivered the stapled cert or not. >> >> Proposal: Introduce a certificate extension that says 'valid OCSP >> token must be stapled when used with TLS'. >> >> >> Mechanism: >> >> If a browser supporting the extension sees a certificate presented in >> a TLS session it ignores any OCSP distribution point published in the >> cert and will only accept the cert if supported by a valid OCSP token >> using the TLS stapling mechanism. >> >> The extension SHOULD NOT be marked critical, legacy browsers will be >> unaffected and fail in the ordinary way. >> >> >> The extension would normally be generated in response to the extension >> being published in a CSR. A CSR generating app should only insert the >> extension if the server is configured to use OCSP stapling. A server >> should provide an operator warning if use of a certificate with the >> extension is attempted without stapling being enabled or alternatively >> turn on stapling automatically. >> >> > -- Website: http://hallambaker.com/ From tmiller@mitre.org Tue Feb 7 06:43:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAC221F85C4 for ; Tue, 7 Feb 2012 06:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbkOnTrjpGGm for ; Tue, 7 Feb 2012 06:43:25 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5AB21F85C0 for ; Tue, 7 Feb 2012 06:43:25 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8958921B1804; Tue, 7 Feb 2012 09:43:24 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7898C21B12D7; Tue, 7 Feb 2012 09:43:24 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.10]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.01.0339.001; Tue, 7 Feb 2012 09:43:24 -0500 From: "Miller, Timothy J." To: Phillip Hallam-Baker , Russ Housley Thread-Topic: [pkix] Certificate flag for 'always stapled' Thread-Index: AQHM5QPZ4EeRVIkoFEaXkC2Z7S5fAJYw2hSAgABB7YCAAFbggA== Date: Tue, 7 Feb 2012 14:43:23 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.31.4.127] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 14:43:26 -0000 So perhaps a more pointed question is why should this be a PKIX work item? The certificate extensions model is open. Is the extension syntax incomplete in some way? -- T On 2/6/12 9:32 PM, "Phillip Hallam-Baker" wrote: >On Mon, Feb 6, 2012 at 6:36 PM, Russ Housley wrote: >> Phill: >> >>> Proposal: Introduce a certificate extension that says 'valid OCSP >>> token must be stapled when used with TLS'. >> >> You really just want the check made by the relying party before making >>use of the certificate. Why do you care who makes the request to the >>OCSP responder? >> >> Russ > >No, thats not the point. The point is that the server is always going >to provide the token stapled so if there is no stapled token there is >no need to look elsewhere. > >The motivation for this is that the Google people are proposing to not >look elsewhere if there is no stapled token. At the moment most of the >browsers will try to pull the OCSP token but give up if it is not >found (soft fail). So the revocation mechanism is effectively >nullified. > > >What is needed therefore is not merely the statement 'OCSP is >supported', that is what the distribution point says and we have been >told 'really check OCSP and hardfail if not found' is not likely to be >implemented so it really has to be 'if you did not get the OCSP token >in the TLS session then you are being MITM'd and must hardfail'. > > >--=20 >Website: http://hallambaker.com/ >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From rob.stradling@comodo.com Tue Feb 7 06:52:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A954221F8473 for ; Tue, 7 Feb 2012 06:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2yytXPeWpH8 for ; Tue, 7 Feb 2012 06:52:36 -0800 (PST) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9494821F8629 for ; Tue, 7 Feb 2012 06:52:34 -0800 (PST) Received: (qmail 15461 invoked from network); 7 Feb 2012 14:52:33 -0000 Received: from ian.bd.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 7 Feb 2012 14:52:33 -0000 Received: (qmail 17443 invoked by uid 1000); 7 Feb 2012 14:52:32 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Tue, 07 Feb 2012 14:52:32 +0000 Message-ID: <4F313AAF.8070708@comodo.com> Date: Tue, 07 Feb 2012 14:52:31 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Miller, Timothy J." References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 14:52:37 -0000 On 07/02/12 14:43, Miller, Timothy J. wrote: > So perhaps a more pointed question is why should this be a PKIX work item? > The certificate extensions model is open. Is the extension syntax > incomplete in some way? If this is a private certificate extension that isn't going to be widely deployed, then fair enough. But if we want to define an extension that all CAs will (eventually) put into all TLS Server Certificates and which all TLS Clients will (eventually) support, then surely it makes sense to make this a PKIX work item? > -- T > > On 2/6/12 9:32 PM, "Phillip Hallam-Baker" wrote: > >> On Mon, Feb 6, 2012 at 6:36 PM, Russ Housley wrote: >>> Phill: >>> >>>> Proposal: Introduce a certificate extension that says 'valid OCSP >>>> token must be stapled when used with TLS'. >>> >>> You really just want the check made by the relying party before making >>> use of the certificate. Why do you care who makes the request to the >>> OCSP responder? >>> >>> Russ >> >> No, thats not the point. The point is that the server is always going >> to provide the token stapled so if there is no stapled token there is >> no need to look elsewhere. >> >> The motivation for this is that the Google people are proposing to not >> look elsewhere if there is no stapled token. At the moment most of the >> browsers will try to pull the OCSP token but give up if it is not >> found (soft fail). So the revocation mechanism is effectively >> nullified. >> >> >> What is needed therefore is not merely the statement 'OCSP is >> supported', that is what the distribution point says and we have been >> told 'really check OCSP and hardfail if not found' is not likely to be >> implemented so it really has to be 'if you did not get the OCSP token >> in the TLS session then you are being MITM'd and must hardfail'. >> >> >> -- >> Website: http://hallambaker.com/ >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From hallam@gmail.com Tue Feb 7 08:08:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA0B21F8827 for ; Tue, 7 Feb 2012 08:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSU+Ib1x-ilF for ; Tue, 7 Feb 2012 08:08:30 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C52C421F8822 for ; Tue, 7 Feb 2012 08:08:29 -0800 (PST) Received: by qcsg13 with SMTP id g13so296571qcs.31 for ; Tue, 07 Feb 2012 08:08:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=QP8c1/H90BT3iHEeKuU6ahfU57eK8ZqCrVLAxaPF1nc=; b=jvMAAPqRAAHQv4K2bB+KNruuvDBQv/ytTTogRpF06JFdj4grv6bLdYp6SsKvmS0Gf7 KYcdyWp5ZgvBaiXqhxLqtKEFOVhjJwUNJTix+QS7tAvKn1+2eBaSoyvnmYgQ4eXsLN86 Qiwmcz3zqlMIt4QPwLjyjH0kmtbWrKonw1vbM= Received: by 10.229.105.71 with SMTP id s7mr9333482qco.17.1328630909324; Tue, 07 Feb 2012 08:08:29 -0800 (PST) Received: from [10.0.1.22] (c-66-30-5-63.hsd1.ma.comcast.net. [66.30.5.63]) by mx.google.com with ESMTPS id m20sm41645951qaj.14.2012.02.07.08.08.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Feb 2012 08:08:28 -0800 (PST) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9A405) From: Phillip Hallam-Baker Date: Tue, 7 Feb 2012 11:08:23 -0500 To: "Miller, Timothy J." Cc: "pkix@ietf.org" Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:08:31 -0000 Because the idea is that Pkix is a standard and clients, servers, etc. all u= se the same extension code and have a common understanding of the semantics w= hich are written down somewhere. Sent from my iPad On Feb 7, 2012, at 9:43, "Miller, Timothy J." wrote: > So perhaps a more pointed question is why should this be a PKIX work item?= > The certificate extensions model is open. Is the extension syntax > incomplete in some way? >=20 > -- T >=20 > On 2/6/12 9:32 PM, "Phillip Hallam-Baker" wrote: >=20 >> On Mon, Feb 6, 2012 at 6:36 PM, Russ Housley wrote= : >>> Phill: >>>=20 >>>> Proposal: Introduce a certificate extension that says 'valid OCSP >>>> token must be stapled when used with TLS'. >>>=20 >>> You really just want the check made by the relying party before making >>> use of the certificate. Why do you care who makes the request to the >>> OCSP responder? >>>=20 >>> Russ >>=20 >> No, thats not the point. The point is that the server is always going >> to provide the token stapled so if there is no stapled token there is >> no need to look elsewhere. >>=20 >> The motivation for this is that the Google people are proposing to not >> look elsewhere if there is no stapled token. At the moment most of the >> browsers will try to pull the OCSP token but give up if it is not >> found (soft fail). So the revocation mechanism is effectively >> nullified. >>=20 >>=20 >> What is needed therefore is not merely the statement 'OCSP is >> supported', that is what the distribution point says and we have been >> told 'really check OCSP and hardfail if not found' is not likely to be >> implemented so it really has to be 'if you did not get the OCSP token >> in the TLS session then you are being MITM'd and must hardfail'. >>=20 >>=20 >> --=20 >> Website: http://hallambaker.com/ >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >=20 From kent@bbn.com Tue Feb 7 09:06:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3499321F881E for ; Tue, 7 Feb 2012 09:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.172 X-Spam-Level: X-Spam-Status: No, score=-106.172 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7FcAuUFHOry for ; Tue, 7 Feb 2012 09:06:17 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 04C2D21F882F for ; Tue, 7 Feb 2012 09:06:16 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:44809 helo=[10.120.131.43]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RuoUg-0009lT-Be; Tue, 07 Feb 2012 12:06:14 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 7 Feb 2012 11:21:18 -0500 To: "Miller, Timothy J." From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "pkix@ietf.org" Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 17:06:18 -0000 At 2:43 PM +0000 2/7/12, Miller, Timothy J. wrote: >So perhaps a more pointed question is why should this be a PKIX work item? > The certificate extensions model is open. Is the extension syntax >incomplete in some way? > >-- T In general, an extension to a PKIX standard should be pursued in PKIX, if one wants broad support for it in CAs and RPs. Steve From tmiller@mitre.org Tue Feb 7 13:08:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FD411E80BD for ; Tue, 7 Feb 2012 13:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfYE9arsLMGE for ; Tue, 7 Feb 2012 13:08:40 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 66A7711E80A6 for ; Tue, 7 Feb 2012 13:08:40 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C9A8821B13E8; Tue, 7 Feb 2012 16:08:39 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AEA2B21B13C4; Tue, 7 Feb 2012 16:08:39 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.10]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Tue, 7 Feb 2012 16:08:39 -0500 From: "Miller, Timothy J." To: Rob Stradling Thread-Topic: [pkix] Certificate flag for 'always stapled' Thread-Index: AQHM5QPZ4EeRVIkoFEaXkC2Z7S5fAJYw2hSAgABB7YCAAFbggIAAZyWAgAAEfgA= Date: Tue, 7 Feb 2012 21:08:38 +0000 Message-ID: In-Reply-To: <4F313AAF.8070708@comodo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.31.4.44] Content-Type: text/plain; charset="us-ascii" Content-ID: <059B0E473210314BA03F66853D2BEC45@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 21:08:41 -0000 Whether a Subscriber needs a specific OID is a contractual issue between the Subscriber and the CA. Any CA can put any arbitrary OID into Extensions at any time. The software changes are trivial. Non-critical Extensions have no impact on existing implementations[1]. Critical Extensions have defined processing requirements. Actual processing of this Extension value is of interest only to the limited community of browser vendors. In short, PKIX doesn't set requirements for what a TLS certificate profile looks like. TLS WG should do that. -- T [1] Yes, Peter, I know. :) On 2/7/12 8:52 AM, "Rob Stradling" wrote: >On 07/02/12 14:43, Miller, Timothy J. wrote: >> So perhaps a more pointed question is why should this be a PKIX work >>item? >> The certificate extensions model is open. Is the extension syntax >> incomplete in some way? > >If this is a private certificate extension that isn't going to be widely >deployed, then fair enough. > >But if we want to define an extension that all CAs will (eventually) put >into all TLS Server Certificates and which all TLS Clients will >(eventually) support, then surely it makes sense to make this a PKIX >work item? > >> -- T >> >> On 2/6/12 9:32 PM, "Phillip Hallam-Baker" wrote: >> >>> On Mon, Feb 6, 2012 at 6:36 PM, Russ Housley >>>wrote: >>>> Phill: >>>> >>>>> Proposal: Introduce a certificate extension that says 'valid OCSP >>>>> token must be stapled when used with TLS'. >>>> >>>> You really just want the check made by the relying party before making >>>> use of the certificate. Why do you care who makes the request to the >>>> OCSP responder? >>>> >>>> Russ >>> >>> No, thats not the point. The point is that the server is always going >>> to provide the token stapled so if there is no stapled token there is >>> no need to look elsewhere. >>> >>> The motivation for this is that the Google people are proposing to not >>> look elsewhere if there is no stapled token. At the moment most of the >>> browsers will try to pull the OCSP token but give up if it is not >>> found (soft fail). So the revocation mechanism is effectively >>> nullified. >>> >>> >>> What is needed therefore is not merely the statement 'OCSP is >>> supported', that is what the distribution point says and we have been >>> told 'really check OCSP and hardfail if not found' is not likely to be >>> implemented so it really has to be 'if you did not get the OCSP token >>> in the TLS session then you are being MITM'd and must hardfail'. >>> >>> >>> -- >>> Website: http://hallambaker.com/ >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > >--=20 >Rob Stradling >Senior Research & Development Scientist >COMODO - Creating Trust Online >Office Tel: +44.(0)1274.730505 >Office Fax: +44.(0)1274.730909 >www.comodo.com > >COMODO CA Limited, Registered in England No. 04058690 >Registered Office: > 3rd Floor, 26 Office Village, Exchange Quay, > Trafford Road, Salford, Manchester M5 3EQ > >This e-mail and any files transmitted with it are confidential and >intended solely for the use of the individual or entity to whom they are >addressed. If you have received this email in error please notify the >sender by replying to the e-mail containing this attachment. Replies to >this email may be monitored by COMODO for operational or business >reasons. Whilst every endeavour is taken to ensure that e-mails are free >from viruses, no liability can be accepted and the recipient is >requested to use their own virus checking software. From kent@bbn.com Tue Feb 7 15:32:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A0421F87C9 for ; Tue, 7 Feb 2012 15:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.252 X-Spam-Level: X-Spam-Status: No, score=-106.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExD-E6pMREY2 for ; Tue, 7 Feb 2012 15:32:06 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 68A1F21F87C0 for ; Tue, 7 Feb 2012 15:32:06 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:38111 helo=[10.120.131.43]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RuuW4-000H14-Mj; Tue, 07 Feb 2012 18:32:04 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 7 Feb 2012 18:31:59 -0500 To: "Miller, Timothy J." From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "pkix@ietf.org" Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 23:32:07 -0000 At 9:08 PM +0000 2/7/12, Miller, Timothy J. wrote: >Whether a Subscriber needs a specific OID is a contractual issue between >the Subscriber and the CA. Any CA can put any arbitrary OID into >Extensions at any time. The software changes are trivial. Non-critical >Extensions have no impact on existing implementations[1]. Critical >Extensions have defined processing requirements. > >Actual processing of this Extension value is of interest only to the >limited community of browser vendors. > >In short, PKIX doesn't set requirements for what a TLS certificate profile >looks like. TLS WG should do that. > >-- T Tim, I agree that TLS is responsible for cert & CRL profiles for that protocol. But, that does not mean that an extension should be developed there, unless there is agreement that the extension is not of general utility. Steve From mmyers@fastq.com Tue Feb 7 15:59:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AF111E8074 for ; Tue, 7 Feb 2012 15:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJqjNt-YTsIS for ; Tue, 7 Feb 2012 15:59:18 -0800 (PST) Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE0611E8072 for ; Tue, 7 Feb 2012 15:59:18 -0800 (PST) Received: from [192.168.1.105] ([140.99.65.9]) (authenticated bits=0) by mailout.fastq.com (8.13.8/8.13.8-FASTQ.10210800) with ESMTP id q17NxCO6007408 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 7 Feb 2012 16:59:15 -0700 Message-Id: From: Michael Myers To: pkix@ietf.org In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-1-312399156 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 7 Feb 2012 17:03:53 -0700 References: X-Mailer: Apple Mail (2.936) Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 23:59:19 -0000 --Apple-Mail-1-312399156 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > I agree that TLS is responsible for cert & CRL profiles for that > protocol. > But, that does not mean that an extension should be developed there, > unless > there is agreement that the extension is not of general utility. > > Steve The extension could indeed have broader applicability. http://tools.ietf.org/html/rfc4806 Mike --Apple-Mail-1-312399156 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
I agree that TLS is responsible for cert & CRL profiles for that protocol.
But, that does not mean that an extension should be developed there, unless
there is agreement that the extension is not of general utility.

Steve

The extension could indeed have broader applicability.

http://tools.ietf.org/html/rfc4806

Mike

--Apple-Mail-1-312399156-- From chris@randomnonce.org Tue Feb 7 19:41:58 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D8011E809D for ; Tue, 7 Feb 2012 19:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aduCgjVb60e5 for ; Tue, 7 Feb 2012 19:41:58 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD1711E8091 for ; Tue, 7 Feb 2012 19:41:57 -0800 (PST) Received: by obbwd15 with SMTP id wd15so232633obb.31 for ; Tue, 07 Feb 2012 19:41:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.47.41 with SMTP id a9mr23702371obn.43.1328672517533; Tue, 07 Feb 2012 19:41:57 -0800 (PST) Received: by 10.182.70.164 with HTTP; Tue, 7 Feb 2012 19:41:57 -0800 (PST) X-Originating-IP: [98.117.34.27] In-Reply-To: References: <92919CEB-C81F-470A-B59C-74C17610C9D8@vigilsec.com> Date: Tue, 7 Feb 2012 22:41:57 -0500 Message-ID: From: Chris Richardson To: Phillip Hallam-Baker , pkix@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 03:41:58 -0000 On Mon, Feb 6, 2012 at 10:32 PM, Phillip Hallam-Baker wrote: > What is needed therefore is not merely the statement 'OCSP is > supported', that is what the distribution point says and we have been > told 'really check OCSP and hardfail if not found' is not likely to be > implemented so it really has to be 'if you did not get the OCSP token > in the TLS session then you are being MITM'd and must hardfail'. If I'm going to MITM you, I'm not going to use a certificate with this extension. To be useful, the RP must remember that the certificate it saw previously for this domain used this extension. And if the RP has to remember a previously seen certificate, what is the advantage of this proposal over pinning mechanisms? From ryan.hurst@globalsign.com Tue Feb 7 20:23:00 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3C121F857F for ; Tue, 7 Feb 2012 20:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f286y1UzLfTe for ; Tue, 7 Feb 2012 20:23:00 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 255CF21F8574 for ; Tue, 7 Feb 2012 20:23:00 -0800 (PST) Received: by dakl33 with SMTP id l33so147523dak.31 for ; Tue, 07 Feb 2012 20:22:59 -0800 (PST) Received: by 10.68.239.197 with SMTP id vu5mr64090651pbc.42.1328674979867; Tue, 07 Feb 2012 20:22:59 -0800 (PST) Received: from rmhlaptop ([50.46.232.231]) by mx.google.com with ESMTPS id x4sm319681pbx.16.2012.02.07.20.22.58 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Feb 2012 20:22:59 -0800 (PST) From: "Ryan Hurst" To: "'Chris Richardson'" , "'Phillip Hallam-Baker'" , References: <92919CEB-C81F-470A-B59C-74C17610C9D8@vigilsec.com> In-Reply-To: Date: Tue, 7 Feb 2012 20:22:57 -0800 Message-ID: <034901cce619$56c6c5e0$045451a0$@globalsign.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKcs09H9CD5Ub3n7bhCZyBJzTC5cQH82unCAi7C6qoBeafR95RloPeg Content-Language: en-us Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 04:23:00 -0000 Chris, That's only true if you are assuming there is another certificate out there for the same name, that would be true for an existing domain for a limited period of time since the current certificate will expire, or if a CA were compromised and would issue arbitrary certificates. Not that #2 hasn't and won't happen but there is no solving for that problem in the PKIX model. Ryan -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Chris Richardson Sent: Tuesday, February 07, 2012 7:42 PM To: Phillip Hallam-Baker; pkix@ietf.org Subject: Re: [pkix] Certificate flag for 'always stapled' On Mon, Feb 6, 2012 at 10:32 PM, Phillip Hallam-Baker wrote: > What is needed therefore is not merely the statement 'OCSP is > supported', that is what the distribution point says and we have been > told 'really check OCSP and hardfail if not found' is not likely to be > implemented so it really has to be 'if you did not get the OCSP token > in the TLS session then you are being MITM'd and must hardfail'. If I'm going to MITM you, I'm not going to use a certificate with this extension. To be useful, the RP must remember that the certificate it saw previously for this domain used this extension. And if the RP has to remember a previously seen certificate, what is the advantage of this proposal over pinning mechanisms? _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From denis.pinkas@bull.net Wed Feb 8 05:02:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3094D21F86A4 for ; Wed, 8 Feb 2012 05:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeFliu-oF-NL for ; Wed, 8 Feb 2012 05:02:17 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6957621F86A2 for ; Wed, 8 Feb 2012 05:02:17 -0800 (PST) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 6189418045; Wed, 8 Feb 2012 14:02:16 +0100 (CET) In-Reply-To: References: <20120103200025.6720.30648.idtracker@ietfa.amsl.com> <48EA5D1A-410E-471A-9B39-B282ADF78763@vigilsec.com> To: Stephen Kent MIME-Version: 1.0 X-KeepSent: 061955A4:A143DEEB-C125799E:00313CCB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Wed, 8 Feb 2012 14:02:15 +0100 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 08/02/2012 14:02:16, Serialize complete at 08/02/2012 14:02:16 Content-Type: multipart/alternative; boundary="=_alternative 004796C1C125799E_=" Cc: pkix@ietf.org Subject: Re: [pkix] I-D Action: draft-ietf-pkix-cmc-serverkeygeneration-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 13:02:18 -0000 Message en plusieurs parties au format MIME --=_alternative 004796C1C125799E_= Content-Type: text/plain; charset="US-ASCII" Steve, PoP does not provide "an app-level confirmation that the private key has been delivered successfully". This "confirmation", whatever it is, is not mandatory. In any case, a rewriting of the security considerations section is needed. Let us see which text you propose next. Denis De : Stephen Kent A : denis.pinkas@bull.net Cc : Russ Housley , IETF PKIX Date : 06/02/2012 19:27 Objet : Re: [pkix] I-D Action: draft-ietf-pkix-cmc-serverkeygeneration-00.txt At 9:22 AM +0100 1/18/12, denis.pinkas@bull.net wrote: >Steve, > >In this case, POP does not counter a threat. Saying in the security >considerations section it is important and necessary >does not make sense. It is certainly possible add controls which are >not necessary. > >If you really want to maintain for whatever reason (already existing >implementation ?), then it, it should clearly be an option >that any compliant implementation is NOT mandated to implement. > >Denis Denis, Sorry to be so slow to reply. In the CMC keygen context, there is a major benefit for the central keygen facility to have an app-level confirmation that the private key has been delivered successfully. I agree that this is a different motivation than we envisioned for PoP originally, but it is still relevant and useful. Steve --=_alternative 004796C1C125799E_= Content-Type: text/html; charset="US-ASCII" Steve,

PoP does  not  provide "an app-level confirmation that the private
key has been delivered successfully".

This "confirmation", whatever it is, is not mandatory.

In any case, a rewriting of the security considerations section is needed.

Let us see which text you propose next.

Denis




De :        Stephen Kent <kent@bbn.com>
A :        denis.pinkas@bull.net
Cc :        Russ Housley <housley@vigilsec.com>, IETF PKIX <pkix@ietf.org>
Date :        06/02/2012 19:27
Objet :        Re: [pkix] I-D Action:  draft-ietf-pkix-cmc-serverkeygeneration-00.txt



At 9:22 AM +0100 1/18/12, denis.pinkas@bull.net wrote:
>Steve,
>
>In this case, POP does not counter a threat. Saying in the security
>considerations section it is important and necessary
>does not make sense. It is certainly possible add controls which are
>not necessary.
>
>If you really want to maintain for whatever reason (already existing
>implementation ?), then it, it should clearly be an option
>that any compliant implementation is NOT mandated to implement.
>
>Denis  

Denis,

Sorry to be so slow to reply.

In the CMC keygen context, there is a major benefit for the central
keygen facility to have an app-level confirmation that the private
key has been delivered successfully. I agree that this is a different
motivation than we
envisioned for PoP originally, but it is still relevant and useful.

Steve
--=_alternative 004796C1C125799E_=-- From kent@bbn.com Wed Feb 8 08:41:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D7721F86D0 for ; Wed, 8 Feb 2012 08:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.272 X-Spam-Level: X-Spam-Status: No, score=-106.272 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beWMVgVQVkFA for ; Wed, 8 Feb 2012 08:41:02 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 97E3D21F865D for ; Wed, 8 Feb 2012 08:41:02 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:33044 helo=[192.67.20.202]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RvAZo-000CZc-Pk; Wed, 08 Feb 2012 11:41:01 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20120103200025.6720.30648.idtracker@ietfa.amsl.com> <48EA5D1A-410E-471A-9B39-B282ADF78763@vigilsec.com> Date: Wed, 8 Feb 2012 11:24:14 -0500 To: denis.pinkas@bull.net From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-883403236==_ma============" Cc: pkix@ietf.org Subject: Re: [pkix] I-D Action: draft-ietf-pkix-cmc-serverkeygeneration-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 16:41:03 -0000 --============_-883403236==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 2:02 PM +0100 2/8/12, denis.pinkas@bull.net wrote: >Steve, > >PoP does not provide "an app-level confirmation that the private >key has been delivered successfully". PoP can be provided in various ways. For the CMC server generated key context, I imagine that PoP will be provided in a fashion that one might view as more app level, but labeling the level is not the most important aspect of this discussion. >This "confirmation", whatever it is, is not mandatory. if the doc authors propose it as mandatory, and there is WG consensus, the it is. >In any case, a rewriting of the security considerations section is needed. > >Let us see which text you propose next. I'm not proposing text for this doc. I am not a coauthor. I am merely noting that your view of what is an and not mandatory is not shared by a WG chair. Steve --============_-883403236==_ma============ Content-Type: text/html; charset="us-ascii" Re: [pkix] I-D Action: draft-ietf-pkix-cmc-serverkeygener
At 2:02 PM +0100 2/8/12, denis.pinkas@bull.net wrote:
Steve,

PoP does  not  provide "an app-level confirmation that the private
key has been delivered successfully".

PoP can be provided in various ways. For the CMC server generated key context, I imagine that PoP will be provided in a fashion that one might view as more app level, but labeling the level is not the most important aspect of this discussion.

This "confirmation", whatever it is, is not mandatory.

if the doc authors propose it as mandatory, and there is WG consensus, the  it is.

In any case, a rewriting of the security considerations section is needed.
Let us see which text you propose next.

I'm not proposing text for this doc. I am not a coauthor. I am merely noting that your view of what is an and not mandatory is not shared by a WG chair.

Steve
--============_-883403236==_ma============-- From turners@ieca.com Wed Feb 8 10:44:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A39221E8010 for ; Wed, 8 Feb 2012 10:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.159 X-Spam-Level: X-Spam-Status: No, score=-102.159 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqLZUOwGPcQJ for ; Wed, 8 Feb 2012 10:44:57 -0800 (PST) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [69.56.195.7]) by ietfa.amsl.com (Postfix) with ESMTP id EEC1521F85D2 for ; Wed, 8 Feb 2012 10:44:56 -0800 (PST) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 4629DA9609093; Wed, 8 Feb 2012 12:44:55 -0600 (CST) Received: from ham03.websitewelcome.com (ham.websitewelcome.com [173.192.100.229]) by gateway04.websitewelcome.com (Postfix) with ESMTP id 3A6D6A9609064 for ; Wed, 8 Feb 2012 12:44:55 -0600 (CST) Received: by ham03.websitewelcome.com (Postfix, from userid 666) id 37C5B15F09E98; Wed, 8 Feb 2012 12:44:55 -0600 (CST) X-Spam-Flag2999: NO X-Spam-Level2999: X-Spam-Status2999: "No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable version=3.3.1 Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by ham03.websitewelcome.com (Postfix) with ESMTP id B673F15F09AE9 for ; Wed, 8 Feb 2012 12:44:53 -0600 (CST) Received: from [198.180.150.234] (port=58743 helo=dhcp-222-239.meetings.nanog.org) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RvCVh-0000RR-AT; Wed, 08 Feb 2012 12:44:53 -0600 Message-ID: <4F32C2A3.0@ieca.com> Date: Wed, 08 Feb 2012 10:44:51 -0800 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Stephen Kent References: <20120206135022.2C12462176@rfc-editor.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: v234.vpn.iad.rg.net (dhcp-222-239.meetings.nanog.org) [198.180.150.234]:58743 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 83 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: stefans@microsoft.com, stefan@aaa-sec.com, loic.etienne@tech.swisssign.com, pkix@ietf.org, magnus@rsasecurity.com Subject: Re: [pkix] [Technical Errata Reported] RFC3739 (3108) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 18:44:57 -0000 On 2/8/12 10:19 AM, Stephen Kent wrote: > At 5:50 AM -0800 2/6/12, RFC Errata System wrote: >> The following errata report has been submitted for RFC3739, >> "Internet X.509 Public Key Infrastructure: Qualified Certificates >> Profile". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3739&eid=3108 >> >> -------------------------------------- >> Type: Technical >> Reported by: LoÔc Etienne >> >> Section: C.1.1.1. >> >> Original Text >> ------------- >> GeneralizedTime : "197110141200Z" >> >> >> >> Corrected Text >> -------------- >> GeneralizedTime : "19711014120000Z" >> > > Seems like a valid catch of a typo to me. I agree. If you look at 5280 it says the following about generalized time: 5280 req: YYYYMMDDHHMMSSZ original text: 197110141200Z corrected text: 19711014120000Z I'm going to go ahead and mark this one as verified. spt From stefan@aaa-sec.com Wed Feb 8 10:46:29 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDB121F85FC for ; Wed, 8 Feb 2012 10:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXYDq0I+RaM3 for ; Wed, 8 Feb 2012 10:46:29 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.111]) by ietfa.amsl.com (Postfix) with ESMTP id 1936821F85FB for ; Wed, 8 Feb 2012 10:46:29 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 5CEB710FC28F for ; Wed, 8 Feb 2012 19:44:21 +0100 (CET) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Bok1SOO0aAb6 for ; Wed, 8 Feb 2012 19:44:21 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id CE99910FC2C0 for ; Wed, 8 Feb 2012 19:44:20 +0100 (CET) Received: (qmail 17950 invoked from network); 8 Feb 2012 18:44:20 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.4]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 Feb 2012 18:44:20 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 08 Feb 2012 19:43:15 +0100 From: Stefan Santesson To: Stephen Kent , RFC Errata System Message-ID: Thread-Topic: [Technical Errata Reported] RFC3739 (3108) In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: stefans@microsoft.com, loic.etienne@tech.swisssign.com, pkix@ietf.org, Magnus =?ISO-8859-1?B?TnlzdHL2bQ==?= Subject: Re: [pkix] [Technical Errata Reported] RFC3739 (3108) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 18:46:30 -0000 Agreed /Stefan On 12-02-08 7:19 PM, "Stephen Kent" wrote: >At 5:50 AM -0800 2/6/12, RFC Errata System wrote: >>The following errata report has been submitted for RFC3739, >>"Internet X.509 Public Key Infrastructure: Qualified Certificates >>Profile". >> >>-------------------------------------- >>You may review the report below and at: >>http://www.rfc-editor.org/errata_search.php?rfc=3D3739&eid=3D3108 >> >>-------------------------------------- >>Type: Technical >>Reported by: Lo=D4c Etienne >> >>Section: C.1.1.1. >> >>Original Text >>------------- >>GeneralizedTime : "197110141200Z" >> >> >> >>Corrected Text >>-------------- >>GeneralizedTime : "19711014120000Z" >> > >Seems like a valid catch of a typo to me. > >Steve From anders.rundgren@telia.com Wed Feb 8 12:01:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F9511E80A0 for ; Wed, 8 Feb 2012 12:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.138 X-Spam-Level: X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[AWL=0.461, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txqCZ1GJt71S for ; Wed, 8 Feb 2012 12:01:56 -0800 (PST) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 093DE11E809A for ; Wed, 8 Feb 2012 12:01:55 -0800 (PST) Received: from [192.168.0.200] (81.232.141.73) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4EFC380E00AE1E98; Wed, 8 Feb 2012 21:01:51 +0100 Message-ID: <4F32D4AC.4030103@telia.com> Date: Wed, 08 Feb 2012 21:01:48 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Ryan Hurst References: <4F307719.9080905@cs.tcd.ie> <0dc301cce53f$f719b820$e54d2860$@globalsign.com> In-Reply-To: <0dc301cce53f$f719b820$e54d2860$@globalsign.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 20:01:57 -0000 On 2012-02-07 03:26, Ryan Hurst wrote: > Short lived certificates are great, I used them successfully in a design for > some work I have done in the past. I like the idea as well. Now assume that the server uses an HSM for keeping private keys. Sounds great doesn't it? However, no HSM can do what a $10 TPM can do, attest the origin of the *new* key-pair. BTW, PKIX recently dismissed end-to-end-secured enrollment/renewal as a valid topic which de-facto leaves us with stapled OCSP as (IMO) the only realistic choice. There are also scalability issues that speaks for OCSP. Anders > > The problem is that most enrollment clients don't reconfigure servers to use > the new certificate and most applications don't deal with the certificate > change automatically -- the net of which is that without changes to servers > and/or enrollment clients this won't work. > > And while I think application vendors/providers could (and should IMHO) > change to deal with these cases better (can you imagine how much time is > wasted dealing with this today) the adoption curve for new servers is > significantly slower than of browsers, I saw a recent article that suggested > that almost 60% of browsers are updated within a year due to the forced > update semantics within it. > > My takeaway is this work would be complimentary to improvements in the > enrollment clients/certificate supporting servers and address a near term > problem in a practical way. > > Ryan > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Stephen Farrell > Sent: Monday, February 06, 2012 4:58 PM > To: Phillip Hallam-Baker > Cc: pkix@ietf.org > Subject: Re: [pkix] Certificate flag for 'always stapled' > > > I'm not necessarily disagreeing with doing this, but... > > Isn't this getting very close to a short-lived cert? Presumably an RP would > hard-fail with that with no code or config changes and it'd be simpler all > 'round with no need for new RFCs or code even on the TLS server or CA. > (Well, maybe some business logic or billing code would need to change.) > > So, I guess it'd be good to be clear why this is better than just > short-lived certs, but I'm not at all sure I know of a good answer for that > question. > > S > > On 02/06/2012 07:16 PM, Phillip Hallam-Baker wrote: >> Discussions on the utility of various revocation mechanisms in another >> place arrived at the following problem identified in OCSP: While OCSP >> stapling is good for performance, it does nothing to address the >> problems that cause current browsers to (mostly) avoid hard-fail when >> a valid OCSP token is not returned since the client has no way to know >> if a TLS connection should have delivered the stapled cert or not. >> >> Proposal: Introduce a certificate extension that says 'valid OCSP >> token must be stapled when used with TLS'. >> >> >> Mechanism: >> >> If a browser supporting the extension sees a certificate presented in >> a TLS session it ignores any OCSP distribution point published in the >> cert and will only accept the cert if supported by a valid OCSP token >> using the TLS stapling mechanism. >> >> The extension SHOULD NOT be marked critical, legacy browsers will be >> unaffected and fail in the ordinary way. >> >> >> The extension would normally be generated in response to the extension >> being published in a CSR. A CSR generating app should only insert the >> extension if the server is configured to use OCSP stapling. A server >> should provide an operator warning if use of a certificate with the >> extension is attempted without stapling being enabled or alternatively >> turn on stapling automatically. >> >> > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From david.cooper@nist.gov Wed Feb 8 13:25:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1560A21F859F for ; Wed, 8 Feb 2012 13:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.176 X-Spam-Level: X-Spam-Status: No, score=-6.176 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UusEhNeC+dqp for ; Wed, 8 Feb 2012 13:25:42 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 3E07021F859B for ; Wed, 8 Feb 2012 13:25:40 -0800 (PST) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q18LPWZU016682 for ; Wed, 8 Feb 2012 16:25:32 -0500 Message-ID: <4F32E84C.8040509@nist.gov> Date: Wed, 08 Feb 2012 16:25:32 -0500 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20120203 Thunderbird/10.0 MIME-Version: 1.0 To: "pkix@ietf.org" References: <4F307719.9080905@cs.tcd.ie> <0dc301cce53f$f719b820$e54d2860$@globalsign.com> <4F32D4AC.4030103@telia.com> In-Reply-To: <4F32D4AC.4030103@telia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 21:25:43 -0000 New certificate does not necessary imply new private key. The short-term certificates may all contain the same public key. RFC 3647, Section 4.4.6: Certificate renewal means the issuance of a new certificate to the subscriber without changing the subscriber or other participant's public key or any other information in the certificate Of course, this doesn't eliminate the problems that others have mentioned with changing the server's certificate. On 02/08/2012 03:01 PM, Anders Rundgren wrote: > On 2012-02-07 03:26, Ryan Hurst wrote: >> Short lived certificates are great, I used them successfully in a design for >> some work I have done in the past. > I like the idea as well. Now assume that the server uses an HSM > for keeping private keys. Sounds great doesn't it? > > However, no HSM can do what a $10 TPM can do, attest the origin of > the *new* key-pair. BTW, PKIX recently dismissed end-to-end-secured > enrollment/renewal as a valid topic which de-facto leaves us with > stapled OCSP as (IMO) the only realistic choice. > > There are also scalability issues that speaks for OCSP. > > Anders From ryan.hurst@globalsign.com Wed Feb 8 13:50:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F0121F8573 for ; Wed, 8 Feb 2012 13:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfolaEzyb0MQ for ; Wed, 8 Feb 2012 13:50:35 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id CD8B921F8525 for ; Wed, 8 Feb 2012 13:50:35 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so995870pbc.31 for ; Wed, 08 Feb 2012 13:50:35 -0800 (PST) Received: by 10.68.72.138 with SMTP id d10mr69544141pbv.15.1328737835451; Wed, 08 Feb 2012 13:50:35 -0800 (PST) Received: from rmhlaptop ([50.46.232.231]) by mx.google.com with ESMTPS id x4sm1271400pbx.16.2012.02.08.13.50.33 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Feb 2012 13:50:33 -0800 (PST) From: "Ryan Hurst" To: "'David A. Cooper'" , References: <4F307719.9080905@cs.tcd.ie> <0dc301cce53f$f719b820$e54d2860$@globalsign.com> <4F32D4AC.4030103@telia.com> <4F32E84C.8040509@nist.gov> In-Reply-To: <4F32E84C.8040509@nist.gov> Date: Wed, 8 Feb 2012 13:50:31 -0800 Message-ID: <010801cce6ab$ae8b1b90$0ba152b0$@globalsign.com> X-Mailer: Microsoft Outlook 14.0 MIME-Version: 1.0 Thread-Index: AQKcs09H9CD5Ub3n7bhCZyBJzTC5cQEg4V/+Aa+3AAAB4E1AZwHFwU9OlGA30uA= Content-Language: en-us Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0103_01CCE668.9F79D210" Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 21:50:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0103_01CCE668.9F79D210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit David, Your absolutely right, sorry for not being clearer; I do however think that new-key renewals significantly address the risks of software managed keys and key compromise so I have a strong preference for that model. Anders, As far as the use of TPMs as general purpose cryptography appliances like one would use a HSM, the performance and reliability characteristics of these devices make them a poor choice in those environments, they also have limited crypto capabilities making it impossible to implement some protocols with them. With that said the attestation model they offer is quite cool; those systems that do use them for general purpose cryptography scenarios usually limit their use to just a means to secure the key material at rest. Ryan -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of David A. Cooper Sent: Wednesday, February 08, 2012 1:26 PM To: pkix@ietf.org Subject: Re: [pkix] Certificate flag for 'always stapled' New certificate does not necessary imply new private key. The short-term certificates may all contain the same public key. RFC 3647, Section 4.4.6: Certificate renewal means the issuance of a new certificate to the subscriber without changing the subscriber or other participant's public key or any other information in the certificate Of course, this doesn't eliminate the problems that others have mentioned with changing the server's certificate. On 02/08/2012 03:01 PM, Anders Rundgren wrote: > On 2012-02-07 03:26, Ryan Hurst wrote: >> Short lived certificates are great, I used them successfully in a >> design for some work I have done in the past. > I like the idea as well. Now assume that the server uses an HSM for > keeping private keys. Sounds great doesn't it? > > However, no HSM can do what a $10 TPM can do, attest the origin of the > *new* key-pair. BTW, PKIX recently dismissed end-to-end-secured > enrollment/renewal as a valid topic which de-facto leaves us with > stapled OCSP as (IMO) the only realistic choice. > > There are also scalability issues that speaks for OCSP. > > Anders _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_000_0103_01CCE668.9F79D210 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCCA3Uw ggJdoAMCAQICCwQAAAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7mmY3O o+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsurHExwB6E9 CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8GPIhpWypNxadU uGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounICjjr8iQTT3NUkxOF Ohu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjIGSvRRqpI1mQq14M0/ywq wWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8/UswDQYJKoZIhvcNAQEFBQADggEB ANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16qEUi25Qijs8o9YU3TRgmzPsOg42NVG/K6 76054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeYBN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8s uWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUMHaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRW MZXQZ4mFK/lspl1GnQyqguSZUd1wt9tWPWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY 24GzBBzFH6SAbxUgyd4MiAod1mZV4vxIySkmaeAwggQWMIIC/qADAgECAgsEAAAAAAEvTuEvUjAN BgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQ MA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMSR2xvYmFsU2lnbiBSb290IENBMB4XDTExMDQxMzEw MDAwMFoXDTE5MDQxMzEwMDAwMFowVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMFrQfk17PgSfd0iUWlft7kTRid3FDvjE4FvPuR0F34M tfQs5AyNU9TcMCAov26OEf5mEeRRFsfdf/3hNBJQv/PYmOxpC9LQ2rJlceEzl566q7M4lHMRDz6h 0RPMeDYbQSu/vKNJ7DCCTANYMmdhQOU6NhMNQQbr6L7wyfjbmt6jgjQTbvvAPnjaSZVZ5bv6ge/l 1mj17VDJbCIpMQ/oERBVVIGBOFcwbi2tpJINFS3dPV5BNnHkQ5umIEQE7g5OqIFMl+Di8QhiCRfM oumd+zNMHpgwOlH39BLqncA0HeR8Bv63q51I7dYKy3QMavAcMsEUYNHhR5hPkoYacjtxYvsCAwEA AaOB5TCB4jAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUPxXS bXwv5zGeQwoGqJRsLDvF7mUwRwYDVR0gBEAwPjA8BgRVHSAAMDQwMgYIKwYBBQUHAgEWJmh0dHBz Oi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6 Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcm9vdC5jcmwwHwYDVR0jBBgwFoAUYHtmGkUNl8qJUC99BM00 qP/8/UswDQYJKoZIhvcNAQEFBQADggEBAENzecykzEkxAxxhQIHf4LvdSm/AMTx4I6vu3YX+5pAo pzKqqy2otlzq8/Aj+twT2gMe6BjlASNDMgEgRpOc3o/S96B7YhdgS9NZtbAZ0/K0MU9giXf/o6o1 JdKdnsPE9x0smra7KKBrw8H9NMggdiR0zb7UMTTvLesf/tOPANUPtIu7n9J058qyS4w9OM4S/Pcr XrWbKZbTqSVWG5sIhY6uj8bHVDbYVA5nv/aTi5ig50FNKVvyRMC7Nk2AgTSsHYEhgJPP8/rNkgpb SiBtFIeVOreo+yT7sDT/85yJsDK5RwydWKVtK5Bdjxq2lQoAwX/XTgfiCKZ8B3yIviw/niEwggUG MIID7qADAgECAhIRIW+uNPxdwlMR7qsGU+m0guUwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29u YWxTaWduIDIgQ0EgLSBHMjAeFw0xMjAxMjMxNjM2NTlaFw0xNTAxMjMxNjM2NTlaMIGUMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTmV3IEhhbXNwaGlyZTETMBEGA1UEBxMKUG9ydHNtb3V0aDEZMBcG A1UEChMQR2xvYmFsU2lnbiwgSW5jLjETMBEGA1UEAxMKUnlhbiBIdXJzdDEoMCYGCSqGSIb3DQEJ ARYZcnlhbi5odXJzdEBnbG9iYWxzaWduLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALgBJJO9q+awVAChvrS6RJLA4Av2dP+z32W01QIB/l88fmM1x4wrFpCx7aaI6ZFEhdrKRyrW n9NsjvRm1x7fyvaZs7CoMcc9WLXcbEkTJRdaBpEG14My7k4bJY0bWRyFWwZaluy1PRni/SZ3mbUF gWfEHbR5snI5HaVcPGwUrbyecpX7l4yPvpTwGk9DhIIfvJMwbrLRdewHdwKsEqvajdM5iAQq/6g2 dtqgy3dTEy32dJ/2PIiyGOp+dPkB7DcJQ0xq07nmDkVdd0i6QDB6DVhJvWWzTmpbexbTRPd3t1Cz 3/s27EKD8DZ6WZUlKjLz4wtHwlIUR/9oyCM79PIuD+MCAwEAAaOCAY8wggGLMA4GA1UdDwEB/wQE AwIFoDBNBgNVHSAERjBEMEIGCisGAQQBoDIBKAowNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cu Z2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wJAYDVR0RBB0wG4EZcnlhbi5odXJzdEBnbG9iYWxz aWduLmNvbTAJBgNVHRMEAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHR8E PDA6MDigNqA0hjJodHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2dzL2dzcGVyc29uYWxzaWduMmcy LmNybDBVBggrBgEFBQcBAQRJMEcwRQYIKwYBBQUHMAKGOWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2ln bi5jb20vY2FjZXJ0L2dzcGVyc29uYWxzaWduMmcyLmNydDAdBgNVHQ4EFgQUVaIQJ7T8vvZ5Vipx ZictXpJKPOEwHwYDVR0jBBgwFoAUPxXSbXwv5zGeQwoGqJRsLDvF7mUwDQYJKoZIhvcNAQEFBQAD ggEBACFCLqEs9652Z/cgEXggPMK9EjQVph0Ep+mtKT8fQ8N5ri+mwttakDS3RJqKOIli3EqOUzhs 937ZyFvt6Nq0N3KtkjOYNXKrhzfT/EyeKcYqiSlgDXX9V76LZ2+O6W7rmpqyu1BEbJsC65nruWun 8rc4wWCNXk0LcAdgvO81TgPBzhBDUFow6DorNhKspsAFFlqN+ukL26J4+y/uYMhcvH+2gE/FY2Vr m8mbkOtl2fu4d28EITqQzKRs4s3mmYQrRQiXAqHpCLlcPSnOVWQRmWIWQEwmC5t394XvF6DtMo9Y LnHI4Wn1J0yiUkzstMLfCdI7d+sEB6/6r+caz1fHK+wxggOYMIIDlAIBATBqMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNv bmFsU2lnbiAyIENBIC0gRzICEhEhb640/F3CUxHuqwZT6bSC5TAJBgUrDgMCGgUAoIICAzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAyMDgyMTUwMzFaMCMGCSqG SIb3DQEJBDEWBBR3xE11zWBLEDYPhL2A0SJo7LFu+DB5BgkrBgEEAYI3EAQxbDBqMFQxCzAJBgNV BAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBl cnNvbmFsU2lnbiAyIENBIC0gRzICEhEhb640/F3CUxHuqwZT6bSC5TB7BgsqhkiG9w0BCRACCzFs oGowVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUds b2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMgISESFvrjT8XcJTEe6rBlPptILlMIGrBgkq hkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglg hkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3 DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0G CSqGSIb3DQEBAQUABIIBAF9nInmR0sRC9TlNUWchf9ZGhcb0tOCcD/GQMTGjIYkC8Xpmbay+ibjO of2UjmckMklA1ELWmFP0GMaoOAR4D/sTL5iBQ8w+4NjBEsKi6D/NExtfMB++2TSRmIOWs+fd8EHV Zp2QlVvRaFG/znIcaSlaRqREYEAMdO7v3LD+f/D1p20XwHtle7a+JqbkokSRnPQLAfYibFLHzS4q G1YgOXKJ/ZdUNv5XWlqtGFNYmB1a/+wKx/+hfW+/RHHVedGjJ1LmS5jagBpN64rNmCGfY2NSunvF Vpc+/NzlrRBTO0g2W6GcPR74uS+OraMRScS3+ydqzcGxqoGRYNHI0qFpOSIAAAAAAAA= ------=_NextPart_000_0103_01CCE668.9F79D210-- From kent@bbn.com Wed Feb 8 14:06:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E4C21F8599 for ; Wed, 8 Feb 2012 14:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.368 X-Spam-Level: X-Spam-Status: No, score=-106.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59QNjOjWxJ9M for ; Wed, 8 Feb 2012 14:06:30 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC5821F84C4 for ; Wed, 8 Feb 2012 14:06:30 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:40403 helo=[192.67.20.202]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RvFej-000LZE-0K; Wed, 08 Feb 2012 17:06:25 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4F32D4AC.4030103@telia.com> References: <4F307719.9080905@cs.tcd.ie> <0dc301cce53f$f719b820$e54d2860$@globalsign.com> <4F32D4AC.4030103@telia.com> Date: Wed, 8 Feb 2012 17:06:22 -0500 To: Anders Rundgren From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 22:06:31 -0000 At 9:01 PM +0100 2/8/12, Anders Rundgren wrote: >...ed them successfully in a design for > > some work I have done in the past. > >I like the idea as well. Now assume that the server uses an HSM >for keeping private keys. Sounds great doesn't it? > >However, no HSM can do what a $10 TPM can do, attest the origin of >the *new* key-pair. Not a new feature, and not unique to TPMs. The HSMs that we provided in the 90's each contained an RSA key pair unique to the device, and thus one could determine that the key pair generator was a BBN SafeKeyper, if the HSM operator wanted to prove this to a 3rd party. Steve From hallam@gmail.com Wed Feb 8 20:29:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC92D21E8013 for ; Wed, 8 Feb 2012 20:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.376 X-Spam-Level: X-Spam-Status: No, score=-3.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHmku9srBB4N for ; Wed, 8 Feb 2012 20:29:45 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 267B021E8010 for ; Wed, 8 Feb 2012 20:29:45 -0800 (PST) Received: by obbwd15 with SMTP id wd15so2100669obb.31 for ; Wed, 08 Feb 2012 20:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8yd+Q8iPFI80ew3GNfbM2WkiVkgGfV6nG7h74K81lmo=; b=eb7X71xxeEMCdZAkS3/+ANPMJJ8YwdKK6fK76FRapQPyfjruL+6+OJn2VrDXogEal3 8ZXIFwF5ir6N5SIfe5lrYjuozl51n1Ch+nO0o+p10HHavbXfBXTVZgL5FIEInF9E1GO3 JGL/YauK8KcJjOcMY43AsjfryLVZElctIHHLo= MIME-Version: 1.0 Received: by 10.182.75.102 with SMTP id b6mr249701obw.9.1328761784740; Wed, 08 Feb 2012 20:29:44 -0800 (PST) Received: by 10.182.75.138 with HTTP; Wed, 8 Feb 2012 20:29:44 -0800 (PST) In-Reply-To: References: <92919CEB-C81F-470A-B59C-74C17610C9D8@vigilsec.com> Date: Wed, 8 Feb 2012 23:29:44 -0500 Message-ID: From: Phillip Hallam-Baker To: Chris Richardson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 04:29:46 -0000 On Tue, Feb 7, 2012 at 10:41 PM, Chris Richardson w= rote: > On Mon, Feb 6, 2012 at 10:32 PM, Phillip Hallam-Baker = wrote: >> What is needed therefore is not merely the statement 'OCSP is >> supported', that is what the distribution point says and we have been >> told 'really check OCSP and hardfail if not found' is not likely to be >> implemented so it really has to be 'if you did not get the OCSP token >> in the TLS session then you are being MITM'd and must hardfail'. > > If I'm going to MITM you, I'm not going to use a certificate with this > extension. Stop right there, my management would be very happy if there was a way to make a cert undesirable to an attacker! But looking at the question, it seems as if you imagine that the three reported incidents of fraudulent certificate issue are the primary concern here. They are not. The number of certs involved was about a hundred. Or about the number of system admins that screw up their system config, lose their key or foul up in some more imaginative way every day. >To be useful, the RP must remember that the certificate it > saw previously for this domain used this extension. =A0And if the RP has > to remember a previously seen certificate, what is the advantage of > this proposal over pinning mechanisms? Well its stateless for one. Pinning is inherently a stateful process and thus more expensive than this mechanism. But more broadly, this is addressing a separate issue to pinning in my view. Even with pinning we want revocation to work and hardfail. --=20 Website: http://hallambaker.com/ From anders.rundgren@telia.com Wed Feb 8 22:39:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732C121F85B1 for ; Wed, 8 Feb 2012 22:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.195 X-Spam-Level: X-Spam-Status: No, score=-3.195 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhrr-uig2UTy for ; Wed, 8 Feb 2012 22:39:32 -0800 (PST) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 78F8721F854E for ; Wed, 8 Feb 2012 22:39:32 -0800 (PST) Received: from [192.168.0.200] (81.232.141.73) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4EFC3D3500F1D56A; Thu, 9 Feb 2012 07:39:24 +0100 Message-ID: <4F336A18.3020803@telia.com> Date: Thu, 09 Feb 2012 07:39:20 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Stephen Kent References: <4F307719.9080905@cs.tcd.ie> <0dc301cce53f$f719b820$e54d2860$@globalsign.com> <4F32D4AC.4030103@telia.com> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 06:39:33 -0000 On 2012-02-08 23:06, Stephen Kent wrote: > At 9:01 PM +0100 2/8/12, Anders Rundgren wrote: >> ...ed them successfully in a design for >> > some work I have done in the past. >> >> I like the idea as well. Now assume that the server uses an HSM >> for keeping private keys. Sounds great doesn't it? >> >> However, no HSM can do what a $10 TPM can do, attest the origin of >> the *new* key-pair. > > Not a new feature, and not unique to TPMs. The HSMs that we provided > in the 90's each contained an RSA key pair unique to the device, and thus > one could determine that the key pair generator was a BBN SafeKeyper, if the > HSM operator wanted to prove this to a 3rd party. Sure, but I was talking about this in the context of *automatic* renewals. In fact the passport system created by ICAO and BSI relies entirely on short-lived certificates that are automatically renewed and with *new* key material and storage in HSMs. BSI got it slightly wrong and assumed that once a key is in a HSM you are done. Fortunately. Google's Wallet can do secure (attested) updates so it is not all doom and gloom. Anders > > Steve > From kent@bbn.com Wed Feb 8 10:39:32 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A279E21F85D2 for ; Wed, 8 Feb 2012 10:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.335 X-Spam-Level: X-Spam-Status: No, score=-106.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovHzZEfhl2nF for ; Wed, 8 Feb 2012 10:39:31 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 31B8B21F85C0 for ; Wed, 8 Feb 2012 10:39:31 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:43314 helo=[192.67.20.202]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RvCQG-000GFX-Ba; Wed, 08 Feb 2012 13:39:16 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20120206135022.2C12462176@rfc-editor.org> References: <20120206135022.2C12462176@rfc-editor.org> Date: Wed, 8 Feb 2012 13:19:05 -0500 To: RFC Errata System From: Stephen Kent Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 09 Feb 2012 09:20:55 -0800 Cc: stefans@microsoft.com, stefan@aaa-sec.com, loic.etienne@tech.swisssign.com, pkix@ietf.org, magnus@rsasecurity.com, rfc-editor@rfc-editor.org Subject: Re: [pkix] [Technical Errata Reported] RFC3739 (3108) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 18:39:32 -0000 At 5:50 AM -0800 2/6/12, RFC Errata System wrote: >The following errata report has been submitted for RFC3739, >"Internet X.509 Public Key Infrastructure: Qualified Certificates Profile". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=3D3739&eid=3D3108 > >-------------------------------------- >Type: Technical >Reported by: Lo=D4c Etienne > >Section: C.1.1.1. > >Original Text >------------- >GeneralizedTime : "197110141200Z" > > > >Corrected Text >-------------- >GeneralizedTime : "19711014120000Z" > Seems like a valid catch of a typo to me. Steve From swilson@lockstep.com.au Thu Feb 9 11:44:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5AE21F86FA for ; Thu, 9 Feb 2012 11:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jq10M8oxt-Fa for ; Thu, 9 Feb 2012 11:44:52 -0800 (PST) Received: from smtp122.iad.emailsrvr.com (smtp122.iad.emailsrvr.com [207.97.245.122]) by ietfa.amsl.com (Postfix) with ESMTP id BB03221F85E3 for ; Thu, 9 Feb 2012 11:44:51 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp52.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 076502404F5 for ; Thu, 9 Feb 2012 14:44:51 -0500 (EST) X-Virus-Scanned: OK Received: by smtp52.relay.iad1a.emailsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTPA id BA220240CD7 for ; Thu, 9 Feb 2012 14:44:49 -0500 (EST) Message-ID: <4F34221A.9040603@lockstep.com.au> Date: Fri, 10 Feb 2012 06:44:26 +1100 From: Stephen Wilson User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: pkix Content-Type: multipart/alternative; boundary="------------080001070601010801060708" Subject: [pkix] Off topic: Preimage attack on SHA-1 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: swilson@lockstep.com.au List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 19:44:53 -0000 This is a multi-part message in MIME format. --------------080001070601010801060708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Colleagues, Trying the PKIX list for its cryptographic expertise, I hope you don't mind: Is anyone aware of a demonstrated preimage attack (or demonstrated feasibility of a practical preimage attack) on SHA-1? Is it still the case, as it was when RFC4270 was published in 2005, that there is only the possibility of Collision attack? Supplementary question: Does anyone think a preimage attack on the signature of a PKC, even if mounted, would be a practical problem? I would have thought there would be so much interference with the rest of the data structures that the certificate would become unparseable. Cheers, Stephen Wilson Lockstep http://lockstep.com.au Lockstep Consulting provides independent specialist advice and analysis on digital identity and privacy.Lockstep Technologies develops unique new smart ID solutions that enhance privacy and prevent identity theft. --------------080001070601010801060708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Colleagues,

Trying the PKIX list for its cryptographic expertise, I hope you don't mind:

Is anyone aware of a demonstrated preimage attack (or demonstrated feasibility of a practical preimage attack) on SHA-1?  Is it still the case, as it was when RFC4270 was published in 2005, that there is only the possibility of Collision attack?

Supplementary question: Does anyone think a preimage attack on the signature of a PKC, even if mounted, would be a practical problem?  I would have thought there would be so much interference with the rest of the data structures that the certificate would become unparseable.

Cheers,

Stephen Wilson
Lockstep

http://lockstep.com.au
Lockstep Consulting provides independent specialist advice and analysis
on digital identity and privacy.  Lockstep Technologies develops unique
new smart ID solutions that enhance privacy and prevent identity theft.


--------------080001070601010801060708-- From martin.peylo@nsn.com Fri Feb 10 05:40:29 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73F121F86CA for ; Fri, 10 Feb 2012 05:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIcko6UB1vvG for ; Fri, 10 Feb 2012 05:40:17 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9F11621F86A3 for ; Fri, 10 Feb 2012 05:40:15 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q1ADeAoC004106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Feb 2012 14:40:10 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q1ADe83i003427; Fri, 10 Feb 2012 14:40:09 +0100 Received: from FIESEXC006.nsn-intra.net ([10.159.0.14]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Feb 2012 14:40:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Feb 2012 15:40:08 +0200 Message-ID: <3BF363C82C184B46930A905352C2013F0198F143@FIESEXC006.nsn-intra.net> In-Reply-To: <4F2BE42E.1000508@ieca.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] AD review of draft-ietf-pkix-cmp-transport-protocols Thread-Index: Aczieaj80/Xu0DP0T9KCi/AEUmmUDAFfuE0w References: <201202030019.q130JPW2019942@fs4113.wdf.sap.corp> <4F2BE42E.1000508@ieca.com> From: "Peylo, Martin (NSN - FI/Espoo)" To: "ext Sean Turner" , X-OriginalArrivalTime: 10 Feb 2012 13:40:09.0128 (UTC) FILETIME=[816E8A80:01CCE7F9] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2488 X-purgate-ID: 151667::1328881210-00007EDF-6BCB8430/0-0/0-0 Cc: pkix@ietf.org Subject: Re: [pkix] AD review of draft-ietf-pkix-cmp-transport-protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 13:40:30 -0000 Hi Sean and Martin, thank you for your excellent review comments. Please excuse that I haven't found time during this week to process them but be assured that this is with high priority in my backlog. I will implement the needed changes you suggested, do some additional research where needed, and will come back with detailed replies for each item asap. Kind regards, Martin -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of ext Sean Turner Sent: Friday, February 03, 2012 3:42 PM To: mrex@sap.com Cc: pkix@ietf.org Subject: Re: [pkix] AD review of draft-ietf-pkix-cmp-transport-protocols On 2/2/12 7:19 PM, Martin Rex wrote: > Sean Turner wrote: >> >> - But, I've been told that HTTP 1.1 is more widely implemented so can we >> make it the preferred version and then make 1.0 a MAY? >> >> OLD: >> >> Either HTTP/1.0 as described in [RFC1945] or HTTP/1.1 as in [RFC2616] >> MAY be used. Server implementations SHOULD be able to interact with >> counterparts utilizing either HTTP protocol version. >> >> NEW: >> >> Clients and servers MUST support HTTP/1.1 [RFC2616]. Clients and >> server MAY also support HTTP/1.0 [RFC1945]. > > > Unless the protocol is vitally dependent on features that exist only > in HTTP/1.1 (which the original text suggests is not the case), > a "MUST support HTTP/1.1" is in clear violation of rfc2119 Section 6 > > > http://tools.ietf.org/html/rfc2119#section-6 > > 6. Guidance in the use of these Imperatives > > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > *> example, they must not be used to try to impose a particular method > *> on implementors where the method is not required for > *> interoperability. I was shooting for less to implement. Regardless, I think the first=20 sentence needs to be explicit about the client requirements so I could=20 live with the following: Clients MUST support either HTTP/1.0 [RFC1945] or HTTP/1.1 [RFC2616]. Servers SHOULD support both HTTP versions. spt _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From piyush@identicate.com Fri Feb 10 10:10:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C2021F87B5 for ; Fri, 10 Feb 2012 10:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgkckGL0yCEh for ; Fri, 10 Feb 2012 10:10:18 -0800 (PST) Received: from col0-omc2-s4.col0.hotmail.com (col0-omc2-s4.col0.hotmail.com [65.55.34.78]) by ietfa.amsl.com (Postfix) with ESMTP id DF8C621F871E for ; Fri, 10 Feb 2012 10:10:17 -0800 (PST) Received: from COL119-DS19 ([65.55.34.72]) by col0-omc2-s4.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Feb 2012 10:10:16 -0800 X-Originating-IP: [75.25.128.241] X-Originating-Email: [piyush@identicate.com] Message-ID: From: Piyush Jain To: "'Phillip Hallam-Baker'" , "'Russ Housley'" References: <92919CEB-C81F-470A-B59C-74C17610C9D8@vigilsec.com> In-Reply-To: Date: Fri, 10 Feb 2012 10:10:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKcs09H9CD5Ub3n7bhCZyBJzTC5cQH82unCAi7C6qqUdXbHMA== Content-Language: en-us X-OriginalArrivalTime: 10 Feb 2012 18:10:16.0810 (UTC) FILETIME=[3DF68CA0:01CCE81F] Cc: pkix@ietf.org Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 18:10:19 -0000 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of > Phillip Hallam-Baker > Sent: Monday, February 06, 2012 7:32 PM > To: Russ Housley > Cc: pkix@ietf.org > Subject: Re: [pkix] Certificate flag for 'always stapled' >=20 > On Mon, Feb 6, 2012 at 6:36 PM, Russ Housley > wrote: > > Phill: > > > >> Proposal: Introduce a certificate extension that says 'valid OCSP > >> token must be stapled when used with TLS'. > > > > You really just want the check made by the relying party before = making use > of the certificate. =A0Why do you care who makes the request to the = OCSP > responder? > > > > Russ >=20 > No, thats not the point. The point is that the server is always going = to provide > the token stapled so if there is no stapled token there is no need to = look > elsewhere. >=20 > The motivation for this is that the Google people are proposing to not look > elsewhere if there is no stapled token. At the moment most of the = browsers > will try to pull the OCSP token but give up if it is not found (soft fail). So the > revocation mechanism is effectively nullified. >=20 Not sure if I understand the use case correctly. It seems that only benefit of this extension is that the CAs will be = able to force the TLS servers to implement OCSP stapling. I>=20 > What is needed therefore is not merely the statement 'OCSP is = supported', > that is what the distribution point says and we have been told 'really check > OCSP and hardfail if not found' is not likely to be implemented so it really has > to be 'if you did not get the OCSP token in the TLS session then you = are being > MITM'd and must hardfail'. If there is an attacker in the middle, why would he present a = certificate with this extension? Are you saying that this is for scenarios where the CA is compromised or those where it has issued certificates in error? >=20 >=20 > -- > Website: http://hallambaker.com/ > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From tom@ritter.vg Fri Feb 10 10:33:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9F221F8786 for ; Fri, 10 Feb 2012 10:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.94 X-Spam-Level: X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goWNi46sZN0T for ; Fri, 10 Feb 2012 10:33:42 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 440BC21F8770 for ; Fri, 10 Feb 2012 10:33:33 -0800 (PST) Received: by lahl5 with SMTP id l5so3114917lah.31 for ; Fri, 10 Feb 2012 10:33:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HE62qxCE+gNutkdrameWhB+TQ5XU+7VFCR7GzHh7Ze8=; b=4D9TiIEG9EAxciB4+fwEtY72zV/hRGwfaElllrU7we/u+AFM61GvEFpUGt4K2a2KCX TbZXhrUYdN9PQOEBrkJ/ltEkL6N1l07k9AlbQZTqe31/bHGdsNcz/TftXGKI/bhvCWPd ITBQ2yDHvmNO9YyV2qK+u3y+wck3Z5zntsVEk= Received: by 10.152.130.102 with SMTP id od6mr4870973lab.14.1328898812131; Fri, 10 Feb 2012 10:33:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.11.67 with HTTP; Fri, 10 Feb 2012 10:33:12 -0800 (PST) In-Reply-To: References: <92919CEB-C81F-470A-B59C-74C17610C9D8@vigilsec.com> From: Tom Ritter Date: Fri, 10 Feb 2012 13:33:12 -0500 Message-ID: To: Piyush Jain Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmRI/XwwUtiJwSkRdF8ejw8uD4PV9hWmV2oRMBP2UWSa7rmxOdbHtJc59i8+II2NWVcSkB+ Cc: pkix@ietf.org Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 18:33:43 -0000 > If there is an attacker in the middle, why would he present a certificate > with this extension? > Are you saying that this is for scenarios where the CA is compromised or > those where it has issued certificates in error? I think the 'big wins' for this mechanism come from enhancements that haven't been made yet. For example: - In some future browser, a site communicates a security policy (perhaps in or similar to Strict Transport Security) that says "certs from me will always have the require-staple extension set". If the browser sees a cert presented that doesn't have it, it fails. - In some future browser/extension that 'learns' security policy from the site without being explicitly told it (e.g. site is hosted in the Us, uses this CA, etc) - this will be another data point - A browser chooses to extend a extra-special-super-green bar[1] to a certificate that has this extension set - CAs eventually decide to only issue (EV || DV) certs that have this extension set ( || for high profile sites || sites that opt in) One scenario today, the only I could think of in 5 minutes, where this an advantage is if an attacker compromises a cert in use, it gets revoked/expires[2], and the attacker wants to use it. Cert can't get a good staple, and would be rejected. For the 'common' attack scenario of an attacker breaking into or tricking a CA to issue him his own cert, this doesn't help. I'm torn. I like things that add incremental options for site owners to improve security. But... there's an implementation cost here. And the more I survey PKIX as it stands and is being developed now... there's *so much* for a security conscious administrator to consider. Do we want to add a whole lot more for relatively small gains? -tom [1] Or some other way to say "This cert is double-plus-good", like the subtle differences in UI we have today between Mixed Content, DV, and EV certs. [2] Considering clock attacks From paul.hoffman@vpnc.org Fri Feb 10 10:47:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF8321F852C for ; Fri, 10 Feb 2012 10:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYAZUJhezG8k for ; Fri, 10 Feb 2012 10:47:30 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id EEC2421F8523 for ; Fri, 10 Feb 2012 10:47:28 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1AIlQq7054062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 10 Feb 2012 11:47:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: Date: Fri, 10 Feb 2012 10:47:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: PKIX X-Mailer: Apple Mail (2.1257) Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 18:47:30 -0000 Although this is a proposed PKIX extension, the value of it only comes = if certificate emitters and relying parties act on it. The extension = itself is pretty trivial, but as the thread has shown, the semantics and = implementation are not. If this is pursued, the work should be done = where there is more difficulty; that is, it should be in the websec WG, = not the pkix WG, although the format of the extension should certainly = be reviewed here. --Paul Hoffman From rob.stradling@comodo.com Fri Feb 10 13:50:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B95421F860D for ; Fri, 10 Feb 2012 13:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiBFt8B3msU8 for ; Fri, 10 Feb 2012 13:50:33 -0800 (PST) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id F0FFD21F84F4 for ; Fri, 10 Feb 2012 13:50:31 -0800 (PST) Received: (qmail 4922 invoked from network); 10 Feb 2012 21:50:30 -0000 Received: from ian.bd.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 10 Feb 2012 21:50:30 -0000 Received: (qmail 19152 invoked by uid 1000); 10 Feb 2012 21:50:29 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Fri, 10 Feb 2012 21:50:29 +0000 Message-ID: <4F359124.5080500@comodo.com> Date: Fri, 10 Feb 2012 21:50:28 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 21:50:36 -0000 On 10/02/12 18:47, Paul Hoffman wrote: > ...although the format of the extension should certainly be reviewed here. Rather than define a completely new extension, wouldn't it make more sense to extend the existing Authority Information Access extension? The fields in the AIA extension are accessMethod and accessLocation. OCSP is the "method" for both on-line OCSP and stapled OCSP. The main difference between the two is the "location" from which the OCSP Response is "accessed". -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From piyush@identicate.com Fri Feb 10 21:53:01 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D337321F8598 for ; Fri, 10 Feb 2012 21:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id En4orppystxO for ; Fri, 10 Feb 2012 21:53:00 -0800 (PST) Received: from col0-omc1-s12.col0.hotmail.com (col0-omc1-s12.col0.hotmail.com [65.55.34.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7B24221F8574 for ; Fri, 10 Feb 2012 21:52:59 -0800 (PST) Received: from COL119-DS8 ([65.55.34.8]) by col0-omc1-s12.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Feb 2012 21:52:54 -0800 X-Originating-IP: [75.25.128.241] X-Originating-Email: [piyush@identicate.com] Message-ID: From: Piyush Jain To: "'Rob Stradling'" , References: <4F359124.5080500@comodo.com> In-Reply-To: <4F359124.5080500@comodo.com> Date: Fri, 10 Feb 2012 21:52:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKcs09H9CD5Ub3n7bhCZyBJzTC5cQLrsyCJAkrWkXWUbeVl8A== Content-Language: en-us X-OriginalArrivalTime: 11 Feb 2012 05:52:54.0617 (UTC) FILETIME=[65F96490:01CCE881] Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 05:53:02 -0000 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Rob Stradling > Sent: Friday, February 10, 2012 1:50 PM > To: pkix@ietf.org > Subject: Re: [pkix] Certificate flag for 'always stapled' > > On 10/02/12 18:47, Paul Hoffman wrote: > > > ...although the format of the extension should certainly be reviewed here. > > Rather than define a completely new extension, wouldn't it make more > sense to extend the existing Authority Information Access extension? > I think that the use cases that this new extension would server are still unclear. > The fields in the AIA extension are accessMethod and accessLocation. > OCSP is the "method" for both on-line OCSP and stapled OCSP. The main > difference between the two is the "location" from which the OCSP Response > is "accessed". > In any case overloading AIA might not be a good idea. The interpretation of this extension would differ depending on whether the RP is a TLS client or a TLS server. > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From anders.rundgren@telia.com Sun Feb 12 01:59:42 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD21321F85E1 for ; Sun, 12 Feb 2012 01:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.24 X-Spam-Level: X-Spam-Status: No, score=-3.24 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSGJ9RT6BePO for ; Sun, 12 Feb 2012 01:59:42 -0800 (PST) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8A421F8593 for ; Sun, 12 Feb 2012 01:59:41 -0800 (PST) Received: from [192.168.0.200] (81.232.141.73) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F337D59000FAB4A; Sun, 12 Feb 2012 10:59:39 +0100 Message-ID: <4F378D84.8040303@telia.com> Date: Sun, 12 Feb 2012 10:59:32 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: denis.pinkas@bull.net References: <20120103200025.6720.30648.idtracker@ietfa.amsl.com> <48EA5D1A-410E-471A-9B39-B282ADF78763@vigilsec.com> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] I-D Action: draft-ietf-pkix-cmc-serverkeygeneration-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 09:59:42 -0000 On 2012-02-08 14:02, denis.pinkas@bull.net wrote: > Steve, > > PoP does not provide "an app-level confirmation that the private > key has been delivered successfully". > > This "confirmation", whatever it is, is not mandatory. > > In any case, a rewriting of the security considerations section is needed. > > Let us see which text you propose next. > > Denis Denis, There are basically two use-cases for out-of-the-crypto-module generated keys. 1. Devices that have limited crypto capability. The already widely established method is using key-injection during the manufacturing/personalization process. That doesn't require a new protocol. 2. Restore/update of encryption keys. For that you would need a secure import process. This is already established by ETSI for smart cards using a completely different method than CMP. Conclusion: this draft doesn't address any real use-cases. Anders > > > > > De : Stephen Kent > A : denis.pinkas@bull.net > Cc : Russ Housley , IETF PKIX > Date : 06/02/2012 19:27 > Objet : Re: [pkix] I-D Action: draft-ietf-pkix-cmc-serverkeygeneration-00.txt > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > At 9:22 AM +0100 1/18/12, denis.pinkas@bull.net wrote: >>Steve, >> >>In this case, POP does not counter a threat. Saying in the security >>considerations section it is important and necessary >>does not make sense. It is certainly possible add controls which are >>not necessary. >> >>If you really want to maintain for whatever reason (already existing >>implementation ?), then it, it should clearly be an option >>that any compliant implementation is NOT mandated to implement. >> >>Denis > > Denis, > > Sorry to be so slow to reply. > > In the CMC keygen context, there is a major benefit for the central > keygen facility to have an app-level confirmation that the private > key has been delivered successfully. I agree that this is a different > motivation than we > envisioned for PoP originally, but it is still relevant and useful. > > Steve > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From internet-drafts@ietf.org Mon Feb 13 07:43:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5981A21F84B5; Mon, 13 Feb 2012 07:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+NJn6JRj1ye; Mon, 13 Feb 2012 07:43:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E2321F849C; Mon, 13 Feb 2012 07:43:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120213154320.7744.34537.idtracker@ietfa.amsl.com> Date: Mon, 13 Feb 2012 07:43:20 -0800 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-caa-04.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 15:43:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : DNS Certification Authority Authorization (CAA) Resource= Record Author(s) : Phillip Hallam-Baker Rob Stradling Filename : draft-ietf-pkix-caa-04.txt Pages : 16 Date : 2012-02-13 The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the certificate signing certificate(s) authorized to issue certificates for that domain. CAA resource records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis- issue. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-caa-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-caa-04.txt From hallam@gmail.com Mon Feb 13 07:49:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBC221F8570 for ; Mon, 13 Feb 2012 07:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W33pu6LkE4IY for ; Mon, 13 Feb 2012 07:49:16 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4091021F8569 for ; Mon, 13 Feb 2012 07:49:16 -0800 (PST) Received: by obbwd15 with SMTP id wd15so8066862obb.31 for ; Mon, 13 Feb 2012 07:49:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=PRI0E3sPZuAZO+6uVQvsJaUcT7Hsp3Wl0kwXymVFLBE=; b=K5q5wnTuneRlVc7ip3+3uorVsw+4MSIBfs8ZGgQLpUQUOm3XricuAVzMvUfSwDvniA pk7JjWOBx11nlYjucgeqfX7VebVi5kFwQZ0EkkXpjqBXEcaElRxhsraYR7Ot63qQX8Ai P7Njdnc0jCWV7NRqNEkKZpcppT+iirIv8yrjQ= MIME-Version: 1.0 Received: by 10.182.121.101 with SMTP id lj5mr12320228obb.39.1329148155817; Mon, 13 Feb 2012 07:49:15 -0800 (PST) Received: by 10.182.75.138 with HTTP; Mon, 13 Feb 2012 07:49:15 -0800 (PST) Date: Mon, 13 Feb 2012 10:49:15 -0500 Message-ID: From: Phillip Hallam-Baker To: pkix@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [pkix] draft-ietf-pkix-caa-04 submitted X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 15:49:20 -0000 This is mostly edits to correct a bunch of nits substantive changes are: * The IODEF reporting mechanism is documented * Have added in ABNF for the property field encoding to separate the private use area from the rest * Removed remaining client side enforcement stuff * Added notes to guide use by projects like convergence, EFF observatory etc. pointing out limitations * Have added previously defined but obsolete properties to list as 'reserved' * Cleaned up the IANA part At this point I think the doument itself is almost ready to go. The main thing that needs to be done is to run an ABNF checker tool over the examples. -- Website: http://hallambaker.com/ From hallam@gmail.com Mon Feb 13 07:54:01 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C5721F8594 for ; Mon, 13 Feb 2012 07:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.376 X-Spam-Level: X-Spam-Status: No, score=-3.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLl9wOCvupS1 for ; Mon, 13 Feb 2012 07:53:58 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D788A21F8661 for ; Mon, 13 Feb 2012 07:53:53 -0800 (PST) Received: by obbwd15 with SMTP id wd15so8072762obb.31 for ; Mon, 13 Feb 2012 07:53:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5pTinh68ddI11Kfa8InTuANpEZBB+nhE6+00EjT/e9A=; b=Gz8DIFD46FyABWGsYLQ6NxkY2ivgnt0kPd8stHPP7Glg3/+XhsWte43D8hCPhSdLCB +Jb2hIanzBOlD/oDxovo/IoSjm1AAdJqwONGJ8R/qTns3hP/8bGy08jv9ILjspXVO3DU ZvrJ34+9gOiW+83xhROzxiiwyMsJD1pCL89wI= MIME-Version: 1.0 Received: by 10.182.1.104 with SMTP id 8mr12283364obl.19.1329148433465; Mon, 13 Feb 2012 07:53:53 -0800 (PST) Received: by 10.182.75.138 with HTTP; Mon, 13 Feb 2012 07:53:53 -0800 (PST) In-Reply-To: References: <92919CEB-C81F-470A-B59C-74C17610C9D8@vigilsec.com> Date: Mon, 13 Feb 2012 10:53:53 -0500 Message-ID: From: Phillip Hallam-Baker To: Tom Ritter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 15:54:01 -0000 We already have a security mechanism in SSL, it is the https URL method combined with the padlock icon. Now that is not the best approach, but it is certainly more than nothing. It would clearly be best if we had a more comprehensive security policy mechanism. But that is a lot more involved than the 'must staple' flag. On Fri, Feb 10, 2012 at 1:33 PM, Tom Ritter wrote: >> If there is an attacker in the middle, why would he present a certificat= e >> with this extension? >> Are you saying that this is for scenarios where the CA is compromised or >> those where it has issued certificates in error? > > I think the 'big wins' for this mechanism come from enhancements that > haven't been made yet. > > For example: > =A0- In some future browser, a site communicates a security policy > (perhaps in or similar to Strict Transport Security) that says "certs > from me will always have the require-staple extension set". =A0If the > browser sees a cert presented that doesn't have it, it fails. > =A0- In some future browser/extension that 'learns' security policy from > the site without being explicitly told it (e.g. site is hosted in the > Us, uses this CA, etc) - this will be another data point > =A0- A browser chooses to extend a extra-special-super-green bar[1] to a > certificate that has this extension set > =A0- CAs eventually decide to only issue (EV || DV) certs that have this > extension set ( || for high profile sites || sites that opt in) > > One scenario today, the only I could think of in 5 minutes, where this > an advantage is if an attacker compromises a cert in use, it gets > revoked/expires[2], and the attacker wants to use it. =A0Cert can't get > a good staple, and would be rejected. =A0For the 'common' attack > scenario of an attacker breaking into or tricking a CA to issue him > his own cert, this doesn't help. > > I'm torn. =A0I like things that add incremental options for site owners > to improve security. But... there's an implementation cost here. =A0And > the more I survey PKIX as it stands and is being developed now... > there's *so much* for a security conscious administrator to consider. > Do we want to add a whole lot more for relatively small gains? > > -tom > > [1] Or some other way to say "This cert is double-plus-good", like the > subtle differences in UI we have today between Mixed Content, DV, and > EV certs. > [2] Considering clock attacks --=20 Website: http://hallambaker.com/ From hallam@gmail.com Mon Feb 13 08:01:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC24721F8648 for ; Mon, 13 Feb 2012 08:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.38 X-Spam-Level: X-Spam-Status: No, score=-3.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBFIcOuwALPf for ; Mon, 13 Feb 2012 08:01:42 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A5A7521F86B8 for ; Mon, 13 Feb 2012 08:01:41 -0800 (PST) Received: by obbwd15 with SMTP id wd15so8081757obb.31 for ; Mon, 13 Feb 2012 08:01:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8s9deF8EuhxZ+34/fnOnTlgjjsMWWqfQrOdkx6bd9YA=; b=g1LMvNKG+lfEfTqP5gy1DLZXwa1hMux69HEyh1oMo95tnJ68f+Pt+JFe03qrJiX3nD 653eZI6F+odH8HpLR7GN4AXOYDkZUAmsc5FP12RTQS7bBVIl7/gC8vzr5YAaI6ktNm7d npulNp1SoWWPlQpSDyiQYUegLEhsPTUzL3SxQ= MIME-Version: 1.0 Received: by 10.182.1.104 with SMTP id 8mr12322227obl.19.1329148901142; Mon, 13 Feb 2012 08:01:41 -0800 (PST) Received: by 10.182.75.138 with HTTP; Mon, 13 Feb 2012 08:01:40 -0800 (PST) In-Reply-To: References: Date: Mon, 13 Feb 2012 11:01:40 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: PKIX Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 16:01:44 -0000 Suggesting WebSec is a fair enough point. The PKIX part is pretty straightforward as you point out. But as Rob also points out, there is more than one option for expressing the flag. I would like to get that part squared away first. As for this being a way for CAs to 'force' use of stapling. I hadn't really though of it that way. But assuming the cost of supporting this type of cert is significantly lower than for regular certs, it is possible that some CAs will offer them at a lower price. That would be a win win for the customer - better security and a lower cost. I somehow suspect that the cost reduction is not going to be significant enough to make a difference for any sites other than the very busiest. On Fri, Feb 10, 2012 at 1:47 PM, Paul Hoffman wrote= : > Although this is a proposed PKIX extension, the value of it only comes if= certificate emitters and relying parties act on it. The extension itself i= s pretty trivial, but as the thread has shown, the semantics and implementa= tion are not. If this is pursued, the work should be done where there is mo= re difficulty; that is, it should be in the websec WG, not the pkix WG, alt= hough the format of the extension should certainly be reviewed here. > > --Paul Hoffman > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From tmiller@mitre.org Mon Feb 13 08:02:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BB821F863F for ; Mon, 13 Feb 2012 08:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCRTmAYxxCWi for ; Mon, 13 Feb 2012 08:02:45 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7901D21F862D for ; Mon, 13 Feb 2012 08:02:45 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F315921B16EB; Mon, 13 Feb 2012 11:02:44 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7133821B16DD; Mon, 13 Feb 2012 11:02:44 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.10]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Mon, 13 Feb 2012 11:02:44 -0500 From: "Miller, Timothy J." To: Phillip Hallam-Baker , Tom Ritter Thread-Topic: [pkix] Certificate flag for 'always stapled' Thread-Index: AQHM5QPZ4EeRVIkoFEaXkC2Z7S5fAJYw2hSAgABB7YCABaxAgIAABmwAgASKe4D//53hAA== Date: Mon, 13 Feb 2012 16:02:44 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.31.63.183] Content-Type: text/plain; charset="us-ascii" Content-ID: <8830DDC6E946FE429A4F35A23048C257@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Certificate flag for 'always stapled' X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 16:02:47 -0000 On 2/13/12 9:53 AM, "Phillip Hallam-Baker" wrote: >We already have a security mechanism in SSL, it is the https URL >method combined with the padlock icon. > >Now that is not the best approach, but it is certainly more than >nothing. It would clearly be best if we had a more comprehensive >security policy mechanism. But that is a lot more involved than the >'must staple' flag. Machine evaluation & mapping of certification policies? I could get behind that. =20 -- T From James.H.Manger@team.telstra.com Mon Feb 13 16:43:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4318A21F86EC for ; Mon, 13 Feb 2012 16:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=-1.638, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FoceTkqL2ul for ; Mon, 13 Feb 2012 16:43:02 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 33BD921F86FE for ; Mon, 13 Feb 2012 16:43:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,414,1325422800"; d="scan'208";a="62103501" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 14 Feb 2012 11:43:00 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6619"; a="50734878" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcdvi.tcif.telstra.com.au with ESMTP; 14 Feb 2012 11:42:57 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Tue, 14 Feb 2012 11:42:59 +1100 From: "Manger, James H" To: Phillip Hallam-Baker , "pkix@ietf.org" Date: Tue, 14 Feb 2012 11:42:59 +1100 Thread-Topic: [pkix] draft-ietf-pkix-caa-04: looking at parent domains Thread-Index: AczqZxJ0u8383lHrTFSNCfUSnzttsQARFLtw Message-ID: <255B9BB34FB7D647A506DC292726F6E114EBD69476@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pkix] draft-ietf-pkix-caa-04: looking at parent domains X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 00:43:03 -0000 Phillip, If a CA is asked to issue a cert to a.b.c.example.com I assume it should lo= ok for CAA records in the following 4 domains, stopping as soon as it finds= some: a.b.c.example.com b.c.example.com c.example.com example.com However, draft-ietf-pkix-caa-04 says [=A73] to look at the canonical form o= f a domain name, then the public delegation point. That would only be: a.b.c.example.com example.com On a minor issue, the ABNF for value [=A74.2] will not work: value =3D *VCHAR | DQUOTE *(%x20-21 / %x23-7E) DQUOTE VCHAR is %x21-7E, which includes DQUOTE and ";" that makes parsing ambiguou= s. How about allowing printable ASCII, excluding space, quote, and semicolon: value =3D *(%x21 / %x23-3A / %x3C-7E) -- James Manger From anders.rundgren@telia.com Tue Feb 14 13:56:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AD221E80D0 for ; Tue, 14 Feb 2012 13:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.276 X-Spam-Level: X-Spam-Status: No, score=-3.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7CXsOQTNDGZ for ; Tue, 14 Feb 2012 13:56:41 -0800 (PST) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3E321E80CE for ; Tue, 14 Feb 2012 13:56:41 -0800 (PST) Received: from [192.168.0.200] (81.232.141.73) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F337D5900214DB4; Tue, 14 Feb 2012 22:56:37 +0100 Message-ID: <4F3AD88C.9040000@telia.com> Date: Tue, 14 Feb 2012 22:56:28 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: denis.pinkas@bull.net References: <20120103200025.6720.30648.idtracker@ietfa.amsl.com> <48EA5D1A-410E-471A-9B39-B282ADF78763@vigilsec.com> <4F378D84.8040303@telia.com> In-Reply-To: <4F378D84.8040303@telia.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] I-D Action: draft-ietf-pkix-cmc-serverkeygeneration-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 21:56:43 -0000 Followup, The section "1.2 Location of Key Generator" is at odds with the reality. Crypto modules seldom (ever?) speak PKIData, they can at best produce a PKCS #1 signature. I.e. there is one trusted path and associated "lingo" between the Client and the RA and another between the RA and the CA. No PKIX enrollment protocol support E2ES. Do you have any idea what a possible client could be? Regarding PoP for server-generated keys it seems redundant since the RA can verify that the key-pair is intact. An established use-case for server-generated keys is CAs delivering keys in PKCS #12 containers. Anders On 2012-02-12 10:59, Anders Rundgren wrote: > On 2012-02-08 14:02, denis.pinkas@bull.net wrote: >> Steve, >> >> PoP does not provide "an app-level confirmation that the private >> key has been delivered successfully". >> >> This "confirmation", whatever it is, is not mandatory. >> >> In any case, a rewriting of the security considerations section is needed. >> >> Let us see which text you propose next. >> >> Denis > > Denis, > There are basically two use-cases for out-of-the-crypto-module generated keys. > > 1. Devices that have limited crypto capability. The already widely established > method is using key-injection during the manufacturing/personalization process. > That doesn't require a new protocol. > > 2. Restore/update of encryption keys. For that you would need a secure import > process. This is already established by ETSI for smart cards using a > completely different method than CMP. > > Conclusion: this draft doesn't address any real use-cases. > > Anders > > >> >> >> >> >> De : Stephen Kent >> A : denis.pinkas@bull.net >> Cc : Russ Housley , IETF PKIX >> Date : 06/02/2012 19:27 >> Objet : Re: [pkix] I-D Action: draft-ietf-pkix-cmc-serverkeygeneration-00.txt >> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> >> >> >> At 9:22 AM +0100 1/18/12, denis.pinkas@bull.net wrote: >>> Steve, >>> >>> In this case, POP does not counter a threat. Saying in the security >>> considerations section it is important and necessary >>> does not make sense. It is certainly possible add controls which are >>> not necessary. >>> >>> If you really want to maintain for whatever reason (already existing >>> implementation ?), then it, it should clearly be an option >>> that any compliant implementation is NOT mandated to implement. >>> >>> Denis >> >> Denis, >> >> Sorry to be so slow to reply. >> >> In the CMC keygen context, there is a major benefit for the central >> keygen facility to have an app-level confirmation that the private >> key has been delivered successfully. I agree that this is a different >> motivation than we >> envisioned for PoP originally, but it is still relevant and useful. >> >> Steve >> >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From hallam@gmail.com Tue Feb 14 15:36:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C367221E8122 for ; Tue, 14 Feb 2012 15:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvRPRFCOdMI4 for ; Tue, 14 Feb 2012 15:36:39 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2843C21E810F for ; Tue, 14 Feb 2012 15:36:39 -0800 (PST) Received: by qafi29 with SMTP id i29so2596760qaf.10 for ; Tue, 14 Feb 2012 15:36:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=vprhIzUdEMDYgbKgp0b6FX+kGntmTVm9L4GM3ADEf44=; b=r78wq106kdP2zT5p4APqVK/SobO4gl60Y8g1AWu4ReMniwMTPgwzO1LuQ+xUbNmfTF Zcz/fjzFsnEtgOFgfk/PUh+HpDeDKY0kzVgI0j2MBpoJAEhtfYmlALPWzfKVgKBDyIe5 odDiM0LPLBHIT7C9fcvhsdwrmxccDmPSKSilA= Received: by 10.229.77.141 with SMTP id g13mr13694018qck.11.1329262597305; Tue, 14 Feb 2012 15:36:37 -0800 (PST) Received: from [192.168.6.53] ([64.134.103.194]) by mx.google.com with ESMTPS id hk9sm6534007qab.20.2012.02.14.15.36.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Feb 2012 15:36:36 -0800 (PST) References: <255B9BB34FB7D647A506DC292726F6E114EBD69476@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114EBD69476@WSMSG3153V.srv.dir.telstra.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <630E6CE0-E0FB-4AA6-A81A-67A6A566DAE9@gmail.com> X-Mailer: iPad Mail (9A405) From: Phillip Hallam-Baker Date: Tue, 14 Feb 2012 18:36:33 -0500 To: "Manger, James H" Cc: "pkix@ietf.org" Subject: Re: [pkix] draft-ietf-pkix-caa-04: looking at parent domains X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 23:36:39 -0000 Thanks, The testing only at the canonical domain and the delegation point is deliber= ate. The CAs do maintain lists of public delegation points and 90+% is met b= y a a policy covering the whole domain in any case. The only reason for look= ing at the canonical domain is that it allows for exceptions to be special c= ased.=20 Checking all the way up would increase the work for the CA and in particular= the records keeping. I will fix the ABNF.=20 Sent from my iPad On Feb 13, 2012, at 19:42, "Manger, James H" wrote: > Phillip, >=20 > If a CA is asked to issue a cert to a.b.c.example.com I assume it should l= ook for CAA records in the following 4 domains, stopping as soon as it finds= some: > a.b.c.example.com > b.c.example.com > c.example.com > example.com >=20 > However, draft-ietf-pkix-caa-04 says [=C2=A73] to look at the canonical fo= rm of a domain name, then the public delegation point. That would only be: > a.b.c.example.com > example.com >=20 >=20 >=20 > On a minor issue, the ABNF for value [=C2=A74.2] will not work: > value =3D *VCHAR | DQUOTE *(%x20-21 / %x23-7E) DQUOTE >=20 > VCHAR is %x21-7E, which includes DQUOTE and ";" that makes parsing ambiguo= us. > How about allowing printable ASCII, excluding space, quote, and semicolon:= > value =3D *(%x21 / %x23-3A / %x3C-7E) >=20 >=20 > -- > James Manger From James.H.Manger@team.telstra.com Tue Feb 14 16:07:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EF721E810F for ; Tue, 14 Feb 2012 16:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.337 X-Spam-Level: X-Spam-Status: No, score=-1.337 tagged_above=-999 required=5 tests=[AWL=-2.295, BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1y6nXNk0f-C for ; Tue, 14 Feb 2012 16:07:15 -0800 (PST) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFB021E802A for ; Tue, 14 Feb 2012 16:07:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,420,1325422800"; d="scan'208";a="62058236" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 15 Feb 2012 11:07:12 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6620"; a="50799753" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcavi.tcif.telstra.com.au with ESMTP; 15 Feb 2012 11:07:12 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Wed, 15 Feb 2012 11:07:11 +1100 From: "Manger, James H" To: Phillip Hallam-Baker Date: Wed, 15 Feb 2012 11:07:10 +1100 Thread-Topic: [pkix] draft-ietf-pkix-caa-04: looking at parent domains Thread-Index: AczrcYDT7PovMpnhQ7i8jEUFpDkNUwAAUuSw Message-ID: <255B9BB34FB7D647A506DC292726F6E114EBDF7723@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114EBD69476@WSMSG3153V.srv.dir.telstra.com> <630E6CE0-E0FB-4AA6-A81A-67A6A566DAE9@gmail.com> In-Reply-To: <630E6CE0-E0FB-4AA6-A81A-67A6A566DAE9@gmail.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] draft-ietf-pkix-caa-04: looking at parent domains X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 00:07:16 -0000 PiBUaGUgdGVzdGluZyBvbmx5IGF0IHRoZSBjYW5vbmljYWwgZG9tYWluIGFuZCB0aGUgZGVsZWdh dGlvbiBwb2ludCBpcyBkZWxpYmVyYXRlLiBUaGUgQ0FzIGRvIG1haW50YWluIGxpc3RzIG9mIHB1 YmxpYyBkZWxlZ2F0aW9uIHBvaW50cyBhbmQgOTArJSBpcyBtZXQgYnkgYSBhIHBvbGljeSBjb3Zl cmluZyB0aGUgd2hvbGUgZG9tYWluIGluIGFueSBjYXNlLiBUaGUgb25seSByZWFzb24gZm9yIGxv b2tpbmcgYXQgdGhlIGNhbm9uaWNhbCBkb21haW4gaXMgdGhhdCBpdCBhbGxvd3MgZm9yIGV4Y2Vw dGlvbnMgdG8gYmUgc3BlY2lhbCBjYXNlZC4gDQoNClRoYXQgbWFrZXMgc29tZSBzZW5zZS4gSG93 ZXZlciwgYXJlICJwdWJsaWMgZGVsZWdhdGlvbiBwb2ludHMiIHdlbGwgZW5vdWdoIGRlZmluZWQ/ IEkgYXNzdW1lIHRoZXNlIGFyZSB0aGUgc2FtZSBhcyBwdWJsaWMgc3VmZml4ZXMgW2h0dHA6Ly9w dWJsaWNzdWZmaXgub3JnL10uIExpc3RzIG9mIHRoZXNlIGV4aXN0LCBidXQgdGhleSBmZWVsIGEg bGl0dGxlIGZ1enp5IGFuZCBhZCBob2MuIEkgZG91YnQgZXZlcnlvbmXigJlzIGxpc3QgaXMgdGhl IHNhbWUgYXQgYW55IHBvaW50IGluIHRpbWUuIEZvciBpbnN0YW5jZSwgd2lsbCB0aGlzIHJ1bGUg bWVhbiBhIHdob2xlIEdvdmVybm1lbnQgY2FuIHNwZWNpZnkgYSBDQSBwb2xpY3ksIGJ1dCBwYXJ0 aWN1bGFyIEdvdmVybm1lbnQgZGVwYXJ0bWVudHMgY2Fubm90Pw0KDQoNCj4gQ2hlY2tpbmcgYWxs IHRoZSB3YXkgdXAgd291bGQgaW5jcmVhc2UgdGhlIHdvcmsgZm9yIHRoZSBDQSBhbmQgaW4gcGFy dGljdWxhciB0aGUgcmVjb3JkcyBrZWVwaW5nLg0KDQpXb3VsZCBpdCByZWFsbHkgaW5jcmVhc2Ug bm90aWNlYWJseT8gTXkgZ3Vlc3MgKHdpdGhvdXQgYW55IGRhdGEpIGlzIHRoYXQgbW9zdCBjZXJ0 cyAocGVyaGFwcyB0aGUgdmFzdCBtYWpvcml0eSkgYXJlIGxpa2Ugd3d3LmV4YW1wbGUuY29tIG9y IGV4YW1wbGUuY29tIHRoYXQgaGF2ZSBubyBleHRyYSBsYXllcnMgaW4gYmV0d2VlbiB0byBjaGVj az8NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQoNCg0KLS0tLS0NCg0KPj4gSWYgYSBDQSBpcyBhc2tl ZCB0byBpc3N1ZSBhIGNlcnQgdG8gYS5iLmMuZXhhbXBsZS5jb20gSSBhc3N1bWUgaXQgc2hvdWxk IGxvb2sgZm9yIENBQSByZWNvcmRzIGluIHRoZSBmb2xsb3dpbmcgNCBkb21haW5zLCBzdG9wcGlu ZyBhcyBzb29uIGFzIGl0IGZpbmRzIHNvbWU6DQo+PiAgYS5iLmMuZXhhbXBsZS5jb20NCj4+ICAg IGIuYy5leGFtcGxlLmNvbQ0KPj4gICAgICBjLmV4YW1wbGUuY29tDQo+PiAgICAgICAgZXhhbXBs ZS5jb20NCj4+IA0KPj4gSG93ZXZlciwgZHJhZnQtaWV0Zi1wa2l4LWNhYS0wNCBzYXlzIFvCpzNd IHRvIGxvb2sgYXQgdGhlIGNhbm9uaWNhbCBmb3JtIG9mIGEgZG9tYWluIG5hbWUsIHRoZW4gdGhl IHB1YmxpYyBkZWxlZ2F0aW9uIHBvaW50LiBUaGF0IHdvdWxkIG9ubHkgYmU6DQo+PiAgYS5iLmMu ZXhhbXBsZS5jb20NCj4+ICAgICAgICBleGFtcGxlLmNvbQ0K From mrex@sap.com Tue Feb 14 16:11:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3216F21F8559 for ; Tue, 14 Feb 2012 16:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.127 X-Spam-Level: X-Spam-Status: No, score=-10.127 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-9uSPrGtWKZ for ; Tue, 14 Feb 2012 16:11:15 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8F61821F8557 for ; Tue, 14 Feb 2012 16:11:14 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q1F0BATF009558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Feb 2012 01:11:10 +0100 (MET) From: Martin Rex Message-Id: <201202150011.q1F0BApg024784@fs4113.wdf.sap.corp> To: eabalea@gmail.com (Erwann Abalea) Date: Wed, 15 Feb 2012 01:11:10 +0100 (MET) In-Reply-To: from "Erwann Abalea" at Jan 24, 12 10:33:16 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 00:11:16 -0000 Erwann Abalea wrote: > > "Martin Rex": > > > > Santosh Chokhani wrote: > > > > > > Originally, CRL DP was designed to partition the CRL. > > > If CRL DP is not included in a certificate, that certificate > > > cannot go in a partition. > > > > > > When you ignore a critical IDP extension in CRL, you are insecure. > > This point is important. > > If you ignore a *critical* extension, then you fail. Completely. You're > free to ignore any non critical extension (at least in X.509, not RFC5280), > but if you encounter a critical extension that you don't understand, you > MUST reject the object. I would agree to criticality of X.509 certificate(!) extensions, but I believe that the expectations are unjusitified with respect to criticial CRL extensions (and entirely misled about criticial CRLEntryExtensions) The default configuration for CRL checking, similar to OCSP checking is to *not* hard-fail. Sticking one's head in the sand about this is not going to change reality. >From the definition of the IssuingDistributionPoint CRL Extension: http://tools.ietf.org/html/rfc5280#section-5.2.5 5.2.5. Issuing Distribution Point The issuing distribution point is a critical CRL extension that identifies the CRL distribution point and scope for a particular CRL, and it indicates whether the CRL covers revocation for end entity certificates only, CA certificates only, attribute certificates only, or a limited set of reason codes. Although the extension is critical, conforming implementations are not required to support this extension. However, implementations that do not support this extension MUST either treat the status of any certificate not listed on this CRL as unknown or locate another CRL that does not contain any unrecognized critical extensions. Scoping of the CRL by the Distribution Point, rather than by "entity certificates ony, CA certificates only, attributes certificates only or a limited set of reason codes" goes beyond the specified design goals, so don't be surprised if it breaks. The wording of the last sentences is particularly confusing: However, implementations that do not support this extension MUST either treat the status of any certificate not listed on this CRL as unknown or locate another CRL that does not contain any unrecognized critical extensions. "unknown" is not a status known to the CRL Validation algorithm in section 6.2. And while our implementation (the software module above the ASN.1 parser) does not "support this extension", the ASN.1 parser of our implementation *DOES* recognize it. > > > If someone fubars his PKI so badly, so that there is no > > CRL DP with full scope listed in his certs, or that the CRL > > returned from that URL is unusable for the promised purpose, > > then for our RP the customer will have to manually configure a download > > URL for that issuerName so that our CRL cache can populated/updated > > out-of-band with conforming CRLs ... or disable revocation checking > > for that issuerName. > > Would you trust such a CA? That question does not apply to us. We do not ship a single CA as pretrusted with out implementation, our customers have to configure *each* CA that they want to trust explicitly. And because of buggy PKI software and non-conforming CAs, there is a non-marginal amount of non-conformance that your PKI software has to tolerate. Keep in mind that rfc5280 is VERY explicit about being liberal about conformance during certificate path validation: http://tools.ietf.org/html/rfc5280#page-72 Therefore, the algorithm only includes checks to verify that the certification path is valid according to X.509 and does not include checks to verify that the certificates and CRLs conform to this profile. While the algorithm could be extended to include checks for conformance to the profiles in Sections 4 and 5, this profile RECOMMENDS against including such checks. So rfc5280 explicitly RECOMMENDS against including conformance checks from Section 5 of rfc5280, and that includes 5.2.5 Issuing Distribution Point above! So one may claim conformance to PKIX rfc5280 in spite of ignoring conformance checks from Sections 4 & 5 of rfc5280. That is what it says. -Martin From hallam@gmail.com Tue Feb 14 18:15:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9530D21F8578 for ; Tue, 14 Feb 2012 18:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.379 X-Spam-Level: X-Spam-Status: No, score=-3.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMgPwC50HxDo for ; Tue, 14 Feb 2012 18:15:37 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9223321F8573 for ; Tue, 14 Feb 2012 18:15:37 -0800 (PST) Received: by obbwd15 with SMTP id wd15so864823obb.31 for ; Tue, 14 Feb 2012 18:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=I0WTjOiQaFUe41bS2UJy73KUtzRk/rr1cU5dLdpYYbY=; b=Y5nVbcc/fvo2kyltb/edBpJN8QakIRTtaZuNVwTf5eqOkGqSZBSI1ykDGXr4usHyrp eaO5PoAYZ/rjdfPqRulVdT0rsjCfWijPFISYHq73k1HXANQ+0N2+ucXUlcN34ZzxD79U IqRUwYs9pZL4qsbUfnQ68Zp85cE4HZBvUWG8I= MIME-Version: 1.0 Received: by 10.60.7.102 with SMTP id i6mr1833544oea.9.1329272137255; Tue, 14 Feb 2012 18:15:37 -0800 (PST) Received: by 10.182.75.138 with HTTP; Tue, 14 Feb 2012 18:15:37 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114EBDF7723@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114EBD69476@WSMSG3153V.srv.dir.telstra.com> <630E6CE0-E0FB-4AA6-A81A-67A6A566DAE9@gmail.com> <255B9BB34FB7D647A506DC292726F6E114EBDF7723@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 14 Feb 2012 21:15:37 -0500 Message-ID: From: Phillip Hallam-Baker To: "Manger, James H" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" Subject: Re: [pkix] draft-ietf-pkix-caa-04: looking at parent domains X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 02:15:38 -0000 On Tue, Feb 14, 2012 at 7:07 PM, Manger, James H wrote: >> The testing only at the canonical domain and the delegation point is del= iberate. The CAs do maintain lists of public delegation points and 90+% is = met by a a policy covering the whole domain in any case. The only reason fo= r looking at the canonical domain is that it allows for exceptions to be sp= ecial cased. > > That makes some sense. However, are "public delegation points" well enoug= h defined? I assume these are the same as public suffixes [http://publicsuf= fix.org/]. Lists of these exist, but they feel a little fuzzy and ad hoc. I= doubt everyone=92s list is the same at any point in time. For instance, wi= ll this rule mean a whole Government can specify a CA policy, but particula= r Government departments cannot? The delegation points are a well known issue in the CA world already. Has to be because the authentication callback email has to go there... Government departments are pretty much the only case I can see where there would likely be a real requirement to support multiple issuers. I guess we could go to a three step approach... > >> Checking all the way up would increase the work for the CA and in partic= ular the records keeping. > > Would it really increase noticeably? My guess (without any data) is that = most certs (perhaps the vast majority) are like www.example.com or example.= com that have no extra layers in between to check? I see no problem at all checking for reasonable cases. It is edge cases like a.b.c.d.e.f.g.h.i.j....com that worry me. I know the DNS makes it possible to set up such domains but I see absolutely no need to support them... The issue here is the way we write and test security code. I am much happier with a limited set of three test cases than having to support an 200+ of them. --=20 Website: http://hallambaker.com/ From tomas@primekey.se Wed Feb 15 00:30:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C2721F8599 for ; Wed, 15 Feb 2012 00:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE2NWo6tko6n for ; Wed, 15 Feb 2012 00:30:15 -0800 (PST) Received: from mail.primekey.se (mail.primekey.se [213.179.18.11]) by ietfa.amsl.com (Postfix) with ESMTP id B623D21F8594 for ; Wed, 15 Feb 2012 00:30:15 -0800 (PST) Received: from mail.primekey.se (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id CFC9FE223B for ; Wed, 15 Feb 2012 09:30:15 +0100 (CET) Received: from [192.168.3.115] (unknown [193.12.106.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.se (Postfix) with ESMTPSA id BDC56E213F for ; Wed, 15 Feb 2012 09:30:15 +0100 (CET) Message-ID: <4F3B6D14.5060601@primekey.se> Date: Wed, 15 Feb 2012 09:30:12 +0100 From: Tomas Gustavsson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: pkix@ietf.org References: <201202150011.q1F0BApg024784@fs4113.wdf.sap.corp> In-Reply-To: <201202150011.q1F0BApg024784@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 08:30:16 -0000 > 5.2.5. Issuing Distribution Point > > The issuing distribution point is a critical CRL extension that > identifies the CRL distribution point and scope for a particular CRL, > and it indicates whether the CRL covers revocation for end entity > certificates only, CA certificates only, attribute certificates only, > or a limited set of reason codes. Although the extension is > critical, conforming implementations are not required to support this > extension. However, implementations that do not support this > extension MUST either treat the status of any certificate not listed > on this CRL as unknown or locate another CRL that does not contain > any unrecognized critical extensions. > > > Scoping of the CRL by the Distribution Point, rather than by > "entity certificates ony, CA certificates only, attributes certificates only > or a limited set of reason codes" goes beyond the specified design goals, > so don't be surprised if it breaks. That is probably the only CRL partitioning that actually does not exists in the wild(?). I know of at least two used CRL partitioning schemes out there and both target the same use case. The common use case for CRL partitioning is to limit the size of CRLs. CRLs basically only consists of entity certificates, so the suggested partitioning scheme in rfc seems totally redundant. Naturally RPs must understand CRL partitioning, it's out there in the wild. There's nothing wrong with designing your validation code to a specific use case of course. If you know these CRL partitioning schemes are not used in your environment, skip it. The standard for CRL partitioning is extremely open ended though, and also used so. The only safe implementation in your software module is to break if it encounters an unsupported critical extension (not the asn.1 parser of course but your software on top of it). Current CRL partitioning schemes that I know of are: - Limiting a certain max no of entries per CRL - Issuing different CRLs for different cert classes, i.e. one CRL for signature certs, and another (or none at all) for auth certs (because the RPs use OCSP). Cheers, Tomas From hotz@jpl.nasa.gov Wed Feb 15 09:54:23 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471EE21F8598 for ; Wed, 15 Feb 2012 09:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLJpoHZwCsCj for ; Wed, 15 Feb 2012 09:54:22 -0800 (PST) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id C9CC621F8597 for ; Wed, 15 Feb 2012 09:54:22 -0800 (PST) Received: from [192.168.2.107] (adsl-99-65-136-93.dsl.lsan03.sbcglobal.net [99.65.136.93]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1FHsJLc021327 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 15 Feb 2012 09:54:20 -0800 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Wed, 15 Feb 2012 09:54:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <255B9BB34FB7D647A506DC292726F6E114EBD69476@WSMSG3153V.srv.dir.telstra.com> <630E6CE0-E0FB-4AA6-A81A-67A6A566DAE9@gmail.com> <255B9BB34FB7D647A506DC292726F6E114EBDF7723@WSMSG3153V.srv.dir.telstra.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) X-Source-IP: adsl-99-65-136-93.dsl.lsan03.sbcglobal.net [99.65.136.93] X-Source-Sender: hotz@jpl.nasa.gov X-Spamclassfication-Commtouch: not spam X-SpamRefId: str=0001.0A090209.4F3BF14D.00C8,ss=1,fgs=0 Cc: "pkix@ietf.org" Subject: Re: [pkix] draft-ietf-pkix-caa-04: looking at parent domains X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 17:54:23 -0000 On Feb 14, 2012, at 6:15 PM, Phillip Hallam-Baker wrote: >>> Checking all the way up would increase the work for the CA and in = particular the records keeping. >>=20 >> Would it really increase noticeably? My guess (without any data) is = that most certs (perhaps the vast majority) are likewww.example.com or = example.com that have no extra layers in between to check? >=20 > I see no problem at all checking for reasonable cases. It is edge > cases like a.b.c.d.e.f.g.h.i.j....com that worry me. >=20 > I know the DNS makes it possible to set up such domains but I see > absolutely no need to support them... >=20 >=20 > The issue here is the way we write and test security code. I am much > happier with a limited set of three test cases than having to support > an 200+ of them. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From SChokhani@cygnacom.com Wed Feb 15 10:20:10 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1208321E806A for ; Wed, 15 Feb 2012 10:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exukjBkqbhMU for ; Wed, 15 Feb 2012 10:20:05 -0800 (PST) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 30B4821E8051 for ; Wed, 15 Feb 2012 10:20:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,424,1325480400"; d="scan'208";a="4124631" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 15 Feb 2012 13:20:03 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Wed, 15 Feb 2012 13:20:03 -0500 From: Santosh Chokhani To: "pkix@ietf.org" Date: Wed, 15 Feb 2012 13:20:02 -0500 Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Thread-Index: Aczrmxq0OQM0sdJUSci1h5zProoTGA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 18:20:10 -0000 All, IDP criticality must be enforced with the knowledge that the CRL may be inc= orrect one for the scope and//or may have partial information. RFC 5280 does not say or imply that use any old CRL without processing or w= ithout applying critical IDP extension and assume that the information in t= he incorrect or incomplete CRL means revocation information has been obtain= ed. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Tuesday, February 14, 2012 7:11 PM To: Erwann Abalea Cc: mrex@sap.com; Santosh Chokhani; pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Erwann Abalea wrote: >=20 > "Martin Rex": > > > > Santosh Chokhani wrote: > > > > > > Originally, CRL DP was designed to partition the CRL. > > > If CRL DP is not included in a certificate, that certificate=20 > > > cannot go in a partition. > > > > > > When you ignore a critical IDP extension in CRL, you are insecure. >=20 > This point is important. > > If you ignore a *critical* extension, then you fail. Completely.=20 > You're free to ignore any non critical extension (at least in X.509,=20 > not RFC5280), but if you encounter a critical extension that you don't=20 > understand, you MUST reject the object. I would agree to criticality of X.509 certificate(!) extensions, but I beli= eve that the expectations are unjusitified with respect to criticial CRL ex= tensions (and entirely misled about criticial CRLEntryExtensions) The default configuration for CRL checking, similar to OCSP checking is to = *not* hard-fail. Sticking one's head in the sand about this is not going t= o change reality. >From the definition of the IssuingDistributionPoint CRL Extension: http://tools.ietf.org/html/rfc5280#section-5.2.5 5.2.5. Issuing Distribution Point The issuing distribution point is a critical CRL extension that identifies the CRL distribution point and scope for a particular CRL, and it indicates whether the CRL covers revocation for end entity certificates only, CA certificates only, attribute certificates only, or a limited set of reason codes. Although the extension is critical, conforming implementations are not required to support this extension. However, implementations that do not support this extension MUST either treat the status of any certificate not listed on this CRL as unknown or locate another CRL that does not contain any unrecognized critical extensions. Scoping of the CRL by the Distribution Point, rather than by "entity certif= icates ony, CA certificates only, attributes certificates only or a limite= d set of reason codes" goes beyond the specified design goals, so don't be = surprised if it breaks. The wording of the last sentences is particularly confusing: However, implementations that do not support this extension MUST either treat the status of any certificate not listed on this CRL as unknown or locate another CRL that does not contain any unrecognized critical extensions. "unknown" is not a status known to the CRL Validation algorithm in section = 6.2. And while our implementation (the software module above the ASN.1 parser) does not "support this extension", the ASN.1 parser of our im= plementation *DOES* recognize it.=20 >=20 > > If someone fubars his PKI so badly, so that there is no CRL DP with=20 > > full scope listed in his certs, or that the CRL returned from that=20 > > URL is unusable for the promised purpose, then for our RP the=20 > > customer will have to manually configure a download URL for that=20 > > issuerName so that our CRL cache can populated/updated out-of-band=20 > > with conforming CRLs ... or disable revocation checking for that=20 > > issuerName. >=20 > Would you trust such a CA? That question does not apply to us. We do not ship a single CA as pretrusted with out implementation, our custo= mers have to configure *each* CA that they want to trust explicitly. And b= ecause of buggy PKI software and non-conforming CAs, there is a non-margina= l amount of non-conformance that your PKI software has to tolerate. Keep in mind that rfc5280 is VERY explicit about being liberal about confor= mance during certificate path validation: http://tools.ietf.org/html/rfc5280#page-72 Therefore, the algorithm only includes checks to verify that the certification path is valid according to X.509 and does not include checks to verify that the certificates and CRLs conform to this profile. While the algorithm could be extended to include checks for conformance to the profiles in Sections 4 and 5, this profile RECOMMENDS against including such checks. So rfc5280 explicitly RECOMMENDS against including conformance checks from = Section 5 of rfc5280, and that includes 5.2.5 Issuing Distribution Point ab= ove! So one may claim conformance to PKIX rfc5280 in spite of ignoring conforman= ce checks from Sections 4 & 5 of rfc5280. That is what it says.=20 -Martin From wjhns1@hardakers.net Wed Feb 15 11:41:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE53521E8071 for ; Wed, 15 Feb 2012 11:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZccQFmeNVAV for ; Wed, 15 Feb 2012 11:41:40 -0800 (PST) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id D89BF21E8032 for ; Wed, 15 Feb 2012 11:41:39 -0800 (PST) Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id 46B2D8DC; Wed, 15 Feb 2012 11:41:36 -0800 (PST) From: Wes Hardaker To: Phillip Hallam-Baker References: <255B9BB34FB7D647A506DC292726F6E114EBD69476@WSMSG3153V.srv.dir.telstra.com> <630E6CE0-E0FB-4AA6-A81A-67A6A566DAE9@gmail.com> Date: Wed, 15 Feb 2012 11:41:36 -0800 In-Reply-To: <630E6CE0-E0FB-4AA6-A81A-67A6A566DAE9@gmail.com> (Phillip Hallam-Baker's message of "Tue, 14 Feb 2012 18:36:33 -0500") Message-ID: <0laa4jhojz.fsf@wjh.hardakers.net> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "pkix@ietf.org" Subject: Re: [pkix] draft-ietf-pkix-caa-04: looking at parent domains X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 19:41:44 -0000 >>>>> On Tue, 14 Feb 2012 18:36:33 -0500, Phillip Hallam-Baker said: PH> Checking all the way up would increase the work for the CA and in PH> particular the records keeping. The work is trivial (we're talking seconds wall-clock, and micro-seconds for actual CPU time considering it's really just waiting for network traffic). What's the record keeping concern of which you speak? Are you saying that it's intensive to document all the places you didn't find anything but did check? Even if you were going to packet log everything you sent and received, we're still only talking about minuscule amounts of bytes. -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ From martin.peylo@nsn.com Wed Feb 15 13:18:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3333F21F86A0 for ; Wed, 15 Feb 2012 13:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwUX8+kazwr4 for ; Wed, 15 Feb 2012 13:18:37 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id B1F8421F869A for ; Wed, 15 Feb 2012 13:18:36 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q1FLIW2O007234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Feb 2012 22:18:33 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q1FLIWS4019394; Wed, 15 Feb 2012 22:18:32 +0100 Received: from FIESEXC006.nsn-intra.net ([10.159.0.14]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Feb 2012 22:18:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Feb 2012 23:18:29 +0200 Message-ID: <3BF363C82C184B46930A905352C2013F01A14942@FIESEXC006.nsn-intra.net> In-Reply-To: <4F2B2243.8070309@ieca.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] AD review of draft-ietf-pkix-cmp-transport-protocols Thread-Index: AcziBhD1yavOGsMxSLeI6P5sukF/iwKEFPkA References: <4F2B2243.8070309@ieca.com> From: "Peylo, Martin (NSN - FI/Espoo)" To: "ext Sean Turner" , , "ext Martin Rex" X-OriginalArrivalTime: 15 Feb 2012 21:18:32.0423 (UTC) FILETIME=[5EBD0F70:01CCEC27] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 7321 X-purgate-ID: 151667::1329340713-000015E0-C946C7C2/0-0/0-0 Cc: toka@tectia.com Subject: Re: [pkix] AD review of draft-ietf-pkix-cmp-transport-protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 21:18:38 -0000 Hi, I've just uploaded a new draft 16 implementing most of the great suggestions=20 I got from Sean Turner. Explicit answers to each issue Sean identified are below. There have also been some minor changes to text in close relation to those issues - which are mentioned at the relevant issue. > I've reviewed draft-ietf-pkix-cmp-transport-protocols and have the > following comments I'd like to see addressed prior to IETF LC: =20 > 1) s1: r/Certificate Authorities (CAs)/Certification Authorities (CAs) Done. > 2) s1: r/an own polling/its own polling Done. > 3) s1: remove the following because it sounds like marketing: >=20 > HTTP transport is generally easy to implement, traverses network > borders utilizing ubiquitous proxies and is already commonly found in > existing implementations. Done. > 4) s3.1/s9: references for RFCs 1945 and 2616 are normative because > there is 2119 language associated with them in s3.1. Also: >=20 > - I think what you're trying say is that either protocol can be used by > clients so I think you need to be specific about that and a MUST is > needed (saying MAY for both seems odd to me). >=20 > - But, I've been told that HTTP 1.1 is more widely implemented so can we > make it the preferred version and then make 1.0 a MAY? >=20 > OLD: >=20 > Either HTTP/1.0 as described in [RFC1945] or HTTP/1.1 as in [RFC2616] > MAY be used. Server implementations SHOULD be able to interact with > counterparts utilizing either HTTP protocol version. >=20 > NEW: >=20 > Clients and servers MUST support HTTP/1.1 [RFC2616]. Clients and > server MAY also support HTTP/1.0 [RFC1945]. Changed the text to Sean's suggestion from the later mail as a reply to=20 Martin Rex' intervention: NEW: > Clients MUST support either HTTP/1.0 [RFC1945] or HTTP/1.1 [RFC2616]. > Servers SHOULD support both HTTP versions. =20 > 5) s3.2: Not sure I can parse the following: >=20 > HTTP permits to reuse a connection for subsequent requests. > Implementations may use this functionality for messages within the > same transaction but MUST NOT rely on that as e.g. intermediate HTTP > proxies might terminate the connection after each request/response > pair. >=20 > did you mean to say: >=20 > ... MUST NOT rely on this because intermediate HTTP proxies might > terminate the connection after each request/response pair. Done - while it sounds the same for me (non-native English speaker) ;-) > 6) s3.3: Not sure the DER-encoded part is necessary isn't that already > covered in CMP: ? >=20 > OLD: An ASN.1 DER-encoded PKIMessage >=20 > NEW: A PKIMessage I couldn't figure out if RFC4210 actually explicitly requires that the whole PKImessage is DER-encoded. It mentions that signatures need to be calculated over the DER-encoding of certain fields. It is mentioned in the transport draft as I once encountered someone who thought about creating an CMP implementation using XML-encoding format. It is now changed to "A DER-encoded PKIMessage", removing the redundant "ASN.1". I hope that is acceptable? > 7) s3.3: I think response is better than reply: >=20 > OLD: the server returns the CMP reply >=20 > NEW: the server returns the CMP response Done. > 8) s3.3: I think you need to be clear that you're talking about the HTTP > status codes because there are also CMP status codes: >=20 > OLD: The response status >=20 > NEW: The HTTP response status Done. > 9) s3.3: Please be specific about the announcement types: >=20 > OLD: >=20 > HTTP responses to pushed CMP Announcement messages > utilize the status codes 201 and 202 to identify whether the received > information was processed. >=20 > NEW: >=20 > HTTP responses to pushed CMP Announcement messages (i.e., > CA Certificate Announcement, Certificate Announcement, > Revocation Announcement, and CRL Announcement) utilize the > status codes 201 and 202 to identify whether the received > information was processed. Done. =20 > 10) s3.3: Do you need to say anything about redirection? Like is it > allowed or should the client not follow them? I note there's some text > in the security considerations but it might be worth also adding in this > section. The following paragraph has been added to s3.3: While "Redirection 3xx" status codes MAY be supported by implementations, clients should only be enabled to automatically follow them after careful consideration of possible security implications. Additionally the following has been extended in the same paragraph to help the reader: 2xx -> "Successful 2xx" 4xx -> "Client Error 4xx" 5xx -> "Server Error 5xx" Also in the security considerations 301 was extended to "301 Moved=20 Permanently". > 11) s3.4/s9: RFC 2510 is a normative reference because that's where > application/pkixcmp is defined. This is going to force a downref > because RFC 2510 is obsoleted - not a big deal but something I need to > remember when I do the IETF LC (hint if you don't see it in the LC make > sure to tell me so I can fix it). RFC2510 is moved to be a normative reference in s8.1. > 12) s3.6: r/pop/POP This was taken directly from RFC4210 but is now anyway removed completely=20 (see 13). > 13) s3.6: Are you saying that the request is directed to something like > POST cmp/0 or POST http://example.com/cmp/0 HTTP/1.1 for initialization > requests (i.e., the ASN.1 tag indicates the directory)?' The list of PKIMessages including the Introduction (from "The following=20 list ...") is removed completely. It had been overlooked before that this list of Messages which can be used by a client initiating the interaction with a server was forgotten to be removed in an earlier version of the=20 draft and - now orphaned - only creates confusion. The initially intended=20 information is in RFC4210 and therefore redundant. > 14) s3.7: r/No request message for is specified,/No request message is > specified, The whole sentence was changed to: As no request messages are specified for those announcements they can only=20 be pushed to the recipient. > 15) s3.7: r/ASN.1 encoded structures/PKIMessage structures Done. > 16) s6: Why isn't this part of s5? Are you trying to say that there's > no confidential information included in a PKIMessage and if there you > ought to use HTTPS? Done, added as list item 4 in s5. Also the following was changed in security considerations: To be more general in the introduction as needed: OLD: "... need to be considered by server side implementers"=20 NEW: "... need to be considered by implementers and users" --> added "... to an HTTP server" in list item 1. to clarify *where* the resources might be exhausted. In list item 2.: "(unless tunneled via TLS)" was removed as mentioning this doesn't seem to add any real value. > PS Based on these comments I've placed the document in the following > state: AD Evaluation::Revised ID Needed. Thank you Sean, your comments are more than valuable! Please feel free to keep the document in this state as long as you can spot anything you'd=20 like to see improved! Kind regards, Martin From tgindin@us.ibm.com Wed Feb 15 19:37:10 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8ECE21F85B6 for ; Wed, 15 Feb 2012 19:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.117 X-Spam-Level: X-Spam-Status: No, score=-8.117 tagged_above=-999 required=5 tests=[AWL=2.482, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvBIdjBZW+TX for ; Wed, 15 Feb 2012 19:37:07 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id EC72D21F858F for ; Wed, 15 Feb 2012 19:37:06 -0800 (PST) Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 15 Feb 2012 20:37:06 -0700 Received: from d01dlp03.pok.ibm.com (9.56.224.17) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 15 Feb 2012 20:37:04 -0700 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 46B10C9004D for ; Wed, 15 Feb 2012 22:37:03 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1G3b3C63006464 for ; Wed, 15 Feb 2012 22:37:03 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1G3b2ec028134 for ; Wed, 15 Feb 2012 22:37:02 -0500 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q1G3b25f028131 for ; Wed, 15 Feb 2012 22:37:02 -0500 In-Reply-To: <201202150011.q1F0BApg024784@fs4113.wdf.sap.corp> References: from "Erwann Abalea" at Jan 24, 12 10:33:16 pm <201202150011.q1F0BApg024784@fs4113.wdf.sap.corp> To: mrex@sap.com MIME-Version: 1.0 X-KeepSent: 0156276B:04A7A67E-852579A5:000CD62D; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Wed, 15 Feb 2012 22:37:02 -0500 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 02/15/2012 22:37:02, Serialize complete at 02/15/2012 22:37:02 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12021603-3270-0000-0000-0000040F4C4D Cc: pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 03:37:11 -0000 Martin: I think you're misreading that sentence. One of the examples in RFC 5280 section 5 is "a set of certificates based on arbitrary local information, such as 'all certificates issued to the NIST employees located in Boulder'", which cannot be done if the scope criteria is limited to certificate type or reason code. There was a lot of discussion about this extension and possible alternatives in April '98 (see http://www.ietf.org/mail-archive/web/pkix/current/msg22720.html). One of the alternative proposals described some of the reasoning as follows: CRL partitioning involves two functions: (a) a CRL location function, which allows for a certificate-using system to find a CRL applicable to a given certificate; (b) a certificate-CRL validation function, which provides for the certificate-using system to confirm that a CRL to hand is indeed an applicable CRL for the certificate under consideration. The CDP mechanism merged these two functions into one mechanism. In contrast, the OpenCDP mechanism separates these two functions and thereby achieves various benefits. It's clear that you don't need function b) if there is a CRL containing all certificates for the specified issuer. So CRL DP has always enabled partitioning, and the broken piece is not a PKI which uses partitioning but rather a general-purpose RP library which cannot support such partitioning. Tom Gindin P.S. - The opinions above are mine, and not necessarily those of my employer From: Martin Rex To: eabalea@gmail.com (Erwann Abalea), Cc: pkix@ietf.org Date: 02/14/2012 07:12 PM Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Sent by: pkix-bounces@ietf.org Erwann Abalea wrote: > > "Martin Rex": > > > > Santosh Chokhani wrote: > > > > > > Originally, CRL DP was designed to partition the CRL. > > > If CRL DP is not included in a certificate, that certificate > > > cannot go in a partition. > > > > > > When you ignore a critical IDP extension in CRL, you are insecure. > > This point is important. > > If you ignore a *critical* extension, then you fail. Completely. You're > free to ignore any non critical extension (at least in X.509, not RFC5280), > but if you encounter a critical extension that you don't understand, you > MUST reject the object. I would agree to criticality of X.509 certificate(!) extensions, but I believe that the expectations are unjusitified with respect to criticial CRL extensions (and entirely misled about criticial CRLEntryExtensions) The default configuration for CRL checking, similar to OCSP checking is to *not* hard-fail. Sticking one's head in the sand about this is not going to change reality. >From the definition of the IssuingDistributionPoint CRL Extension: http://tools.ietf.org/html/rfc5280#section-5.2.5 5.2.5. Issuing Distribution Point The issuing distribution point is a critical CRL extension that identifies the CRL distribution point and scope for a particular CRL, and it indicates whether the CRL covers revocation for end entity certificates only, CA certificates only, attribute certificates only, or a limited set of reason codes. Although the extension is critical, conforming implementations are not required to support this extension. However, implementations that do not support this extension MUST either treat the status of any certificate not listed on this CRL as unknown or locate another CRL that does not contain any unrecognized critical extensions. Scoping of the CRL by the Distribution Point, rather than by "entity certificates ony, CA certificates only, attributes certificates only or a limited set of reason codes" goes beyond the specified design goals, so don't be surprised if it breaks. The wording of the last sentences is particularly confusing: However, implementations that do not support this extension MUST either treat the status of any certificate not listed on this CRL as unknown or locate another CRL that does not contain any unrecognized critical extensions. "unknown" is not a status known to the CRL Validation algorithm in section 6.2. And while our implementation (the software module above the ASN.1 parser) does not "support this extension", the ASN.1 parser of our implementation *DOES* recognize it. > > > If someone fubars his PKI so badly, so that there is no > > CRL DP with full scope listed in his certs, or that the CRL > > returned from that URL is unusable for the promised purpose, > > then for our RP the customer will have to manually configure a download > > URL for that issuerName so that our CRL cache can populated/updated > > out-of-band with conforming CRLs ... or disable revocation checking > > for that issuerName. > > Would you trust such a CA? That question does not apply to us. We do not ship a single CA as pretrusted with out implementation, our customers have to configure *each* CA that they want to trust explicitly. And because of buggy PKI software and non-conforming CAs, there is a non-marginal amount of non-conformance that your PKI software has to tolerate. Keep in mind that rfc5280 is VERY explicit about being liberal about conformance during certificate path validation: http://tools.ietf.org/html/rfc5280#page-72 Therefore, the algorithm only includes checks to verify that the certification path is valid according to X.509 and does not include checks to verify that the certificates and CRLs conform to this profile. While the algorithm could be extended to include checks for conformance to the profiles in Sections 4 and 5, this profile RECOMMENDS against including such checks. So rfc5280 explicitly RECOMMENDS against including conformance checks from Section 5 of rfc5280, and that includes 5.2.5 Issuing Distribution Point above! So one may claim conformance to PKIX rfc5280 in spite of ignoring conformance checks from Sections 4 & 5 of rfc5280. That is what it says. -Martin _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From internet-drafts@ietf.org Thu Feb 16 00:33:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1D921F8531; Thu, 16 Feb 2012 00:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dexUJPsDJzwj; Thu, 16 Feb 2012 00:33:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570F321F862A; Thu, 16 Feb 2012 00:33:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120216083340.22418.44948.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2012 00:33:40 -0800 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-cmp-transport-protocols-16.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 08:33:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : Internet X.509 Public Key Infrastructure -- HTTP Transpo= rt for CMP Author(s) : Tomi Kause Martin Peylo Filename : draft-ietf-pkix-cmp-transport-protocols-16.txt Pages : 14 Date : 2012-02-15 This document describes how to layer the Certificate Management Protocol over HTTP. It is the "CMPtrans" document referenced in RFC 4210 and therefore updates the reference given therein. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols= -16.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-= 16.txt From DPKemp@missi.ncsc.mil Thu Feb 16 06:14:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B9421F8697 for ; Thu, 16 Feb 2012 06:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbkuI3hNMUeT for ; Thu, 16 Feb 2012 06:14:36 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 11BD521F85FD for ; Thu, 16 Feb 2012 06:14:35 -0800 (PST) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q1GEEZDk083885 for ; Thu, 16 Feb 2012 09:14:35 -0500 (EST) Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 09:15:43 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 16 Feb 2012 09:14:35 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Thread-Index: AczsXEzdpgKVenj9T8iDU05bDcf11wAVnFrQ References: from"Erwann Abalea" at Jan 24, 12 10:33:16 pm <201202150011.q1F0BApg024784@fs4113.wdf.sap.corp> From: "Kemp, David P." To: X-OriginalArrivalTime: 16 Feb 2012 14:15:43.0140 (UTC) FILETIME=[77E16E40:01CCECB5] Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 14:14:40 -0000 To reinforce Tom's point, Section 5.2.5 says: identifies the CRL distribution point and scope for a particular CRL, **and** it indicates whether the CRL covers revocation for end entity certificates only, CA certificates only, attribute certificates only, or a limited set of reason codes. (emphasis added). It doesn't say identifies scope **by** indicating reason code; IDP allows partitioning by local scope **in addition to** reason code. CAs with large subscriber populations benefit from limiting the size of CRLs to subsets of the population - in many cases it is better to have 1000 small CRLs covering 1000 subscribers each than a single gigantic CRL covering 1,000,000 subscribers, because the RP's download overhead is 1000 times less when validating a single certificate. An implementation (above the ASN.1 parser) that does not correctly support IDP will fail (not be suitable for use in) in any size-optimized environment. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Tom Gindin Sent: Wednesday, February 15, 2012 10:37 PM To: mrex@sap.com Cc: pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Martin: I think you're misreading that sentence. One of the examples in RFC 5280 section 5 is "a set of certificates based on arbitrary local information, such as 'all certificates issued to the NIST employees located in Boulder'", which cannot be done if the scope criteria is limited to certificate type or reason code. There was a lot of discussion about this extension and possible alternatives in April '98 (see http://www.ietf.org/mail-archive/web/pkix/current/msg22720.html). One of the alternative proposals described some of the reasoning as follows: CRL partitioning involves two functions: (a) a CRL location function, which allows for a certificate-using system to find a CRL applicable to a given certificate; (b) a certificate-CRL validation function, which provides for the certificate-using system to confirm that a CRL to hand is indeed an applicable CRL for the certificate under consideration. The CDP mechanism merged these two functions into one mechanism. In contrast, the OpenCDP mechanism separates these two functions and thereby achieves various benefits.=20 It's clear that you don't need function b) if there is a CRL containing all certificates for the specified issuer. So CRL DP has always enabled partitioning, and the broken piece is not a PKI which uses partitioning but rather a general-purpose RP library which cannot support such partitioning. Tom Gindin P.S. - The opinions above are mine, and not necessarily those of my employer From: Martin Rex To: eabalea@gmail.com (Erwann Abalea),=20 Cc: pkix@ietf.org Date: 02/14/2012 07:12 PM Subject: Re: [pkix] AuthKeyId and=20 CrlEntryExtension.CertificateIssuer Sent by: pkix-bounces@ietf.org Erwann Abalea wrote: >=20 > "Martin Rex": > > > > Santosh Chokhani wrote: > > > > > > Originally, CRL DP was designed to partition the CRL. > > > If CRL DP is not included in a certificate, that certificate > > > cannot go in a partition. > > > > > > When you ignore a critical IDP extension in CRL, you are insecure. >=20 > This point is important. > > If you ignore a *critical* extension, then you fail. Completely. You're > free to ignore any non critical extension (at least in X.509, not=20 RFC5280), > but if you encounter a critical extension that you don't understand, you > MUST reject the object. I would agree to criticality of X.509 certificate(!) extensions, but I believe that the expectations are unjusitified with respect to criticial CRL extensions (and entirely misled about criticial CRLEntryExtensions) The default configuration for CRL checking, similar to OCSP checking is to *not* hard-fail. Sticking one's head in the sand about this is not going to change reality. >From the definition of the IssuingDistributionPoint CRL Extension: http://tools.ietf.org/html/rfc5280#section-5.2.5 5.2.5. Issuing Distribution Point The issuing distribution point is a critical CRL extension that identifies the CRL distribution point and scope for a particular CRL, and it indicates whether the CRL covers revocation for end entity certificates only, CA certificates only, attribute certificates only, or a limited set of reason codes. Although the extension is critical, conforming implementations are not required to support this extension. However, implementations that do not support this extension MUST either treat the status of any certificate not listed on this CRL as unknown or locate another CRL that does not contain any unrecognized critical extensions. Scoping of the CRL by the Distribution Point, rather than by "entity certificates ony, CA certificates only, attributes certificates=20 only or a limited set of reason codes" goes beyond the specified design goals, so don't be surprised if it breaks. The wording of the last sentences is particularly confusing: However, implementations that do not support this extension MUST either treat the status of any certificate not listed on this CRL as unknown or locate another CRL that does not contain any unrecognized critical extensions. "unknown" is not a status known to the CRL Validation algorithm in section 6.2. And while our implementation (the software module above the ASN.1 parser) does not "support this extension", the ASN.1 parser of our implementation *DOES* recognize it.=20 >=20 > > If someone fubars his PKI so badly, so that there is no > > CRL DP with full scope listed in his certs, or that the CRL > > returned from that URL is unusable for the promised purpose, > > then for our RP the customer will have to manually configure a=20 download > > URL for that issuerName so that our CRL cache can populated/updated > > out-of-band with conforming CRLs ... or disable revocation checking > > for that issuerName. >=20 > Would you trust such a CA? That question does not apply to us. We do not ship a single CA as pretrusted with out implementation, our customers have to configure *each* CA that they want to trust explicitly. And because of buggy PKI software and non-conforming CAs, there is a non-marginal amount of non-conformance that your PKI software has to tolerate. Keep in mind that rfc5280 is VERY explicit about being liberal about conformance during certificate path validation: http://tools.ietf.org/html/rfc5280#page-72 Therefore, the algorithm only includes checks to verify that the certification path is valid according to X.509 and does not include checks to verify that the certificates and CRLs conform to this profile. While the algorithm could be extended to include checks for conformance to the profiles in Sections 4 and 5, this profile RECOMMENDS against including such checks. So rfc5280 explicitly RECOMMENDS against including conformance checks from Section 5 of rfc5280, and that includes 5.2.5 Issuing Distribution=20 Point above! So one may claim conformance to PKIX rfc5280 in spite of ignoring conformance checks from Sections 4 & 5 of rfc5280. That is what it says.=20 -Martin _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From tomas@primekey.se Thu Feb 16 07:00:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4852321F876F for ; Thu, 16 Feb 2012 07:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qog4SP45C3m for ; Thu, 16 Feb 2012 07:00:02 -0800 (PST) Received: from mail.primekey.se (mail.primekey.se [213.179.18.11]) by ietfa.amsl.com (Postfix) with ESMTP id BB80D21F86AB for ; Thu, 16 Feb 2012 07:00:01 -0800 (PST) Received: from mail.primekey.se (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id 498FCE253F for ; Thu, 16 Feb 2012 16:00:02 +0100 (CET) Received: from [192.168.3.115] (unknown [193.12.106.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.se (Postfix) with ESMTPSA id 31849E253E for ; Thu, 16 Feb 2012 16:00:02 +0100 (CET) Message-ID: <4F3D19ED.9080406@primekey.se> Date: Thu, 16 Feb 2012 15:59:57 +0100 From: Tomas Gustavsson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: pkix@ietf.org References: from"Erwann Abalea" at Jan 24, 12 10:33:16 pm <201202150011.q1F0BApg024784@fs4113.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:00:06 -0000 Just as a funny of-topic mention. A CRL with 10M revoked entries is about 400-500MB large. Very useful :-) Cheers, Tomas On 02/16/2012 03:14 PM, Kemp, David P. wrote: > To reinforce Tom's point, Section 5.2.5 says: > > identifies the CRL distribution point and scope for a particular CRL, > **and** it indicates whether the CRL covers revocation for end entity > certificates only, CA certificates only, attribute certificates only, > or a limited set of reason codes. > > (emphasis added). It doesn't say identifies scope **by** indicating > reason code; IDP allows partitioning by local scope **in addition to** > reason code. > > CAs with large subscriber populations benefit from limiting the size of > CRLs to subsets of the population - in many cases it is better to have > 1000 small CRLs covering 1000 subscribers each than a single gigantic > CRL covering 1,000,000 subscribers, because the RP's download overhead > is 1000 times less when validating a single certificate. An > implementation (above the ASN.1 parser) that does not correctly support > IDP will fail (not be suitable for use in) in any size-optimized > environment. > > Dave > > > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Tom Gindin > Sent: Wednesday, February 15, 2012 10:37 PM > To: mrex@sap.com > Cc: pkix@ietf.org > Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer > > > Martin: > > I think you're misreading that sentence. One of the examples in > RFC 5280 section 5 is "a set of certificates based on arbitrary local > information, such as 'all certificates issued to the NIST employees > located in Boulder'", which cannot be done if the scope criteria is > limited to certificate type or reason code. > There was a lot of discussion about this extension and possible > alternatives in April '98 (see > http://www.ietf.org/mail-archive/web/pkix/current/msg22720.html). One > of the alternative proposals described some of the reasoning as follows: > CRL partitioning involves two functions: > > (a) a CRL location function, which allows for a certificate-using > system to find a CRL applicable to a given certificate; > (b) a certificate-CRL validation function, which provides for the > certificate-using system to confirm that a CRL to hand is indeed an > applicable CRL for the certificate under consideration. > > The CDP mechanism merged these two functions into one mechanism. In > contrast, the OpenCDP mechanism separates these two functions and > thereby achieves various benefits. > It's clear that you don't need function b) if there is a CRL > containing all certificates for the specified issuer. So CRL DP has > always enabled partitioning, and the broken piece is not a PKI which > uses partitioning but rather a general-purpose RP library which cannot > support such partitioning. > > Tom Gindin > P.S. - The opinions above are mine, and not necessarily those of my > employer > > > > > From: Martin Rex > To: eabalea@gmail.com (Erwann Abalea), > Cc: pkix@ietf.org > Date: 02/14/2012 07:12 PM > Subject: Re: [pkix] AuthKeyId and > CrlEntryExtension.CertificateIssuer > Sent by: pkix-bounces@ietf.org > > > > Erwann Abalea wrote: >> >> "Martin Rex": >>> >>> Santosh Chokhani wrote: >>>> >>>> Originally, CRL DP was designed to partition the CRL. >>>> If CRL DP is not included in a certificate, that certificate >>>> cannot go in a partition. >>>> >>>> When you ignore a critical IDP extension in CRL, you are insecure. >> >> This point is important. >> >> If you ignore a *critical* extension, then you fail. Completely. > You're >> free to ignore any non critical extension (at least in X.509, not > RFC5280), >> but if you encounter a critical extension that you don't understand, > you >> MUST reject the object. > > > I would agree to criticality of X.509 certificate(!) extensions, > but I believe that the expectations are unjusitified with respect > to criticial CRL extensions (and entirely misled about criticial > CRLEntryExtensions) > > The default configuration for CRL checking, similar to OCSP checking > is to *not* hard-fail. Sticking one's head in the sand about this > is not going to change reality. > > From the definition of the IssuingDistributionPoint CRL Extension: > > http://tools.ietf.org/html/rfc5280#section-5.2.5 > > 5.2.5. Issuing Distribution Point > > The issuing distribution point is a critical CRL extension that > identifies the CRL distribution point and scope for a particular CRL, > and it indicates whether the CRL covers revocation for end entity > certificates only, CA certificates only, attribute certificates only, > or a limited set of reason codes. Although the extension is > critical, conforming implementations are not required to support this > extension. However, implementations that do not support this > extension MUST either treat the status of any certificate not listed > on this CRL as unknown or locate another CRL that does not contain > any unrecognized critical extensions. > > > Scoping of the CRL by the Distribution Point, rather than by > "entity certificates ony, CA certificates only, attributes certificates > only > or a limited set of reason codes" goes beyond the specified design > goals, > so don't be surprised if it breaks. > > The wording of the last sentences is particularly confusing: > > However, implementations that do not support this > extension MUST either treat the status of any certificate not listed > on this CRL as unknown or locate another CRL that does not contain > any unrecognized critical extensions. > > "unknown" is not a status known to the CRL Validation algorithm in > section 6.2. And while our implementation (the software module above > the > ASN.1 parser) does not "support this extension", the ASN.1 parser of our > implementation *DOES* recognize it. > > >> >>> If someone fubars his PKI so badly, so that there is no >>> CRL DP with full scope listed in his certs, or that the CRL >>> returned from that URL is unusable for the promised purpose, >>> then for our RP the customer will have to manually configure a > download >>> URL for that issuerName so that our CRL cache can populated/updated >>> out-of-band with conforming CRLs ... or disable revocation checking >>> for that issuerName. >> >> Would you trust such a CA? > > That question does not apply to us. > > We do not ship a single CA as pretrusted with out implementation, > our customers have to configure *each* CA that they want to trust > explicitly. And because of buggy PKI software and non-conforming CAs, > there is a non-marginal amount of non-conformance that your PKI > software has to tolerate. > > Keep in mind that rfc5280 is VERY explicit about being liberal > about conformance during certificate path validation: > > http://tools.ietf.org/html/rfc5280#page-72 > > Therefore, the algorithm only includes checks to verify that the > certification path is valid according to X.509 and does not include > checks to verify that the certificates and CRLs conform to this > profile. While the algorithm could be extended to include checks for > conformance to the profiles in Sections 4 and 5, this profile > RECOMMENDS against including such checks. > > So rfc5280 explicitly RECOMMENDS against including conformance checks > from Section 5 of rfc5280, and that includes 5.2.5 Issuing Distribution > Point > above! > > > So one may claim conformance to PKIX rfc5280 in spite of ignoring > conformance checks from Sections 4 & 5 of rfc5280. That is what it > says. > > > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Thu Feb 16 07:54:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0576A21F864D for ; Thu, 16 Feb 2012 07:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.135 X-Spam-Level: X-Spam-Status: No, score=-10.135 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-D1-Ot1a3JE for ; Thu, 16 Feb 2012 07:54:33 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id D01C321F86C3 for ; Thu, 16 Feb 2012 07:54:30 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q1GFsSMe015160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Feb 2012 16:54:28 +0100 (MET) From: Martin Rex Message-Id: <201202161554.q1GFsSQK009096@fs4113.wdf.sap.corp> To: DPKemp@missi.ncsc.mil (Kemp David P.) Date: Thu, 16 Feb 2012 16:54:28 +0100 (MET) In-Reply-To: from "Kemp, David P." at Feb 16, 12 09:14:35 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:54:38 -0000 Kemp, David P. wrote: > > To reinforce Tom's point, Section 5.2.5 says: > > identifies the CRL distribution point and scope for a particular CRL, > **and** it indicates whether the CRL covers revocation for end entity > certificates only, CA certificates only, attribute certificates only, > or a limited set of reason codes. > > (emphasis added). It doesn't say identifies scope **by** indicating > reason code; IDP allows partitioning by local scope **in addition to** > reason code. I understand just the opposite. For this to mean scoping by distribution point, it must have said "identifies the CRL distribution scope for a particular CRL", but instead the distribution point and the scope are clearly seperated by an and, and the remainder of the sentence describes the details of the scoping. > > CAs with large subscriber populations benefit from limiting the size of > CRLs to subsets of the population - in many cases it is better to have > 1000 small CRLs covering 1000 subscribers each than a single gigantic > CRL covering 1,000,000 subscribers, because the RP's download overhead > is 1000 times less when validating a single certificate. An > implementation (above the ASN.1 parser) that does not correctly support > IDP will fail (not be suitable for use in) in any size-optimized > environment. Now that last sentence is just the opposite of what rfc5280 says. The final sentence of section 5 explicitly says this: Conforming applications are not required to support processing of delta CRLs, indirect CRLs, or CRLs with a scope other than all certificates issued by one CA. which means that it is PERFECTLY OK for RPs to not support partitioning of CRLs _at_all_. Presumably because the only scoping that is defined is that by certificate type and reason code, and hardly anyone actually uses that! -Martin From DPKemp@missi.ncsc.mil Thu Feb 16 11:14:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B322021E8060 for ; Thu, 16 Feb 2012 11:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raBY-30G7SWn for ; Thu, 16 Feb 2012 11:14:04 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 474FF21E805E for ; Thu, 16 Feb 2012 11:14:04 -0800 (PST) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q1GJE3M8092173 for ; Thu, 16 Feb 2012 14:14:03 -0500 (EST) Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 14:15:10 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCECDF.24DFA623" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 16 Feb 2012 14:14:02 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Thread-Index: Aczs3yTtZYgN+IsdQgeYuaTq+xR4nQ== From: "Kemp, David P." To: X-OriginalArrivalTime: 16 Feb 2012 19:15:10.0937 (UTC) FILETIME=[4D85AC90:01CCECDF] Subject: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 19:14:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCECDF.24DFA623 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That reminds me of a billboard I saw a few years back. It had only a picture of a VW Beetle with the caption: 0-60? Yes. =20 I'm sure that car conformed with all NHTSA requirements for use on public roads. I still wouldn't buy one, because I have additional wants and needs. =20 You may choose to read 5280 in any manner you wish. But we read it in the manner I described, and choose to purchase/approve/use RP products that robustly support revocation checking in a manner suitable for large-scale enterprises. =20 Dave =20 =20 =20 Martin Rex wrote: =20 > The final sentence of section 5 explicitly says this: >=20 > Conforming applications are not > required to support processing of delta CRLs, indirect CRLs, or CRLs > with a scope other than all certificates issued by one CA. >=20 > which means that it is PERFECTLY OK for RPs to not support > partitioning of CRLs _at_all_. ------_=_NextPart_001_01CCECDF.24DFA623 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That reminds me of = a billboard I saw a few years back.  It had only a picture of a VW = Beetle with the caption:

    0-60? = Yes.

 

I’m sure that = car conformed with all NHTSA requirements for use on public roads.  = I still wouldn’t buy one, because I have additional wants and = needs.

 

You may choose to = read 5280 in any manner you wish.  But we read it in the manner I = described, and choose to purchase/approve/use RP products that robustly = support revocation checking in a manner suitable for large-scale = enterprises.

 

Dave

 

 

 

Martin Rex = wrote:

 

> The final = sentence of section 5 explicitly says this:

> 

>  =    Conforming applications are = not

>  =    required to support processing of delta CRLs, indirect = CRLs, or CRLs

> =     with a scope other than all certificates issued = by one CA.

> 

> which means = that it is PERFECTLY OK for RPs to not support

> partitioning of CRLs _at_all_.

------_=_NextPart_001_01CCECDF.24DFA623-- From dbrown@certicom.com Thu Feb 16 13:16:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FDD21E8051 for ; Thu, 16 Feb 2012 13:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.782 X-Spam-Level: X-Spam-Status: No, score=-2.782 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CF81mlxvZEXM for ; Thu, 16 Feb 2012 13:16:37 -0800 (PST) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id EF56921E8078 for ; Thu, 16 Feb 2012 13:16:36 -0800 (PST) X-AuditID: 0a412830-b7fdb6d00000552a-11-4f3d7233f2de Received: from XHT107CNC.rim.net (xht107cnc.rim.net [10.65.12.217]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 18.1E.21802.3327D3F4; Thu, 16 Feb 2012 21:16:35 +0000 (GMT) Received: from XHT141CNC.rim.net (10.65.22.70) by XHT107CNC.rim.net (10.65.12.217) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 16 Feb 2012 16:16:35 -0500 Received: from XCT103CNC.rim.net (10.65.161.203) by XHT141CNC.rim.net (10.65.22.70) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 16 Feb 2012 16:16:35 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT103CNC.rim.net ([fe80::b8:d5e:26a5:f4d6%17]) with mapi id 14.01.0339.001; Thu, 16 Feb 2012 16:16:34 -0500 From: Dan Brown To: "'swilson@lockstep.com.au'" , pkix Thread-Topic: [pkix] Off topic: Preimage attack on SHA-1 Thread-Index: AQHM52NPMlxSiP+xT0yPivlzDa5RiJZADHqA Date: Thu, 16 Feb 2012 21:16:32 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF502FDDC@XMB111CNC.rim.net> References: <4F34221A.9040603@lockstep.com.au> In-Reply-To: <4F34221A.9040603@lockstep.com.au> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.252] Content-Type: multipart/related; boundary="_004_810C31990B57ED40B2062BA10D43FBF502FDDCXMB111CNCrimnet_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLJsWRmVeSWpSXmKPExsXC5chzU9e4yNbf4NNieYuLB4ssbj94zu7A 5LFkyU8mj6W9q9kDmKIaGG0S8/LySxJLUhVSUouTbZV8UtMTcxQCijLLEpMrFVwyi5NzEjNz U4uUFDJTbJVMlBQKchKTU3NT80pslRILClLzUpTsuBQwgA1QWWaeQmpecn5KZl66rZJnsL+u hYWppa6hkp0uEkj4x53x7t9KtoLJ2xkrnm2ez9LAuHwpYxcjJ4eEgIlE+8l2VghbTOLCvfVs XYxcHEICvUwS3Q0XWCCcpYwSF0+tYIJwljNKTG/aBVW2iVFi94zl7CD9bAKqEvePnmMGsUUE AiWeTvrLBGILC5hLbFgxmw0ibiFx5+xSFgjbSGLG7bNAcQ4OFqDeaed8QcK8Am4Sy95sBztP SEBP4s3G22DncQroS6yY9BVsDKOArMTus9fBxjMLiEvcejKfCeIFEYmHF0+zQdiiEi8f/2MF GS8hoCixfLsUyMnMAp2MEt1TF7BA7BKUODnzCQvELgWJK9f3sUxgFJ+FZOwsZD2zkPRAFOVK vJy4kxHC1pFYsPsTG4StLbFs4WtmGPvMgcdMmOI6Epsv7YSaoyjR1jkbahkwtP+s7GaBKTq8 fys7TNGU7ofsCxh5VzEK5mYUG5gZJucl6xVl5urlpZZsYgQnSA2DHYwT9modYhTgYFTi4X2W aesvxJpYVlyZe4hRgoNZSYQ3XwYoxJuSWFmVWpQfX1Sak1p8iDEeGAUTmaW4k/OByTuvJN7Y wIAcjpI475KVWv5CAunA1J6dmlqQWgSzgYmDU6qBceOl2b0cuZ/b2QonnuUq29DO653h3Sag 5xysb2Uw5evr8ITLYYfnHxFd4vB8ttxnRfupcR+SU0Vi9qySWHOs/f/JuduutDccFP8or3r3 Q8oHmUtJfBfEWCaIdwvrhDH2bDV3mNHzJKzu3q9l9xd1i9bMZbJQW9rku6vzLudLnfrH0T7n 7vWWKLEUZyQaajEXFScCAKMzIdfQAwAA Subject: Re: [pkix] Off topic: Preimage attack on SHA-1 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 21:16:42 -0000 --_004_810C31990B57ED40B2062BA10D43FBF502FDDCXMB111CNCrimnet_ Content-Type: multipart/alternative; boundary="_000_810C31990B57ED40B2062BA10D43FBF502FDDCXMB111CNCrimnet_" --_000_810C31990B57ED40B2062BA10D43FBF502FDDCXMB111CNCrimnet_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hi Stephen, Regarding your supplementary question: 1) You're right that the pre-image would need to meet the X.509 ToBeSig= end format, so it would depend on the nature of the pre-image attack. Any p= re-image attack on SHA-1 would require about 160 bits of flexibility in the= pre-image format (i.e. to have a large enough target pre-image space to ens= ure that pre-images of the hash value to be inverted exists). I'm not sure= how much flexibility there is in the X.509 format, but I think the serial n= umber could support a sequence of freely chosen bits, which may be a simple= enough formatting restriction to accommodate some pre-image attacks. (Altho= ugh the resulting serial number may be larger than usual, so could be viewed= as suspicious.) The public exponent in an RSA key could support 160 bits,= but the result would look suspicious. The subject name has a large amount= of flexibility, but it seems especially unlikely that an actual faster-than= -generic pre-image attack have the needed control in the pre-image. 2) The answer also depends the vulnerability of the signature algorithm= to hash pre-image attacks. The algorithms DSA and ECDSA admit existential= forgery using a hash pre-image finder, and so does RSA-PSS as specified in= PKCS#1 version 2.1 (but as far as I can tell not RSA-PSS as originally prop= ose by Bellare and Rogaway). I don't see how a hash pre-image finder suffic= es to forge an RSA-PKCS1-v1.5 signature. 3) Under generic attacks, a hash functions's pre-image resistance has a= bout the twice the security level of the collision resistance (exhaustive se= arch vs. birthday). Typically, the public key is chosen to have a security= level half that of the pre-image resistance of hash. So, normally hash pre= -image attacks are not a concern for signatures, unless they are very drasti= c improvements over exhaustive search. Best regards, Daniel Brown Research In Motion Limited [cid:image001.gif@01CCECC5.3B8B7750] From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Step= hen Wilson Sent: Thursday, February 09, 2012 2:44 PM To: pkix Subject: [pkix] Off topic: Preimage attack on SHA-1 Colleagues, Trying the PKIX list for its cryptographic expertise, I hope you don't mind: Is anyone aware of a demonstrated preimage attack (or demonstrated feasibili= ty of a practical preimage attack) on SHA-1? Is it still the case, as it wa= s when RFC4270 was published in 2005, that there is only the possibility of= Collision attack? Supplementary question: Does anyone think a preimage attack on the signature= of a PKC, even if mounted, would be a practical problem? I would have thou= ght there would be so much interference with the rest of the data structures= that the certificate would become unparseable. Cheers, Stephen Wilson Lockstep http://lockstep.com.au Lockstep Consulting provides independent specialist advice and analysis on digital identity and privacy. Lockstep Technologies develops unique new smart ID solutions that enhance privacy and prevent identity theft. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_810C31990B57ED40B2062BA10D43FBF502FDDCXMB111CNCrimnet_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Hi Stephen,

 

Regarding your supplementar= y question:

 

1) &nb= sp;    You’re right= that the pre-image would need to meet the X.509 ToBeSigend format, so it wo= uld depend on the nature of the pre-image attack.  Any pre-image attack on SHA-1 would require about 160 bits of flexibility in the pre-imag= e format (i.e. to have a large enough target pre-image space to ensure that= pre-images of the hash value to be inverted exists).  I’m not su= re how much flexibility there is in the X.509 format, but I think the serial number could support a sequence of freely ch= osen bits, which may be a simple enough formatting restriction to accommodat= e some pre-image attacks. (Although the resulting serial number may be large= r than usual, so could be viewed as suspicious.)  The public exponent in an RSA key could support 160 b= its, but the result would look suspicious.  The subject name has a larg= e amount of flexibility, but it seems especially unlikely that an actual fas= ter-than-generic pre-image attack have the needed control in the pre-image.

 

2) &nb= sp;    The answer also dep= ends the vulnerability of the signature algorithm to hash pre-image attacks.=   The algorithms DSA and ECDSA admit existential forgery using a hash pre-image finder, and so does RSA-PSS as specified in PKCS#1 v= ersion 2.1 (but as far as I can tell not RSA-PSS as originally propose by Be= llare and Rogaway).  I don’t see how a hash pre-image finder suff= ices to forge an RSA-PKCS1-v1.5 signature.

 

3) &nb= sp;    Under generic attac= ks, a hash functions’s pre-image resistance has about the twice the se= curity level of the collision resistance (exhaustive search vs. birthday).  Typically, the public key is chosen to have a security= level half that of the pre-image resistance of hash.  So, normally has= h pre-image attacks are not a concern for signatures, unless they are very d= rastic improvements over exhaustive search. 

 

Best regards,

 

Daniel Brown

Res= earch In Motion Limited

 = ;

 = ;

 

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stephen Wilson
Sent: Thursday, February 09, 2012 2:44 PM
To: pkix
Subject: [pkix] Off topic: Preimage attack on SHA-1=

 


Colleagues,

Trying the PKIX list for its cry= ptographic expertise, I hope you don't mind:

Is anyone aware of a demonstrate= d preimage attack (or demonstrated feasibility of a practical preimage attac= k) on SHA-1?  Is it still the case, as it was when RFC4270 was publishe= d in 2005, that there is only the possibility of Collision attack?

Supplementary question: Does any= one think a preimage attack on the signature of a PKC, even if mounted, woul= d be a practical problem?  I would have thought there would be so much= interference with the rest of the data structures that the certificate would become unparseable.

Cheers,


Stephen Wilson
Lockstep

http://lockstep.com.au
Lockstep Consulting provides independent specialist advice and analysis
on digital identity and privacy.  Lockstep Technologies develops unique=
new smart ID solutions that enhance privacy and prevent identity theft.

 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_810C31990B57ED40B2062BA10D43FBF502FDDCXMB111CNCrimnet_-- --_004_810C31990B57ED40B2062BA10D43FBF502FDDCXMB111CNCrimnet_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=2577; creation-date="Thu, 16 Feb 2012 21:08:33 GMT"; modification-date="Thu, 16 Feb 2012 21:08:33 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhjQAiANUAAF5bXMrJydjX1zIvMF5bW+Xl5fLx8UE9PsvKyvPy8np3eJSTkzIvL5WTlMvK ycrKybCvr4eFhk9MTV5cXJSSk6KhoEI+PoeGhmtqaXp4eOTk5KOhoa+urmxqab68vUE9PZWTk727 vHp3d2xqauTl5LCvrtjY19nY2FBNTdnY16KgoKOhoE9MTL28vK+vrvPy8WtpaTIuLzEuL11bW4iG hkI9Pr68vIiGh09NTSMfHyQgICMfICQfIP///wAAAAAAACH/C1hNUCBEYXRhWE1QPD94cGFja2V0 IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4 bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS4wLWMwNjAg NjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAgICAgICAiPiA8cmRmOlJERiB4bWxuczpy ZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8cmRmOkRl c2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFw LzEuMC8iIHhtbG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxu czpzdFJlZj0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIg eG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M1IFdpbmRvd3MiIHhtcE1NOkluc3Rh bmNlSUQ9InhtcC5paWQ6QTk5QzA5MUNFQkExMTFFMDg4OTZBOEYxNkFFRjgzRjEiIHhtcE1NOkRv Y3VtZW50SUQ9InhtcC5kaWQ6QTk5QzA5MURFQkExMTFFMDg4OTZBOEYxNkFFRjgzRjEiPiA8eG1w TU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDpBOTlDMDkxQUVCQTExMUUw ODg5NkE4RjE2QUVGODNGMSIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDpBOTlDMDkxQkVCQTEx MUUwODg5NkE4RjE2QUVGODNGMSIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6 eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/PgH//v38+/r5+Pf29fTz8vHw7+7t7Ovq6ejn5uXk 4+Lh4N/e3dzb2tnY19bV1NPS0dDPzs3My8rJyMfGxcTDwsHAv769vLu6ubi3trW0s7KxsK+urayr qqmop6alpKOioaCfnp2cm5qZmJeWlZSTkpGQj46NjIuKiYiHhoWEg4KBgH9+fXx7enl4d3Z1dHNy cXBvbm1sa2ppaGdmZWRjYmFgX15dXFtaWVhXVlVUU1JRUE9OTUxLSklIR0ZFRENCQUA/Pj08Ozo5 ODc2NTQzMjEwLy4tLCsqKSgnJiUkIyIhIB8eHRwbGhkYFxYVFBMSERAPDg0MCwoJCAcGBQQDAgEA ACH5BAAAAAAALAAAAACNACIAAAb/wJ5wSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+CweEwum89o 7oYwAQA8wgsBQOgI0vh8D6Db8XgDQn88OjwdeohmO4uLDD0Cg3+HiZRgAn6EORw9Kn08OQN3Ag8B AXdFpAgIpQ+nQyelBVsODgEJRwIItaUBDpVDBrWrGkIFugEIt3s5zDoRRZk8O54HLUMWfQ9aBn45 skY4hNLSoA2/UMyDAEQBOdLTjH8BPQY5hQZaD4UfSIv2hX925DBHSYQ0HQcgCEGxiIeEOwHG5dih gEiFaQPcABggDkMPD58ObFmgI8ekIgim6Zgz4QOzHY4oSfAEkx6jQodCEJgDYIEy/yEY3HkUYkCC tHUUpI1gp4BAjgMzSqDMYPQABoVDJvShIMTEiJ0AFLjjNwQDvCEFRBi1AMNXEQMUwN4psIEOgDYX iHigMwHfkXGLRAYoJDBHxSUHFlUgAsCPR608FguJ4AdgnwxDLhDCdNQvA3mPBkzkwaGDtJM9LhSS IQTC6NE8DgsRINrejgQQYryTEJjIgT8ikAwWx8BFj6SYDohChsDvkAQCdVRAFmIEIR0hesSY5lZz ST8CP5noscDd5nfOehT4nuAEAx06BiDo8aGQggCkKC/iWgKg+T47LFDMAPB9YgECAf0RwSc8DLHB JwM499YDtWhTDH6mDJGYedYMEf9RdJ/Ak8MNPWhQiA5CmPgHAbIkYIEfARQAHgMbBNDAdzoY4ME0 ByDAgDvK9fCCJwH9s8NSCXD0FBwCoPBHTAoQMgAIpgDwhwwc2OKODrIYMIAfBFlhQCQ7rDMEBfCQ s9kGrfUhQTGrxBgABBmAF0AGJTHgSgWjBRCBOxyVJIEyCAA0ziDP9HDRRN/0kEAfOmjzZWRCkHCi KwdMNF8Di1ggBU9h4fMheMENYeUOB7TxpSe+qKaDbCRE8FtDABnwYg40oORAMo2F6I5zCxDCwAwA fBDQDotNsOVBlTFDiz0NtrkDC4z9wYEG0/DQ4RMapCONOQ18Ep8CEjIwjQpDkPD/5Q6H8CFda+mY ly0/zcyDBGDjYNUDAZ9gJsQLLEjjKb+fMPNSQA5ssIiZPfzJQ6JCNGDPAgr4wfATHhDmh4BKYCuQ Kz1kMNEEPXQjynUHLODBAxdM5NE72R2RQkADGLUDAUNMqq+iheSwB3wo0MHTBHOQECUPYQIwkVRD VFDIi36A7ARlf+TAAAlLpLQIEQWYywMAl3wixAI8+pWAuTmgm2kOJAtxQmUUcNCIAOv9MV8PDLqS AAt+OGKWYeyUcseGMeP9x3geAuiHbFAIQEspPyURtgUUULAABqtG5oA4xIQLSAgJlGBBiPMZdJQN K3zpTgoRlHQYAdOYWfACIFDM/9HiPXAAX4AkFFDnIhA86s43JhRcBHSeDBC5GDVg0k1AKJT4hycR Jbjl1ur9yCBsec2kwyY9PNBnD2KFB94fA3wz63WbvfnAk0Os8MfFQigZ4BkCeL2ZHyMoM8H064hS ZeLTkCFA4DOG4kGpCuaKXq0jATPJlkBuloIhCOA359nBoHoQrh3AYAgV40FeijABP4gEDQaAQAMa sIAGbKBR9FiAG9jUAxcIjQIGoN0CGlWACLiBABmwVwFqxzEhpKABIMBhayiARBYijggGWAFPRmAc IYRghXfrQQmQKLW65QAO5wijGGCnA/qJ8Yz5CM8J0MjGLXxgEYxroxynwAEIwRRwjnh8ggCQIbU8 +vGPgAykIPMYBAA7 --_004_810C31990B57ED40B2062BA10D43FBF502FDDCXMB111CNCrimnet_-- From dbrown@certicom.com Thu Feb 16 14:30:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08BD121E803F for ; Thu, 16 Feb 2012 14:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.993 X-Spam-Level: X-Spam-Status: No, score=-3.993 tagged_above=-999 required=5 tests=[AWL=1.211, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H55e7IAeGbJo for ; Thu, 16 Feb 2012 14:30:56 -0800 (PST) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id E8F5621E8028 for ; Thu, 16 Feb 2012 14:30:55 -0800 (PST) X-AuditID: 0a412830-b7fdb6d00000552a-05-4f3d839fba70 Received: from XHT104CNC.rim.net (xht104cnc.rim.net [10.65.22.52]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id B5.73.21802.F938D3F4; Thu, 16 Feb 2012 22:30:55 +0000 (GMT) Received: from XHT141CNC.rim.net (10.65.22.70) by XHT104CNC.rim.net (10.65.22.52) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 16 Feb 2012 17:30:54 -0500 Received: from XCT102CNC.rim.net (10.65.161.202) by XHT141CNC.rim.net (10.65.22.70) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 16 Feb 2012 17:30:54 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.01.0339.001; Thu, 16 Feb 2012 17:30:53 -0500 From: Dan Brown To: "'swilson@lockstep.com.au'" , pkix Thread-Topic: Off-topic clarification RE: [pkix] Off topic: Preimage attack on SHA-1 Thread-Index: AQHM52NPMlxSiP+xT0yPivlzDa5RiJZADHqAgAAVXUA= Date: Thu, 16 Feb 2012 22:30:52 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF502FEA9@XMB111CNC.rim.net> References: <4F34221A.9040603@lockstep.com.au> <810C31990B57ED40B2062BA10D43FBF502FDDC@XMB111CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF502FDDC@XMB111CNC.rim.net> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.252] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIKsWRmVeSWpSXmKPExsXC5Shmoju/2dbf4PplIYuLB4ssbj94zu7A 5LFkyU8mj6W9q9kDmKIaGG0S8/LySxJLUhVSUouTbZV8UtMTcxQCijLLEpMrFVwyi5NzEjNz U4uUFDJTbJVMlBQKchKTU3NT80pslRILClLzUpTsuBQwgA1QWWaeQmpecn5KZl66rZJnsL+u hYWppa6hkp0uEkj4x53RdmUuW8EsvorvE06wNTDu4+5i5OSQEDCR6G84zA5hi0lcuLeeDcQW Euhhkpi5srKLkQvIXsIoceLIanYIZzmjxOVVx6GcrYwSa9ZfZwJpYRNQlbh/9BwziC0iECjx dNJfsLgwkH1s2ytWiHiYxO22VVC2lcTTV9fAVrMA9TYePg8W5xVwk/j+YhoLxBnZEpP3rgSL cwq4S6w/+RIsziggK7H7LMReZgFxiVtP5jNBvCAgsWTPeWYIW1Ti5eN/QL0cQLaixPLtUhDl ehI3pk5hg7C1JZYtfM0MsVZQ4uTMJ1BrFSSuXN/HMoFRYhaSDbOQtM9C0j4LSfsCRpZVjIK5 GcUGZobJecl6RZm5enmpJZsYwWlFw2AH44S9WocYBTgYlXh4jSps/YVYE8uKK3MPMUpwMCuJ 8ObLAIV4UxIrq1KL8uOLSnNSiw8xWgADaCKzFHdyPjDl5ZXEGxsYoHCUxHmXrNTyFxJIB6aw 7NTUgtQimFYmDk6pBsaNR9687HM1VzySoWo1UfNwtnrLZfWG+PDyF4s75zLcey7e/e+r7J9a jR01U49KcsiYpu4p17fKmH1aYmZF2eZfYp7Zv3Ie6+4ScP90edM+a9Fo2Wd9/fsVuEM63epn 3+3fs071Vfe5ZA2xiFmKi44/rd6fxxUe6sAY8Gxx5M2zF1U9Mw/tK1RiKc5INNRiLipOBABu b5TRRAMAAA== Subject: [pkix] Off-topic clarification RE: Off topic: Preimage attack on SHA-1 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 22:30:57 -0000 Hi, Just to clarify myself [at others' advice] when I said "Under generic attack= s", the adjective "generic" meant that to restrict consideration to attacks= that apply to all hash functions (i.e. even a random oracle). In particula= r, I definitely did ***not*** mean to say that if MD5 has only 23 bits of co= llision resistance, then it only has 46 bits of pre-image resistance. As fa= r as I know, MD5 has 128 bits of pre-image resistance. The 2^23 cost MD5 co= llision attack is not a "generic" attack, but a specific attack, so it was m= eant to excluded from that statement. To worsen things, my choice of the word "twice" could have misleadingly impl= ied a relation between the attacks. I erred on the side of brevity, to avoi= d saying "twice", I should have re-stated the cost of generic attacks in ter= ms of hash-function output length. In particular, I do not know of a way to= convert a collision attack into a pre-image attack. (There are conversions= the other way, that would be getting even more off-topic.) Sorry if I've caused any confusion. Daniel Brown Research In Motion Limited From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Dan= Brown Sent: Thursday, February 16, 2012 4:17 PM To: 'swilson@lockstep.com.au'; pkix Subject: Re: [pkix] Off topic: Preimage attack on SHA-1 3) Under generic attacks, a hash functions's pre-image resistance has about= the twice the security level of the collision resistance (exhaustive search= vs. birthday). =A0Typically, the public key is chosen to have a security le= vel half that of the pre-image resistance of hash.=A0 So, normally hash pre-= image attacks are not a concern for signatures, unless they are very drastic= improvements over exhaustive search.=A0 --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From swilson@lockstep.com.au Thu Feb 16 15:02:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37ECE21E8042 for ; Thu, 16 Feb 2012 15:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fR2qBY06ia+r for ; Thu, 16 Feb 2012 15:02:20 -0800 (PST) Received: from smtp152.iad.emailsrvr.com (smtp152.iad.emailsrvr.com [207.97.245.152]) by ietfa.amsl.com (Postfix) with ESMTP id 4189C21F87E4 for ; Thu, 16 Feb 2012 15:02:20 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp25.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id BCB5C30026A; Thu, 16 Feb 2012 18:02:19 -0500 (EST) X-Virus-Scanned: OK Received: by smtp25.relay.iad1a.emailsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTPA id 2BA75300215; Thu, 16 Feb 2012 18:02:17 -0500 (EST) Message-ID: <4F3D8AEB.1060408@lockstep.com.au> Date: Fri, 17 Feb 2012 10:02:03 +1100 From: Stephen Wilson User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Dan Brown References: <4F34221A.9040603@lockstep.com.au> <810C31990B57ED40B2062BA10D43FBF502FDDC@XMB111CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF502FDDC@XMB111CNC.rim.net> Content-Type: multipart/alternative; boundary="------------060306000400090803000704" Cc: pkix Subject: Re: [pkix] Off topic: Preimage attack on SHA-1 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: swilson@lockstep.com.au List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 23:02:25 -0000 This is a multi-part message in MIME format. --------------060306000400090803000704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Many thanks Dan for this and the subsequent clarification. Can I ask a silly question: I've assumed that in preimage attacks [where synthetic data A' is computed so that Hash(A') == Hash(A) original data A] it is not necessary for A and A' to have the same bit length. I am guessing that computing A' is a whole lot easier if you can make it as long as you like. Now, you ponder "how much flexibility there is in the X.509 format" and I it's fair to say there is a lot. You can add totally custom fields to a certificate and in general, most X.509 parsers will skip over them. So here's a thought. If A' can be longer than A, then a preimage attacker could add a nonsense field to the SHA1+RSA profile of interest, and populate that extra field with whatever data is needed to 'compensate' for tampering with data in the original body of the certificate (say the public key value). The nonsense field might be arbitrarily long and still escape the notice of the applications consuming the certificates. Cheers, Steve Wilson. On 17/02/2012 8:16 AM, Dan Brown wrote: > > Hi Stephen, > > Regarding your supplementary question: > > 1)You're right that the pre-image would need to meet the X.509 > ToBeSigend format, so it would depend on the nature of the pre-image > attack. Any pre-image attack on SHA-1 would require about 160 bits of > flexibility in the pre-image format (i.e. to have a large enough > target pre-image space to ensure that pre-images of the hash value to > be inverted exists). I'm not sure how much flexibility there is in > the X.509 format, but I think the serial number could support a > sequence of freely chosen bits, which may be a simple enough > formatting restriction to accommodate some pre-image attacks. > (Although the resulting serial number may be larger than usual, so > could be viewed as suspicious.) The public exponent in an RSA key > could support 160 bits, but the result would look suspicious. The > subject name has a large amount of flexibility, but it seems > especially unlikely that an actual faster-than-generic pre-image > attack have the needed control in the pre-image. > > 2)The answer also depends the vulnerability of the signature algorithm > to hash pre-image attacks. The algorithms DSA and ECDSA admit > existential forgery using a hash pre-image finder, and so does RSA-PSS > as specified in PKCS#1 version 2.1 (but as far as I can tell not > RSA-PSS as originally propose by Bellare and Rogaway). I don't see > how a hash pre-image finder suffices to forge an RSA-PKCS1-v1.5 signature. > > 3)Under generic attacks, a hash functions's pre-image resistance has > about the twice the security level of the collision resistance > (exhaustive search vs. birthday). Typically, the public key is chosen > to have a security level half that of the pre-image resistance of > hash. So, normally hash pre-image attacks are not a concern for > signatures, unless they are very drastic improvements over exhaustive > search. > > Best regards, > > Daniel Brown > > Research In Motion Limited > > > > *From:*pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] *On Behalf > Of *Stephen Wilson > *Sent:* Thursday, February 09, 2012 2:44 PM > *To:* pkix > *Subject:* [pkix] Off topic: Preimage attack on SHA-1 > > > Colleagues, > > Trying the PKIX list for its cryptographic expertise, I hope you don't > mind: > > Is anyone aware of a demonstrated preimage attack (or demonstrated > feasibility of a practical preimage attack) on SHA-1? Is it still the > case, as it was when RFC4270 was published in 2005, that there is only > the possibility of Collision attack? > > Supplementary question: Does anyone think a preimage attack on the > signature of a PKC, even if mounted, would be a practical problem? I > would have thought there would be so much interference with the rest > of the data structures that the certificate would become unparseable. > > Cheers, > > > Stephen Wilson > Lockstep > > http://lockstep.com.au > Lockstep Consulting provides independent specialist advice and analysis > on digital identity and privacy. Lockstep Technologies develops unique > new smart ID solutions that enhance privacy and prevent identity theft. > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute > non-public information. Any use of this information by anyone other > than the intended recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender and > delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. --------------060306000400090803000704 Content-Type: multipart/related; boundary="------------060909060702060203060200" --------------060909060702060203060200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Many thanks Dan for this and the subsequent clarification.

Can I ask a silly question: I've assumed that in preimage attacks [where synthetic data A' is computed so that Hash(A') == Hash(A) original data A] it is not necessary for A and A' to have the same bit length.  I am guessing that computing A' is a whole lot easier if you can make it as long as you like.  

Now, you ponder "how much flexibility there is in the X.509 format" and I it's fair to say there is a lot.  You can add totally custom fields to a certificate and in general, most X.509 parsers will skip over them. 

So here's a thought.  If A' can be longer than A, then a preimage attacker could add a nonsense field to the SHA1+RSA profile of interest, and populate that extra field with whatever data is needed to 'compensate' for tampering with data in the original body of the certificate (say the public key value). The nonsense field might be arbitrarily long and still escape the notice of the applications consuming the certificates.

Cheers,

Steve Wilson.



On 17/02/2012 8:16 AM, Dan Brown wrote:

Hi Stephen,

 

Regarding your supplementary question:

 

1)      You’re right that the pre-image would need to meet the X.509 ToBeSigend format, so it would depend on the nature of the pre-image attack.  Any pre-image attack on SHA-1 would require about 160 bits of flexibility in the pre-image format (i.e. to have a large enough target pre-image space to ensure that pre-images of the hash value to be inverted exists).  I’m not sure how much flexibility there is in the X.509 format, but I think the serial number could support a sequence of freely chosen bits, which may be a simple enough formatting restriction to accommodate some pre-image attacks. (Although the resulting serial number may be larger than usual, so could be viewed as suspicious.)  The public exponent in an RSA key could support 160 bits, but the result would look suspicious.  The subject name has a large amount of flexibility, but it seems especially unlikely that an actual faster-than-generic pre-image attack have the needed control in the pre-image.

 

2)      The answer also depends the vulnerability of the signature algorithm to hash pre-image attacks.  The algorithms DSA and ECDSA admit existential forgery using a hash pre-image finder, and so does RSA-PSS as specified in PKCS#1 version 2.1 (but as far as I can tell not RSA-PSS as originally propose by Bellare and Rogaway).  I don’t see how a hash pre-image finder suffices to forge an RSA-PKCS1-v1.5 signature.

 

3)      Under generic attacks, a hash functions’s pre-image resistance has about the twice the security level of the collision resistance (exhaustive search vs. birthday).  Typically, the public key is chosen to have a security level half that of the pre-image resistance of hash.  So, normally hash pre-image attacks are not a concern for signatures, unless they are very drastic improvements over exhaustive search. 

 

Best regards,

 

Daniel Brown

Research In Motion Limited

 

 

 

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stephen Wilson
Sent: Thursday, February 09, 2012 2:44 PM
To: pkix
Subject: [pkix] Off topic: Preimage attack on SHA-1

 


Colleagues,

Trying the PKIX list for its cryptographic expertise, I hope you don't mind:

Is anyone aware of a demonstrated preimage attack (or demonstrated feasibility of a practical preimage attack) on SHA-1?  Is it still the case, as it was when RFC4270 was published in 2005, that there is only the possibility of Collision attack?

Supplementary question: Does anyone think a preimage attack on the signature of a PKC, even if mounted, would be a practical problem?  I would have thought there would be so much interference with the rest of the data structures that the certificate would become unparseable.

Cheers,


Stephen Wilson
Lockstep

http://lockstep.com.au
Lockstep Consulting provides independent specialist advice and analysis
on digital identity and privacy.  Lockstep Technologies develops unique
new smart ID solutions that enhance privacy and prevent identity theft.

 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
--------------060909060702060203060200 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlhjQAiANUAAF5bXMrJydjX1zIvMF5bW+Xl5fLx8UE9PsvKyvPy8np3eJSTkzIvL5WT lMvKycrKybCvr4eFhk9MTV5cXJSSk6KhoEI+PoeGhmtqaXp4eOTk5KOhoa+urmxqab68vUE9 PZWTk727vHp3d2xqauTl5LCvrtjY19nY2FBNTdnY16KgoKOhoE9MTL28vK+vrvPy8WtpaTIu LzEuL11bW4iGhkI9Pr68vIiGh09NTSMfHyQgICMfICQfIP///wAAAAAAACH/C1hNUCBEYXRh WE1QPD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQi Pz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUg WE1QIENvcmUgNS4wLWMwNjAgNjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAgICAg ICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjIt cmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4 bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOnhtcE1NPSJodHRwOi8v bnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0iaHR0cDovL25zLmFkb2Jl LmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1wOkNyZWF0b3JUb29sPSJBZG9i ZSBQaG90b3Nob3AgQ1M1IFdpbmRvd3MiIHhtcE1NOkluc3RhbmNlSUQ9InhtcC5paWQ6QTk5 QzA5MUNFQkExMTFFMDg4OTZBOEYxNkFFRjgzRjEiIHhtcE1NOkRvY3VtZW50SUQ9InhtcC5k aWQ6QTk5QzA5MURFQkExMTFFMDg4OTZBOEYxNkFFRjgzRjEiPiA8eG1wTU06RGVyaXZlZEZy b20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDpBOTlDMDkxQUVCQTExMUUwODg5NkE4RjE2 QUVGODNGMSIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDpBOTlDMDkxQkVCQTExMUUwODg5 NkE4RjE2QUVGODNGMSIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1w bWV0YT4gPD94cGFja2V0IGVuZD0iciI/PgH//v38+/r5+Pf29fTz8vHw7+7t7Ovq6ejn5uXk 4+Lh4N/e3dzb2tnY19bV1NPS0dDPzs3My8rJyMfGxcTDwsHAv769vLu6ubi3trW0s7KxsK+u rayrqqmop6alpKOioaCfnp2cm5qZmJeWlZSTkpGQj46NjIuKiYiHhoWEg4KBgH9+fXx7enl4 d3Z1dHNycXBvbm1sa2ppaGdmZWRjYmFgX15dXFtaWVhXVlVUU1JRUE9OTUxLSklIR0ZFRENC QUA/Pj08Ozo5ODc2NTQzMjEwLy4tLCsqKSgnJiUkIyIhIB8eHRwbGhkYFxYVFBMSERAPDg0M CwoJCAcGBQQDAgEAACH5BAAAAAAALAAAAACNACIAAAb/wJ5wSCwaj8ikcslsOp/QqHRKrVqv 2Kx2y+16v+CweEwum89o7oYwAQA8wgsBQOgI0vh8D6Db8XgDQn88OjwdeohmO4uLDD0Cg3+H iZRgAn6EORw9Kn08OQN3Ag8BAXdFpAgIpQ+nQyelBVsODgEJRwIItaUBDpVDBrWrGkIFugEI t3s5zDoRRZk8O54HLUMWfQ9aBn45skY4hNLSoA2/UMyDAEQBOdLTjH8BPQY5hQZaD4UfSIv2 hX925DBHSYQ0HQcgCEGxiIeEOwHG5dihgEiFaQPcABggDkMPD58ObFmgI8ekIgim6Zgz4QOz HY4oSfAEkx6jQodCEJgDYIEy/yEY3HkUYkCCtHUUpI1gp4BAjgMzSqDMYPQABoVDJvShIMTE iJ0AFLjjNwQDvCEFRBi1AMNXEQMUwN4psIEOgDYXiHigMwHfkXGLRAYoJDBHxSUHFlUgAsCP R608FguJ4AdgnwxDLhDCdNQvA3mPBkzkwaGDtJM9LhSSIQTC6NE8DgsRINrejgQQYryTEJjI gT8ikAwWx8BFj6SYDohChsDvkAQCdVRAFmIEIR0hesSY5lZzST8CP5noscDd5nfOehT4nuAE Ax06BiDo8aGQggCkKC/iWgKg+T47LFDMAPB9YgECAf0RwSc8DLHBJwM499YDtWhTDH6mDJGY edYMEf9RdJ/Ak8MNPWhQiA5CmPgHAbIkYIEfARQAHgMbBNDAdzoY4ME0ByDAgDvK9fCCJwH9 s8NSCXD0FBwCoPBHTAoQMgAIpgDwhwwc2OKODrIYMIAfBFlhQCQ7rDMEBfCQs9kGrfUhQTGr xBgABBmAF0AGJTHgSgWjBRCBOxyVJIEyCAA0ziDP9HDRRN/0kEAfOmjzZWRCkHCiKwdMNF8D i1ggBU9h4fMheMENYeUOB7TxpSe+qKaDbCRE8FtDABnwYg40oORAMo2F6I5zCxDCwAwAfBDQ DotNsOVBlTFDiz0NtrkDC4z9wYEG0/DQ4RMapCONOQ18Ep8CEjIwjQpDkPD/5Q6H8CFda+mY ly0/zcyDBGDjYNUDAZ9gJsQLLEjjKb+fMPNSQA5ssIiZPfzJQ6JCNGDPAgr4wfATHhDmh4BK YCuQKz1kMNEEPXQjynUHLODBAxdM5NE72R2RQkADGLUDAUNMqq+iheSwB3wo0MHTBHOQECUP YQIwkVRDVFDIi36A7ARlf+TAAAlLpLQIEQWYywMAl3wixAI8+pWAuTmgm2kOJAtxQmUUcNCI AOv9MV8PDLqSAAt+OGKWYeyUcseGMeP9x3geAuiHbFAIQEspPyURtgUUULAABqtG5oA4xIQL SAgJlGBBiPMZdJQNK3zpTgoRlHQYAdOYWfACIFDM/9HiPXAAX4AkFFDnIhA86s43JhRcBHSe DBC5GDVg0k1AKJT4hycRJbjl1ur9yCBsec2kwyY9PNBnD2KFB94fA3wz63WbvfnAk0Os8MfF QigZ4BkCeL2ZHyMoM8H064hSZeLTkCFA4DOG4kGpCuaKXq0jATPJlkBuloIhCOA359nBoHoQ rh3AYAgV40FeijABP4gEDQaAQAMasIAGbKBR9FiAG9jUAxcIjQIGoN0CGlWACLiBABmwVwFq xzEhpKABIMBhayiARBYijggGWAFPRmAcIYRghXfrQQmQKLW65QAO5wijGGCnA/qJ8Yz5CM8J 0MjGLXxgEYxroxynwAEIwRRwjnh8ggCQIbU8+vGPgAykIPMYBAA7 --------------060909060702060203060200-- --------------060306000400090803000704-- From mrex@sap.com Fri Feb 17 07:03:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DB121F870F for ; Fri, 17 Feb 2012 07:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.136 X-Spam-Level: X-Spam-Status: No, score=-10.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjthksKQGMU5 for ; Fri, 17 Feb 2012 07:03:52 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id BCA1C21F8572 for ; Fri, 17 Feb 2012 07:03:50 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q1HF3nQX011398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Feb 2012 16:03:49 +0100 (MET) From: Martin Rex Message-Id: <201202171503.q1HF3mvs026601@fs4113.wdf.sap.corp> To: tomas@primekey.se (Tomas Gustavsson) Date: Fri, 17 Feb 2012 16:03:48 +0100 (MET) In-Reply-To: <4F3D19ED.9080406@primekey.se> from "Tomas Gustavsson" at Feb 16, 12 03:59:57 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 15:03:52 -0000 Tomas Gustavsson wrote: > > Just as a funny of-topic mention. A CRL with 10M revoked entries is > about 400-500MB large. Very useful :-) As I indicated here: https://www.ietf.org/mail-archive/web/pkix/current/msg29842.html I strongly believe that a CA (i.e. that specific DName) should be retired when the expected growth of the CRL during the remaining lifetime of the all certs singed with that exact issuer DName exceeds a reasonable size. The US government is operating several CAs with CRLs carrying >1 million CRLEntries (1080 Millon = 22 MBytes), which is IMO far beyond a resonably sized CRL. Instead of partitioning CRLs, the CA should simply get a new CA cert issued (simply bumping a Serialnumber AVA in the subject DName of the CAs certificate would be sufficient), at which point it will automatically start with a fresh, empty CRL, and this will work nicely with *ALL* RPs. -Martin From anders.rundgren@telia.com Fri Feb 17 07:23:50 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34F421F8681 for ; Fri, 17 Feb 2012 07:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvWwqZz3bNKD for ; Fri, 17 Feb 2012 07:23:50 -0800 (PST) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 2035B21F85F3 for ; Fri, 17 Feb 2012 07:23:50 -0800 (PST) Received: from [192.168.0.200] (213.66.133.125) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4EFC380E00D54BFE; Fri, 17 Feb 2012 16:23:46 +0100 Message-ID: <4F3E70F7.9040309@telia.com> Date: Fri, 17 Feb 2012 16:23:35 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: mrex@sap.com References: <201202171503.q1HF3mvs026601@fs4113.wdf.sap.corp> In-Reply-To: <201202171503.q1HF3mvs026601@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 15:23:51 -0000 On 2012-02-17 16:03, Martin Rex wrote: > Tomas Gustavsson wrote: >> >> Just as a funny of-topic mention. A CRL with 10M revoked entries is >> about 400-500MB large. Very useful :-) > > As I indicated here: > https://www.ietf.org/mail-archive/web/pkix/current/msg29842.html > > I strongly believe that a CA (i.e. that specific DName) should be > retired when the expected growth of the CRL during the remaining > lifetime of the all certs singed with that exact issuer DName exceeds > a reasonable size. > > The US government is operating several CAs with CRLs carrying >1 million > CRLEntries (1080 Millon = 22 MBytes), which is IMO far beyond > a resonably sized CRL. > > Instead of partitioning CRLs, the CA should simply get a new CA cert > issued (simply bumping a Serialnumber AVA in the subject DName > of the CAs certificate would be sufficient), at which point > it will automatically start with a fresh, empty CRL, and this > will work nicely with *ALL* RPs. I guess you are talking about Sub-CAs here, otherwise you end up with trust-anchor distribution issues, right? Yet another alternative would be to have short-lived automatically renewed client-certificates which would keep CRLs in reasonable size. The only thing stopping this is that CAC and PIV cannot perform secure auto-renewals, at least not through PKIX protocols. Anders > > > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From dbrown@certicom.com Fri Feb 17 07:44:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED8921F877C for ; Fri, 17 Feb 2012 07:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ip0v-9nUb8Wv for ; Fri, 17 Feb 2012 07:44:18 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 77BC521F86E1 for ; Fri, 17 Feb 2012 07:44:17 -0800 (PST) X-AuditID: 0a41282f-b7f296d0000023a6-9b-4f3e75d09f31 Received: from XHT104CNC.rim.net (xht104cnc.rim.net [10.65.22.52]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id B9.B7.09126.0D57E3F4; Fri, 17 Feb 2012 15:44:16 +0000 (GMT) Received: from XCT102CNC.rim.net (10.65.161.202) by XHT104CNC.rim.net (10.65.22.52) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 17 Feb 2012 10:44:16 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.01.0339.001; Fri, 17 Feb 2012 10:44:15 -0500 From: Dan Brown To: Dan Brown , "'swilson@lockstep.com.au'" , pkix Thread-Topic: [pkix] Off-topic clarification RE: Off topic: Preimage attack on SHA-1 Thread-Index: AQHM7Yje0XTjGXaA00G++oFG2dRfOA== Date: Fri, 17 Feb 2012 15:44:14 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF503006B@XMB111CNC.rim.net> References: <4F34221A.9040603@lockstep.com.au> <810C31990B57ED40B2062BA10D43FBF502FDDC@XMB111CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF502FDDC@XMB111CNC.rim.net> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.252] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsXC5Shmonux1M7f4MEqPouLB4ssbj94zu7A 5LFkyU8mj6W9q9kDmKIaGG0S8/LySxJLUhVSUouTbZV8UtMTcxQCijLLEpMrFVwyi5NzEjNz U4uUFDJTbJVMlBQKchKTU3NT80pslRILClLzUpTsuBQwgA1QWWaeQmpecn5KZl66rZJnsL+u hYWppa6hkp0uEkj4x53xY01+QRtfxba3XxkbGBdzdzFyckgImEhsWjiZEcIWk7hwbz1bFyMX h5BAD5PEii+PmCGcZYwS/49sZ4VwtjJKPJy7lhmkhU1AVeL+0XNANgeHiECRxLKFYSBhYYFA iRtTFrFBhMMkLixUBgmLCOhJ7JxxiQkkzALU+eiTP0iYV8BNYvW5nUwgtpBAtsTkvStZQWxO AXeJ9SdfsoDYjAKyErvPXgerYRYQl7j1ZD4TxM0CEkv2nGeGsEUlXj7+xwoyXkJAUWL5dimI cj2JG1OnsEHY2kA3vmaGWCsocXLmExaItQoSV67vY5nAKD4LyYZZSNpnIWmfhaR9ASPLKkbB 3IxiAzOD5LxkvaLMXL281JJNjOC0oaG/g7Fvr9YhRgEORiUeXv88O38h1sSy4srcQ4wSHMxK IrzfcoFCvCmJlVWpRfnxRaU5qcWHGC2A4TORWYo7OR+Y0vJK4o0NDFA4SuK8i1dq+QsJpANT VHZqakFqEUwrEwenVAPjxZtGVqJb1greei70gWUb27uJ8+YKn4k69LK6qaNrRUJIkYu1ryK/ nOGPiCk+8lw3P1YseLe1fLfz+eT/t7r6VKfm2eUc5bT08p9VWrX95+JTJvdaDebOYLa8WVKQ cXCN/5FbF8/5Xb1SVc3wkNNkWqyYMV+R8sGDLfuSjnBNUItp2u9wbY+1EktxRqKhFnNRcSIA RoRW3DQDAAA= Subject: [pkix] Off-topic clarification RE: Off topic: Preimage attack on SHA-1 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 15:44:19 -0000 Hi Stephen and PKIX List, One more clarification: in the case of DSA and ECDSA, if the group size is s= ufficiently larger than the hash size, then I don't know how a pre-image att= ack on the hash could be used to forge a signature (in a public-key only att= ack, i.e. no chosen message signature queries). For example, consider, ECD= SA with P-384 and SHA-1. The conditional forgery attack (that I know of) ha= s a step where it generates a special random-like 384-bit integer for which= it needs find a SHA-1 pre-image. The step of computing this integer would= have to be iterated about 2^224 random values on average to get the 384-bit= integer small enough to be a SHA-1 output (so with the parameters this atta= ck is slower than finding the private key). (... Of course, a pre-image att= ack could be also used to find collisions, and then a chosen-message signing= query can be used to make a forgery, and one still needs to consider direct= collision attacks. So, I won't get into overall security levels ...) Best regards, Daniel Brown Research In Motion Limited Context: From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Dan= Brown Sent: Thursday, February 16, 2012 4:17 PM To: 'swilson@lockstep.com.au'; pkix Subject: Re: [pkix] Off topic: Preimage attack on SHA-1 2) The answer also depends the vulnerability of the signature algorithm to h= ash pre-image attacks.=A0 The algorithms DSA and ECDSA admit existential for= gery using a hash pre-image finder, and so does RSA-PSS as specified in PKCS= #1 version 2.1 (but as far as I can tell not RSA-PSS as originally propose b= y Bellare and Rogaway).=A0 I don't see how a hash pre-image finder suffices= to forge an RSA-PKCS1-v1.5 signature. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From hallam@gmail.com Fri Feb 17 09:32:12 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9C421E803A for ; Fri, 17 Feb 2012 09:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cd0aar82b463 for ; Fri, 17 Feb 2012 09:32:11 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC4821E8081 for ; Fri, 17 Feb 2012 09:32:10 -0800 (PST) Received: by obbwd15 with SMTP id wd15so5404780obb.31 for ; Fri, 17 Feb 2012 09:32:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5Po5XoUdQuFpUb+BUqqk1dC/UnFqbikoXMtaNhcXXCo=; b=TIqY+43o1HfrAJegDZaRM1m5ywFXzfPGivsFZctudbnbL+2HDg218QIhJOdOLp1Y38 LH+gMx0UsvFhMfhqqsLW6po2MEAld+34kvCcUt+vUB1i008Q9EbkonJJ/NEnD+vmetfy 5mI6WO406R0z5HKFzNUzGQxeZ2QR94FRDCl6o= MIME-Version: 1.0 Received: by 10.182.1.104 with SMTP id 8mr5675760obl.19.1329499930124; Fri, 17 Feb 2012 09:32:10 -0800 (PST) Received: by 10.182.75.138 with HTTP; Fri, 17 Feb 2012 09:32:09 -0800 (PST) In-Reply-To: <0laa4jhojz.fsf@wjh.hardakers.net> References: <255B9BB34FB7D647A506DC292726F6E114EBD69476@WSMSG3153V.srv.dir.telstra.com> <630E6CE0-E0FB-4AA6-A81A-67A6A566DAE9@gmail.com> <0laa4jhojz.fsf@wjh.hardakers.net> Date: Fri, 17 Feb 2012 12:32:09 -0500 Message-ID: From: Phillip Hallam-Baker To: Wes Hardaker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" Subject: Re: [pkix] draft-ietf-pkix-caa-04: looking at parent domains X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 17:32:12 -0000 The CA should keep logs of all DNS RRs that are signed using DNSSEC. So there would be a sequence of NSEC3 records showing the non existence of the intermediate nodes. It is probably more relevant if the check was happening in real time though. I'll modify the text to specify check everything unless someone objects. On Wed, Feb 15, 2012 at 2:41 PM, Wes Hardaker wrote: >>>>>> On Tue, 14 Feb 2012 18:36:33 -0500, Phillip Hallam-Baker said: > > PH> Checking all the way up would increase the work for the CA and in > PH> particular the records keeping. > > The work is trivial (we're talking seconds wall-clock, and micro-seconds > for actual CPU time considering it's really just waiting for network traf= fic). > > What's the record keeping concern of which you speak? =A0Are you saying > that it's intensive to document all the places you didn't find anything > but did check? =A0Even if you were going to packet log everything you sen= t > and received, we're still only talking about minuscule amounts of bytes. > -- > Wes Hardaker > My Pictures: =A0http://capturedonearth.com/ > My Thoughts: =A0http://pontifications.hardakers.net/ --=20 Website: http://hallambaker.com/ From tmiller@mitre.org Fri Feb 17 12:28:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117D91F0C4F for ; Fri, 17 Feb 2012 12:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zg2vhYKnDnaF for ; Fri, 17 Feb 2012 12:28:00 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 990731F0C4D for ; Fri, 17 Feb 2012 12:28:00 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6E9AB21B136C; Fri, 17 Feb 2012 15:27:59 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 544BF21B1350; Fri, 17 Feb 2012 15:27:59 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.10]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.01.0339.001; Fri, 17 Feb 2012 15:27:59 -0500 From: "Miller, Timothy J." To: "swilson@lockstep.com.au" , Dan Brown Thread-Topic: [pkix] Off topic: Preimage attack on SHA-1 Thread-Index: AQHM52NP33gbWXhQn0K+sKSVxtS72JZAZY0AgAAde4CAAQKygA== Date: Fri, 17 Feb 2012 20:27:58 +0000 Message-ID: In-Reply-To: <4F3D8AEB.1060408@lockstep.com.au> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.31.33.222] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <669797B748E3354E9D3C59336FCB53C8@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pkix Subject: Re: [pkix] Off topic: Preimage attack on SHA-1 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 20:28:02 -0000 Arjen Lenstra and Benne de Weger's work with MD5 may be of interest to you. Not a preimage attack, but the method of integrating a collision into X.509 may be relevant. http://www.win.tue.nl/~bdeweger/CollidingCertificates/ -- T On 2/16/12 5:02 PM, "Stephen Wilson" wrote: > > =20 > =20 > =20 > Many thanks Dan for this and the subsequent clarification. > =20 > Can I ask a silly question: I've assumed that in preimage attacks > [where synthetic data A' is computed so that Hash(A') =3D=3D Hash(A) > original data A] it is not necessary for A and A' to have the same > bit length. I am guessing that computing A' is a whole lot easier > if you can make it as long as you like. > =20 > Now, you ponder "how much flexibility there is in the X.509 format" > and I it's fair to say there is a lot. You can add totally custom > fields to a certificate and in general, most X.509 parsers will skip > over them. =20 > =20 > So here's a thought. If A' can be longer than A, then a preimage > attacker could add a nonsense field to the SHA1+RSA profile of > interest, and populate that extra field with whatever data is needed > to 'compensate' for tampering with data in the original body of the > certificate (say the public key value). The nonsense field might be > arbitrarily long and still escape the notice of the applications > consuming the certificates. > =20 > Cheers,=20 > =20 > Steve Wilson. > =20 > =20 > =20 > On 17/02/2012 8:16 AM, Dan Brown wrote: > =20 > =20 > =20 > =20 > =20 > =20 > Hi > Stephen, > =20 > Regarding > your supplementary question: > =20 > =20 > 1) =20 > You=B9re > right that the pre-image would need to meet the X.509 > ToBeSigend format, so it would depend on the nature of the > pre-image attack. Any pre-image attack on SHA-1 would > require about 160 bits of flexibility in the pre-image > format (i.e. to have a large enough target pre-image space > to ensure that pre-images of the hash value to be inverted > exists). I=B9m not sure how much flexibility there is in the > X.509 format, but I think the serial number could support a > sequence of freely chosen bits, which may be a simple enough > formatting restriction to accommodate some pre-image > attacks. (Although the resulting serial number may be larger > than usual, so could be viewed as suspicious.) The public > exponent in an RSA key could support 160 bits, but the > result would look suspicious. The subject name has a large > amount of flexibility, but it seems especially unlikely that > an actual faster-than-generic pre-image attack have the > needed control in the pre-image. > =20 > 2) =20 > The > answer also depends the vulnerability of the signature > algorithm to hash pre-image attacks. The algorithms DSA and > ECDSA admit existential forgery using a hash pre-image > finder, and so does RSA-PSS as specified in PKCS#1 version > 2.1 (but as far as I can tell not RSA-PSS as originally > propose by Bellare and Rogaway). I don=B9t see how a hash > pre-image finder suffices to forge an RSA-PKCS1-v1.5 > signature. > =20 > 3) =20 > Under > generic attacks, a hash functions=B9s pre-image resistance has > about the twice the security level of the collision > resistance (exhaustive search vs. birthday). Typically, the > public key is chosen to have a security level half that of > the pre-image resistance of hash. So, normally hash > pre-image attacks are not a concern for signatures, unless > they are very drastic improvements over exhaustive search. > =20 > =20 > Best > regards, > =20 > =20 > =20 > =20 > =20 > =20 > Daniel > Brown > =20 > =20 > =20 > =20 > Research > In Motion Limited > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > From: > pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] > On Behalf Of Stephen Wilson > Sent: Thursday, February 09, 2012 2:44 PM > To: pkix > Subject: [pkix] Off topic: Preimage attack on > SHA-1 > =20 > =20 > =20 > =20 > Colleagues, > =20 > Trying the PKIX > list for its cryptographic expertise, I hope you don't > mind: > =20 > =20 > Is anyone aware > of a demonstrated preimage attack (or demonstrated > feasibility of a practical preimage attack) on SHA-1? > Is it still the case, as it was when RFC4270 was > published in 2005, that there is only the possibility > of Collision attack? > =20 > Supplementary > question: Does anyone think a preimage attack on the > signature of a PKC, even if mounted, would be a > practical problem? I would have thought there would > be so much interference with the rest of the data > structures that the certificate would become > unparseable. > =20 > Cheers, > =20 > =20 > =20 > Stephen Wilson > Lockstep > http://lockstep.com.au > Lockstep Consulting provides independent specialist > advice and analysis > on digital identity and privacy. Lockstep Technologies > develops unique > new smart ID solutions that enhance privacy and prevent > identity theft. > =20 > =20 > =20 > =20 > =20 > =20 > =20 >--------------------------------------------------------------------- > =20 > This transmission (including any attachments) may contain > confidential information, privileged material (including material > protected by the solicitor-client or other applicable privileges), > or constitute non-public information. Any use of this information > by anyone other than the intended recipient is prohibited. If you > have received this transmission in error, please immediately reply > to the sender and delete this information from your system. Use, > dissemination, distribution, or reproduction of this transmission > by unintended recipients is not authorized and may be unlawful. > =20 > > =20 > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From tomas@primekey.se Sat Feb 18 09:37:58 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD4C21F8575 for ; Sat, 18 Feb 2012 09:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4160bUyDoF3 for ; Sat, 18 Feb 2012 09:37:58 -0800 (PST) Received: from mail.primekey.se (mail.primekey.se [213.179.18.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0C47321F856F for ; Sat, 18 Feb 2012 09:37:57 -0800 (PST) Received: from mail.primekey.se (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id 9C887E27F9; Sat, 18 Feb 2012 18:37:58 +0100 (CET) Received: from [192.168.0.3] (c-b020e055.18-1-64736c13.cust.bredbandsbolaget.se [85.224.32.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.se (Postfix) with ESMTPSA id 5D5A9E27F8; Sat, 18 Feb 2012 18:37:58 +0100 (CET) Message-ID: <4F3FE1F1.4080001@primekey.se> Date: Sat, 18 Feb 2012 18:37:53 +0100 From: Tomas Gustavsson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120217 Thunderbird/11.0 MIME-Version: 1.0 To: mrex@sap.com References: <201202171503.q1HF3mvs026601@fs4113.wdf.sap.corp> In-Reply-To: <201202171503.q1HF3mvs026601@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 17:37:58 -0000 Hi Martin, On 02/17/2012 04:03 PM, Martin Rex wrote: > Tomas Gustavsson wrote: >> >> Just as a funny of-topic mention. A CRL with 10M revoked entries is >> about 400-500MB large. Very useful :-) > > As I indicated here: > https://www.ietf.org/mail-archive/web/pkix/current/msg29842.html > > I strongly believe that a CA (i.e. that specific DName) should be > retired when the expected growth of the CRL during the remaining > lifetime of the all certs singed with that exact issuer DName exceeds > a reasonable size. > > The US government is operating several CAs with CRLs carrying>1 million > CRLEntries (1080 Millon = 22 MBytes), which is IMO far beyond > a resonably sized CRL. > > Instead of partitioning CRLs, the CA should simply get a new CA cert > issued (simply bumping a Serialnumber AVA in the subject DName > of the CAs certificate would be sufficient), at which point > it will automatically start with a fresh, empty CRL, and this > will work nicely with *ALL* RPs. I think the logic is slightly flawed. Since CRLs needs to be maintained as long as the end entity certificates are active, all issued end entity certificates of a given CA can potentially become revoked, hence the CRL may contain all these entries. This means that any given CA is only allowed to issue as many certificates as is reasonable to have on a CRL. If you think it is 500.000, any given CA is only allowed to issue 500.000 CRLs, this seems cumbersome way beyond usability. In reality CAs can issue 10M certificates within days, I surely don't want to renew these CAs as that pace. Cheers, Tomas From tomas@primekey.se Sat Feb 18 09:39:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F72121F8575 for ; Sat, 18 Feb 2012 09:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0yjtjoPhZLu for ; Sat, 18 Feb 2012 09:39:19 -0800 (PST) Received: from mail.primekey.se (mail.primekey.se [213.179.18.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0101921F856F for ; Sat, 18 Feb 2012 09:39:19 -0800 (PST) Received: from mail.primekey.se (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id B8F64E27F9; Sat, 18 Feb 2012 18:39:21 +0100 (CET) Received: from [192.168.0.3] (c-b020e055.18-1-64736c13.cust.bredbandsbolaget.se [85.224.32.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.se (Postfix) with ESMTPSA id 81D42E27F8; Sat, 18 Feb 2012 18:39:21 +0100 (CET) Message-ID: <4F3FE245.4050706@primekey.se> Date: Sat, 18 Feb 2012 18:39:17 +0100 From: Tomas Gustavsson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120217 Thunderbird/11.0 MIME-Version: 1.0 To: mrex@sap.com References: <201202171503.q1HF3mvs026601@fs4113.wdf.sap.corp> <4F3FE1F1.4080001@primekey.se> In-Reply-To: <4F3FE1F1.4080001@primekey.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 17:39:19 -0000 On 02/18/2012 06:37 PM, Tomas Gustavsson wrote: > > Hi Martin, > > On 02/17/2012 04:03 PM, Martin Rex wrote: >> Tomas Gustavsson wrote: >>> >>> Just as a funny of-topic mention. A CRL with 10M revoked entries is >>> about 400-500MB large. Very useful :-) >> >> As I indicated here: >> https://www.ietf.org/mail-archive/web/pkix/current/msg29842.html >> >> I strongly believe that a CA (i.e. that specific DName) should be >> retired when the expected growth of the CRL during the remaining >> lifetime of the all certs singed with that exact issuer DName exceeds >> a reasonable size. >> >> The US government is operating several CAs with CRLs carrying>1 million >> CRLEntries (1080 Millon = 22 MBytes), which is IMO far beyond >> a resonably sized CRL. >> >> Instead of partitioning CRLs, the CA should simply get a new CA cert >> issued (simply bumping a Serialnumber AVA in the subject DName >> of the CAs certificate would be sufficient), at which point >> it will automatically start with a fresh, empty CRL, and this >> will work nicely with *ALL* RPs. > > I think the logic is slightly flawed. > > Since CRLs needs to be maintained as long as the end entity certificates > are active, all issued end entity certificates of a given CA can > potentially become revoked, hence the CRL may contain all these entries. > > This means that any given CA is only allowed to issue as many > certificates as is reasonable to have on a CRL. If you think it is > 500.000, any given CA is only allowed to issue 500.000 CRLs, this seems > cumbersome way beyond usability. > > In reality CAs can issue 10M certificates within days, I surely don't > want to renew these CAs as that pace. > > Cheers, > Tomas I think a better alternative is to abandon CRLs for these types of CAs and use other mechanisms, like OCSP. If appropriate for the RPs of course... As usual the number of different use cases are not bounded. /Tomas From ietf@augustcellars.com Sat Feb 18 13:47:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBC021E8017 for ; Sat, 18 Feb 2012 13:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BkZlr280FAJ for ; Sat, 18 Feb 2012 13:47:36 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id AAEA221E800F for ; Sat, 18 Feb 2012 13:47:36 -0800 (PST) Received: from Tobias (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id A69842CA13; Sat, 18 Feb 2012 13:47:31 -0800 (PST) From: "Jim Schaad" To: References: <20120103200025.6720.30648.idtracker@ietfa.amsl.com> <48EA5D1A-410E-471A-9B39-B282ADF78763@vigilsec.com> In-Reply-To: <48EA5D1A-410E-471A-9B39-B282ADF78763@vigilsec.com> Date: Sat, 18 Feb 2012 13:46:45 -0800 Message-ID: <011c01ccee86$cfe8f180$6fbad480$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011D_01CCEE43.C1C897B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+meF5ONiLscyt8pms99xtb5FKZQIpW5mBAd/s0yeVv4SckA== Content-Language: en-us Cc: 'IETF PKIX' Subject: Re: [pkix] I-D Action: draft-ietf-pkix-cmc-serverkeygeneration-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 21:47:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_011D_01CCEE43.C1C897B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sorry for the delay, I have not been keeping current with the mailing list like I should have been. The POP is envisioned to make sure that the client does have the ability to decrypt the returned key. This is explicitly stated in the document current. The POP also has a secondary benefit which was not stated because while I think it is probably there is no way to assert that it is true. The POP allows the server to have a fair degree of confidence that only the client can decrypt the returned key. This provides a strong degree of protection against the possibility that an attacker can induce the client to use their public key in the enrollment process. Doing so would result in a certificate for Alice that Alice could not use but Mallory could. The following is based on the assumption that only one entity has control of the private key. If Mallory can induce Alice to accept both a public and a private key then all bets are off on this assumption. Jim From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Russ Housley Sent: Tuesday, January 10, 2012 8:52 AM To: denis.pinkas@bull.net Cc: IETF PKIX Subject: Re: [pkix] I-D Action: draft-ietf-pkix-cmc-serverkeygeneration-00.txt Denis: 3) The security considerations section states: "POP is extremely important". However, the text placed after does not provide a rational: "However, POP here is different than in client-generated key certification requests in that the POP is necessary to prove to the server that the client has possession of the private key necessary to decrypt the server-generated private key rather than possess the private key associated with the public key in the request. If the client does not possess the private key, he will not be able to decrypt the private key and thus there is no harm. IMO, POP is unnecessary. This will lead to many simplifications on the document. I do agree that there is no exposure if the private key cannot be unwrapped (assuming the use of good algorithms and such). However, the way I read it, the authors want proof that the private key could be unwrapped and used. This seems like a good feature. Russ ------=_NextPart_000_011D_01CCEE43.C1C897B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry for the delay, I have not been keeping current with the mailing = list like I should have been.

 

The POP is envisioned to make sure that the client does have the = ability to decrypt the returned key.  This is explicitly stated in = the document current.

 

The POP also has a secondary benefit which was not stated because = while I think it is probably there is no way to assert that it is = true.  The POP allows the server to have a fair degree of = confidence that only the client can decrypt the returned key.  This = provides a strong degree of protection against the possibility that an = attacker can induce the client to use their public key in the enrollment = process.  Doing so would result in a certificate for Alice that = Alice could not use but Mallory could.

 

The following is based on the assumption that only one entity has = control of the private key.  If Mallory can induce Alice to accept = both a public and a private key then all bets are off on this = assumption.

 

Jim

 

 

From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Russ Housley
Sent: Tuesday, January 10, 2012 8:52 = AM
To: denis.pinkas@bull.net
Cc: IETF = PKIX
Subject: Re: [pkix] I-D Action: = draft-ietf-pkix-cmc-serverkeygeneration-00.txt

 

Denis:

 

3) The = security considerations section states: “POP is extremely = important”. 
  However, the text placed after does not = provide a rational: 

<= /span>  =  “However, POP here is different than in 
  =  client-generated key certification requests in that the POP = is 
  =  necessary to prove to the server that the client has possession = of 
  =  the private key necessary to decrypt the server-generated private = key 
  =  rather than possess the private key associated with the public key = in 
  =  the request. 

<= /span>If the = client does not possess the private key, he will not be able to decrypt = the private key 
and thus there is no harm. IMO, POP is = unnecessary. This will lead to many simplifications on the = document. 

 

I = do agree that there is no exposure if the private key cannot be = unwrapped (assuming the use of good algorithms and such).  However, = the way I read it, the authors want proof that the private key = could be unwrapped and used.  This seems like a good = feature.

 

Russ

 

------=_NextPart_000_011D_01CCEE43.C1C897B0-- From wwwrun@rfc-editor.org Sun Feb 19 09:35:35 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736A921F84A0 for ; Sun, 19 Feb 2012 09:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4TlL1370bHl for ; Sun, 19 Feb 2012 09:35:35 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF0621F853B for ; Sun, 19 Feb 2012 09:35:34 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 55D8272F562; Sun, 19 Feb 2012 09:30:34 -0800 (PST) To: paul.hoffman@vpnc.org, jimsch@exmsft.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20120219173034.55D8272F562@rfc-editor.org> Date: Sun, 19 Feb 2012 09:30:34 -0800 (PST) Cc: pkix@ietf.org, rfc-editor@rfc-editor.org Subject: [pkix] [Technical Errata Reported] RFC5912 (3130) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 17:35:35 -0000 The following errata report has been submitted for RFC5912, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5912&eid=3130 -------------------------------------- Type: Technical Reported by: Russ Housley Section: GLOBAL Original Text ------------- ct-foo CONTENT-TYPE ::= { FooType IDENTIFIED BY id-ct-foo } Corrected Text -------------- ct-foo CONTENT-TYPE ::= { TYPE FooType IDENTIFIED BY id-ct-foo } Notes ----- Of course, 'ct-foo', 'FooType', and 'id-ct-foo' need to be replaced as appropriate for the use of CONTENT-TYPE in RFC 5912. CONTENT-TYPE is imported from a module defined in RFC 5911, and errata 2612 makes a change to that definition. Therefore, 'TYPE' needs to be added each time a content type is defined to align with errata 2612. The definitions that need to be updated are: ct-encKeyWithID, ct-scvp-certValRequest, ct-scvp-certValResponse, ct-scvp-valPolRequest, ct-scvp-valPolResponse, ct-PKIData, and ct-PKIResponse. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5912 (draft-ietf-pkix-new-asn1-08) -------------------------------------- Title : New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) Publication Date : June 2010 Author(s) : P. Hoffman, J. Schaad Category : INFORMATIONAL Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From jimsch@nwlink.com Sun Feb 19 10:38:13 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0543C21F852E for ; Sun, 19 Feb 2012 10:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xb7-P8dqo+3N for ; Sun, 19 Feb 2012 10:38:12 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1D22D21F8531 for ; Sun, 19 Feb 2012 10:38:11 -0800 (PST) Received: from Tobias (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 44A2438EF4; Sun, 19 Feb 2012 10:38:11 -0800 (PST) From: "Jim Schaad" To: "'RFC Errata System'" , , , , , , References: <20120219173034.55D8272F562@rfc-editor.org> In-Reply-To: <20120219173034.55D8272F562@rfc-editor.org> Date: Sun, 19 Feb 2012 10:37:26 -0800 Message-ID: <016101ccef35$875806e0$960814a0$@nwlink.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH5cpJIyx0zsWDZix2glulWHmdOTJXrhapg Content-Language: en-us Cc: pkix@ietf.org Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3130) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 18:38:13 -0000 I agree that this is a correct Errata - we should have done it when errata 2612 was reported for RFC 5911 and we apparently missed it. Jim > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: Sunday, February 19, 2012 9:31 AM > To: paul.hoffman@vpnc.org; jimsch@exmsft.com; stephen.farrell@cs.tcd.ie; > turners@ieca.com; kent@bbn.com; stefan@aaa-sec.com > Cc: housley@vigilsec.com; pkix@ietf.org; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC5912 (3130) > > > The following errata report has been submitted for RFC5912, "New ASN.1 > Modules for the Public Key Infrastructure Using X.509 (PKIX)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5912&eid=3130 > > -------------------------------------- > Type: Technical > Reported by: Russ Housley > > Section: GLOBAL > > Original Text > ------------- > ct-foo CONTENT-TYPE ::= > { FooType IDENTIFIED BY id-ct-foo } > > Corrected Text > -------------- > ct-foo CONTENT-TYPE ::= > { TYPE FooType IDENTIFIED BY id-ct-foo } > > Notes > ----- > Of course, 'ct-foo', 'FooType', and 'id-ct-foo' need to be replaced as > appropriate for the use of CONTENT-TYPE in RFC 5912. CONTENT-TYPE is > imported from a module defined in RFC 5911, and errata 2612 makes a > change to that definition. Therefore, 'TYPE' needs to be added each time a > content type is defined to align with errata 2612. > > The definitions that need to be updated are: > ct-encKeyWithID, > ct-scvp-certValRequest, > ct-scvp-certValResponse, > ct-scvp-valPolRequest, > ct-scvp-valPolResponse, > ct-PKIData, and > ct-PKIResponse. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please use "Reply > All" to discuss whether it should be verified or rejected. When a decision is > reached, the verifying party (IESG) can log in to change the status and edit > the report, if necessary. > > -------------------------------------- > RFC5912 (draft-ietf-pkix-new-asn1-08) > -------------------------------------- > Title : New ASN.1 Modules for the Public Key Infrastructure Using > X.509 (PKIX) > Publication Date : June 2010 > Author(s) : P. Hoffman, J. Schaad > Category : INFORMATIONAL > Source : Public-Key Infrastructure (X.509) > Area : Security > Stream : IETF > Verifying Party : IESG From tmiller@mitre.org Mon Feb 20 06:25:04 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915A921F86CB for ; Mon, 20 Feb 2012 06:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Hx-bUTrFaGS for ; Mon, 20 Feb 2012 06:25:03 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E030521F86B2 for ; Mon, 20 Feb 2012 06:24:56 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6419E21B0807; Mon, 20 Feb 2012 09:24:56 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 500DA21B07EF; Mon, 20 Feb 2012 09:24:56 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.10]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.01.0339.001; Mon, 20 Feb 2012 09:24:56 -0500 From: "Miller, Timothy J." To: Tomas Gustavsson , "mrex@sap.com" Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Thread-Index: AQHM7YVZRzjNUj0qxkOK4lsiyUJh8pZDQNyAgAAAZICAAonDAA== Date: Mon, 20 Feb 2012 14:24:55 +0000 Message-ID: In-Reply-To: <4F3FE245.4050706@primekey.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.31.33.113] Content-Type: text/plain; charset="Windows-1252" Content-ID: <195C3C74F86EE94F9CA2ABEC7C78642D@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 14:25:04 -0000 On 2/18/12 11:39 AM, "Tomas Gustavsson" wrote: >I think a better alternative is to abandon CRLs for these types of CAs >and use other mechanisms, like OCSP. If appropriate for the RPs of >course... And since OCSP implementation is uneven and a large number of use cases involve unreliable networking, OCSP isn't really an option either. I personally have used CRL-over-FedEx[1] (once) because it was more cost effective than supporting a network in the same environment.[2] :) -- T [1] "Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway." =8BAndy Tanenbaum [2] And no, the operations guys just would not consider alternative risk mitigations that *didn't* involve revocation validation no matter how much I justified it. From mrex@sap.com Mon Feb 20 07:38:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DD721F8737 for ; Mon, 20 Feb 2012 07:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.785 X-Spam-Level: X-Spam-Status: No, score=-9.785 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v91GQlFeH0Kc for ; Mon, 20 Feb 2012 07:38:17 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 00F0621F8637 for ; Mon, 20 Feb 2012 07:38:16 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q1KFcEs0019112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Feb 2012 16:38:15 +0100 (MET) From: Martin Rex Message-Id: <201202201538.q1KFcE0J009892@fs4113.wdf.sap.corp> To: tomas@primekey.se (Tomas Gustavsson) Date: Mon, 20 Feb 2012 16:38:14 +0100 (MET) In-Reply-To: <4F3FE1F1.4080001@primekey.se> from "Tomas Gustavsson" at Feb 18, 12 06:37:53 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 15:38:22 -0000 Tomas Gustavsson wrote: > > Martin Rex wrote: > > Tomas Gustavsson wrote: > >> > >> Just as a funny of-topic mention. A CRL with 10M revoked entries is > >> about 400-500MB large. Very useful :-) > > > > As I indicated here: > > https://www.ietf.org/mail-archive/web/pkix/current/msg29842.html > > > > I strongly believe that a CA (i.e. that specific DName) should be > > retired when the expected growth of the CRL during the remaining > > lifetime of the all certs singed with that exact issuer DName exceeds > > a reasonable size. > > > > The US government is operating several CAs with CRLs carrying>1 million > > CRLEntries (1080 Millon = 22 MBytes), which is IMO far beyond > > a resonably sized CRL. > > > > Instead of partitioning CRLs, the CA should simply get a new CA cert > > issued (simply bumping a Serialnumber AVA in the subject DName > > of the CAs certificate would be sufficient), at which point > > it will automatically start with a fresh, empty CRL, and this > > will work nicely with *ALL* RPs. > > Since CRLs needs to be maintained as long as the end entity certificates > are active, all issued end entity certificates of a given CA can > potentially become revoked, hence the CRL may contain all these entries. I had that case explicitly covered above. Not a problem. Just move to a different CA cert early enough. This is not about worst case, but what should be reasonably expected, with some safety margin. > > This means that any given CA is only allowed to issue as many > certificates as is reasonable to have on a CRL. If you think it is > 500.000, any given CA is only allowed to issue 500.000 CRLs, this seems > cumbersome way beyond usability. Just the contrary. Managing risk sensibly means that you want to limit the value of any single CA keypair, so that if anything very bad happens, you don't have to nuke the entirey PKI, but only that part of it that is actually affected. Limiting the number of certs that are signed with a single CA keypair can significantly help here, and will work with every conforming RP, while only partitioning CRLs based on distribution point will not help at all, but may create interop problems with conforming RPs and makes things actually slower, because the CA MUST still provide the full CRL in addtion to the zoo of partitioned CRLs, and it is difficult to see how you can mix them in a fashion that they not intefere with each other, becaus the CRL distribution point extension of the certificate (rather than that of the CRL) does not support paritioning of CRLs based on distribution point names, only on reason codes. > > In reality CAs can issue 10M certificates within days, I surely don't > want to renew these CAs as that pace. That is not necessarily a problem, if you do not expect your CRLs to grow at the same rate (10M revocations within days). The partitioning of CRLs by distribution point is ill-conceived, no matter how you look at it. Whether a CA uses partitioning by CRL distribution point is *NOT* visible in the CRL distribution point extension of the Certificate at all! Quoting from rfc5280 Section 6.3: http://tools.ietf.org/html/rfc5280#section-6.3 This algorithm assumes that all of the needed CRLs are available in a local cache. Further, if the next update time of a CRL has passed, the algorithm assumes a mechanism to fetch a current CRL and place it in the local CRL cache. An RP with an efficient implementation of revocation checking will be using CRLs, cache the CRLs and update the CRL cache strictly out-of-band, so that a revocation check will incur a single table lookup keying on issuer&serial, and zero PK-crypto operations and zero third party network communication in-band while authenticating peers. -Martin From tmiller@mitre.org Mon Feb 20 07:41:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398E721F870A for ; Mon, 20 Feb 2012 07:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDuLV-+Em7n8 for ; Mon, 20 Feb 2012 07:41:32 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 909BD21F86FD for ; Mon, 20 Feb 2012 07:41:32 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0AB6621B0C42; Mon, 20 Feb 2012 10:41:32 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0098521B0C35; Mon, 20 Feb 2012 10:41:32 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.10]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Mon, 20 Feb 2012 10:41:31 -0500 From: "Miller, Timothy J." To: "mrex@sap.com" , Tomas Gustavsson Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Thread-Index: AQHM7+WoRzjNUj0qxkOK4lsiyUJh8pZF26iA Date: Mon, 20 Feb 2012 15:41:30 +0000 Message-ID: In-Reply-To: <201202201538.q1KFcE0J009892@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.31.33.113] Content-Type: text/plain; charset="us-ascii" Content-ID: <64AA43F4577E5E41B2790E94696984C5@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 15:41:33 -0000 On 2/20/12 9:38 AM, "Martin Rex" wrote: >I had that case explicitly covered above. Not a problem. Just move >to a different CA cert early enough. This is not about worst case, >but what should be reasonably expected, with some safety margin. You make it sound so simple. CAs don't come cheap at higher assurance levels. They are expensive to deploy and expensive to maintain. -- T From denis.pinkas@bull.net Mon Feb 20 07:53:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA9921F87A0 for ; Mon, 20 Feb 2012 07:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3r+17ouCzBzd for ; Mon, 20 Feb 2012 07:53:01 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9E30A21F860B for ; Mon, 20 Feb 2012 07:53:00 -0800 (PST) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 9501718058; Mon, 20 Feb 2012 16:52:59 +0100 (CET) In-Reply-To: <011c01ccee86$cfe8f180$6fbad480$@augustcellars.com> References: <20120103200025.6720.30648.idtracker@ietfa.amsl.com> <48EA5D1A-410E-471A-9B39-B282ADF78763@vigilsec.com> <011c01ccee86$cfe8f180$6fbad480$@augustcellars.com> To: "Jim Schaad" MIME-Version: 1.0 X-KeepSent: 49E6D532:5AE168C9-C12579AA:0053AC10; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Mon, 20 Feb 2012 16:52:59 +0100 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 20/02/2012 16:52:59, Serialize complete at 20/02/2012 16:52:59 Content-Type: multipart/alternative; boundary="=_alternative 00572778C12579AA_=" Cc: 'IETF PKIX' Subject: Re: [pkix] I-D Action: draft-ietf-pkix-cmc-serverkeygeneration-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 15:53:02 -0000 Message en plusieurs parties au format MIME --=_alternative 00572778C12579AA_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SmltLA0KDQpJIGFtIHN0aWxsIHVuY29udmluY2VkIHRoYXQgdGhpcyBwcm92aWRlcyBhIGhpZ2gg ZGVncmVlIG9mIHByb3RlY3Rpb24gYW5kIA0KdGhhdCBpdCBpcyBuZWNlc3NhcnkuDQoNCllvdSBz YWlkOg0KDQoiVGhpcyBwcm92aWRlcyBhIHN0cm9uZyBkZWdyZWUgb2YgcHJvdGVjdGlvbiBhZ2Fp bnN0IHRoZSBwb3NzaWJpbGl0eSB0aGF0IA0KYW4gYXR0YWNrZXIgDQpjYW4gaW5kdWNlIHRoZSBj bGllbnQgdG8gdXNlIHRoZWlyIHB1YmxpYyBrZXkgaW4gdGhlIGVucm9sbG1lbnQgcHJvY2VzcyIg DQoNClRoZSBwdWJsaWMga2V5IGlzIGludGVncml0eSBwcm90ZWN0ZWQgZHVyaW5nIHRoZSBleGNo YW5nZSB1c2luZyBzaGFyZWQgDQpzZWNyZXQgb3IgYSBjZXJ0aWZpZWQga2V5Lg0KIElmIGFuIGF0 dGFja2VyIGNhbiBjaGFuZ2UgdGhlIHB1YmxpYyBrZXksIHRoZW4gdGhlIHNlY3VyaXR5IGlzIGJy b2tlbi4NCg0KSWYgYW4gYXR0YWNrZXIgY2hhbmdlcyB0aGUgcHVibGljIGtleSB3aXRoIGEgcHVi bGljIGZyb20gYSBrZXkgcGFpciB0aGF0IA0KaGUga25vd3MsIHRoZW4gaW4gdGhlIHNhbWUgd2F5 IHRoZSBzZWN1cml0eSBpcyBicm9rZW4uDQpUaGlzIG1lYW5zIHRoYXQgYWRkaW5nIFBvUCBkb2Vz IG5vdCBhZGQgYW55dGhpbmcuDQoNClRvIG1ha2UgYSBwYXJhbGxlbCwgaW4gYSBUU0wgZXhjaGFu Z2UgZG8gd2UgYXNrIHRoZSB3ZWIgc2VydmVyIHRvIHByb3ZlIA0KdGhhdCBpdCBrbm93cyB0aGUg cHJpdmF0ZSBrZXkgd2hlbiBpdCBzZW5kcyBpdHMgY2VydGlmaWNhdGU/DQpUaGUgYW5zd2VyIGlz IG5vLiBTbyB3aHkgc2hvdWxkIHdlIGRvIGl0IGluIHRoYXQgY2FzZSA/DQoNClRoZSBvbmx5IHZl cnkgbGl0dGxlIGFkdmFudGFnZSB3b3VsZCBiZSA6IGlmIHRoZSBjbGllbnQgbWFrZXMgYSBtaXN0 YWtlIG9mIA0KaXRzIG93biwgdGhlbiB0aGUgc2VydmVyIHdpbGwgbm90aWNlIGl0IGltbWVkaWF0 ZWx5LCANCnJhdGhlciB0aGF0IHRoZSBjbGllbnQgb24gdGhlIG5leHQgcm91bmQuIEFkZGluZyBw cm90b2NvbCBlbGVtZW50cyBmb3IgDQp0aGF0IHNwZWNpZmljIGVycm9yIGNhc2Ugd2hpY2ggbWln aHQgb25seSBoYXBwZW4gaW4gcHJhY3RpY2UgDQpkdXJpbmcgYSBkZWJ1Z2dpbmcgcGhhc2UgaXMg bm90IHdvcnRoIHRoZSBlZmZvcnQuDQoNCk5vdywgaWYgc29tZSBwZW9wbGUgd2FudCB0byBwZXJm b3JtIHVubmVjZXNzYXJ5IGNvbXB1dGF0aW9ucyBhbmQgYWRkIA0KZWxlbWVudHMgdG8gdGhlIHBy b3RvY29sIHRoYXQgYXJlIG5vdCBzdHJpY3RseSBuZWVkZWQsIHRoYXQgaXMgZmluZSBmb3IgDQp0 aGVtLg0KDQpXaHkgc2hvdWxkIHRoZXkgaGF2ZSBhIHNpbXBsZSBwcm90b2NvbCB3aGVuIGl0IGNh biBiZSBtYWRlIG1vcmUgDQpjb21wbGljYXRlZCA/IA0KOi0pDQoNCkhvd2V2ZXIsIHRoZXNlIHBl b3BsZSBzaG91bGQgbm90IGZvcmNlIG90aGVyIHBlb3BsZSB0byBhZGQgdW5uZWNlc3NhcnkgDQpw cm90b2NvbCBlbGVtZW50cy4NCg0KRGVuaXMNCg0KDQoNCg0KRGUgOiAgICAiSmltIFNjaGFhZCIg PGlldGZAYXVndXN0Y2VsbGFycy5jb20+DQpBIDogICAgIDxkZW5pcy5waW5rYXNAYnVsbC5uZXQ+ DQpDYyA6ICAgICInSUVURiBQS0lYJyIgPHBraXhAaWV0Zi5vcmc+DQpEYXRlIDogIDE4LzAyLzIw MTIgMjM6MDgNCk9iamV0IDogUkU6IFtwa2l4XSBJLUQgQWN0aW9uOiANCmRyYWZ0LWlldGYtcGtp eC1jbWMtc2VydmVya2V5Z2VuZXJhdGlvbi0wMC50eHQNCg0KDQoNClNvcnJ5IGZvciB0aGUgZGVs YXksIEkgaGF2ZSBub3QgYmVlbiBrZWVwaW5nIGN1cnJlbnQgd2l0aCB0aGUgbWFpbGluZyBsaXN0 IA0KbGlrZSBJIHNob3VsZCBoYXZlIGJlZW4uDQogDQpUaGUgUE9QIGlzIGVudmlzaW9uZWQgdG8g bWFrZSBzdXJlIHRoYXQgdGhlIGNsaWVudCBkb2VzIGhhdmUgdGhlIGFiaWxpdHkgDQp0byBkZWNy eXB0IHRoZSByZXR1cm5lZCBrZXkuICBUaGlzIGlzIGV4cGxpY2l0bHkgc3RhdGVkIGluIHRoZSBk b2N1bWVudCANCmN1cnJlbnQuDQogDQpUaGUgUE9QIGFsc28gaGFzIGEgc2Vjb25kYXJ5IGJlbmVm aXQgd2hpY2ggd2FzIG5vdCBzdGF0ZWQgYmVjYXVzZSB3aGlsZSBJIA0KdGhpbmsgaXQgaXMgcHJv YmFibHkgdGhlcmUgaXMgbm8gd2F5IHRvIGFzc2VydCB0aGF0IGl0IGlzIHRydWUuICBUaGUgUE9Q IA0KYWxsb3dzIHRoZSBzZXJ2ZXIgdG8gaGF2ZSBhIGZhaXIgZGVncmVlIG9mIGNvbmZpZGVuY2Ug dGhhdCBvbmx5IHRoZSBjbGllbnQgDQpjYW4gZGVjcnlwdCB0aGUgcmV0dXJuZWQga2V5LiAgVGhp cyBwcm92aWRlcyBhIHN0cm9uZyBkZWdyZWUgb2YgcHJvdGVjdGlvbiANCmFnYWluc3QgdGhlIHBv c3NpYmlsaXR5IHRoYXQgYW4gYXR0YWNrZXIgY2FuIGluZHVjZSB0aGUgY2xpZW50IHRvIHVzZSAN CnRoZWlyIHB1YmxpYyBrZXkgaW4gdGhlIGVucm9sbG1lbnQgcHJvY2Vzcy4gIERvaW5nIHNvIHdv dWxkIHJlc3VsdCBpbiBhIA0KY2VydGlmaWNhdGUgZm9yIEFsaWNlIHRoYXQgQWxpY2UgY291bGQg bm90IHVzZSBidXQgTWFsbG9yeSBjb3VsZC4NCiANClRoZSBmb2xsb3dpbmcgaXMgYmFzZWQgb24g dGhlIGFzc3VtcHRpb24gdGhhdCBvbmx5IG9uZSBlbnRpdHkgaGFzIGNvbnRyb2wgDQpvZiB0aGUg cHJpdmF0ZSBrZXkuICBJZiBNYWxsb3J5IGNhbiBpbmR1Y2UgQWxpY2UgdG8gYWNjZXB0IGJvdGgg YSBwdWJsaWMgDQphbmQgYSBwcml2YXRlIGtleSB0aGVuIGFsbCBiZXRzIGFyZSBvZmYgb24gdGhp cyBhc3N1bXB0aW9uLg0KIA0KSmltDQogDQogDQpGcm9tOiBwa2l4LWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpwa2l4LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiANClJ1c3MgSG91c2xl eQ0KU2VudDogVHVlc2RheSwgSmFudWFyeSAxMCwgMjAxMiA4OjUyIEFNDQpUbzogZGVuaXMucGlu a2FzQGJ1bGwubmV0DQpDYzogSUVURiBQS0lYDQpTdWJqZWN0OiBSZTogW3BraXhdIEktRCBBY3Rp b246IA0KZHJhZnQtaWV0Zi1wa2l4LWNtYy1zZXJ2ZXJrZXlnZW5lcmF0aW9uLTAwLnR4dA0KIA0K RGVuaXM6DQogDQozKSBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBzdGF0ZXM6 IOKAnFBPUCBpcyBleHRyZW1lbHkgDQppbXBvcnRhbnTigJ0uIA0KICBIb3dldmVyLCB0aGUgdGV4 dCBwbGFjZWQgYWZ0ZXIgZG9lcyBub3QgcHJvdmlkZSBhIHJhdGlvbmFsOiANCg0KICAg4oCcSG93 ZXZlciwgUE9QIGhlcmUgaXMgZGlmZmVyZW50IHRoYW4gaW4gDQogICBjbGllbnQtZ2VuZXJhdGVk IGtleSBjZXJ0aWZpY2F0aW9uIHJlcXVlc3RzIGluIHRoYXQgdGhlIFBPUCBpcyANCiAgIG5lY2Vz c2FyeSB0byBwcm92ZSB0byB0aGUgc2VydmVyIHRoYXQgdGhlIGNsaWVudCBoYXMgcG9zc2Vzc2lv biBvZiANCiAgIHRoZSBwcml2YXRlIGtleSBuZWNlc3NhcnkgdG8gZGVjcnlwdCB0aGUgc2VydmVy LWdlbmVyYXRlZCBwcml2YXRlIGtleSANCiAgIHJhdGhlciB0aGFuIHBvc3Nlc3MgdGhlIHByaXZh dGUga2V5IGFzc29jaWF0ZWQgd2l0aCB0aGUgcHVibGljIGtleSBpbiANCiAgIHRoZSByZXF1ZXN0 LiANCg0KSWYgdGhlIGNsaWVudCBkb2VzIG5vdCBwb3NzZXNzIHRoZSBwcml2YXRlIGtleSwgaGUg d2lsbCBub3QgYmUgYWJsZSB0byANCmRlY3J5cHQgdGhlIHByaXZhdGUga2V5IA0KYW5kIHRodXMg dGhlcmUgaXMgbm8gaGFybS4gSU1PLCBQT1AgaXMgdW5uZWNlc3NhcnkuIFRoaXMgd2lsbCBsZWFk IHRvIG1hbnkgDQpzaW1wbGlmaWNhdGlvbnMgb24gdGhlIGRvY3VtZW50LiANCiANCkkgZG8gYWdy ZWUgdGhhdCB0aGVyZSBpcyBubyBleHBvc3VyZSBpZiB0aGUgcHJpdmF0ZSBrZXkgY2Fubm90IGJl IA0KdW53cmFwcGVkIChhc3N1bWluZyB0aGUgdXNlIG9mIGdvb2QgYWxnb3JpdGhtcyBhbmQgc3Vj aCkuICBIb3dldmVyLCB0aGUgDQp3YXkgSSByZWFkIGl0LCB0aGUgYXV0aG9ycyB3YW50IHByb29m IHRoYXQgdGhlIHByaXZhdGUga2V5IGNvdWxkIGJlIA0KdW53cmFwcGVkIGFuZCB1c2VkLiAgVGhp cyBzZWVtcyBsaWtlIGEgZ29vZCBmZWF0dXJlLg0KIA0KUnVzcw0KIA0KDQo= --=_alternative 00572778C12579AA_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkppbSw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYW0gc3RpbGwgdW5jb252aW5jZWQgdGhhdCB0 aGlzIHByb3ZpZGVzDQphIGhpZ2ggZGVncmVlIG9mIHByb3RlY3Rpb24gYW5kIHRoYXQgaXQgaXMg bmVjZXNzYXJ5LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+WW91IHNhaWQ6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgw IGZhY2U9IkNhbGlicmkiPiZxdW90O1RoaXMgcHJvdmlkZXMgYSBzdHJvbmcNCmRlZ3JlZSBvZiBw cm90ZWN0aW9uIGFnYWluc3QgdGhlIHBvc3NpYmlsaXR5IHRoYXQgYW4gYXR0YWNrZXIgPGJyPg0K Y2FuIGluZHVjZSB0aGUgY2xpZW50IHRvIHVzZSB0aGVpciBwdWJsaWMga2V5IGluIHRoZSBlbnJv bGxtZW50IHByb2Nlc3M8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ JnF1b3Q7DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PlRoZSBwdWJsaWMga2V5IGlzIGludGVncml0eSBwcm90ZWN0ZWQNCmR1cmluZyB0aGUgZXhjaGFu Z2UgdXNpbmcgc2hhcmVkIHNlY3JldCBvciBhIGNlcnRpZmllZCBrZXkuPGJyPg0KIElmIGFuIGF0 dGFja2VyIGNhbiBjaGFuZ2UgdGhlIHB1YmxpYyBrZXksIHRoZW4gdGhlIHNlY3VyaXR5IGlzIGJy b2tlbi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklm IGFuIGF0dGFja2VyIGNoYW5nZXMgdGhlIHB1YmxpYyBrZXkNCndpdGggYSBwdWJsaWMgZnJvbSBh IGtleSBwYWlyIHRoYXQgaGUga25vd3MsIHRoZW4gaW4gdGhlIHNhbWUgd2F5IHRoZSBzZWN1cml0 eQ0KaXMgYnJva2VuLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ VGhpcyBtZWFucyB0aGF0IGFkZGluZyBQb1AgZG9lcyBub3QNCmFkZCBhbnl0aGluZy48L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRvIG1ha2UgYSBwYXJh bGxlbCwgaW4gYSBUU0wgZXhjaGFuZ2UNCmRvIHdlIGFzayB0aGUgd2ViIHNlcnZlciB0byBwcm92 ZSB0aGF0IGl0IGtub3dzIHRoZSBwcml2YXRlIGtleSB3aGVuIGl0DQpzZW5kcyBpdHMgY2VydGlm aWNhdGU/PGJyPg0KVGhlIGFuc3dlciBpcyBuby4gU28gd2h5IHNob3VsZCB3ZSBkbyBpdCBpbiB0 aGF0IGNhc2UgPzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+VGhlIG9ubHkgdmVyeSBsaXR0bGUgYWR2YW50YWdlIHdvdWxkDQpiZSA6IGlmIHRoZSBjbGll bnQgbWFrZXMgYSBtaXN0YWtlIG9mIGl0cyBvd24sIHRoZW4gdGhlIHNlcnZlciB3aWxsIG5vdGlj ZQ0KaXQgaW1tZWRpYXRlbHksIDxicj4NCnJhdGhlciB0aGF0IHRoZSBjbGllbnQgb24gdGhlIG5l eHQgcm91bmQuIEFkZGluZyBwcm90b2NvbCBlbGVtZW50cyBmb3INCnRoYXQgc3BlY2lmaWMgZXJy b3IgY2FzZSB3aGljaCBtaWdodCBvbmx5IGhhcHBlbiBpbiBwcmFjdGljZSA8YnI+DQpkdXJpbmcg YSBkZWJ1Z2dpbmcgcGhhc2UgaXMgbm90IHdvcnRoIHRoZSBlZmZvcnQuPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Ob3csIGlmIHNvbWUgcGVvcGxlIHdh bnQgdG8gcGVyZm9ybQ0KdW5uZWNlc3NhcnkgY29tcHV0YXRpb25zIGFuZCBhZGQgZWxlbWVudHMg dG8gdGhlIHByb3RvY29sIHRoYXQgYXJlIG5vdA0Kc3RyaWN0bHkgbmVlZGVkLCB0aGF0IGlzIGZp bmUgZm9yIHRoZW0uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5XaHkgc2hvdWxkIHRoZXkgaGF2ZSBhIHNpbXBsZSBwcm90b2NvbA0Kd2hlbiBpdCBjYW4g YmUgbWFkZSBtb3JlIGNvbXBsaWNhdGVkID8gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj46LSk8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPkhvd2V2ZXIsIHRoZXNlIHBlb3BsZSBzaG91bGQgbm90IGZvcmNlDQpvdGhlciBw ZW9wbGUgdG8gYWRkIHVubmVjZXNzYXJ5IHByb3RvY29sIGVsZW1lbnRzLjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RGVuaXM8L2ZvbnQ+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fu cy1zZXJpZiI+RGUgOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7PC9mb250Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtKaW0gU2NoYWFkJnF1b3Q7DQombHQ7aWV0ZkBh dWd1c3RjZWxsYXJzLmNvbSZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVm NWYgZmFjZT0ic2Fucy1zZXJpZiI+QSA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs8L2Zv bnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtkZW5pcy5waW5rYXNAYnVsbC5u ZXQmZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMt c2VyaWYiPkNjJm5ic3A7OiAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7PC9mb250Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDsnSUVURg0KUEtJWCcmcXVvdDsgJmx0O3Br aXhAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZh Y2U9InNhbnMtc2VyaWYiPkRhdGUgOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7PC9mb250 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4xOC8wMi8yMDEyIDIzOjA4PC9mb250Pg0K PGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPk9iamV0IDog Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+UkU6IFtwa2l4XSBJLUQNCkFjdGlvbjogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ZHJhZnQtaWV0Zi1wa2l4LWNtYy1zZXJ2ZXJrZXlnZW5lcmF0aW9uLTAwLnR4dDwvZm9udD4N Cjxicj4NCjxociBub3NoYWRlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0j MDA0MDgwIGZhY2U9IkNhbGlicmkiPlNvcnJ5IGZvciB0aGUgZGVsYXksIEkgaGF2ZQ0Kbm90IGJl ZW4ga2VlcGluZyBjdXJyZW50IHdpdGggdGhlIG1haWxpbmcgbGlzdCBsaWtlIEkgc2hvdWxkIGhh dmUgYmVlbi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2Fs aWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9 IkNhbGlicmkiPlRoZSBQT1AgaXMgZW52aXNpb25lZCB0bw0KbWFrZSBzdXJlIHRoYXQgdGhlIGNs aWVudCBkb2VzIGhhdmUgdGhlIGFiaWxpdHkgdG8gZGVjcnlwdCB0aGUgcmV0dXJuZWQNCmtleS4g Jm5ic3A7VGhpcyBpcyBleHBsaWNpdGx5IHN0YXRlZCBpbiB0aGUgZG9jdW1lbnQgY3VycmVudC48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+Jm5i c3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmki PlRoZSBQT1AgYWxzbyBoYXMgYSBzZWNvbmRhcnkNCmJlbmVmaXQgd2hpY2ggd2FzIG5vdCBzdGF0 ZWQgYmVjYXVzZSB3aGlsZSBJIHRoaW5rIGl0IGlzIHByb2JhYmx5IHRoZXJlDQppcyBubyB3YXkg dG8gYXNzZXJ0IHRoYXQgaXQgaXMgdHJ1ZS4gJm5ic3A7VGhlIFBPUCBhbGxvd3MgdGhlIHNlcnZl ciB0bw0KaGF2ZSBhIGZhaXIgZGVncmVlIG9mIGNvbmZpZGVuY2UgdGhhdCBvbmx5IHRoZSBjbGll bnQgY2FuIGRlY3J5cHQgdGhlIHJldHVybmVkDQprZXkuICZuYnNwO1RoaXMgcHJvdmlkZXMgYSBz dHJvbmcgZGVncmVlIG9mIHByb3RlY3Rpb24gYWdhaW5zdCB0aGUgcG9zc2liaWxpdHkNCnRoYXQg YW4gYXR0YWNrZXIgY2FuIGluZHVjZSB0aGUgY2xpZW50IHRvIHVzZSB0aGVpciBwdWJsaWMga2V5 IGluIHRoZSBlbnJvbGxtZW50DQpwcm9jZXNzLiAmbmJzcDtEb2luZyBzbyB3b3VsZCByZXN1bHQg aW4gYSBjZXJ0aWZpY2F0ZSBmb3IgQWxpY2UgdGhhdCBBbGljZQ0KY291bGQgbm90IHVzZSBidXQg TWFsbG9yeSBjb3VsZC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFj ZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgw IGZhY2U9IkNhbGlicmkiPlRoZSBmb2xsb3dpbmcgaXMgYmFzZWQgb24NCnRoZSBhc3N1bXB0aW9u IHRoYXQgb25seSBvbmUgZW50aXR5IGhhcyBjb250cm9sIG9mIHRoZSBwcml2YXRlIGtleS4gJm5i c3A7SWYNCk1hbGxvcnkgY2FuIGluZHVjZSBBbGljZSB0byBhY2NlcHQgYm90aCBhIHB1YmxpYyBh bmQgYSBwcml2YXRlIGtleSB0aGVuDQphbGwgYmV0cyBhcmUgb2ZmIG9uIHRoaXMgYXNzdW1wdGlv bi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+ Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGli cmkiPkppbTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxp YnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0i Q2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxi PkZyb206PC9iPiBwa2l4LWJvdW5jZXNAaWV0Zi5vcmcgWzwvZm9udD48YSBocmVmPSJtYWlsdG86 cGtpeC1ib3VuY2VzQGlldGYub3JnIj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5tYWlsdG86 cGtpeC1ib3VuY2VzQGlldGYub3JnPC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21h Ij5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJ1c3MgSG91c2xleTxiPjxicj4NClNlbnQ6PC9iPiBU dWVzZGF5LCBKYW51YXJ5IDEwLCAyMDEyIDg6NTIgQU08Yj48YnI+DQpUbzo8L2I+IGRlbmlzLnBp bmthc0BidWxsLm5ldDxiPjxicj4NCkNjOjwvYj4gSUVURiBQS0lYPGI+PGJyPg0KU3ViamVjdDo8 L2I+IFJlOiBbcGtpeF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1wa2l4LWNtYy1zZXJ2ZXJrZXln ZW5lcmF0aW9uLTAwLnR4dDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+RGVuaXM6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjMp IFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uDQpzdGF0ZXM6IOKAnFBPUCBpcyBl eHRyZW1lbHkgaW1wb3J0YW504oCdLiA8YnI+DQogJm5ic3A7SG93ZXZlciwgdGhlIHRleHQgcGxh Y2VkIGFmdGVyIGRvZXMgbm90IHByb3ZpZGUgYSByYXRpb25hbDogPC9mb250Pjxmb250IHNpemU9 NCBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij48YnI+DQogJm5ic3A7IOKAnEhvd2V2ZXIsIFBPUCBoZXJlIGlzIGRpZmZlcmVudCB0 aGFuIGluPC9mb250Pjxmb250IHNpemU9NCBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiAmbmJzcDsgY2xpZW50LWdlbmVyYXRl ZCBrZXkgY2VydGlmaWNhdGlvbiByZXF1ZXN0cyBpbiB0aGF0IHRoZSBQT1AgaXM8L2ZvbnQ+PGZv bnQgc2l6ZT00IGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PGJyPg0KICZuYnNwOyBuZWNlc3NhcnkgdG8gcHJvdmUgdG8gdGhlIHNlcnZl ciB0aGF0IHRoZSBjbGllbnQgaGFzIHBvc3Nlc3Npb24NCm9mPC9mb250Pjxmb250IHNpemU9NCBm YWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ PGJyPg0KICZuYnNwOyB0aGUgcHJpdmF0ZSBrZXkgbmVjZXNzYXJ5IHRvIGRlY3J5cHQgdGhlIHNl cnZlci1nZW5lcmF0ZWQgcHJpdmF0ZQ0Ka2V5PC9mb250Pjxmb250IHNpemU9NCBmYWNlPSJzYW5z LXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KICZu YnNwOyByYXRoZXIgdGhhbiBwb3NzZXNzIHRoZSBwcml2YXRlIGtleSBhc3NvY2lhdGVkIHdpdGgg dGhlIHB1YmxpYw0Ka2V5IGluPC9mb250Pjxmb250IHNpemU9NCBmYWNlPSJzYW5zLXNlcmlmIj4g PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KICZuYnNwOyB0aGUg cmVxdWVzdC48L2ZvbnQ+PGZvbnQgc2l6ZT00IGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpJZiB0aGUgY2xpZW50IGRv ZXMgbm90IHBvc3Nlc3MgdGhlIHByaXZhdGUga2V5LCBoZSB3aWxsIG5vdCBiZSBhYmxlIHRvDQpk ZWNyeXB0IHRoZSBwcml2YXRlIGtleSA8YnI+DQphbmQgdGh1cyB0aGVyZSBpcyBubyBoYXJtLiBJ TU8sIFBPUCBpcyB1bm5lY2Vzc2FyeS4gVGhpcyB3aWxsIGxlYWQgdG8gbWFueQ0Kc2ltcGxpZmlj YXRpb25zIG9uIHRoZSBkb2N1bWVudC48L2ZvbnQ+PGZvbnQgc2l6ZT00IGZhY2U9InNhbnMtc2Vy aWYiPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5JIGRv IGFncmVlIHRoYXQgdGhlcmUgaXMgbm8gZXhwb3N1cmUNCmlmIHRoZSBwcml2YXRlIGtleSBjYW5u b3QgYmUgdW53cmFwcGVkIChhc3N1bWluZyB0aGUgdXNlIG9mIGdvb2QgYWxnb3JpdGhtcw0KYW5k IHN1Y2gpLiAmbmJzcDtIb3dldmVyLCB0aGUgd2F5IEkgcmVhZCBpdCwgdGhlIGF1dGhvcnMgd2Fu dCBwcm9vZiB0aGF0DQp0aGUgcHJpdmF0ZSBrZXkgY291bGQgYmUgdW53cmFwcGVkIGFuZCB1c2Vk LiAmbmJzcDtUaGlzIHNlZW1zIGxpa2UgYSBnb29kDQpmZWF0dXJlLjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+UnVzczwvZm9udD4NCjxicj48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+DQo= --=_alternative 00572778C12579AA_=-- From tomas@primekey.se Mon Feb 20 14:24:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1625F21E8012 for ; Mon, 20 Feb 2012 14:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-la9X3Wgq6f for ; Mon, 20 Feb 2012 14:24:37 -0800 (PST) Received: from mail.primekey.se (mail.primekey.se [213.179.18.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2C921E800C for ; Mon, 20 Feb 2012 14:24:37 -0800 (PST) Received: from mail.primekey.se (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id EA087E2AFF; Mon, 20 Feb 2012 23:24:38 +0100 (CET) Received: from [192.168.122.80] (smart150.bb.netvision.net.il [212.143.76.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.se (Postfix) with ESMTPSA id 1D525E2AFE; Mon, 20 Feb 2012 23:24:37 +0100 (CET) Message-ID: <4F42C820.7000501@primekey.se> Date: Tue, 21 Feb 2012 00:24:32 +0200 From: Tomas Gustavsson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120217 Thunderbird/11.0 MIME-Version: 1.0 To: mrex@sap.com References: <201202201538.q1KFcE0J009892@fs4113.wdf.sap.corp> In-Reply-To: <201202201538.q1KFcE0J009892@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 22:24:38 -0000 Consider this (real world) use case. 50M certificates issued in 10 days. 5M revoked. Far from easy to maintain any type of renewals under this load. IMHO it just shows that the use cases for PKI today is virtually unbounded. PKIX must (and often does) provide mechanisms to encompass a broad range of use cases. Each use case/CA/RP must select the mechanisms that are suitable. If you don't like CRL partitioning in your use case, don't use it. I have tried to avoid it so far, but are being forced to look into it now. If you don't need CRLs, but OCSP works, forget about CRLs and only use OCSP. If you want to replace your CAs every week, do it. Etc etc. Today we really need to be open minded about PKI, because it is ubiquitous in a way it has never been before, in new and improved use cases. Standards gets a bit more complex having to adapt to all these different scenarios. But that means better work for us PKI geeks :-) Seriously it is hard to (currently) see many alternatives to the complexity of this infrastructure. cheers, Tomas On 02/20/2012 05:38 PM, Martin Rex wrote: > Tomas Gustavsson wrote: >> >> Martin Rex wrote: >>> Tomas Gustavsson wrote: >>>> >>>> Just as a funny of-topic mention. A CRL with 10M revoked entries is >>>> about 400-500MB large. Very useful :-) >>> >>> As I indicated here: >>> https://www.ietf.org/mail-archive/web/pkix/current/msg29842.html >>> >>> I strongly believe that a CA (i.e. that specific DName) should be >>> retired when the expected growth of the CRL during the remaining >>> lifetime of the all certs singed with that exact issuer DName exceeds >>> a reasonable size. >>> >>> The US government is operating several CAs with CRLs carrying>1 million >>> CRLEntries (1080 Millon = 22 MBytes), which is IMO far beyond >>> a resonably sized CRL. >>> >>> Instead of partitioning CRLs, the CA should simply get a new CA cert >>> issued (simply bumping a Serialnumber AVA in the subject DName >>> of the CAs certificate would be sufficient), at which point >>> it will automatically start with a fresh, empty CRL, and this >>> will work nicely with *ALL* RPs. >> >> Since CRLs needs to be maintained as long as the end entity certificates >> are active, all issued end entity certificates of a given CA can >> potentially become revoked, hence the CRL may contain all these entries. > > I had that case explicitly covered above. Not a problem. Just move > to a different CA cert early enough. This is not about worst case, > but what should be reasonably expected, with some safety margin. > > >> >> This means that any given CA is only allowed to issue as many >> certificates as is reasonable to have on a CRL. If you think it is >> 500.000, any given CA is only allowed to issue 500.000 CRLs, this seems >> cumbersome way beyond usability. > > Just the contrary. Managing risk sensibly means that you want to limit > the value of any single CA keypair, so that if anything very bad happens, > you don't have to nuke the entirey PKI, but only that part of it that > is actually affected. Limiting the number of certs that are signed > with a single CA keypair can significantly help here, and will work > with every conforming RP, while only partitioning CRLs based on > distribution point will not help at all, but may create interop problems > with conforming RPs and makes things actually slower, because the CA > MUST still provide the full CRL in addtion to the zoo of partitioned > CRLs, and it is difficult to see how you can mix them in a fashion > that they not intefere with each other, becaus the CRL distribution > point extension of the certificate (rather than that of the CRL) > does not support paritioning of CRLs based on distribution > point names, only on reason codes. > > >> >> In reality CAs can issue 10M certificates within days, I surely don't >> want to renew these CAs as that pace. > > That is not necessarily a problem, if you do not expect your CRLs to grow > at the same rate (10M revocations within days). > > > The partitioning of CRLs by distribution point is ill-conceived, no > matter how you look at it. Whether a CA uses partitioning by > CRL distribution point is *NOT* visible in the CRL distribution > point extension of the Certificate at all! > > Quoting from rfc5280 Section 6.3: > http://tools.ietf.org/html/rfc5280#section-6.3 > > This algorithm assumes that all of the needed CRLs are available in a > local cache. Further, if the next update time of a CRL has passed, > the algorithm assumes a mechanism to fetch a current CRL and place it > in the local CRL cache. > > An RP with an efficient implementation of revocation checking will > be using CRLs, cache the CRLs and update the CRL cache strictly > out-of-band, so that a revocation check will incur a single table lookup > keying on issuer&serial, and zero PK-crypto operations and zero third > party network communication in-band while authenticating peers. > > > -Martin From SChokhani@cygnacom.com Mon Feb 20 17:00:10 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76F121E8024 for ; Mon, 20 Feb 2012 17:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7G8yFq7cTt2k for ; Mon, 20 Feb 2012 17:00:09 -0800 (PST) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id B414F21E8016 for ; Mon, 20 Feb 2012 17:00:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,454,1325480400"; d="scan'208";a="419707" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 20 Feb 2012 19:59:56 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 20 Feb 2012 19:59:56 -0500 From: Santosh Chokhani To: "pkix@ietf.org" Date: Mon, 20 Feb 2012 19:59:56 -0500 Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Thread-Index: Aczv8/zq+Izl0PNNQ0G8yC1fcfrSBg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 01:00:10 -0000 As mentioned before the author of the e-mail reads 5280 incorrectly and has= exhibited a genuine lack of understanding or refusal to understand how IDP= , CRL DP and partitioning work. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Mar= tin Rex Sent: Monday, February 20, 2012 10:38 AM To: Tomas Gustavsson Cc: pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Tomas Gustavsson wrote: >=20 > Martin Rex wrote: > > Tomas Gustavsson wrote: > >> > >> Just as a funny of-topic mention. A CRL with 10M revoked entries is=20 > >> about 400-500MB large. Very useful :-) > > > > As I indicated here: > > https://www.ietf.org/mail-archive/web/pkix/current/msg29842.html > > > > I strongly believe that a CA (i.e. that specific DName) should be=20 > > retired when the expected growth of the CRL during the remaining=20 > > lifetime of the all certs singed with that exact issuer DName=20 > > exceeds a reasonable size. > > > > The US government is operating several CAs with CRLs carrying>1=20 > > million CRLEntries (1080 Millon =3D 22 MBytes), which is IMO far=20 > > beyond a resonably sized CRL. > > > > Instead of partitioning CRLs, the CA should simply get a new CA cert=20 > > issued (simply bumping a Serialnumber AVA in the subject DName of=20 > > the CAs certificate would be sufficient), at which point it will=20 > > automatically start with a fresh, empty CRL, and this will work=20 > > nicely with *ALL* RPs. >=20 > Since CRLs needs to be maintained as long as the end entity=20 > certificates are active, all issued end entity certificates of a given=20 > CA can potentially become revoked, hence the CRL may contain all these en= tries. I had that case explicitly covered above. Not a problem. Just move to a d= ifferent CA cert early enough. This is not about worst case, but what shou= ld be reasonably expected, with some safety margin. >=20 > This means that any given CA is only allowed to issue as many=20 > certificates as is reasonable to have on a CRL. If you think it is=20 > 500.000, any given CA is only allowed to issue 500.000 CRLs, this=20 > seems cumbersome way beyond usability. Just the contrary. Managing risk sensibly means that you want to limit the= value of any single CA keypair, so that if anything very bad happens, you = don't have to nuke the entirey PKI, but only that part of it that is actual= ly affected. Limiting the number of certs that are signed with a single CA= keypair can significantly help here, and will work with every conforming R= P, while only partitioning CRLs based on distribution point will not help a= t all, but may create interop problems with conforming RPs and makes things= actually slower, because the CA MUST still provide the full CRL in addtion= to the zoo of partitioned CRLs, and it is difficult to see how you can mix= them in a fashion that they not intefere with each other, becaus the CRL d= istribution point extension of the certificate (rather than that of the CRL= ) does not support paritioning of CRLs based on distribution point names, o= nly on reason codes. >=20 > In reality CAs can issue 10M certificates within days, I surely don't=20 > want to renew these CAs as that pace. That is not necessarily a problem, if you do not expect your CRLs to grow a= t the same rate (10M revocations within days). The partitioning of CRLs by distribution point is ill-conceived, no matter = how you look at it. Whether a CA uses partitioning by CRL distribution poi= nt is *NOT* visible in the CRL distribution point extension of the Certific= ate at all! Quoting from rfc5280 Section 6.3: http://tools.ietf.org/html/rfc5280#section-6.3 This algorithm assumes that all of the needed CRLs are available in a local cache. Further, if the next update time of a CRL has passed, the algorithm assumes a mechanism to fetch a current CRL and place it in the local CRL cache. An RP with an efficient implementation of revocation checking will be using= CRLs, cache the CRLs and update the CRL cache strictly out-of-band, so tha= t a revocation check will incur a single table lookup keying on issuer&seri= al, and zero PK-crypto operations and zero third party network communicatio= n in-band while authenticating peers. -Martin _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From pgut001@login01.cs.auckland.ac.nz Mon Feb 20 17:33:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE9721F8547 for ; Mon, 20 Feb 2012 17:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tj2+iNBqzeFa for ; Mon, 20 Feb 2012 17:33:18 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8489C21F8593 for ; Mon, 20 Feb 2012 17:33:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1329787999; x=1361323999; h=from:to:subject:cc:in-reply-to:message-id:date; bh=nSfAEyWhrOazmR4Wdoce6t1+eXo3sKAaTYRgx2PKnPQ=; b=Zy7Hlb+0qZCB688Fjd9Tka87rzU++/BrYOElEr+mbLc6UoHqJ5d2iKN4 TNprzzgcpgjj4owXQi5KPiOqHUYw4q7mgKfHnpNOwN1KeFnCFWRqg0C0Y r36M0YwOUMEJz9lC1daJ4d4lxjHay6dKJMX774fMVq98XGRu2Zve85fsj 8=; X-IronPort-AV: E=Sophos;i="4.73,454,1325415600"; d="scan'208";a="104600876" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.34.40 - Outgoing - Outgoing Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 21 Feb 2012 14:33:16 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1RzebT-0006XN-CC; Tue, 21 Feb 2012 14:33:15 +1300 From: Peter Gutmann To: mrex@sap.com, tmiller@mitre.org, tomas@primekey.se In-Reply-To: Message-Id: Date: Tue, 21 Feb 2012 14:33:15 +1300 Cc: pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 01:33:19 -0000 "Miller, Timothy J." writes: >And no, the operations guys just would not consider alternative risk >mitigations that *didn't* involve revocation validation no matter how much I >justified it. Magical thinking demands magical solutions, so I can certainly belive this. Peter. From denis.pinkas@bull.net Tue Feb 21 02:57:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EE921F86F1 for ; Tue, 21 Feb 2012 02:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpRIf0hb1vw2 for ; Tue, 21 Feb 2012 02:57:37 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 09F0521F86F4 for ; Tue, 21 Feb 2012 02:57:37 -0800 (PST) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 35AC718024; Tue, 21 Feb 2012 11:57:36 +0100 (CET) In-Reply-To: <4F42A4A0.8010306@telia.com> References: <20120103200025.6720.30648.idtracker@ietfa.amsl.com> <48EA5D1A-410E-471A-9B39-B282ADF78763@vigilsec.com> <011c01ccee86$cfe8f180$6fbad480$@augustcellars.com> <4F42A4A0.8010306@telia.com> To: pkix@ietf.org MIME-Version: 1.0 X-KeepSent: 9EED9678:BF2B6A88-C12579AB:0037DA60; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Tue, 21 Feb 2012 11:57:34 +0100 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 21/02/2012 11:57:36, Serialize complete at 21/02/2012 11:57:36 Content-Type: multipart/alternative; boundary="=_alternative 003C0E57C12579AB_=" Subject: Re: [pkix] I-D Action: draft-ietf-pkix-cmc-serverkeygeneration-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 10:57:40 -0000 Message en plusieurs parties au format MIME --=_alternative 003C0E57C12579AB_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 QW5kZXJzLA0KDQpJIGFncmVlIHdpdGggeW91ICB0aGF0IHRoZSB0cnVzdCBtb2RlbCBkb2VzIG5v dCBtYWtlIHNlbnNlLg0KDQpJbmRlZWQsIHRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIGRyYWZ0ICBp cyBwcm9wb3NlZCBmb3IgInN0YW5kYXJkIHRyYWNrIi4NCklmIGl0IHdlcmUgcHVzaGVkIGZvciBl eHBlcmltZW50YWwgb3IgZm9yIGluZm9ybWF0aW9uYWwsIHRoaXMgd291bGQgYmUgbm8gDQpwcm9i bGVtLg0KDQpEZW5pcw0KDQpQUy4gSSAgc2VudCAxMiBjb21tZW50cyBvbiBKYW51YXJ5IDEwLCAy MDEyIGFuZCBvbmx5IG9uZSBvZiB0aGVtIChuwrAgMykgDQpoYXMvaXMgIGJlaW5nICBkaXNjdXNz ZWQgOiBQT1AuDQpUaGUgbGlzdCBvZiBjb21tZW50cyBpcyBjb3BpZWQgYWdhaW4gYmVsb3cgLg0K DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCkNvbW1lbnRzIG9uIGRyYWZ0 LWlldGYtcGtpeC1jbWMtc2VydmVya2V5Z2VuZXJhdGlvbi0wMC50eHQgDQpDTUMgRXh0ZW5zaW9u czogU2VydmVyIEtleSBHZW5lcmF0aW9uIA0KDQoNCjEpIEEgdnVsbmVyYWJpbGl0eSBhbmFseXNp cyBpcyBtaXNzaW5nIGFuZCB0aHVzIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBhcmUgDQptaXNzaW5n Lg0KDQoNCjIpIFRoZSBhZHZhbnRhZ2VzIGFuZCBkaXNhZHZhbnRhZ2VzIG9mIGVhY2ggbWV0aG9k IGlzIG5vdCBkaXNjdXNzZWQgb3IgDQpleHBsYWluZWQgYmVmb3JlIHRoZSBtZXRob2RzIGFyZSBp bnRyb2R1Y2VkLg0KDQoNCjMpIFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHN0 YXRlczog4oCcUE9QIGlzIGV4dHJlbWVseSANCmltcG9ydGFudOKAnS4gDQpIb3dldmVyLCB0aGUg dGV4dCBwbGFjZWQgYWZ0ZXIgZG9lcyBub3QgcHJvdmlkZSBhIHJhdGlvbmFsOiANCg0KICAg4oCc SG93ZXZlciwgUE9QIGhlcmUgaXMgZGlmZmVyZW50IHRoYW4gaW4NCiAgIGNsaWVudC1nZW5lcmF0 ZWQga2V5IGNlcnRpZmljYXRpb24gcmVxdWVzdHMgaW4gdGhhdCB0aGUgUE9QIGlzDQogICBuZWNl c3NhcnkgdG8gcHJvdmUgdG8gdGhlIHNlcnZlciB0aGF0IHRoZSBjbGllbnQgaGFzIHBvc3Nlc3Np b24gb2YNCiAgIHRoZSBwcml2YXRlIGtleSBuZWNlc3NhcnkgdG8gZGVjcnlwdCB0aGUgc2VydmVy LWdlbmVyYXRlZCBwcml2YXRlIGtleQ0KICAgcmF0aGVyIHRoYW4gcG9zc2VzcyB0aGUgcHJpdmF0 ZSBrZXkgYXNzb2NpYXRlZCB3aXRoIHRoZSBwdWJsaWMga2V5IGluDQogICB0aGUgcmVxdWVzdC4N Cg0KSWYgdGhlIGNsaWVudCBkb2VzIG5vdCBwb3NzZXNzIHRoZSBwcml2YXRlIGtleSwgaGUgd2ls bCBub3QgYmUgYWJsZSB0byANCmRlY3J5cHQgdGhlIHByaXZhdGUga2V5IGFuZCB0aHVzIHRoZXJl IGlzIG5vIGhhcm0uIA0KSU1PLCBQT1AgaXMgdW5uZWNlc3NhcnkuDQpUaGlzIHdpbGwgbGVhZCB0 byBtYW55IHNpbXBsaWZpY2F0aW9ucyBvbiB0aGUgZG9jdW1lbnQuDQoNCg0KNCkgSG93IHJlcGxh eSBwcm90ZWN0aW9uIG9mIHRoZSBtZXNzYWdlcyBpcyBhY2hpZXZlZCBpcyBub3QgZXhwbGFpbmVk LCANCmV2ZW4gaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24uDQoNCg0KNSkg VGhlIHRleHQgc3RhdGVzIGluIHNlY3Rpb24gMS4xLjE6DQoNCuKAnFRoZSBzaGFyZWQgc2VjcmV0 IGFsbG93cyB0aGUgc2VydmVyIHRvIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50IGFuZCBhbGxvd3Mg DQp0aGUgc2VydmVyIHRvIGVuY3J5cHQgdGhlIHNlcnZlci1zaWRlIGdlbmVyYXRlZCBrZXkgZm9y IHRoZSBjbGllbnTigJ0uDQoNClRoaXMgaXMgbm90IHZlcnkgc2VjdXJlLiBJZiB0aGUgc2hhcmVk IGtleSBpcyBkaXNjb3ZlcmVkLCB0aGVuIGFsbCANCnByZXZpb3VzIHByaXZhdGUga2V5cyBtYXkg YmUgZGVjcnlwdGVkLiBUaGVyZSBzaG91bGQgYmUgYSBzdGF0aWMga2V5IA0KZGVyaXZlZCBmcm9t IHRoZSBzaGFyZWQga2V5IHRvIGJlIHVzZWQgZm9yIGF1dGhlbnRpY2F0aW9uIGFuZCBhbiBlcGhl bWVyYWwgDQprZXkgZGVyaXZlZCBmcm9tIHRoZSBzaGFyZWQga2V5IGFuZCBmcm9tIGEgcmFuZG9t ICh0aHVzIHRoZSBlbmNyeXB0aW9uIGtleSANCmlzIGRpZmZlcmVudCBmb3IgZXZlcnkgcHJpdmF0 ZSBrZXkpLiBUaGUgZGVyaXZhdGlvbiBmdW5jdGlvbiBzaG91bGQgYmUgb25lIA0Kd2F5LiBUaGUg ZGVyaXZhdGlvbiBtZXRob2RzIHNob3VsZCBiZSBwYXJ0IG9mIHRoZSBzcGVjaWZpY2F0aW9uLg0K DQoNCjYpIFRoZSB0ZXh0IHN0YXRlcyBpbiBzZWN0aW9uIDEuMS4xOg0KDQrigJxUaGUgc2hhcmVk IHNlY3JldCBhbGxvd3MgdGhlIHNlcnZlciB0byBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCBhbmQg YWxsb3dzIA0KdGhlIHNlcnZlciB0byBlbmNyeXB0IHRoZSBzZXJ2ZXItc2lkZSBnZW5lcmF0ZWQg a2V5IGZvciB0aGUgY2xpZW50LiBUaGUgDQpzaGFyZWQgc2VjcmV0IGlzIGRpc3RyaWJ1dGVkIHZp YSBhbiBvdXQtb2YtYmFuZCBtZWNoYW5pc20gdGhhdCBpcyANCm91dC1vZi1zY29wZSBvZiB0aGlz IGRvY3VtZW504oCdLg0KDQpUaGlzIGlzIGluc3VmZmljaWVudC4gVGhlcmUgaXMgYSBuZWVkIHRv IGRpc3RyaWJ1dGUgSURzIGFuZCBzaGFyZWQgc2VjcmV0cyANCnNvIHRoYXQgdGhlIHNlcnZlciBt YXkgc2VsZWN0IHRoZSByaWdodCBrZXkgd2hlbiBpdCByZWNlaXZlcyBhIHJlcXVlc3QuIA0KVGhl IElEIG11c3QgYmUgcGFydCBvZiB0aGUgcmVxdWVzdC4NCg0KNykgVGhlIHRleHQgc3RhdGVzIGlu IHNlY3Rpb24gMS4xLjE6DQoNCiAgIOKAnFRoZSBjbGllbnQgY2FuIHZhbGlkYXRlIHRoYXQgdGhl IHJlc3BvbnNlIGNhbWUgZnJvbSB0aGUgQ0EgYnkNCiAgIHZhbGlkYXRpbmcgdGhlIGRpZ2l0YWwg c2lnbmF0dXJlIG9uIHRoZSBTaWduZWREYXRhIHRvIGEgVHJ1c3QgQW5jaG9yDQogICAoVEEp4oCd LiANCg0KTm8uIFRoZSBjbGllbnQgbXVzdCB2YWxpZGF0ZSB0aGF0IHRoZSByZXNwb25zZSBjYW1l IGZyb20gdGhlIENBIHVzaW5nIHRoZSANCmF1dGhlbnRpY2F0aW9uIGtleS4NCg0KOCkgVGhlIHRl eHQgc3RhdGVzIGluIHNlY3Rpb24gMS4xLjI6DQoNCiAgIOKAnFBPUCBpcyBuZWNlc3NhcnkgYmVj YXVzZSB0aGUgY2xpZW50IHdvdWxkIGxpa2UgdGhlDQogICByZXNwb25zZSBlbmNyeXB0ZWQgd2l0 aCBhIHB1YmxpYyBrZXkgYW5kIHRoZSBzZXJ2ZXIgbXVzdCBkZXRlcm1pbmUNCiAgIHRoYXQgdGhl IGNsaWVudCBhY3R1YWxseSBoYXMgdGhlIHByaXZhdGUga2V5IGFzc29jaWF0ZWQgd2l0aCB0aGUN CiAgIHB1YmxpYyBrZXku4oCdIA0KDQpQT1AgaXMgbm90IG5lY2Vzc2FyeS4gU2VlIGFib3ZlLg0K DQoNCjkpIFR5cG8gb24gcGFnZSA3LCBsYXN0IGxpbmUgYmVmb3JlIHRoZSBlbmQgb2YgdGhlIHBh Z2UuIA0KUmVwbGFjZSDigJxkYXRl4oCdIGJ5IOKAnGRhdGHigJ0uDQoNCg0KMTApIFRoZSB0ZXh0 IHN0YXRlcyBpbiBzZWN0aW9uIDIuMSBvbiBwYWdlIDE0Og0KDQogICDigJxXaGVuIHRoaXMgbWV0 aG9kIGlzIHVzZWQgd2l0aCB0aGUgY2VydGlmaWNhdGUgb3B0aW9uLCB0aGUgc2VydmVyIE1VU1QN CiAgIHZhbGlkYXRlIHRoZSBjZXJ0aWZpY2F0ZSBiYWNrIHRvIGEgdHJ1c3QgYW5jaG9yLiAgRnVy dGhlciwgdGhlIHNlcnZlcg0KICAgTVVTVCBjaGVjayB0aGF0IHRoZSBjbGllbnQgcHJvdmlkZWQg Y2VydGlmaWNhdGUgYmVsb25ncyB0byB0aGUgc2FtZQ0KICAgY2xpZW50IHRoYXQgYXV0aGVudGlj YXRlZCB0aGUgY2VydGlmaWNhdGUgcmVxdWVzdCAoZS5nLiB0aGUNCiAgIGNlcnRpZmljYXRlIHN1 YmplY3RzIG1hdGNoLCBvciB0aGUgY2xpZW50IHByb3ZpZGVkIGNlcnRpZmljYXRlDQogICBiZWxv bmdzIHRvIHRoZSBzYW1lIGVudGl0eSBhcyB0aGUgYXV0aGVudGljYXRpb24gc2hhcmVkIHNlY3Jl dCkuICBJZg0KICAgZWl0aGVyIG9mIHRoZXNlIGNoZWNrcyBmYWlscywgdGhlbiB0aGUgc2VydmVy IE1VU1QgcmV0dXJuIGENCiAgIENNQ0ZhaWxJbmZvIHdpdGggdGhlIHZhbHVlIG9mIGJhZENlcnRp ZmljYXRlLCB3aGljaCBpcyBkZWZpbmVkIGluDQogICBTZWN0aW9uIDXigJ0uDQoNClRoaXMgaXMg bm90IG5lY2Vzc2FyeS4gVGhpcyBwYXJhZ3JhcGggc2hvdWxkIGJlIGRlbGV0ZWQuDQoNCg0KMTEp IFRoZSB0ZXh0IHN0YXRlcyBpbiBzZWN0aW9uIDIuMiBvbiBwYWdlIDE1Og0KDQogICDigJxJbiBn ZW5lcmFsLCB3aGlsZSBpdA0KICAgaXMgZXhwZWN0ZWQgdGhhdCB0aGUgc2FtZSBpZGVudGl0eSB0 b2tlbiBhbmQgc2hhcmVkIHNlY3JldCB1c2VkIHRvIGRvDQogICB0aGUgaWRlbnRpdHkgYXV0aGVu dGljYXRpb24gYXJlIHVzZWQgdG8gZGVyaXZlIHRoZSBrZXkgZW5jcnlwdGlvbiBrZXkNCiAgIHRo aXMgaXMgbm90IHJlcXVpcmVk4oCdLg0KDQpBcyBzdGF0ZWQgZWFybGllciwgdGhlIHVzZSBvZiB0 aGUgc2FtZSBrZXkgc2hhbGwgbm90IGJlIHBvc3NpYmxlLg0KDQoNCjEyKSBUaGUgdGV4dCBzdGF0 ZXMgaW4gc2VjdGlvbiA2IG9uIHBhZ2UgMjA6DQoNCiAgIOKAnENyeXB0b2dyYXBoaWMgYWxnb3Jp dGhtcyBhbmQga2V5cyB1c2VkIHRvIHByb3RlY3QgdGhlIHByaXZhdGUga2V5DQogICBzaG91bGQg YmUgYXQgbGVhc3QgYXMgc3Ryb25nIGFzIHRoZSBwcml2YXRlIGtleSdzIGludGVuZGVkIHN0cmVu Z3Ro4oCdLg0KDQpBIHNlcGFyYXRlIGRpc2N1c3Npb24gb24gdGhlIHN0cmVuZ3RoIG9mIHRoZSBh dXRoZW50aWNhdGlvbiBrZXkgYW5kIG9mIHRoZSANCmVuY3J5cHRpb24ga2V5IGlzIG5lZWRlZC4N Cg0KDQoNCg0KRGUgOiAgICBBbmRlcnMgUnVuZGdyZW4gPGFuZGVycy5ydW5kZ3JlbkB0ZWxpYS5j b20+DQpBIDogICAgIGRlbmlzLnBpbmthc0BidWxsLm5ldA0KQ2MgOiAgICBKaW0gU2NoYWFkIDxp ZXRmQGF1Z3VzdGNlbGxhcnMuY29tPg0KRGF0ZSA6ICAyMC8wMi8yMDEyIDIwOjUzDQpPYmpldCA6 IFJlOiBbcGtpeF0gSS1EIEFjdGlvbjogDQpkcmFmdC1pZXRmLXBraXgtY21jLXNlcnZlcmtleWdl bmVyYXRpb24tMDAudHh0DQoNCg0KDQpEZW5pcywNClRoaXMgZGlzY3Vzc2lvbiBpcyByZWR1bmRh bnQ7IHRoZSBpc3N1ZXMgaGF2ZSBhbHJlYWR5IGJlZW4NCmFkZHJlc3NlZCBieSB0aGUgc21hcnQg Y2FyZCBpbmR1c3RyeSB5ZWFycyBhZ28uICBXaXRoIEdvb2dsZSdzDQp3YWxsZXQgdGhleSBhcmUg YmVjb21pbmcgdWJpcXVpdG91cy4NCg0KVGhlIGRlc2NyaWJlZCB0cnVzdCBtb2RlbCBkb2Vzbid0 IG1hdGNoIHRoZSByZWFsaXR5LiAgSWYgTlNBDQp3YW50cyB0byBjcmVhdGUgYSBzY2hlbWUgdGhh dA0KDQogIC0gaXMgYXQgb2RkcyB3aXRoZSB0aGUgaW5kdXN0cnkNCiAgLSB3aWxsIGNvc3QgdGhl IFVTRyBhIGZvcnR1bmUNCg0KaXQgc2VlbXMgdGhhdCB0aGV5IHNob3VsZCBjcmVhdGUgYSBwcml2 YXRlIHN0YW5kYXJkIGZvciB0aGF0Lg0KDQpBbmRlcnMNCg0KDQpPbiAyMDEyLTAyLTIwIDE2OjUy LCBkZW5pcy5waW5rYXNAYnVsbC5uZXQgd3JvdGU6DQo+IEppbSwNCj4gDQo+IEkgYW0gc3RpbGwg dW5jb252aW5jZWQgdGhhdCB0aGlzIHByb3ZpZGVzIGEgaGlnaCBkZWdyZWUgb2YgcHJvdGVjdGlv biANCmFuZCB0aGF0IGl0IGlzIG5lY2Vzc2FyeS4NCj4gDQo+IFlvdSBzYWlkOg0KPiANCj4gIlRo aXMgcHJvdmlkZXMgYSBzdHJvbmcgZGVncmVlIG9mIHByb3RlY3Rpb24gYWdhaW5zdCB0aGUgcG9z c2liaWxpdHkgDQp0aGF0IGFuIGF0dGFja2VyDQo+IGNhbiBpbmR1Y2UgdGhlIGNsaWVudCB0byB1 c2UgdGhlaXIgcHVibGljIGtleSBpbiB0aGUgZW5yb2xsbWVudCBwcm9jZXNzIg0KPiANCj4gVGhl IHB1YmxpYyBrZXkgaXMgaW50ZWdyaXR5IHByb3RlY3RlZCBkdXJpbmcgdGhlIGV4Y2hhbmdlIHVz aW5nIHNoYXJlZCANCnNlY3JldCBvciBhIGNlcnRpZmllZCBrZXkuDQo+IElmIGFuIGF0dGFja2Vy IGNhbiBjaGFuZ2UgdGhlIHB1YmxpYyBrZXksIHRoZW4gdGhlIHNlY3VyaXR5IGlzIGJyb2tlbi4N Cj4gDQo+IElmIGFuIGF0dGFja2VyIGNoYW5nZXMgdGhlIHB1YmxpYyBrZXkgd2l0aCBhIHB1Ymxp YyBmcm9tIGEga2V5IHBhaXIgdGhhdCANCmhlIGtub3dzLCB0aGVuIGluIHRoZSBzYW1lIHdheSB0 aGUgc2VjdXJpdHkgaXMgYnJva2VuLg0KPiBUaGlzIG1lYW5zIHRoYXQgYWRkaW5nIFBvUCBkb2Vz IG5vdCBhZGQgYW55dGhpbmcuDQo+IA0KPiBUbyBtYWtlIGEgcGFyYWxsZWwsIGluIGEgVFNMIGV4 Y2hhbmdlIGRvIHdlIGFzayB0aGUgd2ViIHNlcnZlciB0byBwcm92ZSANCnRoYXQgaXQga25vd3Mg dGhlIHByaXZhdGUga2V5IHdoZW4gaXQgc2VuZHMgaXRzIGNlcnRpZmljYXRlPw0KPiBUaGUgYW5z d2VyIGlzIG5vLiBTbyB3aHkgc2hvdWxkIHdlIGRvIGl0IGluIHRoYXQgY2FzZSA/DQo+IA0KPiBU aGUgb25seSB2ZXJ5IGxpdHRsZSBhZHZhbnRhZ2Ugd291bGQgYmUgOiBpZiB0aGUgY2xpZW50IG1h a2VzIGEgbWlzdGFrZSANCm9mIGl0cyBvd24sIHRoZW4gdGhlIHNlcnZlciB3aWxsIG5vdGljZSBp dCBpbW1lZGlhdGVseSwNCj4gcmF0aGVyIHRoYXQgdGhlIGNsaWVudCBvbiB0aGUgbmV4dCByb3Vu ZC4gQWRkaW5nIHByb3RvY29sIGVsZW1lbnRzIGZvciANCnRoYXQgc3BlY2lmaWMgZXJyb3IgY2Fz ZSB3aGljaCBtaWdodCBvbmx5IGhhcHBlbiBpbiBwcmFjdGljZQ0KPiBkdXJpbmcgYSBkZWJ1Z2dp bmcgcGhhc2UgaXMgbm90IHdvcnRoIHRoZSBlZmZvcnQuDQo+IA0KPiBOb3csIGlmIHNvbWUgcGVv cGxlIHdhbnQgdG8gcGVyZm9ybSB1bm5lY2Vzc2FyeSBjb21wdXRhdGlvbnMgYW5kIGFkZCANCmVs ZW1lbnRzIHRvIHRoZSBwcm90b2NvbCB0aGF0IGFyZSBub3Qgc3RyaWN0bHkgbmVlZGVkLCB0aGF0 IGlzIGZpbmUgZm9yIA0KdGhlbS4NCj4gDQo+IFdoeSBzaG91bGQgdGhleSBoYXZlIGEgc2ltcGxl IHByb3RvY29sIHdoZW4gaXQgY2FuIGJlIG1hZGUgbW9yZSANCmNvbXBsaWNhdGVkID8NCj4gOi0p DQo+IA0KPiBIb3dldmVyLCB0aGVzZSBwZW9wbGUgc2hvdWxkIG5vdCBmb3JjZSBvdGhlciBwZW9w bGUgdG8gYWRkIHVubmVjZXNzYXJ5IA0KcHJvdG9jb2wgZWxlbWVudHMuDQo+IA0KPiBEZW5pcw0K PiANCj4gDQo+IA0KPiANCj4gRGUgOiAgICAgICAgIkppbSBTY2hhYWQiIDxpZXRmQGF1Z3VzdGNl bGxhcnMuY29tPg0KPiBBIDogICAgICAgIDxkZW5pcy5waW5rYXNAYnVsbC5uZXQ+DQo+IENjIDog ICAgICAgICInSUVURiBQS0lYJyIgPHBraXhAaWV0Zi5vcmc+DQo+IERhdGUgOiAgICAgICAgMTgv MDIvMjAxMiAyMzowOA0KPiBPYmpldCA6ICAgICAgICBSRTogW3BraXhdIEktRCBBY3Rpb246IA0K ZHJhZnQtaWV0Zi1wa2l4LWNtYy1zZXJ2ZXJrZXlnZW5lcmF0aW9uLTAwLnR4dA0KPiANCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiANCj4gDQo+IFNvcnJ5IGZvciB0aGUgZGVs YXksIEkgaGF2ZSBub3QgYmVlbiBrZWVwaW5nIGN1cnJlbnQgd2l0aCB0aGUgbWFpbGluZyANCmxp c3QgbGlrZSBJIHNob3VsZCBoYXZlIGJlZW4uDQo+IA0KPiBUaGUgUE9QIGlzIGVudmlzaW9uZWQg dG8gbWFrZSBzdXJlIHRoYXQgdGhlIGNsaWVudCBkb2VzIGhhdmUgdGhlIGFiaWxpdHkgDQp0byBk ZWNyeXB0IHRoZSByZXR1cm5lZCBrZXkuICBUaGlzIGlzIGV4cGxpY2l0bHkgc3RhdGVkIGluIHRo ZSBkb2N1bWVudCANCmN1cnJlbnQuDQo+IA0KPiBUaGUgUE9QIGFsc28gaGFzIGEgc2Vjb25kYXJ5 IGJlbmVmaXQgd2hpY2ggd2FzIG5vdCBzdGF0ZWQgYmVjYXVzZSB3aGlsZSANCkkgdGhpbmsgaXQg aXMgcHJvYmFibHkgdGhlcmUgaXMgbm8gd2F5IHRvIGFzc2VydCB0aGF0IGl0IGlzIHRydWUuICBU aGUgUE9QIA0KYWxsb3dzIHRoZSBzZXJ2ZXIgdG8gaGF2ZSBhIGZhaXIgZGVncmVlIG9mIGNvbmZp ZGVuY2UNCj4gdGhhdCBvbmx5IHRoZSBjbGllbnQgY2FuIGRlY3J5cHQgdGhlIHJldHVybmVkIGtl eS4gIFRoaXMgcHJvdmlkZXMgYSANCnN0cm9uZyBkZWdyZWUgb2YgcHJvdGVjdGlvbiBhZ2FpbnN0 IHRoZSBwb3NzaWJpbGl0eSB0aGF0IGFuIGF0dGFja2VyIGNhbiANCmluZHVjZSB0aGUgY2xpZW50 IHRvIHVzZSB0aGVpciBwdWJsaWMga2V5IGluIHRoZSBlbnJvbGxtZW50DQo+IHByb2Nlc3MuICBE b2luZyBzbyB3b3VsZCByZXN1bHQgaW4gYSBjZXJ0aWZpY2F0ZSBmb3IgQWxpY2UgdGhhdCBBbGlj ZSANCmNvdWxkIG5vdCB1c2UgYnV0IE1hbGxvcnkgY291bGQuDQo+IA0KPiBUaGUgZm9sbG93aW5n IGlzIGJhc2VkIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgb25seSBvbmUgZW50aXR5IGhhcyANCmNv bnRyb2wgb2YgdGhlIHByaXZhdGUga2V5LiAgSWYgTWFsbG9yeSBjYW4gaW5kdWNlIEFsaWNlIHRv IGFjY2VwdCBib3RoIGEgDQpwdWJsaWMgYW5kIGEgcHJpdmF0ZSBrZXkgdGhlbiBhbGwgYmV0cyBh cmUgb2ZmIG9uIHRoaXMNCj4gYXNzdW1wdGlvbi4NCj4gDQo+IEppbQ0KPiANCj4gDQo+ICpGcm9t OiogcGtpeC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnXSAq T24gQmVoYWxmIA0KT2YgKlJ1c3MgSG91c2xleSoNCj4gU2VudDoqIFR1ZXNkYXksIEphbnVhcnkg MTAsIDIwMTIgODo1MiBBTSoNCj4gVG86KiBkZW5pcy5waW5rYXNAYnVsbC5uZXQqDQo+IENjOiog SUVURiBQS0lYKg0KPiBTdWJqZWN0OiogUmU6IFtwa2l4XSBJLUQgQWN0aW9uOiANCmRyYWZ0LWll dGYtcGtpeC1jbWMtc2VydmVya2V5Z2VuZXJhdGlvbi0wMC50eHQNCj4gDQo+IERlbmlzOg0KPiAN Cj4gMykgVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gc3RhdGVzOiDigJxQT1Ag aXMgZXh0cmVtZWx5IA0KaW1wb3J0YW504oCdLg0KPiAgSG93ZXZlciwgdGhlIHRleHQgcGxhY2Vk IGFmdGVyIGRvZXMgbm90IHByb3ZpZGUgYSByYXRpb25hbDoNCj4gDQo+ICAg4oCcSG93ZXZlciwg UE9QIGhlcmUgaXMgZGlmZmVyZW50IHRoYW4gaW4NCj4gICBjbGllbnQtZ2VuZXJhdGVkIGtleSBj ZXJ0aWZpY2F0aW9uIHJlcXVlc3RzIGluIHRoYXQgdGhlIFBPUCBpcw0KPiAgIG5lY2Vzc2FyeSB0 byBwcm92ZSB0byB0aGUgc2VydmVyIHRoYXQgdGhlIGNsaWVudCBoYXMgcG9zc2Vzc2lvbiBvZg0K PiAgIHRoZSBwcml2YXRlIGtleSBuZWNlc3NhcnkgdG8gZGVjcnlwdCB0aGUgc2VydmVyLWdlbmVy YXRlZCBwcml2YXRlIGtleQ0KPiAgIHJhdGhlciB0aGFuIHBvc3Nlc3MgdGhlIHByaXZhdGUga2V5 IGFzc29jaWF0ZWQgd2l0aCB0aGUgcHVibGljIGtleSBpbg0KPiAgIHRoZSByZXF1ZXN0Lg0KPiAN Cj4gSWYgdGhlIGNsaWVudCBkb2VzIG5vdCBwb3NzZXNzIHRoZSBwcml2YXRlIGtleSwgaGUgd2ls bCBub3QgYmUgYWJsZSB0byANCmRlY3J5cHQgdGhlIHByaXZhdGUga2V5DQo+IGFuZCB0aHVzIHRo ZXJlIGlzIG5vIGhhcm0uIElNTywgUE9QIGlzIHVubmVjZXNzYXJ5LiBUaGlzIHdpbGwgbGVhZCB0 byANCm1hbnkgc2ltcGxpZmljYXRpb25zIG9uIHRoZSBkb2N1bWVudC4NCj4gDQo+IEkgZG8gYWdy ZWUgdGhhdCB0aGVyZSBpcyBubyBleHBvc3VyZSBpZiB0aGUgcHJpdmF0ZSBrZXkgY2Fubm90IGJl IA0KdW53cmFwcGVkIChhc3N1bWluZyB0aGUgdXNlIG9mIGdvb2QgYWxnb3JpdGhtcyBhbmQgc3Vj aCkuICBIb3dldmVyLCB0aGUgDQp3YXkgSSByZWFkIGl0LCB0aGUgYXV0aG9ycyB3YW50IHByb29m IHRoYXQgdGhlIHByaXZhdGUga2V5DQo+IGNvdWxkIGJlIHVud3JhcHBlZCBhbmQgdXNlZC4gIFRo aXMgc2VlbXMgbGlrZSBhIGdvb2QgZmVhdHVyZS4NCj4gDQo+IFJ1c3MNCj4gDQo+IA0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcGtpeCBt YWlsaW5nIGxpc3QNCj4gcGtpeEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3BraXgNCg0KDQoNCg== --=_alternative 003C0E57C12579AB_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFuZGVycyw8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYWdyZWUgd2l0aCB5b3UgJm5ic3A7dGhh dCB0aGUgdHJ1c3QNCm1vZGVsIGRvZXMgbm90IG1ha2Ugc2Vuc2UuPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JbmRlZWQsIHRoZSBwcm9ibGVtIGlzIHRo YXQgdGhlIGRyYWZ0DQombmJzcDtpcyBwcm9wb3NlZCBmb3IgJnF1b3Q7c3RhbmRhcmQgdHJhY2sm cXVvdDsuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JZiBpdCB3 ZXJlIHB1c2hlZCBmb3IgZXhwZXJpbWVudGFsIG9yDQpmb3IgaW5mb3JtYXRpb25hbCwgdGhpcyB3 b3VsZCBiZSBubyBwcm9ibGVtLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+RGVuaXM8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPlBTLiBJICZuYnNwO3NlbnQgMTIgY29tbWVudHMgb24gSmFudWFyeQ0KMTAsIDIw MTIgYW5kIG9ubHkgb25lIG9mIHRoZW0gKG7CsCAzKSBoYXMvaXMgJm5ic3A7YmVpbmcgJm5ic3A7 ZGlzY3Vzc2VkDQo6IFBPUC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPlRoZSBsaXN0IG9mIGNvbW1lbnRzIGlzIGNvcGllZCBhZ2Fpbg0KYmVsb3cgLjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPkNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtcGtpeC1jbWMtc2VydmVya2V5Z2Vu ZXJhdGlvbi0wMC50eHQNCjxicj4NCkNNQyBFeHRlbnNpb25zOiBTZXJ2ZXIgS2V5IEdlbmVyYXRp b24gPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+MSkgQSB2dWxuZXJhYmlsaXR5IGFuYWx5c2lzIGlzIG1pc3NpbmcNCmFuZCB0aHVzIHNlY3Vy aXR5IHJlcXVpcmVtZW50cyBhcmUgbWlzc2luZy48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4yKSBUaGUgYWR2YW50YWdlcyBhbmQgZGlzYWR2 YW50YWdlcw0Kb2YgZWFjaCBtZXRob2QgaXMgbm90IGRpc2N1c3NlZCBvciBleHBsYWluZWQgYmVm b3JlIHRoZSBtZXRob2RzIGFyZSBpbnRyb2R1Y2VkLjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjMpIFRoZSBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBzZWN0aW9uDQpzdGF0ZXM6IOKAnFBPUCBpcyBleHRyZW1lbHkgaW1wb3J0YW504oCdLiA8 YnI+DQpIb3dldmVyLCB0aGUgdGV4dCBwbGFjZWQgYWZ0ZXIgZG9lcyBub3QgcHJvdmlkZSBhIHJh dGlvbmFsOiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mbmJzcDsgJm5ic3A74oCcSG93ZXZlciwgUE9QIGhlcmUgaXMNCmRpZmZlcmVudCB0aGFuIGlu PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNw O2NsaWVudC1nZW5lcmF0ZWQga2V5IGNlcnRpZmljYXRpb24NCnJlcXVlc3RzIGluIHRoYXQgdGhl IFBPUCBpczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNw OyAmbmJzcDtuZWNlc3NhcnkgdG8gcHJvdmUgdG8NCnRoZSBzZXJ2ZXIgdGhhdCB0aGUgY2xpZW50 IGhhcyBwb3NzZXNzaW9uIG9mPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+Jm5ic3A7ICZuYnNwO3RoZSBwcml2YXRlIGtleSBuZWNlc3NhcnkNCnRvIGRlY3J5cHQg dGhlIHNlcnZlci1nZW5lcmF0ZWQgcHJpdmF0ZSBrZXk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A7cmF0aGVyIHRoYW4gcG9zc2VzcyB0aGUN CnByaXZhdGUga2V5IGFzc29jaWF0ZWQgd2l0aCB0aGUgcHVibGljIGtleSBpbjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDt0aGUgcmVxdWVz dC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5JZiB0 aGUgY2xpZW50IGRvZXMgbm90IHBvc3Nlc3MgdGhlDQpwcml2YXRlIGtleSwgaGUgd2lsbCBub3Qg YmUgYWJsZSB0byBkZWNyeXB0IHRoZSBwcml2YXRlIGtleSBhbmQgdGh1cyB0aGVyZQ0KaXMgbm8g aGFybS4gPGJyPg0KSU1PLCBQT1AgaXMgdW5uZWNlc3NhcnkuPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+VGhpcyB3aWxsIGxlYWQgdG8gbWFueSBzaW1wbGlmaWNh dGlvbnMNCm9uIHRoZSBkb2N1bWVudC48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij40KSBIb3cgcmVwbGF5IHByb3RlY3Rpb24gb2YgdGhlIG1l c3NhZ2VzDQppcyBhY2hpZXZlZCBpcyBub3QgZXhwbGFpbmVkLCBldmVuIGluIHRoZSBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPjUpIFRoZSB0ZXh0IHN0YXRlcyBpbiBzZWN0aW9uIDEu MS4xOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPuKA nFRoZSBzaGFyZWQgc2VjcmV0IGFsbG93cyB0aGUgc2VydmVyDQp0byBhdXRoZW50aWNhdGUgdGhl IGNsaWVudCBhbmQgYWxsb3dzIHRoZSBzZXJ2ZXIgdG8gZW5jcnlwdCB0aGUgc2VydmVyLXNpZGUN CmdlbmVyYXRlZCBrZXkgZm9yIHRoZSBjbGllbnTigJ0uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+VGhpcyBpcyBub3QgdmVyeSBzZWN1cmUuIElmIHRo ZSBzaGFyZWQNCmtleSBpcyBkaXNjb3ZlcmVkLCB0aGVuIGFsbCBwcmV2aW91cyBwcml2YXRlIGtl eXMgbWF5IGJlIGRlY3J5cHRlZC4gVGhlcmUNCnNob3VsZCBiZSBhIHN0YXRpYyBrZXkgZGVyaXZl ZCBmcm9tIHRoZSBzaGFyZWQga2V5IHRvIGJlIHVzZWQgZm9yIGF1dGhlbnRpY2F0aW9uDQphbmQg YW4gZXBoZW1lcmFsIGtleSBkZXJpdmVkIGZyb20gdGhlIHNoYXJlZCBrZXkgYW5kIGZyb20gYSBy YW5kb20gKHRodXMNCnRoZSBlbmNyeXB0aW9uIGtleSBpcyBkaWZmZXJlbnQgZm9yIGV2ZXJ5IHBy aXZhdGUga2V5KS4gVGhlIGRlcml2YXRpb24NCmZ1bmN0aW9uIHNob3VsZCBiZSBvbmUgd2F5LiBU aGUgZGVyaXZhdGlvbiBtZXRob2RzIHNob3VsZCBiZSBwYXJ0IG9mIHRoZQ0Kc3BlY2lmaWNhdGlv bi48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij42KSBUaGUgdGV4dCBzdGF0ZXMgaW4gc2VjdGlvbiAxLjEuMTo8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij7igJxUaGUgc2hhcmVkIHNlY3JldCBhbGxv d3MgdGhlIHNlcnZlcg0KdG8gYXV0aGVudGljYXRlIHRoZSBjbGllbnQgYW5kIGFsbG93cyB0aGUg c2VydmVyIHRvIGVuY3J5cHQgdGhlIHNlcnZlci1zaWRlDQpnZW5lcmF0ZWQga2V5IGZvciB0aGUg Y2xpZW50LiBUaGUgc2hhcmVkIHNlY3JldCBpcyBkaXN0cmlidXRlZCB2aWEgYW4gb3V0LW9mLWJh bmQNCm1lY2hhbmlzbSB0aGF0IGlzIG91dC1vZi1zY29wZSBvZiB0aGlzIGRvY3VtZW504oCdLjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPlRoaXMgaXMg aW5zdWZmaWNpZW50LiBUaGVyZSBpcyBhIG5lZWQNCnRvIGRpc3RyaWJ1dGUgSURzIGFuZCBzaGFy ZWQgc2VjcmV0cyBzbyB0aGF0IHRoZSBzZXJ2ZXIgbWF5IHNlbGVjdCB0aGUNCnJpZ2h0IGtleSB3 aGVuIGl0IHJlY2VpdmVzIGEgcmVxdWVzdC4gJm5ic3A7VGhlIElEIG11c3QgYmUgcGFydCBvZiB0 aGUNCnJlcXVlc3QuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+NykgVGhlIHRleHQgc3RhdGVzIGluIHNlY3Rpb24gMS4xLjE6PC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO+KAnFRoZSBj bGllbnQgY2FuIHZhbGlkYXRlDQp0aGF0IHRoZSByZXNwb25zZSBjYW1lIGZyb20gdGhlIENBIGJ5 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNw O3ZhbGlkYXRpbmcgdGhlIGRpZ2l0YWwNCnNpZ25hdHVyZSBvbiB0aGUgU2lnbmVkRGF0YSB0byBh IFRydXN0IEFuY2hvcjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PiZuYnNwOyAmbmJzcDsoVEEp4oCdLiAmbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5Oby4gVGhlIGNsaWVudCBtdXN0IHZhbGlkYXRlIHRoYXQg dGhlDQpyZXNwb25zZSBjYW1lIGZyb20gdGhlIENBIHVzaW5nIHRoZSBhdXRoZW50aWNhdGlvbiBr ZXkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+OCkg VGhlIHRleHQgc3RhdGVzIGluIHNlY3Rpb24gMS4xLjI6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO+KAnFBPUCBpcyBuZWNlc3Nh cnkgYmVjYXVzZQ0KdGhlIGNsaWVudCB3b3VsZCBsaWtlIHRoZTwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDtyZXNwb25zZSBlbmNyeXB0ZWQg d2l0aA0KYSBwdWJsaWMga2V5IGFuZCB0aGUgc2VydmVyIG11c3QgZGV0ZXJtaW5lPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO3RoYXQgdGhl IGNsaWVudCBhY3R1YWxseQ0KaGFzIHRoZSBwcml2YXRlIGtleSBhc3NvY2lhdGVkIHdpdGggdGhl PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNw O3B1YmxpYyBrZXku4oCdIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPlBPUCBpcyBub3QgbmVjZXNzYXJ5LiBTZWUgYWJvdmUuPC9mb250Pg0KPGJyPg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+OSkgVHlwbyBvbiBwYWdl IDcsIGxhc3QgbGluZSBiZWZvcmUNCnRoZSBlbmQgb2YgdGhlIHBhZ2UuIDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPlJlcGxhY2Ug4oCcZGF0ZeKAnSBieSDigJxk YXRh4oCdLjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjEwKSBUaGUgdGV4dCBzdGF0ZXMgaW4gc2VjdGlvbiAyLjENCm9uIHBhZ2UgMTQ6PC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZu YnNwO+KAnFdoZW4gdGhpcyBtZXRob2QgaXMNCnVzZWQgd2l0aCB0aGUgY2VydGlmaWNhdGUgb3B0 aW9uLCB0aGUgc2VydmVyIE1VU1Q8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mbmJzcDsgJm5ic3A7dmFsaWRhdGUgdGhlIGNlcnRpZmljYXRlDQpiYWNrIHRvIGEg dHJ1c3QgYW5jaG9yLiAmbmJzcDtGdXJ0aGVyLCB0aGUgc2VydmVyPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO01VU1QgY2hlY2sgdGhhdCB0 aGUgY2xpZW50DQpwcm92aWRlZCBjZXJ0aWZpY2F0ZSBiZWxvbmdzIHRvIHRoZSBzYW1lPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO2NsaWVu dCB0aGF0IGF1dGhlbnRpY2F0ZWQNCnRoZSBjZXJ0aWZpY2F0ZSByZXF1ZXN0IChlLmcuIHRoZTwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDtj ZXJ0aWZpY2F0ZSBzdWJqZWN0cyBtYXRjaCwNCm9yIHRoZSBjbGllbnQgcHJvdmlkZWQgY2VydGlm aWNhdGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsg Jm5ic3A7YmVsb25ncyB0byB0aGUgc2FtZSBlbnRpdHkNCmFzIHRoZSBhdXRoZW50aWNhdGlvbiBz aGFyZWQgc2VjcmV0KS4gJm5ic3A7SWY8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A7ZWl0aGVyIG9mIHRoZXNlIGNoZWNrcw0KZmFpbHMsIHRo ZW4gdGhlIHNlcnZlciBNVVNUIHJldHVybiBhPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO0NNQ0ZhaWxJbmZvIHdpdGggdGhlIHZhbHVlDQpv ZiBiYWRDZXJ0aWZpY2F0ZSwgd2hpY2ggaXMgZGVmaW5lZCBpbjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDtTZWN0aW9uIDXigJ0uPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+VGhpcyBpcyBub3Qg bmVjZXNzYXJ5LiBUaGlzIHBhcmFncmFwaA0Kc2hvdWxkIGJlIGRlbGV0ZWQuPC9mb250Pg0KPGJy Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+MTEpIFRoZSB0ZXh0 IHN0YXRlcyBpbiBzZWN0aW9uIDIuMg0Kb24gcGFnZSAxNTo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A74oCcSW4gZ2VuZXJhbCwg d2hpbGUgaXQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJz cDsgJm5ic3A7aXMgZXhwZWN0ZWQgdGhhdCB0aGUgc2FtZQ0KaWRlbnRpdHkgdG9rZW4gYW5kIHNo YXJlZCBzZWNyZXQgdXNlZCB0byBkbzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPiZuYnNwOyAmbmJzcDt0aGUgaWRlbnRpdHkgYXV0aGVudGljYXRpb24NCmFyZSB1 c2VkIHRvIGRlcml2ZSB0aGUga2V5IGVuY3J5cHRpb24ga2V5PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO3RoaXMgaXMgbm90IHJlcXVpcmVk 4oCdLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPkFz IHN0YXRlZCBlYXJsaWVyLCB0aGUgdXNlIG9mIHRoZSBzYW1lDQprZXkgc2hhbGwgbm90IGJlIHBv c3NpYmxlLjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjEyKSBUaGUgdGV4dCBzdGF0ZXMgaW4gc2VjdGlvbiA2IG9uDQpwYWdlIDIwOjwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJz cDvigJxDcnlwdG9ncmFwaGljIGFsZ29yaXRobXMNCmFuZCBrZXlzIHVzZWQgdG8gcHJvdGVjdCB0 aGUgcHJpdmF0ZSBrZXk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mbmJzcDsgJm5ic3A7c2hvdWxkIGJlIGF0IGxlYXN0IGFzDQpzdHJvbmcgYXMgdGhlIHByaXZh dGUga2V5J3MgaW50ZW5kZWQgc3RyZW5ndGjigJ0uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+QSBzZXBhcmF0ZSBkaXNjdXNzaW9uIG9uIHRoZSBzdHJl bmd0aA0Kb2YgdGhlIGF1dGhlbnRpY2F0aW9uIGtleSBhbmQgb2YgdGhlIGVuY3J5cHRpb24ga2V5 IGlzIG5lZWRlZC48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+RGUgOiAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5BbmRlcnMg UnVuZGdyZW4gJmx0O2FuZGVycy5ydW5kZ3JlbkB0ZWxpYS5jb20mZ3Q7PC9mb250Pg0KPGJyPjxm b250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkEgOiAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5k ZW5pcy5waW5rYXNAYnVsbC5uZXQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVm NWYgZmFjZT0ic2Fucy1zZXJpZiI+Q2MmbmJzcDs6ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPkppbSBTY2hhYWQgJmx0O2ll dGZAYXVndXN0Y2VsbGFycy5jb20mZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0j NWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkRhdGUgOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMC8wMi8yMDEyIDIwOjUz PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYi Pk9iamV0IDogJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtwa2l4XSBJLUQNCkFjdGlvbjogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ZHJhZnQtaWV0Zi1wa2l4LWNtYy1zZXJ2ZXJrZXlnZW5lcmF0aW9uLTAwLnR4 dDwvZm9udD4NCjxicj4NCjxociBub3NoYWRlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBz aXplPTI+RGVuaXMsPGJyPg0KVGhpcyBkaXNjdXNzaW9uIGlzIHJlZHVuZGFudDsgdGhlIGlzc3Vl cyBoYXZlIGFscmVhZHkgYmVlbjxicj4NCmFkZHJlc3NlZCBieSB0aGUgc21hcnQgY2FyZCBpbmR1 c3RyeSB5ZWFycyBhZ28uICZuYnNwO1dpdGggR29vZ2xlJ3M8YnI+DQp3YWxsZXQgdGhleSBhcmUg YmVjb21pbmcgdWJpcXVpdG91cy48YnI+DQo8YnI+DQpUaGUgZGVzY3JpYmVkIHRydXN0IG1vZGVs IGRvZXNuJ3QgbWF0Y2ggdGhlIHJlYWxpdHkuICZuYnNwO0lmIE5TQTxicj4NCndhbnRzIHRvIGNy ZWF0ZSBhIHNjaGVtZSB0aGF0PGJyPg0KPGJyPg0KICZuYnNwOy0gaXMgYXQgb2RkcyB3aXRoZSB0 aGUgaW5kdXN0cnk8YnI+DQogJm5ic3A7LSB3aWxsIGNvc3QgdGhlIFVTRyBhIGZvcnR1bmU8YnI+ DQo8YnI+DQppdCBzZWVtcyB0aGF0IHRoZXkgc2hvdWxkIGNyZWF0ZSBhIHByaXZhdGUgc3RhbmRh cmQgZm9yIHRoYXQuPGJyPg0KPGJyPg0KQW5kZXJzPGJyPg0KPGJyPg0KPGJyPg0KT24gMjAxMi0w Mi0yMCAxNjo1MiwgZGVuaXMucGlua2FzQGJ1bGwubmV0IHdyb3RlOjxicj4NCiZndDsgSmltLDxi cj4NCiZndDsgPGJyPg0KJmd0OyBJIGFtIHN0aWxsIHVuY29udmluY2VkIHRoYXQgdGhpcyBwcm92 aWRlcyBhIGhpZ2ggZGVncmVlIG9mIHByb3RlY3Rpb24NCmFuZCB0aGF0IGl0IGlzIG5lY2Vzc2Fy eS48YnI+DQomZ3Q7IDxicj4NCiZndDsgWW91IHNhaWQ6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZx dW90O1RoaXMgcHJvdmlkZXMgYSBzdHJvbmcgZGVncmVlIG9mIHByb3RlY3Rpb24gYWdhaW5zdCB0 aGUgcG9zc2liaWxpdHkNCnRoYXQgYW4gYXR0YWNrZXI8YnI+DQomZ3Q7IGNhbiBpbmR1Y2UgdGhl IGNsaWVudCB0byB1c2UgdGhlaXIgcHVibGljIGtleSBpbiB0aGUgZW5yb2xsbWVudCBwcm9jZXNz JnF1b3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBwdWJsaWMga2V5IGlzIGludGVncml0eSBw cm90ZWN0ZWQgZHVyaW5nIHRoZSBleGNoYW5nZSB1c2luZyBzaGFyZWQNCnNlY3JldCBvciBhIGNl cnRpZmllZCBrZXkuPGJyPg0KJmd0OyBJZiBhbiBhdHRhY2tlciBjYW4gY2hhbmdlIHRoZSBwdWJs aWMga2V5LCB0aGVuIHRoZSBzZWN1cml0eSBpcyBicm9rZW4uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IElmIGFuIGF0dGFja2VyIGNoYW5nZXMgdGhlIHB1YmxpYyBrZXkgd2l0aCBhIHB1YmxpYyBmcm9t IGEga2V5IHBhaXINCnRoYXQgaGUga25vd3MsIHRoZW4gaW4gdGhlIHNhbWUgd2F5IHRoZSBzZWN1 cml0eSBpcyBicm9rZW4uPGJyPg0KJmd0OyBUaGlzIG1lYW5zIHRoYXQgYWRkaW5nIFBvUCBkb2Vz IG5vdCBhZGQgYW55dGhpbmcuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRvIG1ha2UgYSBwYXJhbGxl bCwgaW4gYSBUU0wgZXhjaGFuZ2UgZG8gd2UgYXNrIHRoZSB3ZWIgc2VydmVyIHRvDQpwcm92ZSB0 aGF0IGl0IGtub3dzIHRoZSBwcml2YXRlIGtleSB3aGVuIGl0IHNlbmRzIGl0cyBjZXJ0aWZpY2F0 ZT88YnI+DQomZ3Q7IFRoZSBhbnN3ZXIgaXMgbm8uIFNvIHdoeSBzaG91bGQgd2UgZG8gaXQgaW4g dGhhdCBjYXNlID88YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIG9ubHkgdmVyeSBsaXR0bGUgYWR2 YW50YWdlIHdvdWxkIGJlIDogaWYgdGhlIGNsaWVudCBtYWtlcyBhIG1pc3Rha2UNCm9mIGl0cyBv d24sIHRoZW4gdGhlIHNlcnZlciB3aWxsIG5vdGljZSBpdCBpbW1lZGlhdGVseSw8YnI+DQomZ3Q7 IHJhdGhlciB0aGF0IHRoZSBjbGllbnQgb24gdGhlIG5leHQgcm91bmQuIEFkZGluZyBwcm90b2Nv bCBlbGVtZW50cw0KZm9yIHRoYXQgc3BlY2lmaWMgZXJyb3IgY2FzZSB3aGljaCBtaWdodCBvbmx5 IGhhcHBlbiBpbiBwcmFjdGljZTxicj4NCiZndDsgZHVyaW5nIGEgZGVidWdnaW5nIHBoYXNlIGlz IG5vdCB3b3J0aCB0aGUgZWZmb3J0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBOb3csIGlmIHNvbWUg cGVvcGxlIHdhbnQgdG8gcGVyZm9ybSB1bm5lY2Vzc2FyeSBjb21wdXRhdGlvbnMgYW5kIGFkZA0K ZWxlbWVudHMgdG8gdGhlIHByb3RvY29sIHRoYXQgYXJlIG5vdCBzdHJpY3RseSBuZWVkZWQsIHRo YXQgaXMgZmluZSBmb3INCnRoZW0uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdoeSBzaG91bGQgdGhl eSBoYXZlIGEgc2ltcGxlIHByb3RvY29sIHdoZW4gaXQgY2FuIGJlIG1hZGUgbW9yZSBjb21wbGlj YXRlZA0KPzxicj4NCiZndDsgOi0pPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhvd2V2ZXIsIHRoZXNl IHBlb3BsZSBzaG91bGQgbm90IGZvcmNlIG90aGVyIHBlb3BsZSB0byBhZGQgdW5uZWNlc3NhcnkN CnByb3RvY29sIGVsZW1lbnRzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBEZW5pczxicj4NCiZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBEZSA6ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O0ppbSBTY2hhYWQmcXVvdDsgJmx0O2lldGZAYXVndXN0 Y2VsbGFycy5jb20mZ3Q7PGJyPg0KJmd0OyBBIDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmx0O2RlbmlzLnBpbmthc0BidWxsLm5ldCZndDs8YnI+DQomZ3Q7IENjIDogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7JnF1b3Q7J0lFVEYgUEtJWCcmcXVvdDsgJmx0O3BraXhAaWV0Zi5vcmcm Z3Q7PGJyPg0KJmd0OyBEYXRlIDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MTgvMDIvMjAx MiAyMzowODxicj4NCiZndDsgT2JqZXQgOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSRTog W3BraXhdIEktRCBBY3Rpb246ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDtkcmFmdC1pZXRm LXBraXgtY21jLXNlcnZlcmtleWdlbmVyYXRpb24tMDAudHh0PGJyPg0KJmd0OyAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgU29ycnkgZm9yIHRoZSBkZWxheSwgSSBoYXZlIG5vdCBiZWVuIGtlZXBpbmcgY3VycmVu dCB3aXRoIHRoZSBtYWlsaW5nDQpsaXN0IGxpa2UgSSBzaG91bGQgaGF2ZSBiZWVuLjxicj4NCiZn dDsgJm5ic3A7PGJyPg0KJmd0OyBUaGUgUE9QIGlzIGVudmlzaW9uZWQgdG8gbWFrZSBzdXJlIHRo YXQgdGhlIGNsaWVudCBkb2VzIGhhdmUgdGhlIGFiaWxpdHkNCnRvIGRlY3J5cHQgdGhlIHJldHVy bmVkIGtleS4gJm5ic3A7VGhpcyBpcyBleHBsaWNpdGx5IHN0YXRlZCBpbiB0aGUgZG9jdW1lbnQN CmN1cnJlbnQuPGJyPg0KJmd0OyAmbmJzcDs8YnI+DQomZ3Q7IFRoZSBQT1AgYWxzbyBoYXMgYSBz ZWNvbmRhcnkgYmVuZWZpdCB3aGljaCB3YXMgbm90IHN0YXRlZCBiZWNhdXNlDQp3aGlsZSBJIHRo aW5rIGl0IGlzIHByb2JhYmx5IHRoZXJlIGlzIG5vIHdheSB0byBhc3NlcnQgdGhhdCBpdCBpcyB0 cnVlLg0KJm5ic3A7VGhlIFBPUCBhbGxvd3MgdGhlIHNlcnZlciB0byBoYXZlIGEgZmFpciBkZWdy ZWUgb2YgY29uZmlkZW5jZTxicj4NCiZndDsgdGhhdCBvbmx5IHRoZSBjbGllbnQgY2FuIGRlY3J5 cHQgdGhlIHJldHVybmVkIGtleS4gJm5ic3A7VGhpcyBwcm92aWRlcw0KYSBzdHJvbmcgZGVncmVl IG9mIHByb3RlY3Rpb24gYWdhaW5zdCB0aGUgcG9zc2liaWxpdHkgdGhhdCBhbiBhdHRhY2tlcg0K Y2FuIGluZHVjZSB0aGUgY2xpZW50IHRvIHVzZSB0aGVpciBwdWJsaWMga2V5IGluIHRoZSBlbnJv bGxtZW50PGJyPg0KJmd0OyBwcm9jZXNzLiAmbmJzcDtEb2luZyBzbyB3b3VsZCByZXN1bHQgaW4g YSBjZXJ0aWZpY2F0ZSBmb3IgQWxpY2UgdGhhdA0KQWxpY2UgY291bGQgbm90IHVzZSBidXQgTWFs bG9yeSBjb3VsZC48YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDsgVGhlIGZvbGxvd2luZyBpcyBi YXNlZCBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0IG9ubHkgb25lIGVudGl0eSBoYXMNCmNvbnRyb2wg b2YgdGhlIHByaXZhdGUga2V5LiAmbmJzcDtJZiBNYWxsb3J5IGNhbiBpbmR1Y2UgQWxpY2UgdG8g YWNjZXB0DQpib3RoIGEgcHVibGljIGFuZCBhIHByaXZhdGUga2V5IHRoZW4gYWxsIGJldHMgYXJl IG9mZiBvbiB0aGlzPGJyPg0KJmd0OyBhc3N1bXB0aW9uLjxicj4NCiZndDsgJm5ic3A7PGJyPg0K Jmd0OyBKaW08YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0OyAqRnJv bToqIHBraXgtYm91bmNlc0BpZXRmLm9yZyBbPC9mb250PjwvdHQ+PGEgaHJlZj0ibWFpbHRvOnBr aXgtYm91bmNlc0BpZXRmLm9yZyI+PHR0Pjxmb250IHNpemU9Mj5tYWlsdG86cGtpeC1ib3VuY2Vz QGlldGYub3JnPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+XQ0KKk9uIEJlaGFsZiBP ZiAqUnVzcyBIb3VzbGV5Kjxicj4NCiZndDsgU2VudDoqIFR1ZXNkYXksIEphbnVhcnkgMTAsIDIw MTIgODo1MiBBTSo8YnI+DQomZ3Q7IFRvOiogZGVuaXMucGlua2FzQGJ1bGwubmV0Kjxicj4NCiZn dDsgQ2M6KiBJRVRGIFBLSVgqPGJyPg0KJmd0OyBTdWJqZWN0OiogUmU6IFtwa2l4XSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLXBraXgtY21jLXNlcnZlcmtleWdlbmVyYXRpb24tMDAudHh0PGJyPg0K Jmd0OyAmbmJzcDs8YnI+DQomZ3Q7IERlbmlzOjxicj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0OyAz KSBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBzdGF0ZXM6IOKAnFBPUCBpcyBl eHRyZW1lbHkNCmltcG9ydGFudOKAnS48YnI+DQomZ3Q7ICZuYnNwO0hvd2V2ZXIsIHRoZSB0ZXh0 IHBsYWNlZCBhZnRlciBkb2VzIG5vdCBwcm92aWRlIGEgcmF0aW9uYWw6PGJyPg0KJmd0OyA8YnI+ DQomZ3Q7ICZuYnNwOyDigJxIb3dldmVyLCBQT1AgaGVyZSBpcyBkaWZmZXJlbnQgdGhhbiBpbjxi cj4NCiZndDsgJm5ic3A7IGNsaWVudC1nZW5lcmF0ZWQga2V5IGNlcnRpZmljYXRpb24gcmVxdWVz dHMgaW4gdGhhdCB0aGUgUE9QDQppczxicj4NCiZndDsgJm5ic3A7IG5lY2Vzc2FyeSB0byBwcm92 ZSB0byB0aGUgc2VydmVyIHRoYXQgdGhlIGNsaWVudCBoYXMgcG9zc2Vzc2lvbg0Kb2Y8YnI+DQom Z3Q7ICZuYnNwOyB0aGUgcHJpdmF0ZSBrZXkgbmVjZXNzYXJ5IHRvIGRlY3J5cHQgdGhlIHNlcnZl ci1nZW5lcmF0ZWQgcHJpdmF0ZQ0Ka2V5PGJyPg0KJmd0OyAmbmJzcDsgcmF0aGVyIHRoYW4gcG9z c2VzcyB0aGUgcHJpdmF0ZSBrZXkgYXNzb2NpYXRlZCB3aXRoIHRoZSBwdWJsaWMNCmtleSBpbjxi cj4NCiZndDsgJm5ic3A7IHRoZSByZXF1ZXN0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBJZiB0aGUg Y2xpZW50IGRvZXMgbm90IHBvc3Nlc3MgdGhlIHByaXZhdGUga2V5LCBoZSB3aWxsIG5vdCBiZSBh YmxlDQp0byBkZWNyeXB0IHRoZSBwcml2YXRlIGtleTxicj4NCiZndDsgYW5kIHRodXMgdGhlcmUg aXMgbm8gaGFybS4gSU1PLCBQT1AgaXMgdW5uZWNlc3NhcnkuIFRoaXMgd2lsbCBsZWFkDQp0byBt YW55IHNpbXBsaWZpY2F0aW9ucyBvbiB0aGUgZG9jdW1lbnQuPGJyPg0KJmd0OyAmbmJzcDs8YnI+ DQomZ3Q7IEkgZG8gYWdyZWUgdGhhdCB0aGVyZSBpcyBubyBleHBvc3VyZSBpZiB0aGUgcHJpdmF0 ZSBrZXkgY2Fubm90IGJlDQp1bndyYXBwZWQgKGFzc3VtaW5nIHRoZSB1c2Ugb2YgZ29vZCBhbGdv cml0aG1zIGFuZCBzdWNoKS4gJm5ic3A7SG93ZXZlciwNCnRoZSB3YXkgSSByZWFkIGl0LCB0aGUg YXV0aG9ycyB3YW50IHByb29mIHRoYXQgdGhlIHByaXZhdGUga2V5PGJyPg0KJmd0OyBjb3VsZCBi ZSB1bndyYXBwZWQgYW5kIHVzZWQuICZuYnNwO1RoaXMgc2VlbXMgbGlrZSBhIGdvb2QgZmVhdHVy ZS48YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDsgUnVzczxicj4NCiZndDsgJm5ic3A7PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHBraXggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBw a2l4QGlldGYub3JnPGJyPg0KJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcGtpeD48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGtpeDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQg c2l6ZT0yPjxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 003C0E57C12579AB_=-- From mrex@sap.com Tue Feb 21 06:30:42 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE5521F881D for ; Tue, 21 Feb 2012 06:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.075 X-Spam-Level: X-Spam-Status: No, score=-10.075 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhLv0yKUKyuB for ; Tue, 21 Feb 2012 06:30:42 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id AA1D921F881C for ; Tue, 21 Feb 2012 06:30:41 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q1LEUdKe015748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Feb 2012 15:30:39 +0100 (MET) From: Martin Rex Message-Id: <201202211430.q1LEUblV026791@fs4113.wdf.sap.corp> To: tomas@primekey.se (Tomas Gustavsson) Date: Tue, 21 Feb 2012 15:30:37 +0100 (MET) In-Reply-To: <4F42C820.7000501@primekey.se> from "Tomas Gustavsson" at Feb 21, 12 00:24:32 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 14:30:42 -0000 Tomas Gustavsson wrote: > > Consider this (real world) use case. > > 50M certificates issued in 10 days. 5M revoked. That looks like a serious design flaw of the PKI. A sensible PKI design would seperate certs that need to be frequently revoked from those that are rarely revoked and at least adjust the certificate validity so that the necessity to revoke becomes the exception, but preferably these two kinds of certificates with completely different usage patterns would be signed by seperate intermediate CA certs. > > Far from easy to maintain any type of renewals under this load. Switching to a different intermediate CA cert is _not_ a CA cert roll-over as far as the RP is concerned, so there is ZERO pain involved (for the RPs). btw. the use of the term "renewal" should be limited to a successor cert with the exact same public key and the exact same subject DName. > > IMHO it just shows that the use cases for PKI today is virtually > unbounded. PKIX must (and often does) provide mechanisms to encompass a > broad range of use cases. Each use case/CA/RP must select the mechanisms > that are suitable. If you don't like CRL partitioning in your use case, > don't use it. It's not whether we "like" it. We simply do not support it at all in our RP (fully conforming with rfc5280). It is squarely incompatible with efficient processing of revocation during online authentication. > > I have tried to avoid it so far, but are being forced to > look into it now. If you don't need CRLs, but OCSP works, forget about > CRLs and only use OCSP. If you want to replace your CAs every week, do > it. Etc etc. OCSP is a complete no-go. It is prohibitively expensive. Efficient revocation checking based on CRLs is possible with zero PK-operations and zero network communication in-band during authentication. Obtaining the OCSP responses inband (like with multiple-OCSP-responses TLS extension) might be a future possibility, although this will incur at least one PK-operation. If PK-authentication want to be taken seriously as an alternative to Kerberos authentication, then it MUST be efficient on the server-side processing, which means NO third-party communication during communication, as few PK-operations as possible, and manageable risk. The TLS X.509 PKI as used by web browsers is pretty close to no security at all. > > Today we really need to be open minded about PKI, because it is > ubiquitous in a way it has never been before, in new and improved > use cases. The only thing that is ubiquitous about PKI today is the security problem from having hundreds of omnipotent rootCAs pretrusted. -Martin From mrex@sap.com Tue Feb 21 06:35:07 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE3521F8707 for ; Tue, 21 Feb 2012 06:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.776 X-Spam-Level: X-Spam-Status: No, score=-9.776 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bafnT5SJxd+b for ; Tue, 21 Feb 2012 06:35:03 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id B5BE521F8835 for ; Tue, 21 Feb 2012 06:35:02 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q1LEYn4X026620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Feb 2012 15:34:54 +0100 (MET) From: Martin Rex Message-Id: <201202211434.q1LEYm9o026940@fs4113.wdf.sap.corp> To: SChokhani@cygnacom.com (Santosh Chokhani) Date: Tue, 21 Feb 2012 15:34:48 +0100 (MET) In-Reply-To: from "Santosh Chokhani" at Feb 20, 12 07:59:56 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 14:35:08 -0000 Santosh Chokhani wrote: > > As mentioned before the author of the e-mail reads 5280 incorrectly > and has exhibited a genuine lack of understanding or refusal to > understand how IDP, CRL DP and partitioning work. I'm only reading the specification the way it is written. And I'm apply formal logic to determine the "permissible interpretations" for those many areas that are unclear and ambiguous. Your interpretation of the spec, while not uncommon for people arguing natural language, is outside of formally valid interpretation, I'm sorry. -Martin > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Martin Rex > Sent: Monday, February 20, 2012 10:38 AM > To: Tomas Gustavsson > Cc: pkix@ietf.org > Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer > > Tomas Gustavsson wrote: > > > > Martin Rex wrote: > > > Tomas Gustavsson wrote: > > >> > > >> Just as a funny of-topic mention. A CRL with 10M revoked entries is > > >> about 400-500MB large. Very useful :-) > > > > > > As I indicated here: > > > https://www.ietf.org/mail-archive/web/pkix/current/msg29842.html > > > > > > I strongly believe that a CA (i.e. that specific DName) should be > > > retired when the expected growth of the CRL during the remaining > > > lifetime of the all certs singed with that exact issuer DName > > > exceeds a reasonable size. > > > > > > The US government is operating several CAs with CRLs carrying>1 > > > million CRLEntries (1080 Millon = 22 MBytes), which is IMO far > > > beyond a resonably sized CRL. > > > > > > Instead of partitioning CRLs, the CA should simply get a new CA cert > > > issued (simply bumping a Serialnumber AVA in the subject DName of > > > the CAs certificate would be sufficient), at which point it will > > > automatically start with a fresh, empty CRL, and this will work > > > nicely with *ALL* RPs. > > > > Since CRLs needs to be maintained as long as the end entity > > certificates are active, all issued end entity certificates of a given > > CA can potentially become revoked, hence the CRL may contain all these entries. > > I had that case explicitly covered above. Not a problem. Just move to a different CA cert early enough. This is not about worst case, but what should be reasonably expected, with some safety margin. > > > > > > This means that any given CA is only allowed to issue as many > > certificates as is reasonable to have on a CRL. If you think it is > > 500.000, any given CA is only allowed to issue 500.000 CRLs, this > > seems cumbersome way beyond usability. > > Just the contrary. Managing risk sensibly means that you want to limit the value of any single CA keypair, so that if anything very bad happens, you don't have to nuke the entirey PKI, but only that part of it that is actually affected. Limiting the number of certs that are signed with a single CA keypair can significantly help here, and will work with every conforming RP, while only partitioning CRLs based on distribution point will not help at all, but may create interop problems with conforming RPs and makes things actually slower, because the CA MUST still provide the full CRL in addtion to the zoo of partitioned CRLs, and it is difficult to see how you can mix them in a fashion that they not intefere with each other, becaus the CRL distribution point extension of the certificate (rather than that of the CRL) does not support paritioning of CRLs based on distribution point names, only on reason codes. > > > > > > In reality CAs can issue 10M certificates within days, I surely don't > > want to renew these CAs as that pace. > > That is not necessarily a problem, if you do not expect your CRLs to grow at the same rate (10M revocations within days). > > > The partitioning of CRLs by distribution point is ill-conceived, no matter how you look at it. Whether a CA uses partitioning by CRL distribution point is *NOT* visible in the CRL distribution point extension of the Certificate at all! > > Quoting from rfc5280 Section 6.3: > http://tools.ietf.org/html/rfc5280#section-6.3 > > This algorithm assumes that all of the needed CRLs are available in a > local cache. Further, if the next update time of a CRL has passed, > the algorithm assumes a mechanism to fetch a current CRL and place it > in the local CRL cache. > > An RP with an efficient implementation of revocation checking will be using CRLs, cache the CRLs and update the CRL cache strictly out-of-band, so that a revocation check will incur a single table lookup keying on issuer&serial, and zero PK-crypto operations and zero third party network communication in-band while authenticating peers. > > > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From DPKemp@missi.ncsc.mil Tue Feb 21 14:04:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141E521F86F5 for ; Tue, 21 Feb 2012 14:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4p6m6el-aoz for ; Tue, 21 Feb 2012 14:04:17 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1B50621F86EA for ; Tue, 21 Feb 2012 14:04:14 -0800 (PST) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q1LM4Df7069954 for ; Tue, 21 Feb 2012 17:04:13 -0500 (EST) Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 17:05:22 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 21 Feb 2012 17:04:11 -0500 Message-ID: In-Reply-To: <4F3FE245.4050706@primekey.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Thread-Index: AczuZENXxBizXrVDRf6FHz74x7vdyACfG9nw References: <201202171503.q1HF3mvs026601@fs4113.wdf.sap.corp><4F3FE1F1.4080001@primekey.se> <4F3FE245.4050706@primekey.se> From: "Kemp, David P." To: X-OriginalArrivalTime: 21 Feb 2012 22:05:22.0968 (UTC) FILETIME=[E86EB180:01CCF0E4] Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 22:04:18 -0000 OCSP requires more bandwidth (at least 4x, usually much more) for any given number of certs. In the limit (infinite number of certs, none revoked), OCSP requires infinite bandwidth while an empty CRL is ~200 octets. CRL stapling is quite practical for CRLs partitioned to cover 100 certs each, and can be regarded as a very efficient replacement for short-lived certs. Dave -----Original Message----- From: Tomas Gustavsson I think a better alternative is to abandon CRLs for these types of CAs and use other mechanisms, like OCSP. If appropriate for the RPs of course... As usual the number of different use cases are not bounded. /Tomas From ryan.hurst@globalsign.com Tue Feb 21 14:08:12 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D93611E8094 for ; Tue, 21 Feb 2012 14:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wE0XL-3xS21 for ; Tue, 21 Feb 2012 14:08:11 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D72E511E808A for ; Tue, 21 Feb 2012 14:08:11 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so8172515pbc.31 for ; Tue, 21 Feb 2012 14:08:11 -0800 (PST) Received-SPF: pass (google.com: domain of ryan.hurst@globalsign.com designates 10.68.74.197 as permitted sender) client-ip=10.68.74.197; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ryan.hurst@globalsign.com designates 10.68.74.197 as permitted sender) smtp.mail=ryan.hurst@globalsign.com Received: from mr.google.com ([10.68.74.197]) by 10.68.74.197 with SMTP id w5mr79861987pbv.129.1329862091769 (num_hops = 1); Tue, 21 Feb 2012 14:08:11 -0800 (PST) Received: by 10.68.74.197 with SMTP id w5mr65791113pbv.129.1329862091587; Tue, 21 Feb 2012 14:08:11 -0800 (PST) Received: from [10.69.177.47] (mobile-198-228-222-250.mycingular.net. [198.228.222.250]) by mx.google.com with ESMTPS id f3sm17069671pbr.61.2012.02.21.14.08.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Feb 2012 14:08:10 -0800 (PST) References: <201202171503.q1HF3mvs026601@fs4113.wdf.sap.corp> <4F3FE1F1.4080001@primekey.se> <4F3FE245.4050706@primekey.se> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9A406) From: Ryan Hurst Date: Tue, 21 Feb 2012 14:08:05 -0800 To: "Kemp, David P." X-Gm-Message-State: ALoCoQlsznVKp3tSHqS3Ec7U7pM6Vjrs4lFkKUycdis3p4d+NKml5ziLAyvam2O5wocoWT1s9NSd Cc: "" Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 22:08:12 -0000 Short lived certificates however have the side effect of addressing the key m= anagement issues that plague operational environments. Sent from my iPhone On Feb 21, 2012, at 2:04 PM, "Kemp, David P." wrote:= > OCSP requires more bandwidth (at least 4x, usually much more) for any > given number of certs. In the limit (infinite number of certs, none > revoked), OCSP requires infinite bandwidth while an empty CRL is ~200 > octets. CRL stapling is quite practical for CRLs partitioned to cover > 100 certs each, and can be regarded as a very efficient replacement for > short-lived certs. >=20 > Dave >=20 >=20 >=20 > -----Original Message----- > From: Tomas Gustavsson >=20 > I think a better alternative is to abandon CRLs for these types of CAs > and use other mechanisms, like OCSP. If appropriate for the RPs of > course... >=20 > As usual the number of different use cases are not bounded. >=20 > /Tomas >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From tomas@primekey.se Tue Feb 21 15:00:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA33521F86F0 for ; Tue, 21 Feb 2012 15:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sai0-pX4kN6I for ; Tue, 21 Feb 2012 15:00:05 -0800 (PST) Received: from mail.primekey.se (mail.primekey.se [213.179.18.11]) by ietfa.amsl.com (Postfix) with ESMTP id DC5A621F86EC for ; Tue, 21 Feb 2012 15:00:04 -0800 (PST) Received: from mail.primekey.se (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id EC7CDE286B for ; Wed, 22 Feb 2012 00:00:06 +0100 (CET) Received: from [192.168.122.80] (smart150.bb.netvision.net.il [212.143.76.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.se (Postfix) with ESMTPSA id 70660E2801 for ; Wed, 22 Feb 2012 00:00:06 +0100 (CET) Message-ID: <4F4421F0.7030809@primekey.se> Date: Wed, 22 Feb 2012 01:00:00 +0200 From: Tomas Gustavsson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120217 Thunderbird/11.0 MIME-Version: 1.0 To: pkix@ietf.org References: <201202171503.q1HF3mvs026601@fs4113.wdf.sap.corp><4F3FE1F1.4080001@primekey.se> <4F3FE245.4050706@primekey.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 23:00:06 -0000 On 02/22/2012 12:04 AM, Kemp, David P. wrote: > OCSP requires more bandwidth (at least 4x, usually much more) for any > given number of certs. In the limit (infinite number of certs, none > revoked), OCSP requires infinite bandwidth while an empty CRL is ~200 > octets. CRL stapling is quite practical for CRLs partitioned to cover > 100 certs each, and can be regarded as a very efficient replacement for > short-lived certs. If we are into unrealistic scenarios, how about inifinite number of certificates, 50% revoked, inifinite number of CAs, 10 minute CRL expire period, 1 client connection every 20 minutes? I think OCSP wins in this case. God thing the world is not quite infinite :-) Cheers, Tomas > > Dave > > > > -----Original Message----- > From: Tomas Gustavsson > > I think a better alternative is to abandon CRLs for these types of CAs > and use other mechanisms, like OCSP. If appropriate for the RPs of > course... > > As usual the number of different use cases are not bounded. > > /Tomas > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From SChokhani@cygnacom.com Wed Feb 22 02:24:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5307721F8828 for ; Wed, 22 Feb 2012 02:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkDJjDWaeXfb for ; Wed, 22 Feb 2012 02:24:56 -0800 (PST) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id A77F121F880F for ; Wed, 22 Feb 2012 02:24:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,463,1325480400"; d="scan'208";a="428961" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 22 Feb 2012 05:24:46 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Wed, 22 Feb 2012 05:24:46 -0500 From: Santosh Chokhani To: "mrex@sap.com" Date: Wed, 22 Feb 2012 05:21:13 -0500 Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Thread-Index: AczwpfvhKSRVYaigQ1KCJjefwcRbhAApafqA Message-ID: References: from "Santosh Chokhani" at Feb 20, 12 07:59:56 pm <201202211434.q1LEYm9o026940@fs4113.wdf.sap.corp> In-Reply-To: <201202211434.q1LEYm9o026940@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 10:24:57 -0000 Your formal logic in this case is in serious need of debugging. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Tuesday, February 21, 2012 9:35 AM To: Santosh Chokhani Cc: pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Santosh Chokhani wrote: >=20 > As mentioned before the author of the e-mail reads 5280 incorrectly=20 > and has exhibited a genuine lack of understanding or refusal to=20 > understand how IDP, CRL DP and partitioning work. I'm only reading the specification the way it is written. And I'm apply formal logic to determine the "permissible interpretations" for those many areas that are unclear and ambiguous. Your interpretation of the spec, while not uncommon for people arguing natu= ral language, is outside of formally valid interpretation, I'm sorry. -Martin =20 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf=20 > Of Martin Rex > Sent: Monday, February 20, 2012 10:38 AM > To: Tomas Gustavsson > Cc: pkix@ietf.org > Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer >=20 > Tomas Gustavsson wrote: > >=20 > > Martin Rex wrote: > > > Tomas Gustavsson wrote: > > >> > > >> Just as a funny of-topic mention. A CRL with 10M revoked entries=20 > > >> is about 400-500MB large. Very useful :-) > > > > > > As I indicated here: > > > =20 > > > https://www.ietf.org/mail-archive/web/pkix/current/msg29842.html > > > > > > I strongly believe that a CA (i.e. that specific DName) should be=20 > > > retired when the expected growth of the CRL during the remaining=20 > > > lifetime of the all certs singed with that exact issuer DName=20 > > > exceeds a reasonable size. > > > > > > The US government is operating several CAs with CRLs carrying>1=20 > > > million CRLEntries (1080 Millon =3D 22 MBytes), which is IMO far=20 > > > beyond a resonably sized CRL. > > > > > > Instead of partitioning CRLs, the CA should simply get a new CA=20 > > > cert issued (simply bumping a Serialnumber AVA in the subject=20 > > > DName of the CAs certificate would be sufficient), at which point=20 > > > it will automatically start with a fresh, empty CRL, and this will=20 > > > work nicely with *ALL* RPs. > >=20 > > Since CRLs needs to be maintained as long as the end entity=20 > > certificates are active, all issued end entity certificates of a=20 > > given CA can potentially become revoked, hence the CRL may contain all = these entries. >=20 > I had that case explicitly covered above. Not a problem. Just move to a= different CA cert early enough. This is not about worst case, but what sh= ould be reasonably expected, with some safety margin. >=20 >=20 > >=20 > > This means that any given CA is only allowed to issue as many=20 > > certificates as is reasonable to have on a CRL. If you think it is=20 > > 500.000, any given CA is only allowed to issue 500.000 CRLs, this=20 > > seems cumbersome way beyond usability. >=20 > Just the contrary. Managing risk sensibly means that you want to limit t= he value of any single CA keypair, so that if anything very bad happens, yo= u don't have to nuke the entirey PKI, but only that part of it that is actu= ally affected. Limiting the number of certs that are signed with a single = CA keypair can significantly help here, and will work with every conforming= RP, while only partitioning CRLs based on distribution point will not help= at all, but may create interop problems with conforming RPs and makes thin= gs actually slower, because the CA MUST still provide the full CRL in addti= on to the zoo of partitioned CRLs, and it is difficult to see how you can m= ix them in a fashion that they not intefere with each other, becaus the CRL= distribution point extension of the certificate (rather than that of the C= RL) does not support paritioning of CRLs based on distribution point names,= only on reason codes. >=20 >=20 > >=20 > > In reality CAs can issue 10M certificates within days, I surely=20 > > don't want to renew these CAs as that pace. >=20 > That is not necessarily a problem, if you do not expect your CRLs to grow= at the same rate (10M revocations within days). >=20 >=20 > The partitioning of CRLs by distribution point is ill-conceived, no matte= r how you look at it. Whether a CA uses partitioning by CRL distribution p= oint is *NOT* visible in the CRL distribution point extension of the Certif= icate at all! >=20 > Quoting from rfc5280 Section 6.3: > http://tools.ietf.org/html/rfc5280#section-6.3 >=20 > This algorithm assumes that all of the needed CRLs are available in a > local cache. Further, if the next update time of a CRL has passed, > the algorithm assumes a mechanism to fetch a current CRL and place it > in the local CRL cache. >=20 > An RP with an efficient implementation of revocation checking will be usi= ng CRLs, cache the CRLs and update the CRL cache strictly out-of-band, so t= hat a revocation check will incur a single table lookup keying on issuer&se= rial, and zero PK-crypto operations and zero third party network communicat= ion in-band while authenticating peers. >=20 >=20 > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix >=20 From robert@hernady.cz Tue Feb 21 23:30:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4354B21E8088 for ; Tue, 21 Feb 2012 23:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[AWL=0.648, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nifeygGkUEza for ; Tue, 21 Feb 2012 23:30:40 -0800 (PST) Received: from mail.firma6p.cz (mail.firma6p.cz [85.207.51.98]) by ietfa.amsl.com (Postfix) with ESMTP id B5D7D21E8065 for ; Tue, 21 Feb 2012 23:30:38 -0800 (PST) Received: from POSTAK1.firma6p.cz ([fe80::1846:13ff:5ea7:18b1]) by postak1.firma6p.cz ([fe80::1846:13ff:5ea7:18b1%11]) with mapi id 14.01.0355.002; Wed, 22 Feb 2012 08:30:32 +0100 From: Robert Hernady To: "pkix@ietf.org" Thread-Topic: Explanation of the OCSP sign request (RFC 2560) Thread-Index: AczxM6SXUb792kJAQImnV/qAqd3S+Q== Date: Wed, 22 Feb 2012 07:30:31 +0000 Message-ID: Accept-Language: cs-CZ, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.0.1] Content-Type: multipart/alternative; boundary="_000_A025E9A3487E4B44B7112C4430DA8252A3BA1B29postak1firma6pc_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 22 Feb 2012 05:48:04 -0800 Subject: [pkix] Explanation of the OCSP sign request (RFC 2560) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 07:30:41 -0000 --_000_A025E9A3487E4B44B7112C4430DA8252A3BA1B29postak1firma6pc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I'm looking for the better understanding for the RFC 2560 Online Certifica= te Status Protocol - OCSP. The section 4.1 defines the ASN.1 structure for the OCSP request. Follows t= he shortened structure. OCSPRequest TBSRequest OPTIONAL Signature, where the signature is marked as OPTIONAL. That one leads to the conclusion= that signing of the OCSP request is not required and the implementer of th= e OCSP client MAY digitally sign that request. But the section 2.3 Exception Cases defines error types and one of them is= "-sigRequired" The response "sigRequired" is returned in cases where the server requires the client sign the request in order to construct a response. Does it mean that in that case the signature of the request becomes mandato= ry? Does it mean that OCSP clients that have not implemented OCSP request s= igning after receiving error "-sigRequired" are breaking this RFC? Thanks in advance Robert Hernady --_000_A025E9A3487E4B44B7112C4430DA8252A3BA1B29postak1firma6pc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’m looking for the bette= r understanding for the RFC 2560  Online Certificate Status Protocol – OCSP.

 

The section 4.1 defines the ASN= .1 structure for the OCSP request. Follows the shortened structure.

<= o:p> 

O= CSPRequest

&= nbsp;  TBSRequest

&= nbsp;  OPTIONAL Signature,

<= o:p> 

w= here the signature is marked as OPTIONAL. That one leads to the conclusion = that signing of the OCSP request is not required and the implementer of the= OCSP client MAY digitally sign that request.

<= o:p> 

B= ut the section 2.3  Exception Cases defines error types and one of the= m is “—sigRequired”

<= o:p> 

   The response "si= gRequired" is returned in cases where the server

   requires the client s= ign the request in order to construct a

   response.<= /span>

<= o:p> 

<= o:p> 

Does it mean that in that case = the signature of the request becomes mandatory? Does it mean that OCSP clie= nts that have not implemented OCSP request signing after receiving error &#= 8220;—sigRequired” are breaking this RFC?

 

Thanks in advance

 

Robert Hernady

 

--_000_A025E9A3487E4B44B7112C4430DA8252A3BA1B29postak1firma6pc_-- From tmiller@mitre.org Wed Feb 22 05:53:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5374E21F87E5 for ; Wed, 22 Feb 2012 05:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMowxAgKw1MT for ; Wed, 22 Feb 2012 05:53:02 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4198F21F87E4 for ; Wed, 22 Feb 2012 05:53:02 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B63B421B1878 for ; Wed, 22 Feb 2012 08:53:01 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A05AC21B1880 for ; Wed, 22 Feb 2012 08:53:01 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.10]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Wed, 22 Feb 2012 08:53:01 -0500 From: "Miller, Timothy J." To: "pkix@ietf.org" Thread-Topic: [pkix] Explanation of the OCSP sign request (RFC 2560) Thread-Index: AczxM6SXUb792kJAQImnV/qAqd3S+QALUG6A Date: Wed, 22 Feb 2012 13:53:01 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.31.35.86] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Explanation of the OCSP sign request (RFC 2560) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 13:53:06 -0000 The signature is optional per the protocol spec, but a specific server implementation is allowed to make it mandatory. That's pretty standard behavior--you (the implementor or deployer) are free to required options that make sense in your environment. Personally I'm not sure why anyone would make sigs mandatory on OCSP requests, but I'm sure someone can come up with a reason. :) -- T On 2/22/12 1:30 AM, "Robert Hernady" wrote: >Hi, >=20 >I=B9m looking for the better understanding for the RFC >2560 Online Certificate Status Protocol =AD OCSP. >=20 >The section 4.1 defines the ASN.1 structure for the OCSP request. Follows >the shortened structure. > >=20 >OCSPRequest > > TBSRequest > > OPTIONAL Signature, >=20 >where the signature is marked as OPTIONAL. That one leads to the >conclusion that signing of the OCSP request is not required and the >implementer of the OCSP client MAY digitally sign that request. > >=20 >But the section 2.3 Exception Cases defines error types and one of them >is =B3=8BsigRequired=B2 >=20 > The response "sigRequired" is returned in cases where the server > requires the client sign the request in order to construct a > response. >=20 >=20 >Does it mean that in that case the signature of the request becomes >mandatory? Does it mean that OCSP clients that have not implemented OCSP >request signing after receiving error =B3=8BsigRequired=B2 are breaking th= is >RFC? > >=20 >Thanks in advance >=20 >Robert Hernady >=20 > > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From DPKemp@missi.ncsc.mil Wed Feb 22 06:54:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816F621F865A for ; Wed, 22 Feb 2012 06:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiMLnds0o7bu for ; Wed, 22 Feb 2012 06:54:00 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id CDA1B21F870F for ; Wed, 22 Feb 2012 06:53:59 -0800 (PST) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q1MErxg5083554 for ; Wed, 22 Feb 2012 09:53:59 -0500 (EST) Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 09:55:08 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 22 Feb 2012 09:53:58 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Thread-Index: Aczw5U8Rw9eD6Q+DT3mZ5OcDtd3+iQAiJFOA References: <201202171503.q1HF3mvs026601@fs4113.wdf.sap.corp> <4F3FE1F1.4080001@primekey.se> <4F3FE245.4050706@primekey.se> From: "Kemp, David P." To: X-OriginalArrivalTime: 22 Feb 2012 14:55:08.0296 (UTC) FILETIME=[F81A1880:01CCF171] Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 14:54:02 -0000 Only in very limited circumstances. 1) Short-lived certificates can renew (extend validity only) or rekey. Renew is trivially easy and is the normal use case for short-lived certs, but it doesn't address key management. 2) Key management must address loss/destruction of key, detected compromise, and undetected compromise. Loss/destruction/detected compromise are all handled the same way regardless of cert lifetime: a new cert is issued since the old key can't be used to support rekey. 3) Undetected compromise allows either the adversary or the subscriber, but not both, to rekey, so it provides some compromise detection capability when the subscriber is denied a rekey. This detection happens more quickly with short-lived certs. So rekeying at frequent intervals provides a potential advantage over infrequent rekeying in the case of undetected exposure of a key that remains usable by the subscriber. But that's a pretty small subset of key management issues. Dave -----Original Message----- From: Ryan Hurst [mailto:ryan.hurst@globalsign.com]=20 Sent: Tuesday, February 21, 2012 5:08 PM To: Kemp, David P. Cc: Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Short lived certificates however have the side effect of addressing the key management issues that plague operational environments. Sent from my iPhone On Feb 21, 2012, at 2:04 PM, "Kemp, David P." wrote: > OCSP requires more bandwidth (at least 4x, usually much more) for any=20 > given number of certs. In the limit (infinite number of certs, none=20 > revoked), OCSP requires infinite bandwidth while an empty CRL is ~200=20 > octets. CRL stapling is quite practical for CRLs partitioned to cover > 100 certs each, and can be regarded as a very efficient replacement=20 > for short-lived certs. >=20 > Dave >=20 >=20 >=20 > -----Original Message----- > From: Tomas Gustavsson >=20 > I think a better alternative is to abandon CRLs for these types of CAs > and use other mechanisms, like OCSP. If appropriate for the RPs of=20 > course... >=20 > As usual the number of different use cases are not bounded. >=20 > /Tomas >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From rstruik.ext@gmail.com Wed Feb 22 07:58:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19F621F8824 for ; Wed, 22 Feb 2012 07:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.301 X-Spam-Level: X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kbry7pn6sDft for ; Wed, 22 Feb 2012 07:58:01 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D2DCC21F85D3 for ; Wed, 22 Feb 2012 07:57:57 -0800 (PST) Received: by yhkk25 with SMTP id k25so124374yhk.31 for ; Wed, 22 Feb 2012 07:57:57 -0800 (PST) Received-SPF: pass (google.com: domain of rstruik.ext@gmail.com designates 10.50.207.99 as permitted sender) client-ip=10.50.207.99; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rstruik.ext@gmail.com designates 10.50.207.99 as permitted sender) smtp.mail=rstruik.ext@gmail.com; dkim=pass header.i=rstruik.ext@gmail.com Received: from mr.google.com ([10.50.207.99]) by 10.50.207.99 with SMTP id lv3mr27397237igc.24.1329926277547 (num_hops = 1); Wed, 22 Feb 2012 07:57:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=3+E/4V16YFWUzZgNWI0WHcvgZEHP5gZXxvC+4TfzwkA=; b=hfWNs3421XYY6Sw3dPtIpfo/BVNUsjfu2QSOMjiY3Cm5S+26EdHOdwrhPkJQTDYITs xy2VAhhKhMWAr+wpdtrXgjaW+uEqoR5xsfs1QfrVg9hgJm1uMhr3OlxKpGCNSgLhKA52 LOzPLdHOTtDSAkfArL70Zb3FijDR+BXNLbQlY= Received: by 10.50.207.99 with SMTP id lv3mr22251488igc.24.1329926277258; Wed, 22 Feb 2012 07:57:57 -0800 (PST) Received: from [192.168.1.101] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [173.34.96.176]) by mx.google.com with ESMTPS id f8sm37630187ibl.6.2012.02.22.07.57.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Feb 2012 07:57:56 -0800 (PST) Message-ID: <4F451073.2050404@gmail.com> Date: Wed, 22 Feb 2012 10:57:39 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Kemp, David P." References: <201202171503.q1HF3mvs026601@fs4113.wdf.sap.corp> <4F3FE1F1.4080001@primekey.se> <4F3FE245.4050706@primekey.se> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: pkix@ietf.org Subject: [pkix] The case for short-lived vs. long-lived certificates (was: Re: AuthKeyId and CrlEntryExtension.CertificateIssuer) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 15:58:02 -0000 Dear collagues: Some papers of interest here include Ron Rivest's [1] advocacy for short-lived certs (1998) and Rubin et al's [2] response (2001). In those papers, arguments underlying picks for short-lived certs vs. certificate checks during stated lifetime center around a) computational overhead. Cost of generating a certificate (or, more precisely, cost of certificate [renewal] request, response sequence). b) communication overhead. Cost of the protocol messaging to and from the CA for issuing a new cert, resp. cost for messaging to and from server who arbitrages into okaying a current certificate on the spot. My own perspective is as follows: For networks with lack of "online" connectivity, availability of an arbitraging server on the spot cannot be assumed *and* could impose a huge communication bandwidth burden (case in point: sensors). For those networks, short-lived certs (that provide positive evidence of authentic binding, without "only maybe valid, but please check" semantics), seem to be more suitable. Here, a device can try and obtain a new credential (with associated "new lease of life") from the CA, when it is available to do so (and a moment of its choosing). Contrast this with longer-lived certs (with "only maybe valid, but please check" semantics), where the ambiguous assertion on validity forces an almost immediate connection with an arbitraging agent somewhere in the network (be it using OCSP or for CRL checking). The traditional argument that computational cost of generating certificates is too expensive seems to be less valid now, witness the progress in efficient implementations of cryptographic algorithms over the last decade. Moreover, some of the cost can be amortized via hybrid schemes, such as Micali's [3], that essentially trade the cost of generating n certificates, each valid for 1 time unit, for the cost of generating 1 certificate conditionally valid for n time units and the cost of computing a Lamport-style hash chain of length n, each representing validity for another time unit. The main reason for certificate revocation right now seems to be "change of authorization" (organizational change, change of policies), rather than "change of authentication" (compromised device or key). For authorization triggers, providing a "positively valid" credential seems far more effective than providing a "maybe valid, but please check" credential. For authentication changes, indeed, all bets are off until detection, irrespective of the scheme, but once compromise has been detected, long-lived credentials keep polluting the network and requiring checks with an arbitraging agent, while short-lived certs just cease to exist after their short moment under the sun. Here, one should bear in mind that detection time windows are often of human time-scale, so trying and making certs extremely short-lived (i.e., well below practical loss/compromise reporting and processing time window) may not add too much value here. In summary, the case for short-lived certs seems to be quite compelling (presuming devices have a reliable notion of time). This being said, I would suggest revisiting the papers below, re-weighing the arguments and metrics used over a decade ago, and seeing for yourself. [1] R.L. Rivest, “Can We Eliminate Certificate Revocation Lists?,” in Financial Cryptography - FC’98, R. Hirschfeld, Ed., Lecture Notes in Computer Science, Vol. 1465, pp. 178-183, Springer, 1998. [2] P. McDaniel, A. Rubin, “A Response to “Can We Eliminate Certificate Revocation Lists?”,” in Financial Cryptography - FC 2000, Y. Frankel, Ed., Lecture Notes in Computer Science, Vol. 1962, pp. 245-258, Springer, 2001. [3] S. Micali, “Efficient Certificate Revocation,” Technical Report TM-542b, MIT Laboratory for Computer Science, March 22, 1996 On 22/02/2012 9:53 AM, Kemp, David P. wrote: > Only in very limited circumstances. > > 1) Short-lived certificates can renew (extend validity only) or rekey. > Renew is trivially easy and is the normal use case for short-lived > certs, but it doesn't address key management. > 2) Key management must address loss/destruction of key, detected > compromise, and undetected compromise. Loss/destruction/detected > compromise are all handled the same way regardless of cert lifetime: a > new cert is issued since the old key can't be used to support rekey. > 3) Undetected compromise allows either the adversary or the subscriber, > but not both, to rekey, so it provides some compromise detection > capability when the subscriber is denied a rekey. This detection > happens more quickly with short-lived certs. > > So rekeying at frequent intervals provides a potential advantage over > infrequent rekeying in the case of undetected exposure of a key that > remains usable by the subscriber. But that's a pretty small subset of > key management issues. > > Dave > > > -----Original Message----- > From: Ryan Hurst [mailto:ryan.hurst@globalsign.com] > Sent: Tuesday, February 21, 2012 5:08 PM > To: Kemp, David P. > Cc: > Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer > > Short lived certificates however have the side effect of addressing the > key management issues that plague operational environments. > > Sent from my iPhone > > On Feb 21, 2012, at 2:04 PM, "Kemp, David P." > wrote: > >> OCSP requires more bandwidth (at least 4x, usually much more) for any >> given number of certs. In the limit (infinite number of certs, none >> revoked), OCSP requires infinite bandwidth while an empty CRL is ~200 >> octets. CRL stapling is quite practical for CRLs partitioned to cover >> 100 certs each, and can be regarded as a very efficient replacement >> for short-lived certs. >> >> Dave >> >> >> >> -----Original Message----- >> From: Tomas Gustavsson >> >> I think a better alternative is to abandon CRLs for these types of CAs >> and use other mechanisms, like OCSP. If appropriate for the RPs of >> course... >> >> As usual the number of different use cases are not bounded. >> >> /Tomas >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From simon@tardell.se Wed Feb 22 08:57:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01EF621F88BC for ; Wed, 22 Feb 2012 08:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPM73gFYZkQe for ; Wed, 22 Feb 2012 08:57:22 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 73EB621E8012 for ; Wed, 22 Feb 2012 08:57:21 -0800 (PST) Received: by lahl5 with SMTP id l5so312724lah.31 for ; Wed, 22 Feb 2012 08:57:21 -0800 (PST) Received-SPF: pass (google.com: domain of simon@tardell.se designates 10.152.129.69 as permitted sender) client-ip=10.152.129.69; Authentication-Results: mr.google.com; spf=pass (google.com: domain of simon@tardell.se designates 10.152.129.69 as permitted sender) smtp.mail=simon@tardell.se; dkim=pass header.i=simon@tardell.se Received: from mr.google.com ([10.152.129.69]) by 10.152.129.69 with SMTP id nu5mr24009161lab.9.1329929841179 (num_hops = 1); Wed, 22 Feb 2012 08:57:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tardell.se; s=delta; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=eIMRJjAw2YjDPISlWZ8G4OssQMdf+YuHqQ0qKi10Ruw=; b=Xl5kQfAd+L82dw1bYHPLPAm2sxK8HYaomjnYA3zbqnSD/IcK8CLw9THaQG4HkKkPIs sqYGEyzSKvwO6CiEdQIfO/ddY9qIP7LKNQcHCoEif8WQnyNQJcil9pQ2M0Pz1KqoQ6Zo 0Al99NbonIXpnCK2NrYUuyRYvjM5yLCG4JF78= Received: by 10.152.129.69 with SMTP id nu5mr20140308lab.9.1329929841086; Wed, 22 Feb 2012 08:57:21 -0800 (PST) Received: from [192.168.0.5] (ua-83-227-240-7.cust.bredbandsbolaget.se. [83.227.240.7]) by mx.google.com with ESMTPS id mc3sm25495264lab.12.2012.02.22.08.57.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Feb 2012 08:57:20 -0800 (PST) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <0BE07B94-1389-4C7B-8DC2-1A4D2E6CDD29@tardell.se> X-Mailer: iPhone Mail (9A405) From: Simon Tardell Date: Wed, 22 Feb 2012 17:55:27 +0100 To: "Miller, Timothy J." X-Gm-Message-State: ALoCoQlu/uSqUev6xAusrV6f5dLttkVaRh+ZWNHjukr9yEl/bDO5HmYDpGG+RhztmBU5rfGURW6h Cc: "pkix@ietf.org" Subject: Re: [pkix] Explanation of the OCSP sign request (RFC 2560) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 16:57:27 -0000 Sent from my iPhone On 22 feb 2012, at 14:53, "Miller, Timothy J." wrote: > Personally I'm not sure why anyone would make sigs mandatory on OCSP > requests, but I'm sure someone can come up with a reason. :) Billing. One not uncommon model in public PKIs is to enroll people for free but charg= e the relying party per use. /Simon= From piyush@identicate.com Wed Feb 22 11:04:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE1221F8501 for ; Wed, 22 Feb 2012 11:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xj3ujobYpUVy for ; Wed, 22 Feb 2012 11:04:38 -0800 (PST) Received: from col0-omc2-s8.col0.hotmail.com (col0-omc2-s8.col0.hotmail.com [65.55.34.82]) by ietfa.amsl.com (Postfix) with ESMTP id 56D9621F8637 for ; Wed, 22 Feb 2012 11:04:37 -0800 (PST) Received: from COL119-W13 ([65.55.34.71]) by col0-omc2-s8.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 11:04:36 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_d075a95d-a9db-438c-97fe-2f3775a0abfe_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: Date: Wed, 22 Feb 2012 11:04:36 -0800 Importance: Normal In-Reply-To: References: <201202171503.q1HF3mvs026601@fs4113.wdf.sap.corp><4F3FE1F1.4080001@primekey.se>, <4F3FE245.4050706@primekey.se>, MIME-Version: 1.0 X-OriginalArrivalTime: 22 Feb 2012 19:04:36.0687 (UTC) FILETIME=[D1F54DF0:01CCF194] Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 19:04:39 -0000 --_d075a95d-a9db-438c-97fe-2f3775a0abfe_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Interesting observation even though the example given doe not represent rea= l worl deployments. The CRLs (non partitioned) tend to grow in size as the number of certificat= es issued of the CA grows. =20 But it makes me wonder=2C why OCSP does not have the provision for efficien= tly returning the response for a range of certs without including the seria= l numbers explicitly. One enhancement in OCSP V2 (if it happens) could be to change certID so it= represents a range as opposed to single serial number. =20 For the example given below a single OCSP response (srart serial =3D -infin= ity=2C end serial =3D +infinity=2C status=3Dgood) can be used for all the c= ertificates issued by that CA. =20 And this approach would greatly reduce the computational and bandwidth requ= irement in deployments that pre-sign OCSP responses. =20 -Piyush > Date: Tue=2C 21 Feb 2012 17:04:11 -0500 > From: DPKemp@missi.ncsc.mil > To: pkix@ietf.org > Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer >=20 > OCSP requires more bandwidth (at least 4x=2C usually much more) for any > given number of certs. In the limit (infinite number of certs=2C none > revoked)=2C OCSP requires infinite bandwidth while an empty CRL is ~200 > octets. CRL stapling is quite practical for CRLs partitioned to cover > 100 certs each=2C and can be regarded as a very efficient replacement for > short-lived certs. >=20 > Dave >=20 >=20 >=20 > -----Original Message----- > From: Tomas Gustavsson >=20 > I think a better alternative is to abandon CRLs for these types of CAs > and use other mechanisms=2C like OCSP. If appropriate for the RPs of > course... >=20 > As usual the number of different use cases are not bounded. >=20 > /Tomas >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix = --_d075a95d-a9db-438c-97fe-2f3775a0abfe_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Interesting observation even though the example given doe not represent rea= l worl deployments.
The CRLs (non partitioned) tend to grow in size as t= he number of certificates issued of the CA grows.

But it makes me w= onder=2C why OCSP does not have the provision for efficiently returning the= response for a range of certs without including the serial numbers explici= tly.

One enhancement in OCSP V2 (if it happens) could be to change = certID so it represents a range as opposed to single serial number.
For the example given below a single OCSP response (srart serial =3D -infi= nity=2C end serial =3D +infinity=2C status=3Dgood) can be used for all the = certificates issued by that CA.

And this approach would greatly red= uce the computational and bandwidth requirement in deployments that pre-sig= n OCSP responses.

-Piyush

 =3B
>=3B Date: Tue=2C 21 Feb 2012 17:04:11 -0500
>= =3B From: DPKemp@missi.ncsc.mil
>=3B To: pkix@ietf.org
>=3B Subje= ct: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer
>=3B =
>=3B OCSP requires more bandwidth (at least 4x=2C usually much more) = for any
>=3B given number of certs. In the limit (infinite number of = certs=2C none
>=3B revoked)=2C OCSP requires infinite bandwidth while = an empty CRL is ~200
>=3B octets. CRL stapling is quite practical for= CRLs partitioned to cover
>=3B 100 certs each=2C and can be regarded = as a very efficient replacement for
>=3B short-lived certs.
>=3B =
>=3B Dave
>=3B
>=3B
>=3B
>=3B -----Original Me= ssage-----
>=3B From: Tomas Gustavsson
>=3B
>=3B I think a = better alternative is to abandon CRLs for these types of CAs
>=3B and = use other mechanisms=2C like OCSP. If appropriate for the RPs of
>=3B = course...
>=3B
>=3B As usual the number of different use cases a= re not bounded.
>=3B
>=3B /Tomas
>=3B
>=3B __________= _____________________________________
>=3B pkix mailing list
>=3B= pkix@ietf.org
>=3B https://www.ietf.org/mailman/listinfo/pkix
= --_d075a95d-a9db-438c-97fe-2f3775a0abfe_-- From hallam@gmail.com Wed Feb 22 11:07:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937E421E8010 for ; Wed, 22 Feb 2012 11:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.413 X-Spam-Level: X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Fw0NOIJPaqU for ; Wed, 22 Feb 2012 11:07:21 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 54FD121F8637 for ; Wed, 22 Feb 2012 11:07:21 -0800 (PST) Received: by ghbg16 with SMTP id g16so272194ghb.31 for ; Wed, 22 Feb 2012 11:07:21 -0800 (PST) Received-SPF: pass (google.com: domain of hallam@gmail.com designates 10.60.1.4 as permitted sender) client-ip=10.60.1.4; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hallam@gmail.com designates 10.60.1.4 as permitted sender) smtp.mail=hallam@gmail.com; dkim=pass header.i=hallam@gmail.com Received: from mr.google.com ([10.60.1.4]) by 10.60.1.4 with SMTP id 4mr8587361oei.28.1329937641006 (num_hops = 1); Wed, 22 Feb 2012 11:07:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5QGSv+MbRamfaENr/wb4wiiv0GZiKSwpXCW5pOAaVkM=; b=YOdrROf6XkXZhDE02TE78iMPYfd3hyoPJe6chVdgDN0RoNurm5HP60+otrMr+44E1W drOytHPrV/+QnL1Qr8Se0WAxV1+Eb/ISbELdKQfOz3qI9xv07e9j/Yr3a9e63vkRg0sY 5EQeEG8r8bf2wH5t5+zqa71dsCl31nwY23k/8= MIME-Version: 1.0 Received: by 10.60.1.4 with SMTP id 4mr7345997oei.28.1329937640778; Wed, 22 Feb 2012 11:07:20 -0800 (PST) Received: by 10.182.38.97 with HTTP; Wed, 22 Feb 2012 11:07:20 -0800 (PST) In-Reply-To: <4F451073.2050404@gmail.com> References: <201202171503.q1HF3mvs026601@fs4113.wdf.sap.corp> <4F3FE1F1.4080001@primekey.se> <4F3FE245.4050706@primekey.se> <4F451073.2050404@gmail.com> Date: Wed, 22 Feb 2012 14:07:20 -0500 Message-ID: From: Phillip Hallam-Baker To: Rene Struik Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] The case for short-lived vs. long-lived certificates (was: Re: AuthKeyId and CrlEntryExtension.CertificateIssuer) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 19:07:22 -0000 There are two separate questions: 1) Where should we go 2) How do we get there I think Rivest's argument is essentially sound on CRLs with respect to the first question. The original paper was written round about the time that we were developing OCSP and even then it was apparent that the OCSP model is very close to being a certificate model. The second part is rather more difficult. Short lived certs and stapled OCSP responses have almost identical properties. But that does not mean that they are interchangeable. There is a deployed infrastructure that expects to make use of OCSP and CRLs. On Wed, Feb 22, 2012 at 10:57 AM, Rene Struik wrote= : > Dear collagues: > > Some papers of interest here include Ron Rivest's [1] advocacy for short-= lived certs (1998) and Rubin et al's [2] response (2001). > > In those papers, arguments underlying picks for short-lived certs vs. cer= tificate checks during stated lifetime center around > a) computational overhead. > Cost of generating a certificate (or, more precisely, cost of certificate= [renewal] request, response sequence). > b) communication overhead. > Cost of the protocol messaging to and from the CA for issuing a new cert,= resp. cost for messaging to and from server > who arbitrages into okaying a current certificate on the spot. > > My own perspective is as follows: > > For networks with lack of "online" connectivity, availability of an arbit= raging server on the spot cannot be assumed *and* could > impose a huge communication bandwidth burden (case in point: sensors). Fo= r those networks, short-lived certs (that provide positive > evidence of authentic binding, without "only maybe valid, but please chec= k" semantics), seem to be more suitable. Here, a device can > try and obtain a new credential (with associated "new lease of life") fro= m the CA, when it is available to do so (and a moment of its choosing). > Contrast this with longer-lived certs (with "only maybe valid, but please= check" semantics), where the ambiguous assertion on validity > forces an almost immediate connection with an arbitraging agent somewhere= in the network (be it using OCSP or for CRL checking). > > The traditional argument that computational cost of generating certificat= es is too expensive seems to be less valid now, witness the > progress in efficient implementations of cryptographic algorithms over th= e last decade. Moreover, some of the cost can be amortized > via hybrid schemes, such as Micali's [3], that essentially trade the cost= of generating n certificates, each valid for 1 time unit, for > the cost of generating 1 certificate conditionally valid for n time units= and the cost of computing a Lamport-style hash chain of > length n, each representing validity for another time unit. > > The main reason for certificate revocation right now seems to be "change = of authorization" (organizational change, change of policies), rather than > "change of authentication" (compromised device or key). For authorization= triggers, providing a "positively valid" credential seems far more > effective than providing a "maybe valid, but please check" credential. Fo= r authentication changes, indeed, all bets are off until detection, irrespe= ctive > of the scheme, but once compromise has been detected, long-lived credenti= als keep polluting the network and requiring checks with an arbitraging age= nt, > while short-lived certs just cease to exist after their short moment unde= r the sun. Here, one should bear in mind that detection time windows are of= ten > of human time-scale, so trying and making certs extremely short-lived (i.= e., well below practical loss/compromise reporting and processing time wind= ow) > may not add too much value here. > > In summary, the case for short-lived certs seems to be quite compelling (= presuming devices have a reliable notion of time). This being said, I would > suggest revisiting the papers below, re-weighing the arguments and metric= s used over a decade ago, and seeing for yourself. > > > [1] R.L. Rivest, > =93Can We Eliminate Certificate Revocation Lists?,=94 > in Financial Cryptography - FC=9298, R. Hirschfeld, Ed., > Lecture Notes in Computer Science, Vol. 1465, pp. 178-183, > Springer, 1998. > > [2] P. McDaniel, A. Rubin, > =93A Response to =93Can We Eliminate Certificate Revocation Lists?=94,=94 > in Financial Cryptography - FC 2000, Y. Frankel, Ed., > Lecture Notes in Computer Science, Vol. 1962, pp. 245-258, > Springer, 2001. > > [3] S. Micali, > =93Efficient Certificate Revocation,=94 Technical Report TM-542b, > MIT Laboratory for Computer Science, > March 22, 1996 > > > On 22/02/2012 9:53 AM, Kemp, David P. wrote: >> Only in very limited circumstances. >> >> 1) Short-lived certificates can renew (extend validity only) or rekey. >> Renew is trivially easy and is the normal use case for short-lived >> certs, but it doesn't address key management. >> 2) Key management must address loss/destruction of key, detected >> compromise, and undetected compromise. =A0Loss/destruction/detected >> compromise are all handled the same way regardless of cert lifetime: a >> new cert is issued since the old key can't be used to support rekey. >> 3) Undetected compromise allows either the adversary or the subscriber, >> but not both, to rekey, so it provides some compromise detection >> capability when the subscriber is denied a rekey. =A0This detection >> happens more quickly with short-lived certs. >> >> So rekeying at frequent intervals provides a potential advantage over >> infrequent rekeying in the case of undetected exposure of a key that >> remains usable by the subscriber. =A0But that's a pretty small subset of >> key management issues. >> >> Dave >> >> >> -----Original Message----- >> From: Ryan Hurst [mailto:ryan.hurst@globalsign.com] >> Sent: Tuesday, February 21, 2012 5:08 PM >> To: Kemp, David P. >> Cc: >> Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer >> >> Short lived certificates however have the side effect of addressing the >> key management issues that plague operational environments. >> >> Sent from my iPhone >> >> On Feb 21, 2012, at 2:04 PM, "Kemp, David P." >> wrote: >> >>> OCSP requires more bandwidth (at least 4x, usually much more) for any >>> given number of certs. =A0In the limit (infinite number of certs, none >>> revoked), OCSP requires infinite bandwidth while an empty CRL is ~200 >>> octets. =A0CRL stapling is quite practical for CRLs partitioned to cove= r >>> 100 certs each, and can be regarded as a very efficient replacement >>> for short-lived certs. >>> >>> Dave >>> >>> >>> >>> -----Original Message----- >>> From: Tomas Gustavsson >>> >>> I think a better alternative is to abandon CRLs for these types of CAs >>> and use other mechanisms, like OCSP. If appropriate for the RPs of >>> course... >>> >>> As usual the number of different use cases are not bounded. >>> >>> /Tomas >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > -- > email: rstruik.ext@gmail.com > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From rstruik.ext@gmail.com Wed Feb 22 11:28:17 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDFB21E8010 for ; Wed, 22 Feb 2012 11:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7X4XmJUbs1c for ; Wed, 22 Feb 2012 11:28:16 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 266A821F86D1 for ; Wed, 22 Feb 2012 11:28:16 -0800 (PST) Received: by ghbg16 with SMTP id g16so286199ghb.31 for ; Wed, 22 Feb 2012 11:28:15 -0800 (PST) Received-SPF: pass (google.com: domain of rstruik.ext@gmail.com designates 10.50.135.37 as permitted sender) client-ip=10.50.135.37; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rstruik.ext@gmail.com designates 10.50.135.37 as permitted sender) smtp.mail=rstruik.ext@gmail.com; dkim=pass header.i=rstruik.ext@gmail.com Received: from mr.google.com ([10.50.135.37]) by 10.50.135.37 with SMTP id pp5mr28690324igb.26.1329938895722 (num_hops = 1); Wed, 22 Feb 2012 11:28:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=5jpTd+uZqs4JnQt8iilrLojbDAru5Ruiv5RJb6t61b8=; b=ww5I8JwHw6mZKRgAatM/67UJ5a/HjRMkfGCKxWqBlTNiaoT4iRT2Ke5fstf3BduI7y gMA+3yaA4b0rKVKOWg1wenR3RMjKsZqCbNz5atxr546BSIZEfKibdIu1RY7lOjzVwBGj ZvAZligcSAAu0CwFZs3VJm854AgzNVrCdjb20= Received: by 10.50.135.37 with SMTP id pp5mr23227299igb.26.1329938895514; Wed, 22 Feb 2012 11:28:15 -0800 (PST) Received: from [192.168.43.48] ([207.245.236.60]) by mx.google.com with ESMTPS id e17sm38367971ibe.0.2012.02.22.11.28.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Feb 2012 11:28:14 -0800 (PST) Message-ID: <4F4541BB.8020005@gmail.com> Date: Wed, 22 Feb 2012 14:27:55 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <201202171503.q1HF3mvs026601@fs4113.wdf.sap.corp> <4F3FE1F1.4080001@primekey.se> <4F3FE245.4050706@primekey.se> <4F451073.2050404@gmail.com> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: pkix@ietf.org Subject: Re: [pkix] The case for short-lived vs. long-lived certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 19:28:17 -0000 Dear Phil: Unfortunately, current deployment in areas that could bear a particular solution direction often spills over in areas that cannot. A vivid example of this is smart grid/cybersecurity, where one has networks with sleepy devices and spotty connectivity at best and where minimizing communication traffic density (esp. the one that needs to be almost on-demand) is highly desirable. Here, emphasis on CRLs and OCSP may kill off the prospect of getting all those 30-50 billions of devices actually deployed or, in an attempt to make this work no matter what, will lead to network designs that at first may not hurt that much (e.g., centralized management approaches), but ultimately do not scale that well (but then it may be "too late", since the "backward compatibility requirement crowd" will make lots of noise on sunk investments and make it very hard to change course - not realizing that this may ultimately also significantly limit the deployment potential. For those networks (where "the other 99%" is not deployed yet), one should try and avoid imposing CRLs and other constructs that put a heavy just-in-time messaging demand on the network. In that respect, e.g., NIST IR 7628's Smart Grid Cybersecurity Framework may need some rethink and erasing of CRL/OCSP terms that may work or have worked reasonably well elsewhere, but transplanting this to a domain with entirely different characteristics may not. So, agreed with your question split, with the caveat that we should look beyond areas we are currently confortable with and know the characteristics of. Rene On 22/02/2012 2:07 PM, Phillip Hallam-Baker wrote: > There are two separate questions: > > 1) Where should we go > 2) How do we get there > > I think Rivest's argument is essentially sound on CRLs with respect to > the first question. The original paper was written round about the > time that we were developing OCSP and even then it was apparent that > the OCSP model is very close to being a certificate model. > > The second part is rather more difficult. Short lived certs and > stapled OCSP responses have almost identical properties. But that does > not mean that they are interchangeable. There is a deployed > infrastructure that expects to make use of OCSP and CRLs. > > > On Wed, Feb 22, 2012 at 10:57 AM, Rene Struik wrote: >> Dear collagues: >> >> Some papers of interest here include Ron Rivest's [1] advocacy for short-lived certs (1998) and Rubin et al's [2] response (2001). >> >> In those papers, arguments underlying picks for short-lived certs vs. certificate checks during stated lifetime center around >> a) computational overhead. >> Cost of generating a certificate (or, more precisely, cost of certificate [renewal] request, response sequence). >> b) communication overhead. >> Cost of the protocol messaging to and from the CA for issuing a new cert, resp. cost for messaging to and from server >> who arbitrages into okaying a current certificate on the spot. >> >> My own perspective is as follows: >> >> For networks with lack of "online" connectivity, availability of an arbitraging server on the spot cannot be assumed *and* could >> impose a huge communication bandwidth burden (case in point: sensors). For those networks, short-lived certs (that provide positive >> evidence of authentic binding, without "only maybe valid, but please check" semantics), seem to be more suitable. Here, a device can >> try and obtain a new credential (with associated "new lease of life") from the CA, when it is available to do so (and a moment of its choosing). >> Contrast this with longer-lived certs (with "only maybe valid, but please check" semantics), where the ambiguous assertion on validity >> forces an almost immediate connection with an arbitraging agent somewhere in the network (be it using OCSP or for CRL checking). >> >> The traditional argument that computational cost of generating certificates is too expensive seems to be less valid now, witness the >> progress in efficient implementations of cryptographic algorithms over the last decade. Moreover, some of the cost can be amortized >> via hybrid schemes, such as Micali's [3], that essentially trade the cost of generating n certificates, each valid for 1 time unit, for >> the cost of generating 1 certificate conditionally valid for n time units and the cost of computing a Lamport-style hash chain of >> length n, each representing validity for another time unit. >> >> The main reason for certificate revocation right now seems to be "change of authorization" (organizational change, change of policies), rather than >> "change of authentication" (compromised device or key). For authorization triggers, providing a "positively valid" credential seems far more >> effective than providing a "maybe valid, but please check" credential. For authentication changes, indeed, all bets are off until detection, irrespective >> of the scheme, but once compromise has been detected, long-lived credentials keep polluting the network and requiring checks with an arbitraging agent, >> while short-lived certs just cease to exist after their short moment under the sun. Here, one should bear in mind that detection time windows are often >> of human time-scale, so trying and making certs extremely short-lived (i.e., well below practical loss/compromise reporting and processing time window) >> may not add too much value here. >> >> In summary, the case for short-lived certs seems to be quite compelling (presuming devices have a reliable notion of time). This being said, I would >> suggest revisiting the papers below, re-weighing the arguments and metrics used over a decade ago, and seeing for yourself. >> >> >> [1] R.L. Rivest, >> “Can We Eliminate Certificate Revocation Lists?,” >> in Financial Cryptography - FC’98, R. Hirschfeld, Ed., >> Lecture Notes in Computer Science, Vol. 1465, pp. 178-183, >> Springer, 1998. >> >> [2] P. McDaniel, A. Rubin, >> “A Response to “Can We Eliminate Certificate Revocation Lists?”,” >> in Financial Cryptography - FC 2000, Y. Frankel, Ed., >> Lecture Notes in Computer Science, Vol. 1962, pp. 245-258, >> Springer, 2001. >> >> [3] S. Micali, >> “Efficient Certificate Revocation,” Technical Report TM-542b, >> MIT Laboratory for Computer Science, >> March 22, 1996 >> >> >> On 22/02/2012 9:53 AM, Kemp, David P. wrote: >>> Only in very limited circumstances. >>> >>> 1) Short-lived certificates can renew (extend validity only) or rekey. >>> Renew is trivially easy and is the normal use case for short-lived >>> certs, but it doesn't address key management. >>> 2) Key management must address loss/destruction of key, detected >>> compromise, and undetected compromise. Loss/destruction/detected >>> compromise are all handled the same way regardless of cert lifetime: a >>> new cert is issued since the old key can't be used to support rekey. >>> 3) Undetected compromise allows either the adversary or the subscriber, >>> but not both, to rekey, so it provides some compromise detection >>> capability when the subscriber is denied a rekey. This detection >>> happens more quickly with short-lived certs. >>> >>> So rekeying at frequent intervals provides a potential advantage over >>> infrequent rekeying in the case of undetected exposure of a key that >>> remains usable by the subscriber. But that's a pretty small subset of >>> key management issues. >>> >>> Dave >>> >>> >>> -----Original Message----- >>> From: Ryan Hurst [mailto:ryan.hurst@globalsign.com] >>> Sent: Tuesday, February 21, 2012 5:08 PM >>> To: Kemp, David P. >>> Cc: >>> Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer >>> >>> Short lived certificates however have the side effect of addressing the >>> key management issues that plague operational environments. >>> >>> Sent from my iPhone >>> >>> On Feb 21, 2012, at 2:04 PM, "Kemp, David P." >>> wrote: >>> >>>> OCSP requires more bandwidth (at least 4x, usually much more) for any >>>> given number of certs. In the limit (infinite number of certs, none >>>> revoked), OCSP requires infinite bandwidth while an empty CRL is ~200 >>>> octets. CRL stapling is quite practical for CRLs partitioned to cover >>>> 100 certs each, and can be regarded as a very efficient replacement >>>> for short-lived certs. >>>> >>>> Dave >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Tomas Gustavsson >>>> >>>> I think a better alternative is to abandon CRLs for these types of CAs >>>> and use other mechanisms, like OCSP. If appropriate for the RPs of >>>> course... >>>> >>>> As usual the number of different use cases are not bounded. >>>> >>>> /Tomas >>>> >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >> -- >> email: rstruik.ext@gmail.com >> Skype: rstruik >> cell: +1 (647) 867-5658 >> USA Google voice: +1 (415) 690-7363 >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From anders.rundgren@telia.com Wed Feb 22 12:02:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C76021E803F for ; Wed, 22 Feb 2012 12:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZuHqFHkto9F for ; Wed, 22 Feb 2012 12:02:15 -0800 (PST) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 2354921E800E for ; Wed, 22 Feb 2012 12:02:15 -0800 (PST) Received: from [192.168.0.200] (213.66.133.125) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4EFC380E00EB5342; Wed, 22 Feb 2012 21:02:13 +0100 Message-ID: <4F4549B0.6030004@telia.com> Date: Wed, 22 Feb 2012 21:01:52 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Rene Struik References: <201202171503.q1HF3mvs026601@fs4113.wdf.sap.corp> <4F3FE1F1.4080001@primekey.se> <4F3FE245.4050706@primekey.se> <4F451073.2050404@gmail.com> In-Reply-To: <4F451073.2050404@gmail.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: pkix@ietf.org Subject: Re: [pkix] The case for short-lived vs. long-lived certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 20:02:16 -0000 Mozillas recent BrowserID scheme relies on certificates that typically only last a web session so it seems that short-lived certificate actually "live", albeit not that long :-) A combination of short-lived certificates and thus comparatively small CRLs could also be an alternative for large enterprise or citizen CAs. Short-lived certificates is an intrinsic part of our passport system created by BSI and ICAO. Unfortunately they got it wrong and did the assumption that just because the initial key is an HSM, the renewed keys are automatically there as well. For that you need an attesting HSM and protocol, both which are unavailable or at least completely non-standard. Cheers, Anders On 2012-02-22 16:57, Rene Struik wrote: > Dear collagues: > > Some papers of interest here include Ron Rivest's [1] advocacy for short-lived certs (1998) and Rubin et al's [2] response (2001). > > In those papers, arguments underlying picks for short-lived certs vs. certificate checks during stated lifetime center around > a) computational overhead. > Cost of generating a certificate (or, more precisely, cost of certificate [renewal] request, response sequence). > b) communication overhead. > Cost of the protocol messaging to and from the CA for issuing a new cert, resp. cost for messaging to and from server > who arbitrages into okaying a current certificate on the spot. > > My own perspective is as follows: > > For networks with lack of "online" connectivity, availability of an arbitraging server on the spot cannot be assumed *and* could > impose a huge communication bandwidth burden (case in point: sensors). For those networks, short-lived certs (that provide positive > evidence of authentic binding, without "only maybe valid, but please check" semantics), seem to be more suitable. Here, a device can > try and obtain a new credential (with associated "new lease of life") from the CA, when it is available to do so (and a moment of its choosing). > Contrast this with longer-lived certs (with "only maybe valid, but please check" semantics), where the ambiguous assertion on validity > forces an almost immediate connection with an arbitraging agent somewhere in the network (be it using OCSP or for CRL checking). > > The traditional argument that computational cost of generating certificates is too expensive seems to be less valid now, witness the > progress in efficient implementations of cryptographic algorithms over the last decade. Moreover, some of the cost can be amortized > via hybrid schemes, such as Micali's [3], that essentially trade the cost of generating n certificates, each valid for 1 time unit, for > the cost of generating 1 certificate conditionally valid for n time units and the cost of computing a Lamport-style hash chain of > length n, each representing validity for another time unit. > > The main reason for certificate revocation right now seems to be "change of authorization" (organizational change, change of policies), rather than > "change of authentication" (compromised device or key). For authorization triggers, providing a "positively valid" credential seems far more > effective than providing a "maybe valid, but please check" credential. For authentication changes, indeed, all bets are off until detection, irrespective > of the scheme, but once compromise has been detected, long-lived credentials keep polluting the network and requiring checks with an arbitraging agent, > while short-lived certs just cease to exist after their short moment under the sun. Here, one should bear in mind that detection time windows are often > of human time-scale, so trying and making certs extremely short-lived (i.e., well below practical loss/compromise reporting and processing time window) > may not add too much value here. > > In summary, the case for short-lived certs seems to be quite compelling (presuming devices have a reliable notion of time). This being said, I would > suggest revisiting the papers below, re-weighing the arguments and metrics used over a decade ago, and seeing for yourself. > > > [1] R.L. Rivest, > “Can We Eliminate Certificate Revocation Lists?,” > in Financial Cryptography - FC’98, R. Hirschfeld, Ed., > Lecture Notes in Computer Science, Vol. 1465, pp. 178-183, > Springer, 1998. > > [2] P. McDaniel, A. Rubin, > “A Response to “Can We Eliminate Certificate Revocation Lists?”,” > in Financial Cryptography - FC 2000, Y. Frankel, Ed., > Lecture Notes in Computer Science, Vol. 1962, pp. 245-258, > Springer, 2001. > > [3] S. Micali, > “Efficient Certificate Revocation,” Technical Report TM-542b, > MIT Laboratory for Computer Science, > March 22, 1996 > > > On 22/02/2012 9:53 AM, Kemp, David P. wrote: >> Only in very limited circumstances. >> >> 1) Short-lived certificates can renew (extend validity only) or rekey. >> Renew is trivially easy and is the normal use case for short-lived >> certs, but it doesn't address key management. >> 2) Key management must address loss/destruction of key, detected >> compromise, and undetected compromise. Loss/destruction/detected >> compromise are all handled the same way regardless of cert lifetime: a >> new cert is issued since the old key can't be used to support rekey. >> 3) Undetected compromise allows either the adversary or the subscriber, >> but not both, to rekey, so it provides some compromise detection >> capability when the subscriber is denied a rekey. This detection >> happens more quickly with short-lived certs. >> >> So rekeying at frequent intervals provides a potential advantage over >> infrequent rekeying in the case of undetected exposure of a key that >> remains usable by the subscriber. But that's a pretty small subset of >> key management issues. >> >> Dave >> >> >> -----Original Message----- >> From: Ryan Hurst [mailto:ryan.hurst@globalsign.com] >> Sent: Tuesday, February 21, 2012 5:08 PM >> To: Kemp, David P. >> Cc: >> Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer >> >> Short lived certificates however have the side effect of addressing the >> key management issues that plague operational environments. >> >> Sent from my iPhone >> >> On Feb 21, 2012, at 2:04 PM, "Kemp, David P." >> wrote: >> >>> OCSP requires more bandwidth (at least 4x, usually much more) for any >>> given number of certs. In the limit (infinite number of certs, none >>> revoked), OCSP requires infinite bandwidth while an empty CRL is ~200 >>> octets. CRL stapling is quite practical for CRLs partitioned to cover >>> 100 certs each, and can be regarded as a very efficient replacement >>> for short-lived certs. >>> >>> Dave >>> >>> >>> >>> -----Original Message----- >>> From: Tomas Gustavsson >>> >>> I think a better alternative is to abandon CRLs for these types of CAs >>> and use other mechanisms, like OCSP. If appropriate for the RPs of >>> course... >>> >>> As usual the number of different use cases are not bounded. >>> >>> /Tomas >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > From hotz@jpl.nasa.gov Wed Feb 22 12:12:04 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFE021F8507 for ; Wed, 22 Feb 2012 12:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.278 X-Spam-Level: X-Spam-Status: No, score=-6.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6hgl5pbOM0C for ; Wed, 22 Feb 2012 12:12:03 -0800 (PST) Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id CDA3221F84FD for ; Wed, 22 Feb 2012 12:12:02 -0800 (PST) Received: from dhcp-128-149-190-134.jpl.nasa.gov (dhcp-128-149-190-134.jpl.nasa.gov [128.149.190.134]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1MKBe4G002108 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 22 Feb 2012 12:11:41 -0800 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Wed, 22 Feb 2012 12:11:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: from "Santosh Chokhani" at Feb 20, 12 07:59:56 pm <201202211434.q1LEYm9o026940@fs4113.wdf.sap.corp> To: Santosh Chokhani X-Mailer: Apple Mail (2.1084) X-Source-IP: dhcp-128-149-190-134.jpl.nasa.gov [128.149.190.134] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "pkix@ietf.org" Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 20:12:04 -0000 I think it would be more useful if you explained what you think 5280 is = supposed to be saying. There seem to be a significant number of people who believe that neither = CRLs, nor OCSP provide the revocation functionality which is actually = needed. There also seem to be people (like you?) who believe that, = given some kind of meta-knowledge, the existing capabilities and = specifications are just fine. I can't help wondering if that isn't = behind some of these more localized disagreements. On Feb 22, 2012, at 2:21 AM, Santosh Chokhani wrote: > Your formal logic in this case is in serious need of debugging. >=20 > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com]=20 > Sent: Tuesday, February 21, 2012 9:35 AM > To: Santosh Chokhani > Cc: pkix@ietf.org > Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer >=20 > Santosh Chokhani wrote: >>=20 >> As mentioned before the author of the e-mail reads 5280 incorrectly=20= >> and has exhibited a genuine lack of understanding or refusal to=20 >> understand how IDP, CRL DP and partitioning work. >=20 > I'm only reading the specification the way it is written. > And I'm apply formal logic to determine the "permissible = interpretations" > for those many areas that are unclear and ambiguous. >=20 > Your interpretation of the spec, while not uncommon for people arguing = natural language, is outside of formally valid interpretation, I'm = sorry. >=20 > -Martin >=20 >=20 >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf=20= >> Of Martin Rex >> Sent: Monday, February 20, 2012 10:38 AM >> To: Tomas Gustavsson >> Cc: pkix@ietf.org >> Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer >>=20 >> Tomas Gustavsson wrote: >>>=20 >>> Martin Rex wrote: >>>> Tomas Gustavsson wrote: >>>>>=20 >>>>> Just as a funny of-topic mention. A CRL with 10M revoked entries=20= >>>>> is about 400-500MB large. Very useful :-) >>>>=20 >>>> As I indicated here: >>>>=20 >>>> https://www.ietf.org/mail-archive/web/pkix/current/msg29842.html >>>>=20 >>>> I strongly believe that a CA (i.e. that specific DName) should be=20= >>>> retired when the expected growth of the CRL during the remaining=20 >>>> lifetime of the all certs singed with that exact issuer DName=20 >>>> exceeds a reasonable size. >>>>=20 >>>> The US government is operating several CAs with CRLs carrying>1=20 >>>> million CRLEntries (1080 Millon =3D 22 MBytes), which is IMO far=20 >>>> beyond a resonably sized CRL. >>>>=20 >>>> Instead of partitioning CRLs, the CA should simply get a new CA=20 >>>> cert issued (simply bumping a Serialnumber AVA in the subject=20 >>>> DName of the CAs certificate would be sufficient), at which point=20= >>>> it will automatically start with a fresh, empty CRL, and this will=20= >>>> work nicely with *ALL* RPs. >>>=20 >>> Since CRLs needs to be maintained as long as the end entity=20 >>> certificates are active, all issued end entity certificates of a=20 >>> given CA can potentially become revoked, hence the CRL may contain = all these entries. >>=20 >> I had that case explicitly covered above. Not a problem. Just move = to a different CA cert early enough. This is not about worst case, but = what should be reasonably expected, with some safety margin. >>=20 >>=20 >>>=20 >>> This means that any given CA is only allowed to issue as many=20 >>> certificates as is reasonable to have on a CRL. If you think it is=20= >>> 500.000, any given CA is only allowed to issue 500.000 CRLs, this=20 >>> seems cumbersome way beyond usability. >>=20 >> Just the contrary. Managing risk sensibly means that you want to = limit the value of any single CA keypair, so that if anything very bad = happens, you don't have to nuke the entirey PKI, but only that part of = it that is actually affected. Limiting the number of certs that are = signed with a single CA keypair can significantly help here, and will = work with every conforming RP, while only partitioning CRLs based on = distribution point will not help at all, but may create interop problems = with conforming RPs and makes things actually slower, because the CA = MUST still provide the full CRL in addtion to the zoo of partitioned = CRLs, and it is difficult to see how you can mix them in a fashion that = they not intefere with each other, becaus the CRL distribution point = extension of the certificate (rather than that of the CRL) does not = support paritioning of CRLs based on distribution point names, only on = reason codes. >>=20 >>=20 >>>=20 >>> In reality CAs can issue 10M certificates within days, I surely=20 >>> don't want to renew these CAs as that pace. >>=20 >> That is not necessarily a problem, if you do not expect your CRLs to = grow at the same rate (10M revocations within days). >>=20 >>=20 >> The partitioning of CRLs by distribution point is ill-conceived, no = matter how you look at it. Whether a CA uses partitioning by CRL = distribution point is *NOT* visible in the CRL distribution point = extension of the Certificate at all! >>=20 >> Quoting from rfc5280 Section 6.3: >> http://tools.ietf.org/html/rfc5280#section-6.3 >>=20 >> This algorithm assumes that all of the needed CRLs are available in = a >> local cache. Further, if the next update time of a CRL has passed, >> the algorithm assumes a mechanism to fetch a current CRL and place = it >> in the local CRL cache. >>=20 >> An RP with an efficient implementation of revocation checking will be = using CRLs, cache the CRLs and update the CRL cache strictly = out-of-band, so that a revocation check will incur a single table lookup = keying on issuer&serial, and zero PK-crypto operations and zero third = party network communication in-band while authenticating peers. >>=20 >>=20 >> -Martin >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >>=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From DPKemp@missi.ncsc.mil Wed Feb 22 12:22:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1270C21E8074 for ; Wed, 22 Feb 2012 12:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EHSbuu-nSgW for ; Wed, 22 Feb 2012 12:22:21 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id D912221E804A for ; Wed, 22 Feb 2012 12:22:19 -0800 (PST) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q1MKMF3x091437 for ; Wed, 22 Feb 2012 15:22:15 -0500 (EST) Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 15:23:24 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 22 Feb 2012 15:22:14 -0500 Message-ID: In-Reply-To: <4F4541BB.8020005@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] The case for short-lived vs. long-lived certificates Thread-Index: AczxmCFfTO8QItrdSGSZwdiilMS4gwAAtorA References: <201202171503.q1HF3mvs026601@fs4113.wdf.sap.corp> <4F3FE1F1.4080001@primekey.se> <4F3FE245.4050706@primekey.se> <4F451073.2050404@gmail.com> <4F4541BB.8020005@gmail.com> From: "Kemp, David P." To: X-OriginalArrivalTime: 22 Feb 2012 20:23:24.0359 (UTC) FILETIME=[D3DECD70:01CCF19F] Subject: Re: [pkix] The case for short-lived vs. long-lived certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 20:22:33 -0000 CRLs, OCSP, and/or short- or long- lifetime certs do not "put a heavy just-in-time messaging demand" on the network, currency requirements for authentication and authorization information, in whatever form it is encoded, do that. PKIX has long eschewed the placement of authorization information in PK certificates for exactly the reason Phill cites: authorization changes more rapidly. "Looking beyond" includes looking beyond current counterproductive practices (mixing static and dynamic information in the same data structures) and properly deploying PK certificates, authentication revocation mechanisms, and separate authorization attributes. What is your proposed alternative that achieves appropriate information currency for billions of devices using less network demand? My assertion is that proper application of currently-defined data structures (including full, delta, and partitioned CRLs) for authorization-free PK certs will be strongly competitive with whatever you propose. Dave -----Original Message----- From: Rene Struik [mailto:rstruik.ext@gmail.com]=20 Sent: Wednesday, February 22, 2012 2:28 PM To: Phillip Hallam-Baker Cc: Kemp, David P.; pkix@ietf.org Subject: Re: [pkix] The case for short-lived vs. long-lived certificates Dear Phil: Unfortunately, current deployment in areas that could bear a particular solution direction often spills over in areas that cannot. =20 A vivid example of this is smart grid/cybersecurity, where one has networks with sleepy devices and spotty connectivity at best and where minimizing communication traffic density (esp. the one that needs to be almost on-demand) is highly desirable. Here, emphasis on CRLs and OCSP may kill off the prospect of getting all those 30-50 billions of devices actually deployed or, in an attempt to make this work no matter what, will lead to network designs that at first may not hurt that much (e.g., centralized management approaches), but ultimately do not scale that well (but then it may be "too late", since the "backward compatibility requirement crowd" will make lots of noise on sunk investments and make it very hard to change course - not realizing that this may ultimately also significantly limit the deployment potential. For those networks (where "the other 99%" is not deployed yet), one should try and avoid imposing CRLs and other constructs that put a heavy just-in-time messaging demand on the network. In that respect, e.g., NIST IR 7628's Smart Grid Cybersecurity Framework may need some rethink and erasing of CRL/OCSP terms that may work or have worked reasonably well elsewhere, but transplanting this to a domain with entirely different characteristics may not. So, agreed with your question split, with the caveat that we should look beyond areas we are currently confortable with and know the characteristics of. Rene On 22/02/2012 2:07 PM, Phillip Hallam-Baker wrote: > There are two separate questions: > > 1) Where should we go > 2) How do we get there > > I think Rivest's argument is essentially sound on CRLs with respect to > the first question. The original paper was written round about the=20 > time that we were developing OCSP and even then it was apparent that=20 > the OCSP model is very close to being a certificate model. > > The second part is rather more difficult. Short lived certs and=20 > stapled OCSP responses have almost identical properties. But that does > not mean that they are interchangeable. There is a deployed=20 > infrastructure that expects to make use of OCSP and CRLs. > > > On Wed, Feb 22, 2012 at 10:57 AM, Rene Struik wrote: >> Dear collagues: >> >> Some papers of interest here include Ron Rivest's [1] advocacy for short-lived certs (1998) and Rubin et al's [2] response (2001). >> >> In those papers, arguments underlying picks for short-lived certs vs. >> certificate checks during stated lifetime center around >> a) computational overhead. >> Cost of generating a certificate (or, more precisely, cost of certificate [renewal] request, response sequence). >> b) communication overhead. >> Cost of the protocol messaging to and from the CA for issuing a new=20 >> cert, resp. cost for messaging to and from server who arbitrages into okaying a current certificate on the spot. >> >> My own perspective is as follows: >> >> For networks with lack of "online" connectivity, availability of an=20 >> arbitraging server on the spot cannot be assumed *and* could impose a >> huge communication bandwidth burden (case in point: sensors). For=20 >> those networks, short-lived certs (that provide positive evidence of authentic binding, without "only maybe valid, but please check" semantics), seem to be more suitable. Here, a device can try and obtain a new credential (with associated "new lease of life") from the CA, when it is available to do so (and a moment of its choosing). >> Contrast this with longer-lived certs (with "only maybe valid, but=20 >> please check" semantics), where the ambiguous assertion on validity forces an almost immediate connection with an arbitraging agent somewhere in the network (be it using OCSP or for CRL checking). >> >> The traditional argument that computational cost of generating=20 >> certificates is too expensive seems to be less valid now, witness the >> progress in efficient implementations of cryptographic algorithms=20 >> over the last decade. Moreover, some of the cost can be amortized via >> hybrid schemes, such as Micali's [3], that essentially trade the cost of generating n certificates, each valid for 1 time unit, for the cost of generating 1 certificate conditionally valid for n time units and the cost of computing a Lamport-style hash chain of length n, each representing validity for another time unit. >> >> The main reason for certificate revocation right now seems to be=20 >> "change of authorization" (organizational change, change of=20 >> policies), rather than "change of authentication" (compromised device >> or key). For authorization triggers, providing a "positively valid"=20 >> credential seems far more effective than providing a "maybe valid,=20 >> but please check" credential. For authentication changes, indeed, all >> bets are off until detection, irrespective of the scheme, but once compromise has been detected, long-lived credentials keep polluting the network and requiring checks with an arbitraging agent, while short-lived certs just cease to exist after their short moment under the sun. Here, one should bear in mind that detection time windows are often of human time-scale, so trying and making certs extremely short-lived (i.e., well below practical loss/compromise reporting and processing time window) may not add too much value here. >> >> In summary, the case for short-lived certs seems to be quite=20 >> compelling (presuming devices have a reliable notion of time). This being said, I would suggest revisiting the papers below, re-weighing the arguments and metrics used over a decade ago, and seeing for yourself. >> >> >> [1] R.L. Rivest, >> "Can We Eliminate Certificate Revocation Lists?," >> in Financial Cryptography - FC'98, R. Hirschfeld, Ed., Lecture Notes=20 >> in Computer Science, Vol. 1465, pp. 178-183, Springer, 1998. >> >> [2] P. McDaniel, A. Rubin, >> "A Response to "Can We Eliminate Certificate Revocation Lists?"," >> in Financial Cryptography - FC 2000, Y. Frankel, Ed., Lecture Notes=20 >> in Computer Science, Vol. 1962, pp. 245-258, Springer, 2001. >> >> [3] S. Micali, >> "Efficient Certificate Revocation," Technical Report TM-542b, MIT=20 >> Laboratory for Computer Science, March 22, 1996 >> >> >> On 22/02/2012 9:53 AM, Kemp, David P. wrote: >>> Only in very limited circumstances. >>> >>> 1) Short-lived certificates can renew (extend validity only) or rekey. >>> Renew is trivially easy and is the normal use case for short-lived=20 >>> certs, but it doesn't address key management. >>> 2) Key management must address loss/destruction of key, detected=20 >>> compromise, and undetected compromise. Loss/destruction/detected=20 >>> compromise are all handled the same way regardless of cert lifetime: >>> a new cert is issued since the old key can't be used to support rekey. >>> 3) Undetected compromise allows either the adversary or the=20 >>> subscriber, but not both, to rekey, so it provides some compromise=20 >>> detection capability when the subscriber is denied a rekey. This=20 >>> detection happens more quickly with short-lived certs. >>> >>> So rekeying at frequent intervals provides a potential advantage=20 >>> over infrequent rekeying in the case of undetected exposure of a key >>> that remains usable by the subscriber. But that's a pretty small=20 >>> subset of key management issues. >>> >>> Dave >>> >>> >>> -----Original Message----- >>> From: Ryan Hurst [mailto:ryan.hurst@globalsign.com] >>> Sent: Tuesday, February 21, 2012 5:08 PM >>> To: Kemp, David P. >>> Cc: >>> Subject: Re: [pkix] AuthKeyId and=20 >>> CrlEntryExtension.CertificateIssuer >>> >>> Short lived certificates however have the side effect of addressing=20 >>> the key management issues that plague operational environments. >>> >>> Sent from my iPhone >>> >>> On Feb 21, 2012, at 2:04 PM, "Kemp, David P."=20 >>> >>> wrote: >>> >>>> OCSP requires more bandwidth (at least 4x, usually much more) for=20 >>>> any given number of certs. In the limit (infinite number of certs, >>>> none revoked), OCSP requires infinite bandwidth while an empty CRL=20 >>>> is ~200 octets. CRL stapling is quite practical for CRLs=20 >>>> partitioned to cover >>>> 100 certs each, and can be regarded as a very efficient replacement >>>> for short-lived certs. >>>> >>>> Dave >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Tomas Gustavsson >>>> >>>> I think a better alternative is to abandon CRLs for these types of=20 >>>> CAs and use other mechanisms, like OCSP. If appropriate for the RPs >>>> of course... >>>> >>>> As usual the number of different use cases are not bounded. >>>> >>>> /Tomas >>>> >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >> -- >> email: rstruik.ext@gmail.com >> Skype: rstruik >> cell: +1 (647) 867-5658 >> USA Google voice: +1 (415) 690-7363 >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From mrex@sap.com Wed Feb 22 14:08:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E868121F856A for ; Wed, 22 Feb 2012 14:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.056 X-Spam-Level: X-Spam-Status: No, score=-10.056 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNwgfv2wKZ6s for ; Wed, 22 Feb 2012 14:08:30 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0F721E803C for ; Wed, 22 Feb 2012 14:08:29 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q1MM8FGq022439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Feb 2012 23:08:20 +0100 (MET) From: Martin Rex Message-Id: <201202222208.q1MM8FUG014456@fs4113.wdf.sap.corp> To: SChokhani@cygnacom.com (Santosh Chokhani) Date: Wed, 22 Feb 2012 23:08:15 +0100 (MET) In-Reply-To: from "Santosh Chokhani" at Feb 22, 12 05:21:13 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 22:08:31 -0000 Santosh Chokhani wrote: > > Your formal logic in this case is in serious need of debugging. Debugging is a method to search for defects in trial-and-error approaches to design and implementation. If you apply formal correctness proofing to specifications, the result is provable ambiguities and contradictions. Maybe you're just not familiar with reviewing specification under the aspect of formal correctness proofing in order to find out whether some existing wording is a defect of the spec or some interpretation that seems conceivable at the natural language level is actually inconsistent with the specification. -Martin From SChokhani@cygnacom.com Wed Feb 22 14:28:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5596821E804B for ; Wed, 22 Feb 2012 14:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntpJ1pgvih2m for ; Wed, 22 Feb 2012 14:28:20 -0800 (PST) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6A121E8015 for ; Wed, 22 Feb 2012 14:28:20 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,466,1325480400"; d="scan'208";a="4188348" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 22 Feb 2012 17:28:15 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Wed, 22 Feb 2012 17:28:15 -0500 From: Santosh Chokhani To: "Henry B. Hotz" Date: Wed, 22 Feb 2012 17:28:14 -0500 Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Thread-Index: AczxnjO8rREBIT1/TUOgupXoHMTxVAAEYJ1Q Message-ID: References: from "Santosh Chokhani" at Feb 20, 12 07:59:56 pm <201202211434.q1LEYm9o026940@fs4113.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 22:28:21 -0000 5280 is saying that IDP must be critical, Hence relying party must process the IDP in order to use the CRL. 5280 us saying that if IDP has DP in it, that DP must match one of the DPs = in the CRL DP of the certificate of interest in order to ensure that the ce= rtificate is covered. -----Original Message----- From: Henry B. Hotz [mailto:hotz@jpl.nasa.gov]=20 Sent: Wednesday, February 22, 2012 3:12 PM To: Santosh Chokhani Cc: mrex@sap.com; pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer I think it would be more useful if you explained what you think 5280 is sup= posed to be saying. There seem to be a significant number of people who believe that neither CR= Ls, nor OCSP provide the revocation functionality which is actually needed.= There also seem to be people (like you?) who believe that, given some kin= d of meta-knowledge, the existing capabilities and specifications are just = fine. I can't help wondering if that isn't behind some of these more local= ized disagreements. On Feb 22, 2012, at 2:21 AM, Santosh Chokhani wrote: > Your formal logic in this case is in serious need of debugging. >=20 > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Tuesday, February 21, 2012 9:35 AM > To: Santosh Chokhani > Cc: pkix@ietf.org > Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer >=20 > Santosh Chokhani wrote: >>=20 >> As mentioned before the author of the e-mail reads 5280 incorrectly=20 >> and has exhibited a genuine lack of understanding or refusal to=20 >> understand how IDP, CRL DP and partitioning work. >=20 > I'm only reading the specification the way it is written. > And I'm apply formal logic to determine the "permissible interpretations" > for those many areas that are unclear and ambiguous. >=20 > Your interpretation of the spec, while not uncommon for people arguing na= tural language, is outside of formally valid interpretation, I'm sorry. >=20 > -Martin >=20 >=20 >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf=20 >> Of Martin Rex >> Sent: Monday, February 20, 2012 10:38 AM >> To: Tomas Gustavsson >> Cc: pkix@ietf.org >> Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer >>=20 >> Tomas Gustavsson wrote: >>>=20 >>> Martin Rex wrote: >>>> Tomas Gustavsson wrote: >>>>>=20 >>>>> Just as a funny of-topic mention. A CRL with 10M revoked entries=20 >>>>> is about 400-500MB large. Very useful :-) >>>>=20 >>>> As I indicated here: >>>>=20 >>>> https://www.ietf.org/mail-archive/web/pkix/current/msg29842.html >>>>=20 >>>> I strongly believe that a CA (i.e. that specific DName) should be=20 >>>> retired when the expected growth of the CRL during the remaining=20 >>>> lifetime of the all certs singed with that exact issuer DName=20 >>>> exceeds a reasonable size. >>>>=20 >>>> The US government is operating several CAs with CRLs carrying>1=20 >>>> million CRLEntries (1080 Millon =3D 22 MBytes), which is IMO far=20 >>>> beyond a resonably sized CRL. >>>>=20 >>>> Instead of partitioning CRLs, the CA should simply get a new CA=20 >>>> cert issued (simply bumping a Serialnumber AVA in the subject DName=20 >>>> of the CAs certificate would be sufficient), at which point it will=20 >>>> automatically start with a fresh, empty CRL, and this will work=20 >>>> nicely with *ALL* RPs. >>>=20 >>> Since CRLs needs to be maintained as long as the end entity=20 >>> certificates are active, all issued end entity certificates of a=20 >>> given CA can potentially become revoked, hence the CRL may contain all = these entries. >>=20 >> I had that case explicitly covered above. Not a problem. Just move to = a different CA cert early enough. This is not about worst case, but what s= hould be reasonably expected, with some safety margin. >>=20 >>=20 >>>=20 >>> This means that any given CA is only allowed to issue as many=20 >>> certificates as is reasonable to have on a CRL. If you think it is=20 >>> 500.000, any given CA is only allowed to issue 500.000 CRLs, this=20 >>> seems cumbersome way beyond usability. >>=20 >> Just the contrary. Managing risk sensibly means that you want to limit = the value of any single CA keypair, so that if anything very bad happens, y= ou don't have to nuke the entirey PKI, but only that part of it that is act= ually affected. Limiting the number of certs that are signed with a single= CA keypair can significantly help here, and will work with every conformin= g RP, while only partitioning CRLs based on distribution point will not hel= p at all, but may create interop problems with conforming RPs and makes thi= ngs actually slower, because the CA MUST still provide the full CRL in addt= ion to the zoo of partitioned CRLs, and it is difficult to see how you can = mix them in a fashion that they not intefere with each other, becaus the CR= L distribution point extension of the certificate (rather than that of the = CRL) does not support paritioning of CRLs based on distribution point names= , only on reason codes. >>=20 >>=20 >>>=20 >>> In reality CAs can issue 10M certificates within days, I surely=20 >>> don't want to renew these CAs as that pace. >>=20 >> That is not necessarily a problem, if you do not expect your CRLs to gro= w at the same rate (10M revocations within days). >>=20 >>=20 >> The partitioning of CRLs by distribution point is ill-conceived, no matt= er how you look at it. Whether a CA uses partitioning by CRL distribution = point is *NOT* visible in the CRL distribution point extension of the Certi= ficate at all! >>=20 >> Quoting from rfc5280 Section 6.3: >> http://tools.ietf.org/html/rfc5280#section-6.3 >>=20 >> This algorithm assumes that all of the needed CRLs are available in a >> local cache. Further, if the next update time of a CRL has passed, >> the algorithm assumes a mechanism to fetch a current CRL and place it >> in the local CRL cache. >>=20 >> An RP with an efficient implementation of revocation checking will be us= ing CRLs, cache the CRLs and update the CRL cache strictly out-of-band, so = that a revocation check will incur a single table lookup keying on issuer&s= erial, and zero PK-crypto operations and zero third party network communica= tion in-band while authenticating peers. >>=20 >>=20 >> -Martin >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >>=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL,= NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From pgut001@login01.cs.auckland.ac.nz Wed Feb 22 17:02:00 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A118F21E8035 for ; Wed, 22 Feb 2012 17:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHj6JQIR6Ojx for ; Wed, 22 Feb 2012 17:01:58 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 50FA321E802A for ; Wed, 22 Feb 2012 17:01:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1329958917; x=1361494917; h=from:to:subject:in-reply-to:message-id:date; bh=hflRQAg3L9Md235dkIwyH11qJH3YKlluDnLznAK8zns=; b=IAqTv/XOw/HiYALSTp9L09zqIocmKJ4RFkOCATW2EPfj4PviNA4s2/ef FI4iAA/uI22urKAiiIBPo6BHK8UwOMR/SWKs1hZIQG8baTM4msuacvVOJ PUOniYwfibodlbFadoZPEJUx+18J4eVxSthVEFS/CtrUsLV5leLDS+G0m 0=; X-IronPort-AV: E=Sophos;i="4.73,467,1325415600"; d="scan'208";a="105009046" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.34.40 - Outgoing - Outgoing Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 23 Feb 2012 14:01:53 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1S0N4E-0002sp-Pd; Thu, 23 Feb 2012 14:01:54 +1300 From: Peter Gutmann To: pkix@ietf.org, tmiller@mitre.org In-Reply-To: Message-Id: Date: Thu, 23 Feb 2012 14:01:54 +1300 Subject: Re: [pkix] Explanation of the OCSP sign request (RFC 2560) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 01:02:00 -0000 "Miller, Timothy J." writes: >Personally I'm not sure why anyone would make sigs mandatory on OCSP requests, >but I'm sure someone can come up with a reason. :) For billing purposes, when the CA charges for revocation checks. (It's actually used for that. Then the clients disable rev.checks in order to save money, which also actually happens). Peter. From mrex@sap.com Wed Feb 22 19:05:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D979C21E8036 for ; Wed, 22 Feb 2012 19:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.058 X-Spam-Level: X-Spam-Status: No, score=-10.058 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWxVWXSG78WQ for ; Wed, 22 Feb 2012 19:05:36 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id F186821E8013 for ; Wed, 22 Feb 2012 19:05:35 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q1N35YOV011579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Feb 2012 04:05:34 +0100 (MET) From: Martin Rex Message-Id: <201202230305.q1N35XW5001399@fs4113.wdf.sap.corp> To: tmiller@mitre.org (Miller Timothy J.) Date: Thu, 23 Feb 2012 04:05:33 +0100 (MET) In-Reply-To: from "Miller, Timothy J." at Feb 20, 12 03:41:30 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tomas@primekey.se, pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 03:05:37 -0000 Miller, Timothy J. wrote: > > "Martin Rex" wrote: > > >I had that case explicitly covered above. Not a problem. Just move > >to a different CA cert early enough. This is not about worst case, > >but what should be reasonably expected, with some safety margin. > > You make it sound so simple. > > CAs don't come cheap at higher assurance levels. They are expensive to > deploy and expensive to maintain. Are you thinking of crypto hardware that is quite limited in the amount of distinct keypairs it can handle? One solution to that might be to re-use the same keypair with different intermediate CA certs, i.e. instead of trying to partition by an optional, overly complex "CRL distribution point name" simply create the same number of intermediate CA certs with distinct subject dnames for the same public key. That should be easy&straightforward, will _not_ interfere with efficient CRL processing and will work with just everything that supports CRLs at all? But you should compute the SPKID of those certs based on a concatenation of the public key and subject name, or some implementations might get fatally confused and break. -Martin From SChokhani@cygnacom.com Thu Feb 23 14:43:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2350F11E8094 for ; Thu, 23 Feb 2012 14:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D68Cc2Zv3voy for ; Thu, 23 Feb 2012 14:43:27 -0800 (PST) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5774711E8074 for ; Thu, 23 Feb 2012 14:43:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,472,1325480400"; d="scan'208";a="443084" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 23 Feb 2012 17:43:26 -0500 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 23 Feb 2012 17:43:26 -0500 From: Santosh Chokhani To: "mrex@sap.com" Date: Thu, 23 Feb 2012 17:43:21 -0500 Thread-Topic: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Thread-Index: AczyfInWGR9FMN4aR/KFX95QU/PhmA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 22:43:28 -0000 Please share your formal specification and proofs for 5280 with us. We would love to see how you are so confident that you have not made errors= in converting 5280 descriptions into a formal specification. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Wednesday, February 22, 2012 5:08 PM To: Santosh Chokhani Cc: mrex@sap.com; pkix@ietf.org Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Santosh Chokhani wrote: >=20 > Your formal logic in this case is in serious need of debugging. Debugging is a method to search for defects in trial-and-error approaches t= o design and implementation. If you apply formal correctness proofing to specifications, the result is p= rovable ambiguities and contradictions. Maybe you're just not familiar with reviewing specification under the aspec= t of formal correctness proofing in order to find out whether some existing= wording is a defect of the spec or some interpretation that seems conceiva= ble at the natural language level is actually inconsistent with the specifi= cation. -Martin From tgindin@us.ibm.com Thu Feb 23 17:55:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A605021F886B for ; Thu, 23 Feb 2012 17:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.644 X-Spam-Level: X-Spam-Status: No, score=-8.644 tagged_above=-999 required=5 tests=[AWL=1.355, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNtjLTps-2fs for ; Thu, 23 Feb 2012 17:55:52 -0800 (PST) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by ietfa.amsl.com (Postfix) with ESMTP id 57F6A21F8864 for ; Thu, 23 Feb 2012 17:55:52 -0800 (PST) Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 23 Feb 2012 20:55:50 -0500 Received: from d01dlp02.pok.ibm.com (9.56.224.85) by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 23 Feb 2012 20:55:46 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 663BE6E8049 for ; Thu, 23 Feb 2012 20:55:45 -0500 (EST) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1O1tGMI213234 for ; Thu, 23 Feb 2012 20:55:17 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1O1tEZP023421 for ; Thu, 23 Feb 2012 23:55:15 -0200 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q1O1tDXt023391; Thu, 23 Feb 2012 23:55:13 -0200 In-Reply-To: References: from "Santosh Chokhani" at Feb 20, 12 07:59:56 pm <201202211434.q1LEYm9o026940@fs4113.wdf.sap.corp> To: "Henry B. Hotz" MIME-Version: 1.0 X-KeepSent: 0BAD5B5A:5380C782-852579AD:005A3AD3; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Thu, 23 Feb 2012 20:55:11 -0500 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 02/23/2012 20:55:13, Serialize complete at 02/23/2012 20:55:13 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12022401-5806-0000-0000-000012D778BC Cc: "pkix@ietf.org" Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 01:55:53 -0000 Henry: I can't speak for Santosh, but only for myself. However, I can reiterate my position on these things. First, I don't believe that it's feasible to implement the use of more than a few issuers with revocation checking unless each certificate includes a transport address for revocation information. The major ways of doing this are OCSP and CRL Distribution Points, and CRL Distribution Points work in this way only when they include a URL. It is true that if relying parties need to individually configure each of those intermediate certificates which they accept, they can configure the corresponding CRL locations for each intermediate as well for a few times the effort. Second, the use of CRL Distribution Points to assign certificates to partitioned CRL's at the time of issuance is a legitimate design choice and has been used by major CA's in the past. For very large scale PKI's, it seems IMHO to be more feasible than any other choice. My experience with RP deployments leads me to believe that CRL's can be used with Distribution Points containing URL's, or with the configuration technique I mentioned, but are not very workable in non-internal PKI's otherwise. It is also crucial NOT to regard nextUpdate as a precise expiration time for the CRL. I don't want to overrate the quality of the CRL mechanism, but if you set those criteria and avoid that mistake it's at least good for something. My experience does NOT cover browsers or other SSL clients which use more than a few trust anchors, and should not be taken to imply that I am sure that CRL's with distribution points are good enough for them. Tom Gindin P.S. - The opinions above are mine, and not necessarily those of my employer From: "Henry B. Hotz" To: Santosh Chokhani , Cc: "pkix@ietf.org" Date: 02/22/2012 03:13 PM Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer Sent by: pkix-bounces@ietf.org I think it would be more useful if you explained what you think 5280 is supposed to be saying. There seem to be a significant number of people who believe that neither CRLs, nor OCSP provide the revocation functionality which is actually needed. There also seem to be people (like you?) who believe that, given some kind of meta-knowledge, the existing capabilities and specifications are just fine. I can't help wondering if that isn't behind some of these more localized disagreements. On Feb 22, 2012, at 2:21 AM, Santosh Chokhani wrote: > Your formal logic in this case is in serious need of debugging. > > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Tuesday, February 21, 2012 9:35 AM > To: Santosh Chokhani > Cc: pkix@ietf.org > Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer > > Santosh Chokhani wrote: >> >> As mentioned before the author of the e-mail reads 5280 incorrectly >> and has exhibited a genuine lack of understanding or refusal to >> understand how IDP, CRL DP and partitioning work. > > I'm only reading the specification the way it is written. > And I'm apply formal logic to determine the "permissible interpretations" > for those many areas that are unclear and ambiguous. > > Your interpretation of the spec, while not uncommon for people arguing natural language, is outside of formally valid interpretation, I'm sorry. > > -Martin > > >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf >> Of Martin Rex >> Sent: Monday, February 20, 2012 10:38 AM >> To: Tomas Gustavsson >> Cc: pkix@ietf.org >> Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer >> >> Tomas Gustavsson wrote: >>> >>> Martin Rex wrote: >>>> Tomas Gustavsson wrote: >>>>> >>>>> Just as a funny of-topic mention. A CRL with 10M revoked entries >>>>> is about 400-500MB large. Very useful :-) >>>> >>>> As I indicated here: >>>> >>>> https://www.ietf.org/mail-archive/web/pkix/current/msg29842.html >>>> >>>> I strongly believe that a CA (i.e. that specific DName) should be >>>> retired when the expected growth of the CRL during the remaining >>>> lifetime of the all certs singed with that exact issuer DName >>>> exceeds a reasonable size. >>>> >>>> The US government is operating several CAs with CRLs carrying>1 >>>> million CRLEntries (1080 Millon = 22 MBytes), which is IMO far >>>> beyond a resonably sized CRL. >>>> >>>> Instead of partitioning CRLs, the CA should simply get a new CA >>>> cert issued (simply bumping a Serialnumber AVA in the subject >>>> DName of the CAs certificate would be sufficient), at which point >>>> it will automatically start with a fresh, empty CRL, and this will >>>> work nicely with *ALL* RPs. >>> >>> Since CRLs needs to be maintained as long as the end entity >>> certificates are active, all issued end entity certificates of a >>> given CA can potentially become revoked, hence the CRL may contain all these entries. >> >> I had that case explicitly covered above. Not a problem. Just move to a different CA cert early enough. This is not about worst case, but what should be reasonably expected, with some safety margin. >> >> >>> >>> This means that any given CA is only allowed to issue as many >>> certificates as is reasonable to have on a CRL. If you think it is >>> 500.000, any given CA is only allowed to issue 500.000 CRLs, this >>> seems cumbersome way beyond usability. >> >> Just the contrary. Managing risk sensibly means that you want to limit the value of any single CA keypair, so that if anything very bad happens, you don't have to nuke the entirey PKI, but only that part of it that is actually affected. Limiting the number of certs that are signed with a single CA keypair can significantly help here, and will work with every conforming RP, while only partitioning CRLs based on distribution point will not help at all, but may create interop problems with conforming RPs and makes things actually slower, because the CA MUST still provide the full CRL in addtion to the zoo of partitioned CRLs, and it is difficult to see how you can mix them in a fashion that they not intefere with each other, becaus the CRL distribution point extension of the certificate (rather than that of the CRL) does not support paritioning of CRLs based on distribution point names, only on reason codes. >> >> >>> >>> In reality CAs can issue 10M certificates within days, I surely >>> don't want to renew these CAs as that pace. >> >> That is not necessarily a problem, if you do not expect your CRLs to grow at the same rate (10M revocations within days). >> >> >> The partitioning of CRLs by distribution point is ill-conceived, no matter how you look at it. Whether a CA uses partitioning by CRL distribution point is *NOT* visible in the CRL distribution point extension of the Certificate at all! >> >> Quoting from rfc5280 Section 6.3: >> http://tools.ietf.org/html/rfc5280#section-6.3 >> >> This algorithm assumes that all of the needed CRLs are available in a >> local cache. Further, if the next update time of a CRL has passed, >> the algorithm assumes a mechanism to fetch a current CRL and place it >> in the local CRL cache. >> >> An RP with an efficient implementation of revocation checking will be using CRLs, cache the CRLs and update the CRL cache strictly out-of-band, so that a revocation check will incur a single table lookup keying on issuer&serial, and zero PK-crypto operations and zero third party network communication in-band while authenticating peers. >> >> >> -Martin >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From anders.rundgren@telia.com Sat Feb 25 00:13:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4768E21E801E for ; Sat, 25 Feb 2012 00:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWfUkqrB-J1J for ; Sat, 25 Feb 2012 00:13:49 -0800 (PST) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id BB3E021E801D for ; Sat, 25 Feb 2012 00:13:48 -0800 (PST) Received: from [192.168.0.200] (213.66.133.125) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4EFC380E00F59C74 for pkix@ietf.org; Sat, 25 Feb 2012 09:13:47 +0100 Message-ID: <4F489823.5050207@telia.com> Date: Sat, 25 Feb 2012 09:13:23 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "pkix@ietf.org" References: <4F21439C.2050308@primekey.se> <28AE71BA-F40E-4834-A4EA-5D086B548B26@cisco.com> In-Reply-To: <28AE71BA-F40E-4834-A4EA-5D086B548B26@cisco.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] Invention Disclosure: Efficient End-2-End Secured Provisioning X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 08:13:51 -0000 With the advent of Google's Wallet E2ES-based provisioning of keys will go from being an esoteric activity performed by a handful of card vendors to be used by essentially everybody. The following defensive publication [1] shows how you by using a virtual namespace can combine E2ES with protocol efficiency while still keeping complexity in cryptographic modules at a reasonable level. http://openkeystore.googlecode.com/svn/trunk/resources/docs/Efficient-Provisioning-of-Complex-Structures-Over-Unsecured-Channels.pdf Regards, Anders 1] Filed at http://defensivepublications.org From tomas@primekey.se Sat Feb 25 07:29:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2438421F8585 for ; Sat, 25 Feb 2012 07:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bxPuAxXZgUS for ; Sat, 25 Feb 2012 07:29:14 -0800 (PST) Received: from mail.primekey.se (mail.primekey.se [213.179.18.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE3A21F8584 for ; Sat, 25 Feb 2012 07:29:14 -0800 (PST) Received: from mail.primekey.se (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id 338FDE2A58 for ; Sat, 25 Feb 2012 16:29:16 +0100 (CET) Received: from [10.0.0.70] (DSL212-235-40-239.bb.netvision.net.il [212.235.40.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.se (Postfix) with ESMTPSA id CA5DDE21A6 for ; Sat, 25 Feb 2012 16:29:15 +0100 (CET) Message-ID: <4F48FE46.6050408@primekey.se> Date: Sat, 25 Feb 2012 17:29:10 +0200 From: Tomas Gustavsson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120224 Thunderbird/11.0 MIME-Version: 1.0 To: pkix@ietf.org References: <4F21439C.2050308@primekey.se> <28AE71BA-F40E-4834-A4EA-5D086B548B26@cisco.com> <4F489823.5050207@telia.com> In-Reply-To: <4F489823.5050207@telia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [pkix] Invention Disclosure: Efficient End-2-End Secured Provisioning X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 15:29:15 -0000 On 02/25/2012 10:13 AM, Anders Rundgren wrote: > With the advent of Google's Wallet E2ES-based provisioning of > keys will go from being an esoteric activity performed by a > handful of card vendors to be used by essentially everybody. > > The following defensive publication [1] shows how you by using a > virtual namespace can combine E2ES with protocol efficiency while > still keeping complexity in cryptographic modules at a reasonable level. > > http://openkeystore.googlecode.com/svn/trunk/resources/docs/Efficient-Provisioning-of-Complex-Structures-Over-Unsecured-Channels.pdf > > Regards, > Anders > > 1] Filed at http://defensivepublications.org Without going into the spec I think it's really great that you submit this as defensive publication. Cheers, Tomas From kent@bbn.com Mon Feb 27 08:30:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1822421F8736 for ; Mon, 27 Feb 2012 08:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.471 X-Spam-Level: X-Spam-Status: No, score=-106.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7rzvzebsitj for ; Mon, 27 Feb 2012 08:30:32 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id AA36C21F870F for ; Mon, 27 Feb 2012 08:30:32 -0800 (PST) Received: from dhcp89-089-054.bbn.com ([128.89.89.54]:49183) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S23T5-000Hja-JW for pkix@ietf.org; Mon, 27 Feb 2012 11:30:31 -0500 Mime-Version: 1.0 Message-Id: Date: Mon, 27 Feb 2012 11:30:29 -0500 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] FYI our scheduled time in Paris X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 16:30:33 -0000 pkix Session 1 (2 hours) Tuesday, Morning Session I 0930-1130 Room Name: 212/213 From kent@bbn.com Tue Feb 28 14:49:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80EBF21E8028 for ; Tue, 28 Feb 2012 14:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.178 X-Spam-Level: X-Spam-Status: No, score=-105.178 tagged_above=-999 required=5 tests=[AWL=-1.179, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vt-XY-mkBGii for ; Tue, 28 Feb 2012 14:49:25 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B14CE21E8018 for ; Tue, 28 Feb 2012 14:49:25 -0800 (PST) Received: from dhcp89-089-054.bbn.com ([128.89.89.54]:49172) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S2VrD-000Fr0-NY for pkix@ietf.org; Tue, 28 Feb 2012 17:49:20 -0500 Mime-Version: 1.0 Message-Id: Date: Tue, 28 Feb 2012 17:49:21 -0500 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] Agenda requests for Paris X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 22:49:31 -0000 Folks, I have already sent a message noting our meeting day/time/room. Please let Stefan and me know if you want a slot on the agenda. Thanks, Steve