From SChokhani@cygnacom.com Tue Sep 4 06:43:24 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464E521F851E for ; Tue, 4 Sep 2012 06:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bb9JV8kHBD4W for ; Tue, 4 Sep 2012 06:43:23 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE9421F854F for ; Tue, 4 Sep 2012 06:43:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,367,1344225600"; d="scan'208";a="6103492" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 04 Sep 2012 09:43:19 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 4 Sep 2012 09:43:19 -0400 From: Santosh Chokhani To: Tim Moses , "wpkops@ietf.org" Date: Tue, 4 Sep 2012 09:43:18 -0400 Thread-Topic: [wpkops] Second draft charter proposal Thread-Index: Ac2Gxfw8PmJfmJJLTxGAagHtE7TNSwAJpfwAAABc+wAAABaBgAAoCViwAMUalSA= Message-ID: References: <37FAC45A-304E-48A8-B294-A0C3F465FDAA@me.com> <5B68A271B9C97046963CB6A5B8D6F62C3A57B344@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A57B344@SOTTEXCH10.corp.ad.entrust.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 04 Sep 2012 06:45:17 -0700 Subject: Re: [wpkops] Second draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 13:43:24 -0000 Hi Tim, Based on my experience client authentication should be largely out of scope= except for the issues such as hints list and how client selects the certif= icate to be presented. Most of the other issues I see on the Server side when authenticating the c= lient certificate are generic PK enablement issues and not specific to Web. -----Original Message----- From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of= Tim Moses Sent: Friday, August 31, 2012 11:52 AM To: wpkops@ietf.org Subject: Re: [wpkops] Second draft charter proposal All - I have no fundamental objection to expanding the scope in the ways su= ggested. It's true that the original idea was to limit the scope to server-auth to W= eb browsers. That's because vulnerabilities have been demonstrated and the= impact can clearly be severe. Do those conditions exist for client-auth a= nd CalDAV? If not, I might assign them lower priority. On the other hand, if they impact the workload by no more than (say) 10%, w= hy wouldn't we include them? I think it's important to remember that increased workload must be borne no= t just by the editors but also by the reviewers (every subscriber to the ma= il-list). All the best. Tim. -----Original Message----- From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of= Carl Wallace Sent: Thursday, August 30, 2012 12:31 PM To: Jon Callas; wpkops@ietf.org Subject: Re: [wpkops] Second draft charter proposal On 8/30/12 12:28 PM, "Jon Callas" wrote: >On Aug 30, 2012, at 9:18 AM, Carl Wallace wrote: > >>> And for issuers, it can be difficult to predict what proportion of=20 >>> the user population will accept a certificate chain with certain=20 >>> characteristics. For instance, when a browser includes a nonce in=20 >>> an OCSP request but the server supplies a response that does not=20 >>> include the nonce, it is hard to know which browsers will accept and=20 >>> which will reject the response. >>>=20 >>>=20 >>>=20 >>=20 >> Is client authentication processing performed by web servers in scope? >>If >> not, explicitly push that out of scope. > >It would be nice if it were in scope. Client authorization is a vastly=20 >under-used feature. > >I wouldn't want to endanger everything else over it, but if we keep=20 >sweeping it under the rug, it will continue to languish. I agree and would like to see it stay in scope as well. =20 _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops From hallam@gmail.com Tue Sep 4 09:28:43 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D8621F84E6 for ; Tue, 4 Sep 2012 09:28:43 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11NbaoWXMa8j for ; Tue, 4 Sep 2012 09:28:42 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4504521F849D for ; Tue, 4 Sep 2012 09:28:42 -0700 (PDT) Received: by iabz21 with SMTP id z21so10482134iab.31 for ; Tue, 04 Sep 2012 09:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OrlLkTSlDtaAn76c4SKESQqey5tAGsTUhVdqkGS8XZQ=; b=Iyu8HYH/5bE2/cttN50n4elXl7pAfvMs0Rd3yauN0IUzKZccEN+GXFyWH0jILk9HYG 8SQYLBOkqOc88IlNlPgYDOQza31ZoGprl7/iOw6INlpOE7IN1J4sMu88NlSWY6tn7qsL haVnjACPmQwhQlTKc5uPJHG4cubxDaH9K3OjPc0NYtodrzTicU9gg5OszGvidwV9RWfK jH72t5svm6aKCRPpatiwswjfMYtKLfT8xukIh87HE7HvGYxH3cVmjKnZakZHKUoRJY04 8tb8ny2sxKMcbL58xuADFJRMt4GhqB4mmB8WQU2F2kU1FFf+l1MlZs17xvNxPn5F1BAT kGOQ== MIME-Version: 1.0 Received: by 10.60.28.202 with SMTP id d10mr15908096oeh.36.1346776121697; Tue, 04 Sep 2012 09:28:41 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Tue, 4 Sep 2012 09:28:41 -0700 (PDT) In-Reply-To: References: <37FAC45A-304E-48A8-B294-A0C3F465FDAA@me.com> Date: Tue, 4 Sep 2012 12:28:41 -0400 Message-ID: From: Phillip Hallam-Baker To: Carl Wallace Content-Type: text/plain; charset=ISO-8859-1 Cc: wpkops@ietf.org, Jon Callas Subject: Re: [wpkops] Second draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 16:28:43 -0000 I would like to see us 'do' something 'about' client authentication. But I don't see much of a client PKI out there to be operated, I think we are going to have to 'build stuff' to fix it. So I don't think its a PKI operations issue. I would prefer to see a separate, security area WG to look into the client ops side. In particular I don't want to spend time trying to work out how to automate the 'certificate lifecycle' premised on the idea that client certs expire on an annual basis in a group where we can't ask why the cert has to expire. On Thu, Aug 30, 2012 at 12:31 PM, Carl Wallace wrote: > On 8/30/12 12:28 PM, "Jon Callas" wrote: > >>On Aug 30, 2012, at 9:18 AM, Carl Wallace wrote: >> >>>> And for issuers, it can be difficult to predict what proportion of the >>>> user population will accept a certificate chain with certain >>>> characteristics. For instance, when a browser includes a nonce in an >>>> OCSP request but the server supplies a >>>> response that does not include the nonce, it is hard to know which >>>> browsers will accept and which will reject the response. >>>> >>>> >>>> >>> >>> Is client authentication processing performed by web servers in scope? >>>If >>> not, explicitly push that out of scope. >> >>It would be nice if it were in scope. Client authorization is a vastly >>under-used feature. >> >>I wouldn't want to endanger everything else over it, but if we keep >>sweeping it under the rug, it will continue to languish. > > I agree and would like to see it stay in scope as well. > > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops -- Website: http://hallambaker.com/ From ben@digicert.com Tue Sep 4 09:50:31 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858ED11E80A3 for ; Tue, 4 Sep 2012 09:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2mQrpFIbyYN for ; Tue, 4 Sep 2012 09:50:28 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id AE97711E809A for ; Tue, 4 Sep 2012 09:50:28 -0700 (PDT) Received: from BWILSONL1 (unknown [64.78.193.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 3DA791AE051; Tue, 4 Sep 2012 10:50:28 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1346777428; bh=JqCbfsD8B9HX0snoO1Ztu/GoHtCQ8WUvp3Vvcof2POo=; h=Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date: Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bwye0J6nkxy6J5rvyh4tAOUrzmPbha3JFUSrHYwDafIv95JTQIMcYscmABzNa1f44 uYQMcD6Z9u2uCHEbQ4+M4L9tEZsSMZ14jN0nf6iE3wc29gLc04KMG1C6T/SsaoBi/z LX100r4AnZmxS95rG8WtAMuQ/nfLxupVVPIaksPg= From: "Ben Wilson" To: "'Phillip Hallam-Baker'" , "'Carl Wallace'" References: <37FAC45A-304E-48A8-B294-A0C3F465FDAA@me.com> In-Reply-To: Date: Tue, 4 Sep 2012 10:50:26 -0600 Organization: DigiCert Message-ID: <007701cd8abd$6283a8a0$278af9e0$@digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHahyLv7Zxir7m6bG8quokZXEzxZgLIi+coAmCHzZeXNyJKAA== Content-Language: en-us Cc: wpkops@ietf.org, 'Jon Callas' Subject: Re: [wpkops] Second draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ben@digicert.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 16:50:31 -0000 While I agree that it needs to be addressed, I'm not sure I want to enlarge the scope when our success will depend on our ability to handle the workload and address and resolve the issues presented. -----Original Message----- From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker Sent: Tuesday, September 04, 2012 10:29 AM To: Carl Wallace Cc: wpkops@ietf.org; Jon Callas Subject: Re: [wpkops] Second draft charter proposal I would like to see us 'do' something 'about' client authentication. But I don't see much of a client PKI out there to be operated, I think we are going to have to 'build stuff' to fix it. So I don't think its a PKI operations issue. I would prefer to see a separate, security area WG to look into the client ops side. In particular I don't want to spend time trying to work out how to automate the 'certificate lifecycle' premised on the idea that client certs expire on an annual basis in a group where we can't ask why the cert has to expire. On Thu, Aug 30, 2012 at 12:31 PM, Carl Wallace wrote: > On 8/30/12 12:28 PM, "Jon Callas" wrote: > >>On Aug 30, 2012, at 9:18 AM, Carl Wallace wrote: >> >>>> And for issuers, it can be difficult to predict what proportion of >>>> the user population will accept a certificate chain with certain >>>> characteristics. For instance, when a browser includes a nonce in >>>> an OCSP request but the server supplies a response that does not >>>> include the nonce, it is hard to know which browsers will accept >>>> and which will reject the response. >>>> >>>> >>>> >>> >>> Is client authentication processing performed by web servers in scope? >>>If >>> not, explicitly push that out of scope. >> >>It would be nice if it were in scope. Client authorization is a vastly >>under-used feature. >> >>I wouldn't want to endanger everything else over it, but if we keep >>sweeping it under the rug, it will continue to languish. > > I agree and would like to see it stay in scope as well. > > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops -- Website: http://hallambaker.com/ _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops From anders.rundgren@telia.com Tue Sep 4 09:57:39 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5312721F8459 for ; Tue, 4 Sep 2012 09:57:39 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-xBxYH-qy1y for ; Tue, 4 Sep 2012 09:57:38 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 4E90521F8458 for ; Tue, 4 Sep 2012 09:57:38 -0700 (PDT) Received: from [95.209.48.182] (95.209.48.182) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 503A68CC003781BF; Tue, 4 Sep 2012 18:57:36 +0200 Message-ID: <504632FC.9050706@telia.com> Date: Tue, 04 Sep 2012 18:57:32 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <37FAC45A-304E-48A8-B294-A0C3F465FDAA@me.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jon Callas , wpkops@ietf.org, Carl Wallace Subject: Re: [wpkops] Second draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 16:57:39 -0000 On 2012-09-04 18:28, Phillip Hallam-Baker wrote: > I would like to see us 'do' something 'about' client authentication. > > But I don't see much of a client PKI out there to be operated, I think > we are going to have to 'build stuff' to fix it. So I don't think its > a PKI operations issue. http://www.w3.org/2012/webcrypto > > I would prefer to see a separate, security area WG to look into the > client ops side. In particular I don't want to spend time trying to > work out how to automate the 'certificate lifecycle' premised on the > idea that client certs expire on an annual basis in a group where we > can't ask why the cert has to expire. > > On Thu, Aug 30, 2012 at 12:31 PM, Carl Wallace > wrote: >> On 8/30/12 12:28 PM, "Jon Callas" wrote: >> >>> On Aug 30, 2012, at 9:18 AM, Carl Wallace wrote: >>> >>>>> And for issuers, it can be difficult to predict what proportion of the >>>>> user population will accept a certificate chain with certain >>>>> characteristics. For instance, when a browser includes a nonce in an >>>>> OCSP request but the server supplies a >>>>> response that does not include the nonce, it is hard to know which >>>>> browsers will accept and which will reject the response. >>>>> >>>>> >>>>> >>>> >>>> Is client authentication processing performed by web servers in scope? >>>> If >>>> not, explicitly push that out of scope. >>> >>> It would be nice if it were in scope. Client authorization is a vastly >>> under-used feature. >>> >>> I wouldn't want to endanger everything else over it, but if we keep >>> sweeping it under the rug, it will continue to languish. >> >> I agree and would like to see it stay in scope as well. >> >> >> _______________________________________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/listinfo/wpkops > > > From tim.moses@entrust.com Tue Sep 4 10:13:36 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD3621F8569 for ; Tue, 4 Sep 2012 10:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lewovNH2rRbJ for ; Tue, 4 Sep 2012 10:13:34 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4894B21F8568 for ; Tue, 4 Sep 2012 10:13:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,367,1344225600"; d="scan'208,217";a="1856494" Received: from unknown (HELO SOTTEXCHCAS2.corp.ad.entrust.com) ([10.4.51.224]) by ipedge2.entrust.com with ESMTP; 04 Sep 2012 13:13:33 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by SOTTEXCHCAS2.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.001; Tue, 4 Sep 2012 13:13:33 -0400 From: Tim Moses To: "wpkops@ietf.org" Thread-Topic: 00 I-D on trust models Thread-Index: Ac2KwJva1iV25LdBSFS/lVEejHkcYg== Date: Tue, 4 Sep 2012 17:13:32 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A57CBA7@SOTTEXCH10.corp.ad.entrust.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.88] Content-Type: multipart/alternative; boundary="_000_5B68A271B9C97046963CB6A5B8D6F62C3A57CBA7SOTTEXCH10corpa_" MIME-Version: 1.0 Subject: [wpkops] 00 I-D on trust models X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 17:13:36 -0000 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A57CBA7SOTTEXCH10corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Colleagues - Here's a 00 I-D on trust models. http://tools.ietf.org/html/draft-moses-webpki-trustmodel-00 Please take a moment to look it over and comment. I need your help to corr= ect and complete it. Thanks a lot. All the best. Tim. T: +1 613 270 3183 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A57CBA7SOTTEXCH10corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Colleagues – Here’s a 00 I-D on trust mo= dels.

 

http://tools.ietf.org/html/draft-moses-webpki-trustmode= l-00

 

Please take a moment to look it over and comment.&nb= sp; I need your help to correct and complete it.

 

Thanks a lot.  All the best.  Tim.

 

T: +1 613 270 3183

 

--_000_5B68A271B9C97046963CB6A5B8D6F62C3A57CBA7SOTTEXCH10corpa_-- From carl@redhoundsoftware.com Tue Sep 4 11:11:37 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2AB11E80A3 for ; Tue, 4 Sep 2012 11:11:37 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiQdXnczyRT8 for ; Tue, 4 Sep 2012 11:11:36 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 10AC611E809A for ; Tue, 4 Sep 2012 11:11:35 -0700 (PDT) Received: by yenm5 with SMTP id m5so1373713yen.31 for ; Tue, 04 Sep 2012 11:11:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=7NX1N5KgB2fMhtZz3OQjjVDzYX5p2RaCO0FZOXFEl1s=; b=QvAY92sB1EiI0t4G8PtjD1mVq1+7FO/K4odnaaoKETULvS8S+m843smNPRaXF5gn0T K+npEqDaVq41oH8pUr41lKmlf+ROUr11f59tYeGnrmrDA4TC+rJISQ6DOAhun4NZYrja I/WgMkSOsPL246PI3vpl2hBmT2RF/O1vjMpILUbpMG8qyN+/5H6cWoRMGcIimfU51oF9 McVUZJPWqh/wWEUI3L0D0BdvQJY1zmqqyyV58JgVirPd2X+F1haRUhpP6jtz/7r2toqE gCPfklHM/1d+iyET6jSdIqSvUIuw8wKr4PoLrfqj9v+6eD7OswI8Htmcqm/D6QSNI2Fl 0POw== Received: by 10.58.33.234 with SMTP id u10mr17571429vei.49.1346782295492; Tue, 04 Sep 2012 11:11:35 -0700 (PDT) Received: from [192.168.2.8] (pool-71-191-137-227.washdc.fios.verizon.net. [71.191.137.227]) by mx.google.com with ESMTPS id g1sm1397126vdk.8.2012.09.04.11.11.32 (version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 11:11:34 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Tue, 04 Sep 2012 14:11:28 -0400 From: Carl Wallace To: Phillip Hallam-Baker Message-ID: Thread-Topic: [wpkops] Second draft charter proposal In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQkti1ehMeZmBcvsQxwp/twL4tCTQlAxapYCA92/99QTEO9bGaHlHIURuZaibR0B92kTzvwG Cc: wpkops@ietf.org, Jon Callas Subject: Re: [wpkops] Second draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 18:11:37 -0000 That sounds fair enough. My request was that if client auth was not in scope that it be explicitly called out as out of scope. I'm more interested in seeing documentation of the overlap/reuse of Web PKI components for enterprise and non-browser purposes being included as in scope since this is often a source of pain. On 9/4/12 12:28 PM, "Phillip Hallam-Baker" wrote: >I would like to see us 'do' something 'about' client authentication. > >But I don't see much of a client PKI out there to be operated, I think >we are going to have to 'build stuff' to fix it. So I don't think its >a PKI operations issue. > >I would prefer to see a separate, security area WG to look into the >client ops side. In particular I don't want to spend time trying to >work out how to automate the 'certificate lifecycle' premised on the >idea that client certs expire on an annual basis in a group where we >can't ask why the cert has to expire. > >On Thu, Aug 30, 2012 at 12:31 PM, Carl Wallace > wrote: >> On 8/30/12 12:28 PM, "Jon Callas" wrote: >> >>>On Aug 30, 2012, at 9:18 AM, Carl Wallace wrote: >>> >>>>> And for issuers, it can be difficult to predict what proportion of >>>>>the >>>>> user population will accept a certificate chain with certain >>>>> characteristics. For instance, when a browser includes a nonce in an >>>>> OCSP request but the server supplies a >>>>> response that does not include the nonce, it is hard to know which >>>>> browsers will accept and which will reject the response. >>>>> >>>>> >>>>> >>>> >>>> Is client authentication processing performed by web servers in scope? >>>>If >>>> not, explicitly push that out of scope. >>> >>>It would be nice if it were in scope. Client authorization is a vastly >>>under-used feature. >>> >>>I wouldn't want to endanger everything else over it, but if we keep >>>sweeping it under the rug, it will continue to languish. >> >> I agree and would like to see it stay in scope as well. >> >> >> _______________________________________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/listinfo/wpkops > > > >-- >Website: http://hallambaker.com/ > From joncallas@me.com Tue Sep 4 12:29:50 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407D811E80A3 for ; Tue, 4 Sep 2012 12:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.98 X-Spam-Level: X-Spam-Status: No, score=-5.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W61Aq6t3Nedz for ; Tue, 4 Sep 2012 12:29:49 -0700 (PDT) Received: from st11p01mm-asmtp004.mac.com (st11p01mm-asmtp004.mac.com [17.172.204.239]) by ietfa.amsl.com (Postfix) with ESMTP id 872C511E809A for ; Tue, 4 Sep 2012 12:29:49 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.9.163] (unknown [216.86.59.131]) by st11p01mm-asmtp004.mac.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Jan 3 2012)) with ESMTPSA id <0M9U00J2MBH6CWA0@st11p01mm-asmtp004.mac.com> for wpkops@ietf.org; Tue, 04 Sep 2012 19:29:33 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.431,0.0.0000 definitions=2012-09-04_06:2012-09-04, 2012-09-04, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=1 spamscore=1 ipscore=0 suspectscore=0 phishscore=0 bulkscore=1 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1209040201 References: <37FAC45A-304E-48A8-B294-A0C3F465FDAA@me.com> <007701cd8abd$6283a8a0$278af9e0$@digicert.com> In-reply-to: <007701cd8abd$6283a8a0$278af9e0$@digicert.com> Message-id: <13DDAB86-B2CF-4081-B99A-F9A176A85680@me.com> X-Mailer: iPad Mail (9B206) From: Jon Callas Date: Tue, 04 Sep 2012 15:29:31 -0400 To: "ben@digicert.com" Cc: Carl Wallace , "wpkops@ietf.org" , Phillip Hallam-Baker Subject: Re: [wpkops] Second draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 19:29:50 -0000 On Sep 4, 2012, at 12:50, Ben Wilson wrote: > While I agree that it needs to be addressed, I'm not sure I want to enlarge > the scope when our success will depend on our ability to handle the workload > and address and resolve the issues presented. I would rather push it off than have an unfocused group, but I still think it is part of "web PKI" and someone has th address it, so why not us? If I connect to example.com, it proves to me who it is through a certificate. I want to prove to it who I am through a certificate, too. That's the two halves of web PKI and it's that latter part I would like to include, if possible. Jon From joncallas@me.com Tue Sep 4 12:32:35 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B1221F84DC for ; Tue, 4 Sep 2012 12:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.98 X-Spam-Level: X-Spam-Status: No, score=-5.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ts9LoVGhCB4F for ; Tue, 4 Sep 2012 12:32:34 -0700 (PDT) Received: from st11p01mm-asmtp004.mac.com (st11p01mm-asmtp004.mac.com [17.172.204.239]) by ietfa.amsl.com (Postfix) with ESMTP id 36C8821F84D7 for ; Tue, 4 Sep 2012 12:32:34 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.9.163] (unknown [216.86.59.131]) by st11p01mm-asmtp004.mac.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Jan 3 2012)) with ESMTPSA id <0M9U0003KBLXBD00@st11p01mm-asmtp004.mac.com> for wpkops@ietf.org; Tue, 04 Sep 2012 19:32:23 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.431,0.0.0000 definitions=2012-09-04_06:2012-09-04, 2012-09-04, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1209040201 References: <37FAC45A-304E-48A8-B294-A0C3F465FDAA@me.com> <504632FC.9050706@telia.com> In-reply-to: <504632FC.9050706@telia.com> Message-id: <3A6B8C10-CF94-4C14-A8A4-2CC232DB19C5@me.com> X-Mailer: iPad Mail (9B206) From: Jon Callas Date: Tue, 04 Sep 2012 15:32:22 -0400 To: Anders Rundgren Cc: Carl Wallace , "wpkops@ietf.org" , Phillip Hallam-Baker Subject: Re: [wpkops] Second draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 19:32:35 -0000 On Sep 4, 2012, at 12:57, Anders Rundgren wrote: > On 2012-09-04 18:28, Phillip Hallam-Baker wrote: >> I would like to see us 'do' something 'about' client authentication. >> >> But I don't see much of a client PKI out there to be operated, I think >> we are going to have to 'build stuff' to fix it. So I don't think its >> a PKI operations issue. > > http://www.w3.org/2012/webcrypto This isn't the same thing. JOSE and all of that are doing crypto, and they are doing it on the web, but it isn't web PKI, either server side nor client side. Jon From ben@digicert.com Tue Sep 4 12:43:11 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E12021E8049 for ; Tue, 4 Sep 2012 12:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01HKnDGYmbZG for ; Tue, 4 Sep 2012 12:43:10 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id ADD7221E8041 for ; Tue, 4 Sep 2012 12:43:10 -0700 (PDT) Received: from BWILSONL1 (unknown [64.78.193.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 0CF121AE09D; Tue, 4 Sep 2012 13:43:10 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1346787790; bh=qOboQe72iLBeWzqJwlk8h1paoYw0L1NptsHO/EVFBTA=; h=Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date: Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QEMxbHEi6FzQBQ4ddW37gvMGPeiz5rRqzL7hGRY+efZ2Lu2bX05FBwf7AXBE8oJpX V4QuATEBkfuWQa/SXXNZwm6mRqUHyW08HF9XaxXbEM9/cQ3cYhoYVpc0RuGwRNa1ue BEkbKJajAiantz8+MVeSfklAFh959nx73zRBH/GE= From: "Ben Wilson" To: "'Jon Callas'" References: <37FAC45A-304E-48A8-B294-A0C3F465FDAA@me.com> <007701cd8abd$6283a8a0$278af9e0$@digicert.com> <13DDAB86-B2CF-4081-B99A-F9A176A85680@me.com> In-Reply-To: <13DDAB86-B2CF-4081-B99A-F9A176A85680@me.com> Date: Tue, 4 Sep 2012 13:43:08 -0600 Organization: DigiCert Message-ID: <00e201cd8ad5$829432f0$87bc98d0$@digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHahyLv7Zxir7m6bG8quokZXEzxZgLIi+coAmCHzZcA2CpsrwIT6sIWlx/yAEA= Content-Language: en-us Cc: 'Carl Wallace' , wpkops@ietf.org, 'Phillip Hallam-Baker' Subject: Re: [wpkops] Second draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ben@digicert.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 19:43:11 -0000 I'm fine addressing it, I just don't want to add things without realizing that there may be indirect impacts on quality and focus. I like client auth -- I just want to see the distinct subtasks laid out coherently so that the work can be kept straight. -----Original Message----- From: Jon Callas [mailto:joncallas@me.com] Sent: Tuesday, September 04, 2012 1:30 PM To: ben@digicert.com Cc: Phillip Hallam-Baker; Carl Wallace; wpkops@ietf.org Subject: Re: [wpkops] Second draft charter proposal On Sep 4, 2012, at 12:50, Ben Wilson wrote: > While I agree that it needs to be addressed, I'm not sure I want to > enlarge the scope when our success will depend on our ability to > handle the workload and address and resolve the issues presented. I would rather push it off than have an unfocused group, but I still think it is part of "web PKI" and someone has th address it, so why not us? If I connect to example.com, it proves to me who it is through a certificate. I want to prove to it who I am through a certificate, too. That's the two halves of web PKI and it's that latter part I would like to include, if possible. Jon From anders.rundgren@telia.com Tue Sep 4 12:51:45 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD4821E8084 for ; Tue, 4 Sep 2012 12:51:45 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGHqSZNPqH2Y for ; Tue, 4 Sep 2012 12:51:44 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF3121E8053 for ; Tue, 4 Sep 2012 12:51:38 -0700 (PDT) Received: from [192.168.0.203] (213.66.133.125) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 503A691C0038311C; Tue, 4 Sep 2012 21:51:34 +0200 Message-ID: <50465BC3.8050107@telia.com> Date: Tue, 04 Sep 2012 21:51:31 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Jon Callas References: <37FAC45A-304E-48A8-B294-A0C3F465FDAA@me.com> <504632FC.9050706@telia.com> <3A6B8C10-CF94-4C14-A8A4-2CC232DB19C5@me.com> In-Reply-To: <3A6B8C10-CF94-4C14-A8A4-2CC232DB19C5@me.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Carl Wallace , "wpkops@ietf.org" , Phillip Hallam-Baker Subject: Re: [wpkops] Second draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 19:51:45 -0000 On 2012-09-04 21:32, Jon Callas wrote: > On Sep 4, 2012, at 12:57, Anders Rundgren wrote: > >> On 2012-09-04 18:28, Phillip Hallam-Baker wrote: >>> I would like to see us 'do' something 'about' client authentication. >>> >>> But I don't see much of a client PKI out there to be operated, I think >>> we are going to have to 'build stuff' to fix it. So I don't think its >>> a PKI operations issue. >> >> http://www.w3.org/2012/webcrypto > > This isn't the same thing. JOSE and all of that are doing crypto, and they are doing it on the web, but it isn't web PKI, either server side nor client side. Jon, in Korea there are 25M active certificates for consumers, in Sweden there are 5M. These schemes are based on proprietary client software. One of the targets of WebCrypto is to get rid of this software. Here is a private proposal on how this could be done: http://webpki.org/papers/PKI/pki-webcrypto.pdf Anders > > Jon > From agl@google.com Tue Sep 4 13:40:59 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC8121F847F for ; Tue, 4 Sep 2012 13:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKWDz02cY2d8 for ; Tue, 4 Sep 2012 13:40:59 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id DA10021F8496 for ; Tue, 4 Sep 2012 13:40:58 -0700 (PDT) Received: by ieak13 with SMTP id k13so6703151iea.31 for ; Tue, 04 Sep 2012 13:40:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=ATSrxXIYN2Dh/pJitDuG830CbSTuZPwckR0MfBl31rI=; b=CO13ho/F/vu3LmpgyRU1SQ8YICd32mDpcfWcoZ6R5pwWcjzt1dOGSrkB23+EAF3ldX 9SvmpFH5Tzns9a63YOS59KNyhB19j4d2mqn6BtLGsXn3p7KcLjjng/uuvTvsxgLuA9Xt BvhrGpq88A01xXeryTGrBmUIGh0RCMtn0IqrjG8GdBqH+dGUrhtBN6ZQkLwXUHFiOiG7 E6E5OjLy25ISZvfJVKbKgiW/4TDq+ZCLIb6CdcYXtd7PeaXXwMIRlr2/n+QlFUJtezwf 66/oS+DEGRGfeJfiSfd1B/3WOD6u62uEHPeA3WanFn99mV1Z/8h7gf+U+ZolfhPrwh+M ZEPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=ATSrxXIYN2Dh/pJitDuG830CbSTuZPwckR0MfBl31rI=; b=NXkXb/gQl4Am4GjTcODKON690Wi9nMTfYDzNc+PoKNRih/UnH/7QOfElht9DXzwA/4 1BDuqcHXh6DX3h7IbKNvtx6AqGxVylMUDQ+lCMpzKMdyCIUOR0z7T6nTsWySgSw4bca6 0pOJdAwcJyUrs2zit4ar4ainAexEYOWrrz+ykBawpJxhpaPE2y4M/9TI4SG5AU76vT6R Vck0JUjB0nz+GRRZ1FvSGtN9X4748ZBUbKYmR8k33ougpbhPUaGIKhoXOoSNcc4ZRjik 5ABtQ8vZItcS9CL3UBYHBmWdPtS9nzuVcvsGII0SxBkxZ7N8BTEX2TF7D+qmFcQkv+aF klyg== Received: by 10.43.92.71 with SMTP id bp7mr19241397icc.52.1346791254544; Tue, 04 Sep 2012 13:40:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.92.71 with SMTP id bp7mr19222475icc.52.1346790817056; Tue, 04 Sep 2012 13:33:37 -0700 (PDT) Sender: agl@google.com Received: by 10.231.224.84 with HTTP; Tue, 4 Sep 2012 13:33:36 -0700 (PDT) In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A57CBA7@SOTTEXCH10.corp.ad.entrust.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A57CBA7@SOTTEXCH10.corp.ad.entrust.com> Date: Tue, 4 Sep 2012 16:33:36 -0400 X-Google-Sender-Auth: qxSBEBdU7Vx8tBB0eH1kIpUAzTk Message-ID: From: Adam Langley To: Tim Moses Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlV4TheOO+5mvysF9GVSZRZJ8dxpCGDh8O8FmikQvkoPkcmzi/fGEi0ReuPeNl1SS5ZDvutNTUd4v/YA7TMCBX6Q8PGsyvoRBaZCa6j41zNgijQtaILeidmB59cnWGD0ozc2J0/xbqeq2kyKuFib4uuxYx3HKrMc2rtOYynjHWmOBRk0b3NmIfH9lvBUfSwX+6Ko+dB Cc: "wpkops@ietf.org" Subject: Re: [wpkops] 00 I-D on trust models X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 20:41:00 -0000 On Tue, Sep 4, 2012 at 1:13 PM, Tim Moses wrote: > Please take a moment to look it over and comment. I need your help to > correct and complete it. I'm afraid that, while I lovely use of ASCII-art, I find the document very hard to understand. If I didn't already know what it was trying to say, I don't believe that I'd have a hope of understanding it. I feel that having two different labels in each box is a mistake, as are the carnality indicators, at least as currently drawn. Some examples may also help. Cheers AGL From dkg@fifthhorseman.net Tue Sep 4 14:50:30 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1CA21E8098 for ; Tue, 4 Sep 2012 14:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SrlJ7CXQC2A for ; Tue, 4 Sep 2012 14:50:30 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id DC80821E805A for ; Tue, 4 Sep 2012 14:50:29 -0700 (PDT) Received: from [192.168.13.75] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 511D0F970; Tue, 4 Sep 2012 17:50:27 -0400 (EDT) Message-ID: <5046779D.9050104@fifthhorseman.net> Date: Tue, 04 Sep 2012 17:50:21 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6 MIME-Version: 1.0 To: Adam Langley References: <5B68A271B9C97046963CB6A5B8D6F62C3A57CBA7@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: X-Enigmail-Version: 1.5a1pre Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig7591375C41814D908FC725C2" Cc: "wpkops@ietf.org" , Tim Moses Subject: Re: [wpkops] 00 I-D on trust models X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 21:50:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7591375C41814D908FC725C2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09/04/2012 04:33 PM, Adam Langley wrote: > On Tue, Sep 4, 2012 at 1:13 PM, Tim Moses wrote= : >> Please take a moment to look it over and comment. I need your help to= >> correct and complete it. >=20 > I'm afraid that, while I lovely use of ASCII-art, I find the document > very hard to understand. If I didn't already know what it was trying > to say, I don't believe that I'd have a hope of understanding it. while i think we need some kind of taxonomy/shared vocabulary like this document is trying to introduce, I'm afraid i have to echo Adam's sentiment here. The terminology and the ascii artwork seem confusing rather than enlightening. There are also some curious inconsistencies in this document. For example, section 3.1 ("Client Application uses OS root store") says "[the certificate user software] may then apply additional checks, such as checking that the certificate subject's domain name matches that requested by the certificate user." But surely that's also the case in section 2 ("Basic trust model") and the other 3.x sections? Also, section 3.8 ("The certificate user directly trusts a certificate-holder certificate") says: Clearly, in this case, the user does not benefit from any of the assurances normally provided by the policy management authority, the root CA, or the issuing CA. 3.7 contains similar language, but nowhere else in the document are any "assurances" mentioned. What do users generally expect from these assurances? Perhaps such things should be mentioned specifically before being referenced? Arguably, the same section could also say "In this case, the user's connections cannot be compromised by any flaws in the validation and certification processes enacted by the policy management authority, the root CA, or the issuing CA." i'm not sure one text is in any way more correct than the other, but it seems odd to have just the one perspective presented. Regards, --dkg --------------enig7591375C41814D908FC725C2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJQRneeXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpE/UQAKMfK3RYMC2ANQYSKe+LO67U qOA0eb+fNe80mj+bTSQNMYVys4byVc5+94peKFJzspMReIX4lkEKlnoR5CQMYMpC mapRmRTqdwiNYlaNofIYp5fPeEy/wUDgkylaWHQ9h0xHrGh3sfONKZZCG4CN74Pl PlmIJRyy5QXuERyIHVFy8JTlT0y5c8ifefnV9p7K62tBSH8t4NV5iQJHdVnD0/8K y437YEj7ETFk64kEtSPCH82DX3s2otv3qPD8U2Do6R99IQGd1iJnKmjEWkOAaNJx uKH7hCb6VZAMdqqxaONVu5cLfJS5i+XVdT9G8n5B538uZoN1TTZ/wvDZGWgk8Rev 3Eg2N4YSE4bqfru6XpKtvXVRahXJrcV/Zf2Ic7X+Cbtf9UCbNCS91XNk7vT5b54z 9jJ9zKcszhtfHD+GisS9rb5w4mjfgxZf28N4wUi7Vc8t0kPA6PIvqQicGCRBoabc h/nBSitzPnfjSCJwqV3GrWLAYVdrBx1gVwt/LyV2B8Ki12BwAGKP4fe7n7qJ3FFs 8bOjHzJwxU8H5fQqFGnG09F7whNYrlhsSiFE9vt81ufctYxd6PezRzBmkXYfOiLB B5jHSB0FYBP+m12YToMGSBe5myaBhbClp7O5barDwfL5NnMMejimNbjJIHfbPi7c y4fOPpXqeQT1ZzLjoJ3B =i79X -----END PGP SIGNATURE----- --------------enig7591375C41814D908FC725C2-- From Jeff.Hodges@KingsMountain.com Tue Sep 4 16:22:18 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2512521F841B for ; Tue, 4 Sep 2012 16:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u57iBeN-riUp for ; Tue, 4 Sep 2012 16:22:16 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id C44E221E80A8 for ; Tue, 4 Sep 2012 16:22:14 -0700 (PDT) Received: (qmail 18019 invoked by uid 0); 4 Sep 2012 23:22:13 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 4 Sep 2012 23:22:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=XgniSk9P402Q+sU4NC2gLiEBc6A4vrAZH24xEzHQK4Y=; b=3m7CQY5ku2VAvdUSlnJjUvVcCF961WBKreyns18ZGgZAOKp/ysmElIzyaq7+Dy79EoZd7+DOsanaoQ47B36/SG9jdk775muXK7bVoWXmWSfX/EX9vJvtWLkc6ceUyOyW; Received: from [216.113.168.128] (port=30031 helo=[10.244.136.33]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1T92Rh-0007lj-LQ; Tue, 04 Sep 2012 17:22:13 -0600 Message-ID: <50468D26.4020206@KingsMountain.com> Date: Tue, 04 Sep 2012 16:22:14 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Tim Moses Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: wpkops@ietf.org Subject: Re: [wpkops] 00 I-D on trust models X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 23:22:18 -0000 > Colleagues - Here's a 00 I-D on trust models. > > http://tools.ietf.org/html/draft-moses-webpki-trustmodel-00 > > Please take a moment to look it over and comment. I need your help to > correct and complete it. It appears to be a good start, thanks for writing it up. An overall +1 to AGL's comments. I think some definitions of terms would also help, such as at least these.. Unaffiliated user Certificate User Policy Management Authority certificate-holder certificate ..though all the terms for "functions of the Web PKI" should probably be at least briefly defined. Also, are figures 5 and 6 inter-related? on it's own I don't understand fig 5, and it almost seems fig 6 continues fig 5. In general, perhaps it'd help to describe in (much) more detailed prose what fig 1 is attempting to represent. eg, I don't understand the overlapping boxes, and don't know if you're referring to them in the last paragraph of section 1, or referring to the "stacked" boxes of the underlying large box. HTH, =JeffH From joncallas@me.com Wed Sep 5 06:07:27 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB9821F848F for ; Wed, 5 Sep 2012 06:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99C28TisvbJD for ; Wed, 5 Sep 2012 06:07:26 -0700 (PDT) Received: from st11p01mm-asmtp002.mac.com (st11p01mm-asmtpout002.mac.com [17.172.204.237]) by ietfa.amsl.com (Postfix) with ESMTP id 57A6D21F847A for ; Wed, 5 Sep 2012 06:07:26 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [10.32.240.187] ([198.228.192.114]) by st11p01mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Jan 3 2012)) with ESMTPSA id <0M9V007K1OFX6790@st11p01mm-asmtp002.mac.com> for wpkops@ietf.org; Wed, 05 Sep 2012 13:07:11 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.431,0.0.0000 definitions=2012-09-05_03:2012-09-05, 2012-09-05, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1209050097 References: <37FAC45A-304E-48A8-B294-A0C3F465FDAA@me.com> <504632FC.9050706@telia.com> <3A6B8C10-CF94-4C14-A8A4-2CC232DB19C5@me.com> <50465BC3.8050107@telia.com> In-reply-to: <50465BC3.8050107@telia.com> Message-id: <40C5A092-A326-4870-9890-9E061396D858@me.com> X-Mailer: iPad Mail (9B206) From: Jon Callas Date: Wed, 05 Sep 2012 09:05:42 -0400 To: Anders Rundgren Cc: Phillip Hallam-Baker , "wpkops@ietf.org" , Carl Wallace Subject: Re: [wpkops] Second draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 13:07:27 -0000 On Sep 4, 2012, at 15:51, Anders Rundgren wrote: > On 2012-09-04 21:32, Jon Callas wrote: >> On Sep 4, 2012, at 12:57, Anders Rundgren wrote: >> >>> On 2012-09-04 18:28, Phillip Hallam-Baker wrote: >>>> I would like to see us 'do' something 'about' client authentication. >>>> >>>> But I don't see much of a client PKI out there to be operated, I think >>>> we are going to have to 'build stuff' to fix it. So I don't think its >>>> a PKI operations issue. >>> >>> http://www.w3.org/2012/webcrypto >> >> This isn't the same thing. JOSE and all of that are doing crypto, and they are doing it on the web, but it isn't web PKI, either server side nor client side. > > Jon, in Korea there are 25M active certificates for consumers, in Sweden there are 5M. > These schemes are based on proprietary client software. > One of the targets of WebCrypto is to get rid of this software. > > Here is a private proposal on how this could be done: > > http://webpki.org/papers/PKI/pki-webcrypto.pdf Anders, This is a laudable goal, and indeed something worth solving. It is also something that JOSE addresses. It still isn't what we are talking about here. Repeating my use case, Alice connects to example.com with TLS. The host example.com authenticates to her with its certificate and she authenticates to example.com with hers. At that point, there is a mutually-authenticated TLS connection between them. This is a fine place to start using the webcrypto protocols over that TLS connection for use cases including those in that paper. I hope that what we would do in this working group would be to document edge conditions that the usual PKI documents don't address in using a client certs. I don't expect it to be much more than a few paragraphs, myself, but I'd be willing to lose it for the larger goal. Jon From tim.moses@entrust.com Wed Sep 5 06:16:15 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CCC21F8504 for ; Wed, 5 Sep 2012 06:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aQ6mRJ8Ytuw for ; Wed, 5 Sep 2012 06:16:15 -0700 (PDT) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id 570AB21F84EA for ; Wed, 5 Sep 2012 06:16:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,374,1344225600"; d="scan'208";a="6116306" Received: from unknown (HELO SOTTEXCHCAS2.corp.ad.entrust.com) ([10.4.51.224]) by ipedge1.entrust.com with ESMTP; 05 Sep 2012 09:16:12 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by SOTTEXCHCAS2.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.001; Wed, 5 Sep 2012 09:16:12 -0400 From: Tim Moses To: Adam Langley Thread-Topic: [wpkops] 00 I-D on trust models Thread-Index: Ac2KwJva1iV25LdBSFS/lVEejHkcYgAPXo0AABqiO+Y= Date: Wed, 5 Sep 2012 13:16:12 +0000 Message-ID: <8796517D-B6E0-4691-AA1E-F4D67623CDF1@entrust.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A57CBA7@SOTTEXCH10.corp.ad.entrust.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "wpkops@ietf.org" Subject: Re: [wpkops] 00 I-D on trust models X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 13:16:16 -0000 Thanks Adam. If the figures aren't adding anything, we might as well just = delete them. All the best. Tim. On 2012-09-04, at 4:33 PM, "Adam Langley" wrote: > On Tue, Sep 4, 2012 at 1:13 PM, Tim Moses wrote: >> Please take a moment to look it over and comment. I need your help to >> correct and complete it. >=20 > I'm afraid that, while I lovely use of ASCII-art, I find the document > very hard to understand. If I didn't already know what it was trying > to say, I don't believe that I'd have a hope of understanding it. I > feel that having two different labels in each box is a mistake, as are > the carnality indicators, at least as currently drawn. Some examples > may also help. >=20 >=20 > Cheers >=20 > AGL From anders.rundgren@telia.com Wed Sep 5 06:19:45 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABD621F85A8 for ; Wed, 5 Sep 2012 06:19:45 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWmcTNMOomcJ for ; Wed, 5 Sep 2012 06:19:44 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 52CDE21F85A3 for ; Wed, 5 Sep 2012 06:19:44 -0700 (PDT) Received: from [192.168.0.203] (213.66.133.125) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 503A691C003D0C7C; Wed, 5 Sep 2012 15:19:41 +0200 Message-ID: <50475169.8090607@telia.com> Date: Wed, 05 Sep 2012 15:19:37 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Jon Callas References: <37FAC45A-304E-48A8-B294-A0C3F465FDAA@me.com> <504632FC.9050706@telia.com> <3A6B8C10-CF94-4C14-A8A4-2CC232DB19C5@me.com> <50465BC3.8050107@telia.com> <40C5A092-A326-4870-9890-9E061396D858@me.com> In-Reply-To: <40C5A092-A326-4870-9890-9E061396D858@me.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "wpkops@ietf.org" Subject: Re: [wpkops] Second draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 13:19:45 -0000 On 2012-09-05 15:05, Jon Callas wrote: > > On Sep 4, 2012, at 15:51, Anders Rundgren wrote: > >> On 2012-09-04 21:32, Jon Callas wrote: >>> On Sep 4, 2012, at 12:57, Anders Rundgren wrote: >>> >>>> On 2012-09-04 18:28, Phillip Hallam-Baker wrote: >>>>> I would like to see us 'do' something 'about' client authentication. >>>>> >>>>> But I don't see much of a client PKI out there to be operated, I think >>>>> we are going to have to 'build stuff' to fix it. So I don't think its >>>>> a PKI operations issue. >>>> >>>> http://www.w3.org/2012/webcrypto >>> >>> This isn't the same thing. JOSE and all of that are doing crypto, and they are doing it on the web, but it isn't web PKI, either server side nor client side. >> >> Jon, in Korea there are 25M active certificates for consumers, in Sweden there are 5M. >> These schemes are based on proprietary client software. >> One of the targets of WebCrypto is to get rid of this software. >> >> Here is a private proposal on how this could be done: >> >> http://webpki.org/papers/PKI/pki-webcrypto.pdf > > Anders, > > This is a laudable goal, and indeed something worth solving. > It is also something that JOSE addresses. It still isn't what we are talking about here. Pardon my ignorance but I'm not sure then what you mean with client-side PKI. > > Repeating my use case, Alice connects to example.com with TLS. > The host example.com authenticates to her with its certificate > and she authenticates to example.com with hers. At that point, > there is a mutually-authenticated TLS connection between them. > This is a fine place to start using the webcrypto protocols > over that TLS connection for use cases including those in that paper. I don't think this applies to the payment example I outlined. In such scenarios you authenticate the server but not the client. The client rather signs (authorizes) a request. The request may even be rerouted behind the curtain to another party (like your bank), although it (for the user) looks like you actually pay directly to the merchant. > > I hope that what we would do in this working group would be to > document edge conditions that the usual PKI documents don't address > in using a client certs. I have no idea what this could be so I look forward to any kind of documentation. I'm personally trying to get the basics going because currently it doesn't work well at all. Anders I don't expect it to be much more than a few paragraphs, myself, but I'd be willing to lose it for the larger goal. > > Jon > From tim.moses@entrust.com Wed Sep 5 07:03:58 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C0821F8599 for ; Wed, 5 Sep 2012 07:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRhXu1U3MH1k for ; Wed, 5 Sep 2012 07:03:57 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8F19821F8596 for ; Wed, 5 Sep 2012 07:03:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,374,1344225600"; d="scan'208";a="1864886" Received: from unknown (HELO sottexchcas1.corp.ad.entrust.com) ([10.4.51.93]) by ipedge2.entrust.com with ESMTP; 05 Sep 2012 10:03:56 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by sottexchcas1.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.001; Wed, 5 Sep 2012 10:03:56 -0400 From: Tim Moses To: =JeffH Thread-Topic: [wpkops] 00 I-D on trust models Thread-Index: AQHNivQd1iV25LdBSFS/lVEejHkcYpd7yKsk Date: Wed, 5 Sep 2012 14:03:55 +0000 Message-ID: <51B22C73-208C-4212-BEF3-760B0A99DBA4@entrust.com> References: <50468D26.4020206@KingsMountain.com> In-Reply-To: <50468D26.4020206@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "wpkops@ietf.org" Subject: Re: [wpkops] 00 I-D on trust models X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 14:03:58 -0000 Thanks Jeff. I think I'll dispense with the figures; they clearly aren't h= elping. I will add definitions, though. All the best. Tim. On 2012-09-04, at 7:22 PM, "=3DJeffH" wrote= : > > Colleagues - Here's a 00 I-D on trust models. > > > > http://tools.ietf.org/html/draft-moses-webpki-trustmodel-00 > > > > Please take a moment to look it over and comment. I need your help to > > correct and complete it. >=20 >=20 > It appears to be a good start, thanks for writing it up. >=20 > An overall +1 to AGL's comments. I think some definitions of terms would= also help, such as at least these.. >=20 > Unaffiliated user >=20 > Certificate User >=20 > Policy Management Authority >=20 > certificate-holder certificate >=20 > ..though all the terms for "functions of the Web PKI" should probably be = at > least briefly defined. >=20 > Also, are figures 5 and 6 inter-related? on it's own I don't understand = fig 5, > and it almost seems fig 6 continues fig 5. >=20 > In general, perhaps it'd help to describe in (much) more detailed prose w= hat fig 1 is attempting to represent. eg, I don't understand the overlappi= ng boxes, and don't know if you're referring to them in the last paragraph = of section 1, or referring to the "stacked" boxes of the underlying large b= ox. >=20 >=20 > HTH, >=20 > =3DJeffH >=20 From leifj@mnt.se Wed Sep 5 08:38:30 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F55121F85AD for ; Wed, 5 Sep 2012 08:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTYRpD9EEKfj for ; Wed, 5 Sep 2012 08:38:29 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [193.10.252.66]) by ietfa.amsl.com (Postfix) with ESMTP id 486CA21F85A3 for ; Wed, 5 Sep 2012 08:38:27 -0700 (PDT) Received: from [145.96.3.16] (host-16-3.eduroamers.nl [145.96.3.16]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q85Fb5WZ002507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Sep 2012 17:37:10 +0200 (CEST) Message-ID: <504771A1.9050102@mnt.se> Date: Wed, 05 Sep 2012 17:37:05 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: wpkops@ietf.org References: <5B68A271B9C97046963CB6A5B8D6F62C3A57CBA7@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [wpkops] 00 I-D on trust models X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:38:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/04/2012 10:33 PM, Adam Langley wrote: > On Tue, Sep 4, 2012 at 1:13 PM, Tim Moses > wrote: >> Please take a moment to look it over and comment. I need your >> help to correct and complete it. > > I'm afraid that, while I lovely use of ASCII-art, I find the > document very hard to understand. If I didn't already know what it > was trying to say, I don't believe that I'd have a hope of > understanding it. I feel that having two different labels in each > box is a mistake, as are the carnality indicators, at least as > currently drawn. Some examples may also help. > +1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBHcaEACgkQ8Jx8FtbMZne4BQCeLvaPoTge0rofjY7X10xPqgrq U7AAn2TXAuh796fisuQdgs+UL79XqWtL =s+uN -----END PGP SIGNATURE----- From Jeff.Hodges@KingsMountain.com Wed Sep 5 13:35:59 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6110821F86B7 for ; Wed, 5 Sep 2012 13:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npK7KsMcH7If for ; Wed, 5 Sep 2012 13:35:58 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 26ADE21F86A2 for ; Wed, 5 Sep 2012 13:35:58 -0700 (PDT) Received: (qmail 15587 invoked by uid 0); 5 Sep 2012 20:35:56 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 5 Sep 2012 20:35:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=8fKXktrt49ym5XyMQ5WGi5WucGr+LOYv9UzCDrGs4gc=; b=vULOCmfswszNNPrB+YuWBDRsxKO9dN6rJoisvRPl/DW6O4pjh+TfIdWEC0bhj4XZoBySaoSUosbBSXIu6SfMbL3RxpQxrEylV71fLF9errdUKWUgyGiOqoKAWn1Ms4Z0; Received: from [24.4.122.173] (port=43956 helo=[192.168.11.12]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1T9MKJ-00043a-BG for wpkops@ietf.org; Wed, 05 Sep 2012 14:35:55 -0600 Message-ID: <5047B7A9.4000407@KingsMountain.com> Date: Wed, 05 Sep 2012 13:35:53 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: wpkops@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [wpkops] Second draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 20:35:59 -0000 Tim replied.. > > I'd said.. >> >> a detail-level comment: >> >> > Also, the reliability of the Web PKI depends critically on the practices of >> > its certificate issuers. However, the topic of practices is outside the >> > scope of the IETF. Therefore, this will be left to other competent bodies. >> >> "practices of ... certificate issuers" needs to be clearly defined in order >> to disambiguate between, e.g., verification of certificate issuance requester >> and CA infrastructure operational practices. >> >> My understanding is that this scope declaration is intended to exclude the >> former and not necessarily the latter, but this isn't clear. > > I was thinking that "both" aspects of practices should be outside the scope > of an IETF activity. Maybe so, at least for now. Although, the term "practices" in the draft charter should be defined, and refs to the relevant (technical) CA/Browser Forum (CABF) documents included, which are it seems.. https://www.cabforum.org/Network_Security_Controls_V1.pdf https://www.cabforum.org/Baseline_Requirements_V1.pdf https://www.cabforum.org/Guidelines_v1_4.pdf https://www.cabforum.org/Guidelines_for_the_processing_of_EV_certificates%20v1_0.pdf (note that some IETF working group charters do contain refs to various docs for context-setting purposes) > The CA/Browser Forum is working on these with the > co-operation of the root-program operators and the relevant audit experts > (ETSI and WebTrust). I think that best value is obtained from the IETF > community by focusing on technical protocols. No? Just to note, the IETF Ops Area has explicitly specified infrastructural operational "practices" in at least two cases, see for example.. DNSSEC Operational Practices https://datatracker.ietf.org/doc/rfc4641/ Current Operational Security Practices in Internet Service Provider Environments https://datatracker.ietf.org/doc/rfc4778/ HTH, =JeffH From stephen.farrell@cs.tcd.ie Thu Sep 6 07:42:30 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABDA21F8504; Thu, 6 Sep 2012 07:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OM0WU6WNxPS6; Thu, 6 Sep 2012 07:42:29 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 43E5A21F8501; Thu, 6 Sep 2012 07:42:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D7F7A17147A; Thu, 6 Sep 2012 15:42:27 +0100 (IST) 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=1346942547; bh=FdWuwDOj2gXykg yC9E1/2LnKzVi/Gh71yN4r0Omg7M0=; b=abRor1NzYMABM0jMRYCxD7dW2oXAxX GbpiQH64yTJIUY3Llk46oeosmaBD+GXwP6tF7zGanG+HBVdQkX+c36QdG0B8gwOq BYxZ/+C5KJ4RPYhs2VIBaO0C1ksmfm9Q9fVJNdbXoGb049uylyVW2wOkwfn4sHhZ HHxJStawzphgUra7gd4o/Y0v8jyMlIXRJb5cMoMm4YeB6Yh/udBg9sVVygdUK13K GF777f76YbpQ/paHbX1mQp+v8QV4tvJ1WAQIaWhhxetFjjcEqHQJmpwXdK3x4b14 JtExNJjZSWiJXI+9UQvZh2IqMIId8BNGBfloncX59sZqe6P6BBamXaVA== 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 5NTQ+R1Vsr2i; Thu, 6 Sep 2012 15:42:27 +0100 (IST) Received: from [10.87.48.9] (unknown [86.44.75.103]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 4EAB0171486; Thu, 6 Sep 2012 15:42:27 +0100 (IST) Message-ID: <5048B653.3080902@cs.tcd.ie> Date: Thu, 06 Sep 2012 15:42:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "saag@ietf.org" , "'wpkops@ietf.org'" , pkix References: In-Reply-To: X-Enigmail-Version: 1.4.4 X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [wpkops] Fwd: [therightkey] Certificate Transparency Working Group? X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:42:30 -0000 Hi all, Please see below. Ben Laurie's looking to see if folks are interested in a BoF on Certificate Transparency for the IETF meeting in Altanta. Sean and I would be fine with that, if there's sufficient interest etc. Please follow up on therightkey@ietf.org if this is a topic that's of interest to you. Thanks, Stephen. -------- Original Message -------- Subject: [therightkey] Certificate Transparency Working Group? Date: Thu, 6 Sep 2012 15:32:05 +0100 From: Ben Laurie To: therightkey@ietf.org Would people be interested in starting a WG on Certificate Transparency? If so, how about a BoF in Atlanta? Here's a draft charter... CT IETF WG Draft Charter Objective Specify mechanisms and techniques that allow Internet applications to monitor and verify the issuance of public X.509 certificates such that all public issued certificates are available to applications, and each certificate seen by an application can be efficiently shown to be in the log of issued certificates. Furthermore, it should be possible to cryptographically verify the correct operation of the log. Optionally, do the same for certificate revocations. Problem Statement Currently it is possible for any CA to issue a certificate for any site without any oversight. This has led to some high profile mis-issuance of certificates, such as by DigiNotar, a subsidiary of VASCO Data Security International, in July 2011 (http://www.vasco.com/company/about_vasco/press_room/news_archive/2011/news_diginotar_reports_security_incident.aspx). The aim is to make it possible to detect such mis-issuance promptly through the use of a public log of all public issued certificates. Domain owners can then monitor this log and, upon detecting mis-issuance, take appropriate action. This public log must also be able to efficiently demonstrate its own correct operation, rather than introducing yet another party that must be trusted into the equation. Clients should also be able to efficiently verify that certificates they receive have indeed been entered into the public log. For revocations, the aim would be similar: ensure that revocations are as expected, that clients can efficiently obtain the revocation status of a certificate and that the log is operating correctly. Also, in both cases, the solution must be usable by browsers - this means that it cannot add any round trips to page fetches, and that any data transfers that are mandatory are of a reasonable size. _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey From denis.pinkas@bull.net Thu Sep 6 07:55:49 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55ED421F857A; Thu, 6 Sep 2012 07:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZFNyFpOSV97; Thu, 6 Sep 2012 07:55:48 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1475821F8568; Thu, 6 Sep 2012 07:55:48 -0700 (PDT) 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 41C3818170; Thu, 6 Sep 2012 16:55:47 +0200 (CEST) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <5048B653.3080902@cs.tcd.ie> References: <5048B653.3080902@cs.tcd.ie>, X-Disclaimed: 1 From: denis.pinkas@bull.net To: stephen.farrell@cs.tcd.ie Message-ID: Date: Thu, 6 Sep 2012 16:55:46 +0200 X-Mailer: Lotus Domino Web Server Release 8.5.2FP1 November 29, 2010 X-MIMETrack: Serialize by HTTP Server on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 06/09/2012 16:55:46, Serialize complete at 06/09/2012 16:55:46, Itemize by HTTP Server on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 06/09/2012 16:55:46, Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 06/09/2012 16:55:47, Serialize complete at 06/09/2012 16:55:47 Content-Type: multipart/alternative; boundary="=_alternative 0052028CC1257A71_=" X-Mailman-Approved-At: Thu, 06 Sep 2012 07:57:09 -0700 Cc: pkix@ietf.org, wpkops@ietf.org, saag@ietf.org Subject: Re: [wpkops] [pkix] Fwd: [therightkey] Certificate Transparency Working Group? X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:55:49 -0000 --=_alternative 0052028CC1257A71_= Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Part of the stated objective (i.e. verify the issuance of public X.509 cert= ificates)=20 is currently addressed, within the context of OCSP, in : https://datatracker.ietf.org/doc/draft-pinkas-2560bis-certinfo/ This draft is being considered within the PKIX WG. The second part of the objective (i.e. making all public issued certificate= s available to applications)=20 may be dangerous in many situations.=20 Denis -----pkix-bounces@ietf.org a =E9crit : -----=20 A : "saag@ietf.org" , "'wpkops@ietf.org'" ,= pkix De : Stephen Farrell=20 Envoy=E9 par : pkix-bounces@ietf.org Date : 06/09/2012 16:42 Objet : [pkix] Fwd: [therightkey] Certificate Transparency Working Group? Hi all, Please see below. Ben Laurie's looking to see if folks are interested in a BoF on Certificate Transparency for the IETF meeting in Altanta. Sean and I would be fine with that, if there's sufficient interest etc. Please follow up on therightkey@ietf.org if this is a topic that's of interest to you. Thanks, Stephen. -------- Original Message -------- Subject: [therightkey] Certificate Transparency Working Group? Date: Thu, 6 Sep 2012 15:32:05 +0100 From: Ben Laurie To: therightkey@ietf.org Would people be interested in starting a WG on Certificate Transparency? If so, how about a BoF in Atlanta? Here's a draft charter... CT IETF WG Draft Charter Objective Specify mechanisms and techniques that allow Internet applications to monitor and verify the issuance of public X.509 certificates such that all public issued certificates are available to applications, and each certificate seen by an application can be efficiently shown to be in the log of issued certificates. Furthermore, it should be possible to cryptographically verify the correct operation of the log. Optionally, do the same for certificate revocations. Problem Statement Currently it is possible for any CA to issue a certificate for any site without any oversight. This has led to some high profile mis-issuance of certificates, such as by DigiNotar, a subsidiary of VASCO Data Security International, in July 2011 (http://www.vasco.com/company/about=5Fvasco/press=5Froom/news=5Farchive/201= 1/news=5Fdiginotar=5Freports=5Fsecurity=5Fincident.aspx). The aim is to make it possible to detect such mis-issuance promptly through the use of a public log of all public issued certificates. Domain owners can then monitor this log and, upon detecting mis-issuance, take appropriate action. This public log must also be able to efficiently demonstrate its own correct operation, rather than introducing yet another party that must be trusted into the equation. Clients should also be able to efficiently verify that certificates they receive have indeed been entered into the public log. For revocations, the aim would be similar: ensure that revocations are as expected, that clients can efficiently obtain the revocation status of a certificate and that the log is operating correctly. Also, in both cases, the solution must be usable by browsers - this means that it cannot add any round trips to page fetches, and that any data transfers that are mandatory are of a reasonable size. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 0052028CC1257A71_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Part of the stated objective (i.e. verify the issuance of publi= c X.509 certificates)
is currently addressed, within the context of OCS= P, in :
=0D
 
=0D=0D

This draft is be= ing considered within the PKIX WG.
=0D
 
=0D
= = The second part of the objective (i.e. making all public issued certificate= s available to applications)
may be dangerous in many situations.
=0D
 
=0D
Denis
=0D

-----pkix-bounces@ietf.org a =E9crit : -----
=0D
=0D=
A : "saag@ietf.org" <= ;saag@ietf.org>, "'wpkops@ietf.org'" <wpkops@ietf.org>, pkix <p= kix@ietf.org>
De : Stephen Farrell
Env= oy=E9 par : pkix-bounces@ietf.org
Date : 06/09/2012 16:42
Objet : [pk= ix] Fwd: [therightkey] Certificate Transparency Working Group?

Hi all,

Pl= ease see below. Ben Laurie's looking to see if folks are
interested in a= BoF on Certificate Transparency for the
IETF meeting in Altanta.
Sean and I would be fine with that, if there's sufficient
interest etc.=

Please follow up on therightkey@ietf.org if this is a
topic that= 's of interest to you.

Thanks,
Stephen.


-------- Origi= nal Message --------
Subject: [therightkey] Certificate Transparency Wor= king Group?
Date: Thu, 6 Sep 2012 15:32:05 +0100
From: Ben Laurie <= ;benl@google.com>
To: therightkey@ietf.org

Would people be int= erested in starting a WG on Certificate
Transparency? If so, how about a= BoF in Atlanta?

Here's a draft charter...


CT IETF WG Dra= ft Charter

Objective

Specify mechanisms and techniques that a= llow Internet applications to
monitor and verify the issuance of public = X.509 certificates such that
all public issued certificates are availabl= e to applications, and each
certificate seen by an application can be ef= ficiently shown to be in
the log of issued certificates. Furthermore, it= should be possible to
cryptographically verify the correct operation of= the log.


Optionally, do the same for certificate revocations.
Problem Statement

Currently it is possible for any CA to issue= a certificate for any
site without any oversight. This has led to some = high profile
mis-issuance of certificates, such as by DigiNotar, a subsi= diary of
VASCO Data Security International, in July 2011
(http://www.vasco.co= m/company/about=5Fvasco/press=5Froom/news=5Farchive/2011/news=5Fdiginotar= =5Freports=5Fsecurity=5Fincident.aspx).


The aim is to make i= t possible to detect such mis-issuance promptly
through the use of a pub= lic log of all public issued certificates.
Domain owners can then monito= r this log and, upon detecting
mis-issuance, take appropriate action.

This public log must also be able to efficiently demonstrate its o= wn
correct operation, rather than introducing yet another party that mus= t
be trusted into the equation.


Clients should also be able t= o efficiently verify that certificates
they receive have indeed been ent= ered into the public log.


For revocations, the aim would be simi= lar: ensure that revocations are
as expected, that clients can efficient= ly obtain the revocation status
of a certificate and that the log is ope= rating correctly.


Also, in both cases, the solution must be usab= le by browsers - this
means that it cannot add any round trips to page f= etches, and that any
data transfers that are mandatory are of a reasonab= le size.
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/= listinfo/therightkey




=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org<= BR>https://www.ietf.= org/mailman/listinfo/pkix
=0D
--=_alternative 0052028CC1257A71_=-- From stephen.farrell@cs.tcd.ie Thu Sep 6 07:58:10 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD91B21F8683; Thu, 6 Sep 2012 07:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kq4FIW41YCvk; Thu, 6 Sep 2012 07:58:09 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 142F621F866E; Thu, 6 Sep 2012 07:58:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 7FC01171486; Thu, 6 Sep 2012 15:58:08 +0100 (IST) 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=1346943488; bh=SGDn/Gvpj2skaZ 3O25K8NbvfB1rlHxE3AEcjL9x08IE=; b=oR2zI6AmFJrPfvo2nDdGzSWj9XL0Pf Gfq5Iy83saZFF6b/gWgm555Z/nkrkrSOyV9r3FLCvIknfxg4t58tq8qR2xqhvQt0 PZPP7Q75kzC23ne0Nn8zMhwI2qcZkH6VPFSITQpwkN21esbg/5mJ24m5XHMIcwC5 dqOLQxQWdHIczOrujES9O41ZapiN44SA4AYGIQuwLoTqFvh0XWyKozexpbgghwct W5UvAbXEHpeffocvk5CvkzrodYr/ovTrvO43QM+qEuCJ5CpO+/UpZm0ab73NXVux eL8RKms7Xwv08dugoi/47lOMAxTRKZyWR2XAbNBiImWEzM5k2F4p0e5A== 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 ZMb38ijg-nek; Thu, 6 Sep 2012 15:58:08 +0100 (IST) Received: from [10.87.48.9] (unknown [86.44.75.103]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D42D117147A; Thu, 6 Sep 2012 15:58:07 +0100 (IST) Message-ID: <5048B9FF.50801@cs.tcd.ie> Date: Thu, 06 Sep 2012 15:58:07 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: denis.pinkas@bull.net References: <5048B653.3080902@cs.tcd.ie>, In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: pkix@ietf.org, wpkops@ietf.org, saag@ietf.org Subject: Re: [wpkops] [pkix] Fwd: [therightkey] Certificate Transparency Working Group? X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:58:10 -0000 Denis, all, Please follow-up on therightkey@ietf.org which is where this will be discussed. Thanks, S. On 09/06/2012 03:55 PM, denis.pinkas@bull.net wrote: > Part of the stated objective (i.e. verify the issuance of public X.509 certificates) > is currently addressed, within the context of OCSP, in : > > https://datatracker.ietf.org/doc/draft-pinkas-2560bis-certinfo/ > > This draft is being considered within the PKIX WG. > > The second part of the objective (i.e. making all public issued certificates available to applications) > may be dangerous in many situations. > > Denis > > -----pkix-bounces@ietf.org a écrit : ----- > A : "saag@ietf.org" , "'wpkops@ietf.org'" , pkix > De : Stephen Farrell > Envoyé par : pkix-bounces@ietf.org > Date : 06/09/2012 16:42 > Objet : [pkix] Fwd: [therightkey] Certificate Transparency Working Group? > > Hi all, > > Please see below. Ben Laurie's looking to see if folks are > interested in a BoF on Certificate Transparency for the > IETF meeting in Altanta. > > Sean and I would be fine with that, if there's sufficient > interest etc. > > Please follow up on therightkey@ietf.org if this is a > topic that's of interest to you. > > Thanks, > Stephen. > > > -------- Original Message -------- > Subject: [therightkey] Certificate Transparency Working Group? > Date: Thu, 6 Sep 2012 15:32:05 +0100 > From: Ben Laurie > To: therightkey@ietf.org > > Would people be interested in starting a WG on Certificate > Transparency? If so, how about a BoF in Atlanta? > > Here's a draft charter... > > > CT IETF WG Draft Charter > > Objective > > Specify mechanisms and techniques that allow Internet applications to > monitor and verify the issuance of public X.509 certificates such that > all public issued certificates are available to applications, and each > certificate seen by an application can be efficiently shown to be in > the log of issued certificates. Furthermore, it should be possible to > cryptographically verify the correct operation of the log. > > > Optionally, do the same for certificate revocations. > > Problem Statement > > Currently it is possible for any CA to issue a certificate for any > site without any oversight. This has led to some high profile > mis-issuance of certificates, such as by DigiNotar, a subsidiary of > VASCO Data Security International, in July 2011 > (http://www.vasco.com/company/about_vasco/press_room/news_archive/2011/news_diginotar_reports_security_incident.aspx). > > > The aim is to make it possible to detect such mis-issuance promptly > through the use of a public log of all public issued certificates. > Domain owners can then monitor this log and, upon detecting > mis-issuance, take appropriate action. > > > This public log must also be able to efficiently demonstrate its own > correct operation, rather than introducing yet another party that must > be trusted into the equation. > > > Clients should also be able to efficiently verify that certificates > they receive have indeed been entered into the public log. > > > For revocations, the aim would be similar: ensure that revocations are > as expected, that clients can efficiently obtain the revocation status > of a certificate and that the log is operating correctly. > > > Also, in both cases, the solution must be usable by browsers - this > means that it cannot add any round trips to page fetches, and that any > data transfers that are mandatory are of a reasonable size. > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > From SChokhani@cygnacom.com Thu Sep 6 14:19:38 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779CA21F86B5; Thu, 6 Sep 2012 14:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYI3SZWf5mR8; Thu, 6 Sep 2012 14:19:35 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCF621F867C; Thu, 6 Sep 2012 14:19:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,381,1344225600"; d="scan'208,217";a="1880458" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 06 Sep 2012 17:19:31 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 6 Sep 2012 17:19:31 -0400 From: Santosh Chokhani To: "denis.pinkas@bull.net" , "stephen.farrell@cs.tcd.ie" Date: Thu, 6 Sep 2012 17:19:30 -0400 Thread-Topic: [pkix] Fwd: [therightkey] Certificate Transparency Working Group? Thread-Index: Ac2MP7aNNCOrJRfXREq4TcOezgbyVAANRC1w Message-ID: References: <5048B653.3080902@cs.tcd.ie>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AF362EC770scygexch7cygnac_" MIME-Version: 1.0 Cc: "pkix@ietf.org" , "wpkops@ietf.org" , "saag@ietf.org" Subject: Re: [wpkops] [pkix] Fwd: [therightkey] Certificate Transparency Working Group? X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 21:19:38 -0000 --_000_B83745DA469B7847811819C5005244AF362EC770scygexch7cygnac_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Denis, As you may have seen my comment on this I-D and additions for security cons= ideration, this extension does not provide the requisite transparency since= anyone who has compromised the CA can put in their own OCSP pointer. That is the reason I want you to add the text in the "Security Consideratio= ns" section. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of den= is.pinkas@bull.net Sent: Thursday, September 06, 2012 10:56 AM To: stephen.farrell@cs.tcd.ie Cc: pkix@ietf.org; wpkops@ietf.org; saag@ietf.org Subject: Re: [pkix] Fwd: [therightkey] Certificate Transparency Working Gro= up? Part of the stated objective (i.e. verify the issuance of public X.509 cert= ificates) is currently addressed, within the context of OCSP, in : https://datatracker.ietf.org/doc/draft-pinkas-2560bis-certinfo/ This draft is being considered within the PKIX WG. The second part of the objective (i.e. making all public issued certificate= s available to applications) may be dangerous in many situations. Denis -----pkix-bounces@ietf.org a =E9crit : -= ---- A : "saag@ietf.org" >, "'wpkops@ietf.org'" >, pkix <= pkix@ietf.org> De : Stephen Farrell Envoy=E9 par : pkix-bounces@ietf.org Date : 06/09/2012 16:42 Objet : [pkix] Fwd: [therightkey] Certificate Transparency Working Group? Hi all, Please see below. Ben Laurie's looking to see if folks are interested in a BoF on Certificate Transparency for the IETF meeting in Altanta. Sean and I would be fine with that, if there's sufficient interest etc. Please follow up on therightkey@ietf.org if th= is is a topic that's of interest to you. Thanks, Stephen. -------- Original Message -------- Subject: [therightkey] Certificate Transparency Working Group? Date: Thu, 6 Sep 2012 15:32:05 +0100 From: Ben Laurie > To: therightkey@ietf.org Would people be interested in starting a WG on Certificate Transparency? If so, how about a BoF in Atlanta? Here's a draft charter... CT IETF WG Draft Charter Objective Specify mechanisms and techniques that allow Internet applications to monitor and verify the issuance of public X.509 certificates such that all public issued certificates are available to applications, and each certificate seen by an application can be efficiently shown to be in the log of issued certificates. Furthermore, it should be possible to cryptographically verify the correct operation of the log. Optionally, do the same for certificate revocations. Problem Statement Currently it is possible for any CA to issue a certificate for any site without any oversight. This has led to some high profile mis-issuance of certificates, such as by DigiNotar, a subsidiary of VASCO Data Security International, in July 2011 (http://www.vasco.com/company/about_vasco/press_room/news_archive/2011/news= _diginotar_reports_security_incident.aspx). The aim is to make it possible to detect such mis-issuance promptly through the use of a public log of all public issued certificates. Domain owners can then monitor this log and, upon detecting mis-issuance, take appropriate action. This public log must also be able to efficiently demonstrate its own correct operation, rather than introducing yet another party that must be trusted into the equation. Clients should also be able to efficiently verify that certificates they receive have indeed been entered into the public log. For revocations, the aim would be similar: ensure that revocations are as expected, that clients can efficiently obtain the revocation status of a certificate and that the log is operating correctly. Also, in both cases, the solution must be usable by browsers - this means that it cannot add any round trips to page fetches, and that any data transfers that are mandatory are of a reasonable size. _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --_000_B83745DA469B7847811819C5005244AF362EC770scygexch7cygnac_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Denis,<= /o:p>

 

As you may have seen my comment on this I-D and addition= s for security consideration, this extension does not provide the requisite= transparency since anyone who has compromised the CA can put in their own = OCSP pointer.

 

That is the reason I want you to add = the text in the “Security Considerations” section. <= /span>

 

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Beh= alf Of denis.pinkas@bull.net
Sent: Thursday, September 06, 20= 12 10:56 AM
To: stephen.farrell@cs.tcd.ie
Cc: pkix@ietf= .org; wpkops@ietf.org; saag@ietf.org
Subject: Re: [pkix] Fwd: [th= erightkey] Certificate Transparency Working Group?

 

Part of the stated = objective (i.e. verify the issuance of public X.509 certificates)
is cu= rrently addressed, within the context of OCSP, in :

 


This draft is being considered w= ithin the PKIX WG.

 

The second part of the objective (= i.e. making all public issued certificates available to applications)
m= ay be dangerous in many situations.

 

Denis


-----pkix-bounces@ietf.org a= =E9crit : -----

A : "saag@ietf.org"= ; <saag@ietf.org>, "'wpkops= @ietf.org'" <wpkops@ietf.org= >, pkix <pkix@ietf.org>
De= : Stephen Farrell
Envoy=E9 par : pkix-bounces@ietf.org
Date : 06/09/2012 16:42
Objet : [pkix] = Fwd: [therightkey] Certificate Transparency Working Group?

Hi all,

Ple= ase see below. Ben Laurie's looking to see if folks are
interested in a = BoF on Certificate Transparency for the
IETF meeting in Altanta.

= Sean and I would be fine with that, if there's sufficient
interest etc.<= br>
Please follow up on theright= key@ietf.org if this is a
topic that's of interest to you.

Th= anks,
Stephen.


-------- Original Message --------
Subject:= [therightkey] Certificate Transparency Working Group?
Date: Thu, 6 Sep = 2012 15:32:05 +0100
From: Ben Laurie <benl@google.com>
To: = therightkey@ietf.org

Would people be interested in starting a WG= on Certificate
Transparency? If so, how about a BoF in Atlanta?

= Here's a draft charter...


CT IETF WG Draft Charter

Object= ive

Specify mechanisms and techniques that allow Internet applicatio= ns to
monitor and verify the issuance of public X.509 certificates such = that
all public issued certificates are available to applications, and e= ach
certificate seen by an application can be efficiently shown to be in=
the log of issued certificates. Furthermore, it should be possible tocryptographically verify the correct operation of the log.


Opt= ionally, do the same for certificate revocations.

Problem Statement<= br>
Currently it is possible for any CA to issue a certificate for anysite without any oversight. This has led to some high profile
mis-issu= ance of certificates, such as by DigiNotar, a subsidiary of
VASCO Data S= ecurity International, in July 2011
(http://www.vasco.com/company/about_vasco/press_room/news_= archive/2011/news_diginotar_reports_security_incident.aspx).

The aim is to make it possible to detect such mis-issuance promptly
thr= ough the use of a public log of all public issued certificates.
Domain o= wners can then monitor this log and, upon detecting
mis-issuance, take a= ppropriate action.


This public log must also be able to efficien= tly demonstrate its own
correct operation, rather than introducing yet a= nother party that must
be trusted into the equation.


Clients = should also be able to efficiently verify that certificates
they receive= have indeed been entered into the public log.


For revocations, = the aim would be similar: ensure that revocations are
as expected, that = clients can efficiently obtain the revocation status
of a certificate an= d that the log is operating correctly.


Also, in both cases, the = solution must be usable by browsers - this
means that it cannot add any = round trips to page fetches, and that any
data transfers that are mandat= ory are of a reasonable size.
__________________________________________= _____
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey
<= br>


_______________________________________________
pkix mail= ing list
pkix@ietf.org
https://www.ietf.org/mailma= n/listinfo/pkix

= --_000_B83745DA469B7847811819C5005244AF362EC770scygexch7cygnac_-- From rbonica@juniper.net Mon Sep 10 08:28:19 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B152421F8617 for ; Mon, 10 Sep 2012 08:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k81KDdbbJ-t4 for ; Mon, 10 Sep 2012 08:28:18 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id B651D21F85B8 for ; Mon, 10 Sep 2012 08:28:18 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUE4HEO6RzhNERjLN5YlZNolEIeExJIdq@postini.com; Mon, 10 Sep 2012 08:28:18 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 10 Sep 2012 08:26:58 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 10 Sep 2012 08:26:57 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 10 Sep 2012 11:26:21 -0400 From: Ronald Bonica To: "'wpkops@ietf.org'" Date: Mon, 10 Sep 2012 11:26:20 -0400 Thread-Topic: Gentle Reminder Thread-Index: Ac2PaKEkkWmBjFJCRiSdHF60290KHg== Message-ID: <13205C286662DE4387D9AF3AC30EF456D7830D7A66@EMBX01-WF.jnpr.net> 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: [wpkops] Gentle Reminder X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 15:28:20 -0000 Folks, This group appears to be particularly well-positioned for a BoF at IETF 85.= I see a proposed charter and a version-00 trust model document. Both of th= ese have been discussed on the list.=20 So, I will be looking for a BOF request to be submitted before the Septembe= r 24 deadline. -------------------------- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf From tim.moses@entrust.com Sat Sep 15 08:02:34 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C4E21F84D6 for ; Sat, 15 Sep 2012 08:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LL+lAan8Zduc for ; Sat, 15 Sep 2012 08:02:30 -0700 (PDT) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id 10A8121F8472 for ; Sat, 15 Sep 2012 08:02:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,426,1344225600"; d="scan'208";a="6228590" Received: from unknown (HELO sottexchcas1.corp.ad.entrust.com) ([10.4.51.93]) by ipedge1.entrust.com with ESMTP; 15 Sep 2012 11:02:29 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by sottexchcas1.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.001; Sat, 15 Sep 2012 11:02:29 -0400 From: Tim Moses To: "wpkops@ietf.org" Thread-Topic: New Version Notification for draft-moses-webpki-trustmodel-01.txt Thread-Index: AQHNk1MBHs4yMbv2C061uO77NW0nG5eLf4AA Date: Sat, 15 Sep 2012 15:02:28 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A5862B5@SOTTEXCH10.corp.ad.entrust.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.88] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [wpkops] FW: New Version Notification for draft-moses-webpki-trustmodel-01.txt X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 15:02:34 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogU2F0dXJkYXks IFNlcHRlbWJlciAxNSwgMjAxMiAxMTowMiBBTQ0KVG86IFRpbSBNb3Nlcw0KU3ViamVjdDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1tb3Nlcy13ZWJwa2ktdHJ1c3Rtb2RlbC0w MS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbW9zZXMtd2VicGtpLXRydXN0 bW9kZWwtMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRpbSBNb3Nl cyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQt bW9zZXMtd2VicGtpLXRydXN0bW9kZWwNClJldmlzaW9uOgkgMDENClRpdGxlOgkJIFRydXN0IG1v ZGVscyBvZiB0aGUgV2ViIFBLSQ0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMDktMTUNCldHIElEOgkJ IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA4DQpVUkw6ICAgICAgICAg ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1vc2VzLXdlYnBr aS10cnVzdG1vZGVsLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LW1vc2VzLXdlYnBraS10cnVzdG1vZGVsDQpIdG1saXplZDogICAg ICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1vc2VzLXdlYnBraS10cnVzdG1v ZGVsLTAxDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LW1vc2VzLXdlYnBraS10cnVzdG1vZGVsLTAxDQoNCkFic3RyYWN0Og0KICAgVGhpcyBp cyBvbmUgb2YgYSBzZXQgb2YgZHJhZnRzIHRoYXQgZG9jdW1lbnQgdGhlIG9wZXJhdGlvbiBvZiB0 aGUgV2ViDQogICBQS0kuICBJdCBkZXNjcmliZXMgY29tbW9uIHZhcmlhbnRzIG9mIHRoZSBXZWIg UEtJIHRydXN0IG1vZGVsDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVU RiBTZWNyZXRhcmlhdA0KDQo= From dkg@fifthhorseman.net Sat Sep 15 08:50:44 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B695B21F84BF for ; Sat, 15 Sep 2012 08:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUsmZKVh5pNl for ; Sat, 15 Sep 2012 08:50:44 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 43C4321F849B for ; Sat, 15 Sep 2012 08:50:44 -0700 (PDT) Received: from [192.168.13.75] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 5ED67F970; Sat, 15 Sep 2012 11:50:41 -0400 (EDT) Message-ID: <5054A3C6.6010702@fifthhorseman.net> Date: Sat, 15 Sep 2012 11:50:30 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6 MIME-Version: 1.0 To: Tim Moses References: <5B68A271B9C97046963CB6A5B8D6F62C3A5862B5@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A5862B5@SOTTEXCH10.corp.ad.entrust.com> X-Enigmail-Version: 1.5a1pre Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig2C5A2EE026E179FDC5B0D463" Cc: "wpkops@ietf.org" Subject: [wpkops] "additional checks" ? [was: Re: FW: New Version Notification for draft-moses-webpki-trustmodel-01.txt] X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 15:50:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2C5A2EE026E179FDC5B0D463 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09/15/2012 11:02 AM, Tim Moses wrote: > Filename: draft-moses-webpki-trustmodel > Revision: 01 Thanks for the new version, Tim. I think it's an improvement on the old one. However, in the new version, section 3.2 (Certificate using product uses OS root store) still retains the following clause, which is absent in both the "basic trust model" and the "trust model variants": It may then apply additional checks, such as checking that the certificate subject's domain name matches that requested by the certificate user. I'm pretty sure these "additional checks" are critical to most legitimate use cases on the web. If i browse to site X and it presents a valid certificate that's only valid or site Y, the browser should not accept it. So i really don't think you want the term "additional" here ("additional" makes it sound like those checks are unimportant). And i also think this description of what sort of requested name-to-cert validation (and other criteria, like looking for certain X.509v3 extensions?) should span the various defined trust models, rather than being isolated to a single "variant". --dkg --------------enig2C5A2EE026E179FDC5B0D463 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJQVKPGXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznplYgP/2MI/PAi36RN5go/Z/CGSEJ6 fEIS2YdGzV1ubPAGRC1E/rwyCEQfLuljYqP3M1AOBqCIx6tLxI2LD/FJCIWXw0fm WpXgobXxngwzeRP+hFQTWnyYfuUXN67UlsP3Ywfcd5u726Jbla4Or7yb3TQfIN9A NaY0yuPik6bFTsKRyWua1EhDLl+TXJCV4wl79Pdb4qOFUncRPXwoQkTcFvfpidhg SaeTK9wtHn7buxalHQhHFIu4cS6mDAhj5oN97Fy9x+Z7lFZJSbRhrsgB1BxzsBpi atJYt2OZIdQtnhwfJ1mDQ17tafFXINbHAGv39CI3mrvfv9PLMLf8J7pe2wU5OaxF 3VqQTTiD9jVV2zLtHSusTV2yrO9VB269v4jYpbFmq9NkeZdGw/Eks5IThmsLJTDc B9GC16wWuGlofnljw8lKuitJ3ML+yQONpt37oX+upAFBHdrwcwOkrUCJXBTyuSBe gKEFIU/+nz0VVlS9UANKp94m7Hyt9CNoBBR7Juut5NI1V3VxBnYGReX8lMFDRmGk SEH15MXMoXNu/OrCE71vxnl1z6DG0VFHqvnNLcC9doZR35yAyzrn4AG8CwVkO5K6 PDshr7FvvY9HFkz+HOyuJaXceCwhLWZv3tdGEMd8gv/KXUr4EUH7bTYQx3rdVi2C o0FtNzQiIyGDtXl4SQOn =ywrm -----END PGP SIGNATURE----- --------------enig2C5A2EE026E179FDC5B0D463-- From tim.moses@entrust.com Sat Sep 15 09:00:20 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B4521F851B for ; Sat, 15 Sep 2012 09:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[AWL=-0.739, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KJTISjPzsOq for ; Sat, 15 Sep 2012 09:00:13 -0700 (PDT) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id F41AD21F84E2 for ; Sat, 15 Sep 2012 09:00:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,428,1344225600"; d="scan'208,217";a="6228790" Received: from unknown (HELO sottexchcas1.corp.ad.entrust.com) ([10.4.51.93]) by ipedge1.entrust.com with ESMTP; 15 Sep 2012 12:00:12 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by sottexchcas1.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.001; Sat, 15 Sep 2012 12:00:12 -0400 From: Tim Moses To: "wpkops@ietf.org" Thread-Topic: Third draft charter proposal Thread-Index: Ac2TWy5Wt+5+AKCyQmSih2MU3O89AQ== Date: Sat, 15 Sep 2012 16:00:11 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A5862E7@SOTTEXCH10.corp.ad.entrust.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.88] Content-Type: multipart/alternative; boundary="_000_5B68A271B9C97046963CB6A5B8D6F62C3A5862E7SOTTEXCH10corpa_" MIME-Version: 1.0 Subject: [wpkops] Third draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 16:00:20 -0000 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A5862E7SOTTEXCH10corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Colleagues - Here is a third draft of the WPKOPS charter proposal. It atte= mpts to accommodate comments received on the second draft. The other major change is that I have deleted the proposal for a draft on c= ommunications between the certificate-holder and the certificate issuer. T= his was included originally to ensure that we didn't lose sight of the role= of the Web server in the "stapling" process. But, I think this can be dea= lt with in the "certificate revocation" document. Equally to the point, I have received commitments from individuals to act a= s the primary editors for the remaining documents. Rick Andrews from Syman= tec with Scott Rea and Ben Wilson from DigiCert have offered to tackle cert= ificate revocation, Ben Wilson and colleagues from DigiCert have offered to= tackle the behavior of the certificate using product, and Adam Langley of = Google has volunteered to edit the draft on TLS stack operation. I am looking for others to volunteer to assist in an editing role. Please = let me know as soon as you possibly can and I'll put you in touch with the = editors that have already been identified. Thanks a lot. All the best. Tim. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The Web PKI is the set of systems and procedures most commonly used to prot= ect the confidentiality, integrity and authenticity of communications betwe= en Web browsers and Web content servers. It first appeared in 1993 or ther= eabouts and has developed continuously in a somewhat organic fashion since = then. Across all the suppliers and the point releases of their products, t= here are now hundreds of variations on the Web PKI in regular use. And thi= s can be a source of problems for end-users, certificate holders, and certi= ficate issuers. For end-users, there is no clear view whether certificate "problems" remain= when they see indication of a "good" connection. For instance, in some br= owsers, a "good" indication may be displayed when a "revoked" response has = been received and "accepted" by the user, whereas other browsers may refuse= to display the contents under these circumstances. Certificate holders may have difficulty understanding whether some browser = versions will reject their certificate if certain content specifications ar= e not met, such as a subject public key that does not satisfy a minimum key= size, or a certificate policies extension that does not contain a particul= ar standard policy identifier. And for issuers, it can be difficult to predict what proportion of the user= population will accept a certificate chain with certain characteristics. = For instance, when a browser includes a nonce in an OCSP request but the se= rver supplies a response that does not include the nonce, it is hard to kno= w which browsers will accept and which will reject the response. Starting from the premise that more consistency in Web security behavior is= desirable, a natural first step would be to document current and historic = browser and server behavior. But, such a project has to be bounded. There= fore, only server-authentication behavior encountered in more than 0.1 perc= ent of connections made by desktop and mobile browsers should be considered= . While it is not intended to apply the threshold with any precision, it m= ay be used to justify the inclusion or exclusion of a technique. Future activities may attempt to prescribe how the Web PKI "should" work, a= nd the prescription may turn out to be a proper subset of the PKIX PKI. Ho= wever, that task is explicitly not a goal of the proposed working group. I= nstead, the group's goal is merely to describe how the Web PKI "actually" w= orks in the set of browsers and servers that are in common use today. Additionally, a number of applications (such as client authentication, docu= ment signing, code signing, and email) may use the same trust anchors and c= ertificate-handling libraries as the ones used for server authentication on= the Web. Nevertheless, they may use the results in a way that is visibly = different from the way in which they are used for server authentication. W= hile these applications are considered outside the scope of this working gr= oup, deliverables should (wherever practical within the available expertise= and time) identify other applications that exhibit identical behavior and = identify the implications of that behavior where they differ from those for= server authentication. Also, the reliability of the Web PKI depends critically on the practices of= its certificate issuers; practices such as: how the contents of certificat= e applications are verified and how access (both direct and indirect) to th= e CA's private key is controlled. However, the topic of practices is consi= dered outside the scope of the working group. This topic will be left to o= ther competent bodies, such as the CA/Browser Forum [1][2]. That there are technical shortcomings with Web PKI, as it is practiced toda= y, is well recognized. And, that there is also some urgency in addressing = these shortcomings is also well recognized. But, it is felt that too much = haste can be counter-productive. The expectation is that the work of this = group will bring to light, in a systematic way, aspects of the Web PKI that= should be progressed in future working groups of the IETF's Security Area,= and that suppliers will be willing to participate in those working groups = and modify their products to comply with their standards. Given the urgency of the required developments and the scale of the task, i= t is agreed that adherence to the published schedule should take precedence= over completeness of the results. Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. First WG draft of "trust model" document (4 months). 2. First WG draft of "certificate, CRL, and OCSP field and extension pro= cessing" document (12 months). 3. First WG draft of "certificate revocation" document (8 months). 4. First WG draft of "TLS stack operation" document (8 months). 5. IESG submission of "trust model" document (16 months). 6. IESG submission of "certificate, CRL, and OCSP field and extension pr= ocessing" document (24 months). 7. IESG submission of "certificate revocation" document (20 months). 8. IESG submission of "TLS stack operation" document (16 months). References: [1] Network and certificate system security requirements, CA/Browser Foru= m, Aug 2012, https://www.cabforum.org/Network_Security_Controls_V1.pdf [2] Baseline Requirements for the Issuance and Management of Publicly-Tru= sted Certificates Version 1.0, CA/Browser Forum, Nov 2011, https://www.cabf= orum.org/Baseline_Requirements_V1.pdf T: +1 613 270 3183 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A5862E7SOTTEXCH10corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Colleagues – Here is a third draft of the WPKO= PS charter proposal.  It attempts to accommodate comments received on = the second draft.

 

The other major change is that I have deleted the pr= oposal for a draft on communications between the certificate-holder and the= certificate issuer.  This was included originally to ensure that we d= idn’t lose sight of the role of the Web server in the “stapling” process.  But, I think this can = be dealt with in the “certificate revocation” document.

 

Equally to the point, I have received commitments fr= om individuals to act as the primary editors for the remaining documents.&n= bsp; Rick Andrews from Symantec with Scott Rea and Ben Wilson from DigiCert= have offered to tackle certificate revocation, Ben Wilson and colleagues from DigiCert have offered to tackle the behavio= r of the certificate using product, and Adam Langley of Google has voluntee= red to edit the draft on TLS stack operation.

 

I am looking for others to volunteer to assist in an= editing role.  Please let me know as soon as you possibly can and I&#= 8217;ll put you in touch with the editors that have already been identified= .

 

Thanks a lot.  All the best.  Tim.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

The Web PKI is the set of sy= stems and procedures most commonly used to protect the confidentiality, int= egrity and authenticity of communications between Web browsers and Web content servers.  It first appeared in 1993 or t= hereabouts and has developed continuously in a somewhat organic fashion sin= ce then.  Across all the suppliers and the point releases of their pro= ducts, there are now hundreds of variations on the Web PKI in regular use.  And this can be a source of problems = for end-users, certificate holders, and certificate issuers.

 

For end-users, there is no c= lear view whether certificate "problems" remain when they see ind= ication of a "good" connection.  For instance, in some brows= ers, a "good" indication may be displayed when a "revoked" = response has been received and "accepted" by the user, whereas ot= her browsers may refuse to display the contents under these circumstances.<= o:p>

 

Certificate holders may have= difficulty understanding whether some browser versions will reject their c= ertificate if certain content specifications are not met, such as a subject public key that does not satisfy a minimum key = size, or a certificate policies extension that does not contain a particula= r standard policy identifier.

 

And for issuers, it can be d= ifficult to predict what proportion of the user population will accept a ce= rtificate chain with certain characteristics.  For instance, when a browser includes a nonce in an OCSP request but the serve= r supplies a response that does not include the nonce, it is hard to know w= hich browsers will accept and which will reject the response.

 

Starting from the premise th= at more consistency in Web security behavior is desirable, a natural first = step would be to document current and historic browser and server behavior.  But, such a project has to be bounded.  Th= erefore, only server-authentication behavior encountered in more than 0.1 p= ercent of connections made by desktop and mobile browsers should be conside= red.  While it is not intended to apply the threshold with any precision, it may be used to justify the inclusion or e= xclusion of a technique.

 

Future activities may attemp= t to prescribe how the Web PKI "should" work, and the prescriptio= n may turn out to be a proper subset of the PKIX PKI.  However, that task is explicitly not a goal of the proposed working group.  In= stead, the group's goal is merely to describe how the Web PKI "actuall= y" works in the set of browsers and servers that are in common use tod= ay.

 

Additionally, a number of ap= plications (such as client authentication, document signing, code signing, = and email) may use the same trust anchors and certificate-handling libraries as the ones used for server authentication on the Web.  Nev= ertheless, they may use the results in a way that is visibly different from= the way in which they are used for server authentication.  While thes= e applications are considered outside the scope of this working group, deliverables should (wherever practical withi= n the available expertise and time) identify other applications that exhibi= t identical behavior and identify the implications of that behavior where t= hey differ from those for server authentication.

 

Also, the reliability of the= Web PKI depends critically on the practices of its certificate issuers; pr= actices such as: how the contents of certificate applications are verified and how access (both direct and indirect) to the= CA's private key is controlled.  However, the topic of practices is c= onsidered outside the scope of the working group.  This topic will be = left to other competent bodies, such as the CA/Browser Forum [1][2].

 

That there are technical sho= rtcomings with Web PKI, as it is practiced today, is well recognized. = And, that there is also some urgency in addressing these shortcomings is also well recognized.  But, it is felt that too much = haste can be counter-productive.  The expectation is that the work of = this group will bring to light, in a systematic way, aspects of the Web PKI= that should be progressed in future working groups of the IETF's Security Area, and that suppliers will be willing to = participate in those working groups and modify their products to comply wit= h their standards.

 

Given the urgency of the req= uired developments and the scale of the task, it is agreed that adherence t= o the published schedule should take precedence over completeness of the results.

 

Milestones=

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

1.    First W= G draft of "trust model" document (4 months).

2.    First W= G draft of "certificate, CRL, and OCSP field and extension processing&= quot; document (12 months).

3.    First W= G draft of "certificate revocation" document (8 months).

4.    First W= G draft of "TLS stack operation" document (8 months).<= /span>

5.    IESG su= bmission of "trust model" document (16 months).=

6.    IESG su= bmission of "certificate, CRL, and OCSP field and extension processing= " document (24 months).

7.    IESG su= bmission of "certificate revocation" document (20 months).

8.    IESG su= bmission of "TLS stack operation" document (16 months).

 

 

References:

 

[1]   Network and = certificate system security requirements, CA/Browser Forum, Aug 2012, https= ://www.cabforum.org/Network_Security_Controls_V1.pdf

 

[2]   Baseline Req= uirements for the Issuance and Management of Publicly-Trusted Certificates = Version 1.0, CA/Browser Forum, Nov 2011, https://www.cabforum.org/Baseline_= Requirements_V1.pdf

 

 

 

 

T: +1 613 270 3183

 

--_000_5B68A271B9C97046963CB6A5B8D6F62C3A5862E7SOTTEXCH10corpa_-- From stephen.farrell@cs.tcd.ie Sat Sep 15 10:35:40 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23E221F84D9 for ; Sat, 15 Sep 2012 10:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.739 X-Spam-Level: X-Spam-Status: No, score=-105.739 tagged_above=-999 required=5 tests=[AWL=-3.140, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95HY+lBNXcTb for ; Sat, 15 Sep 2012 10:35:38 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 501B721F84C8 for ; Sat, 15 Sep 2012 10:35:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 4B45D171476; Sat, 15 Sep 2012 18:35:35 +0100 (IST) 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=1347730531; bh=ADrlPKnXu5Sue+ 48MUxztkImzbceSKwRzei9f18SqyQ=; b=gXBzTiv3H4U0aXwfh6pUFYv+YDvrMQ bl/1alq4Ao/qqzusBsLgshNxGfhZNEEQkuEkwvaeadGCtASuwyPw5SvBewDxoRuA 0XJU4V4xU+LYmlOjVi7MhktCQ4JIKGlLrPH1E53Ro0w/8f3WfKFXhVlcVghN1oKb fiqY0d9r7Y4BGErYNHRr5dhhl53IalNUvyPjAxZ+gzjZRT4zrU/Z4q+CHX4HSZSC y3WswgpXykE2rE26JlAlaE95MInW0oigFOQEyW1aHGJXito02ape7wWBPTkbmIIN ISHzE+dADdZd9J1GV+AobGbSywKM4ePDSSD2YqxGYXU8gvwKi5XvIwmw== 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 kUWGpgblJq5x; Sat, 15 Sep 2012 18:35:31 +0100 (IST) Received: from [10.87.48.9] (unknown [86.46.30.165]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id AA979171474; Sat, 15 Sep 2012 18:35:28 +0100 (IST) Message-ID: <5054BC5F.5080107@cs.tcd.ie> Date: Sat, 15 Sep 2012 18:35:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Tim Moses References: <5B68A271B9C97046963CB6A5B8D6F62C3A5862E7@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A5862E7@SOTTEXCH10.corp.ad.entrust.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "wpkops@ietf.org" Subject: Re: [wpkops] Third draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 17:35:40 -0000 Hi Tim, That looks pretty good to me. Some comments below. On 09/15/2012 05:00 PM, Tim Moses wrote: > Colleagues - Here is a third draft of the WPKOPS charter proposal. It attempts to accommodate comments received on the second draft. > > The other major change is that I have deleted the proposal for a draft on communications between the certificate-holder and the certificate issuer. This was included originally to ensure that we didn't lose sight of the role of the Web server in the "stapling" process. But, I think this can be dealt with in the "certificate revocation" document. > > Equally to the point, I have received commitments from individuals to act as the primary editors for the remaining documents. Rick Andrews from Symantec with Scott Rea and Ben Wilson from DigiCert have offered to tackle certificate revocation, Ben Wilson and colleagues from DigiCert have offered to tackle the behavior of the certificate using product, and Adam Langley of Google has volunteered to edit the draft on TLS stack operation. > > I am looking for others to volunteer to assist in an editing role. Please let me know as soon as you possibly can and I'll put you in touch with the editors that have already been identified. > > Thanks a lot. All the best. Tim. > > ==================================================================== > > The Web PKI is the set of systems and procedures most commonly used to protect the confidentiality, integrity and authenticity of communications between Web browsers and Web content servers. It first appeared in 1993 or thereabouts and has developed continuously in a somewhat organic fashion since then. Across all the suppliers and the point releases of their products, there are now hundreds of variations on the Web PKI in regular use. And this can be a source of problems for end-users, certificate holders, and certificate issuers. > > For end-users, there is no clear view whether certificate "problems" remain when they see indication of a "good" connection. For instance, in some browsers, a "good" indication may be displayed when a "revoked" response has been received and "accepted" by the user, whereas other browsers may refuse to display the contents under these circumstances. > > Certificate holders may have difficulty understanding whether some browser versions will reject their certificate if certain content specifications are not met, such as a subject public key that does not satisfy a minimum key size, or a certificate policies extension that does not contain a particular standard policy identifier. > > And for issuers, it can be difficult to predict what proportion of the user population will accept a certificate chain with certain characteristics. For instance, when a browser includes a nonce in an OCSP request but the server supplies a response that does not include the nonce, it is hard to know which browsers will accept and which will reject the response. > > Starting from the premise that more consistency in Web security behavior is desirable, a natural first step would be to document current and historic browser and server behavior. But, such a project has to be bounded. Therefore, only server-authentication behavior encountered in more than 0.1 percent of connections made by desktop and mobile browsers should be considered. While it is not intended to apply the threshold with any precision, it may be used to justify the inclusion or exclusion of a technique. > > Future activities may attempt to prescribe how the Web PKI "should" work, and the prescription may turn out to be a proper subset of the PKIX PKI. However, that task is explicitly not a goal of the proposed working group. Instead, the group's goal is merely to describe how the Web PKI "actually" works in the set of browsers and servers that are in common use today. > > Additionally, a number of applications (such as client authentication, document signing, code signing, and email) may use the same trust anchors and certificate-handling libraries as the ones used for server authentication on the Web. Nevertheless, they may use the results in a way that is visibly different from the way in which they are used for server authentication. While these applications are considered outside the scope of this working group, deliverables should (wherever practical within the available expertise and time) identify other applications that exhibit identical behavior and identify the implications of that behavior where they differ from those for server authentication. > > Also, the reliability of the Web PKI depends critically on the practices of its certificate issuers; practices such as: how the contents of certificate applications are verified and how access (both direct and indirect) to the CA's private key is controlled. However, the topic of practices is considered outside the scope of the working group. I think that last sentence is problematically ambiguous. I suspect that the term "practice" has evolved into something well defined for CAB forum members but I don't think its well understood in the IETF. If you don't make this more precise, in terms understood in the IETF context, I suspect the WG might have recurring friction about what is or is not in scope. Some examples of what's in/out of scope might help the discussion here I reckon. > This topic will be left to other competent bodies, such as the CA/Browser Forum [1][2]. I think that sentence wouldn't be needed if the previous one were well enough defined. I also think that since CAB forum's constitution is in flux it'd be better to just not mention it in the charter. > > That there are technical shortcomings with Web PKI, as it is practiced today, is well recognized. And, that there is also some urgency in addressing these shortcomings is also well recognized. But, it is felt that too much haste can be counter-productive. The expectation is that the work of this group will bring to light, in a systematic way, aspects of the Web PKI that should be progressed in future working groups of the IETF's Security Area, and that suppliers will be willing to participate in those working groups and modify their products to comply with their standards. > > Given the urgency of the required developments and the scale of the task, it is agreed that adherence to the published schedule should take precedence over completeness of the results. I sympathise with that, but it needs to be understood (e.g. by folks new to the IETF) that the usual IETF processes do apply and the WG doesn't get to override those. That means that technically correct and relevant comments can be a showstopper at any point for example. I don't know if that needs different text, but it needs to be understood. > Milestones > ========== I think these deliverables need to be better characterised in the text above, e.g. its not clear that the "trust model" document is meant only to document the existing trust model(s) that are in use in non-trivial deployments. I'm also not sure if this is the right structure for the set of documents you want to produce, e.g. whether or not its better to separate trust models from the processing of e.g. issuer, subject and SPKI fields, nor whether it makes sense to discuss OCSP in one document but revocation in another. So I think a bit more discussion on that is needed. Cheers, S. > > 1. First WG draft of "trust model" document (4 months). > 2. First WG draft of "certificate, CRL, and OCSP field and extension processing" document (12 months). > 3. First WG draft of "certificate revocation" document (8 months). > 4. First WG draft of "TLS stack operation" document (8 months). > 5. IESG submission of "trust model" document (16 months). > 6. IESG submission of "certificate, CRL, and OCSP field and extension processing" document (24 months). > 7. IESG submission of "certificate revocation" document (20 months). > 8. IESG submission of "TLS stack operation" document (16 months). > > > References: > > [1] Network and certificate system security requirements, CA/Browser Forum, Aug 2012, https://www.cabforum.org/Network_Security_Controls_V1.pdf > > [2] Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates Version 1.0, CA/Browser Forum, Nov 2011, https://www.cabforum.org/Baseline_Requirements_V1.pdf > > > > > T: +1 613 270 3183 > > > > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > From rbonica@juniper.net Mon Sep 17 08:50:56 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519F221F8702 for ; Mon, 17 Sep 2012 08:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.459 X-Spam-Level: X-Spam-Status: No, score=-106.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujoY01Ramj7R for ; Mon, 17 Sep 2012 08:50:55 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB8A21F8701 for ; Mon, 17 Sep 2012 08:50:51 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUFdG23aFo7byaYDKqh7FJiK/Hc07ty0A@postini.com; Mon, 17 Sep 2012 08:50:54 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 17 Sep 2012 08:48:41 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 17 Sep 2012 11:48:40 -0400 From: Ronald Bonica To: Stephen Farrell , Tim Moses Date: Mon, 17 Sep 2012 11:48:38 -0400 Thread-Topic: [wpkops] Third draft charter proposal Thread-Index: Ac2TaImEVJxlLHSuTE2dFruvRJrblABgwkhg Message-ID: <13205C286662DE4387D9AF3AC30EF456D7834D9FB4@EMBX01-WF.jnpr.net> References: <5B68A271B9C97046963CB6A5B8D6F62C3A5862E7@SOTTEXCH10.corp.ad.entrust.com> <5054BC5F.5080107@cs.tcd.ie> In-Reply-To: <5054BC5F.5080107@cs.tcd.ie> 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: "wpkops@ietf.org" Subject: Re: [wpkops] Third draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 15:50:56 -0000 Folks, On September 26, the IAB and IESG will review BoF proposals. Would it be OK= if I included this version of the charter proposal in the BoF proposal? Ron > -----Original Message----- > From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On > Behalf Of Stephen Farrell > Sent: Saturday, September 15, 2012 1:35 PM > To: Tim Moses > Cc: wpkops@ietf.org > Subject: Re: [wpkops] Third draft charter proposal >=20 >=20 > Hi Tim, >=20 > That looks pretty good to me. Some comments below. >=20 > On 09/15/2012 05:00 PM, Tim Moses wrote: > > Colleagues - Here is a third draft of the WPKOPS charter proposal. > It attempts to accommodate comments received on the second draft. > > > > The other major change is that I have deleted the proposal for a > draft on communications between the certificate-holder and the > certificate issuer. This was included originally to ensure that we > didn't lose sight of the role of the Web server in the "stapling" > process. But, I think this can be dealt with in the "certificate > revocation" document. > > > > Equally to the point, I have received commitments from individuals to > act as the primary editors for the remaining documents. Rick Andrews > from Symantec with Scott Rea and Ben Wilson from DigiCert have offered > to tackle certificate revocation, Ben Wilson and colleagues from > DigiCert have offered to tackle the behavior of the certificate using > product, and Adam Langley of Google has volunteered to edit the draft > on TLS stack operation. > > > > I am looking for others to volunteer to assist in an editing role. > Please let me know as soon as you possibly can and I'll put you in > touch with the editors that have already been identified. > > > > Thanks a lot. All the best. Tim. > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > The Web PKI is the set of systems and procedures most commonly used > to protect the confidentiality, integrity and authenticity of > communications between Web browsers and Web content servers. It first > appeared in 1993 or thereabouts and has developed continuously in a > somewhat organic fashion since then. Across all the suppliers and the > point releases of their products, there are now hundreds of variations > on the Web PKI in regular use. And this can be a source of problems > for end-users, certificate holders, and certificate issuers. > > > > For end-users, there is no clear view whether certificate "problems" > remain when they see indication of a "good" connection. For instance, > in some browsers, a "good" indication may be displayed when a "revoked" > response has been received and "accepted" by the user, whereas other > browsers may refuse to display the contents under these circumstances. > > > > Certificate holders may have difficulty understanding whether some > browser versions will reject their certificate if certain content > specifications are not met, such as a subject public key that does not > satisfy a minimum key size, or a certificate policies extension that > does not contain a particular standard policy identifier. > > > > And for issuers, it can be difficult to predict what proportion of > the user population will accept a certificate chain with certain > characteristics. For instance, when a browser includes a nonce in an > OCSP request but the server supplies a response that does not include > the nonce, it is hard to know which browsers will accept and which will > reject the response. > > > > Starting from the premise that more consistency in Web security > behavior is desirable, a natural first step would be to document > current and historic browser and server behavior. But, such a project > has to be bounded. Therefore, only server-authentication behavior > encountered in more than 0.1 percent of connections made by desktop and > mobile browsers should be considered. While it is not intended to > apply the threshold with any precision, it may be used to justify the > inclusion or exclusion of a technique. > > > > Future activities may attempt to prescribe how the Web PKI "should" > work, and the prescription may turn out to be a proper subset of the > PKIX PKI. However, that task is explicitly not a goal of the proposed > working group. Instead, the group's goal is merely to describe how the > Web PKI "actually" works in the set of browsers and servers that are in > common use today. > > > > Additionally, a number of applications (such as client > authentication, document signing, code signing, and email) may use the > same trust anchors and certificate-handling libraries as the ones used > for server authentication on the Web. Nevertheless, they may use the > results in a way that is visibly different from the way in which they > are used for server authentication. While these applications are > considered outside the scope of this working group, deliverables should > (wherever practical within the available expertise and time) identify > other applications that exhibit identical behavior and identify the > implications of that behavior where they differ from those for server > authentication. > > > > Also, the reliability of the Web PKI depends critically on the > practices of its certificate issuers; practices such as: how the > contents of certificate applications are verified and how access (both > direct and indirect) to the CA's private key is controlled. However, > the topic of practices is considered outside the scope of the working > group. >=20 > I think that last sentence is problematically ambiguous. I suspect that > the term "practice" has evolved into something well defined for CAB > forum members but I don't think its well understood in the IETF. If you > don't make this more precise, in terms understood in the IETF context, > I suspect the WG might have recurring friction about what is or is not > in scope. >=20 > Some examples of what's in/out of scope might help the discussion here > I reckon. >=20 > > This topic will be left to other competent bodies, such as the > CA/Browser Forum [1][2]. >=20 > I think that sentence wouldn't be needed if the previous one were well > enough defined. I also think that since CAB forum's constitution is in > flux it'd be better to just not mention it in the charter. >=20 > > > > That there are technical shortcomings with Web PKI, as it is > practiced today, is well recognized. And, that there is also some > urgency in addressing these shortcomings is also well recognized. But, > it is felt that too much haste can be counter-productive. The > expectation is that the work of this group will bring to light, in a > systematic way, aspects of the Web PKI that should be progressed in > future working groups of the IETF's Security Area, and that suppliers > will be willing to participate in those working groups and modify their > products to comply with their standards. > > > > Given the urgency of the required developments and the scale of the > task, it is agreed that adherence to the published schedule should take > precedence over completeness of the results. >=20 > I sympathise with that, but it needs to be understood (e.g. by folks > new to the IETF) that the usual IETF processes do apply and the WG > doesn't get to override those. That means that technically correct and > relevant comments can be a showstopper at any point for example. I > don't know if that needs different text, but it needs to be understood. >=20 > > Milestones > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > I think these deliverables need to be better characterised in the text > above, e.g. its not clear that the "trust model" document is meant only > to document the existing trust model(s) that are in use in non-trivial > deployments. >=20 > I'm also not sure if this is the right structure for the set of > documents you want to produce, e.g. whether or not its better to > separate trust models from the processing of e.g. issuer, subject and > SPKI fields, nor whether it makes sense to discuss OCSP in one document > but revocation in another. >=20 > So I think a bit more discussion on that is needed. >=20 > Cheers, > S. >=20 > > > > 1. First WG draft of "trust model" document (4 months). > > 2. First WG draft of "certificate, CRL, and OCSP field and > extension processing" document (12 months). > > 3. First WG draft of "certificate revocation" document (8 months). > > 4. First WG draft of "TLS stack operation" document (8 months). > > 5. IESG submission of "trust model" document (16 months). > > 6. IESG submission of "certificate, CRL, and OCSP field and > extension processing" document (24 months). > > 7. IESG submission of "certificate revocation" document (20 > months). > > 8. IESG submission of "TLS stack operation" document (16 months). > > > > > > References: > > > > [1] Network and certificate system security requirements, > CA/Browser Forum, Aug 2012, > https://www.cabforum.org/Network_Security_Controls_V1.pdf > > > > [2] Baseline Requirements for the Issuance and Management of > Publicly-Trusted Certificates Version 1.0, CA/Browser Forum, Nov 2011, > https://www.cabforum.org/Baseline_Requirements_V1.pdf > > > > > > > > > > T: +1 613 270 3183 > > > > > > > > > > _______________________________________________ > > wpkops mailing list > > wpkops@ietf.org > > https://www.ietf.org/mailman/listinfo/wpkops > > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops From stephen.farrell@cs.tcd.ie Mon Sep 17 10:11:04 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC67621F8723 for ; Mon, 17 Sep 2012 10:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdvTVE8RGq19 for ; Mon, 17 Sep 2012 10:11:02 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7684621F86E4 for ; Mon, 17 Sep 2012 10:11:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id CF425171487; Mon, 17 Sep 2012 18:10:56 +0100 (IST) 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=1347901853; bh=k+D1hUQIOBFJho THSUKFdxxdKkyH2kc2u//+cixMylQ=; b=hC2l0Xda9z1otibf0QjSbCl+D54fXN wYPEYxu/72m49KzQKaCAI8it+9BwydVEOzsebH4oS4PMBJ3e5mqzXWggtlXRaMfx vtlqSGB+IwHoNMVYfUZIv6BtMJLGViZ8PUf6vnPzhruIDO3le/h9ZE/tC5LUSp2U lyw4Gg9e9oUpeUQ5DezLcXacu2Xl1SxFzCAjo6fHJdC9vxAHXfFM8YNyfUAe71Bl dbOPkOyEiJO6iukFNgf+Q4T2tFUUOh1XmiAypDbXdd+NtBPipx4uC1eT2IrG3vmt ffiMMP2Tn6WXwjKCxchRxv20M6piRBF+qIO6+DnfyveOfFiupjNhKrhw== 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 8zmlwrV61OYA; Mon, 17 Sep 2012 18:10:53 +0100 (IST) Received: from [192.6.10.181] (bri-event-82.hpl.hp.com [192.6.10.181]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 7F555171473; Mon, 17 Sep 2012 18:10:50 +0100 (IST) Message-ID: <50575999.5090003@cs.tcd.ie> Date: Mon, 17 Sep 2012 18:10:49 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ronald Bonica References: <5B68A271B9C97046963CB6A5B8D6F62C3A5862E7@SOTTEXCH10.corp.ad.entrust.com> <5054BC5F.5080107@cs.tcd.ie> <13205C286662DE4387D9AF3AC30EF456D7834D9FB4@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D7834D9FB4@EMBX01-WF.jnpr.net> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "wpkops@ietf.org" , Tim Moses Subject: Re: [wpkops] Third draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 17:11:04 -0000 While I have comments on this version, I personally think its almost-baked so should be fine for the BoF approval call. S On 09/17/2012 04:48 PM, Ronald Bonica wrote: > Folks, > > On September 26, the IAB and IESG will review BoF proposals. Would it be OK if I included this version of the charter proposal in the BoF proposal? > > Ron > > >> -----Original Message----- >> From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On >> Behalf Of Stephen Farrell >> Sent: Saturday, September 15, 2012 1:35 PM >> To: Tim Moses >> Cc: wpkops@ietf.org >> Subject: Re: [wpkops] Third draft charter proposal >> >> >> Hi Tim, >> >> That looks pretty good to me. Some comments below. >> >> On 09/15/2012 05:00 PM, Tim Moses wrote: >>> Colleagues - Here is a third draft of the WPKOPS charter proposal. >> It attempts to accommodate comments received on the second draft. >>> >>> The other major change is that I have deleted the proposal for a >> draft on communications between the certificate-holder and the >> certificate issuer. This was included originally to ensure that we >> didn't lose sight of the role of the Web server in the "stapling" >> process. But, I think this can be dealt with in the "certificate >> revocation" document. >>> >>> Equally to the point, I have received commitments from individuals to >> act as the primary editors for the remaining documents. Rick Andrews >> from Symantec with Scott Rea and Ben Wilson from DigiCert have offered >> to tackle certificate revocation, Ben Wilson and colleagues from >> DigiCert have offered to tackle the behavior of the certificate using >> product, and Adam Langley of Google has volunteered to edit the draft >> on TLS stack operation. >>> >>> I am looking for others to volunteer to assist in an editing role. >> Please let me know as soon as you possibly can and I'll put you in >> touch with the editors that have already been identified. >>> >>> Thanks a lot. All the best. Tim. >>> >>> ==================================================================== >>> >>> The Web PKI is the set of systems and procedures most commonly used >> to protect the confidentiality, integrity and authenticity of >> communications between Web browsers and Web content servers. It first >> appeared in 1993 or thereabouts and has developed continuously in a >> somewhat organic fashion since then. Across all the suppliers and the >> point releases of their products, there are now hundreds of variations >> on the Web PKI in regular use. And this can be a source of problems >> for end-users, certificate holders, and certificate issuers. >>> >>> For end-users, there is no clear view whether certificate "problems" >> remain when they see indication of a "good" connection. For instance, >> in some browsers, a "good" indication may be displayed when a "revoked" >> response has been received and "accepted" by the user, whereas other >> browsers may refuse to display the contents under these circumstances. >>> >>> Certificate holders may have difficulty understanding whether some >> browser versions will reject their certificate if certain content >> specifications are not met, such as a subject public key that does not >> satisfy a minimum key size, or a certificate policies extension that >> does not contain a particular standard policy identifier. >>> >>> And for issuers, it can be difficult to predict what proportion of >> the user population will accept a certificate chain with certain >> characteristics. For instance, when a browser includes a nonce in an >> OCSP request but the server supplies a response that does not include >> the nonce, it is hard to know which browsers will accept and which will >> reject the response. >>> >>> Starting from the premise that more consistency in Web security >> behavior is desirable, a natural first step would be to document >> current and historic browser and server behavior. But, such a project >> has to be bounded. Therefore, only server-authentication behavior >> encountered in more than 0.1 percent of connections made by desktop and >> mobile browsers should be considered. While it is not intended to >> apply the threshold with any precision, it may be used to justify the >> inclusion or exclusion of a technique. >>> >>> Future activities may attempt to prescribe how the Web PKI "should" >> work, and the prescription may turn out to be a proper subset of the >> PKIX PKI. However, that task is explicitly not a goal of the proposed >> working group. Instead, the group's goal is merely to describe how the >> Web PKI "actually" works in the set of browsers and servers that are in >> common use today. >>> >>> Additionally, a number of applications (such as client >> authentication, document signing, code signing, and email) may use the >> same trust anchors and certificate-handling libraries as the ones used >> for server authentication on the Web. Nevertheless, they may use the >> results in a way that is visibly different from the way in which they >> are used for server authentication. While these applications are >> considered outside the scope of this working group, deliverables should >> (wherever practical within the available expertise and time) identify >> other applications that exhibit identical behavior and identify the >> implications of that behavior where they differ from those for server >> authentication. >>> >>> Also, the reliability of the Web PKI depends critically on the >> practices of its certificate issuers; practices such as: how the >> contents of certificate applications are verified and how access (both >> direct and indirect) to the CA's private key is controlled. However, >> the topic of practices is considered outside the scope of the working >> group. >> >> I think that last sentence is problematically ambiguous. I suspect that >> the term "practice" has evolved into something well defined for CAB >> forum members but I don't think its well understood in the IETF. If you >> don't make this more precise, in terms understood in the IETF context, >> I suspect the WG might have recurring friction about what is or is not >> in scope. >> >> Some examples of what's in/out of scope might help the discussion here >> I reckon. >> >>> This topic will be left to other competent bodies, such as the >> CA/Browser Forum [1][2]. >> >> I think that sentence wouldn't be needed if the previous one were well >> enough defined. I also think that since CAB forum's constitution is in >> flux it'd be better to just not mention it in the charter. >> >>> >>> That there are technical shortcomings with Web PKI, as it is >> practiced today, is well recognized. And, that there is also some >> urgency in addressing these shortcomings is also well recognized. But, >> it is felt that too much haste can be counter-productive. The >> expectation is that the work of this group will bring to light, in a >> systematic way, aspects of the Web PKI that should be progressed in >> future working groups of the IETF's Security Area, and that suppliers >> will be willing to participate in those working groups and modify their >> products to comply with their standards. >>> >>> Given the urgency of the required developments and the scale of the >> task, it is agreed that adherence to the published schedule should take >> precedence over completeness of the results. >> >> I sympathise with that, but it needs to be understood (e.g. by folks >> new to the IETF) that the usual IETF processes do apply and the WG >> doesn't get to override those. That means that technically correct and >> relevant comments can be a showstopper at any point for example. I >> don't know if that needs different text, but it needs to be understood. >> >>> Milestones >>> ========== >> >> I think these deliverables need to be better characterised in the text >> above, e.g. its not clear that the "trust model" document is meant only >> to document the existing trust model(s) that are in use in non-trivial >> deployments. >> >> I'm also not sure if this is the right structure for the set of >> documents you want to produce, e.g. whether or not its better to >> separate trust models from the processing of e.g. issuer, subject and >> SPKI fields, nor whether it makes sense to discuss OCSP in one document >> but revocation in another. >> >> So I think a bit more discussion on that is needed. >> >> Cheers, >> S. >> >>> >>> 1. First WG draft of "trust model" document (4 months). >>> 2. First WG draft of "certificate, CRL, and OCSP field and >> extension processing" document (12 months). >>> 3. First WG draft of "certificate revocation" document (8 months). >>> 4. First WG draft of "TLS stack operation" document (8 months). >>> 5. IESG submission of "trust model" document (16 months). >>> 6. IESG submission of "certificate, CRL, and OCSP field and >> extension processing" document (24 months). >>> 7. IESG submission of "certificate revocation" document (20 >> months). >>> 8. IESG submission of "TLS stack operation" document (16 months). >>> >>> >>> References: >>> >>> [1] Network and certificate system security requirements, >> CA/Browser Forum, Aug 2012, >> https://www.cabforum.org/Network_Security_Controls_V1.pdf >>> >>> [2] Baseline Requirements for the Issuance and Management of >> Publicly-Trusted Certificates Version 1.0, CA/Browser Forum, Nov 2011, >> https://www.cabforum.org/Baseline_Requirements_V1.pdf >>> >>> >>> >>> >>> T: +1 613 270 3183 >>> >>> >>> >>> >>> _______________________________________________ >>> wpkops mailing list >>> wpkops@ietf.org >>> https://www.ietf.org/mailman/listinfo/wpkops >>> >> _______________________________________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/listinfo/wpkops > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > > From tim.moses@entrust.com Mon Sep 17 10:18:32 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC2221F8526 for ; Mon, 17 Sep 2012 10:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgPZmXYvrWDe for ; Mon, 17 Sep 2012 10:18:31 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id E430A21F867C for ; Mon, 17 Sep 2012 10:18:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,437,1344225600"; d="scan'208";a="1962983" Received: from unknown (HELO SOTTEXCHCAS2.corp.ad.entrust.com) ([10.4.51.224]) by ipedge2.entrust.com with ESMTP; 17 Sep 2012 13:18:16 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by SOTTEXCHCAS2.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.001; Mon, 17 Sep 2012 13:18:15 -0400 From: Tim Moses To: 'Ronald Bonica' Thread-Topic: [wpkops] Third draft charter proposal Thread-Index: Ac2TWy5Wt+5+AKCyQmSih2MU3O89AQALtceAAGDaMQAABUxZ4A== Date: Mon, 17 Sep 2012 17:18:14 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A58738B@SOTTEXCH10.corp.ad.entrust.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A5862E7@SOTTEXCH10.corp.ad.entrust.com> <5054BC5F.5080107@cs.tcd.ie> <13205C286662DE4387D9AF3AC30EF456D7834D9FB4@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D7834D9FB4@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.88] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "wpkops@ietf.org" , Stephen Farrell Subject: Re: [wpkops] Third draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 17:18:32 -0000 Hi Ron. I have written up a BoF proposal/application and it is with Steve = Hanna for his consideration. I'll forward it to you as soon as I hear back= from Steve. All the best. Tim. -----Original Message----- From: Ronald Bonica [mailto:rbonica@juniper.net]=20 Sent: Monday, September 17, 2012 11:49 AM To: Stephen Farrell; Tim Moses Cc: wpkops@ietf.org Subject: RE: [wpkops] Third draft charter proposal Folks, On September 26, the IAB and IESG will review BoF proposals. Would it be OK= if I included this version of the charter proposal in the BoF proposal? Ron > -----Original Message----- > From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On=20 > Behalf Of Stephen Farrell > Sent: Saturday, September 15, 2012 1:35 PM > To: Tim Moses > Cc: wpkops@ietf.org > Subject: Re: [wpkops] Third draft charter proposal >=20 >=20 > Hi Tim, >=20 > That looks pretty good to me. Some comments below. >=20 > On 09/15/2012 05:00 PM, Tim Moses wrote: > > Colleagues - Here is a third draft of the WPKOPS charter proposal. > It attempts to accommodate comments received on the second draft. > > > > The other major change is that I have deleted the proposal for a > draft on communications between the certificate-holder and the=20 > certificate issuer. This was included originally to ensure that we=20 > didn't lose sight of the role of the Web server in the "stapling" > process. But, I think this can be dealt with in the "certificate=20 > revocation" document. > > > > Equally to the point, I have received commitments from individuals=20 > > to > act as the primary editors for the remaining documents. Rick Andrews=20 > from Symantec with Scott Rea and Ben Wilson from DigiCert have offered=20 > to tackle certificate revocation, Ben Wilson and colleagues from=20 > DigiCert have offered to tackle the behavior of the certificate using=20 > product, and Adam Langley of Google has volunteered to edit the draft=20 > on TLS stack operation. > > > > I am looking for others to volunteer to assist in an editing role. > Please let me know as soon as you possibly can and I'll put you in=20 > touch with the editors that have already been identified. > > > > Thanks a lot. All the best. Tim. > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > The Web PKI is the set of systems and procedures most commonly used > to protect the confidentiality, integrity and authenticity of=20 > communications between Web browsers and Web content servers. It first=20 > appeared in 1993 or thereabouts and has developed continuously in a=20 > somewhat organic fashion since then. Across all the suppliers and the=20 > point releases of their products, there are now hundreds of variations=20 > on the Web PKI in regular use. And this can be a source of problems=20 > for end-users, certificate holders, and certificate issuers. > > > > For end-users, there is no clear view whether certificate "problems" > remain when they see indication of a "good" connection. For instance,=20 > in some browsers, a "good" indication may be displayed when a "revoked" > response has been received and "accepted" by the user, whereas other=20 > browsers may refuse to display the contents under these circumstances. > > > > Certificate holders may have difficulty understanding whether some > browser versions will reject their certificate if certain content=20 > specifications are not met, such as a subject public key that does not=20 > satisfy a minimum key size, or a certificate policies extension that=20 > does not contain a particular standard policy identifier. > > > > And for issuers, it can be difficult to predict what proportion of > the user population will accept a certificate chain with certain=20 > characteristics. For instance, when a browser includes a nonce in an=20 > OCSP request but the server supplies a response that does not include=20 > the nonce, it is hard to know which browsers will accept and which=20 > will reject the response. > > > > Starting from the premise that more consistency in Web security > behavior is desirable, a natural first step would be to document=20 > current and historic browser and server behavior. But, such a project=20 > has to be bounded. Therefore, only server-authentication behavior=20 > encountered in more than 0.1 percent of connections made by desktop=20 > and mobile browsers should be considered. While it is not intended to=20 > apply the threshold with any precision, it may be used to justify the=20 > inclusion or exclusion of a technique. > > > > Future activities may attempt to prescribe how the Web PKI "should" > work, and the prescription may turn out to be a proper subset of the=20 > PKIX PKI. However, that task is explicitly not a goal of the proposed=20 > working group. Instead, the group's goal is merely to describe how=20 > the Web PKI "actually" works in the set of browsers and servers that=20 > are in common use today. > > > > Additionally, a number of applications (such as client > authentication, document signing, code signing, and email) may use the=20 > same trust anchors and certificate-handling libraries as the ones used=20 > for server authentication on the Web. Nevertheless, they may use the=20 > results in a way that is visibly different from the way in which they=20 > are used for server authentication. While these applications are=20 > considered outside the scope of this working group, deliverables=20 > should (wherever practical within the available expertise and time)=20 > identify other applications that exhibit identical behavior and=20 > identify the implications of that behavior where they differ from=20 > those for server authentication. > > > > Also, the reliability of the Web PKI depends critically on the > practices of its certificate issuers; practices such as: how the=20 > contents of certificate applications are verified and how access (both=20 > direct and indirect) to the CA's private key is controlled. However,=20 > the topic of practices is considered outside the scope of the working=20 > group. >=20 > I think that last sentence is problematically ambiguous. I suspect=20 > that the term "practice" has evolved into something well defined for=20 > CAB forum members but I don't think its well understood in the IETF.=20 > If you don't make this more precise, in terms understood in the IETF=20 > context, I suspect the WG might have recurring friction about what is=20 > or is not in scope. >=20 > Some examples of what's in/out of scope might help the discussion here=20 > I reckon. >=20 > > This topic will be left to other competent bodies, such as the > CA/Browser Forum [1][2]. >=20 > I think that sentence wouldn't be needed if the previous one were well=20 > enough defined. I also think that since CAB forum's constitution is in=20 > flux it'd be better to just not mention it in the charter. >=20 > > > > That there are technical shortcomings with Web PKI, as it is > practiced today, is well recognized. And, that there is also some=20 > urgency in addressing these shortcomings is also well recognized. =20 > But, it is felt that too much haste can be counter-productive. The=20 > expectation is that the work of this group will bring to light, in a=20 > systematic way, aspects of the Web PKI that should be progressed in=20 > future working groups of the IETF's Security Area, and that suppliers=20 > will be willing to participate in those working groups and modify=20 > their products to comply with their standards. > > > > Given the urgency of the required developments and the scale of the > task, it is agreed that adherence to the published schedule should=20 > take precedence over completeness of the results. >=20 > I sympathise with that, but it needs to be understood (e.g. by folks=20 > new to the IETF) that the usual IETF processes do apply and the WG=20 > doesn't get to override those. That means that technically correct and=20 > relevant comments can be a showstopper at any point for example. I=20 > don't know if that needs different text, but it needs to be understood. >=20 > > Milestones > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > I think these deliverables need to be better characterised in the text=20 > above, e.g. its not clear that the "trust model" document is meant=20 > only to document the existing trust model(s) that are in use in=20 > non-trivial deployments. >=20 > I'm also not sure if this is the right structure for the set of=20 > documents you want to produce, e.g. whether or not its better to=20 > separate trust models from the processing of e.g. issuer, subject and=20 > SPKI fields, nor whether it makes sense to discuss OCSP in one=20 > document but revocation in another. >=20 > So I think a bit more discussion on that is needed. >=20 > Cheers, > S. >=20 > > > > 1. First WG draft of "trust model" document (4 months). > > 2. First WG draft of "certificate, CRL, and OCSP field and > extension processing" document (12 months). > > 3. First WG draft of "certificate revocation" document (8 months). > > 4. First WG draft of "TLS stack operation" document (8 months). > > 5. IESG submission of "trust model" document (16 months). > > 6. IESG submission of "certificate, CRL, and OCSP field and > extension processing" document (24 months). > > 7. IESG submission of "certificate revocation" document (20 > months). > > 8. IESG submission of "TLS stack operation" document (16 months). > > > > > > References: > > > > [1] Network and certificate system security requirements, > CA/Browser Forum, Aug 2012, > https://www.cabforum.org/Network_Security_Controls_V1.pdf > > > > [2] Baseline Requirements for the Issuance and Management of > Publicly-Trusted Certificates Version 1.0, CA/Browser Forum, Nov 2011,=20 > https://www.cabforum.org/Baseline_Requirements_V1.pdf > > > > > > > > > > T: +1 613 270 3183 > > > > > > > > > > _______________________________________________ > > wpkops mailing list > > wpkops@ietf.org > > https://www.ietf.org/mailman/listinfo/wpkops > > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops From rbonica@juniper.net Mon Sep 17 11:37:00 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB9B21E803C for ; Mon, 17 Sep 2012 11:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.466 X-Spam-Level: X-Spam-Status: No, score=-106.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgdPUdMRQxFq for ; Mon, 17 Sep 2012 11:36:59 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4F421E803F for ; Mon, 17 Sep 2012 11:36:58 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUFdtxiB2zH+ijVfShfaPD1HTOaey6kdL@postini.com; Mon, 17 Sep 2012 11:36:59 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 17 Sep 2012 11:34:38 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 17 Sep 2012 14:34:37 -0400 From: Ronald Bonica To: Tim Moses Date: Mon, 17 Sep 2012 14:34:36 -0400 Thread-Topic: [wpkops] Third draft charter proposal Thread-Index: Ac2TWy5Wt+5+AKCyQmSih2MU3O89AQALtceAAGDaMQAABUxZ4AAH4w7Q Message-ID: <13205C286662DE4387D9AF3AC30EF456D7834DA209@EMBX01-WF.jnpr.net> References: <5B68A271B9C97046963CB6A5B8D6F62C3A5862E7@SOTTEXCH10.corp.ad.entrust.com> <5054BC5F.5080107@cs.tcd.ie> <13205C286662DE4387D9AF3AC30EF456D7834D9FB4@EMBX01-WF.jnpr.net> <5B68A271B9C97046963CB6A5B8D6F62C3A58738B@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A58738B@SOTTEXCH10.corp.ad.entrust.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "wpkops@ietf.org" , Stephen Farrell Subject: Re: [wpkops] Third draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 18:37:00 -0000 Thanks! > -----Original Message----- > From: Tim Moses [mailto:tim.moses@entrust.com] > Sent: Monday, September 17, 2012 1:18 PM > To: Ronald Bonica > Cc: wpkops@ietf.org; Stephen Farrell > Subject: RE: [wpkops] Third draft charter proposal >=20 > Hi Ron. I have written up a BoF proposal/application and it is with > Steve Hanna for his consideration. I'll forward it to you as soon as I > hear back from Steve. All the best. Tim. >=20 > -----Original Message----- > From: Ronald Bonica [mailto:rbonica@juniper.net] > Sent: Monday, September 17, 2012 11:49 AM > To: Stephen Farrell; Tim Moses > Cc: wpkops@ietf.org > Subject: RE: [wpkops] Third draft charter proposal >=20 > Folks, >=20 > On September 26, the IAB and IESG will review BoF proposals. Would it > be OK if I included this version of the charter proposal in the BoF > proposal? >=20 > Ron >=20 >=20 > > -----Original Message----- > > From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On > > Behalf Of Stephen Farrell > > Sent: Saturday, September 15, 2012 1:35 PM > > To: Tim Moses > > Cc: wpkops@ietf.org > > Subject: Re: [wpkops] Third draft charter proposal > > > > > > Hi Tim, > > > > That looks pretty good to me. Some comments below. > > > > On 09/15/2012 05:00 PM, Tim Moses wrote: > > > Colleagues - Here is a third draft of the WPKOPS charter proposal. > > It attempts to accommodate comments received on the second draft. > > > > > > The other major change is that I have deleted the proposal for a > > draft on communications between the certificate-holder and the > > certificate issuer. This was included originally to ensure that we > > didn't lose sight of the role of the Web server in the "stapling" > > process. But, I think this can be dealt with in the "certificate > > revocation" document. > > > > > > Equally to the point, I have received commitments from individuals > > > to > > act as the primary editors for the remaining documents. Rick Andrews > > from Symantec with Scott Rea and Ben Wilson from DigiCert have > offered > > to tackle certificate revocation, Ben Wilson and colleagues from > > DigiCert have offered to tackle the behavior of the certificate using > > product, and Adam Langley of Google has volunteered to edit the draft > > on TLS stack operation. > > > > > > I am looking for others to volunteer to assist in an editing role. > > Please let me know as soon as you possibly can and I'll put you in > > touch with the editors that have already been identified. > > > > > > Thanks a lot. All the best. Tim. > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > The Web PKI is the set of systems and procedures most commonly used > > to protect the confidentiality, integrity and authenticity of > > communications between Web browsers and Web content servers. It > first > > appeared in 1993 or thereabouts and has developed continuously in a > > somewhat organic fashion since then. Across all the suppliers and > the > > point releases of their products, there are now hundreds of > variations > > on the Web PKI in regular use. And this can be a source of problems > > for end-users, certificate holders, and certificate issuers. > > > > > > For end-users, there is no clear view whether certificate > "problems" > > remain when they see indication of a "good" connection. For > instance, > > in some browsers, a "good" indication may be displayed when a > "revoked" > > response has been received and "accepted" by the user, whereas other > > browsers may refuse to display the contents under these > circumstances. > > > > > > Certificate holders may have difficulty understanding whether some > > browser versions will reject their certificate if certain content > > specifications are not met, such as a subject public key that does > not > > satisfy a minimum key size, or a certificate policies extension that > > does not contain a particular standard policy identifier. > > > > > > And for issuers, it can be difficult to predict what proportion of > > the user population will accept a certificate chain with certain > > characteristics. For instance, when a browser includes a nonce in an > > OCSP request but the server supplies a response that does not include > > the nonce, it is hard to know which browsers will accept and which > > will reject the response. > > > > > > Starting from the premise that more consistency in Web security > > behavior is desirable, a natural first step would be to document > > current and historic browser and server behavior. But, such a > project > > has to be bounded. Therefore, only server-authentication behavior > > encountered in more than 0.1 percent of connections made by desktop > > and mobile browsers should be considered. While it is not intended > to > > apply the threshold with any precision, it may be used to justify the > > inclusion or exclusion of a technique. > > > > > > Future activities may attempt to prescribe how the Web PKI "should" > > work, and the prescription may turn out to be a proper subset of the > > PKIX PKI. However, that task is explicitly not a goal of the > proposed > > working group. Instead, the group's goal is merely to describe how > > the Web PKI "actually" works in the set of browsers and servers that > > are in common use today. > > > > > > Additionally, a number of applications (such as client > > authentication, document signing, code signing, and email) may use > the > > same trust anchors and certificate-handling libraries as the ones > used > > for server authentication on the Web. Nevertheless, they may use the > > results in a way that is visibly different from the way in which they > > are used for server authentication. While these applications are > > considered outside the scope of this working group, deliverables > > should (wherever practical within the available expertise and time) > > identify other applications that exhibit identical behavior and > > identify the implications of that behavior where they differ from > > those for server authentication. > > > > > > Also, the reliability of the Web PKI depends critically on the > > practices of its certificate issuers; practices such as: how the > > contents of certificate applications are verified and how access > (both > > direct and indirect) to the CA's private key is controlled. However, > > the topic of practices is considered outside the scope of the working > > group. > > > > I think that last sentence is problematically ambiguous. I suspect > > that the term "practice" has evolved into something well defined for > > CAB forum members but I don't think its well understood in the IETF. > > If you don't make this more precise, in terms understood in the IETF > > context, I suspect the WG might have recurring friction about what is > > or is not in scope. > > > > Some examples of what's in/out of scope might help the discussion > here > > I reckon. > > > > > This topic will be left to other competent bodies, such as the > > CA/Browser Forum [1][2]. > > > > I think that sentence wouldn't be needed if the previous one were > well > > enough defined. I also think that since CAB forum's constitution is > in > > flux it'd be better to just not mention it in the charter. > > > > > > > > That there are technical shortcomings with Web PKI, as it is > > practiced today, is well recognized. And, that there is also some > > urgency in addressing these shortcomings is also well recognized. > > But, it is felt that too much haste can be counter-productive. The > > expectation is that the work of this group will bring to light, in a > > systematic way, aspects of the Web PKI that should be progressed in > > future working groups of the IETF's Security Area, and that suppliers > > will be willing to participate in those working groups and modify > > their products to comply with their standards. > > > > > > Given the urgency of the required developments and the scale of the > > task, it is agreed that adherence to the published schedule should > > take precedence over completeness of the results. > > > > I sympathise with that, but it needs to be understood (e.g. by folks > > new to the IETF) that the usual IETF processes do apply and the WG > > doesn't get to override those. That means that technically correct > and > > relevant comments can be a showstopper at any point for example. I > > don't know if that needs different text, but it needs to be > understood. > > > > > Milestones > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > I think these deliverables need to be better characterised in the > text > > above, e.g. its not clear that the "trust model" document is meant > > only to document the existing trust model(s) that are in use in > > non-trivial deployments. > > > > I'm also not sure if this is the right structure for the set of > > documents you want to produce, e.g. whether or not its better to > > separate trust models from the processing of e.g. issuer, subject and > > SPKI fields, nor whether it makes sense to discuss OCSP in one > > document but revocation in another. > > > > So I think a bit more discussion on that is needed. > > > > Cheers, > > S. > > > > > > > > 1. First WG draft of "trust model" document (4 months). > > > 2. First WG draft of "certificate, CRL, and OCSP field and > > extension processing" document (12 months). > > > 3. First WG draft of "certificate revocation" document (8 > months). > > > 4. First WG draft of "TLS stack operation" document (8 months). > > > 5. IESG submission of "trust model" document (16 months). > > > 6. IESG submission of "certificate, CRL, and OCSP field and > > extension processing" document (24 months). > > > 7. IESG submission of "certificate revocation" document (20 > > months). > > > 8. IESG submission of "TLS stack operation" document (16 > months). > > > > > > > > > References: > > > > > > [1] Network and certificate system security requirements, > > CA/Browser Forum, Aug 2012, > > https://www.cabforum.org/Network_Security_Controls_V1.pdf > > > > > > [2] Baseline Requirements for the Issuance and Management of > > Publicly-Trusted Certificates Version 1.0, CA/Browser Forum, Nov > 2011, > > https://www.cabforum.org/Baseline_Requirements_V1.pdf > > > > > > > > > > > > > > > T: +1 613 270 3183 > > > > > > > > > > > > > > > _______________________________________________ > > > wpkops mailing list > > > wpkops@ietf.org > > > https://www.ietf.org/mailman/listinfo/wpkops > > > > > _______________________________________________ > > wpkops mailing list > > wpkops@ietf.org > > https://www.ietf.org/mailman/listinfo/wpkops From Jeff.Hodges@KingsMountain.com Mon Sep 17 11:40:34 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DD521F84F8 for ; Mon, 17 Sep 2012 11:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.878 X-Spam-Level: X-Spam-Status: No, score=-101.878 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCMzNjier1UB for ; Mon, 17 Sep 2012 11:40:33 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 7A57721F84F2 for ; Mon, 17 Sep 2012 11:40:33 -0700 (PDT) Received: (qmail 1307 invoked by uid 0); 17 Sep 2012 18:40:11 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy9.bluehost.com with SMTP; 17 Sep 2012 18:40:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=c1v/2byrNJ0snzdwBTxGVp2JpEseJ8qYyaPHJA7AQB4=; b=hLntHY9eH3Tz581dc4xhvXFX7XsrLvvu80CHSrymicKmRj+egKhjWlEUPsoQgufH0vTBXIL9f1AEpY6FvzGdgvN0D9ee7Sic70myMxBLKGIGK+3UJbWH1Ke/xjbJ3oWu; Received: from [24.4.122.173] (port=56864 helo=[192.168.11.12]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TDgEs-00007K-NP; Mon, 17 Sep 2012 12:40:10 -0600 Message-ID: <50576E89.7050405@KingsMountain.com> Date: Mon, 17 Sep 2012 11:40:09 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Tim Moses Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: wpkops@ietf.org Subject: Re: [wpkops] Third draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 18:40:34 -0000 +1 to Stephen's comments. Also, I think the first paragraph's definition of "Web PKI" merits a bit more full definition. Various folks that aren't quite as familiar with all this may well be reading and trying to understand the charter. Suggested enhancement (first paragraph becomes two paragraphs).. ### The Web PKI is the set of systems and procedures most commonly used, in conjunction with security protocols such as TLS, to protect the confidentiality, integrity and authenticity of communications between Web browsers and Web content servers. More specifically, the Web PKI (as considered here) consists of the actual contents of the certificates issued to Web application providers by Certification Authorities (CAs), the certificate validation services provided by the Authorities to web browsers and their users, and the TLS/SSL protocol stacks embedded in web servers and browsers. The Web PKI first appeared in 1993 or thereabouts and has developed continuously in a somewhat organic fashion since then. Across all the suppliers and the point releases of their products, there are now hundreds of variations on the Web PKI in regular use. And this can be a source of problems for end-users, certificate holders, and certificate issuers. ### (though, this isn't critial and shouldn't hold anything up) HTH, =JeffH From carl@redhoundsoftware.com Mon Sep 17 11:59:18 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7408421F8674 for ; Mon, 17 Sep 2012 11:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.861 X-Spam-Level: X-Spam-Status: No, score=-4.861 tagged_above=-999 required=5 tests=[AWL=-2.659, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+4eUr404YK8 for ; Mon, 17 Sep 2012 11:59:18 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B987721F8668 for ; Mon, 17 Sep 2012 11:59:17 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so8487596vbb.31 for ; Mon, 17 Sep 2012 11:59:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:x-gm-message-state; bh=LYGm0jealeG70302DSmWV5Yizzhs49D/h49p0Eoqcr8=; b=MSkZV1Irfz0fNrzzgSirgFlrMr9dNEICLBdUghS+NfDZRWnm9xmvW78P54BE4TN8Qb JUNQeHIIAxnql//lynJvJUPbhYKXUasARtyvvTNyrG/Fe8R80vF+hJRT3F38aDd2vUNb hwCkz0s5CSkGINj/gGDvSIuBxcVeO3QEE7CtyglLoITvVjNSVsb1leDPGvV6wLn9e2VH dMLtHNpXVA6yKlE/Zc7atPkY/W09xpcsLeOgftaMScQkHD6yO0KfrehqSaDXfsUs3rmO o1w5XDd7FvPlXm5nCIrXVLE1fxvQXChN/THj9RvlZ3A13yocoImdFIJA1zPlurOLT4x9 JQTg== Received: by 10.220.107.136 with SMTP id b8mr7919027vcp.17.1347908357031; Mon, 17 Sep 2012 11:59:17 -0700 (PDT) Received: from [192.168.2.8] (pool-72-66-83-116.washdc.fios.verizon.net. [72.66.83.116]) by mx.google.com with ESMTPS id f10sm1614792vdk.5.2012.09.17.11.59.13 (version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 11:59:15 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Mon, 17 Sep 2012 14:59:10 -0400 From: Carl Wallace To: Tim Moses , "wpkops@ietf.org" Message-ID: Thread-Topic: [wpkops] Third draft charter proposal In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3430738754_3417413" X-Gm-Message-State: ALoCoQntAgNfjsyG4va3P5EVeVw++nNiYU40GlFIRNX0f+j5KMyuqXXr+eVpgXy/bNy8teu1Gc30 Subject: Re: [wpkops] Third draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 18:59:18 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3430738754_3417413 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit From: Tim Moses Date: Saturday, September 15, 2012 12:00 PM To: "wpkops@ietf.org" Subject: [wpkops] Third draft charter proposal > > > Additionally, a number of applications (such as client authentication, > document signing, code signing, and email) may use the same trust anchors and > certificate-handling libraries as the ones used for server authentication on > the Web. Nevertheless, they may use the results in a way that is visibly > different from the way in which they are used for server authentication. I think the concern is that reused mechanisms can interfere with each other, not that results are used differently. > While these applications are considered outside the scope of this working > group, deliverables should (wherever practical within the available expertise > and time) identify other applications that exhibit identical behavior and > identify the implications of that behavior where they differ from those for > server authentication. I don't understand the reference to identical behavior. I suggest the following: Additionally, a number of applications (such as client authentication, document signing, code signing, and email) use the same trust anchors and certificate processing mechanisms as used for server authentication on the Web. This reuse creates problems in some situations. While these applications are outside the scope of this working group, deliverables should (wherever practical within the available expertise and time) identify mechanisms that are reused by other applications and identify the implications of that reuse. --B_3430738754_3417413 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable

From: Tim Moses <tim.moses@entrust.com>
Date: Saturday, September 15, 2012 12:00 PM
T= o: "wpkops@ietf.org" <wpkops@ietf.org>
Subject: [wpkops] Third draft charter proposal

<snip>

Additionally, a number of ap= plications (such as client authentication, document signing, code signing, a= nd email) may use the same trust anchors and certificate-handling libraries as the ones used for server authentication on the Web.  Nev= ertheless, they may use the results in a way that is visibly different from = the way in which they are used for server authentication. 

<= /div>

I think the concern= is that reused mechanisms can interfere with each other, not that results a= re used differently.

= While these appl= ications are considered outside the scope of this working group, deliverables should (wherever practical withi= n the available expertise and time) identify other applications that exhibit= identical behavior and identify the implications of that behavior where the= y differ from those for server authentication.


<= /div>
I don't understand the reference to identical behavior.  I su= ggest the following:

Additionally, a number of applicatio= ns (such as client authentication, document signing, code signing, and email= ) use the same trust anchors and certificate processing mechanisms as used f= or server authentication on the Web.  This reuse creates problems in so= me situations.  While these applications are outside the scope of this = working group, deliverables should (wherever practical within the available = expertise and time) identify mechanisms that are reused by other application= s and identify the implications of that reuse.



--B_3430738754_3417413--