From nobody Wed Aug 2 12:56:45 2017 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 654E113209B for ; Wed, 2 Aug 2017 12:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3K7PJjOJEe3R for ; Wed, 2 Aug 2017 12:56:40 -0700 (PDT) Received: from smtp105.biz.mail.bf1.yahoo.com (smtp105.biz.mail.bf1.yahoo.com [98.139.221.43]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A73C132146 for ; Wed, 2 Aug 2017 12:56:40 -0700 (PDT) Received: (qmail 50981 invoked from network); 2 Aug 2017 19:56:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1501703799; bh=tmeDelZ8QFPcH30cnSdFTZ5PxP5dbMa9bZhsI9Lazog=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:In-Reply-To; b=UBxdfvxNtt1y06DIdExaoKrNlTesR13HKvvXhzHj5iGRMUxGSZgoyGYNUbmPjUaKRFUzVIlpwF/1eReUy/K9DXpEIqI3lDuTBPHPrFO8psQIG7z7c7EB/1G5uS3sx5G0/M3x33h6FCk/CmgElWQGAP1980A+JDspl0v662kQtzc= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: EFjzMtsVM1mrRVegctRlFpb9AFbvtCl7R0sT7TpofijwlR0 t.CN4wwTtP8gmUaOWbTGFqhTpxkQnHEldzW35pHcKaS5t3nRuV4rrVyHNJAI 7za7I2ix35w1RXGGt_SHGZ5SJL8TAd8r9A2tvargu6Rr_Rae7wQDOeNdlDXO Vi18kz_.G8xX5MsimZOUpGKIz_RFSkTQqolVTk9wqMplMSeGuyZYWq0FHYXK jKrQ5iDOFy10.xZRt15bxpdH66EEXBCg4o83e6UH7hU8L4JGLNtwWluB4cZd LdmVcRNAPOL7TuPS9CeeWLjEUdTCa8OrMgVCFoNi3uaDug9gIQpn7vTBh6Ej wpb0OrPKZxMSeWw1nE7rUvt3An28nMxBOwhrpGSGwxxSFHqnqGN8qTD2rfPJ AR1wiv6BsxD.fg8lf_7OgwRY_snZsRa3ueUmQTuu3C1zUDD7V4zOQxal_dmK XrT_IhJaPnQAs.XWJaVjz2FYVEPosf9hrwHTPh5CohNhbPYROV1j.9jqNJve fkm_glsZJtvqR8h45FFF25fsucYfPXKLn8NfoKuJAzwUgTHU4QDeFPQ6B6w_ f8REdzqDceBQVJNM- X-Yahoo-SMTP: jmBfdwyswBDjKAJJHOJZlktXNss- From: "Beth Flippo" To: "'Joseph Lorenzo Hall'" , "'Polk, Tim \(Fed\)'" Cc: Date: Wed, 2 Aug 2017 16:16:05 -0400 Message-ID: <4460B8AC888C44CE9AD96092D90E06B7@telegridtech.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0255_01D30BAA.A6C8F510" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Archived-At: Subject: Re: [saag] Side meeting on USG efforts to combat botnets, Wednesday at 3:15 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 19:56:43 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0255_01D30BAA.A6C8F510 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello everyone! I am an embedded software developer at TELEGRID and we specialize in the development of custom embedded cybersecurity solutions for the US Military. I personally develop on ARM microcontrollers as well as embedded LINUX microprocessors. Unfortunately I wasn't able to attend the botnet meeting last month but I did read the attached Best Practices for IOT Devices document. I think it is a good approach to secure software development from a high-level. I don't know if this is the right forum but I was hoping to provide tangible steps to implement security on IoT embedded platforms based on my experience. Any recomendations for how I can get involved? Thank you! Beth Beth Flippo VP Embedded Software Development TELEGRID Technologies, Inc. 23 Vreeland Road Florham Park, NJ 07932 Work: (973) 994-4440 www.telegrid.com TELEGRID is ISO 9001:2008 Certified ------------------------------------------------------------------------ ------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind TELEGRID to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ------------------------------------------------------------------------ ------------------------------- -----Original Message----- From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Joseph Lorenzo Hall Sent: Wednesday, July 19, 2017 10:05 AM To: Polk, Tim (Fed) Cc: saag@ietf.org Subject: Re: [saag] Side meeting on USG efforts to combat botnets, Wednesday at 3:15 Richard Barnes pointed to this I-D that looks pretty damn good here in terms of a floor for IoT technical requirements: https://tools.ietf.org/html/draft-moore-iot-security-bcp-01 On Tue, Jul 18, 2017 at 11:51 AM, Polk, Tim (Fed) wrote: Folks, I have reserved the side meeting room (Tyrolka, Mezzanine Level) on Wednesday from 3:15 - 4:30 for an informal discussion of an ongoing US Government effort to combat botnets and other "automated, distributed threats" to the Internet. This effort will produce a document that identifies and promotes "action by appropriate stakeholders" by May of 2018. Given that the USG does not own or operate the Internet, such an effort is always at risk of creating shelfware, and I am too old to waste my time that way. To ensure that actions identified in the report are pragmatic and effective, I would like to encourage participation by members of this community. If you have an interest, please join me in Tyrolka tomorrow afternoon or catch me in the hallway between meetings. For those with an interest, here is some additional background information, including an immediate opportunity to participate: Executive Order 13800, Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure, which was issued May 11, 2017, requires the Secretaries of Commerce and Homeland Security to "jointly lead an open and transparent process to identify and promote action by appropriate stakeholders to improve the resilience of the internet and communications ecosystem and to encourage collaboration with the goal of dramatically reducing threats perpetrated by automated and distributed attacks (e.g., botnets)." The executive order requires Commerce and DHS to issue a draft report in 240 days (January 5, 2018) and submit a final report to the President one year after issuance (May 11, 2018). Given this aggressive timeline, there are several different (but hopefully complementary) workstreams underway at Commerce and DHS that may be of interest. In particular: (1) The National Telecommunications and Information Administration (NTIA) published a "Request for Comments on Promoting Stakeholder Action Against Botnets and Other Automated Threats" on June 8. In the request, "NTIA seeks broad input from all interested stakeholders-including private industry, academia, civil society, and other security experts-on ways to improve industry's ability to reduce threats perpetuated by automated distributed attacks, such as botnets, and what role, if any, the U.S. Government should play in this area." NTIA would definitely appreciate comments from members of this community! Additional details may be in the full text of the request for comments, found in https://www.gpo.gov/fdsys/pkg/ FR-2017-06-13/pdf/2017-12192.pdf Note that the official comment period was extended to July 28 in https://www.gpo.gov/fdsys/pkg/ FR-2017-06-22/pdf/2017-13034.pdf (2) Last week, NIST hosted a public workshop on "Enhancing Resilience of the Internet and Communications Ecosystem". 150 participants from a range of industry sectors, civil society, and government participated in a day and half workshop. The workshop explored a range of current and emerging solutions to enhance the resiliency of the Internet against automated, distributed threats. The workshop agenda is available at https://www.nist.gov/sites/ default/files/documents/2017/07/10/final-draft-agenda-resilience-worksho p-070517.pdf NIST plans to summarize results in a workshop report for publication in September 2017. Regards, Tim Polk _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/ listinfo/saag -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ------=_NextPart_000_0255_01D30BAA.A6C8F510 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hello = everyone!
 
I am an embedded = software developer=20 at TELEGRID and we specialize in the development of custom embedded=20 cybersecurity solutions for the US Military. 
 
I personally develop on = ARM microcontrollers as well as embedded = LINUX=20 microprocessors.
 
Unfortunately I wasn't = able to attend=20 the botnet meeting last month but I did read the attached Best Practices for IOT = Devices=20 document.  I think it is a good approach to secure software = development=20 from a high-level.
 
I don’t know if = this is the right=20 forum but I was hoping to provide tangible=20 steps to implement security on IoT embedded platforms based on my experience.
 
Any recomendations for how I can get involved?
 
Thank = you!
Beth
 
 
 
Beth Flippo
VP = Embedded Software=20 Development
TELEGRID Technologies, Inc.
23 Vreeland = Road
Florham Park,=20 NJ 07932
Work: (973) 994-4440
www.telegrid.com
TELEGRID is ISO = 9001:2008=20 Certified
 
------------------------------------------------------------= -------------------------------------------
This=20 is a PRIVATE message. If you are not the intended recipient, please = delete=20 without copying and kindly advise us by e-mail of the mistake in = delivery. NOTE:=20 Regardless of content, this e-mail shall not operate to bind TELEGRID to = any=20 order or other contract unless pursuant to explicit written agreement or = government initiative expressly permitting the use of e-mail for such=20 purpose.
-------------------------------------------------------------= ------------------------------------------
-----Original Message-----
From: saag=20 [mailto:saag-bounces@ietf.org] On Behalf Of Joseph Lorenzo=20 Hall
Sent: Wednesday, July 19, 2017 10:05 AM
To: = Polk, Tim=20 (Fed)
Cc: saag@ietf.org
Subject: Re: [saag] Side = meeting=20 on USG efforts to combat botnets, Wednesday at = 3:15

Richard Barnes pointed to this I-D that looks pretty = damn good=20 here in terms of a floor for IoT technical requirements:

http= s://tools.ietf.org/html/draft-moore-iot-security-bcp-01

On Tue, Jul 18, 2017 at 11:51 AM, Polk, Tim = (Fed) <william.polk@nist.gov> wrote:

Folks,

 

I have reserved the = side meeting=20 room (Tyrolka, Mezzanine Level) on Wednesday from 3:15 = – 4:30=20 for an informal discussion of an ongoing US Government effort to = combat=20 botnets and other “automated, distributed threats” to = the=20 Internet.  This effort will produce a document = that=20 identifies and promotes “action by appropriate = stakeholders” by May of=20 2018.  Given that the USG does not own or operate = the=20 Internet, such an effort is always at risk of creating shelfware, = and I am=20 too old to waste my time that way.  To ensure that = actions=20 identified in the report are pragmatic and effective, I would like = to=20 encourage participation by members of this community.

 

If you have an = interest, please=20 join me in Tyrolka tomorrow afternoon or catch me in the hallway = between=20 meetings.

 

For those with an = interest, here=20 is some additional background information, including an immediate=20 opportunity to participate:

 

Executive Order=20 13800, Strengthening the Cybersecurity of Federal Networks and = Critical=20 Infrastructure, which was issued May 11, 2017, = requires the=20 Secretaries of Commerce and Homeland Security to “jointly lead = an open and=20 transparent process to identify and promote action by appropriate=20 stakeholders to improve the resilience of the internet and = communications=20 ecosystem and to encourage collaboration with the goal of = dramatically=20 reducing threats perpetrated by automated and distributed attacks = (e.g.,=20 botnets).” 

 

The executive order = requires=20 Commerce and DHS to issue a draft report in 240 days (January 5, = 2018) and=20 submit a final report to the President one year after issuance (May = 11,=20 2018).  Given this aggressive timeline, there are = several=20 different (but hopefully complementary) workstreams underway at = Commerce and=20 DHS that may be of interest.  In = particular:

 

(1) The National=20 Telecommunications and Information Administration (NTIA) published a = “Request for Comments on Promoting Stakeholder Action Against = Botnets and=20 Other Automated Threats” on June 8.  In the request, = “NTIA seeks broad=20 input from all interested stakeholders—including private = industry, academia,=20 civil society, and other security experts—on ways to improve = industry’s=20 ability to reduce threats perpetuated by automated distributed = attacks, such=20 as botnets, and what role, if any, the U.S. Government should play = in this=20 area.”  NTIA would definitely appreciate = comments from=20 members of this community!

 

Additional details may = be in the=20 full text of the request for comments, found in

https://www.gpo.gov/fdsys/pkg/FR-2017-06-13/pdf/2017= -12192.pdf

 

Note that the official = comment=20 period was extended to July 28 in

https://www.gpo.gov/fdsys/pkg/FR-2017-06-22/pdf/2017= -13034.pdf

 

(2) Last week, NIST = hosted a=20 public workshop on “Enhancing Resilience of the Internet and = Communications=20 Ecosystem”.  150 participants from a range of industry = sectors, civil=20 society, and government participated in a day and half = workshop. =20  The workshop explored a range of current = and=20 emerging solutions to enhance the resiliency of the Internet against = automated, distributed threats. The workshop agenda is available at=20

https://www.nist.gov/sites/default/files/documents/2= 017/07/10/final-draft-agenda-resilience-workshop-070517.pdf=

 

NIST plans to summarize = results=20 in a workshop report for publication in September 2017.

 

 Regards,

 

Tim Polk

 


=


_____________________________________________= __
saag=20 mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag


--
Joseph = Lorenzo=20 Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST=20 NW STE 200, Washington DC 20005-3497
e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: = 3CA2 8D7B=20 9F6D DBD3 4B10  1607 5F86 6987 40A9=20 A871
------=_NextPart_000_0255_01D30BAA.A6C8F510-- From nobody Mon Aug 7 04:12:35 2017 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 8D51B1320B5 for ; Mon, 7 Aug 2017 04:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82a1AEsxSLlD for ; Mon, 7 Aug 2017 04:12:32 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03CCF1293E1 for ; Mon, 7 Aug 2017 04:12:32 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id s6so600412qtc.1 for ; Mon, 07 Aug 2017 04:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ILMOR/EZ19mg311X4D6lRd79H6FIglABLh2HsEBkhEw=; b=cd2uuZsUz3GaNyx2huYWV2p5SdXt6RXFNp6rBi6DzXad+C3xbHaMbn+xHCAgOlAE3g UzgDXvfFC+mAS4pcVz+vrFod6m5huvf7KWflqKIySBULuE3DMm564mpSt/kVjAbJV4Tf v+e2enVANe0CrCrUG3tYFFw9xeQ4hGDXckl+6e0jbX84L9/+WLonoELAEabv074EZqOR fBH+eFYqJGXsKQ0gngtcI39g3kkhhf8qgZFD7cKn4ueTaHdw6LIJgu08FXA40f5plc/A NOmyywow2U66S1gZBfznemSm3GfauzB0cv+pksZfGL0oE4AKO5E0+2NTuXxIgYKlr0zb XRJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ILMOR/EZ19mg311X4D6lRd79H6FIglABLh2HsEBkhEw=; b=Tazuy+TtBUGejBhKoxHLC71/m4ohPx0ky3HbLh1LNSg1GaYyr5qckV1zlI+/3PTvaH H3KnW/zLWxTo2Ip/WYhGHaJHG1yJ7cWc8Mqh/MOPIas7O8LyDDa86T8tVqQudL1B69Av b8PYzlHKAnZ5zB1H26ravdRdRbkYWqxL3AftCQvJQrpaq4rlKBmfwckkOAJ3frazC/14 +P+cY1b/OgWvOrfEHJmzPbgOYrDMPETezeWjqSLUp1orNrVwdiOC26IqgYT1oY0aGLCx P8T/8j+TuZUYajAphd2qCXAIZRZQZ/UQqyDrlMKBM1RZfGuAbLrtQSRxxiyHuoUWDquT 3xUw== X-Gm-Message-State: AHYfb5hMUssE4zAtkfnQPlo8tpk4lCODhqdgelIy0qH63x3/MBAXGQV4 VZ59u37+AeOb7ozWcgUV5FlKMgpLnW8lR7E= X-Received: by 10.237.37.107 with SMTP id w40mr190061qtc.14.1502104350959; Mon, 07 Aug 2017 04:12:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.209.228 with HTTP; Mon, 7 Aug 2017 04:11:50 -0700 (PDT) From: Nikos Mavrogiannopoulos Date: Mon, 7 Aug 2017 13:11:50 +0200 Message-ID: To: IETF SAAG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] storing validation parameters on PKCS#8 formatted private keys X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 11:12:34 -0000 Hi, I've needed to store parameters related to FIPS-186-4 provable key generation validation in a PKCS#8 private keys for RSA (can be used for DSA too if anyone cares). I've described the PKCS#8 extension at: http://nmav.gitlab.io/draft-mavrogiannopoulos-pkcs8-validated-parameters/ The approach followed was simple, store the validation parameters as an attribute, something that allows the keys to be backwards compatible. I'd appreciate comments on the approach. regards, Nikos From nobody Mon Aug 7 08:53:42 2017 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 1DFD013238F for ; Mon, 7 Aug 2017 08:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXKjlP9hJvZp for ; Mon, 7 Aug 2017 08:53:39 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E348132320 for ; Mon, 7 Aug 2017 08:53:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7F1A3300546 for ; Mon, 7 Aug 2017 11:53:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8wk1aXwujavG for ; Mon, 7 Aug 2017 11:53:33 -0400 (EDT) Received: from [192.168.1.9] (75-139-107-240.dhcp.mant.nc.charter.com [75.139.107.240]) by mail.smeinc.net (Postfix) with ESMTPSA id 9CD8F300288; Mon, 7 Aug 2017 11:53:33 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Mon, 7 Aug 2017 11:53:39 -0400 Cc: IETF SAAG Content-Transfer-Encoding: quoted-printable Message-Id: <351EDC5F-D7A3-4377-A662-2EDBDC17D5CA@vigilsec.com> References: To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [saag] storing validation parameters on PKCS#8 formatted private keys X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 15:53:41 -0000 This seems like a simple and straightforward approach to me. I'd = support publication as an RFC. Russ > On Aug 7, 2017, at 7:11 AM, Nikos Mavrogiannopoulos = wrote: >=20 > Hi, > I've needed to store parameters related to FIPS-186-4 provable key > generation validation in a PKCS#8 private keys for RSA (can be used > for DSA too if anyone cares). I've described the PKCS#8 extension at: > = http://nmav.gitlab.io/draft-mavrogiannopoulos-pkcs8-validated-parameters/ >=20 > The approach followed was simple, store the validation parameters as > an attribute, something that allows the keys to be backwards > compatible. I'd appreciate comments on the approach. >=20 > regards, > Nikos >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Tue Aug 8 01:24:09 2017 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 B26DE1320BE for ; Tue, 8 Aug 2017 01:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vi4zYjjMa23U for ; Tue, 8 Aug 2017 01:24:05 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E68124B0A for ; Tue, 8 Aug 2017 01:24:05 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id d145so15877002qkc.2 for ; Tue, 08 Aug 2017 01:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=X7JJgWl7DtEESckZFxIfqNJSeyU7J/gLfBzWLI/dQjo=; b=j0E4bVi5LRRnpuZedPhDXylt7bVjRI6NvTrz9QlBAaGVRHiKwxTXe6MyOVZiW6hF9X aDhkubRFOjclJ6E8z9PeCJyL9StI1/kzHtXivRvnmU3CtkJ3csvGebFUVEs7dFmXv753 kmJCY2ZXv9N3VB3kwsWRQ3JezgugY0x8PuZjvwd1MOZhZC78Hre+lcC7mlfC3lJfQ8vb IYNyijhRvOtkOQtnFO4N8Xo87BzxydxyS/pph1nr3vROaN59lSQ/LOYiRIBHknq5Zbb9 AturtaoBWf9Ui+9IS4FbWEi92EVEG9FZ9WLA/Q4wm9DdNXLsHny/pd7jxcUKmRxO+gv0 ltZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=X7JJgWl7DtEESckZFxIfqNJSeyU7J/gLfBzWLI/dQjo=; b=a1HY7smHCMizlSQ6a4E6H4QCSpTnSU0gVOj1lY/PiSMzEEMKqRHlr9jT/mhJuvSFrn imf2+VveqsEs+CEAc6u9X7a142tOkCGjLvw1qA0b4oWW1p10ZpwhfwsnYNS0DsW82m00 Z/WcjrUKqdjcGo9OWbcHImAP6aBuA/r8F/rChcD3uCsD9ESMsSfMM9aRjNPkmJLgafgj J/0C7jmIIfeP6lOWdfZ6TJ8M1TXTthLFAECtwRsCVKxF66LGr9/w82NBKngGCiakKNmS bBci7JgN7YrmyMvHcxX6h2b5cSKTsKRyfv2Nne5nD+v/ZFTIwViIZaiE3IE68ceVFOsa 2Xyw== X-Gm-Message-State: AHYfb5gtYcedogYawIvAKMmaK6cH6RTUdlTFofpdYmz1lPFDBkmvTjXE 0MsJytO3QWH63/kcvhuqe3qlVnxQIw== X-Received: by 10.55.188.134 with SMTP id m128mr4487317qkf.233.1502180644817; Tue, 08 Aug 2017 01:24:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.209.228 with HTTP; Tue, 8 Aug 2017 01:23:24 -0700 (PDT) In-Reply-To: <627C0D5E-E705-4AB5-80E2-62D7EF635BA3@vigilsec.com> References: <627C0D5E-E705-4AB5-80E2-62D7EF635BA3@vigilsec.com> From: Nikos Mavrogiannopoulos Date: Tue, 8 Aug 2017 10:23:24 +0200 Message-ID: To: Russ Housley , David Woodhouse Cc: IETF SAAG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] encrypted files with UTF-8/16 passwords X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 08:24:08 -0000 On Wed, May 3, 2017 at 7:01 PM, Russ Housley wrote: > I do not understand two things in your Internet-Draft. > > In Section 3, I do not know what you mean by: > > As an exception to the OpaqueString profile, empty (zero-length) > passwords MAY be used, when they are not they result of the [RFC7613] > processing. > > Can you please state as: If a zero-length string is provided as a passwor= d, then =E2=80=A6 Thank you Russ for the comments. Sorry it took quite long to get back to it= . I've rephrase it as: Note that the OpaqueString profile does not allow empty passwords. Since th= ese passwords are often used in practice, applications conforming to this docum= ent MAY allow empty (zero-length) passwords, when they are not they result of the processing. That is, an empty string generated from any non-empty internationalized input MUST NOT be used. > In Section 5.2, I do not know how an implementation is impacted by the MU= ST statement: > > =E2=80=A6 This is the correct > version which any application supporting the use of files for > certificates and keys MUST support. > > I think you are trying to say that PKCS#12 implementations MUST encode th= e password in UTF-16 big-endian form. However, Appendix B.1 of RFC 7292 al= ready says that, and more. Note that this section is not intended to be a normative description of RFC7292, but rather document bugs in password processing of existing software. The intention of this description is to provide context on why openssl's conversion on the next paragraphs was incorrect. > > In this specification, however, all passwords are created from > BMPStrings with a NULL terminator. This means that each character in > the original BMPString is encoded in 2 bytes in big-endian format > (most-significant byte first). There are no Unicode byte order > marks. The 2 bytes produced from the last character in the BMPString > are followed by 2 additional bytes with the value 0x00. > > Further, your example omits the UTF-16 null character (0x00 0x00) from th= e resulting password string. Added and posted an updated version at: https://tools.ietf.org/html/draft-mavrogiannopoulos-pkcs5-passwords-01 regards, Nikos From nobody Tue Aug 8 01:25:01 2017 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 9F9941320E3 for ; Tue, 8 Aug 2017 01:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfZXK0l9Y8wf for ; Tue, 8 Aug 2017 01:24:58 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 294941320DC for ; Tue, 8 Aug 2017 01:24:58 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id x191so15680878qka.5 for ; Tue, 08 Aug 2017 01:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XKtqrAGUfN7sCWPSZdJEso+9jKDyo6s+kbc/XgailVs=; b=HewXyIB/COw0c5mPIrGeT0VhAsegf0bk6knX0u8H59L56lyYKDIOBjk3Md33n9xdD5 jNQ8Me5KPVoS9Dl5lGcYovb9+lch5pYX2lzYtzTHwor6YvB1vRJPPcLFEhBbBY6Y8bCS 98KB6CeO1LedH5z1knmH0uPU2MaGk6CML+LryjwmqdAgzgl8YPeqaklE6/cx0BEgkOmo Nv4kVDvvS1uvj2BZswEMF/y6CoXflglH0r0Yl6UOdVMwDdQFePcM9Z8OxzxUE82Crz/N 4GYS66jP6vbe6EPl3gIryPWrh3auIaXZzxLc5So84maMzXOz8G8H+GH3U4zgbIzYfaUv Y6qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XKtqrAGUfN7sCWPSZdJEso+9jKDyo6s+kbc/XgailVs=; b=UtnUb6mOoUF3EAPm2ZPGBJbv50xeUu/bNi5p/nV/hOCM5PPgXW4jjUKJaeRdEk36O2 6xLaouf9nbM5Up4MpSir50FbNYiQy4RpEOeK49jfoHoq1d9hxT9QF+Uvj5JWJLbMf6By Yyr98e0ERCuwRrkG1T8aOT8pM1pOPYOT9fMtcuzH49GZX+FQ3zc41E2FApVeImhvq/66 hXXCSUYITdIDj8VITsj5BpUHR1Y9hWH6Mn1jq0870S27qN6YI8FHkUp5MmAVrr6uBwyZ N+vhjdF+D6dNTUytg+22zeBlaQ5REkwC0sSdIJeXtFTMqaxljLQEAmSlWE05F1uBDr6q RJfg== X-Gm-Message-State: AHYfb5iKt/kA6HexRYMQPZEID1bky2g5sZmqZJ1xHLhhqlsszEhYMKQ6 L3pje/Lc0ATmDLBhCjZijbXVzNQGYMoyTeE= X-Received: by 10.55.168.140 with SMTP id r134mr4588621qke.204.1502180697369; Tue, 08 Aug 2017 01:24:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.209.228 with HTTP; Tue, 8 Aug 2017 01:24:17 -0700 (PDT) In-Reply-To: <351EDC5F-D7A3-4377-A662-2EDBDC17D5CA@vigilsec.com> References: <351EDC5F-D7A3-4377-A662-2EDBDC17D5CA@vigilsec.com> From: Nikos Mavrogiannopoulos Date: Tue, 8 Aug 2017 10:24:17 +0200 Message-ID: To: Russ Housley Cc: IETF SAAG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] storing validation parameters on PKCS#8 formatted private keys X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 08:24:59 -0000 Thank you. I've posted a version at: https://tools.ietf.org/html/draft-mavrogiannopoulos-pkcs8-validated-parameters-00 On Mon, Aug 7, 2017 at 5:53 PM, Russ Housley wrote: > This seems like a simple and straightforward approach to me. I'd support publication as an RFC. > > Russ > > >> On Aug 7, 2017, at 7:11 AM, Nikos Mavrogiannopoulos wrote: >> >> Hi, >> I've needed to store parameters related to FIPS-186-4 provable key >> generation validation in a PKCS#8 private keys for RSA (can be used >> for DSA too if anyone cares). I've described the PKCS#8 extension at: >> http://nmav.gitlab.io/draft-mavrogiannopoulos-pkcs8-validated-parameters/ >> >> The approach followed was simple, store the validation parameters as >> an attribute, something that allows the keys to be backwards >> compatible. I'd appreciate comments on the approach. >> >> regards, >> Nikos >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > From nobody Tue Aug 8 21:48:04 2017 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 A9CD1131D24 for ; Tue, 8 Aug 2017 21:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4mD-O2dv9fB for ; Tue, 8 Aug 2017 21:48:00 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0085.outbound.protection.outlook.com [104.47.37.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61984120227 for ; Tue, 8 Aug 2017 21:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PjswhK/XkYdyqUTUWTHOGaMchpAi9V/r//0mEHlbwDQ=; b=n8FZMZAGClwCCrJ+m2MRinHEPiWDpEGpdhJZFpp6e4mt9eNxnZj55RqVHQ9fZBO0shSGNdCCfbLKlmG+vVwCw6Oa6F+9OavXUhkTwp/4MVn9mTGiXiYXXUSDkraH38XRVd2qWu3leo25SGrOTKVmqjOaJRDKS8tLHBts7Nleou8= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB2455.namprd06.prod.outlook.com (10.169.186.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.16; Wed, 9 Aug 2017 04:47:59 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.01.1320.018; Wed, 9 Aug 2017 04:47:59 +0000 From: Karen O'Donoghue To: "saag@ietf.org" Thread-Topic: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHTEMnCjue8Luaa4E6rvQH1AttmiA== Date: Wed, 9 Aug 2017 04:47:59 +0000 Message-ID: <2291590C-822A-4EB2-81E1-08D06A0C900A@isoc.org> References: <9D367122-EFFD-4C2E-9AE1-49FD5C694166@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=odonoghue@isoc.org; x-originating-ip: [24.245.108.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB2455; 6:78QKclIWMOpK6V7ui3DFr0nKjbgA0wP6Hu8s4PW/zRZIvwAR/Yx94DPXVbub0iilIc1yRtZFLrbk1d4V0it0BmxwLWtQuMeylmRe19G8AYM++aNz/DnNnw24+Z0dzYF9mRPL5uPRYv1wYGd9z5ufiHpHlZtcBilqdYneXLdTCmFnIMEFZWIBMU8xYYyB+oUYMkxJPKyaResAWyBOb+/zHyI8LWJQX5FzsAzjdZLAHSKfh2COqQxddG2ITeYGpCdnB7E8yp5z2kyclODUthMrExnB7uoviVE1BoIvq067wX1Aw97VxyGwjqYEayvYfx5wGRlrzMAw01KI/Lq3A/ty4A==; 5:9adoN1GKSdIPXd0LXODPG07eH8q5SQDBDNzZXyaavXPQaBa1pZ7nArtXFvrnDHTlZjAr+9CVNzVrgB2QqgqOukK6RHfpUfpxaipvIl4TlCpv4j2x6Ii+qaZOoB2Rd13eDL3aAQl/MsSX+6FiKROD/g==; 24:ph5q2eZqvGEsPGMoTaNhBEEpqGYenBsMvI0r5+9nzUfTrzigL3yfaMLEUReOzrZBUfl/VN4zKOkuwKhbIsCJs75MUYtprd2nKKvvlVp696c=; 7:bWDJ48O6laSoCVdcKUDSzwCegYvJDXyc7Eds3IYMJxYCjQHZFIvGVpOdR0kX3DEarhfcPEVMHntnwRtAQzS7yikcZaS7XJtyGWyG1FO9wY2zxEorQOJxfy42WYCD4g1+LEouhLm8hrfA1rTPu65xhMkvrZkZ32W+DP6kaOe5gT2uJfUwfg+sp4zVGUKefDT+3h0K1nOZD3yZQg8fow4vWTXgC0rqykM+ETuYqlLqaTk= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d0d2874b-7f55-4fbc-e120-08d4dee1cf81 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR06MB2455; x-ms-traffictypediagnostic: CY4PR06MB2455: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(100405760836317); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB2455; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB2455; x-forefront-prvs: 0394259C80 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39410400002)(39400400002)(39830400002)(377454003)(199003)(189002)(2900100001)(189998001)(6116002)(101416001)(97736004)(81166006)(99286003)(76176999)(36756003)(8936002)(8676002)(105586002)(54356999)(2351001)(5640700003)(66066001)(50986999)(54896002)(6436002)(2473003)(2501003)(966005)(3660700001)(53936002)(33656002)(83716003)(81156014)(1730700003)(3846002)(3280700002)(106356001)(478600001)(230783001)(6306002)(6512007)(606006)(110136004)(25786009)(82746002)(38730400002)(6916009)(229853002)(236005)(68736007)(5660300001)(86362001)(6506006)(102836003)(77096006)(2906002)(6486002)(14454004)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB2455; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_2291590C822A4EB281E108D06A0C900Aisocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2017 04:47:59.4923 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2455 Archived-At: Subject: [saag] Fwd: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 04:48:03 -0000 --_000_2291590C822A4EB281E108D06A0C900Aisocorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9sa3MsDQoNCknigJlkIGxpa2UgdG8gY2FsbCB0aGlzIFdHTEMgYW5ub3VuY2VtZW50IHRvIHRo ZSBhdHRlbnRpb24gb2YgdGhlIGJyb2FkZXIgc2VjdXJpdHkgY29tbXVuaXR5LiBDb21tZW50cyB3 ZWxjb21lLg0KDQpUaGFua3MsDQpLYXJlbg0KDQpCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCg0K RnJvbTogS2FyZW4gTydEb25vZ2h1ZSA8b2Rvbm9naHVlQGlzb2Mub3JnPG1haWx0bzpvZG9ub2do dWVAaXNvYy5vcmc+Pg0KU3ViamVjdDogW050cF0gV0dMQyBmb3IgZHJhZnQtaWV0Zi1udHAtdXNp bmctbnRzLWZvci1udHANCkRhdGU6IEF1Z3VzdCA5LCAyMDE3IGF0IDEyOjQxOjI1IEFNIEVEVA0K VG86ICJudHBAaWV0Zi5vcmc8bWFpbHRvOm50cEBpZXRmLm9yZz4iIDxudHBAaWV0Zi5vcmc8bWFp bHRvOm50cEBpZXRmLm9yZz4+DQpDYzogInRpY3RvY0BpZXRmLm9yZzxtYWlsdG86dGljdG9jQGll dGYub3JnPiIgPHRpY3RvY0BpZXRmLm9yZzxtYWlsdG86dGljdG9jQGlldGYub3JnPj4NCg0KRm9s a3MsDQoNClRoaXMgYmVnaW5zIGEgdGhyZWUgd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCAo V0dMQykgZm9yICJOZXR3b3JrIFRpbWUgU2VjdXJpdHkgZm9yIHRoZSBOZXR3b3JrIFRpbWUgUHJv dG9jb2zigJ0uDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt bnRwLXVzaW5nLW50cy1mb3ItbnRwLw0KDQpQbGVhc2UgcmV2aWV3IGFuZCBwcm92aWRlIGNvbW1l bnRzIHRvIHRoZSBtYWlsaW5nIGxpc3QgYnkgbm8gbGF0ZXIgdGhhbiAzMSBBdWd1c3QgMjAxNy4g RWFybGllciBjb21tZW50cyBhbmQgZGlzY3Vzc2lvbiB3b3VsZCBiZSBhcHByZWNpYXRlZC4gUGxl YXNlIG5vdGUgdGhhdCB0aGUgY2hhaXJzIHdpbGwgYmUgdXNpbmcgdGhpcyBXR0xDIHRvIGRldGVy bWluZSBjb25zZW5zdXMgdG8gbW92ZSB0aGlzIGRvY3VtZW50IGZvcndhcmQgdG8gdGhlIElFU0cu DQoNCkFsc28sIGFzIGEgcmVtaW5kZXIsIHdlIGhhdmUgbWlncmF0ZWQgdGhlIHdvcmtpbmcgZ3Jv dXAgbWFpbGluZyBsaXN0IHRvIElFVEYgaW5mcmFzdHJ1Y3R1cmUuIFBsZWFzZSByZXNwb25kIHRv IG50cEBpZXRmLm9yZy4gXQ0KDQpSZWdhcmRzLA0KS2FyZW4gYW5kIERpZXRlcg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm50cCBtYWlsaW5nIGxpc3QN Cm50cEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udHAN Cg0K --_000_2291590C822A4EB281E108D06A0C900Aisocorg_ Content-Type: text/html; charset="utf-8" Content-ID: <66889FF9C2C76D4A991F81463255FCDA@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRm9sa3MsDQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5J4oCZZCBsaWtlIHRvIGNhbGwg dGhpcyBXR0xDIGFubm91bmNlbWVudCB0byB0aGUgYXR0ZW50aW9uIG9mIHRoZSBicm9hZGVyIHNl Y3VyaXR5IGNvbW11bml0eS4gQ29tbWVudHMgd2VsY29tZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyw8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+S2FyZW48YnIgY2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5CZWdpbiBmb3J3YXJkZWQg bWVzc2FnZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tYm90 dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwg c2Fucy1zZXJpZjsgY29sb3I6cmdiYSgwLCAwLCAwLCAxLjApOyIgY2xhc3M9IiI+PGIgY2xhc3M9 IiI+RnJvbToNCjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5 c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+S2FyZW4gTydEb25vZ2h1ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9kb25vZ2h1ZUBpc29jLm9y ZyIgY2xhc3M9IiI+b2Rvbm9naHVlQGlzb2Mub3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8L3Nw YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1yaWdodDogMHB4 OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUs IEhlbHZldGljYSwgc2Fucy1zZXJpZjsgY29sb3I6cmdiYSgwLCAwLCAwLCAxLjApOyIgY2xhc3M9 IiI+PGIgY2xhc3M9IiI+U3ViamVjdDoNCjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+W050cF0gV0dMQyBmb3IgZHJhZnQtaWV0Zi1u dHAtdXNpbmctbnRzLWZvci1udHA8L2I+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRv bTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNh bnMtc2VyaWY7IGNvbG9yOnJnYmEoMCwgMCwgMCwgMS4wKTsiIGNsYXNzPSIiPjxiIGNsYXNzPSIi PkRhdGU6DQo8L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0 ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi PkF1Z3VzdCA5LCAyMDE3IGF0IDEyOjQxOjI1IEFNIEVEVDxiciBjbGFzcz0iIj4NCjwvc3Bhbj48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1h cmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVs dmV0aWNhLCBzYW5zLXNlcmlmOyBjb2xvcjpyZ2JhKDAsIDAsIDAsIDEuMCk7IiBjbGFzcz0iIj48 YiBjbGFzcz0iIj5UbzoNCjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Vi a2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm50cEBpZXRmLm9yZyIgY2xhc3M9IiI+bnRw QGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm50cEBpZXRmLm9yZyIgY2xh c3M9IiI+bnRwQGlldGYub3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tYm90 dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwg c2Fucy1zZXJpZjsgY29sb3I6cmdiYSgwLCAwLCAwLCAxLjApOyIgY2xhc3M9IiI+PGIgY2xhc3M9 IiI+Q2M6DQo8L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0 ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi PiZxdW90OzxhIGhyZWY9Im1haWx0bzp0aWN0b2NAaWV0Zi5vcmciIGNsYXNzPSIiPnRpY3RvY0Bp ZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0aWN0b2NAaWV0Zi5vcmciIGNs YXNzPSIiPnRpY3RvY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2 Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Rm9sa3MsPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhpcyBiZWdpbnMgYSB0aHJlZSB3ZWVrIHdvcmtp bmcgZ3JvdXAgbGFzdCBjYWxsIChXR0xDKSBmb3IgJnF1b3Q7TmV0d29yayBUaW1lIFNlY3VyaXR5 IGZvciB0aGUgTmV0d29yayBUaW1lIFByb3RvY29s4oCdLjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtbnRwLXVzaW5nLW50cy1mb3ItbnRwLyIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1udHAtdXNpbmctbnRzLWZvci1udHAvPC9hPjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NClBsZWFzZSByZXZpZXcgYW5kIHByb3ZpZGUgY29tbWVudHMg dG8gdGhlIG1haWxpbmcgbGlzdCBieSBubyBsYXRlciB0aGFuIDMxIEF1Z3VzdCAyMDE3LiBFYXJs aWVyIGNvbW1lbnRzIGFuZCBkaXNjdXNzaW9uIHdvdWxkIGJlIGFwcHJlY2lhdGVkLiBQbGVhc2Ug bm90ZSB0aGF0IHRoZSBjaGFpcnMgd2lsbCBiZSB1c2luZyB0aGlzIFdHTEMgdG8gZGV0ZXJtaW5l IGNvbnNlbnN1cyB0byBtb3ZlIHRoaXMgZG9jdW1lbnQgZm9yd2FyZCB0byB0aGUgSUVTRy4NCjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFsc28sIGFzIGEgcmVtaW5kZXIsIHdlIGhhdmUg bWlncmF0ZWQgdGhlIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IHRvIElFVEYgaW5mcmFzdHJ1 Y3R1cmUuIFBsZWFzZSByZXNwb25kIHRvIG50cEBpZXRmLm9yZy4gXTxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NClJlZ2FyZHMsPGJyIGNsYXNzPSIiPg0KS2FyZW4gYW5kIERpZXRlcjxiciBj bGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyIGNsYXNzPSIiPg0KbnRwIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCm50cEBpZXRmLm9y ZzxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnRw PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2291590C822A4EB281E108D06A0C900Aisocorg_-- From nobody Thu Aug 10 05:21:22 2017 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 E5CE6132656 for ; Thu, 10 Aug 2017 05:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVWrHPvLHjGs for ; Thu, 10 Aug 2017 05:21:19 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2A91132125 for ; Thu, 10 Aug 2017 05:21:18 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id 76so12003468ith.0 for ; Thu, 10 Aug 2017 05:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GXsgm45YEclD2wMyN8p1dlpUeA/Fd+HMVP6UHdMn2Fk=; b=W9K6IW7agP5E9C1CwVebXqDuDA6PXI5fnYxor0QLVYvDd33vGv81TaKOD9Wk0zQwgu 2ChvZ9qU8f8+KVnISHcQ+LY6jRLwXy107ji2VifaO/lq+m/pXKr6Vnd38chcwftzkS9G 8tpMmnj9QP38nQEbu1AO0TjVpOr4jlVtw7ocVO5iMQABW9rtT54xxbx9PtX/9tjlqrpD kV4DJWhR7IK/CsU11roLobN9vvUC8XfY9hzqRmbbqmiZ8ZvjT9B2kuvjpK2UE+ttN4sB DK9zKSift7g4xBGKOQESN2z3q1i281FSneJMPPNLUgkk4i+peG6Utb9KlijwrNAhoMBQ w9hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GXsgm45YEclD2wMyN8p1dlpUeA/Fd+HMVP6UHdMn2Fk=; b=QLp/uk2CP7QTf+qZcr4IYvCWeOh7MMdVv8hGVxVvIDh9sFxuhU0s9fb/ZHzDhMopiu vBPTjpRy5e4ktefbqwwp7Gefis2cIvwQOTsdkzxuY+mhBUMwWdMfkpUWKXpq1Bczkgv3 4dXM5A5mqY9gSMbsgWo2fi5l3DR9hYyaGIlsN+hs+dXExMcPCNxSubZBXfEhpuI3fKhI vOVMXClxB19nuho3vCBzpHIqEwNuQE4IDdw3BklSdlZe4L6cc0JfPdC6iIIhSudmNwnq PMzAb3eZRKldStt+vDtKR9SqRDdoWE4cObf1AFWq1YvWGQ+DOcNY24yTBTJNW5klwRTl Eeuw== X-Gm-Message-State: AIVw1111+pO++dHVltem8UlymaQNfijg4+d7YgyLcUpEA3lgui9tL3ow 0H6mb7k3JNziplVbMtUwOjrGHn0cGJlZ X-Received: by 10.36.40.147 with SMTP id h141mr4626428ith.85.1502367678299; Thu, 10 Aug 2017 05:21:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.222.86 with HTTP; Thu, 10 Aug 2017 05:21:17 -0700 (PDT) In-Reply-To: References: From: Brian Smith Date: Thu, 10 Aug 2017 02:21:17 -1000 Message-ID: To: Nikos Mavrogiannopoulos Cc: IETF SAAG Content-Type: multipart/alternative; boundary="001a113f67dcc9947e0556653b59" Archived-At: Subject: Re: [saag] storing validation parameters on PKCS#8 formatted private keys X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 12:21:21 -0000 --001a113f67dcc9947e0556653b59 Content-Type: text/plain; charset="UTF-8" Nikos Mavrogiannopoulos wrote: > Hi, > I've needed to store parameters related to FIPS-186-4 provable key > generation validation in a PKCS#8 private keys for RSA (can be used > for DSA too if anyone cares). I've described the PKCS#8 extension at: > http://nmav.gitlab.io/draft-mavrogiannopoulos-pkcs8-validated-parameters/ > > The approach followed was simple, store the validation parameters as > an attribute, something that allows the keys to be backwards > compatible. I'd appreciate comments on the approach. > This format only supports one private key generation method, and also requires (IIUC) that the proof be generated at the time the key was generated. Why not instead define an attribute for storing a primality certificate? A primality certificate can be generated after-the-fact and for any (IIUC) key generation algorithm. Cheers, Brian -- https://briansmith.org/ --001a113f67dcc9947e0556653b59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Niko= s Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com> wrote:
Hi,
=C2=A0I've needed to store parameters related to FIPS-186-4 provable ke= y
generation validation in a PKCS#8 private keys for RSA (can be used
for DSA too if anyone cares). I've described the PKCS#8 extension at: http://nmav.gitlab.io/draft= -mavrogiannopoulos-pkcs8-validated-parameters/

The approach followed was simple, store the validation parameters as
an attribute, something that allows the keys to be backwards
compatible. I'd appreciate comments on the approach.

This format only supports one private key generation meth= od, and also requires (IIUC) that the proof be generated at the time the ke= y was generated.

Why not instead define an attribu= te for storing a primality certificate? A primality certificate can be gene= rated after-the-fact and for any (IIUC) key generation algorithm.

Cheers,
Brian
--
--001a113f67dcc9947e0556653b59-- From nobody Thu Aug 10 05:54:30 2017 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 E58C5132198 for ; Thu, 10 Aug 2017 05:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkAxbaVFkxq4 for ; Thu, 10 Aug 2017 05:54:26 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61DB13218F for ; Thu, 10 Aug 2017 05:54:25 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id a77so3407284qkb.0 for ; Thu, 10 Aug 2017 05:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uXPmjijM3ECeIf5qhWdj9fiurVXg2aaGVJPiSJdtJtM=; b=jexe8kxuvdnssggRpx7MAKL9WxAr6jSdk1FebZc085Yls/DmfpvieVNTn4R7Yz5+Z5 1saPrmG7sNxQIX2fQjXoCf1jvpsDM6njGCqaUMRWhy7TL5DDr4MMrx8Kun7t+hdPvy5L 0BBraQ8ljRCiyj7v0QN1Q7ZawVeJyPIdn5/oYmZKkRStfV9biIvb1jcQmPb46oJ8voNI dpeCyUwZ/pX4NQW3nbxsx2qVxcqJKyvSIQl9XGRgaphAkzlXWXfoV03+/5udkT9dAlUf qIlxazytMEEVW5c2U9cSiiu9/AIvFdIWHwxOA/NlOxtz5wwIIS+x599CUR+1pxgz3+Ps FylQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uXPmjijM3ECeIf5qhWdj9fiurVXg2aaGVJPiSJdtJtM=; b=M0jNffQEZOkPWu6634/4sCRnkEmGh2B8+pxyKi9wVhzQHprkssWOgt7cbaRdYz9scb jg4wQF9ajWdMQyNvcOUfkjgfE/ICIiNdZswWyx5VWGz94IiZ57MbqwhmM3RAgGBqctWY 6vZVVcdhwu+PvbtS/cf6mgSm9VwCi5MZOFMwplC8w+ux6qRFkCv2VctlI6XlIDWXW/5h REbnuZfV6ZEUj2cdxIPDglQmQ8q/jCxLCJSXfJkGKwg0wasMA8Tz7Z3fxWG+cr7BQE3a v8CAcMz/T3RLF0tCDeAmDFHgD39JIxSYFY2msTc1MIBI2mv7Lo92xsSCau1sLBB13KJu YAag== X-Gm-Message-State: AHYfb5g97wW33H1M5jaU4qy2g/FfJUX+DFsc3wCE9gZ3npcvot+ll4e/ uSsPZ10y5IrDOZTuWP9HLOTxlUI9d7f6tfI= X-Received: by 10.55.110.196 with SMTP id j187mr13224296qkc.128.1502369664840; Thu, 10 Aug 2017 05:54:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.175.235 with HTTP; Thu, 10 Aug 2017 05:53:44 -0700 (PDT) In-Reply-To: References: From: Nikos Mavrogiannopoulos Date: Thu, 10 Aug 2017 14:53:44 +0200 Message-ID: To: Brian Smith Cc: IETF SAAG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] storing validation parameters on PKCS#8 formatted private keys X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 12:54:28 -0000 On Thu, Aug 10, 2017 at 2:21 PM, Brian Smith wrote: > Nikos Mavrogiannopoulos wrote: >> >> Hi, >> I've needed to store parameters related to FIPS-186-4 provable key >> generation validation in a PKCS#8 private keys for RSA (can be used >> for DSA too if anyone cares). I've described the PKCS#8 extension at: >> http://nmav.gitlab.io/draft-mavrogiannopoulos-pkcs8-validated-parameters/ >> >> The approach followed was simple, store the validation parameters as >> an attribute, something that allows the keys to be backwards >> compatible. I'd appreciate comments on the approach. > > > This format only supports one private key generation method, and also > requires (IIUC) that the proof be generated at the time the key was > generated. > > Why not instead define an attribute for storing a primality certificate? A > primality certificate can be generated after-the-fact and for any (IIUC) key > generation algorithm. That's an interesting question. The algorithm's parameters above are part of the key generation process and thus makes quite some sense to store them with the private key. However, a primality certificate as you mentioned is typically generated after the fact, there are multiple methods for it, and all of them involve a very long process (which would also make key generation process longer if you'd like to store them with the key), while they often produce several megabytes of output. Ignoring all that, I am still not sure what would a primality certificate buy attached to a private key. The FIPS186-4 Shawe-Taylor process on the other hand gives you not only an assurance that numbers are prime, but that they were generated from the specific seed, with the specific hash. On the other hand, I see primality certificates being more suitable for DH parameters, and in fact more suitable for being companions to RFCs defining such parameters. Though even then, they only guarantee primality, not that some particular process was followed when generating them. Don't take me wrong, I have nothing against primality certificates, and I'd be happy to assign an OID for storing them if you have a use for them. regards, Nikos From nobody Tue Aug 15 00:08:24 2017 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 5BBAF132511 for ; Tue, 15 Aug 2017 00:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 934paoxOQnrM for ; Tue, 15 Aug 2017 00:08:19 -0700 (PDT) Received: from lb1-smtp-cloud7.xs4all.net (lb1-smtp-cloud7.xs4all.net [194.109.24.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7976F132513 for ; Tue, 15 Aug 2017 00:08:16 -0700 (PDT) Received: from airhead.local ([IPv6:2001:980:93a5:1:292e:13c1:776d:d434]) by smtp-cloud7.xs4all.net with ESMTPSA id hVxUdKURYAr7rhVxWd4ffr; Tue, 15 Aug 2017 09:08:14 +0200 Message-ID: <59929DDC.2000407@openfortress.nl> Date: Tue, 15 Aug 2017 09:08:12 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: saag@ietf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfEySYfIJhBxHraINv3AmxWgVfKG3EeXiPRvnd9j6m+DjhqwLKyse0qMdjuILoHgVyqJYTxFZK60epRwE42/z6Gw6akJj5KfDw3e0fbZwb2432HZNWX8L vC70H6XtuKX2MQfZ7BVhoy54bcDZAbiNFRygU8gG/hCwIA2UTb0WkgC0ixv3fZyxiMC/Y3ITchW82z8uYnHnueMDTz5ukeEUeVjrL51HyoVLBK5TudJgfIK5 jEuOv6T91xE5CXZxX+UmmHBEcp48ZoqRQEWE36LKpUo= Archived-At: Subject: [saag] Where-to I-Ds: HTTP Auth with SASL, EAP method for SASL X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 07:08:23 -0000 Hello SAAG, I have just posted two I-Ds and am looking where to send them, since the HTTP Auth WG and EAP WG have both been concluded. Could you advise me? https://datatracker.ietf.org/doc/draft-vanrein-httpauth-sasl/ This one explains how SASL can be used as an HTTP Auth mechanism. This turns out to be beneficial for SASL as well as HTTP. https://datatracker.ietf.org/doc/draft-vanrein-eap-sasl/ This one allows the various front-ends that use SASL to relay the interaction to a backend over EAP, which in turn might be carried over Diameter or RADIUS. I was advised to ask for directions here, so if you have suggestions than I would love to hear them. FYI, EAP requires a specification and an expert review, so it could be an independent submission. I currently think that would be best. And, HTTP Auth through SASL registers an Authentication Scheme, for which IETF Review is the standard. Thank you, Rick van Rein InternetWide.org / ARPA2.net / OpenFortress.nl From nobody Fri Aug 18 14:28:29 2017 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 3D5C31323A5 for ; Fri, 18 Aug 2017 14:28:28 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3cX8awQBeJJ for ; Fri, 18 Aug 2017 14:28:26 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8465313228D for ; Fri, 18 Aug 2017 14:28:26 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id u207so66110858ywc.3 for ; Fri, 18 Aug 2017 14:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=YyULZJ4P4oJ6ERepaRJfguAq3lMTfw5T09bIoU5lcCs=; b=B3n5OKXgG3PfUoTClzcAIN0rb94wjz1Hhvjrs72+qbeot9MB+qaKlB9UxSiKVJaW7/ hKw0spkjFVes3RWQVXsJ6RC66RTZvHGARaWUL9ZBdGzxpik4JW8uI+UuwrVb30cHH/HW T3/XbVQu6lrYcwMSTwbxXYV1Irck09/V2uBykrY054FaLu2GddHxfuD/i3S6GP8I9Xze LZxAvnO9D2KqQpEEAdPajGw4rpIDccG8Bjo8BHtCK82UfS/tLx37ZSIel0Qxqs1Do2ro aD/YwLVuvxwV6hyrYR4mLk1cfWeyk747+STXcG8yorJqzCB25ldnlT7THJmoEqg7RTf7 Iqkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YyULZJ4P4oJ6ERepaRJfguAq3lMTfw5T09bIoU5lcCs=; b=mni/RWlO+38e5elhBqgZoVWY2VFBClj58Z/BTyMQU5Y6rM5WD3BiE8x/bLiSH9hkp9 V3Giq3hO5M1A1YBr7ieLSLvv4yjW2DOgllfv34Wpt5dBeuqn1H424KiqwdMMuaQQKRw1 Je4fv7JfxilNdOz5oy8rRSCroMDmpKJBVAqKq3iEV3w+FfUilyrTdahjaqdJEqpb3tYG 66mGgcW3V4aIv7QPXFpBacSfc75NAVtg0pmLJjgvQD4vymKGdFWji0KKxk9CClvsoHJo hNW5caUawcWGyCAfD6KHf7Xg1STKdXasnhLYBV0pcVDu6d3NkDTxfPybsnHPq6L/EfgF KiHw== X-Gm-Message-State: AHYfb5jbn99zVKZZeL3MUS1u7RGgtcxkTWwTcXDrc1v/OoGJtnj+oCPW VmfdB/A26VdcpOvzOwSRnK+9Z+tuw1s0zE2a7w== X-Received: by 10.37.56.12 with SMTP id f12mr8922945yba.289.1503091705510; Fri, 18 Aug 2017 14:28:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Fri, 18 Aug 2017 14:27:44 -0700 (PDT) From: Eric Rescorla Date: Fri, 18 Aug 2017 14:27:44 -0700 Message-ID: To: "saag@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c03e4c22c182505570dcf11" Archived-At: Subject: [saag] PSA: SECDISPATCH Experiment for SAAG in Singapore X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 21:28:28 -0000 --94eb2c03e4c22c182505570dcf11 Content-Type: text/plain; charset="UTF-8" We (Kathleen and EKR) are investigating starting up a DISPATCH-style process for SEC (tentatively named SECDISPATCH). Rather than just charter it, we're going to try running it once as an experiment in Singapore at the end of the SAAG session with Russ Housley and Nancy Cam-Winget serving as chairs. If that goes well, we'll look into chartering an actual WG for London [0]. When asking for meeting time, please specify whether you wish to present at SAAG or SECDISPATCH. Presentations which are appropriate for SAAG are those of general interest, awareness, etc. Proposals for new work should be presented at SECDISPATCH Thanks, -EKR and Kathleen [0] Prototype Charter Charter for Working Group The Security Dispatch working group is chartered to consider proposals for new work in the SEC area and identify, or help create, an appropriate venue for the work. Guiding principles for the proposed new work include: 1. Providing a clear problem statement, motivation and deliverables for the proposed new work. 2. Ensuring there has been adequate mailing list discussion reflecting sufficient interest, individuals have expressed a willingness to contribute and there is WG consensus before new work is dispatched. 3. Looking for and identifying commonalities and overlap amongst published or ongoing protocol work. Such commonalities may indicate the possibility of reusing existing protocols or elements thereof published by other WGs, or expanding and/or refactoring the scope of deliverables in an active WG. 4. Protecting the architectural integrity of IETF protocols. Ensuring sufficient interest in the new work. 5. Ensuring that the new work considers and seeks to improve security and privacy. Options for handling new work include: - Directing the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter for a new WG. - Making recommendations that documents be AD-sponsored (which ADs may or may not choose to follow). - By agreement with SEC ADs, processing simple administrative documents (such as code point assignments) - Deferring the decision for the new work. - Rejecting the new work. If the group decides that a particular topic needs to be addressed by a new WG, the normal IETF chartering process will be followed, including, for instance, IETF-wide review of the proposed charter. Proposals for large work efforts SHOULD lead to a BOF where the topic can be discussed in front of the entire IETF community. The SECDISPATCH WG will not do any protocol work. Specifically, SECDISPATCH will always opt to find a location for technical work; the only work that SECDISPATCH is not required to delegate (or defer, or reject) is administrative work such as IANA actions. Documents progressed as AD-sponsored would typically include those that do not have general applicability to IETF protocols, but rather are only applicable to specific use cases and network deployments, for which the scope must be clearly specified. --94eb2c03e4c22c182505570dcf11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We (Kathleen and EKR) are investigating starting up a= DISPATCH-style
process for SEC (tentatively named SECDISPATCH).<= /div>

Rather than just charter it, we're going to tr= y running it once as an
experiment in Singapore at the end of the= SAAG session with Russ
Housley and Nancy Cam-Winget serving as c= hairs. If that goes well,
we'll look into chartering an actua= l WG for London [0].

When asking for meeting time,= please specify whether you wish to
present at SAAG or SECDISPATC= H. Presentations which are appropriate
for SAAG are those of gene= ral interest, awareness, etc. Proposals for
new work should be pr= esented at SECDISPATCH

Thanks,
-EKR and = Kathleen


[0] Prototype Charter

Charter for Working Group

The= Security Dispatch working group is chartered to consider proposals
for new work in the SEC area and identify, or help create, an
= appropriate venue for the work. Guiding principles for the proposed
new work include:

1. Providing a clear problem = statement, motivation and deliverables
for the proposed new work.=

2. Ensuring there has been adequate mailing list = discussion reflecting
sufficient interest, individuals have expre= ssed a willingness to
contribute and there is WG consensus before= new work is dispatched.

3. Looking for and identi= fying commonalities and overlap amongst
published or ongoing prot= ocol work. Such commonalities may indicate
the possibility of reu= sing existing protocols or elements thereof
published by other WG= s, or expanding and/or refactoring the scope of
deliverables in a= n active WG.

4. Protecting the architectural integ= rity of IETF protocols. Ensuring
sufficient interest in the new w= ork.
=C2=A0
5. Ensuring that the new work considers and= seeks to improve security
and privacy.

=
Options for handling new work include:

<= div>- Directing the work to an existing WG.
- Developing a propos= al for a BOF.
- Developing a charter for a new WG.
- Ma= king recommendations that documents be AD-sponsored (which ADs may
=C2=A0 or may not choose to follow).
- By agreement with SEC AD= s, processing simple administrative
=C2=A0 documents (such as cod= e point assignments)
- Deferring the decision for the new work.
- Rejecting the new work.


= If the group decides that a particular topic needs to be addressed by
=
a new WG, the normal IETF chartering process will be followed,
including, for instance, IETF-wide review of the proposed
char= ter. Proposals for large work efforts SHOULD lead to a BOF where
= the topic can be discussed in front of the entire IETF community. The
=
SECDISPATCH WG will not do any protocol work. Specifically,
= SECDISPATCH will always opt to find a location for technical work; the
only work that SECDISPATCH is not required to delegate (or defer, or<= /div>
reject) is administrative work such as IANA actions. Documents
progressed as AD-sponsored would typically include those that do no= t
have general applicability to IETF protocols, but rather are on= ly
applicable to specific use cases and network deployments, for = which
the scope must be clearly specified.

--94eb2c03e4c22c182505570dcf11-- From nobody Fri Aug 18 17:07:27 2017 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 0585F13239D for ; Fri, 18 Aug 2017 17:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ruy6mXOxmoOa for ; Fri, 18 Aug 2017 17:07:23 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B145131D19 for ; Fri, 18 Aug 2017 17:07:23 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01D31844.7167B0E0" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1503101210; h=from:subject:to:date:message-id; bh=5BkpZ4YxnEUX/ZgrOeCVp8BmvHT1F1+mmoCwEJG27i4=; b=kQfMHNCBRrqqnwmO1sGK26veGAGSX/8FA1dkoKX9sMW1zsyNJi8lHGzT+NyjYP/Qzll6e44gn+y qsxVih8g/4L8s+w7akSTNPCMU50bMeTQ8caeCdtabsnO7hXQ4f2yGU1Pe+Trh29bvVz3mXXDMOPsa LOIlDuddCvLn9QtOjDGREJh/VRcYIFzoTmZwYfe76je1YilFWy2qyoclzrgdZ5HzVppqG0+sWr4aK c50nFGCzMh9gRMVpizCa/njU9QpOhupwwe0IKfSZcqnJNXMve3iS7bGOMiP4rdwEo7qtVUWoGpyuT WNpS2kCyBc6AYw2ErMP2Ims2TNJ/MFvPvKNg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 18 Aug 2017 17:06:49 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 18 Aug 2017 17:06:48 -0700 From: Jim Schaad To: 'Eric Rescorla' , References: In-Reply-To: Date: Fri, 18 Aug 2017 17:07:13 -0700 Message-ID: <006601d3187f$1dc57770$59506650$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQF+FXE4RwFXcz8G0UN0qJQ+SzI8J6M00zhg X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [saag] PSA: SECDISPATCH Experiment for SAAG in Singapore X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 00:07:26 -0000 ------=_NextPart_000_0067_01D31844.7167B0E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Is there a mailing list or is thing going to use the SAAG mailing list? Jim From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Friday, August 18, 2017 2:28 PM To: saag@ietf.org Subject: [saag] PSA: SECDISPATCH Experiment for SAAG in Singapore We (Kathleen and EKR) are investigating starting up a DISPATCH-style process for SEC (tentatively named SECDISPATCH). Rather than just charter it, we're going to try running it once as an experiment in Singapore at the end of the SAAG session with Russ Housley and Nancy Cam-Winget serving as chairs. If that goes well, we'll look into chartering an actual WG for London [0]. When asking for meeting time, please specify whether you wish to present at SAAG or SECDISPATCH. Presentations which are appropriate for SAAG are those of general interest, awareness, etc. Proposals for new work should be presented at SECDISPATCH Thanks, -EKR and Kathleen [0] Prototype Charter Charter for Working Group The Security Dispatch working group is chartered to consider proposals for new work in the SEC area and identify, or help create, an appropriate venue for the work. Guiding principles for the proposed new work include: 1. Providing a clear problem statement, motivation and deliverables for the proposed new work. 2. Ensuring there has been adequate mailing list discussion reflecting sufficient interest, individuals have expressed a willingness to contribute and there is WG consensus before new work is dispatched. 3. Looking for and identifying commonalities and overlap amongst published or ongoing protocol work. Such commonalities may indicate the possibility of reusing existing protocols or elements thereof published by other WGs, or expanding and/or refactoring the scope of deliverables in an active WG. 4. Protecting the architectural integrity of IETF protocols. Ensuring sufficient interest in the new work. 5. Ensuring that the new work considers and seeks to improve security and privacy. Options for handling new work include: - Directing the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter for a new WG. - Making recommendations that documents be AD-sponsored (which ADs may or may not choose to follow). - By agreement with SEC ADs, processing simple administrative documents (such as code point assignments) - Deferring the decision for the new work. - Rejecting the new work. If the group decides that a particular topic needs to be addressed by a new WG, the normal IETF chartering process will be followed, including, for instance, IETF-wide review of the proposed charter. Proposals for large work efforts SHOULD lead to a BOF where the topic can be discussed in front of the entire IETF community. The SECDISPATCH WG will not do any protocol work. Specifically, SECDISPATCH will always opt to find a location for technical work; the only work that SECDISPATCH is not required to delegate (or defer, or reject) is administrative work such as IANA actions. Documents progressed as AD-sponsored would typically include those that do not have general applicability to IETF protocols, but rather are only applicable to specific use cases and network deployments, for which the scope must be clearly specified. ------=_NextPart_000_0067_01D31844.7167B0E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Is there a mailing list or is thing going to use the = SAAG mailing list?

 

Jim

 

 

From: saag = [mailto:saag-bounces@ietf.org] On Behalf Of Eric = Rescorla
Sent: Friday, August 18, 2017 2:28 PM
To: = saag@ietf.org
Subject: [saag] PSA: SECDISPATCH Experiment for = SAAG in Singapore

 

We = (Kathleen and EKR) are investigating starting up a = DISPATCH-style

process for = SEC (tentatively named SECDISPATCH).

 

Rather than just charter it, we're going to try = running it once as an

experiment in Singapore at the end of the SAAG session = with Russ

Housley and = Nancy Cam-Winget serving as chairs. If that goes = well,

we'll look into = chartering an actual WG for London [0].

 

When asking for meeting time, please specify whether = you wish to

present at = SAAG or SECDISPATCH. Presentations which are = appropriate

for SAAG are = those of general interest, awareness, etc. Proposals = for

new work should be = presented at SECDISPATCH

 

Thanks,

-EKR and Kathleen

 

 

[0] Prototype Charter

 

Charter for Working Group

 

The Security Dispatch working group is chartered to = consider proposals

for new = work in the SEC area and identify, or help create, = an

appropriate venue for = the work. Guiding principles for the = proposed

new work = include:

 

1. Providing a clear problem statement, motivation and = deliverables

for the = proposed new work.

 

2. Ensuring there has been adequate mailing list = discussion reflecting

sufficient interest, individuals have expressed a = willingness to

contribute = and there is WG consensus before new work is = dispatched.

 

3. Looking for and identifying commonalities and = overlap amongst

published = or ongoing protocol work. Such commonalities may = indicate

the possibility = of reusing existing protocols or elements = thereof

published by other = WGs, or expanding and/or refactoring the scope = of

deliverables in an = active WG.

 

4. Protecting the architectural integrity of IETF = protocols. Ensuring

sufficient interest in the new = work.

 

5. Ensuring that the new work considers and seeks to = improve security

and = privacy.

 

 

Options for handling new work = include:

 

- = Directing the work to an existing WG.

- Developing a proposal for a = BOF.

- Developing a = charter for a new WG.

- = Making recommendations that documents be AD-sponsored (which ADs = may

  or may not = choose to follow).

- By = agreement with SEC ADs, processing simple = administrative

  = documents (such as code point assignments)

- Deferring the decision for the new = work.

- Rejecting the new = work.

 

 

If the group decides that a particular topic needs to = be addressed by

a new WG, = the normal IETF chartering process will be = followed,

including, for = instance, IETF-wide review of the proposed

charter. Proposals for large work efforts SHOULD lead = to a BOF where

the topic = can be discussed in front of the entire IETF community. = The

SECDISPATCH WG will = not do any protocol work. Specifically,

SECDISPATCH will always opt to find a location for = technical work; the

only = work that SECDISPATCH is not required to delegate (or defer, = or

reject) is = administrative work such as IANA actions. = Documents

progressed as = AD-sponsored would typically include those that do = not

have general = applicability to IETF protocols, but rather are = only

applicable to = specific use cases and network deployments, for = which

the scope must be = clearly specified.

 

------=_NextPart_000_0067_01D31844.7167B0E0-- From nobody Sat Aug 19 03:53:20 2017 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 BBE4913243A for ; Sat, 19 Aug 2017 03:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rzy1um9w8ENt for ; Sat, 19 Aug 2017 03:53:16 -0700 (PDT) Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ADC813235C for ; Sat, 19 Aug 2017 03:53:16 -0700 (PDT) Received: by mail-qk0-x242.google.com with SMTP id x77so10794586qka.4 for ; Sat, 19 Aug 2017 03:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fye/mk+IBI69DeFEHp1d5mRAucAZ3QdO3gyjS33GlWw=; b=ue0yBFGf0U9Z0gJ/3pTzUTdelZ1moeT6pJqVJulR3bF+EmurRtm1xJAy7xr6vcHHDG vW9gjaHg1QQeX5b2yn2i0oD/HG+lIl5T/l5ZjsZPjr5l79YY9fyFYQyz/Vj2Cpd5XEk1 uRxFLtBfzjEyP9x7GMBN2KgSke8mhgZM05EmMojcP90n2A5hD6knjEabNXTeYex7Ocqv C6vqlJfhY9vdRVVf6u5uenAcHj+54NBiCoDLo1QQUFFPKiZ+Jos0TxD3pSIL5SQtb8YD aR/ZEYliOvWbDiGmERLGxJj7fHnuNRHpWP9j8XG5aOFDp4GwuRazYw2kWXM1ntAI2E9m dCIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fye/mk+IBI69DeFEHp1d5mRAucAZ3QdO3gyjS33GlWw=; b=qTMroG+udD7QVoneTIb/2VX5NgDzUC6S8FhmUoRrxSB5Sv5ufGJjqCz0qMtAdyQX2p mTNC6FLs9j+SFcRtLPSQ7DoFoSyxySXNXm5XfqfOPwqGd3yHzCOdJsmWnWnf83TW0XGF M1u4p/3jT80PcVbzYyMmTLdYeUSkxFeVAeLNE3yOGUwGWSEk2gRlBcD6LDbCUZDrOkrb N6y7TS+pHfLxivnbotk2e5n43ajpApvC3yN+dOqewz7wxobMLQX7GoAaG9hnOs4eucb0 Jpv2KVCUSxhGXbOuyZ0PVGHSAzPGtXkL2KqiCXO4AfNQ1Bc3ZEsSg+6lrVXGzYe4h8pB HjTQ== X-Gm-Message-State: AHYfb5iHPq6TxcdBbiGuYbq6SgVwCiVe4RQQZhR++6t+1a4JH5eA8hVI 31QOEumli7E2BnFX6a4= X-Received: by 10.55.188.134 with SMTP id m128mr16058162qkf.233.1503139995008; Sat, 19 Aug 2017 03:53:15 -0700 (PDT) Received: from [192.168.1.13] (209-6-124-204.s3530.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id l202sm4415278qke.60.2017.08.19.03.53.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Aug 2017 03:53:13 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-60576751-1911-45F1-BF83-867EA8D74E9F Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: <006601d3187f$1dc57770$59506650$@augustcellars.com> Date: Sat, 19 Aug 2017 06:53:13 -0400 Cc: Eric Rescorla , saag@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <7477BD29-C107-4B90-966E-78D3B3E0A697@gmail.com> References: <006601d3187f$1dc57770$59506650$@augustcellars.com> To: Jim Schaad Archived-At: Subject: Re: [saag] PSA: SECDISPATCH Experiment for SAAG in Singapore X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 10:53:19 -0000 --Apple-Mail-60576751-1911-45F1-BF83-867EA8D74E9F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable SAAG for now as that's what we've used to discuss drafts without a home to d= ate. If all goes well, we'll settle on a name and set up a list. Thank you, Kathleen=20 Sent from my iPhone > On Aug 18, 2017, at 8:07 PM, Jim Schaad wrote: >=20 > Is there a mailing list or is thing going to use the SAAG mailing list? > =20 > Jim > =20 > =20 > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Eric Rescorla > Sent: Friday, August 18, 2017 2:28 PM > To: saag@ietf.org > Subject: [saag] PSA: SECDISPATCH Experiment for SAAG in Singapore > =20 > We (Kathleen and EKR) are investigating starting up a DISPATCH-style > process for SEC (tentatively named SECDISPATCH). > =20 > Rather than just charter it, we're going to try running it once as an > experiment in Singapore at the end of the SAAG session with Russ > Housley and Nancy Cam-Winget serving as chairs. If that goes well, > we'll look into chartering an actual WG for London [0]. > =20 > When asking for meeting time, please specify whether you wish to > present at SAAG or SECDISPATCH. Presentations which are appropriate > for SAAG are those of general interest, awareness, etc. Proposals for > new work should be presented at SECDISPATCH > =20 > Thanks, > -EKR and Kathleen > =20 > =20 > [0] Prototype Charter > =20 > Charter for Working Group > =20 > The Security Dispatch working group is chartered to consider proposals > for new work in the SEC area and identify, or help create, an > appropriate venue for the work. Guiding principles for the proposed > new work include: > =20 > 1. Providing a clear problem statement, motivation and deliverables > for the proposed new work. > =20 > 2. Ensuring there has been adequate mailing list discussion reflecting > sufficient interest, individuals have expressed a willingness to > contribute and there is WG consensus before new work is dispatched. > =20 > 3. Looking for and identifying commonalities and overlap amongst > published or ongoing protocol work. Such commonalities may indicate > the possibility of reusing existing protocols or elements thereof > published by other WGs, or expanding and/or refactoring the scope of > deliverables in an active WG. > =20 > 4. Protecting the architectural integrity of IETF protocols. Ensuring > sufficient interest in the new work. > =20 > 5. Ensuring that the new work considers and seeks to improve security > and privacy. > =20 > =20 > Options for handling new work include: > =20 > - Directing the work to an existing WG. > - Developing a proposal for a BOF. > - Developing a charter for a new WG. > - Making recommendations that documents be AD-sponsored (which ADs may > or may not choose to follow). > - By agreement with SEC ADs, processing simple administrative > documents (such as code point assignments) > - Deferring the decision for the new work. > - Rejecting the new work. > =20 > =20 > If the group decides that a particular topic needs to be addressed by > a new WG, the normal IETF chartering process will be followed, > including, for instance, IETF-wide review of the proposed > charter. Proposals for large work efforts SHOULD lead to a BOF where > the topic can be discussed in front of the entire IETF community. The > SECDISPATCH WG will not do any protocol work. Specifically, > SECDISPATCH will always opt to find a location for technical work; the > only work that SECDISPATCH is not required to delegate (or defer, or > reject) is administrative work such as IANA actions. Documents > progressed as AD-sponsored would typically include those that do not > have general applicability to IETF protocols, but rather are only > applicable to specific use cases and network deployments, for which > the scope must be clearly specified. > =20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail-60576751-1911-45F1-BF83-867EA8D74E9F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
SAAG for now as that's what we've used= to discuss drafts without a home to date.  If all goes well, we'll set= tle on a name and set up a list.

Thank you,
Kathleen 

Sent from my iPhone

On Aug 18, 2017= , at 8:07 PM, Jim Schaad <ietf@= augustcellars.com> wrote:

Is there a mailing list or is thing going to use the SAAG mailing l= ist?

 

Jim

 

 

From: saag [mailto:saa= g-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Fri= day, August 18, 2017 2:28 PM
To: = saag@ietf.org
Subject: [saag] PSA: SECDISPATCH Experiment for S= AAG in Singapore

 = ;

We (Kathleen and EKR) are invest= igating starting up a DISPATCH-style

process for SEC (tentatively named SECDISPATCH).

 

Rather than just charter it, we're going to try running it once as a= n

experiment in Singapore at= the end of the SAAG session with Russ

Housley and Nancy Cam-Winget serving as chairs. If that goes well= ,

we'll look into chartering= an actual WG for London [0].

 

When asking for mee= ting time, please specify whether you wish to

present at SAAG or SECDISPATCH. Presentations which are ap= propriate

for SAAG are those= of general interest, awareness, etc. Proposals for

new work should be presented at SECDISPATCH

 

Thanks,

-= EKR and Kathleen

 =

 

=

[0] Prototype Charter

 

Char= ter for Working Group

&= nbsp;

The Security Dispatch worki= ng group is chartered to consider proposals

for new work in the SEC area and identify, or help create, a= n

appropriate venue for the w= ork. Guiding principles for the proposed

new work include:

 

1. Providing a clea= r problem statement, motivation and deliverables

for the proposed new work.

 

2.= Ensuring there has been adequate mailing list discussion reflecting

sufficient interest, individuals ha= ve expressed a willingness to

contribute and there is WG consensus before new work is dispatched.

 

3. Looking for and identifying commonalities and overla= p amongst

published or ongoi= ng protocol work. Such commonalities may indicate

<= p class=3D"MsoNormal">the possibility of reusing existing protocols or eleme= nts thereof

published by oth= er WGs, or expanding and/or refactoring the scope of

deliverables in an active WG.

<= div>

 

4. Protecting the architectural integrity of IETF protocols. Ensuring<= o:p>

sufficient interest in the n= ew work.

 

5. Ensuring that the new work considers a= nd seeks to improve security

and privacy.

 

 

Options for handling new work include:

 

- Directing the work to an existing WG.

- Developing a proposal for a BOF.

=

- Developing a charter for a new WG.<= /p>

- Making recommendations that documents= be AD-sponsored (which ADs may

  or may not choose to follow).

- By agreement with SEC ADs, processing simple administrative

  documents (such as code= point assignments)

- Deferr= ing the decision for the new work.

- Rejecting the new work.

 

 

If the group decides that a particula= r topic needs to be addressed by

a new WG, the normal IETF chartering process will be followed,

including, for instance, IETF-wide r= eview of the proposed

charte= r. Proposals for large work efforts SHOULD lead to a BOF where

the topic can be discussed in front of th= e entire IETF community. The

SECDISPATCH WG will not do any protocol work. Specifically,

<= /div>

SECDISPATCH will always opt to find a locat= ion for technical work; the

= only work that SECDISPATCH is not required to delegate (or defer, or

reject) is administrative work such= as IANA actions. Documents

= progressed as AD-sponsored would typically include those that do not

have general applicability to IETF p= rotocols, but rather are only

applicable to specific use cases and network deployments, for which

the scope must be clearly specifie= d.

 

= _______________________________________________
saag mailing= list
saag@ietf.org
https://= www.ietf.org/mailman/listinfo/saag
<= /html>= --Apple-Mail-60576751-1911-45F1-BF83-867EA8D74E9F--