From turners@ieca.com Mon Sep 3 06:40:45 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7034C21F8587 for ; Mon, 3 Sep 2012 06:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.908 X-Spam-Level: X-Spam-Status: No, score=-100.908 tagged_above=-999 required=5 tests=[AWL=-1.243, BAYES_50=0.001, 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 4udaTsEsQGFi for ; Mon, 3 Sep 2012 06:40:44 -0700 (PDT) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [67.18.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8928C21F8575 for ; Mon, 3 Sep 2012 06:40:44 -0700 (PDT) Received: by gateway11.websitewelcome.com (Postfix, from userid 5011) id 1C51BFC420748; Mon, 3 Sep 2012 08:40:45 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway11.websitewelcome.com (Postfix) with ESMTP id 0E3E3FC420717 for ; Mon, 3 Sep 2012 08:40:45 -0500 (CDT) Received: from [108.18.174.220] (port=55159 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1T8WtP-0006P0-I1 for saag@ietf.org; Mon, 03 Sep 2012 08:40:43 -0500 Message-ID: <5044B35B.9050703@ieca.com> Date: Mon, 03 Sep 2012 09:40:43 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: saag@ietf.org References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:55159 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 11 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [saag] Fwd: Public Comment Period - FIPS 140-3 (Second Draft), Security Requirements for Cryptographic Modules X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 13:40:45 -0000 Here's a recent announcement from NIST. I'm sure there are some on this list that care but might not have gotten it. If there were any change that impacted on IETF protocols that'd be good to know. spt -------- Original Message -------- Subject: Public Comment Period - FIPS 140-3 (Second Draft), Security Requirements for Cryptographic Modules Date: Fri, 31 Aug 2012 11:02:18 -0400 From: Caswell, Sara J. To: 'turners@ieca.com' NIST seeks additional comments on specific sections of *Federal Information Processing Standard 140-3 (Second Draft), /Security Requirements for Cryptographic Modules/*, to clarify and resolve inconsistencies in the public comments received in response tothe Federal Register (74 FR 91333) notice of December 11, 2009. The Second Draft is available for download on NIST’s site at_http://csrc.nist.gov/news_events/index.html_. The list of these specific sections can be found here. Comments on sections not specifically listed will not be considered. Please submit comments on these specific sections before *October 1, 2012* using the template provided at http://csrc.nist.gov/publications/drafts/fips140-3/revised-fips140-3_comments-template.dot Written comments may be sent to: Chief, Computer Security Division, Information Technology Laboratory, Attention: Dr. Michaela Iorga, 100 Bureau Drive, Mail Stop 8930, National Institute of Standards and Technology, Gaithersburg, MD 20899-8930. Electronic comments may also be sent to: FIPS140-3@nist.gov, with a Subject: “/Additional/ /Comments - FIPS 140-3 (Second Draft)./” *FIPS 140-3 Publication Development Page:* http://csrc.nist.gov/groups/ST/FIPS140_3/index.html From stephen.farrell@cs.tcd.ie Thu Sep 6 07:42:30 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@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: [saag] Fwd: [therightkey] Certificate Transparency Working Group? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group 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 stephen.farrell@cs.tcd.ie Thu Sep 6 07:58:10 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@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: [saag] [wpkops] [pkix] Fwd: [therightkey] Certificate Transparency Working Group? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group 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 turners@ieca.com Thu Sep 6 10:26:06 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118AD21F871D for ; Thu, 6 Sep 2012 10:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.164 X-Spam-Level: X-Spam-Status: No, score=-101.164 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_20=-0.74, 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 Hy1uAi9pPQny for ; Thu, 6 Sep 2012 10:26:05 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [67.18.71.14]) by ietfa.amsl.com (Postfix) with ESMTP id 667F521F8668 for ; Thu, 6 Sep 2012 10:26:05 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 2090440AABA6; Thu, 6 Sep 2012 12:26:07 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 126B140AAB85 for ; Thu, 6 Sep 2012 12:26:07 -0500 (CDT) Received: from [108.18.174.220] (port=56142 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1T9fq8-0004nN-Gv for saag@ietf.org; Thu, 06 Sep 2012 12:26:04 -0500 Message-ID: <5048DCAC.7060803@ieca.com> Date: Thu, 06 Sep 2012 13:26:04 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: saag@ietf.org References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:56142 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 10 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [saag] Fwd: NIST requests comments on two Draft Pubs for Random Bit Generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 17:26:06 -0000 Some people on this might find this of interest. spt -------- Original Message -------- Subject: NIST requests comments on two Draft Pubs for Random Bit Generation Date: Thu, 6 Sep 2012 13:19:46 -0400 From: Caswell, Sara J. To: 'turners@ieca.com' NIST requests comments on two Draft publications for random bit generation: Draft SP 800-90B, /Recommendation for the Entropy Sources Used for Random Bit Generation/ and Draft SP 800-90C, /Recommendation for Random Bit Generator (RBG) Constructions/. SP 800-90B specifies the design principles and requirements for the entropy sources used by Random Bit Generators and the tests for the validation of entropy sources. A list of questions relating to SP 800-90B is also provided for reviewers. SP 800-90C specifies constructions for the implementation of random bit generators (RBGs). An RBG may be a deterministic random bit generator (DRBG) or a non-deterministic random bit generator (NRBG). The constructed RBGs consist of DRBG mechanisms as specified SP 800-90A and entropy sources as specified in SP 800-90B. SP 800-90A is available at http://csrc.nist.gov/publications/PubsSPs.html#800-90A. Please send comments to rbg_comments@nist.gov by *December 5, 2012*. For the comments on SP 800-90B, please put “Comments on Entropy Sources” in the subject line. For the comments on SP 800-90C, please put “Comments on RBG Constructions” in the subject line. From turners@ieca.com Thu Sep 6 10:31:59 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32A321F8758 for ; Thu, 6 Sep 2012 10:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.039 X-Spam-Level: X-Spam-Status: No, score=-102.039 tagged_above=-999 required=5 tests=[AWL=0.226, 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 KdsJce0a9FxW for ; Thu, 6 Sep 2012 10:31:59 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.56.150.9]) by ietfa.amsl.com (Postfix) with ESMTP id 17D7021F8753 for ; Thu, 6 Sep 2012 10:31:59 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 1EF4CFD082DF0; Thu, 6 Sep 2012 12:31:59 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 76D9CFD082B46 for ; Thu, 6 Sep 2012 12:31:58 -0500 (CDT) Received: from [108.18.174.220] (port=56158 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1T9fvp-0008M7-Om for saag@ietf.org; Thu, 06 Sep 2012 12:31:57 -0500 Message-ID: <5048DE0D.4090801@ieca.com> Date: Thu, 06 Sep 2012 13:31:57 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: saag@ietf.org References: <20120906000602.6028.69834.idtracker@ietfa.amsl.com> In-Reply-To: <20120906000602.6028.69834.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120906000602.6028.69834.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:56158 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 11 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [saag] Fwd: NomCom 2012-2013: Call for Nomination and Feedback X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 17:32:00 -0000 FYI -------- Original Message -------- Subject: NomCom 2012-2013: Call for Nomination and Feedback Date: Wed, 05 Sep 2012 17:06:02 -0700 From: NomCom Chair To: IETF Announcement List This is a reminder that the 2012-2013 Nominating Committee (NomCom) is seeking nominations from now until September 24, 2012 . Additionally, this is an announcement that the NomCom is seeking feedback on individuals who have accepted nominations for IETF leadership positions. As we are following the advice of RFC 5680, the list of individuals who have agreed to be considered for various positions can be found on the NomCom Community Feedback Tool: https://www.ietf.org/group/nomcom/2012/input Within the coming weeks, we will be updating the list of individuals we are considering for each position as more individuals accept nominations. All feedback provided to the NomCom about these individuals is kept strictly confidential (as per RFC 3777). Your honest feedback is very important to the NomCom process. The open positions being considered by this year's NomCom can be found at the end of this email or on the NomCom 2012-2013 website: https://www.ietf.org/group/nomcom/2012/ Nominations may be made by selecting the Nominate link at the top of the NomCom 2012-2013 website or by visiting the following URL: https://www.ietf.org/group/nomcom/2012/nominate Note that nominations made using the web tool require an ietf.org (i.e., datatracker) account. You can create an ietf.org account by visiting the following URL: https://datatracker.ietf.org/accounts/create/ Nominations may also be made by email to nomcom12@ietf.org. If you do so, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you wish to nominate someone via email for more than one position, please use separate emails to do so. Self nomination is welcome. NomCom 2012-2013 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. As stated in RFC 5680: "The list of nominees willing to be considered for positions under review in the current NomCom cycle is not confidential". Willing Nominees for each position will be publicly listed. With the exception of publicly listing willing nominees, the confidentiality requirements of RFC 3777 remain in effect. All feedback and NomCom deliberations will remain confidential and will not be disclosed. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the NomCom on or before September 24, 2012. The NomCom appoints individuals to fill the open slots on the IAOC, the IAB, and the IESG. This year, the NomCom willing be filling the positions currently held by the following individuals, whose terms expire in March 2013: IAOC: -------- Dave Crocker IAB: -------- Alissa Cooper Joel Halpern David Kessens Danny McPherson Jon Peterson Dave Thaler IESG: -------- Russ Housley (IETF Chair) Pete Resnick (Applications Area) Ralph Droms (Internet Area) Ronald Bonica (Operations and Management Area) Robert Sparks (Real-Time Applications and Infrastructure Area) Adrian Farrel (Routing Area) Stephen Farrell (Security Area) Wesley Eddy (Transport Area) In addition to nominations, the Nominating Committee is actively seeking community input on the jobs that need to be filled. We have received the job descriptions from the IAB, IESG, and IAOC and they can be found at: https://www.ietf.org/group/nomcom/2012/iaoc-requirements https://www.ietf.org/group/nomcom/2012/iab-requirements https://www.ietf.org/group/nomcom/2012/chair-requirements https://www.ietf.org/group/nomcom/2012/iesg-requirements However, we also need the community's views and input on the jobs within each organization. If you have ideas on job responsibilities (more, less, different), please let us know. Please send suggestions and feedback to nomcom12@ietf.org. Thank you for your help in identifying qualified nominees, and in providing feedback about individuals we are considering for IETF leadership positions. Matt Lepinski nomcom-chair@ietf.org From SChokhani@cygnacom.com Thu Sep 6 14:19:38 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@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: [saag] [pkix] Fwd: [therightkey] Certificate Transparency Working Group? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group 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 denis.pinkas@bull.net Thu Sep 6 07:55:49 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@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: Mon, 10 Sep 2012 05:18:56 -0700 Cc: pkix@ietf.org, wpkops@ietf.org, saag@ietf.org Subject: Re: [saag] [pkix] Fwd: [therightkey] Certificate Transparency Working Group? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group 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 ietf@hardjono.net Tue Sep 11 07:47:11 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0E921F8804 for ; Tue, 11 Sep 2012 07:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 aKRxcgygWcfG for ; Tue, 11 Sep 2012 07:47:10 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id C0E3521F87FF for ; Tue, 11 Sep 2012 07:47:10 -0700 (PDT) Received: (qmail 477 invoked by uid 0); 11 Sep 2012 14:47:09 -0000 Received: from unknown (HELO box602.bluehost.com) (70.40.220.102) by cpoproxy3.bluehost.com with SMTP; 11 Sep 2012 14:47:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hardjono.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=U0RnC69CKn7+lVHCDe/+OGsyhTqRnTo0CqZ72XBv22M=; b=go7pyTXAj9tdvHOzAYBGswEQfzJvCPwlsXG2gT+xPSJTbnxe/xSkstrGHmZ2+MbIm/iHDStxwpFRXM/h7lhiRH2ayELeHhSKgBLT3cRWOkIehLhX5A+priHDo+3vAsM4; Received: from [18.111.36.97] (port=51083 helo=WINCE7P9IL9EJ0) by box602.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1TBRk5-0005ST-J1 for saag@ietf.org; Tue, 11 Sep 2012 08:47:09 -0600 From: "Thomas Hardjono" To: References: <001701cd902a$29191bf0$7b4b53d0$@hardjono.net> <5E393DF26B791A428E5F003BB6C5342A10886C5D@OC11EXPO24.exchange.mit.edu> In-Reply-To: <5E393DF26B791A428E5F003BB6C5342A10886C5D@OC11EXPO24.exchange.mit.edu> Date: Tue, 11 Sep 2012 10:47:08 -0400 Message-ID: <005e01cd902c$525f4af0$f71de0d0$@hardjono.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2QKif90gB/3ky+QgyW3dZUvBfu3QAIuzYAAAg5zxA= Content-Language: en-us X-Identified-User: {3727:box602.bluehost.com:hardjono:hardjono.net} {sentby:smtp auth 18.111.36.97 authed with ietf@hardjono.net} Subject: [saag] FW: OASIS Webinar covering plans for SAML2.1 (25 September 2012) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 14:47:11 -0000 FYI. --------------------------- Folks, As some of you may know, the OASIS SSTC is currently starting work on updating the SAML2.0 specifications. OASIS will be holding a free webinar on the plans for SAML2.1. The date is Tuesday 25 September 2012 (11AM-East). Registration is below. -------------------------------------------------------------------- OASIS Webinar on SAML2.1 (25 September 2012) The 'SAML -- Right Here, Right Now' Webinar -- during this webinar, we will briefly summarize the work which has already been done and discuss plans for SAML 2.1. The next generation, SAML 2.1, will streamline and reorganize the specifications to make it easier to implement and deploy SAML in a way which is both manageable and secure. SAML 2.1 will better align the functionality of SAML which is most commonly used, while making minor enhancements and adjustments to areas such as conformance. ~ 11:00AM - Noon - New York, USA. ~ 4:00PM - 5:00PM - London, United Kingdom. ~ 11:00PM - Midnight - Beijing, China. ~ 1:00AM - 2:00AM - Sydney, Australia (Wednesday, 26 Sept 2012). Register here: https://www1.gotomeeting.com/register/661177496 **Feel free to distribute to your colleagues** -------------------------------------------------------------------- __________________________________________ Thomas Hardjono MIT Kerberos Consortium email: hardjono[at]mit.edu mobile: +1 781-729-9559 __________________________________________ From stephen.farrell@cs.tcd.ie Wed Sep 12 10:01:57 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE0B21F8682 for ; Wed, 12 Sep 2012 10:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.099 X-Spam-Level: X-Spam-Status: No, score=-107.099 tagged_above=-999 required=5 tests=[AWL=0.590, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-4, SARE_NETPROD=0.111, SARE_SUB_RAND_LETTRS4=0.799, 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 m1woUEE0xv7t for ; Wed, 12 Sep 2012 10:01:56 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8E91F21F869C for ; Wed, 12 Sep 2012 10:01:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 833D8171471 for ; Wed, 12 Sep 2012 18:01:32 +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=1347469291; bh=jEEgJ1suu7kecH 27vscwV1OLT1IZy7IIi9VMTme0tEE=; b=M57fj5KcI6XTX8dMKgqjqz8+bTOD1h AtVl75z2Em+AHk+aeEK5YViSz8IaoBDrkvTo3NqRuGB86QYYcyPPmb/CZpFAdoqM oCtmQTaQj7WPhQxJ90LJfWjsL9XFS8KpUjAqbGy9BPybRhyxVGe1zLV0k/bhWwuj rMLt7Z+ysfH+9n3L6vOla/SQbF1PWfqyT2BTMFJTcysdksZmRaQ8OqULtZ0mXLT6 H74M2XeuwgtVm/TLA8NA6qOuD/f4jGaGOQHDUrbBmuCbvIrTyP/nYASuVCHWqpfH i6O0GDXoPZ/6ZDVgMr3BCCAmvwuajYzJXyNcsf7wyoR+ItlYjYgImbgw== 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 JZGSgyQV+Sm3 for ; Wed, 12 Sep 2012 18:01:31 +0100 (IST) Received: from [IPv6:2001:770:10:203:353a:ba33:c76c:87ba] (unknown [IPv6:2001:770:10:203:353a:ba33:c76c:87ba]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 97EC9171474 for ; Wed, 12 Sep 2012 18:01:31 +0100 (IST) Message-ID: <5050BFEC.3080002@cs.tcd.ie> Date: Wed, 12 Sep 2012 18:01:32 +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" References: In-Reply-To: X-Enigmail-Version: 1.4.4 X-Forwarded-Message-Id: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: [saag] Fwd: [IRTF-Announce] Call for Nominations: Applied Networking Research Prize 2013 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 17:01:57 -0000 FYI. I think folks enjoyed the presentation at saag in Vancouver from the ARNP winner, so if you think it'd be good to get some security researcher to an IETF meeting then nominate your favourite recent bit of their published research. S. -------- Original Message -------- Subject: [IRTF-Announce] Call for Nominations: Applied Networking Research Prize 2013 Date: Wed, 12 Sep 2012 16:58:00 +0000 From: Eggert, Lars Reply-To: anrp@irtf.org To: irtf-announce@irtf.org CALL FOR NOMINATIONS: APPLIED NETWORKING RESEARCH PRIZE (ANRP) 2013 http://irtf.org/anrp ******************************************************************** *** Submit nominations for the 2013 award period of the *** *** Applied Networking Research Prize until November 30, 2012! *** *** *** *** (Please share this announcement with your colleagues.) *** ******************************************************************** The Applied Networking Research Prize (ANRP) is awarded for recent results in applied networking research that are relevant for transitioning into shipping Internet products and related standardization efforts. Researchers with relevant, recent results are encouraged to apply for this prize, which will offer them the opportunity to present and discuss their work with the engineers, network operators, policy makers and scientists that participate in the Internet Engineering Task Force (IETF) and its research arm, the Internet Research Task Force (IRTF). Third-party nominations for this prize are also encouraged. The goal of the Applied Networking Research Prize is to recognize the best new ideas in networking, and bring them to the IETF and IRTF especially in cases where they would not otherwise see much exposure or discussion. The Applied Networking Research Prize (ANRP) consists of: • cash prize of $500 (USD) • invited talk at the IRTF Open Meeting • travel grant to attend a week-long IETF meeting (airfare, hotel, registration, stipend) • recognition at the IETF plenary • invitation to related social activities • potential for additional travel grants to future IETF meetings, based on community feedback The Applied Networking Research Prize will be awarded once per calendar year. Each year, several winners will be chosen and invited to present their work at one of the three IETF meetings during the year. HOW TO NOMINATE Only a single person can be nominated for the award. The basis of the nomination is a peer-reviewed, original journal, conference or workshop paper they authored, which was recently published or accepted for publication. The nominee must be one of the main authors of the nominated paper. Both self nominations (nominating one’s own paper) and third-party nominations (nominating someone else’s paper) are encouraged. The nominated paper should provide a scientific foundation for possible future IETF engineering work or IRTF research and experimentation, analyze the behavior of Internet protocols in operational deployments or realistic testbeds, make an important contribution to the understanding of Internet scalability, performance, reliability, security or capability, or otherwise be of relevance to ongoing or future IETF or IRTF activities. Applicants must briefly describe how the nominated paper relates to these goals, and are encouraged to describe how a presentation of these research results would foster their transition into new IETF engineering or IRTF experimentation, or otherwise seed new activities that will have an impact on the real-world Internet. The goal of the Applied Networking Research Prize (ANRP) is to foster the transitioning of research results into real-world benefits for the Internet. Therefore, applicants must indicate that they (or the nominee, in case of third-party nominations) are available to attend at least one of the year’s IETF meetings in person and in its entirety. Nominations must include: • the name and email address of the nominee • a bibliographic reference to the published (or accepted) nominated paper • a PDF copy of the nominated paper • a statement that describes how the nominated paper fulfills the goals of the award • a statement about which of the year’s IETF meetings the nominee would be available to attend in person and in its entirety • a brief biography or CV of the nominee • optionally, any other supporting information (link to nominee’s web site, etc.) Nominations are submitted via the submission site at http://irtf.org/anrp/2013/. In exceptional cases, nominations may also be submitted by email to anrp@irtf.org. SELECTION PROCESS A small selection committee comprised of individuals knowledgeable about the IRTF, IETF and the broader networking research community will evaluate the submissions against these selection criteria. IMPORTANT DATES Applications close: November 30, 2012 (hard) Notifications: December 20, 2012 SPONSORS The Applied Networking Research Prize (ANRP) is supported by the Internet Society (ISOC), as part of its Internet Research Award Programme, in coordination with the Internet Research Task Force (IRTF). HELP PUBLICIZE THE ANRP If you would like to help publicize the ANRP within your organization, you are welcome to print and use the flyer at http://irtf.org/anrp-2013-flyer.pdf From ietf@hardjono.net Tue Sep 11 07:31:47 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD2021F8809 for ; Tue, 11 Sep 2012 07:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.805 X-Spam-Level: X-Spam-Status: No, score=0.805 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 p-dnOWNA52zJ for ; Tue, 11 Sep 2012 07:31:47 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id F201121F8807 for ; Tue, 11 Sep 2012 07:31:46 -0700 (PDT) Received: (qmail 2472 invoked by uid 0); 11 Sep 2012 14:31:41 -0000 Received: from unknown (HELO box602.bluehost.com) (70.40.220.102) by cpoproxy3.bluehost.com with SMTP; 11 Sep 2012 14:31:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hardjono.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=Rkj3J180err1Eu14CVZ7/lap2K77pfe7sHktwV1p9Yo=; b=cmZJ3+/6TxNMSlxHrHhQ1sy1A6ttP5SriNpxOyX/MINcXIW1s8O0/KmjsEs7Rf7PZkC5+ab/jXSWbgUMP8Zh848PNU7ib2JFl3A22noTeEF2EYyPdUW0Db7p9/1hwfq9; Received: from [18.111.36.97] (port=50953 helo=WINCE7P9IL9EJ0) by box602.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1TBRV7-0008Ff-BU; Tue, 11 Sep 2012 08:31:41 -0600 From: "Thomas Hardjono" To: Date: Tue, 11 Sep 2012 10:31:39 -0400 Message-ID: <001701cd902a$29191bf0$7b4b53d0$@hardjono.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2QKif90gB/3ky+QgyW3dZUvBfu3Q== Content-Language: en-us X-Identified-User: {3727:box602.bluehost.com:hardjono:hardjono.net} {sentby:smtp auth 18.111.36.97 authed with ietf@hardjono.net} X-Mailman-Approved-At: Thu, 13 Sep 2012 08:01:56 -0700 Subject: [saag] OASIS Webinar covering plans for SAML2.1 (25 September 2012) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 14:31:47 -0000 Folks, As some of you may know, the OASIS SSTC is currently starting work on updating the SAML2.0 specifications. OASIS will be holding a free webinar on the plans for SAML2.1. The date is Tuesday 25 September 2012 (11AM-East). Registration is below. ---------------------------------------------------------------------- ----- OASIS Webinar on SAML2.1 (25 September 2012) The 'SAML -- Right Here, Right Now' Webinar -- during this webinar, we will briefly summarize the work which has already been done and discuss plans for SAML 2.1. The next generation, SAML 2.1, will streamline and reorganize the specifications to make it easier to implement and deploy SAML in a way which is both manageable and secure. SAML 2.1 will better align the functionality of SAML which is most commonly used, while making minor enhancements and adjustments to areas such as conformance. ~ 11:00AM - Noon - New York, USA ~ 4:00PM - 5:00PM - London, United Kingdom ~ 11:00PM - Midnight - Beijing, China ~ 1:00AM - 2:00AM - Sydney, Australia (Wednesday, 26 September 2012) Register here: https://www1.gotomeeting.com/register/661177496 **Feel free to distribute to your colleagues** ---------------------------------------------------------------------- ----- __________________________________________ Thomas Hardjono MIT Kerberos Consortium email: hardjono[at]mit.edu mobile: +1 781-729-9559 __________________________________________ From hhalpin@w3.org Mon Sep 17 08:15:23 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C6421F870B for ; Mon, 17 Sep 2012 08:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 s35FEzyaHCkE for ; Mon, 17 Sep 2012 08:15:23 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 27F8E21F870A for ; Mon, 17 Sep 2012 08:15:23 -0700 (PDT) Received: from [199.254.238.254] (helo=[172.27.0.78]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1TDd2g-0002pI-06 for saag@ietf.org; Mon, 17 Sep 2012 11:15:22 -0400 Message-ID: <50573E85.9000106@w3.org> Date: Mon, 17 Sep 2012 17:15:17 +0200 From: Harry Halpin User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] W3C WebCrypto API (Javascript) First Public Working Draft: Request for Review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 15:15:23 -0000 SAAG and larger IETF community, The W3C has recently released the First Public Working Draft of the W3C Web Crypto API [1], a Javascript API created in a W3C Working Group with representatives of all major browsers that will expose cryptographic primitives to WebApps. As you can tell, its currently only supporting core functionality, but will likely be expanded over the course of next year. The rest of the features are going to be use-case driven and "secondary", see charter for details on possible future features for the API [2]. At this stage, we are at this stage leaving many of the issues open (14 in total, clearly listed in the spec!) but we will need to close them all as soon as possible. We'd love any comments you have, please post to public-webcrypto-comments@w3.org. Any further questions I'd be happy to answer. Here I go, reigniting the Javascript authentication debate on this list :) cheers, harry [1] http://www.w3.org/TR/WebCryptoAPI/ [2] http://www.w3.org/2011/11/webcryptography-charter.html#scope From agrieco@cisco.com Thu Sep 13 14:17:37 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5A121F8484 for ; Thu, 13 Sep 2012 14:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 1vELwHpLoQyA for ; Thu, 13 Sep 2012 14:17:37 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 14CBD21F846A for ; Thu, 13 Sep 2012 14:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1072; q=dns/txt; s=iport; t=1347571057; x=1348780657; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Y3vXTdVPdgmBxU48+g3/PCt9g3Tmn+lk5wvdrvDo7N8=; b=TURf2ZL/RQPKkaLs75yLWzsTdoPKWYoFULfMt6OPPAu7kyo4dcdCUKyT ICWRKTfMPpFaeANUcehrGY/IEJnsrxAYjkgxuzerBKcjY+Q0OzzqZ4vto 7ZzWFusOjEqmsNQmLccS5LBzPycrIjxdatbmEwarZDTWlMLYWSorCClky Y=; X-IronPort-AV: E=Sophos;i="4.80,419,1344211200"; d="scan'208";a="121402817" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 13 Sep 2012 21:17:36 +0000 Received: from [64.102.57.160] (dhcp-64-102-57-160.cisco.com [64.102.57.160]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8DLHaBn027575; Thu, 13 Sep 2012 21:17:36 GMT Message-ID: <50524D70.40503@cisco.com> Date: Thu, 13 Sep 2012 17:17:36 -0400 From: Anthony Grieco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20120905 Thunderbird/16.0 MIME-Version: 1.0 To: saag@ietf.org References: <50524CD7.9030407@cisco.com> In-Reply-To: <50524CD7.9030407@cisco.com> X-Forwarded-Message-Id: <50524CD7.9030407@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 18 Sep 2012 05:38:07 -0700 Cc: Stephen Orr Subject: [saag] request for review of draft-orr-wireless-lan-architectures-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 21:17:37 -0000 All, Stephen Orr and I recently submitted: draft-orr-wireless-lan-architectures-00 “Cryptographic Security Characteristics of 802.11 Wireless LAN Access Systems.” We'd like to solicit feedback on this document. The intent of the document is to identify all of the places that cryptography is used in Wireless Local Area Network (WLAN) architectures in order to simplify the task of selecting and profiling the protocols, algorithms, and key sizes needed to achieve a consistent security level across the entire architecture. As Wireless LAN Access systems are deployed today there is no clearly defined end-to-end security consistency required. The result is the overall cryptographic strength of the WLAN System being brought down to the lowest cryptographic strength of one of the components. With this draft we are hoping to lay the foundation for other’s to construct profiles that should specify the exact end-to-end cryptographic characteristics required to provide consistency. Thanks in advance. Anthony -- Anthony Grieco Cisco From lear@cisco.com Wed Sep 19 22:02:49 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E0021F84F0; Wed, 19 Sep 2012 22:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.649 X-Spam-Level: X-Spam-Status: No, score=-110.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 wNSd1CR-4lMp; Wed, 19 Sep 2012 22:02:48 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id B0F8F21F846A; Wed, 19 Sep 2012 22:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=476; q=dns/txt; s=iport; t=1348117368; x=1349326968; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=PwHYxXpTh5aU6hXeEfjp9jdp0aUhvYVWq/QMWUN/zFc=; b=c5YM5wnBLsbCzHQa8t3yAe2AXJMyoK+JQe5H6L6qSTUPh+zqd8M9j1aw jv2rLvPF6yzrR9QlMJkB2C8O1FQ83pAsmf1fePjt+dPZPTr9qW5EI3tOn XivYmjAk2aQ/VMKRnJlt2IU2cTwBvrYncN5GTDGJ68FMPH+P82vNvhf96 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAH2iWlCQ/khL/2dsb2JhbABFhUNHtnaBCII5ARBVNgIFFgsCCwMCAQIBSwEMCAEBEA6HYQuZeI0bkmyBIY8qgRIDlWSOOIFpgmg X-IronPort-AV: E=Sophos;i="4.80,452,1344211200"; d="scan'208";a="8167974" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 20 Sep 2012 05:02:46 +0000 Received: from ams3-vpn-dhcp6699.cisco.com (ams3-vpn-dhcp6699.cisco.com [10.61.90.42]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8K52jPx003763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Sep 2012 05:02:46 GMT Message-ID: <505AA377.3050003@cisco.com> Date: Thu, 20 Sep 2012 07:02:47 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , "saag@ietf.org" X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [saag] The passing of Dr. John Larmouth X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 05:02:49 -0000 Earlier this month Dr. John Larmouth, who was the father of ASN.1 passed away. He was an active leader within the ITU-T, and the Internet community has made great use of ASN.1 in SNMP and X.509 certificates, to name a few. The ITU has published a memorial page, which you can find at http://www.itu.int/ITU-T/newslog/In+Memoriam+John+Larmouth.aspx. Russ has signed the condolence book on behalf of the IETF. Eliot (in my role as IETF Liaison Manager to the ITU-T)