From nobody Tue Oct 1 08:22:56 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDE9120872 for ; Tue, 1 Oct 2019 08:22:54 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=entrustdatacardcorp.onmicrosoft.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 ncf_NB7Ow1km for ; Tue, 1 Oct 2019 08:22:52 -0700 (PDT) Received: from mx1.entrustdatacard.com (mx1.entrustdatacard.com [204.124.80.220]) (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 D5FC512089D for ; Tue, 1 Oct 2019 08:22:51 -0700 (PDT) IronPort-SDR: dRs/hWvnwkFqHtocHJlRf6+W/dJQE+02mZYs9JCB5ATNFfBiWstw77k2ZIZemGiYMvqu8Fa36X fHvwifDrl+jA== X-IronPort-AV: E=Sophos;i="5.64,571,1559538000"; d="scan'208";a="58266495" Received: from pmspex02.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.30]) by pmspesa03inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 01 Oct 2019 10:22:50 -0500 Received: from PMSPEX05.corporate.datacard.com (192.168.211.52) by pmspex02.corporate.datacard.com (192.168.211.30) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 1 Oct 2019 10:22:50 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (172.28.1.8) by PMSPEX05.corporate.datacard.com (192.168.211.52) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 1 Oct 2019 10:22:50 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n3UGSlz4vGuXmG5si4GkIPPJdCXPrDHyFySti9XSouza8ObqVeWlgceTxsOx4/bv0xj/DUOc+fCIBqdcN/c7K7F6pwiUisS9S+/INxEsmdrwcrrIputWQdy+l0tnXKY8f2ZUh4ONrgyiWuc7IkdSOyiqsqLkqTN2VDQr6XcgK/EXIrxBQNIAta4PpweKNNitwctSO01f+YYUtc3+M6n3fxxIYdO0p3jbvC01Ax5vSkyyGqTv4Bw7JS+7oZlAQD3A9v5bDqpxMft7MbImaAmogCWlExJWzIjholcg+vQUo8tPJ5ao05tYTvbH/io/8D/DLnCRrVXOFLy3nrY7KjXCFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YetR+pqTvDYiBh+nJocK7Wxzr24m7ubHKN/1gpu3Sbw=; b=JqyQYDMe5LcAbYvlR4ibxl2eSXQKrto0gfhzIlOXY39WBaKyoSrpLwftmE+cs1rwFAbjgkYxD//rgCvQqixmgxVPHdo+NQHCceRQT7RlCzPYP5my7JNrPfCPWMALtoINJbOCPBuFziXnXM20RSkkDkRG1YN2Jd4kzvELAIN0uXpiAqYAWrevrGVWVgC6/38HTyTYEaKkmmNb1u8Z8E3WxCiI8KfGn5g8uRuxmdjlQUa/3iHCE9uh/DHlrzO0HEmAFx0Y19khiMpUAUALIVJVdjkcVzjjvIOd9gcTDklw+bDEh8FdPp2Uk3KL16CH/mrmR7QpoGlmg84tTysNd7hVUg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrustdatacard.com; dmarc=pass action=none header.from=entrustdatacard.com; dkim=pass header.d=entrustdatacard.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrustdatacardcorp.onmicrosoft.com; s=selector2-entrustdatacardcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YetR+pqTvDYiBh+nJocK7Wxzr24m7ubHKN/1gpu3Sbw=; b=QkEQcdtF4lYffUmXJclR9q8cx+7OsCWHyOl8N/A4YHjN2IMhCTTIYY20XU4QEySrtYHSxUceBH2JyFm9rFVXUD2yv+geYqhbtHHfgHWS7m02EXcMptMT3cadvdVHgW3iuYgUZiTh+oF5i1aHeaSvGlYokUYkQBowxCUDM50q1O0= Received: from MN2PR11MB3710.namprd11.prod.outlook.com (20.178.252.147) by MN2PR11MB3742.namprd11.prod.outlook.com (20.178.254.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.20; Tue, 1 Oct 2019 15:22:49 +0000 Received: from MN2PR11MB3710.namprd11.prod.outlook.com ([fe80::ccee:a2c9:107:8e97]) by MN2PR11MB3710.namprd11.prod.outlook.com ([fe80::ccee:a2c9:107:8e97%5]) with mapi id 15.20.2305.017; Tue, 1 Oct 2019 15:22:49 +0000 From: Mike Ounsworth To: Erik Andersen , 'LAMPS' Thread-Topic: [lamps] [EXTERNAL] X.510 Thread-Index: AQHVcrIQKeRiJK3IuUWLzXk81rHZpKdF8cpw Date: Tue, 1 Oct 2019 15:22:49 +0000 Message-ID: References: <000601d57081$5afa8fc0$10efaf40$@x500.eu> <01fd886909e94b0ab9c353958f46a45e@PMSPEX05.corporate.datacard.com> <002201d572b2$0815f6e0$1841e4a0$@x500.eu> In-Reply-To: <002201d572b2$0815f6e0$1841e4a0$@x500.eu> 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=Mike.Ounsworth@entrustdatacard.com; x-originating-ip: [142.114.132.63] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7c27b18e-9ff2-427e-3459-08d746833819 x-ms-traffictypediagnostic: MN2PR11MB3742: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4714; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(396003)(376002)(346002)(39850400004)(199004)(189003)(13464003)(52314003)(66446008)(8676002)(66556008)(476003)(305945005)(76116006)(110136005)(14454004)(446003)(11346002)(81166006)(81156014)(6116002)(966005)(3846002)(6436002)(66946007)(66476007)(8936002)(71200400001)(7736002)(486006)(478600001)(9686003)(2906002)(229853002)(64756008)(316002)(7696005)(5660300002)(14444005)(5024004)(186003)(256004)(66066001)(25786009)(26005)(99286004)(6246003)(55016002)(76176011)(52536014)(86362001)(74316002)(6506007)(71190400001)(6306002)(53546011)(33656002)(102836004); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR11MB3742; H:MN2PR11MB3710.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IEg3qulGBsQJSJRKqTD6AV4ISRA03uQPSrJK31PyNXHP4tL9zB/K6g3pbEKv1NSwCjY+4BNRH9psZSKpTuP+0FM3A1OelX8NLSduHecsWKViL2klVumBkn0HnnboiLqU7ECpOjSPufySC8ricilYwWFnqCPkHNGT+hU3Ld6OCtNtSbHkYrMrIk/wVTdomDkjDpdktW/1Y8OPLW60Gz1idAQ9yTmtgoK6HpaOCC+OsVfEfwXw3oi1Oq+IVWQ7V4aZQbQ75zIQOOg49Twi11Nq+9VECkgaIKdzAqekAekpvZf4bTyGXfd7QewF73dtpl6p6zIaqCYTtN+jWBQsxZDfjwecg7OeOfJJBEN0K94NZHlC1LfNdPjA384Z4ydaddLdmNrahl781K2vAaJLLiDAPXrqrAQoQ1dUYE7nkdP8zVDbY8j7oncBuBVr9liJALQVbIfLeXyWNXreX4ZE2XxwdQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7c27b18e-9ff2-427e-3459-08d746833819 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2019 15:22:49.0601 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: U093avvTRee5zVnvLvk24rrv4Sv40T5LOI2/+Kl4y+7caNxQ2RfaZ2X8FvIPzX7EphNUM/+n3C3s3dyaYiqhrK0wpIZZ9sNNRPFDPm4JMGeG4QZRU5+VmkicVVP1Zp54 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3742 X-OriginatorOrg: entrustdatacard.com Archived-At: Subject: Re: [lamps] [EXTERNAL] X.510 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 15:22:55 -0000 Hi Erik, This is joint feedback on X.510 from the group of authors who worked on the= composite pubic keys and signatures draft (https://tools.ietf.org/html/dra= ft-ounsworth-pq-composite-sigs-01) and some overlap with the authors of the= hybrid certificates draft (https://tools.ietf.org/html/draft-truskovsky-la= mps-pq-hybrid-x509-01) which is now being pursued at ITU-T by ISARA. 1. X.510 section 6 defines MultiplePublicKeyAlgo identifiers and params, bu= t seems to be missing a definition of the public keys themselves. If the id= ea is to concatenate multiple public keys into the single existing octet st= ring, it's probably important to define that encoding. See our draft for ho= w we thought to define that structure: https://tools.ietf.org/html/draft-ou= nsworth-pq-composite-sigs-01#section-2.3. 2. X.510 Annex G: the mechanism you define relies on the use of ASN.1 exten= sion marks, which were introduced to the SIGNED structure in X.509 rev 7 (2= 012), and are not included in the ASN.1 structures of the X.509 profile in = IETF RFC5280 (2008). I see that you address that on p. 72 in the paragraph = "If extension marks are not supported", basically saying to use the Multipl= ePublicKey definitions from section 6. This is not a problem for your draft= , but we wanted to point out on this mailing list that IETF and WebPKI can'= t use the mechanism proposed in Annex G without updating RFC5280 and relyin= g implementations to support ASN.1 extension marks. 3. For both mechanisms (section 6, and Annex G), have you thought about str= ipping attacks, where say the attacker cracks the weaker of the two signatu= res and then replaces the other public key with one that he controls? I sup= pose this needs to be addressed at the protocol layer, and therefore is out= of scope for section 6 / annex G, but we still wanted to mention it on thi= s mailing list. 4. Perhaps it makes sense to harmonize the ASN.1 structures between X.510 a= nd our IETF draft(s). Would you be open to joining a phone call with our au= thor group? -Mike Ounsworth, Representing the authors of draft-ounsworth-pq-composite-sigs -----Original Message----- From: Spasm On Behalf Of Erik Andersen Sent: Tuesday, September 24, 2019 3:28 AM To: 'LAMPS' Cc: Mark Pecen ; Jean-Paul LEMAIRE Subject: Re: [lamps] [EXTERNAL] X.510 Hi Mike, A good point. Having multiple algorithms for added security and not just fo= r migration is not really considered in draft X.510, which could be a miss.= We will see if we can get that aspect into document during its final ballo= t round where in principle only editorials are allowed. Anyway, we will pro= bably need an edition 2 quite quickly. Best regards, Erik -----Oprindelig meddelelse----- Fra: Spasm [mailto:spasm-bounces@ietf.org] P=E5 vegne af Mike Ounsworth Sendt: 24 September 2019 05:51 Til: Erik Andersen ; LAMPS Emne: Re: [lamps] [EXTERNAL] X.510 Hi Erik, I found your slides https://docbox.etsi.org/Workshop/2019/201906_ETSISECURITYWEEK/202106_Dynami= c NatureOfTechno/SESSION03_CHANGINGCRYPTOGRAPHY/ANDERSENSLSERVICES_ANDERSEN.p= d f, explaining the rationale behind X.510. In it, you say: * A back level recipient will ignore the alternative algorithm, but validat= e according to the native one * An advanced recipient will validate according to the alternative algorith= m In attending post-quantum conferences, for example the NIST PQC, there is a= strong call for "hybrid" modes where *both* algorithms are validated becau= se we don't fully trust the new stuff yet. So this may not be simply a migr= ation issue, but a more long-term issue of combining algorithms for increas= ed security. Do you have an opinion on whether X.510 in its current form would be approp= riate for hybrid modes, and whether your language should be adjusted to be = "native algorithm and alt algorithm" as opposed to your current "native alg= orithm or alt algorithm" ? - - - Mike Ounsworth | Office: +1 (613) 270-2873 From: Spasm On Behalf Of Erik Andersen Sent: Saturday, September 21, 2019 8:35 AM To: LAMPS Subject: [EXTERNAL][lamps] X.510 WARNING: This email originated outside of Entrust Datacard. DO NOT CLICK links or attachments unless you trust the sender and know the = content is safe. ________________________________________ Within ITU-T and ISO we have developed a new specification, Rec. ITU-T X.51= 0 | ISO/IEC 9594-11, which now is out for final vote. There is a link to=20 | it https://www.dropbox.com/s/qzzuy9hu2vjz9qw/X.510-dis.pdf?dl=3D0. We expect t= o complete it by March 2020. Any comment any of you might have will be highly appreciated. Best regards, Erik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Oct 3 13:09:48 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D99120821 for ; Thu, 3 Oct 2019 13:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 Tf67OhaLFycj for ; Thu, 3 Oct 2019 13:09:37 -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 1C51D1208A3 for ; Thu, 3 Oct 2019 13:09:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 97FB6300AEA for ; Thu, 3 Oct 2019 16:09:35 -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 R0OzpqBvgRcL for ; Thu, 3 Oct 2019 16:09:34 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 7D0C7300460 for ; Thu, 3 Oct 2019 16:09:34 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 3 Oct 2019 16:09:35 -0400 References: <3DB1B550-26FA-4F93-8CFA-434C1F8811D1@vigilsec.com> To: LAMPS WG In-Reply-To: Message-Id: <1FCD3A67-9834-4D0B-8B19-2C3EADA498E5@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Proposed charter update regarding clarifications X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2019 20:09:47 -0000 I am pleased that several more people have spoken up. In addition, some = people that appeared indifferent are now be counted as supportive. I = believe that there is consensus to propose the NEW text as part of the = next recharter. Russ On Wed, Sep 11, 2019 at 3:17 PM Russ Housley = wrote: >=20 > I am concerned that we have heard from very few people on this topic, = with roughly equal numbers speaking for, against, and indifferent. If = you have not spoken, please do so. >=20 > Russ >=20 >> On Jul 27, 2019, at 7:40 AM, Russ Housley = wrote: >>=20 >> At the meeting in Montreal, we suggested a charter update to allow = clarifications. I suggest: >>=20 >> OLD: >>=20 >> In addition, the LAMPS WG may investigate other updates to documents >> produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt >> any of these potential work items without rechartering. >>=20 >> NEW: >>=20 >> In addition, the LAMPS WG may investigate other updates to documents >> produced by the PKIX and S/MIME WG. The LAMPS WG may produce >> clarifications where needed, but the LAMPS WG shall not adopt >> anything beyond clarifications without rechartering. >>=20 >> Thoughts? >>=20 >> Russ From nobody Thu Oct 3 13:41:38 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6E9120823 for ; Thu, 3 Oct 2019 13:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 h06r-NcMFrkM for ; Thu, 3 Oct 2019 13:41:26 -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 24F2A12087A for ; Thu, 3 Oct 2019 13:41:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 91AF6300460 for ; Thu, 3 Oct 2019 16:41:24 -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 h5Y5wU-mLMjO for ; Thu, 3 Oct 2019 16:41:23 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 185EC300B1E for ; Thu, 3 Oct 2019 16:41:23 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Thu, 3 Oct 2019 16:41:23 -0400 To: LAMPS WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] Proposed LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2019 20:41:37 -0000 Many of the work items in the current charter have reached the RFC = Editor queue. I believe that we can safely drop those topics. That = leaves three, including the CMP profile work that has already been = discussed on the list. We do not have an active document for the short-lived X.509 certificates = work item that was directed to us by the SECDISPATCH process. Please review. Is this ready to be sent to the IESG for approval? Russ =3D =3D =3D =3D =3D =3D =3D =3D =3D The PKIX and S/MIME Working Groups have been closed for some time. Some updates have been proposed to the X.509 certificate documents produced=20= by the PKIX Working Group and the electronic mail security documents=20 produced by the S/MIME Working Group. The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working=20 Group is chartered to make updates where there is a known constituency=20= interested in real deployment and there is at least one sufficiently=20 well specified approach to the update so that the working group can=20 sensibly evaluate whether to adopt a proposal. The LAMPS WG is now tackling these topics: 1. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information. As a result, revoking short-lived certificates is unnecessary and pointless. 2. Update the specification for the cryptographic protection of email headers -- both for signatures and encryption -- to improve the implementation situation with respect to privacy, security, usability and interoperability in cryptographically-protected electronic mail. Most current implementations of cryptographically-protected electronic mail protect only the body of the message, which leaves significant=20 room for attacks against otherwise-protected messages. 3. The Certificate Management Protocol (CMP) is specified in RFC 4210, and it offers a vast range of certificate management options. CMP is currently being used in many different industrial environments, but it needs to be tailored to the specific needs of some environments. The LAMPS WG will develop a "lightweight" profile of CMP to more efficiently support of these environments and better facilitate interoperable implementation, while preserving cryptographic algorithm agility. In addition, the LAMPS WG may investigate other updates to documents produced by the PKIX and S/MIME WG. The LAMPS WG may produce clarifications where needed, but the LAMPS WG shall not adopt anything beyond clarifications without rechartering. From nobody Thu Oct 3 13:46:49 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6331207FC for ; Thu, 3 Oct 2019 13:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 uFO6NeDkgsiA for ; Thu, 3 Oct 2019 13:46:46 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 E2C6512003E for ; Thu, 3 Oct 2019 13:46:45 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x93KitDS026681; Thu, 3 Oct 2019 21:46:38 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=0kSTybpVq/a/Xj/DGXS+iWxdxVqsWCO1rtg5Bso4oHw=; b=B/SB9T1hp/T3TTQPl6z0d2oMOJxq6MUqrVXsm9t7fBv1jm7ZeFjijwOi8Ck4iyMHrFdz zJhyhdEDczAu+gsJZnfhiQkITPN25CjHvR0I1FDwZpHrTCkZJYlMMFrXMTcFChIymB6N 7qVqk3nU/H5eiAD+6BAAj49rHMntFlzksi47T4zM1ThB/P89tSkYRs3XbXc62lPajOJa AoGnZaWhdoOPvEvOItVSDZGXhb+i9k9Cztp6Uz7rV3KRlnZ73/ewvlxxTt0TU6AIAePd 8k8l3bqaXZWZrriJkoouXTW2Msrj/ttPITy9W0tHjCWiMZrYXM0DIB4cI5X8Tx/+74da nw== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2v9vkfsg9e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 Oct 2019 21:46:38 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x93KWaqv027817; Thu, 3 Oct 2019 16:46:37 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2va2v0wm8k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 03 Oct 2019 16:46:35 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 3 Oct 2019 16:46:22 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Thu, 3 Oct 2019 16:46:22 -0400 From: "Salz, Rich" To: Russ Housley , LAMPS WG Thread-Topic: [lamps] Proposed LAMPS Recharter Thread-Index: AQHVeisAPkG0PGafQUSoC1Bk8hQ/K6dJYuOA Date: Thu, 3 Oct 2019 20:46:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.88] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-03_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=836 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910030166 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-03_08:2019-10-03,2019-10-03 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=841 spamscore=0 impostorscore=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 mlxscore=0 clxscore=1015 priorityscore=1501 phishscore=0 malwarescore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910030168 Archived-At: Subject: Re: [lamps] Proposed LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2019 20:46:47 -0000 PiAgICBQbGVhc2UgcmV2aWV3LiAgSXMgdGhpcyByZWFkeSB0byBiZSBzZW50IHRvIHRoZSBJRVNH IGZvciBhcHByb3ZhbD8NCiAgDQpTaGlwIGl0Lg0KDQo= From nobody Thu Oct 3 22:50:06 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD94B1200F6 for ; Thu, 3 Oct 2019 22:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.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 ybfbVfowFkwU for ; Thu, 3 Oct 2019 22:50:01 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0604.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::604]) (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 6D5A91200C1 for ; Thu, 3 Oct 2019 22:50:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NX+naC5EGGEV5dPsUUZkQAvBCkOohEw+AeJtyY/kIKYVOE4QrqZZaunMkJ5e6e2DeBO5R0oF9pt5rlqp8DDhu38WUt5eiX2+kjG3nFtZ+E20JrYTW675p1WP3A7YMpHCw9CNB9m/R0gZaqp8aBuUrkKf15laf6g8v7A0+6eB5kw54Hv5VvmOAKH/zss6olrCYuKHpQm46hzU4/GCbmWc6juoO94CVLZqrFrJ7PSzthpX02OFehEvKR6Bll7tKJH6VPWbO39cTiOwsdQVBCxCyMWkjx++YYFLsbsZZ7jE7WFV7CUU8gECj45Uw1DzAU6XbPCFWPJxs5XF8+XCY2Uoow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pNodwOBZ32DSam6Jv77oc/mtam+HzDV6oBeNe7IrrHE=; b=cbZsU1QOl/VfOs0tI4ODgHU0H7CnjHr9DZk3ki0/cwAgdrFR6OCvhzfMR61fXj0Ggr4MOzzx0vFsCmgn6GQ1AJLjTSZz1GeRfpNPdq3opn+ch8SS2M8osN53MGyAQM/z27Z/QlB+ErMWZnppMoSpaSmVauXP2FJX4VGcIkEcZVJCX5F0Ni3VOKE1z82F5h/qjR9ZvRdrpI4cptZeOc454h+pwFQQM2Sc1P4DyJPKOrj1i5mZKm+Y+0htHTWSP4Im2iZnoOmZdvEJ63aIf3NDKzfZtuzYemqw9tCFSRXp+jA7W/xnV1Y/6z9AF7Bp6znwMf/yTe1LAxeajYA9mNt3IA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector2-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pNodwOBZ32DSam6Jv77oc/mtam+HzDV6oBeNe7IrrHE=; b=jeJ86f73Iql9V2Fx15NjoFkmSU430sPer7RUW8fszL4PbfxI68Hi3U9YmRFA4stnCWTH4PIpyFhkVpa09Kcu6Y0Wk2VtyTJh+OzuTMJps4dzloxCzNA20uqrCUaUg8emkHjC63Zk7wYOYhJb7dRptbbZlEGNE0m6UQ+q0HV1LEo= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB3089.EURPRD10.PROD.OUTLOOK.COM (10.255.31.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.17; Fri, 4 Oct 2019 05:49:59 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a83c:43ea:badd:b7ac]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a83c:43ea:badd:b7ac%7]) with mapi id 15.20.2305.023; Fri, 4 Oct 2019 05:49:59 +0000 From: "Brockhaus, Hendrik" To: Russ Housley , LAMPS WG Thread-Topic: [lamps] Proposed LAMPS Recharter Thread-Index: AQHVeisBR8NRscNWhEOYduojoanYOqdJ+f/Q Date: Fri, 4 Oct 2019 05:49:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [195.145.170.153] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ac1404fd-6d73-47a5-365b-08d7488eb137 x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: AM0PR10MB3089: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 018093A9B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(376002)(136003)(366004)(396003)(199004)(189003)(76176011)(76116006)(66446008)(8936002)(8676002)(81156014)(81166006)(64756008)(9686003)(55016002)(33656002)(86362001)(6306002)(66574012)(6436002)(99286004)(561944003)(14444005)(71190400001)(71200400001)(66066001)(256004)(476003)(74316002)(486006)(3846002)(6116002)(7736002)(446003)(305945005)(66556008)(2906002)(7696005)(102836004)(11346002)(186003)(110136005)(478600001)(316002)(25786009)(66946007)(45080400002)(26005)(6506007)(5660300002)(52536014)(14454004)(66476007)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB3089; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vMYRyOrJXpNjy+LrNt3nd3Mp0OgO6SIBCCWqv7LxDv+Kufzt/wF/6rCZnraV2T4K7yn/Crvf+3LLCXtsoykw7VB0lICQLVoZhSZ2SnFPTww/hHnphkA/gtFr8Sgq5vdH7piM0+iUUjPd+e8GojT0oU/c+eBHdQ2I0BKn0M27GApXgQsd9t58hqe/S7v5UpLTMB8XzW7cQLzuNyvntlrVWmrBMH7NUYnwrdiXTCgMIId+oQtpMsbwELQVrOmW+lI0UvQgy++YUJMWi4+1J0CprsYEyCa0EVe5W0JdiNpW/jVHaJ9dzr8qe5XrBO4/ENUX2NBTXq1oEFpTEQct47C73t94KtTw3CgKUdNyAbhrX5feoQtgmuMTl62Lm+8RAdhQJzKmyGMdx+DfsiK3TpOIFv+CB+l7Tw41TiLkb4CPcVM= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: ac1404fd-6d73-47a5-365b-08d7488eb137 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2019 05:49:59.1286 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QQNs3tg8jtqTaCCzdwClFyNWY/im4mxRFfwbMLST9WjfTtPOCec8fkEjXqh3p62rxlYotT5dvIhZ8WHUnm6kHTpE2j07aKfbyRaV+eRAFPI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB3089 Archived-At: Subject: Re: [lamps] Proposed LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 05:50:05 -0000 Should we also mention the CMP Updates in the re-charter. Proposal: 3. The Certificate Management Protocol (CMP) is specified in RFC 4210, and = it offers a vast range of certificate management options. CMP is currently= being used in many different industrial environments, but it needs to be t= ailored to the specific needs of some environments. The LAMPS WG will prov= ide some updates to CMP and develop a "lightweight" profile of CMP to more = efficiently support of these environments and better facilitate interoperab= le implementation, while preserving cryptographic algorithm agility. Hendrik > -----Urspr=FCngliche Nachricht----- > Von: Spasm Im Auftrag von Russ Housley > Gesendet: Donnerstag, 3. Oktober 2019 22:41 > An: LAMPS WG > Betreff: [lamps] Proposed LAMPS Recharter >=20 > Many of the work items in the current charter have reached the RFC Editor > queue. I believe that we can safely drop those topics. That leaves thre= e, > including the CMP profile work that has already been discussed on the lis= t. >=20 > We do not have an active document for the short-lived X.509 certificates > work item that was directed to us by the SECDISPATCH process. >=20 > Please review. Is this ready to be sent to the IESG for approval? >=20 > Russ >=20 > =3D =3D =3D =3D =3D =3D =3D =3D =3D >=20 > The PKIX and S/MIME Working Groups have been closed for some time. > Some updates have been proposed to the X.509 certificate documents > produced by the PKIX Working Group and the electronic mail security > documents produced by the S/MIME Working Group. >=20 > The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working > Group is chartered to make updates where there is a known constituency > interested in real deployment and there is at least one sufficiently well > specified approach to the update so that the working group can sensibly > evaluate whether to adopt a proposal. >=20 > The LAMPS WG is now tackling these topics: >=20 > 1. Specify the use of short-lived X.509 certificates for which no revocat= ion > information is made available by the Certification Authority. > Short-lived certificates have a lifespan that is shorter than the time ne= eded > to detect, report, and distribute revocation information. As a result, r= evoking > short-lived certificates is unnecessary and pointless. >=20 > 2. Update the specification for the cryptographic protection of email hea= ders > -- both for signatures and encryption -- to improve the implementation > situation with respect to privacy, security, usability and interoperabili= ty in > cryptographically-protected electronic mail. > Most current implementations of cryptographically-protected electronic ma= il > protect only the body of the message, which leaves significant room for > attacks against otherwise-protected messages. >=20 > 3. The Certificate Management Protocol (CMP) is specified in RFC 4210, an= d it > offers a vast range of certificate management options. CMP is currently > being used in many different industrial environments, but it needs to be > tailored to the specific needs of some environments. The LAMPS WG will > develop a "lightweight" profile of CMP to more efficiently support of the= se > environments and better facilitate interoperable implementation, while > preserving cryptographic algorithm agility. >=20 > In addition, the LAMPS WG may investigate other updates to documents > produced by the PKIX and S/MIME WG. The LAMPS WG may produce > clarifications where needed, but the LAMPS WG shall not adopt anything > beyond clarifications without rechartering. >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww > .ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D02%7C01%7Chendrik. > brockhaus%40siemens.com%7C0b63866951bd40e98d8d08d7484222e1%7C38 > ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637057321200934913&am > p;sdata=3DAHNsCOeT60Jrqo1TshfcFaS8a5l55SwdJp91pHAybno%3D&reser > ved=3D0 From nobody Fri Oct 4 07:59:45 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2176120883 for ; Fri, 4 Oct 2019 07:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 k6nffDeDLNLD for ; Fri, 4 Oct 2019 07:59:41 -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 44C0D12087D for ; Fri, 4 Oct 2019 07:59:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B24DB300B18 for ; Fri, 4 Oct 2019 10:59:39 -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 WVyAz1a3W5DL for ; Fri, 4 Oct 2019 10:59:37 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 8F0CF300ABE; Fri, 4 Oct 2019 10:59:37 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: Date: Fri, 4 Oct 2019 10:59:38 -0400 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <13252053-7DD8-4C76-AC74-E5E0A31D4F40@vigilsec.com> References: To: "Brockhaus, Hendrik" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Proposed LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 14:59:44 -0000 Hendrik: You are correct. I somehow dropped a sentence that was discussed on the = list: Necessary updates and clarifications to CMP will be specified in = a separate document. I suggest we stick with that wording ... Russ > On Oct 4, 2019, at 1:49 AM, Brockhaus, Hendrik = wrote: >=20 > Should we also mention the CMP Updates in the re-charter. >=20 > Proposal: > 3. The Certificate Management Protocol (CMP) is specified in RFC 4210, = and it offers a vast range of certificate management options. CMP is = currently being used in many different industrial environments, but it = needs to be tailored to the specific needs of some environments. The = LAMPS WG will provide some updates to CMP and develop a "lightweight" = profile of CMP to more efficiently support of these environments and = better facilitate interoperable implementation, while preserving = cryptographic algorithm agility. >=20 > Hendrik >=20 >> -----Urspr=C3=BCngliche Nachricht----- >> Von: Spasm Im Auftrag von Russ Housley >> Gesendet: Donnerstag, 3. Oktober 2019 22:41 >> An: LAMPS WG >> Betreff: [lamps] Proposed LAMPS Recharter >>=20 >> Many of the work items in the current charter have reached the RFC = Editor >> queue. I believe that we can safely drop those topics. That leaves = three, >> including the CMP profile work that has already been discussed on the = list. >>=20 >> We do not have an active document for the short-lived X.509 = certificates >> work item that was directed to us by the SECDISPATCH process. >>=20 >> Please review. Is this ready to be sent to the IESG for approval? >>=20 >> Russ >>=20 >> =3D =3D =3D =3D =3D =3D =3D =3D =3D >>=20 >> The PKIX and S/MIME Working Groups have been closed for some time. >> Some updates have been proposed to the X.509 certificate documents >> produced by the PKIX Working Group and the electronic mail security >> documents produced by the S/MIME Working Group. >>=20 >> The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working >> Group is chartered to make updates where there is a known = constituency >> interested in real deployment and there is at least one sufficiently = well >> specified approach to the update so that the working group can = sensibly >> evaluate whether to adopt a proposal. >>=20 >> The LAMPS WG is now tackling these topics: >>=20 >> 1. Specify the use of short-lived X.509 certificates for which no = revocation >> information is made available by the Certification Authority. >> Short-lived certificates have a lifespan that is shorter than the = time needed >> to detect, report, and distribute revocation information. As a = result, revoking >> short-lived certificates is unnecessary and pointless. >>=20 >> 2. Update the specification for the cryptographic protection of email = headers >> -- both for signatures and encryption -- to improve the = implementation >> situation with respect to privacy, security, usability and = interoperability in >> cryptographically-protected electronic mail. >> Most current implementations of cryptographically-protected = electronic mail >> protect only the body of the message, which leaves significant room = for >> attacks against otherwise-protected messages. >>=20 >> 3. The Certificate Management Protocol (CMP) is specified in RFC = 4210, and it >> offers a vast range of certificate management options. CMP is = currently >> being used in many different industrial environments, but it needs to = be >> tailored to the specific needs of some environments. The LAMPS WG = will >> develop a "lightweight" profile of CMP to more efficiently support of = these >> environments and better facilitate interoperable implementation, = while >> preserving cryptographic algorithm agility. >>=20 >> In addition, the LAMPS WG may investigate other updates to documents >> produced by the PKIX and S/MIME WG. The LAMPS WG may produce >> clarifications where needed, but the LAMPS WG shall not adopt = anything >> beyond clarifications without rechartering. >>=20 >>=20 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= >> .ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D02%7C01%7Chendrik. >> brockhaus%40siemens.com%7C0b63866951bd40e98d8d08d7484222e1%7C38 >> ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637057321200934913&am >> p;sdata=3DAHNsCOeT60Jrqo1TshfcFaS8a5l55SwdJp91pHAybno%3D&reser >> ved=3D0 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Fri Oct 4 08:00:55 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F325912087B for ; Fri, 4 Oct 2019 08:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.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 RXBwZ4a16iXX for ; Fri, 4 Oct 2019 08:00:44 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150055.outbound.protection.outlook.com [40.107.15.55]) (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 E37D3120861 for ; Fri, 4 Oct 2019 08:00:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j8zM8NwkQG2/s/YTPNKXNVEJ4Pez/KAk6UutVOCfp0dGdP0Y5kdRZ5pxjfDpdsIZWxfljeebLL7Cs5sj9SVyarCEA+0uIZmigUMAyTN1ty0nxXhUVBvDvwJGUxkHgBztVnx52rVFUtnj5Ia28jPZ3j0fs36/0DEwVTdjCJosu5/UspE6LsJxxeyQaA9aX01UvVmhmsVAhV2kIB14DEZBA+4yhtDbfnbuOMQyGDjZlOCDb6b07VX3WfACqDZRwnYC48iuEd/Iqab/QgADhAEuD0Kh7lyVgNec2x8dB6Q10QdC6izJtJpeimeC/ekHMBitOtvadsBh8wImkqYcpa6Gtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5+Zse49K3+Mki6r9Y2qk+MRzzT1f5MeBguigsmHiey4=; b=iLSHHQxGWkz7ic5OpEOZD58+bY94IznEEh2NyffJ8IQjUStYStuu/WIccx54Gc+UEcCeEyEP+sRYIMFPay9sTrsz4NO5pvswzj91a/SdpN7edXsEjc9/2B73M+jxwH6GtiIdzsLxr2bMrlTvBbHW5K1S8CAd/7LhN9kLUULtLO+UVVwFquxI/oLHgnRt1ztQQIMpeIpJoIH7kveL1weZgt253X8Q51c7SWyJ4MBEg9V/oh2FjZIat9VwielMoZiYSXr+5o6m4j/H8lgXTYZavva+dehgfzO5QO8U/vMDg7vEPI8QZYxrVgHFutxmF7THTxAKf9M+dKSqcTnWhEko6w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector2-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5+Zse49K3+Mki6r9Y2qk+MRzzT1f5MeBguigsmHiey4=; b=dWtA0nGgjSAza40VBBsfabzxRpzwIfmCO8gnGbLLycfFZ7P2MAgrs3utmA111biJftMhlLW8QcwIj0eBQHStUwh5c/LWL5x9UG33Jvntlb4BWib51MtZ1ZPOTXNLwdHF6u94FXrJ+yuyjoruKDRcMR/xAjoYRDN0RM3qtZDQm9I= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB2210.EURPRD10.PROD.OUTLOOK.COM (20.177.43.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.23; Fri, 4 Oct 2019 15:00:42 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a83c:43ea:badd:b7ac]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a83c:43ea:badd:b7ac%7]) with mapi id 15.20.2305.023; Fri, 4 Oct 2019 15:00:42 +0000 From: "Brockhaus, Hendrik" To: Russ Housley CC: LAMPS WG Thread-Topic: [lamps] Proposed LAMPS Recharter Thread-Index: AQHVeisBR8NRscNWhEOYduojoanYOqdJ+f/QgACaWgCAAAArsA== Date: Fri, 4 Oct 2019 15:00:41 +0000 Message-ID: References: <13252053-7DD8-4C76-AC74-E5E0A31D4F40@vigilsec.com> In-Reply-To: <13252053-7DD8-4C76-AC74-E5E0A31D4F40@vigilsec.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [195.145.170.153] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 56a6590f-9820-430a-fa15-08d748dba054 x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: AM0PR10MB2210: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 018093A9B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(376002)(346002)(136003)(396003)(199004)(189003)(478600001)(71190400001)(14444005)(71200400001)(256004)(966005)(6306002)(9686003)(55016002)(6436002)(52536014)(486006)(14454004)(561944003)(4326008)(5660300002)(33656002)(316002)(476003)(25786009)(66066001)(26005)(102836004)(66446008)(45080400002)(86362001)(186003)(66574012)(446003)(81156014)(81166006)(8676002)(99286004)(53546011)(6506007)(66476007)(66946007)(76116006)(66556008)(64756008)(7736002)(305945005)(7696005)(2906002)(76176011)(74316002)(6116002)(8936002)(6916009)(11346002)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB2210; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0PaNuFk2KxfvBf0OjPRAnI2L606Hu60/RZUOS0ssRFII3bxOWtWg1PzsJOCOY0j/aakrU9o9lmk3PeS+9YSCpvzfMv/SRy2Z0YMcZ/cCKnY1LE2JSYxZROnjWi6neV2CdNiO32BfxXxtEJvC8+GvrgWmCKJqUnIqtK4nVKViXYD/0Zmwvz7zBtCRCspNJtiqPJ75bfIu7aL6x4VxAGCD/SpQkQb0oVmWl4CIm0UZlfLvrjT++gcav0RJMIeb7syHCHTtQxDJWLhWlBD7xN2//QF5e1MkKuNa3d0x20YTTRbGaahPLFtn7kGQixWPDiHL9einLR27WFuBRnLhinxJgEIdUZgVPdLtadaOX4ZRaUF0NKqqA6Oda2L5HVKDEnd3CEZmY9RnG6oqGMVka+QZczYLpJzlcwA1lczu9GCae40= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 56a6590f-9820-430a-fa15-08d748dba054 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2019 15:00:41.9686 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9A4dKxfFapcgXuHS3Bm7Ew57Ixd+mBxgYYR2lIa4sbF5KpP3QQUye2DvnGt4gyyxVO9rE/tub+0byi3vXrDe18k+u3d/Y8zH3W7FQTOJjsE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2210 Archived-At: Subject: Re: [lamps] Proposed LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 15:00:48 -0000 VGhhbmtzLCB0aGF0IGlzIGV2ZW4gYmV0dGVyDQpIZW5kcmlrDQoNCj4gLS0tLS1VcnNwcsO8bmds aWNoZSBOYWNocmljaHQtLS0tLQ0KPiBWb246IFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNl Yy5jb20+DQo+IEdlc2VuZGV0OiBGcmVpdGFnLCA0LiBPa3RvYmVyIDIwMTkgMTc6MDANCj4gQW46 IEJyb2NraGF1cywgSGVuZHJpayAoQ1QgUkRBIENTVCBTRUEtREUpDQo+IDxoZW5kcmlrLmJyb2Nr aGF1c0BzaWVtZW5zLmNvbT4NCj4gQ2M6IExBTVBTIFdHIDxzcGFzbUBpZXRmLm9yZz4NCj4gQmV0 cmVmZjogUmU6IFtsYW1wc10gUHJvcG9zZWQgTEFNUFMgUmVjaGFydGVyDQo+IA0KPiBIZW5kcmlr Og0KPiANCj4gWW91IGFyZSBjb3JyZWN0LiAgSSBzb21laG93IGRyb3BwZWQgYSBzZW50ZW5jZSB0 aGF0IHdhcyBkaXNjdXNzZWQgb24gdGhlDQo+IGxpc3Q6DQo+IA0KPiAJTmVjZXNzYXJ5IHVwZGF0 ZXMgYW5kIGNsYXJpZmljYXRpb25zIHRvIENNUCB3aWxsIGJlIHNwZWNpZmllZCBpbiBhDQo+IHNl cGFyYXRlIGRvY3VtZW50Lg0KPiANCj4gSSBzdWdnZXN0IHdlIHN0aWNrIHdpdGggdGhhdCB3b3Jk aW5nIC4uLg0KPiANCj4gUnVzcw0KPiANCj4gDQo+ID4gT24gT2N0IDQsIDIwMTksIGF0IDE6NDkg QU0sIEJyb2NraGF1cywgSGVuZHJpaw0KPiA8aGVuZHJpay5icm9ja2hhdXNAc2llbWVucy5jb20+ IHdyb3RlOg0KPiA+DQo+ID4gU2hvdWxkIHdlIGFsc28gbWVudGlvbiB0aGUgQ01QIFVwZGF0ZXMg aW4gdGhlIHJlLWNoYXJ0ZXIuDQo+ID4NCj4gPiBQcm9wb3NhbDoNCj4gPiAzLiBUaGUgQ2VydGlm aWNhdGUgTWFuYWdlbWVudCBQcm90b2NvbCAoQ01QKSBpcyBzcGVjaWZpZWQgaW4gUkZDIDQyMTAs IGFuZA0KPiBpdCBvZmZlcnMgYSB2YXN0IHJhbmdlIG9mIGNlcnRpZmljYXRlIG1hbmFnZW1lbnQg b3B0aW9ucy4gIENNUCBpcyBjdXJyZW50bHkNCj4gYmVpbmcgdXNlZCBpbiBtYW55IGRpZmZlcmVu dCBpbmR1c3RyaWFsIGVudmlyb25tZW50cywgYnV0IGl0IG5lZWRzIHRvIGJlDQo+IHRhaWxvcmVk IHRvIHRoZSBzcGVjaWZpYyBuZWVkcyBvZiBzb21lIGVudmlyb25tZW50cy4gIFRoZSBMQU1QUyBX RyB3aWxsDQo+IHByb3ZpZGUgc29tZSB1cGRhdGVzIHRvIENNUCBhbmQgZGV2ZWxvcCBhICJsaWdo dHdlaWdodCIgcHJvZmlsZSBvZiBDTVAgdG8NCj4gbW9yZSBlZmZpY2llbnRseSBzdXBwb3J0IG9m IHRoZXNlIGVudmlyb25tZW50cyBhbmQgYmV0dGVyIGZhY2lsaXRhdGUNCj4gaW50ZXJvcGVyYWJs ZSBpbXBsZW1lbnRhdGlvbiwgd2hpbGUgcHJlc2VydmluZyBjcnlwdG9ncmFwaGljIGFsZ29yaXRo bQ0KPiBhZ2lsaXR5Lg0KPiA+DQo+ID4gSGVuZHJpaw0KPiA+DQo+ID4+IC0tLS0tVXJzcHLDvG5n bGljaGUgTmFjaHJpY2h0LS0tLS0NCj4gPj4gVm9uOiBTcGFzbSA8c3Bhc20tYm91bmNlc0BpZXRm Lm9yZz4gSW0gQXVmdHJhZyB2b24gUnVzcyBIb3VzbGV5DQo+ID4+IEdlc2VuZGV0OiBEb25uZXJz dGFnLCAzLiBPa3RvYmVyIDIwMTkgMjI6NDENCj4gPj4gQW46IExBTVBTIFdHIDxzcGFzbUBpZXRm Lm9yZz4NCj4gPj4gQmV0cmVmZjogW2xhbXBzXSBQcm9wb3NlZCBMQU1QUyBSZWNoYXJ0ZXINCj4g Pj4NCj4gPj4gTWFueSBvZiB0aGUgd29yayBpdGVtcyBpbiB0aGUgY3VycmVudCBjaGFydGVyIGhh dmUgcmVhY2hlZCB0aGUgUkZDDQo+ID4+IEVkaXRvciBxdWV1ZS4gIEkgYmVsaWV2ZSB0aGF0IHdl IGNhbiBzYWZlbHkgZHJvcCB0aG9zZSB0b3BpY3MuICBUaGF0DQo+ID4+IGxlYXZlcyB0aHJlZSwg aW5jbHVkaW5nIHRoZSBDTVAgcHJvZmlsZSB3b3JrIHRoYXQgaGFzIGFscmVhZHkgYmVlbg0KPiBk aXNjdXNzZWQgb24gdGhlIGxpc3QuDQo+ID4+DQo+ID4+IFdlIGRvIG5vdCBoYXZlIGFuIGFjdGl2 ZSBkb2N1bWVudCBmb3IgdGhlIHNob3J0LWxpdmVkIFguNTA5DQo+ID4+IGNlcnRpZmljYXRlcyB3 b3JrIGl0ZW0gdGhhdCB3YXMgZGlyZWN0ZWQgdG8gdXMgYnkgdGhlIFNFQ0RJU1BBVENIDQo+IHBy b2Nlc3MuDQo+ID4+DQo+ID4+IFBsZWFzZSByZXZpZXcuICBJcyB0aGlzIHJlYWR5IHRvIGJlIHNl bnQgdG8gdGhlIElFU0cgZm9yIGFwcHJvdmFsPw0KPiA+Pg0KPiA+PiBSdXNzDQo+ID4+DQo+ID4+ ID0gPSA9ID0gPSA9ID0gPSA9DQo+ID4+DQo+ID4+IFRoZSBQS0lYIGFuZCBTL01JTUUgV29ya2lu ZyBHcm91cHMgaGF2ZSBiZWVuIGNsb3NlZCBmb3Igc29tZSB0aW1lLg0KPiA+PiBTb21lIHVwZGF0 ZXMgaGF2ZSBiZWVuIHByb3Bvc2VkIHRvIHRoZSBYLjUwOSBjZXJ0aWZpY2F0ZSBkb2N1bWVudHMN Cj4gPj4gcHJvZHVjZWQgYnkgdGhlIFBLSVggV29ya2luZyBHcm91cCBhbmQgdGhlIGVsZWN0cm9u aWMgbWFpbCBzZWN1cml0eQ0KPiA+PiBkb2N1bWVudHMgcHJvZHVjZWQgYnkgdGhlIFMvTUlNRSBX b3JraW5nIEdyb3VwLg0KPiA+Pg0KPiA+PiBUaGUgTEFNUFMgKExpbWl0ZWQgQWRkaXRpb25hbCBN ZWNoYW5pc21zIGZvciBQS0lYIGFuZCBTTUlNRSkgV29ya2luZw0KPiA+PiBHcm91cCBpcyBjaGFy dGVyZWQgdG8gbWFrZSB1cGRhdGVzIHdoZXJlIHRoZXJlIGlzIGEga25vd24NCj4gPj4gY29uc3Rp dHVlbmN5IGludGVyZXN0ZWQgaW4gcmVhbCBkZXBsb3ltZW50IGFuZCB0aGVyZSBpcyBhdCBsZWFz dCBvbmUNCj4gPj4gc3VmZmljaWVudGx5IHdlbGwgc3BlY2lmaWVkIGFwcHJvYWNoIHRvIHRoZSB1 cGRhdGUgc28gdGhhdCB0aGUNCj4gPj4gd29ya2luZyBncm91cCBjYW4gc2Vuc2libHkgZXZhbHVh dGUgd2hldGhlciB0byBhZG9wdCBhIHByb3Bvc2FsLg0KPiA+Pg0KPiA+PiBUaGUgTEFNUFMgV0cg aXMgbm93IHRhY2tsaW5nIHRoZXNlIHRvcGljczoNCj4gPj4NCj4gPj4gMS4gU3BlY2lmeSB0aGUg dXNlIG9mIHNob3J0LWxpdmVkIFguNTA5IGNlcnRpZmljYXRlcyBmb3Igd2hpY2ggbm8NCj4gPj4g cmV2b2NhdGlvbiBpbmZvcm1hdGlvbiBpcyBtYWRlIGF2YWlsYWJsZSBieSB0aGUgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkuDQo+ID4+IFNob3J0LWxpdmVkIGNlcnRpZmljYXRlcyBoYXZlIGEgbGlm ZXNwYW4gdGhhdCBpcyBzaG9ydGVyIHRoYW4gdGhlDQo+ID4+IHRpbWUgbmVlZGVkIHRvIGRldGVj dCwgcmVwb3J0LCBhbmQgZGlzdHJpYnV0ZSByZXZvY2F0aW9uIGluZm9ybWF0aW9uLg0KPiA+PiBB cyBhIHJlc3VsdCwgcmV2b2tpbmcgc2hvcnQtbGl2ZWQgY2VydGlmaWNhdGVzIGlzIHVubmVjZXNz YXJ5IGFuZCBwb2ludGxlc3MuDQo+ID4+DQo+ID4+IDIuIFVwZGF0ZSB0aGUgc3BlY2lmaWNhdGlv biBmb3IgdGhlIGNyeXB0b2dyYXBoaWMgcHJvdGVjdGlvbiBvZiBlbWFpbA0KPiA+PiBoZWFkZXJz DQo+ID4+IC0tIGJvdGggZm9yIHNpZ25hdHVyZXMgYW5kIGVuY3J5cHRpb24gLS0gdG8gaW1wcm92 ZSB0aGUNCj4gPj4gaW1wbGVtZW50YXRpb24gc2l0dWF0aW9uIHdpdGggcmVzcGVjdCB0byBwcml2 YWN5LCBzZWN1cml0eSwgdXNhYmlsaXR5DQo+ID4+IGFuZCBpbnRlcm9wZXJhYmlsaXR5IGluIGNy eXB0b2dyYXBoaWNhbGx5LXByb3RlY3RlZCBlbGVjdHJvbmljIG1haWwuDQo+ID4+IE1vc3QgY3Vy cmVudCBpbXBsZW1lbnRhdGlvbnMgb2YgY3J5cHRvZ3JhcGhpY2FsbHktcHJvdGVjdGVkDQo+ID4+ IGVsZWN0cm9uaWMgbWFpbCBwcm90ZWN0IG9ubHkgdGhlIGJvZHkgb2YgdGhlIG1lc3NhZ2UsIHdo aWNoIGxlYXZlcw0KPiA+PiBzaWduaWZpY2FudCByb29tIGZvciBhdHRhY2tzIGFnYWluc3Qgb3Ro ZXJ3aXNlLXByb3RlY3RlZCBtZXNzYWdlcy4NCj4gPj4NCj4gPj4gMy4gVGhlIENlcnRpZmljYXRl IE1hbmFnZW1lbnQgUHJvdG9jb2wgKENNUCkgaXMgc3BlY2lmaWVkIGluIFJGQw0KPiA+PiA0MjEw LCBhbmQgaXQgb2ZmZXJzIGEgdmFzdCByYW5nZSBvZiBjZXJ0aWZpY2F0ZSBtYW5hZ2VtZW50IG9w dGlvbnMuDQo+ID4+IENNUCBpcyBjdXJyZW50bHkgYmVpbmcgdXNlZCBpbiBtYW55IGRpZmZlcmVu dCBpbmR1c3RyaWFsDQo+ID4+IGVudmlyb25tZW50cywgYnV0IGl0IG5lZWRzIHRvIGJlIHRhaWxv cmVkIHRvIHRoZSBzcGVjaWZpYyBuZWVkcyBvZg0KPiA+PiBzb21lIGVudmlyb25tZW50cy4gIFRo ZSBMQU1QUyBXRyB3aWxsIGRldmVsb3AgYSAibGlnaHR3ZWlnaHQiIHByb2ZpbGUNCj4gPj4gb2Yg Q01QIHRvIG1vcmUgZWZmaWNpZW50bHkgc3VwcG9ydCBvZiB0aGVzZSBlbnZpcm9ubWVudHMgYW5k IGJldHRlcg0KPiA+PiBmYWNpbGl0YXRlIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb24sIHdo aWxlIHByZXNlcnZpbmcgY3J5cHRvZ3JhcGhpYw0KPiBhbGdvcml0aG0gYWdpbGl0eS4NCj4gPj4N Cj4gPj4gSW4gYWRkaXRpb24sIHRoZSBMQU1QUyBXRyBtYXkgaW52ZXN0aWdhdGUgb3RoZXIgdXBk YXRlcyB0byBkb2N1bWVudHMNCj4gPj4gcHJvZHVjZWQgYnkgdGhlIFBLSVggYW5kIFMvTUlNRSBX Ry4gVGhlIExBTVBTIFdHIG1heSBwcm9kdWNlDQo+ID4+IGNsYXJpZmljYXRpb25zIHdoZXJlIG5l ZWRlZCwgYnV0IHRoZSBMQU1QUyBXRyBzaGFsbCBub3QgYWRvcHQNCj4gPj4gYW55dGhpbmcgYmV5 b25kIGNsYXJpZmljYXRpb25zIHdpdGhvdXQgcmVjaGFydGVyaW5nLg0KPiA+Pg0KPiA+Pg0KPiA+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBT cGFzbSBtYWlsaW5nIGxpc3QNCj4gPj4gU3Bhc21AaWV0Zi5vcmcNCj4gPj4NCj4gaHR0cHM6Ly9l dXIwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG d3d3DQo+ID4+DQo+IC5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwYXNtJmFtcDtk YXRhPTAyJTdDMDElN0NoZW5kcmlrLg0KPiA+Pg0KPiBicm9ja2hhdXMlNDBzaWVtZW5zLmNvbSU3 QzBiNjM4NjY5NTFiZDQwZTk4ZDhkMDhkNzQ4NDIyMmUxJTdDMzgNCj4gPj4NCj4gYWUzYmNkOTU3 OTRmZDRhZGRhYjQyZTE0OTVkNTVhJTdDMSU3QzAlN0M2MzcwNTczMjEyMDA5MzQ5MTMmYW0NCj4g Pj4NCj4gcDtzZGF0YT1BSE5zQ09lVDYwSnJxbzFUc2hmY0ZhUzhhNWw1NVN3ZEpwOTFwSEF5Ym5v JTNEJmFtcDtyZXNlcg0KPiA+PiB2ZWQ9MA0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBTcGFzbSBtYWlsaW5nIGxpc3QNCj4gPiBT cGFzbUBpZXRmLm9yZw0KPiA+DQo+IGh0dHBzOi8vZXVyMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dw0KPiAuDQo+ID4NCj4gaWV0Zi5vcmcl MkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcGFzbSZhbXA7ZGF0YT0wMiU3QzAxJTdDaGVuZHJpay5i DQo+IHJvY2sNCj4gPg0KPiBoYXVzJTQwc2llbWVucy5jb20lN0M4Y2JhY2NhNTRjZWE0ZGMyMTRm YjA4ZDc0OGRiN2RmMCU3QzM4YWUzYmNkDQo+IDk1Nzk0Zg0KPiA+DQo+IGQ0YWRkYWI0MmUxNDk1 ZDU1YSU3QzElN0MwJTdDNjM3MDU3OTc5ODU4NTk5NTg1JmFtcDtzZGF0YT1PVmlkWQ0KPiBPZTBq NiUyDQo+ID4gQjlkRHYzcUd5N2ZJczg1WUZYNmdkRGFZRlUzY2JseTJBJTNEJmFtcDtyZXNlcnZl ZD0wDQoNCg== From nobody Fri Oct 4 09:31:18 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410871208F0 for ; Fri, 4 Oct 2019 09:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 PJ2PVq-gebh4 for ; Fri, 4 Oct 2019 09:30:58 -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 06D80120048 for ; Fri, 4 Oct 2019 09:30:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7E410300AE8 for ; Fri, 4 Oct 2019 12:30:56 -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 c5QlhVQqvnC5 for ; Fri, 4 Oct 2019 12:30:54 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id C5AE93005DF for ; Fri, 4 Oct 2019 12:30:54 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_563C0B17-7373-4E7D-A5DC-450D52D5B941" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: References: <157013285155.16268.2893008309280903681.idtracker@ietfa.amsl.com> To: LAMPS WG Date: Fri, 4 Oct 2019 12:30:55 -0400 X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] New Version Notification for draft-housley-lamps-cms-update-alg-id-protect-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 16:31:06 -0000 --Apple-Mail=_563C0B17-7373-4E7D-A5DC-450D52D5B941 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If the recharter text is approved, then I will be asking the LAMPS WG to = adopt this document. That said, I welcome review and comment now. Russ > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-housley-lamps-cms-update-alg-id-protect-00.txt > Date: October 3, 2019 at 4:00:51 PM EDT > To: "Russ Housley" >=20 >=20 > A new version of I-D, = draft-housley-lamps-cms-update-alg-id-protect-00.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. >=20 > Name: draft-housley-lamps-cms-update-alg-id-protect > Revision: 00 > Title: Update to the Cryptographic Message Syntax (CMS) = for Algorithm Identifier Protection > Document date: 2019-10-03 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-housley-lamps-cms-update-alg-id= -protect-00.txt > Status: = https://datatracker.ietf.org/doc/draft-housley-lamps-cms-update-alg-id-pro= tect/ > Htmlized: = https://tools.ietf.org/html/draft-housley-lamps-cms-update-alg-id-protect-= 00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-housley-lamps-cms-update-alg-i= d-protect >=20 >=20 > Abstract: > This document updates the Cryptographic Message Syntax (CMS) > specified in RFC 5652 to ensure that algorithm identifiers are > adequately protected. --Apple-Mail=_563C0B17-7373-4E7D-A5DC-450D52D5B941 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii If = the recharter text is approved, then I will be asking the LAMPS WG to = adopt this document.  That said, I welcome review and comment = now.

Russ


From: = internet-drafts@ietf.org
Subject: = New Version = Notification for = draft-housley-lamps-cms-update-alg-id-protect-00.txt
Date: = October 3, 2019 at 4:00:51 PM = EDT
To: = "Russ Housley" <housley@vigilsec.com>


A new version = of I-D, draft-housley-lamps-cms-update-alg-id-protect-00.txt
has been successfully submitted by Russ Housley and posted to = the
IETF repository.

Name: = draft-housley-lamps-cms-update-alg-id-protect
Revision: 00
Title: Update to = the Cryptographic Message Syntax (CMS) for Algorithm Identifier = Protection
Document date: 2019-10-03
Group:= = Individual Submission
Pages: 8
URL: =            https://www.ietf.org/internet-drafts/draft-housley-lamps-cms-up= date-alg-id-protect-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-housley-lamps-cms-update= -alg-id-protect/
Htmlized: =       https://tools.ietf.org/html/draft-housley-lamps-cms-update-alg-= id-protect-00
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-housley-lamps-cms-u= pdate-alg-id-protect


Abstract:
  This document updates = the Cryptographic Message Syntax (CMS)
=   specified in RFC 5652 to ensure that algorithm identifiers = are
  adequately protected.

= --Apple-Mail=_563C0B17-7373-4E7D-A5DC-450D52D5B941-- From nobody Mon Oct 7 12:07:30 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A4112008A for ; Mon, 7 Oct 2019 12:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 0hYxP0VHN5UR for ; Mon, 7 Oct 2019 12:07:26 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2DBB1200E9 for ; Mon, 7 Oct 2019 12:07:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 6291C20238E; Mon, 7 Oct 2019 12:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WR2fVe_Ub5-5; Mon, 7 Oct 2019 12:06:16 -0700 (PDT) Received: from [64.170.98.200] (unknown [64.170.98.200]) by c8a.amsl.com (Postfix) with ESMTPA id 20806202289; Mon, 7 Oct 2019 12:06:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Megan Ferguson In-Reply-To: <20190924174350.35F53B80836@rfc-editor.org> Date: Mon, 7 Oct 2019 12:07:13 -0700 Cc: housley@vigilsec.com, rdd@cert.org, kaduk@mit.edu, tim.hollebeek@digicert.com, nay486028@gmail.com, spasm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1599A7BC-FED6-4BA4-9807-5CCF01156B3A@amsl.com> References: <20190924174350.35F53B80836@rfc-editor.org> To: RFC System X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [lamps] [Editorial Errata Reported] RFC8649 (5863) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 19:07:28 -0000 Greetings, FYI - this errata report has been deleted. Thank you. RFC Editor/mf On Sep 24, 2019, at 10:43 AM, RFC Errata System = wrote: > The following errata report has been submitted for RFC8649, > "Hash Of Root Key Certificate Extension". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5863 >=20 > -------------------------------------- > Type: Editorial > Reported by: Shwe Yoke Lay >=20 > Section: RFC 2119 >=20 > Original Text > ------------- > Spelling >=20 > Corrected Text > -------------- > Grammer >=20 > Notes > ----- > Punctuation >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC8649 (draft-ietf-lamps-hash-of-root-key-cert-extn-07) > -------------------------------------- > Title : Hash Of Root Key Certificate Extension > Publication Date : August 2019 > Author(s) : R. Housley > Category : INFORMATIONAL > Source : Limited Additional Mechanisms for PKIX and SMIME > Area : Security > Stream : IETF > Verifying Party : IESG >=20 From nobody Thu Oct 10 10:10:52 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F9C1200F6 for ; Thu, 10 Oct 2019 10:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 XddBAj-foGSn for ; Thu, 10 Oct 2019 10:10:49 -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 C50D11200E6 for ; Thu, 10 Oct 2019 10:10:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 42336300AEF for ; Thu, 10 Oct 2019 13:10:47 -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 OG_GVSDCpJ1h for ; Thu, 10 Oct 2019 13:10:45 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 24FBA300250; Thu, 10 Oct 2019 13:10:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: Date: Thu, 10 Oct 2019 13:10:45 -0400 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <13252053-7DD8-4C76-AC74-E5E0A31D4F40@vigilsec.com> To: "Roman D. Danyliw" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] Proposed LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 17:10:50 -0000 Roman: The LAMPS WG requests a recharter as below. Of course, the milestones = can be adjusted as we work. It would be great if we could beat every = one of them... Russ =3D =3D =3D =3D =3D =3D =3D =3D The PKIX and S/MIME Working Groups have been closed for some time. Some updates have been proposed to the X.509 certificate documents produced=20= by the PKIX Working Group and the electronic mail security documents=20 produced by the S/MIME Working Group. The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working=20 Group is chartered to make updates where there is a known constituency=20= interested in real deployment and there is at least one sufficiently=20 well specified approach to the update so that the working group can=20 sensibly evaluate whether to adopt a proposal. The LAMPS WG is now tackling these topics: 1. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information. As a result, revoking short-lived certificates is unnecessary and pointless. 2. Update the specification for the cryptographic protection of email headers -- both for signatures and encryption -- to improve the implementation situation with respect to privacy, security, usability and interoperability in cryptographically-protected electronic mail. Most current implementations of cryptographically-protected electronic mail protect only the body of the message, which leaves significant=20 room for attacks against otherwise-protected messages. 3. The Certificate Management Protocol (CMP) is specified in RFC 4210, and it offers a vast range of certificate management options. CMP is currently being used in many different industrial environments, but it needs to be tailored to the specific needs of some environments. The LAMPS WG will develop a "lightweight" profile of CMP to more efficiently support of these environments and better facilitate interoperable implementation, while preserving cryptographic algorithm agility. In addition, necessary updates and clarifications to CMP will be specified in a separate document. In addition, the LAMPS WG may investigate other updates to documents produced by the PKIX and S/MIME WG. The LAMPS WG may produce clarifications where needed, but the LAMPS WG shall not adopt anything beyond clarifications without rechartering. PROPOSED MILESTONES Nov 2020 Short-lived certificate conventions sent to IESG = for BCP publication Nov 2019 Adopt a draft for short-lived certificate conventions=20 Mar 2021 Header protection conventions sent to IESG for = standards track publication Dec 2019 Adopt a draft for header protection conventions Nov 2020 CMP updates sent to IESG for standards track = publication Dec 2019 Adopt a draft for CMP updates Nov 2020 Lightweight CMP profile sent to IESG for = informational publication Dec 2019 Adopt a draft for Lightweight CMP profile From nobody Mon Oct 14 05:29:42 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994C1120274 for ; Mon, 14 Oct 2019 05:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=x500.eu 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 paUW8W1vX8eh for ; Mon, 14 Oct 2019 05:29:37 -0700 (PDT) Received: from outscan1.mf.dandomain.dk (outscan1.mf.dandomain.dk [212.237.249.58]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5599E1202DD for ; Mon, 14 Oct 2019 05:29:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by outscan1.mf.dandomain.dk (Postfix) with ESMTP id A646A4054A18 for ; Mon, 14 Oct 2019 14:29:34 +0200 (CEST) Received: from outscan1.mf.dandomain.dk ([127.0.0.1]) by localhost (outscan1.mf.dandomain.dk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2ab0C9UvmRK for ; Mon, 14 Oct 2019 14:29:33 +0200 (CEST) Received: from mail-proxy.dandomain.dk (dilvs03.dandomain.net [194.150.112.64]) by outscan1.mf.dandomain.dk (Postfix) with ESMTPA id 573E34054A1D for ; Mon, 14 Oct 2019 14:29:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=x500.eu; s=dandomain; t=1571056173; bh=HS/ic/3uRN4f5+mgTV2h8laG96DvFQzBQkvkYlYNc1s=; h=From:To:References:In-Reply-To:Subject:Date:From; b=cHGshQA8vNtBm6u9CpZaNXlk0nBgnOQIN+RBdpT1BK2BxK4e0wJW2ub9m7Nz9QEY9 wyG4GtKp0AAL3kXGvJfQJKFiC6dnUijGOTetkrg21K+uDv9WnUFYZBTzXQpGqlwN4n CuUWPzSL7Fdoj3Sa3yMl4hv75WUXjfIQB9r/MdXQEbqp8C6KXMoo/09mhXgpb7BqjI xx9zlGKQP5DdwiQAteyao9dYPA4wFK6typJ+i8SQVcT+ZjG+Mv6Ykjmp2me2cPcRex IIsqcqWbvTsSjwy9nrVPju5/ZsH7bEcGBvAHCXG2HQ0yhmSeUJxP0w/iJK1vQXJ/J0 qmHGG3PqMy3Dg== From: "Erik Andersen" To: "'LAMPS'" References: <000601d57081$5afa8fc0$10efaf40$@x500.eu> <01fd886909e94b0ab9c353958f46a45e@PMSPEX05.corporate.datacard.com> <002201d572b2$0815f6e0$1841e4a0$@x500.eu> In-Reply-To: Date: Mon, 14 Oct 2019 14:29:32 +0200 Message-ID: <000601d5828b$089cdaa0$19d68fe0$@x500.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQISoDp2LBZNpXW83TH/US3RFiUrOAFnm8W/AmSLsb4Byz/iDqaxzZ1Q Content-Language: en-gb Archived-At: Subject: Re: [lamps] [EXTERNAL] X.510 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 12:29:41 -0000 Hi Mike, Jim, Russ and others, In X.509 and X.510 we have mostly been concentrating on establishing migration paths. Using multiple algorithms for added security was not = the scope, although some of our ASN.1 construct could be used for that = purpose. In our work we have considered the basic public-key certificate = structure sacred in order not to cause backward compatibility problems. That is = why we adopted the ISARA approach. We did not dare to add duplicate signatures = on the certificate itself. We would then also need to duplicate the = signature component in order to protect all the used digital signature algorithms. That would break a lot of applications. The ISARA solution was added to X.509, not X.510. X.509 together with the rest of the X.500 series have = been approved, the master is with the ITU-T editing team and therefore out of = my jurisdictions. As far as public-key certificates, attribute = certificates, CRLs and authorization and validation lists, it is too late to make any changes. When using double algorithms and signature, it is important that the alternative algorithms and signature can be ignored by a legacy entity. X.510, which is not yet an officially part of the X.500 series, is = getting close to completion. In clause 6.4.1 we have a MULTY-SIGNED = parameterized data type that seems to do the same thing as the sa-CompositeSignature object specified in the Internet Draft. This MULTY-SIGNED data type is = an expansion of the SIGNED data type. It appears to me we have a general problem with the use of ASN.1 between = the two organizations. The Internet draft make reference to ASN.1 = information object classes specified in RFC 5912. This RFC redefine a number of information object classes, such as ATTRIBUTE, MATCHING-RULE, EXTENSION = and ALGORITHM and it adds a lot of new information object classes not used = in the by X.509 or X.510. Alignment will probably require quite extensive negotiation between the = two organizations. Best regards, Erik -----Oprindelig meddelelse----- Fra: Mike Ounsworth [mailto:Mike.Ounsworth@entrustdatacard.com]=20 Sendt: 01 October 2019 17:23 Til: Erik Andersen ; 'LAMPS' Emne: RE: [lamps] [EXTERNAL] X.510 Hi Erik, This is joint feedback on X.510 from the group of authors who worked on = the composite pubic keys and signatures draft (https://tools.ietf.org/html/draft-ounsworth-pq-composite-sigs-01) and = some overlap with the authors of the hybrid certificates draft (https://tools.ietf.org/html/draft-truskovsky-lamps-pq-hybrid-x509-01) = which is now being pursued at ITU-T by ISARA. 1. X.510 section 6 defines MultiplePublicKeyAlgo identifiers and params, but seems to be missing a definition of the public keys = themselves. If the idea is to concatenate multiple public keys into the single = existing octet string, it's probably important to define that encoding. See our = draft for how we thought to define that structure: https://tools.ietf.org/html/draft-ounsworth-pq-composite-sigs-01#section-= 2.3 . 2. X.510 Annex G: the mechanism you define relies on the use of ASN.1 extension marks, which were introduced to the SIGNED structure in X.509 = rev 7 (2012), and are not included in the ASN.1 structures of the X.509 = profile in IETF RFC5280 (2008). I see that you address that on p. 72 in the paragraph "If extension marks are not supported", basically saying to = use the MultiplePublicKey definitions from section 6. This is not a problem = for your draft, but we wanted to point out on this mailing list that IETF = and WebPKI can't use the mechanism proposed in Annex G without updating = RFC5280 and relying implementations to support ASN.1 extension marks. 3. For both mechanisms (section 6, and Annex G), have you thought about stripping attacks, where say the attacker cracks the weaker of the two signatures and then replaces the other public key with one that he = controls? I suppose this needs to be addressed at the protocol layer, and = therefore is out of scope for section 6 / annex G, but we still wanted to mention it = on this mailing list. 4. Perhaps it makes sense to harmonize the ASN.1 structures between X.510 and our IETF draft(s). Would you be open to joining a phone call = with our author group? -Mike Ounsworth, Representing the authors of draft-ounsworth-pq-composite-sigs -----Original Message----- From: Spasm On Behalf Of Erik Andersen Sent: Tuesday, September 24, 2019 3:28 AM To: 'LAMPS' Cc: Mark Pecen ; Jean-Paul LEMAIRE Subject: Re: [lamps] [EXTERNAL] X.510 Hi Mike, A good point. Having multiple algorithms for added security and not just = for migration is not really considered in draft X.510, which could be a = miss. We will see if we can get that aspect into document during its final ballot round where in principle only editorials are allowed. Anyway, we will probably need an edition 2 quite quickly. Best regards, Erik -----Oprindelig meddelelse----- Fra: Spasm [mailto:spasm-bounces@ietf.org] P=E5 vegne af Mike Ounsworth Sendt: 24 September 2019 05:51 Til: Erik Andersen ; LAMPS Emne: Re: [lamps] [EXTERNAL] X.510 Hi Erik, I found your slides https://docbox.etsi.org/Workshop/2019/201906_ETSISECURITYWEEK/202106_Dyna= mic NatureOfTechno/SESSION03_CHANGINGCRYPTOGRAPHY/ANDERSENSLSERVICES_ANDERSEN= .pd f, explaining the rationale behind X.510. In it, you say: * A back level recipient will ignore the alternative algorithm, but = validate according to the native one * An advanced recipient will validate according to the alternative = algorithm In attending post-quantum conferences, for example the NIST PQC, there = is a strong call for "hybrid" modes where *both* algorithms are validated = because we don't fully trust the new stuff yet. So this may not be simply a migration issue, but a more long-term issue of combining algorithms for increased security. Do you have an opinion on whether X.510 in its current form would be appropriate for hybrid modes, and whether your language should be = adjusted to be "native algorithm and alt algorithm" as opposed to your current "native algorithm or alt algorithm" ? - - - Mike Ounsworth | Office: +1 (613) 270-2873 From: Spasm On Behalf Of Erik Andersen Sent: Saturday, September 21, 2019 8:35 AM To: LAMPS Subject: [EXTERNAL][lamps] X.510 WARNING: This email originated outside of Entrust Datacard. DO NOT CLICK links or attachments unless you trust the sender and know = the content is safe. ________________________________________ Within ITU-T and ISO we have developed a new specification, Rec. ITU-T = X.510 | ISO/IEC 9594-11, which now is out for final vote. There is a link to=20 | it https://www.dropbox.com/s/qzzuy9hu2vjz9qw/X.510-dis.pdf?dl=3D0. We = expect to complete it by March 2020. Any comment any of you might have will be highly appreciated. Best regards, Erik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Wed Oct 16 06:47:27 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43301200D5 for ; Wed, 16 Oct 2019 06:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=x500.eu 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 KtcGEOuHtWje for ; Wed, 16 Oct 2019 06:47:21 -0700 (PDT) Received: from outscan1.mf.dandomain.dk (outscan1.mf.dandomain.dk [212.237.249.58]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95AA112006B for ; Wed, 16 Oct 2019 06:47:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by outscan1.mf.dandomain.dk (Postfix) with ESMTP id 427604068A72; Wed, 16 Oct 2019 15:47:19 +0200 (CEST) Received: from outscan1.mf.dandomain.dk ([127.0.0.1]) by localhost (outscan1.mf.dandomain.dk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NO-HuWfMxVe; Wed, 16 Oct 2019 15:47:18 +0200 (CEST) Received: from mail-proxy.dandomain.dk (dilvs03.dandomain.net [194.150.112.64]) by outscan1.mf.dandomain.dk (Postfix) with ESMTPA id C499040689D0; Wed, 16 Oct 2019 15:47:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=x500.eu; s=dandomain; t=1571233638; bh=/4ebB6aiCWkWIIg4pJbJk2o5K9oGfpr2b2XMzbwjlhE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:From; b=CqbG1mOO2ilk/HvC8/aZSRZmQsbOuTELyUPyHhFuk136F+KEbaLLADwDaHdzRMxDM Z56UYkcgC+aITe6KbKlG9yAYAcC1GtViauyOFmBeJ3pCbAgLHNTKZdUXRWVYomxBkw 5gAcH40/JpVSqRO1WEBrFjJZH/KbdvWGRIongkyFtW4jafC+0etK8CtMEPKXed1Tql CGLeRuZpgP8R6hmZ3xfOETPCO77zuKnTqVVEuvjHeULNmipzm8+UYjtTz8WOhSY6wU RWidu8RBdk4SKAIj1GPT/XTWvHHpI1w7HdkOzVRF0S/GBfnGPORHQR5k4pHlZyKicX bepC+kV6hhMuQ== From: "Erik Andersen" To: "'Max Pala'" Cc: "'Mike Ounsworth'" , "LAMPS" References: <000601d57081$5afa8fc0$10efaf40$@x500.eu> <01fd886909e94b0ab9c353958f46a45e@PMSPEX05.corporate.datacard.com> <002201d572b2$0815f6e0$1841e4a0$@x500.eu> <001201d57931$5cf5aae0$16e100a0$@x500.eu> <308C443D-1AB3-4D6F-959B-B4AD5649E757@cablelabs.com> In-Reply-To: <308C443D-1AB3-4D6F-959B-B4AD5649E757@cablelabs.com> Date: Wed, 16 Oct 2019 15:47:15 +0200 Message-ID: <002601d58428$39ed7800$adc86800$@x500.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQISoDp2LBZNpXW83TH/US3RFiUrOAFnm8W/AmSLsb4Byz/iDgI39cnCAuCbG7gDTSVZCQIiCZT8pmHWRGA= Content-Language: en-gb Archived-At: Subject: Re: [lamps] [EXTERNAL] X.510 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 13:47:26 -0000 Hi Max, Thanks for your comments. They are useful. Currently the work on X.510 and the Internet draft have no overlap and = they have different scopes. The X.510 concentrates on migration issues = and requires only a single signature to be verified. We not are = considering multiple signatures to be verified for added security, = although this could be added but it would have to be combined with the = migration issue (how do we migrate from current use of a single digital = signature to use multiple signatures to be verified). Avoiding multiple specification with the same scope can only be done if = only one organization develops the specification and the other one = unitizes it. However, it becomes difficult if our use of ASN.1 is quite = different. It will difficult to adapt the information object classes = defined in RFC 5912 to our specification and to the specifications = within smart grid security (IEC TC 57 WG 15), where it has been accepted = to refer to X.509 rather than RFC 5280 to make use of the new = capabilities added to X.509. Best regards, Erik=20 -----Oprindelig meddelelse----- Fra: Max Pala [mailto:M.Pala@cablelabs.com]=20 Sendt: 15 October 2019 01:55 Til: Erik Andersen Cc: Mike Ounsworth Emne: Re: [lamps] [EXTERNAL] X.510 Hi Erik, Mike, I just wanted to take the opportunity to introduce myself - I am = Massimiliano ("Max") Pala, one of the authors of the draft and original = author behind the OpenCA projects and labs. I also wanted to join Mike in stressing the importance of not having = multiple specifications - I am currently working for CableLabs and we = manage and run the DOCSIS(r) PKI - which is one of the largest PKIs in = the world with roughly 3 Billions certificates installed and deployed in = devices across the whole world. Our work has originated from the need to = protect our PKI(s) for the next 50 years and we needed a new tool to = secure our Trust Infrastructure in these uncertain times. Our interest, = however, it is not only for the Cable industry - we do work closely with = many ecosystems where we provide certification services (from OCF to = SunSpec, from CMI to WBA): also these environment require solutions that = can help protecting their assets even before the factorization problem = becomes a reality (and a security nightmare for everybody __). I am looking forward to our conversation and future collaboration - I = think we have a simple, elegant, and useful solution/tool for our PKI = toolboxes and the right time has come to finally standardize it. Again, very nice to virtually "meet" you and looking forward to future = collaborations! Cheers, Max =EF=BB=BFOn 10/10/19, 8:06 AM, "Mike Ounsworth" = wrote: FYI =20 - - - Mike Ounsworth | Office: +1 (613) 270-2873 =20 -----Original Message----- From: Mike Ounsworth=20 Sent: Wednesday, October 2, 2019 10:52 AM To: Erik Andersen Subject: RE: [lamps] [EXTERNAL] X.510 =20 Thanks Erik! =20 Our group has put over 2 years of bi-weekly meetings into this = topic, so I hope we have some valuable ideas to contribute! =20 Perfect, let me know when you are back from your travels. I look = forward to a chat. =20 - - - Mike Ounsworth | Office: +1 (613) 270-2873 =20 -----Original Message----- From: Erik Andersen Sent: Wednesday, October 2, 2019 9:55 AM To: Mike Ounsworth Subject: SV: [lamps] [EXTERNAL] X.510 =20 Hi Mike, =20 Thanks a lot for your answer. I am quite interesting in your = proposal. Having competing specifications is not good for the industry.=20 =20 Next week I am going to a meeting in IEC TC57 WG15 on smart grid = security and quite busy preparing. When returning I will come back to = you. In the meantime, I will read your draft. I have read the ISARA = internet draft. =20 Best regards, =20 Erik =20 -----Oprindelig meddelelse----- Fra: Mike Ounsworth [mailto:Mike.Ounsworth@entrustdatacard.com] Sendt: 01 October 2019 17:23 Til: Erik Andersen ; 'LAMPS' Emne: RE: [lamps] [EXTERNAL] X.510 =20 Hi Erik, =20 This is joint feedback on X.510 from the group of authors who worked = on the composite pubic keys and signatures draft (https://tools.ietf.org/html/draft-ounsworth-pq-composite-sigs-01) = and some overlap with the authors of the hybrid certificates draft = (https://tools.ietf.org/html/draft-truskovsky-lamps-pq-hybrid-x509-01) = which is now being pursued at ITU-T by ISARA. =20 1. X.510 section 6 defines MultiplePublicKeyAlgo identifiers and params, but seems to be missing a definition of the public keys = themselves. If the idea is to concatenate multiple public keys into the single = existing octet string, it's probably important to define that encoding. = See our draft for how we thought to define that structure: = https://tools.ietf.org/html/draft-ounsworth-pq-composite-sigs-01#section-= 2.3 . =20 2. X.510 Annex G: the mechanism you define relies on the use of = ASN.1 extension marks, which were introduced to the SIGNED structure in = X.509 rev 7 (2012), and are not included in the ASN.1 structures of the X.509 = profile in IETF RFC5280 (2008). I see that you address that on p. 72 in = the paragraph "If extension marks are not supported", basically saying = to use the MultiplePublicKey definitions from section 6. This is not a = problem for your draft, but we wanted to point out on this mailing list = that IETF and WebPKI can't use the mechanism proposed in Annex G without = updating RFC5280 and relying implementations to support ASN.1 extension = marks. =20 3. For both mechanisms (section 6, and Annex G), have you thought = about stripping attacks, where say the attacker cracks the weaker of the = two signatures and then replaces the other public key with one that he = controls? I suppose this needs to be addressed at the protocol layer, and = therefore is out of scope for section 6 / annex G, but we still wanted = to mention it on this mailing list. =20 4. Perhaps it makes sense to harmonize the ASN.1 structures between X.510 and our IETF draft(s). Would you be open to joining a phone = call with our author group? =20 -Mike Ounsworth, Representing the authors of draft-ounsworth-pq-composite-sigs =20 -----Original Message----- From: Spasm On Behalf Of Erik Andersen Sent: Tuesday, September 24, 2019 3:28 AM To: 'LAMPS' Cc: Mark Pecen ; Jean-Paul LEMAIRE = Subject: Re: [lamps] [EXTERNAL] X.510 =20 Hi Mike, =20 A good point. Having multiple algorithms for added security and not = just for migration is not really considered in draft X.510, which could = be a miss. We will see if we can get that aspect into document during = its final ballot round where in principle only editorials are allowed. = Anyway, we will probably need an edition 2 quite quickly. =20 Best regards, =20 Erik =20 -----Oprindelig meddelelse----- Fra: Spasm [mailto:spasm-bounces@ietf.org] P=C3=A5 vegne af Mike = Ounsworth Sendt: 24 September 2019 05:51 Til: Erik Andersen ; LAMPS Emne: Re: [lamps] [EXTERNAL] X.510 =20 Hi Erik, =20 I found your slides = https://docbox.etsi.org/Workshop/2019/201906_ETSISECURITYWEEK/202106_Dyna= mic = NatureOfTechno/SESSION03_CHANGINGCRYPTOGRAPHY/ANDERSENSLSERVICES_ANDERSEN= .pd f, explaining the rationale behind X.510. In it, you say: =20 * A back level recipient will ignore the alternative algorithm, but = validate according to the native one * An advanced recipient will validate according to the alternative = algorithm =20 In attending post-quantum conferences, for example the NIST PQC, = there is a strong call for "hybrid" modes where *both* algorithms are = validated because we don't fully trust the new stuff yet. So this may = not be simply a migration issue, but a more long-term issue of combining = algorithms for increased security. Do you have an opinion on whether X.510 in its current form would be = appropriate for hybrid modes, and whether your language should be = adjusted to be "native algorithm and alt algorithm" as opposed to your = current "native algorithm or alt algorithm" ? =20 - - - Mike Ounsworth | Office: +1 (613) 270-2873 =20 From: Spasm On Behalf Of Erik Andersen Sent: Saturday, September 21, 2019 8:35 AM To: LAMPS Subject: [EXTERNAL][lamps] X.510 =20 WARNING: This email originated outside of Entrust Datacard. DO NOT CLICK links or attachments unless you trust the sender and = know the content is safe. ________________________________________ Within ITU-T and ISO we have developed a new specification, Rec. = ITU-T X.510 | ISO/IEC 9594-11, which now is out for final vote. There is a link = to=20 | it https://www.dropbox.com/s/qzzuy9hu2vjz9qw/X.510-dis.pdf?dl=3D0. We = expect to complete it by March 2020. =20 Any comment any of you might have will be highly appreciated. =20 Best regards, =20 Erik =20 _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm =20 _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm =20 =20 From nobody Wed Oct 23 10:44:18 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06881120BE7 for ; Wed, 23 Oct 2019 10:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 WUKx0bGCSXWR for ; Wed, 23 Oct 2019 10:44:15 -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 6A0311201DE for ; Wed, 23 Oct 2019 10:44:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EA695300B13 for ; Wed, 23 Oct 2019 13:44:13 -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 TyNRGC58pMZy for ; Wed, 23 Oct 2019 13:44:12 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id BCC023002AD for ; Wed, 23 Oct 2019 13:44:12 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_C2FE5E0C-7B59-4CDF-A7B7-43124F0825FC" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <5DAAAAB3-B2F1-4551-8F54-21795203DDD0@vigilsec.com> Date: Wed, 23 Oct 2019 13:44:13 -0400 To: LAMPS WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] LAMPS at IETF 106 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2019 17:44:17 -0000 --Apple-Mail=_C2FE5E0C-7B59-4CDF-A7B7-43124F0825FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Here is the proposed agenda. Please review and comment. I note that we = have a chartered topic on short-lived X.509 certificates, but no one has = asked for a slot on that topic. I hope that section 2 of the agenda will take no time at all. Maybe = these documents will even be RFCs by the time we get to Singapore. Russ =3D =3D =3D =3D =3D =3D =3D =3D LAMPS WG Agenda at IETF 106 in Singapore 0) Minute Taker, Jabber Scribe, Bluesheets 1) Agenda Bash 2) Documents with the RFC Editor and IESG a) draft-ietf-lamps-pkix-shake (Panos, Quynh) b) draft-ietf-lamps-cms-shakes (Quynh, Panos) c) draft-ietf-lamps-cms-hash-sig (Russ) d) draft-ietf-lamps-cms-mix-with-psk (Russ) 3) Active Working Group Documents a) draft-ietf-lamps-header-protection-requirements (Alexey, Bernie) 4) Documents related to the proposed re-charter a) draft-brockhaus-lamps-lightweight-cmp-profile (Hendrik) b) draft-brockhaus-lamps-cmp-updates (Hendrik) c) draft-housley-lamps-cms-update-alg-id-protect (Russ) 5) Other Business (if time allows) a) OCSPv2 (Max) 6) Wrap Up =20 =20= --Apple-Mail=_C2FE5E0C-7B59-4CDF-A7B7-43124F0825FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


Here is the proposed agenda.  Please = review and comment. I note that we have a chartered topic on short-lived = X.509 certificates, but no one has asked for a slot on that = topic.

I hope = that section 2 of the agenda will take no time at all.  Maybe these = documents will even be RFCs by the time we get to Singapore.

Russ

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

LAMPS = WG Agenda at IETF 106 in Singapore

0)  Minute Taker, Jabber Scribe, = Bluesheets

1) =  Agenda Bash

2)  Documents with the RFC Editor and IESG
    a)  draft-ietf-lamps-pkix-shake (Panos, = Quynh)
    b) =  draft-ietf-lamps-cms-shakes (Quynh, Panos)
    c)  draft-ietf-lamps-cms-hash-sig = (Russ)
    d) =  draft-ietf-lamps-cms-mix-with-psk (Russ)

3)  Active Working Group = Documents
    a) =  draft-ietf-lamps-header-protection-requirements (Alexey, = Bernie)

4) =  Documents related to the proposed re-charter
    a) =  draft-brockhaus-lamps-lightweight-cmp-profile (Hendrik)
    b)  draft-brockhaus-lamps-cmp-updates = (Hendrik)
    c) =  draft-housley-lamps-cms-update-alg-id-protect (Russ)

5)  Other Business = (if time allows)
    a)  OCSPv2 = (Max)

6) =  Wrap Up
 

 

= --Apple-Mail=_C2FE5E0C-7B59-4CDF-A7B7-43124F0825FC-- From nobody Thu Oct 24 08:01:19 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E7B1209AA for ; Thu, 24 Oct 2019 08:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 VnM5rCpD3ea7 for ; Thu, 24 Oct 2019 08:01:14 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 509FC1208CC for ; Thu, 24 Oct 2019 08:01:14 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 1F0BA374137D for ; Thu, 24 Oct 2019 15:01:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vBKwJGHjFwFK for ; Thu, 24 Oct 2019 11:01:12 -0400 (EDT) Received: from Maxs-MBP-2.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id BEA47374107C for ; Thu, 24 Oct 2019 11:01:12 -0400 (EDT) To: LAMPS WG From: "Dr. Pala" Message-ID: <8c84cf2c-c192-c13b-17e5-7ae09b748530@openca.org> Date: Thu, 24 Oct 2019 09:01:12 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------7E8A4155E4185C847049FB45" Content-Language: en-US Archived-At: Subject: [lamps] The Status of OCSP and its future X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 15:01:17 -0000 This is a multi-part message in MIME format. --------------7E8A4155E4185C847049FB45 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi All, I just wanted to start the conversation around the status of revocation infrastructures and possible work we can be doing to address some of new issues deriving from the deployment of large PKIs. In particular, we are working on the optimization of the OCSP protocol to better serve some of the use-cases we have. Specifically, for very large PKIs (i.e., few hundreds million certificates valid at any given time), the OCSP protocol does not scale well. In fact, taking into consideration how we operate OCSP responders today, the larger the PKI is, the higher the costs of providing a good revocation infrastructure is. Our approach stem from two practical considerations: the occasion to provide optimized responses for the non-revoked case, and the possibility to reduce the number of round trips required to retrieve the revocation status for the full chain of certificates. In particular: * /*Optimizing for the common case (non-revoked certificate).*/ In particular, for certificates that have no revocation information, we do not have to provide specific responses for each individual certificate (as we do in the revoked case), but we can provide responses for ranges of certificates where the status is not revoked. In a PKI with a population of 100M certificate and a revocation rate of 5%, using "range" response types reduces the need for calculating OCSP responses from 100M to 1M (i.e. 2N + 1 where N is the population of revoked certificates). This allows to pre-generate responses more quickly, allows for lower costs of running the revocation infrastructure, and it is better for the planet :D * /*Providing Full Chain responses.*/ Although single OCSP responders can be authoritative for their own CA only, they can attach the responses for the full chain as additional data. If we add this possibility, then a single OCSP request can provide the client/server with the full chain of certificates up to the Root. This might be tricky in complex scenarios where cross-certification is used, but it would definitely work for the Web PKI and IoT use cases. Given these considerations - and the fact that large PKIs are being deployed, today, for the IoT case - we would like to start the discussion around the current status of OCSP and possibly work on a proposal for moving forward with a more efficient protocol. What do you think ? Anybody would like to tackle this problem together ? Cheers, Max -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------7E8A4155E4185C847049FB45 Content-Type: multipart/related; boundary="------------2203B2F05E88B4060DDD5D11" --------------2203B2F05E88B4060DDD5D11 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi All,

I just wanted to start the conversation around the status of revocation infrastructures and possible work we can be doing to address some of new issues deriving from the deployment of large PKIs. In particular, we are working on the optimization of the OCSP protocol to better serve some of the use-cases we have.

Specifically, for very large PKIs (i.e., few hundreds million certificates valid at any given time), the OCSP protocol does not scale well. In fact, taking into consideration how we operate OCSP responders today, the larger the PKI is, the higher the costs of providing a good revocation infrastructure is.

Our approach stem from two practical considerations: the occasion to provide optimized responses for the non-revoked case, and the possibility to reduce the number of round trips required to retrieve the revocation status for the full chain of certificates. In particular:

  • Optimizing for the common case (non-revoked certificate). In particular, for certificates that have no revocation information, we do not have to provide specific responses for each individual certificate (as we do in the revoked case), but we can provide responses for ranges of certificates where the status is not revoked. In a PKI with a population of 100M certificate and a revocation rate of 5%, using "range" response types reduces the need for calculating OCSP responses from 100M to 1M (i.e. 2N + 1 where N is the population of revoked certificates). This allows to pre-generate responses more quickly, allows for lower costs of running the revocation infrastructure, and it is better for the planet :D

  • Providing Full Chain responses. Although single OCSP responders can be authoritative for their own CA only, they can attach the responses for the full chain as additional data. If we add this possibility, then a single OCSP request can provide the client/server with the full chain of certificates up to the Root. This might be tricky in complex scenarios where cross-certification is used, but it would definitely work for the Web PKI and IoT use cases.

Given these considerations - and the fact that large PKIs are being deployed, today, for the IoT case - we would like to start the discussion around the current status of OCSP and possibly work on a proposal for moving forward with a more efficient protocol.

What do you think ? Anybody would like to tackle this problem together ?

Cheers,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------2203B2F05E88B4060DDD5D11 Content-Type: image/png; name="edlnajaiinmgcjll.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="edlnajaiinmgcjll.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------2203B2F05E88B4060DDD5D11-- --------------7E8A4155E4185C847049FB45-- From nobody Thu Oct 24 08:37:50 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EBB1208BE for ; Thu, 24 Oct 2019 08:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.226, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 JN72FCra8Myk for ; Thu, 24 Oct 2019 08:37:47 -0700 (PDT) Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) (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 434EC1209D8 for ; Thu, 24 Oct 2019 08:37:47 -0700 (PDT) Received: by mail-ed1-f52.google.com with SMTP id r4so18998072edy.4 for ; Thu, 24 Oct 2019 08:37:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pQMfAbYM24vmUf9PKDhihiDv6lN1TSQTJpYFOenBtAk=; b=mBvbLC8JxPfpKNPD8X8W9aIykSV4hWxEL7CG8EzExLG9n/o7gqZRvyVGnow8cQbOVD MLPMVJSVlIMJu5SwDaZ3ulVxaf+ebXvwHPjK6GATV/z0oEjoxW0VIhI9KeWwdbavEng/ Q2dvqEtMfHpDGkiMFK5PdpHxHqwVok1oZ9kX9cxWfM1WJARiA+RUIhN2bMtWg9c0JJx6 jd12ks2ojr6khJMb0bI++h5y5yJnuNPWoxuSdGTaSr03lUTT5ITxhCQZyxWxF9r9bcbs FP6k+7YkHWlBL/tbe22VkYUWFqUr6SQIwIvHx/CsDEQhUxXEeMUqPYU1S/qy2RfZMDFY 42+w== X-Gm-Message-State: APjAAAXN2Sh9IFX/o7NMqdKnM2O3mHRtLL0Y3SYV4VkLO7j+7qvBaTi8 av0CLXPu/p6JRexAyu0mHPOX/CuJ X-Google-Smtp-Source: APXvYqx7t1/IJeLqzC196Irh5+ih9DMMPSp51D52YsCNzMcwhijqc9L6sZQfhHj0PeffYZA3l0Uc+w== X-Received: by 2002:a17:906:5bcf:: with SMTP id w15mr17307471ejs.84.1571931465285; Thu, 24 Oct 2019 08:37:45 -0700 (PDT) Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com. [209.85.221.46]) by smtp.gmail.com with ESMTPSA id h14sm229159edq.70.2019.10.24.08.37.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Oct 2019 08:37:45 -0700 (PDT) Received: by mail-wr1-f46.google.com with SMTP id s1so17847631wro.0 for ; Thu, 24 Oct 2019 08:37:44 -0700 (PDT) X-Received: by 2002:adf:ab5b:: with SMTP id r27mr4627671wrc.13.1571931464610; Thu, 24 Oct 2019 08:37:44 -0700 (PDT) MIME-Version: 1.0 References: <8c84cf2c-c192-c13b-17e5-7ae09b748530@openca.org> In-Reply-To: <8c84cf2c-c192-c13b-17e5-7ae09b748530@openca.org> From: Ryan Sleevi Date: Thu, 24 Oct 2019 11:37:33 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Dr. Pala" Cc: LAMPS WG Content-Type: multipart/related; boundary="0000000000008f66300595a9d0a2" Archived-At: Subject: Re: [lamps] The Status of OCSP and its future X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 15:37:49 -0000 --0000000000008f66300595a9d0a2 Content-Type: multipart/alternative; boundary="0000000000008f662e0595a9d0a1" --0000000000008f662e0595a9d0a1 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 24, 2019 at 11:01 AM Dr. Pala wrote: > Hi All, > > I just wanted to start the conversation around the status of revocation > infrastructures and possible work we can be doing to address some of new > issues deriving from the deployment of large PKIs. In particular, we are > working on the optimization of the OCSP protocol to better serve some of > the use-cases we have. > > Specifically, for very large PKIs (i.e., few hundreds million certificates > valid at any given time), the OCSP protocol does not scale well. In fact, > taking into consideration how we operate OCSP responders today, the larger > the PKI is, the higher the costs of providing a good revocation > infrastructure is. > > Our approach stem from two practical considerations: the occasion to > provide optimized responses for the non-revoked case, and the possibility > to reduce the number of round trips required to retrieve the revocation > status for the full chain of certificates. > Don't CRLs address this use case? That is, it's not clear "Why OCSP" vs "Why not something else" in your overall message here. > In particular: > > - *Optimizing for the common case (non-revoked certificate).* In > particular, for certificates that have no revocation information, we do not > have to provide specific responses for each individual certificate (as we > do in the revoked case), but we can provide responses for ranges of > certificates where the status is not revoked. In a PKI with a population of > 100M certificate and a revocation rate of 5%, using "range" response types > reduces the need for calculating OCSP responses from 100M to 1M (i.e. 2N + > 1 where N is the population of revoked certificates). This allows to > pre-generate responses more quickly, allows for lower costs of running the > revocation infrastructure, and it is better for the planet :D > > On a conceptual level, how is the concept of "Signed status information for a range of certificates" functionally or conceptually different than a CRL, potentially sharded (e.g. by varying the issuerDistributionPoint extension within the CRL and the crlDistributionPoint within the range of certificates). As best I can tell, the only difference is that it allows the CA to rebalance the ranges post-issuance, but it's unclear if that's either good or desirable from a validator perspective. > > - *Providing Full Chain responses.* Although single OCSP responders > can be authoritative for their own CA only, they can attach the responses > for the full chain as additional data. If we add this possibility, then a > single OCSP request can provide the client/server with the full chain of > certificates up to the Root. This might be tricky in complex scenarios > where cross-certification is used, but it would definitely work for the Web > PKI and IoT use cases. > > Similarly, this is unclear the set of problems you're trying to solve. Did you mean to provide status information about the full chain? Or did you actually meant the full chain? Clients already presumably have the full chain, as they're using OCSP in the context of RFC 5280 path validation. If the goal is to be able to use this within protocols that make OCSP available (e.g. TLS), then you already have the means to deliver the additional certificates. So I'm not sure how to interpret this suggestion here, and/or why OCSP is somehow the appropriate technology for it. --0000000000008f662e0595a9d0a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Oct 24, 2019 at 11:01 AM Dr. = Pala <madwolf@openca.org> w= rote:
=20 =20 =20

Hi All,

I just wanted to start the conversation around the status of revocation infrastructures and possible work we can be doing to address some of new issues deriving from the deployment of large PKIs. In particular, we are working on the optimization of the OCSP protocol to better serve some of the use-cases we have.

Specifically, for very large PKIs (i.e., few hundreds million certificates valid at any given time), the OCSP protocol does not scale well. In fact, taking into consideration how we operate OCSP responders today, the larger the PKI is, the higher the costs of providing a good revocation infrastructure is.

Our approach stem from two practical considerations: the occasion to provide optimized responses for the non-revoked case, and the possibility to reduce the number of round trips required to retrieve the revocation status for the full chain of certificates.

Don't CRLs address this use case?
That is, it's not clear "Why OCSP" vs "Why = not something else" in your overall message here.=C2=A0

In particular:

  • Optimizing for the common case (non-revoked certificate). In particular, for certificates that have no revocation information, we do not have to provide specific responses for each individual certificate (as we do in the revoked case), but we can provide responses for ranges of certificates where the status is not revoked. In a PKI with a population of 100M certificate and a revocation rate of 5%, using "range" response types reduces the need for calcula= ting OCSP responses from 100M to 1M (i.e. 2N + 1 where N is the population of revoked certificates). This allows to pre-generate responses more quickly, allows for lower costs of running the revocation infrastructure, and it is better for the planet :D
On a conceptual level, how is the concept o= f "Signed status information for a range of certificates" functio= nally or conceptually different than a CRL, potentially sharded (e.g. by va= rying the issuerDistributionPoint extension within the CRL and the crlDistr= ibutionPoint within the range of certificates).

As= best I can tell, the only difference is that it allows the CA to rebalance= the ranges post-issuance, but it's unclear if that's either good o= r desirable from a validator perspective.
=C2=A0
  • Providing Full Chain responses. Although single OCSP responders can be authoritative for their own CA only, they can attach the responses for the full chain as additional data. If we add this possibility, then a single OCSP request can provide the client/server with the full chain of certificates up to the Root. This might be tricky in complex scenarios where cross-certification is used, but it would definitely work for the Web PKI and IoT use cases.
Sim= ilarly, this is unclear the set of problems you're trying to solve. Did= you mean to provide status information about the full chain? Or did you ac= tually meant the full chain?

Clients already presu= mably have the full chain, as they're using OCSP in the context of RFC = 5280 path validation. If the goal is to be able to use this within protocol= s that make OCSP available (e.g. TLS), then you already have the means to d= eliver the additional certificates.

So I'm not= sure how to interpret this suggestion here, and/or why OCSP is somehow the= appropriate technology for it.
--0000000000008f662e0595a9d0a1-- --0000000000008f66300595a9d0a2 Content-Type: image/png; name="edlnajaiinmgcjll.png" Content-Disposition: inline; filename="edlnajaiinmgcjll.png" Content-Transfer-Encoding: base64 Content-ID: <16dfe665f60482ef531> X-Attachment-Id: 16dfe665f60482ef531 iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoXBwES CQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAqMjpXKgs/ MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1SGdDR0lDSFJf RDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27PgCaSANtUT57VBer SQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXaeVR+lVRZrYld1ZiB7YEuS YQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDVWQJ1blapYjbXWgDRXACMaU6W bgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3WqaS6BcGeobwndXwzkXwLgYgDaYwyM eCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuvcEPrZQDQaSyockrFbSvmZwnabQLvZwDp aQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqK gnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXleSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQ iwCximixim/EkAORkZGVkYrOh0rPiVL5giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvK lGqpnJLdlF2boKy+m324nImkoZ+eo6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/S rI7dq4bqqXTOrpWttL+6s6uwtbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfR wbXFyMvbxbPNyMP8zgTczMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp 7/Hy9PHw9fj6/v3YktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPX GT6E+l9BZ0EFsTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+U SgFL4r9gEaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqE SrMplYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75UjLZf p6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/85sH2KeX vj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf70RPUPjxLouB EgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxcAwyWTbacW0sTDGoJ en4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+NpuKpq32qLVaexOCCJB91 aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq1LzUMQ4uxxycjl0LWO1bBsY6 yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XOcajZb6GDu7PTFEdPkVu0k4vQyd3J c/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV 2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRbjuxtfqRypNACK28+j3FsqcilAD0ADuIWCt0y Ra7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7 QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxar lr0grlQn92DQt1vBUk+nUFeHGZmegUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJ o+2PGLb2d9WE5bw1L4DcnOco9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bF zhw3eZylM2dgwkbWW3IyJp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwd ElJmarxedr/u3P6CNn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivo BjrfUgNB69zfb6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toV EevCi9/ffmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzS Y3FuBkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/dY1p7 qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1RgrYlfrRe SqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxHdRJFGJkhfKxg mM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3luaLNe1F++bjXGyWyz ZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCmGIzpqKlm27KTSWUcAX1g oBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJCBVkrrBJ1BewMmlVpgRUQF7wp ItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQYIOhklDKzo2C1IV2sijzdhjorqwef NdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41qKFl02YaswYNkULTeLC9CFFK4bDHDMmZb hnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYvJpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkc Hz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkhmt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlC XaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7Wfg ZOv4uLLl0w8wUah71QLBpJeXq/eMVVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6 vjt1z/ghMehVKiUpyt1VYBXCN6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oE DQ6jB9Wc3Z6bm6zLTtLlgLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgX s2kV4WUC0YR/KOLvPby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP 7LnTfsd42at3+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw90 1G+ttVlTJa34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K +f59qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a8XoA AAAASUVORK5CYII= --0000000000008f66300595a9d0a2-- From nobody Thu Oct 24 09:12:04 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50228120943 for ; Thu, 24 Oct 2019 09:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.226, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 jRB1PXII0IKn for ; Thu, 24 Oct 2019 09:12:00 -0700 (PDT) Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) (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 7869F120A62 for ; Thu, 24 Oct 2019 09:11:53 -0700 (PDT) Received: by mail-oi1-f181.google.com with SMTP id s71so8248789oih.11 for ; Thu, 24 Oct 2019 09:11:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4UXwCsuY2JhWSgDxbnKlkz1NbmTnZXD42U/Q25tRdB4=; b=Y/rHtmbvUB+CDFy63BAraL4e5KUlvr+kGPmKb/XXBRjqBlXfq8jZAvvsLYL7jI+BPY mdx2m3HGdKAWfJtxkR8Ajo4pehhYUgb0jWR8M4z4phXhkXUtga6n5GQUDYBFtTf/83dr pqvXQeED1rlto07HmweX4ldCpSJ2DI9EphoTxeMNEAhkY3Lamu5UaWgrJJol6r3CvUJu Vnmz2OtAErsx84JPQWvIymYre8f/pjHKX0DX0v058/OtytBOlm9y9Efp3pDe+2yK7mdl s0VM1uVEe0Js6ANdhvK05Scsxjv/CeMr6OdFPQHY7vC/AXWLKoGt+K+JMAs2oY92hZ0a PJog== X-Gm-Message-State: APjAAAXmSaoycUMZG7LOxFaU0DNi9+H4/8P0BrlRZSSgkk32pa0kpxyS OTQlVKu/t47hrVA0ORhX0tkFc0BQJtd8cmmVkyc= X-Google-Smtp-Source: APXvYqySodn3ObGxdM6rjeDrzHqdycgizU+k+bVJMz9+SOGVwvof5rhzpDqRR6NcjxbDmQbILhBzH/F2AR2/3RKwB+M= X-Received: by 2002:a54:471a:: with SMTP id k26mr5591508oik.100.1571933512469; Thu, 24 Oct 2019 09:11:52 -0700 (PDT) MIME-Version: 1.0 References: <8c84cf2c-c192-c13b-17e5-7ae09b748530@openca.org> In-Reply-To: <8c84cf2c-c192-c13b-17e5-7ae09b748530@openca.org> From: Phillip Hallam-Baker Date: Thu, 24 Oct 2019 12:11:41 -0400 Message-ID: To: "Dr. Pala" Cc: LAMPS WG Content-Type: multipart/related; boundary="000000000000a02ab90595aa4a25" Archived-At: Subject: Re: [lamps] The Status of OCSP and its future X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 16:12:03 -0000 --000000000000a02ab90595aa4a25 Content-Type: multipart/alternative; boundary="000000000000a02ab80595aa4a24" --000000000000a02ab80595aa4a24 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 24, 2019 at 11:01 AM Dr. Pala wrote: > Given these considerations - and the fact that large PKIs are being > deployed, today, for the IoT case - we would like to start the discussion > around the current status of OCSP and possibly work on a proposal for > moving forward with a more efficient protocol. > > What do you think ? Anybody would like to tackle this problem together ? > I am interested in the problem. I just disagree with the notion that X.509/PKIX is a useful way to think about IoT devices. It is not what the architecture was originally designed to serve and it doesn't actually serve it at all well. The reason we need revocation in the WebPKI is that the primary concern that infrastructure was originally designed to address was the appearance of fake Web Merchants. The design brief was to make online commerce as safe as bricks and mortar. The fundamental concern VeriSign Class 3 was designed to meet was to establish accountability so that posing as a fake Web merchant was unprofitable. And that limited goal was achieved with enormous success. Or at least it was before big tech thought it a good idea to strip out the security signal from the browsers. The problem with the WebPKI is that it does not serve every purpose well. And it has been co-opted to a rather sordid dispute into who can invade users privacy to bombard them with ads and who can't. So we have the current Congressional hearings and the looming anti-Trust lawsuits. People who thought PKIX would be so much better without the lawyers and were happy to see them disappear are going to be in for a nasty shock in the next couple of years. We are long past the point where it is prudent for any of the Web Browser providers with more than 5% market share to allow any of their employees to contribute to discussions on the WebPKI without having every email vetted by company lawyers and company lawyers attend every meeting. The question to ask is why we need revocation at all. In the WebPKI it is because: 1) Private keys are weakly bound to the devices and are prone to disclosure. 2) WebPKI certificates conflate authentication and authorization and it is necessary to revoke certificates that are being used by criminals to steal money. Neither of these need be a concern in the IoT space. But certificate expiry and revocation are deeply bound into the architecture. If you decide neither is needed, you can greatly simplify the architecture: Bind a keypair into the device during manufacture so that it can never be extracted without serious effort and 99% of the causes of key compromise disappear. Separate authentication and authorization and there is no need for the PKI to be concerned with it. This is of course the approach I have taken in the Mesh (Singapore, Friday 10:00am). But before people accuse me of using this to promote my own work, it was this exact set of concerns that led me to design the Mesh in the first place. And yes, we can't trust keys that come from a manufacturer and nor do I suggest that we ever should. PKIX was designed according to the cryptographic capabilities as they were understood in 1978 when Kohnfelder wrote his master's thesis. We have moved on since. The techniques I am applying were invented in the 1990s but since people are loathe to recognize technology unless it is all bright and shiny, I have re-branded them 'meta-cryptography'. Point is that today we face a number of concerns that were almost entirely theoretical or limited to the most sensitive applications in the 1990s: * Alice used to share her computer with more than 50 other students, now she owns more than 50 computers. The key provisioning problem has changed completely as a result. * Compromise in the supply chain is no longer a theoretical problem, nor is the problem a single state actor as some suggest. The supply chains are large, complex and opaque. Nobody really knows the provenance of anything unless it is one of the handful of devices from a trustworthy foundry. * The shortest password that is secure is far longer than the longest password that is memorable and this cannot be solved by changing the hash function. The capabilities of massively parallel machines outstrips the capacity of a single core by many orders of magnitude. There is no technical means of making exhaustive search prohibitive. * We are no longer just providing security to government employees, academics and students. We can't expect them to adapt to our technologies any more. *Don't try to change the user*. * The Internet has 5 billion users and 50 billion devices. Deployment of technology is a vastly harder challenge than designing or implementing it. We have to design for deployment and we cannot do that with a design from the 1970s. This does not mean that PKIX is irrelevant, far from it. What I have done in the Mesh is to take the use patterns that emerged from the deployment and use of PKIX and reified them as architecture. So Alice can now use online/offline key management to protect her data but don't tell Alice that because she doesn't need to know thats what she is doing. To paraphrase Keynes: We have unused cryptography in a world of security need. --000000000000a02ab80595aa4a24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Oct 24, 2019 at 11:01 AM Dr. Pala <madwolf@openca.org> wrote:
=20 =20 =20

Given these considerations - and the fact that large PKIs are being deployed, today, for the IoT case - we would like to start the discussion around the current status of OCSP and possibly work on a proposal for moving forward with a more efficient protocol.=C2= =A0

What do you think ? Anybody would like to tackle this problem together ?

I am interested in the problem. I just disagree wit= h the notion that X.509/PKIX is a useful way to think about IoT devices. It= is not what the architecture was originally designed to serve and it doesn= 't actually serve it at all well.

The reason we need revocation in the WebPKI is that the primar= y concern that infrastructure=C2=A0was originally designed to address was t= he appearance of fake Web Merchants. The design brief was to make online co= mmerce as safe as bricks and mortar. The fundamental concern VeriSign Class= 3 was designed to meet was to establish accountability so that posing as a= fake Web merchant was unprofitable. And that limited goal was achieved wit= h enormous success. Or at least it was before big tech thought it a good id= ea to strip out the security signal from the browsers.

The problem with the WebPKI is that it does n= ot serve every purpose well. And it has been co-opted to a rather sordid di= spute into who can invade users privacy to bombard them with ads and who ca= n't. So we have the current Congressional hearings and the looming anti= -Trust lawsuits. People who thought PKIX would be so much better without th= e lawyers and were happy to see them disappear are going to be in for a nas= ty shock in the next couple of years.

We are long past the point where it is prudent for any of the = Web Browser providers with more than 5% market share to allow any of their = employees to contribute to discussions on the WebPKI without having every e= mail vetted by company lawyers and company lawyers attend every meeting.=C2= =A0

<= br>
The qu= estion to ask is why we need revocation at all. In the WebPKI it is because= :

1) Private keys are wea= kly bound to the devices and are prone to disclosure.
2) WebPKI certificates conflate auth= entication and authorization and it is necessary to revoke certificates tha= t are being used by criminals to steal money.

Neither of these need be a co= ncern in the IoT space. But certificate expiry and revocation are deeply bo= und into the architecture. If you decide neither is needed, you can greatly= simplify the architecture: Bind a keypair into the device during manufactu= re so that it can never be extracted without serious effort and 99% of the = causes of key compromise disappear. Separate authentication and authorizati= on and there is no need for the PKI to be concerned with it.

This is of course the approach I have t= aken in the Mesh (Singapore, Friday 10:00am). But before people accuse me o= f using this to promote my own work, it was this exact set of concerns that= led me to design the Mesh in the first place.

And yes, we can't trust keys that come from a man= ufacturer and nor do I suggest that we ever should. PKIX was designed accor= ding to the cryptographic capabilities as they were understood in 1978 when= Kohnfelder wrote his master's thesis. We have moved on since. The tech= niques I am applying were invented in the 1990s but since people are loathe= to recognize technology unless it is all bright and shiny, I have re-brand= ed them 'meta-cryptography'.

Point is that today we face a number o= f concerns that were almost entirely theoretical or limited to the most sen= sitive applications in the 1990s:

* Alice used to share her computer with more than 50 other stude= nts, now she owns more than 50 computers. The key provisioning problem has = changed completely as a result.

* Compromise in the supply chain is no longer a theoretical problem,= nor is the problem a single state actor as some suggest. The supply chains= are large, complex and opaque. Nobody really knows the provenance of anyth= ing unless it is one of the handful of devices from a trustworthy foundry.<= /div>

* The shortest password t= hat is secure is far longer than the longest password that is memorable and= this cannot be solved by changing the hash function. The capabilities of m= assively parallel machines outstrips the capacity of a single core by many = orders of magnitude. There is no technical means of making exhaustive searc= h prohibitive.
=
* We are n= o longer just providing security to government employees, academics and stu= dents. We can't expect them to adapt to our technologies any more. <= b>Don't try to change the user.

* The Internet has 5 billion users and 50 billion devi= ces. Deployment of technology is a vastly harder challenge than designing o= r implementing it. We have to design for deployment and we cannot do that w= ith a design from the 1970s.

This does not mean that PKIX is irrelevant, fa= r from it. What I have done in the Mesh is to take the use patterns that em= erged from the deployment and use of PKIX and reified them as architecture.= So Alice can now use online/offline key management to protect her data but= don't tell Alice that because she doesn't need to know thats what = she is doing.


To paraphrase Keynes: We have unused cryptogra= phy in a world of security need.

--000000000000a02ab80595aa4a24-- --000000000000a02ab90595aa4a25 Content-Type: image/png; name="edlnajaiinmgcjll.png" Content-Disposition: inline; filename="edlnajaiinmgcjll.png" Content-Transfer-Encoding: base64 Content-ID: <16dfe5b50a9482ef531> X-Attachment-Id: 16dfe5b50a9482ef531 iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoXBwES CQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAqMjpXKgs/ MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1SGdDR0lDSFJf RDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27PgCaSANtUT57VBer SQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXaeVR+lVRZrYld1ZiB7YEuS YQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDVWQJ1blapYjbXWgDRXACMaU6W bgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3WqaS6BcGeobwndXwzkXwLgYgDaYwyM eCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuvcEPrZQDQaSyockrFbSvmZwnabQLvZwDp aQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqK gnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXleSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQ iwCximixim/EkAORkZGVkYrOh0rPiVL5giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvK lGqpnJLdlF2boKy+m324nImkoZ+eo6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/S rI7dq4bqqXTOrpWttL+6s6uwtbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfR wbXFyMvbxbPNyMP8zgTczMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp 7/Hy9PHw9fj6/v3YktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPX GT6E+l9BZ0EFsTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+U SgFL4r9gEaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqE SrMplYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75UjLZf p6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/85sH2KeX vj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf70RPUPjxLouB EgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxcAwyWTbacW0sTDGoJ en4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+NpuKpq32qLVaexOCCJB91 aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq1LzUMQ4uxxycjl0LWO1bBsY6 yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XOcajZb6GDu7PTFEdPkVu0k4vQyd3J c/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV 2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRbjuxtfqRypNACK28+j3FsqcilAD0ADuIWCt0y Ra7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7 QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxar lr0grlQn92DQt1vBUk+nUFeHGZmegUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJ o+2PGLb2d9WE5bw1L4DcnOco9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bF zhw3eZylM2dgwkbWW3IyJp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwd ElJmarxedr/u3P6CNn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivo BjrfUgNB69zfb6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toV EevCi9/ffmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzS Y3FuBkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/dY1p7 qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1RgrYlfrRe SqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxHdRJFGJkhfKxg mM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3luaLNe1F++bjXGyWyz ZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCmGIzpqKlm27KTSWUcAX1g oBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJCBVkrrBJ1BewMmlVpgRUQF7wp ItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQYIOhklDKzo2C1IV2sijzdhjorqwef NdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41qKFl02YaswYNkULTeLC9CFFK4bDHDMmZb hnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYvJpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkc Hz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkhmt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlC XaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7Wfg ZOv4uLLl0w8wUah71QLBpJeXq/eMVVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6 vjt1z/ghMehVKiUpyt1VYBXCN6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oE DQ6jB9Wc3Z6bm6zLTtLlgLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgX s2kV4WUC0YR/KOLvPby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP 7LnTfsd42at3+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw90 1G+ttVlTJa34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K +f59qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a8XoA AAAASUVORK5CYII= --000000000000a02ab90595aa4a25-- From nobody Thu Oct 24 12:11:08 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD3D1200B2 for ; Thu, 24 Oct 2019 12:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 J4fLdi9fW6hI for ; Thu, 24 Oct 2019 12:11:04 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F1BD12008F for ; Thu, 24 Oct 2019 12:11:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 221173897C; Thu, 24 Oct 2019 15:08:24 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 037DE61F; Thu, 24 Oct 2019 15:11:00 -0400 (EDT) From: Michael Richardson To: "Dr. Pala" cc: LAMPS WG In-Reply-To: <8c84cf2c-c192-c13b-17e5-7ae09b748530@openca.org> References: <8c84cf2c-c192-c13b-17e5-7ae09b748530@openca.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] The Status of OCSP and its future X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 19:11:06 -0000 --=-=-= Content-Type: text/plain Dr. Pala wrote: > Specifically, for very large PKIs (i.e., few hundreds million > certificates valid at any given time), the OCSP protocol does not > scale well. In fact, taking into consideration how we operate OCSP > responders today, the larger the PKI is, the higher the costs of > providing a good revocation infrastructure is. Why not just spread your load across multiple OCSP endpoints by putting different AuthorityInfoAccess values in? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl2x90MACgkQgItw+93Q 3WVkVwgAiXhP86Y9zwa0A6sRrCQcYk3vjf9rjJekiTE9T5e9s+RT5CLhX45M7Xs5 4m3GRwBxiGth1datgfUt4CzVRd2RZ6v+8Yn7G2Ehq/V3wa2aqVt8JdOcLk0G8GJ5 wbn9iAZGC9Fq7BInaoPGs4/kL5AzI4c+yiV5ScaTGkIhEAvZ5Kszs8KEqf7AJ85f fS8fGq9Gn63wI9iiflwS7t+FqL+MXhgmpnquDt9GJTdYghcCDPGYE0b5dRmE0dRA ejf/dmPstjk3fpgCnKk5c+Afop6OGsRGewF5Tc40hGWd3wpI1pHsj1dmcQ5UMZUc R6KbKMIuYmt6t3jUSH9fWGUMGAC3zg== =Hc+W -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 24 23:58:43 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B9B120100 for ; Thu, 24 Oct 2019 23:58:41 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=L+5qNfnh; dkim=pass (1024-bit key) header.d=primekey.com header.b=L+5qNfnh 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 qSwAQK70aJz6 for ; Thu, 24 Oct 2019 23:58:38 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E473A12003F for ; Thu, 24 Oct 2019 23:52:25 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id 1545C6AA0098 for ; Fri, 25 Oct 2019 08:52:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1571986331; bh=FRTbbrHfKubKWsBDblyVtcujNoG9//Bdv9XxKb1DJmQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=L+5qNfnheoNLVJX+tRoWHkpFKTscQZQFil/7x0Yeykrq3M8RsvMIEIb2kG4MGhbpU 9bpxPyQ73PjfnIRGMufovKYn/kDglTFbGihWJPfZoF3Hc9JplMox40jp5r9PygTc+1 ZdIpoRseGM1sXkrlw7+66GLvPaSeYvGPvLiTU5rw= Received: from [192.168.1.113] (unknown [85.24.187.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id EA69A6AA0094 for ; Fri, 25 Oct 2019 08:52:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1571986331; bh=FRTbbrHfKubKWsBDblyVtcujNoG9//Bdv9XxKb1DJmQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=L+5qNfnheoNLVJX+tRoWHkpFKTscQZQFil/7x0Yeykrq3M8RsvMIEIb2kG4MGhbpU 9bpxPyQ73PjfnIRGMufovKYn/kDglTFbGihWJPfZoF3Hc9JplMox40jp5r9PygTc+1 ZdIpoRseGM1sXkrlw7+66GLvPaSeYvGPvLiTU5rw= To: spasm@ietf.org References: <8c84cf2c-c192-c13b-17e5-7ae09b748530@openca.org> From: Tomas Gustavsson Openpgp: preference=signencrypt Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= mQENBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAG0MFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPokB NwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5uQENBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAGJAR8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: <84e130d2-2df2-2f96-0200-716b333a1390@primekey.com> Date: Fri, 25 Oct 2019 08:52:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <8c84cf2c-c192-c13b-17e5-7ae09b748530@openca.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] The Status of OCSP and its future X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 06:58:41 -0000 On 2019-10-24 17:01, Dr. Pala wrote: > Hi All, > > I just wanted to start the conversation around the status of revocation > infrastructures and possible work we can be doing to address some of new > issues deriving from the deployment of large PKIs. In particular, we are > working on the optimization of the OCSP protocol to better serve some of > the use-cases we have. > > Specifically, for very large PKIs (i.e., few hundreds million > certificates valid at any given time), the OCSP protocol does not scale > well. In fact, taking into consideration how we operate OCSP responders > today, the larger the PKI is, the higher the costs of providing a good > revocation infrastructure is. As there are many PKIs today with 100M+ entities, some with and some without revocation infrastructure, I think it's a bit too broad claim for all use cases. It is certainly true of all operations, the larger the scale the larger infrastructure costs usually are, where OCSP I'd say is generally a very minor part. It differs from use case to use case though, I think it would be good for the discussion to provide more details on your problematic use case, architecture, use pattern etc. Many things are use case and implementation choice specific. > > Our approach stem from two practical considerations: the occasion to > provide optimized responses for the non-revoked case, and the > possibility to reduce the number of round trips required to retrieve the > revocation status for the full chain of certificates. In particular: > > * /*Optimizing for the common case (non-revoked certificate).*/ In > particular, for certificates that have no revocation information, we > do not have to provide specific responses for each individual > certificate (as we do in the revoked case), but we can provide > responses for ranges of certificates where the status is not > revoked. In a PKI with a population of 100M certificate and a > revocation rate of 5%, using "range" response types reduces the need > for calculating OCSP responses from 100M to 1M (i.e. 2N + 1 where N > is the population of revoked certificates). This allows to > pre-generate responses more quickly, allows for lower costs of > running the revocation infrastructure, and it is better for the > planet :D What could a "range" of certificates be based on? (I consider sequential serialnumbers to be dead by now) > > * /*Providing Full Chain responses.*/ Although single OCSP responders > can be authoritative for their own CA only, they can attach the > responses for the full chain as additional data. If we add this > possibility, then a single OCSP request can provide the > client/server with the full chain of certificates up to the Root. > This might be tricky in complex scenarios where cross-certification > is used, but it would definitely work for the Web PKI and IoT use cases. If extra round-tripping is needed it is certainly a concern. This is also valid and discussed in the Web PKI case. > > Given these considerations - and the fact that large PKIs are being > deployed, today, for the IoT case - we would like to start the > discussion around the current status of OCSP and possibly work on a > proposal for moving forward with a more efficient protocol. We do se working use cases with OCSP for huge number of devices, but in IoT it's all use case dependent so I'm interested in more on your use case. > > What do you think ? Anybody would like to tackle this problem together ? > > Cheers, > Max > > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > OpenCA Logo > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Fri Oct 25 00:15:04 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72E41200F8 for ; Fri, 25 Oct 2019 00:15:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 xg56Ri5OkF0n for ; Fri, 25 Oct 2019 00:15:02 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 D3F6F1200FD for ; Fri, 25 Oct 2019 00:15:01 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id e12so798799vsr.4 for ; Fri, 25 Oct 2019 00:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J2zkOKv+6XzDAuwgAyN+mBn695R+dxDA2CKuPxOFWuU=; b=j+ySWSBX/RKuWcguTyDZotvqNyGS6hEDJdFcfROWWqiETIrktqyn971p8l76HQwzkg qQPnDPDec3xTL9eBft9cN2/se2GTfNfkG8ejm+mEGkMdNM1a7MTFPNRmY3Mg33ixdrqH GU6wb8zheaRiD6PiBt+uyrPlYhR9GQp8imyIPLBM6caHvai2OInopErE/Zrlc862eEEc y48RfH1zBU8ld9gaQoialbpNc3DmLm7Hx6u3wp8QLHDs6zLo3ie9kknRxPKWxtoEeR0z NbDLUjPFey5KlrLC6XnFcqIJuRewqw4XDJIVhCzNWzwFaPdALPR1G/YqvsSD8Z5977LZ Civg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J2zkOKv+6XzDAuwgAyN+mBn695R+dxDA2CKuPxOFWuU=; b=WEwnhdQVn7sP+/NCaYoNi7sIPKvGZTawIg6hoMJtSjnJMQ0lmLTRr4D8jx5cbModK3 mvOzCTWZ4f318Lr51UD4GRPPHK/cDY5Pa30wAD1xs7Q6nHYKP4Xp2NAOzoHn3cYVgjw+ kE6VKdgupCZ2Y4M/rPluSYAeJsp8UsVF9yjES6mPyimJCYEM54OUfIyz+yNIeELrGLX3 9dXLl4JgOnZmaIAd8OSZSEIPxyCyiH8By1eIK0OpKGNlP03Ct+adnu1WK/jCMNIzIbIi E/NslGNvmRPI4EbaVIJBCBESetkQulFMTOXEHMPejzJC3y+8pONDo8bb6utL6OimiEdA 1+Cw== X-Gm-Message-State: APjAAAU0LoVVS3jgpdI5v1MQcxixOvhJKcTG4FFV0EhL7JfOYRfy93LG 4yz48i9TQA9AnsuSTiDpw0KtAixODUq4fKPZMhA5CJF+mZY= X-Google-Smtp-Source: APXvYqySW4Rp0VoZz9OkuQ7d9QUqh4nI4YhvdgBxmBH8yII1dRCcN696ND5sce2Rift0nTVgKyk+WsJ83g8dZG295wQ= X-Received: by 2002:a67:d890:: with SMTP id f16mr1253216vsj.119.1571987700525; Fri, 25 Oct 2019 00:15:00 -0700 (PDT) MIME-Version: 1.0 References: <8c84cf2c-c192-c13b-17e5-7ae09b748530@openca.org> <84e130d2-2df2-2f96-0200-716b333a1390@primekey.com> In-Reply-To: <84e130d2-2df2-2f96-0200-716b333a1390@primekey.com> From: Dmitry Belyavsky Date: Fri, 25 Oct 2019 10:14:49 +0300 Message-ID: To: Tomas Gustavsson Cc: LAMPS Content-Type: multipart/alternative; boundary="0000000000007b30f20595b6e8b3" Archived-At: Subject: Re: [lamps] The Status of OCSP and its future X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 07:15:04 -0000 --0000000000007b30f20595b6e8b3 Content-Type: text/plain; charset="UTF-8" Dear Tomas, On Fri, Oct 25, 2019 at 9:58 AM Tomas Gustavsson < tomas.gustavsson@primekey.com> wrote: > > > > > > Our approach stem from two practical considerations: the occasion to > > provide optimized responses for the non-revoked case, and the > > possibility to reduce the number of round trips required to retrieve the > > revocation status for the full chain of certificates. In particular: > > > > * /*Optimizing for the common case (non-revoked certificate).*/ In > > particular, for certificates that have no revocation information, we > > do not have to provide specific responses for each individual > > certificate (as we do in the revoked case), but we can provide > > responses for ranges of certificates where the status is not > > revoked. In a PKI with a population of 100M certificate and a > > revocation rate of 5%, using "range" response types reduces the need > > for calculating OCSP responses from 100M to 1M (i.e. 2N + 1 where N > > is the population of revoked certificates). This allows to > > pre-generate responses more quickly, allows for lower costs of > > running the revocation infrastructure, and it is better for the > > planet :D > > What could a "range" of certificates be based on? > (I consider sequential serialnumbers to be dead by now) > E.g. notBefore time? -- SY, Dmitry Belyavsky --0000000000007b30f20595b6e8b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear=C2=A0Tomas,

On Fri, Oct 25, 2019 at 9= :58 AM Tomas Gustavsson <tomas.gustavsson@primekey.com> wrote:


>
> Our approach stem from two practical considerations: the occasion to > provide optimized responses for the non-revoked case, and the
> possibility to reduce the number of round trips required to retrieve t= he
> revocation status for the full chain of certificates. In particular: >
>=C2=A0 =C2=A0* /*Optimizing for the common case (non-revoked certificat= e).*/ In
>=C2=A0 =C2=A0 =C2=A0particular, for certificates that have no revocatio= n information, we
>=C2=A0 =C2=A0 =C2=A0do not have to provide specific responses for each = individual
>=C2=A0 =C2=A0 =C2=A0certificate (as we do in the revoked case), but we = can provide
>=C2=A0 =C2=A0 =C2=A0responses for ranges of certificates where the stat= us is not
>=C2=A0 =C2=A0 =C2=A0revoked. In a PKI with a population of 100M certifi= cate and a
>=C2=A0 =C2=A0 =C2=A0revocation rate of 5%, using "range" resp= onse types reduces the need
>=C2=A0 =C2=A0 =C2=A0for calculating OCSP responses from 100M to 1M (i.e= . 2N + 1 where N
>=C2=A0 =C2=A0 =C2=A0is the population of revoked certificates). This al= lows to
>=C2=A0 =C2=A0 =C2=A0pre-generate responses more quickly, allows for low= er costs of
>=C2=A0 =C2=A0 =C2=A0running the revocation infrastructure, and it is be= tter for the
>=C2=A0 =C2=A0 =C2=A0planet :D

What could a "range" of certificates be based on?
(I consider sequential serialnumbers to be dead by now)

E.g. notBefore time?

= --
SY, Dmitry Belyavsky
--0000000000007b30f20595b6e8b3-- From nobody Fri Oct 25 00:53:20 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD18512012E for ; Fri, 25 Oct 2019 00:53:19 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=lYD2V4Cq; dkim=pass (1024-bit key) header.d=primekey.com header.b=lYD2V4Cq 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 8rcbhYRQ7cKX for ; Fri, 25 Oct 2019 00:53:18 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34BA012012A for ; Fri, 25 Oct 2019 00:53:18 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id 26C9A6AA0098; Fri, 25 Oct 2019 09:53:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1571989985; bh=1uawdbX6rw//eu89dYPLuuotL4jwwDQHoLOzwa/Nd6A=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=lYD2V4Cq2HpO2Mm5UQ5ur212NYq2SP7sTnCAhXe8O41H8OvBWIkp7iqUuxH3tqk4w n3lD+j7d/RxMRicmATJGS04ILNcjw9CuGdilwWOhBfMaKmEBEpzpxaQZBREbHIlKLX QMRc9FoRzRwBdZELubDoico43i4g1YpbnFg0LCLw= Received: from [10.11.0.15] (gatekeeper.primekey.se [84.55.121.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id 056436AA0094; Fri, 25 Oct 2019 09:53:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1571989985; bh=1uawdbX6rw//eu89dYPLuuotL4jwwDQHoLOzwa/Nd6A=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=lYD2V4Cq2HpO2Mm5UQ5ur212NYq2SP7sTnCAhXe8O41H8OvBWIkp7iqUuxH3tqk4w n3lD+j7d/RxMRicmATJGS04ILNcjw9CuGdilwWOhBfMaKmEBEpzpxaQZBREbHIlKLX QMRc9FoRzRwBdZELubDoico43i4g1YpbnFg0LCLw= To: Dmitry Belyavsky Cc: LAMPS References: <8c84cf2c-c192-c13b-17e5-7ae09b748530@openca.org> <84e130d2-2df2-2f96-0200-716b333a1390@primekey.com> From: Tomas Gustavsson Openpgp: preference=signencrypt Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= mQENBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAG0MFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPokB NwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5uQENBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAGJAR8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: <201561ae-fb90-cba8-87f3-c88a7324f483@primekey.com> Date: Fri, 25 Oct 2019 09:53:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lamps] The Status of OCSP and its future X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 07:53:20 -0000 On 2019-10-25 09:14, Dmitry Belyavsky wrote: > Dear Tomas, > > On Fri, Oct 25, 2019 at 9:58 AM Tomas Gustavsson > > > wrote: > > > > > > > Our approach stem from two practical considerations: the occasion to > > provide optimized responses for the non-revoked case, and the > > possibility to reduce the number of round trips required to > retrieve the > > revocation status for the full chain of certificates. In particular: > > > >   * /*Optimizing for the common case (non-revoked certificate).*/ In > >     particular, for certificates that have no revocation > information, we > >     do not have to provide specific responses for each individual > >     certificate (as we do in the revoked case), but we can provide > >     responses for ranges of certificates where the status is not > >     revoked. In a PKI with a population of 100M certificate and a > >     revocation rate of 5%, using "range" response types reduces > the need > >     for calculating OCSP responses from 100M to 1M (i.e. 2N + 1 > where N > >     is the population of revoked certificates). This allows to > >     pre-generate responses more quickly, allows for lower costs of > >     running the revocation infrastructure, and it is better for the > >     planet :D > > What could a "range" of certificates be based on? > (I consider sequential serialnumbers to be dead by now) > > > E.g. notBefore time? That certainly works for partitioning, often used in partitioned CRLs of course. From nobody Fri Oct 25 07:24:25 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B53120122 for ; Fri, 25 Oct 2019 07:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 Xyt6v_04cjHH for ; Fri, 25 Oct 2019 07:24:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BED412007C for ; Fri, 25 Oct 2019 07:24:22 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E5C4C3897D; Fri, 25 Oct 2019 10:21:43 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0ADD1723; Fri, 25 Oct 2019 10:24:21 -0400 (EDT) From: Michael Richardson To: spasm@ietf.org CC: max pritikin In-Reply-To: <157194474122.11345.14631980040123871622.idtracker@ietfa.amsl.com> References: <157194474122.11345.14631980040123871622.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] New Version Notification for draft-richardson-lamps-rfc7030est-clarify-04.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 14:24:24 -0000 --=-=-= Content-Type: text/plain internet-drafts@ietf.org wrote: > has been successfully submitted by Michael Richardson and posted to the > IETF repository. > Name: draft-richardson-lamps-rfc7030est-clarify > Revision: 04 > Title: Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1 > Document date: 2019-10-24 > Group: Individual Submission > Pages: 10 I futzed -03, so this diff is more useful: https://www.ietf.org/rfcdiff?url1=draft-richardson-lamps-rfc7030est-clarify-02&url2=draft-richardson-lamps-rfc7030est-clarify-04 1) Added module from Sean Turner. 2) Added Sean Turner as co-author. Waiting for rechartering in order for an adoption call to be possible. I don't see a need for any WG time at IETF106. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl2zBZQACgkQgItw+93Q 3WXHqgf+N/jtUbKntBXM2Lnpw+wzR17fZ11RAKiPhj3TT7QPpiVUA06dx9M5FY5Z F/M7DXBrwW+L5XgHlhdypNTvie9kRuJ1hy0Hw7U+7pMnZMBs0pGWslNT7UBihTX0 12H75XiMVzBWnm3u8bIDofNCBgmhhJKkRaV7laz2gs2uRH+GOsvETTo+9p/1u09X 2LdETXMJK4wyMCOlmGIhKR8lQw47Pvu7BFhGxfREakpYABjEcKtll6cckq0jO8St mSqpZiezA5lovPgnAzQyZ8jYttCigq9Yd5b6IDtG6f4ahGkRg86GFCTRlCmbDn5i 9pivXx0nnNBRf2/tBdaYUQSEQ191lQ== =Wn6O -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 25 07:30:46 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0979A12087A for ; Fri, 25 Oct 2019 07:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 entIgDllFDYR for ; Fri, 25 Oct 2019 07:30:42 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id E6483120072 for ; Fri, 25 Oct 2019 07:30:42 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id AC784374137D for ; Fri, 25 Oct 2019 14:30:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id J1S0UlD1aZpC for ; Fri, 25 Oct 2019 10:30:41 -0400 (EDT) Received: from Maxs-MBP-2.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id E17003741035 for ; Fri, 25 Oct 2019 10:30:40 -0400 (EDT) To: spasm@ietf.org References: <8c84cf2c-c192-c13b-17e5-7ae09b748530@openca.org> <84e130d2-2df2-2f96-0200-716b333a1390@primekey.com> From: "Dr. Pala" Message-ID: <7c618415-21d7-64c8-e43d-2617d59185f4@openca.org> Date: Fri, 25 Oct 2019 08:30:40 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <84e130d2-2df2-2f96-0200-716b333a1390@primekey.com> Content-Type: multipart/alternative; boundary="------------8CFEF79AFE0A650699745759" Content-Language: en-US Archived-At: Subject: Re: [lamps] The Status of OCSP and its future X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 14:30:45 -0000 This is a multi-part message in MIME format. --------------8CFEF79AFE0A650699745759 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Tomas, On 10/25/19 12:52 AM, Tomas Gustavsson wrote: > On 2019-10-24 17:01, Dr. Pala wrote: >> Hi All, >> >> I just wanted to start the conversation around the status of revocation >> [...] >> today, the larger the PKI is, the higher the costs of providing a good >> revocation infrastructure is. > As there are many PKIs today with 100M+ entities, some with and some > without revocation infrastructure, I think it's a bit too broad claim > for all use cases. > It is certainly true of all operations, the larger the scale the larger > infrastructure costs usually are, where OCSP I'd say is generally a very > minor part. > It differs from use case to use case though, I think it would be good > for the discussion to provide more details on your problematic use case, > architecture, use pattern etc. Many things are use case and > implementation choice specific. This is a good point - very practical approach. A sample use-case is our industry (Cable). In particular, in our industry, we leverage PKIs to secure the communication in our networks: each Cable Modem and DVRs come with one or more certificates from our infrastructure. This covers all modems from all vendors from all operators. Our Network, though, are going through radical changes that are aimed at providing the 10Gig platform we just released the standard for. In particular, the new architectures will see an increasing number of "entities" that require authentication. As you can see, our PKI tend to be larger than what you typically see in the Web PKI (quite small in comparison - even combining all providers), therefore improving the efficiency and reducing the costs is a big win for the industry in general and for the users since we can now provide OCSP responses with shorter validity periods, thus reducing the risk level of our Access Networks. This is not the only use-case, though. Many IoT environments are starting to use digital certificates for authentication at a scale. Some environments, like the Power Grid, are already deploying solutions that use certificates to protect the communication up to the customers' premises. Another use-case that I am bringing forward is Cellular. In particular, we already have standardized the use of certificates in some environments (e.g., CBRS-A, 5G Fixed, etc.) and it is expected that by freeing the network authentication from the need of a physical SIM (and associated licensing costs) we will see more and more devices (e.g., Fix and Industrial) using this technology. This said, I think that reducing the costs of providing revocation information is a good goal in general and can help reducing authentication risks by providing shorter validity responses. >> Our approach stem from two practical considerations: the occasion to >> provide optimized responses for the non-revoked case, and the >> [...] >> planet :D > What could a "range" of certificates be based on? > (I consider sequential serialnumbers to be dead by now) Our current approach is very simple. Take a CRL and produce (a) one response for each revoked certificate, and (b) one response for each range between revoked serial numbers. For example, if you have the following serial numbers revoked { 3, 5, 12 }, then you would sign 3 responses for the 3 revoked certificates, plus the response from "0" to "3", two responses for the gaps between {3 and 5} and {5 and 12}, plus the last response for 5+. In this case, the number of revoked certificates is 3 and the number of signed responses is 2N + 1 = { 3 revoked } + { 1 from 0 to the first entry } + { 2 gaps } + { 1 from last to infinity } = 7 Therefore, with this approach, if you are good at keeping the number of revoked certificates low, you can see how efficient this technique can be - especially when you revoked/valid certificate ratio is very low. > >> * /*Providing Full Chain responses.*/ Although single OCSP responders >> can be authoritative for their own CA only, they can attach the >> responses for the full chain as additional data. If we add this >> possibility, then a single OCSP request can provide the >> client/server with the full chain of certificates up to the Root. >> This might be tricky in complex scenarios where cross-certification >> is used, but it would definitely work for the Web PKI and IoT use cases. > If extra round-tripping is needed it is certainly a concern. This is > also valid and discussed in the Web PKI case. It is to be mentioned that providing the full chain is possible today - however, no clients I know leverages this option. This, I think, it is because of several factors (i.e., trust model, AIA in certificates, etc.) that, if you are interested, we can explore separately. >> Given these considerations - and the fact that large PKIs are being >> deployed, today, for the IoT case - we would like to start the >> discussion around the current status of OCSP and possibly work on a >> proposal for moving forward with a more efficient protocol. > We do se working use cases with OCSP for huge number of devices, but in > IoT it's all use case dependent so I'm interested in more on your use case. I hope that I provided you with some compelling scenarios here - I think that by optimizing the provisioning of revocation information we can help not only our specific use cases, but also the deployment of revocation information infrastructures that are low-cost for environments where using CDNs, Load Balancers, etc. is not an option because of the cost :D Thanks for the reply - I do really appreciate the feedback! Cheers, Max -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------8CFEF79AFE0A650699745759 Content-Type: multipart/related; boundary="------------DD059D3C97411F4DB1A60AEE" --------------DD059D3C97411F4DB1A60AEE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi Tomas,

On 10/25/19 12:52 AM, Tomas Gustavsson wrote:
On 2019-10-24 17:01, Dr. Pala wrote:

Hi All,

I just wanted to start the conversation around the status of revocation
[...]
today, the larger the PKI is, the higher the costs of providing a good
revocation infrastructure is.

As there are many PKIs today with 100M+ entities, some with and some
without revocation infrastructure, I think it's a bit too broad claim
for all use cases.
It is certainly true of all operations, the larger the scale the larger
infrastructure costs usually are, where OCSP I'd say is generally a very
minor part.
It differs from use case to use case though, I think it would be good
for the discussion to provide more details on your problematic use case,
architecture, use pattern etc. Many things are use case and
implementation choice specific.

This is a good point - very practical approach. A sample use-case is our industry (Cable). In particular, in our industry, we leverage PKIs to secure the communication in our networks: each Cable Modem and DVRs come with one or more certificates from our infrastructure. This covers all modems from all vendors from all operators.

Our Network, though, are going through radical changes that are aimed at providing the 10Gig platform we just released the standard for. In particular, the new architectures will see an increasing number of "entities" that require authentication.

As you can see, our PKI tend to be larger than what you typically see in the Web PKI (quite small in comparison - even combining all providers), therefore improving the efficiency and reducing the costs is a big win for the industry in general and for the users since we can now provide OCSP responses with shorter validity periods, thus reducing the risk level of our Access Networks.

This is not the only use-case, though.

Many IoT environments are starting to use digital certificates for authentication at a scale. Some environments, like the Power Grid, are already deploying solutions that use certificates to protect the communication up to the customers' premises.

Another use-case that I am bringing forward is Cellular. In particular, we already have standardized the use of certificates in some environments (e.g., CBRS-A, 5G Fixed, etc.) and it is expected that by freeing the network authentication from the need of a physical SIM (and associated licensing costs) we will see more and more devices (e.g., Fix and Industrial) using this technology.

This said, I think that reducing the costs of providing revocation information is a good goal in general and can help reducing authentication risks by providing shorter validity responses.


      

        
Our approach stem from two practical considerations: the occasion to
provide optimized responses for the non-revoked case, and the
[...]
    planet :D


      

      
What could a "range" of certificates be based on?
(I consider sequential serialnumbers to be dead by now)

    

    
Our current approach is very simple. Take a CRL and produce (a)
      one response for each revoked certificate, and (b) one response
      for each range between revoked serial numbers. For example, if you
      have the following serial numbers revoked { 3, 5, 12 }, then you
      would sign 3 responses for the 3 revoked certificates, plus the
      response from "0" to "3", two responses for the gaps between {3
      and 5} and {5 and 12}, plus the last response for 5+. In this
      case, the number of revoked certificates is 3 and the number of
      signed responses is 2N + 1 = { 3 revoked } + { 1 from 0 to the
      first entry } + { 2 gaps } + { 1 from last to infinity } = 7

    
Therefore, with this approach, if you are good at keeping the
      number of revoked certificates low, you can see how efficient this
      technique can be - especially when you revoked/valid certificate
      ratio is very low.

    

    

      



      

        
  * /*Providing Full Chain responses.*/ Although single OCSP responders
    can be authoritative for their own CA only, they can attach the
    responses for the full chain as additional data. If we add this
    possibility, then a single OCSP request can provide the
    client/server with the full chain of certificates up to the Root.
    This might be tricky in complex scenarios where cross-certification
    is used, but it would definitely work for the Web PKI and IoT use cases.


      

      
If extra round-tripping is needed it is certainly a concern. This is
also valid and discussed in the Web PKI case.

    

    It is to be mentioned that providing the full chain is possible
    today - however, no clients I know leverages this option. This, I
    think, it is because of several factors (i.e., trust model, AIA in
    certificates, etc.) that, if you are interested, we can explore
    separately.

    

      

      

        
Given these considerations - and the fact that large PKIs are being
deployed, today, for the IoT case - we would like to start the
discussion around the current status of OCSP and possibly work on a
proposal for moving forward with a more efficient protocol.


      

      
We do se working use cases with OCSP for huge number of devices, but in
IoT it's all use case dependent so I'm interested in more on your use case.


    

    
I hope that I provided you with some compelling scenarios here -
      I think that by optimizing the provisioning of revocation
      information we can help not only our specific use cases, but also
      the deployment of revocation information infrastructures that are
      low-cost for environments where using CDNs, Load Balancers, etc.
      is not an option because of the cost :D 

    

    
Thanks for the reply - I do really appreciate the feedback!

    
Cheers,

      Max

    

    

    

    
-- 

      

        Best Regards,
        

          Massimiliano Pala, Ph.D.

          OpenCA Labs Director

        

        OpenCA Logo

      

    

  


--------------DD059D3C97411F4DB1A60AEE
Content-Type: image/png;
 name="ojpkbgagdmiikiea.png"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="ojpkbgagdmiikiea.png"

iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX
BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq
MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1
SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27
PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae
VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV
WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq
aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv
cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7
gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl
eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5
giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e
o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw
tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc
zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y
ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF
sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g
EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp
lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE
y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U
jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/
85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf
70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc
AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N
puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq
1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO
cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM
9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb
juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9
wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX
3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme
gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco
9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy
Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C
Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf
b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f
fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu
BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW
hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d
Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R
grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH
dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu
aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm
GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC
BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY
IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q
KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv
JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh
mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/
JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM
VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC
N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl
gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv
Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3
+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT
Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59
qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd
XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a
8XoAAAAASUVORK5CYII=
--------------DD059D3C97411F4DB1A60AEE--

--------------8CFEF79AFE0A650699745759--


From nobody Fri Oct 25 07:41:27 2019
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940AE120072 for ; Fri, 25 Oct 2019 07:41:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.494
X-Spam-Level: 
X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 cYbr4XfIaolQ for ; Fri, 25 Oct 2019 07:41:24 -0700 (PDT)
Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id D4F0E120118 for ; Fri, 25 Oct 2019 07:41:24 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 915B4374137D; Fri, 25 Oct 2019 14:41:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at katezarealty.com
Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GmY6BlVn_7DF; Fri, 25 Oct 2019 10:41:23 -0400 (EDT)
Received: from Maxs-MBP-2.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id C05173741035; Fri, 25 Oct 2019 10:41:23 -0400 (EDT)
To: Michael Richardson 
Cc: LAMPS WG 
References: <8c84cf2c-c192-c13b-17e5-7ae09b748530@openca.org> <5837.1571944259@localhost>
From: "Dr. Pala" 
Message-ID: <944cc3f3-8df5-740b-a7e9-6083dd834b72@openca.org>
Date: Fri, 25 Oct 2019 08:41:23 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <5837.1571944259@localhost>
Content-Type: multipart/alternative; boundary="------------07638E383EAB31F334BDEBAF"
Content-Language: en-US
Archived-At: 
Subject: Re: [lamps] The Status of OCSP and its future
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2019 14:41:25 -0000

This is a multi-part message in MIME format.
--------------07638E383EAB31F334BDEBAF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Michael,

On 10/24/19 1:10 PM, Michael Richardson wrote:
> Dr. Pala  wrote:
>      > Specifically, for very large PKIs (i.e., few hundreds million
> [...]
>      > providing a good revocation infrastructure is.
>
> Why not just spread your load across multiple OCSP endpoints by putting
> different AuthorityInfoAccess values in?

thanks for the comment - yes, I think that is an option. However, that 
does add complexity to the issuing system that might need to be tweaked 
as the infrastructure grows... and that does not lower my operational 
costs that can be significant for large PKI environments.

The proposal here is to optimize for the average case (and maybe 
simplify the messages in the process) - in particular providing 
responses for ranges of certificates (serial) where there is no 
revocation information available.

Although this is quite relevant for the Industry I work in (Cable), 
optimizing revocation information distribution might lower the 
operational cost for every PKI that implements revocation - the WebPKI 
included. In particular, if such a solution existed, then we could see 
OCSP responses for the WebPKI that have shorter validity periods, I 
think and hope: hours instead of days or months.

Thanks again for the feedback!

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

--------------07638E383EAB31F334BDEBAF
Content-Type: multipart/related;
 boundary="------------D592D19A20C79D829F2E1443"


--------------D592D19A20C79D829F2E1443
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi Michael,

    

    
On 10/24/19 1:10 PM, Michael Richardson
      wrote:

    

    

      
Dr. Pala <madwolf@openca.org> wrote:
    > Specifically, for very large PKIs (i.e., few hundreds million
[...]
    > providing a good revocation infrastructure is.

Why not just spread your load across multiple OCSP endpoints by putting
different AuthorityInfoAccess values in?


    

    

    
thanks for the comment - yes, I think that is an option. However,
      that does add complexity to the issuing system that might need to
      be tweaked as the infrastructure grows... and that does not lower
      my operational costs that can be significant for large PKI
      environments.

    
The proposal here is to optimize for the average case (and maybe
      simplify the messages in the process) - in particular providing
      responses for ranges of certificates (serial) where there is no
      revocation information available.

    
Although this is quite relevant for the Industry I work in
      (Cable), optimizing revocation information distribution might
      lower the operational cost for every PKI that implements
      revocation - the WebPKI included. In particular, if such a
      solution existed, then we could see OCSP responses for the WebPKI
      that have shorter validity periods, I think and hope: hours
      instead of days or months.

    
Thanks again for the feedback!

    
Cheers,

      Max

    

    

    

    
-- 

      

        Best Regards,
        

          Massimiliano Pala, Ph.D.

          OpenCA Labs Director

        

        OpenCA Logo

      

    

  


--------------D592D19A20C79D829F2E1443
Content-Type: image/png;
 name="olaholgchjophpia.png"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="olaholgchjophpia.png"

iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX
BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq
MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1
SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27
PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae
VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV
WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq
aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv
cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7
gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl
eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5
giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e
o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw
tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc
zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y
ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF
sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g
EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp
lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE
y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U
jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/
85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf
70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc
AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N
puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq
1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO
cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM
9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb
juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9
wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX
3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme
gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco
9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy
Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C
Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf
b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f
fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu
BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW
hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d
Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R
grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH
dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu
aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm
GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC
BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY
IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q
KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv
JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh
mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/
JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM
VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC
N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl
gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv
Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3
+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT
Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59
qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd
XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a
8XoAAAAASUVORK5CYII=
--------------D592D19A20C79D829F2E1443--

--------------07638E383EAB31F334BDEBAF--


From nobody Fri Oct 25 07:48:40 2019
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6EC120878 for ; Fri, 25 Oct 2019 07:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level: 
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 APexxt7EOdcT for ; Fri, 25 Oct 2019 07:48:38 -0700 (PDT)
Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) (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 3BBDD12085D for ; Fri, 25 Oct 2019 07:48:38 -0700 (PDT)
Received: by mail-ot1-f45.google.com with SMTP id s22so2240882otr.6 for ; Fri, 25 Oct 2019 07:48:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7Tm4ENBubim7n3GKzy284CGua/EW3q8b4eeifik9HQk=; b=Q145MzzYYJe+iUK6793RX9hK4lJgBAv9t8Sxv4phvgvc/MjAO/GwfCMJF3/JAzPtCk Oc4Nyb8Em06j3ivAMX1rrPPnHGYDoa1nrwuX4Gny0ChFuhAMyZ+tjO3lB5g24oWDCPtF egtohWL8PtH3flyjJMkg9c+pmxstLNjHT9gmSQTY9/22ABT6BWctHzvcNkcnbiqaZaSR RYgRKMzrIWrLgFRdlLskyuiDsaYZAkzCNkorqIQF0B7/SPZytBpnRD2EEWz4c6zNf1u3 MRE5G431zQkBQ1VGYNIbucOSUqHYRZJ0BNep2OwsjjR+HsLTHGy9/yFmn4B9IccnbDtM iy5Q==
X-Gm-Message-State: APjAAAXvWweojVhenTszTMTdDS3DobfYE5+qvQnGldXWRA+Q7OonVqvw rooFsAO3jGdxn5JGazPZF5t85wDBT7+aoiRlnMI=
X-Google-Smtp-Source: APXvYqxbhr/AzU5C3nu3zMn/AyJ+NFJb9xCC8Gr/8yZbSAxxI1+6onUdyqxwTp21vXicG/tc4bd8aDHNUnUjRmYWIPI=
X-Received: by 2002:a9d:4591:: with SMTP id x17mr3078186ote.112.1572014917261;  Fri, 25 Oct 2019 07:48:37 -0700 (PDT)
MIME-Version: 1.0
References: <8c84cf2c-c192-c13b-17e5-7ae09b748530@openca.org> <84e130d2-2df2-2f96-0200-716b333a1390@primekey.com> <7c618415-21d7-64c8-e43d-2617d59185f4@openca.org>
In-Reply-To: <7c618415-21d7-64c8-e43d-2617d59185f4@openca.org>
From: Phillip Hallam-Baker 
Date: Fri, 25 Oct 2019 10:48:27 -0400
Message-ID: 
To: "Dr. Pala" 
Cc: SPASM 
Content-Type: multipart/related; boundary="000000000000b9c5020595bd3e66"
Archived-At: 
Subject: Re: [lamps] The Status of OCSP and its future
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2019 14:48:40 -0000

--000000000000b9c5020595bd3e66
Content-Type: multipart/alternative; boundary="000000000000b9c5010595bd3e65"

--000000000000b9c5010595bd3e65
Content-Type: text/plain; charset="UTF-8"

On Fri, Oct 25, 2019 at 10:30 AM Dr. Pala  wrote:

> This is a good point - very practical approach. A sample use-case is our
> industry (Cable). In particular, in our industry, we leverage PKIs to
> secure the communication in our networks: each Cable Modem and DVRs come
> with one or more certificates from our infrastructure. This covers all
> modems from all vendors from all operators.
>
> Our Network, though, are going through radical changes that are aimed at
> providing the 10Gig platform we just released the standard for. In
> particular, the new architectures will see an increasing number of
> "entities" that require authentication.
>
Knowing that it is all hilariously insecure, I have deployed roughly
$20,000 worth of smarthome type equipment in my house so as to experience
it myself.

At this point, it is very clear to me that this stuff is really not suited
for anyone who is not an enthusiast. IoT is a hobby and it is going to
remain so unless we see some major improvements in manageability.

I currently have about 100 devices of which 50 have IP addresses. So
multiply by a billion or so households and that is a heck of a lot more
devices than we have been thinking about to date.


If we are going to get a handle on this, we have to change the
architecture. I don't think there was ever a business or such with 50
devices that would put itself on the internet without some sort of
co-ordination service on site. And to get to 100 there would be redundancy
and such.
Yes, peer to peer looks cool until you get to the point where n^2 is a big
number and then it is a headache. Peer to peer means that I have to
maintain each of my printers on every machine in the house. Just does not
scale.

The Cable Modem and DVR are the natural devices for such co-ordinating
services to reside.

--000000000000b9c5010595bd3e65
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Fri, Oct 25, 2019 at 10:30 AM Dr. Pala <madwolf@openca.org> wrote:
<=
div bgcolor=3D"#FFFFFF">

    

    
This is a good point - very practical approach. A sample use-case
      is our industry (Cable). In particular, in our industry, we
      leverage PKIs to secure the communication in our networks: each
      Cable Modem and DVRs come with one or more certificates from our
      infrastructure. This covers all modems from all vendors from all
      operators.

    
Our Network, though, are going through radical changes that are
      aimed at providing the 10Gig platform we just released the
      standard for. In particular, the new architectures will see an
      increasing number of "entities" that require authentication=
.
Knowing that it is all hilariously insecure, I have deployed rough=
ly $20,000 worth of smarthome type equipment in my house so as to experienc=
e it myself.
At this poin=
t, it is very clear to me that this stuff is really not suited for anyone w=
ho is not an enthusiast. IoT is a hobby and it is going to remain so unless=
 we see some major improvements in manageability.

I currently have about 100 devices of which 50 hav=
e IP addresses. So multiply by a billion or so households and that is a hec=
k of a lot more devices than we have been thinking about to date.


If we are going to get a handle on this, we =
have to change the architecture. I don't think there was ever a busines=
s or such with 50 devices that would put itself on the internet without som=
e sort of co-ordination service on site. And to get to 100 there would be r=
edundancy and such.
Yes, peer=
 to peer looks cool until you get to the point where n^2 is a big number an=
d then it is a headache. Peer to peer means that I have to maintain each of=
 my printers on every machine in the house. Just does not scale.=C2=A0

The Cable Modem and DVR are t=
he natural devices for such co-ordinating services to reside.




--000000000000b9c5010595bd3e65--

--000000000000b9c5020595bd3e66
Content-Type: image/png; name="ojpkbgagdmiikiea.png"
Content-Disposition: inline; filename="ojpkbgagdmiikiea.png"
Content-Transfer-Encoding: base64
Content-ID: <16e035b17aa93b382df1>
X-Attachment-Id: 16e035b17aa93b382df1

iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoXBwES
CQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAqMjpXKgs/
MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1SGdDR0lDSFJf
RDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27PgCaSANtUT57VBer
SQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXaeVR+lVRZrYld1ZiB7YEuS
YQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDVWQJ1blapYjbXWgDRXACMaU6W
bgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3WqaS6BcGeobwndXwzkXwLgYgDaYwyM
eCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuvcEPrZQDQaSyockrFbSvmZwnabQLvZwDp
aQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqK
gnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXleSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQ
iwCximixim/EkAORkZGVkYrOh0rPiVL5giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvK
lGqpnJLdlF2boKy+m324nImkoZ+eo6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/S
rI7dq4bqqXTOrpWttL+6s6uwtbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfR
wbXFyMvbxbPNyMP8zgTczMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp
7/Hy9PHw9fj6/v3YktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPX
GT6E+l9BZ0EFsTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+U
SgFL4r9gEaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqE
SrMplYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE
y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75UjLZf
p6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/85sH2KeX
vj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf70RPUPjxLouB
EgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxcAwyWTbacW0sTDGoJ
en4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+NpuKpq32qLVaexOCCJB91
aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq1LzUMQ4uxxycjl0LWO1bBsY6
yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XOcajZb6GDu7PTFEdPkVu0k4vQyd3J
c/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV
2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRbjuxtfqRypNACK28+j3FsqcilAD0ADuIWCt0y
Ra7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7
QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxar
lr0grlQn92DQt1vBUk+nUFeHGZmegUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJ
o+2PGLb2d9WE5bw1L4DcnOco9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bF
zhw3eZylM2dgwkbWW3IyJp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwd
ElJmarxedr/u3P6CNn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivo
BjrfUgNB69zfb6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toV
EevCi9/ffmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzS
Y3FuBkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW
hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/dY1p7
qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1RgrYlfrRe
SqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxHdRJFGJkhfKxg
mM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3luaLNe1F++bjXGyWyz
ZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCmGIzpqKlm27KTSWUcAX1g
oBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJCBVkrrBJ1BewMmlVpgRUQF7wp
ItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQYIOhklDKzo2C1IV2sijzdhjorqwef
NdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41qKFl02YaswYNkULTeLC9CFFK4bDHDMmZb
hnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYvJpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkc
Hz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkhmt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlC
XaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7Wfg
ZOv4uLLl0w8wUah71QLBpJeXq/eMVVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6
vjt1z/ghMehVKiUpyt1VYBXCN6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oE
DQ6jB9Wc3Z6bm6zLTtLlgLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgX
s2kV4WUC0YR/KOLvPby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP
7LnTfsd42at3+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw90
1G+ttVlTJa34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K
+f59qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd
XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a8XoA
AAAASUVORK5CYII=
--000000000000b9c5020595bd3e66--


From nobody Fri Oct 25 08:18:19 2019
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C41120123 for ; Fri, 25 Oct 2019 08:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 TU3gsr7K7HcT for ; Fri, 25 Oct 2019 08:18:15 -0700 (PDT)
Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 33E4E120105 for ; Fri, 25 Oct 2019 08:18:15 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id EA051374288F; Fri, 25 Oct 2019 15:18:14 +0000 (UTC)
X-Virus-Scanned: amavisd-new at katezarealty.com
Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nJHEJ5rvl9Be; Fri, 25 Oct 2019 11:18:14 -0400 (EDT)
Received: from Maxs-MBP-2.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id E4BFD3741074; Fri, 25 Oct 2019 11:18:13 -0400 (EDT)
To: Ryan Sleevi 
Cc: LAMPS WG 
References: <8c84cf2c-c192-c13b-17e5-7ae09b748530@openca.org> 
From: "Dr. Pala" 
Message-ID: <07ee43b6-a1b2-c2d4-2361-e6f87d0197c0@openca.org>
Date: Fri, 25 Oct 2019 09:18:13 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------7E30010E0AE6F07E5C36392F"
Content-Language: en-US
Archived-At: 
Subject: Re: [lamps] The Status of OCSP and its future
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2019 15:18:17 -0000

This is a multi-part message in MIME format.
--------------7E30010E0AE6F07E5C36392F
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Ryan,

On 10/24/19 9:37 AM, Ryan Sleevi wrote:
>
>
> On Thu, Oct 24, 2019 at 11:01 AM Dr. Pala  > wrote:
>
>     Hi All,
>
>     I just wanted to start the conversation around the status of
>     revocation infrastructures and possible work we can be doing to
>     address some of new issues deriving [...]Our approach stem from
>     two practical considerations: the occasion to provide optimized
>     responses for the non-revoked case, and the possibility to reduce
>     the number of round trips required to retrieve the revocation
>     status for the full chain of certificates.
>
> Don't CRLs address this use case?
Yes and No. "Yes" because CRLs provide the same type of information - 
you are correct :D "No" because CRLs provide all the information at once 
- the reason we have OCSP today is to address the "Large CRLs" problem.
> That is, it's not clear "Why OCSP" vs "Why not something else" in your 
> overall message here.

Well, I do not want to exclude the possibility to work on "something 
else" :D

Our proposal is to provide a more efficient way to deliver the service 
that can still be used with current protocols (e.g., OCSP stapling) - 
this addresses the medium-term deployment and, we believe, provide an 
additional tool for the PKI architects when planning / designing the 
revocation infrastructure for their PKIs.

If there are other proposals on the table for improving efficiency, it 
would be great to hear them - this can spark an healthy discussion 
around handling revocation in PKIX (maybe a dedicated WG if LAMPS is not 
the right place... ?) :D However, until then, our proposal is to work on 
something rather than not do anything :D

>     [ ...]
>
> On a conceptual level, how is the concept of "Signed status 
> information for a range of certificates" functionally or conceptually 
> different than a CRL, potentially sharded (e.g. by varying the 
> issuerDistributionPoint extension within the CRL and the 
> crlDistributionPoint within the range of certificates).
>
> As best I can tell, the only difference is that it allows the CA to 
> rebalance the ranges post-issuance, but it's unclear if that's either 
> good or desirable from a validator perspective.
I think you got it right :D The main difference is that the 
issuerDistributionPoint is a static assignment and that might not be 
optimal. As you point out, it is a possibility today to do this, however 
there is no guarantee for the client that the target CRLs will not be 
big in size (since it is a static assignment, that is an unknown). 
Therefore, to provide the same level of flexibility, you might need to 
plan for thousands or even millions of different endpoints for a single 
CA. Conceptually, not a big issue. From a DevOps perspective... very 
scary, IMHO.
> [...]
>
> Similarly, this is unclear the set of problems you're trying to solve. 
> Did you mean to provide status information about the full chain? Or 
> did you actually meant the full chain?
>
> Clients already presumably have the full chain, as they're using OCSP 
> in the context of RFC 5280 path validation. If the goal is to be able 
> to use this within protocols that make OCSP available (e.g. TLS), then 
> you already have the means to deliver the additional certificates.
>
> So I'm not sure how to interpret this suggestion here, and/or why OCSP 
> is somehow the appropriate technology for it.
Sorry for the lack of clarity here - I meant providing the revocation 
information for the full chain, not the full chain itself :D In 
particular, although this is possible with today's protocol, it is a 
feature that is not used by clients. There might be several 
considerations as to why this is (my personal point of view is because 
of a series of different practical reasons - trust model, AIA in 
certificates, how path-building and validation is approached by crypto 
libraries).

As discussed before, there might be some other technologies for this - 
our proposal is to provide an updated version of the OCSP that optimizes 
responses for the non-revoked case and lowers the operational 
requirements and costs associated with it.

Does this address your questions ? Would you be interested in 
participating to the work ?

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

--------------7E30010E0AE6F07E5C36392F
Content-Type: multipart/related;
 boundary="------------62BBEC4CBA511630EB030559"


--------------62BBEC4CBA511630EB030559
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Ryan,

    
On 10/24/19 9:37 AM, Ryan Sleevi wrote:

    

    

      
      

        


        

        

        

          
On Thu, Oct 24, 2019 at
            11:01 AM Dr. Pala <madwolf@openca.org> wrote:

          

          

            

              
Hi All,

              
I just wanted to start the conversation around the
                status of revocation infrastructures and possible work
                we can be doing to address some of new issues deriving
                [...]Our approach stem from two practical
                considerations: the occasion to provide optimized
                responses for the non-revoked case, and the possibility
                to reduce the number of round trips required to retrieve
                the revocation status for the full chain of
                certificates.

            

          

          
Don't CRLs address this use case?

        

      

    

    Yes and No. "Yes" because CRLs provide the same type of information
    - you are correct :D "No" because CRLs provide all the information
    at once - the reason we have OCSP today is to address the "Large
    CRLs" problem.

    

      

        

          
That is, it's not clear "Why OCSP" vs "Why not something
            else" in your overall message here. 

          

        

      

    

    
Well, I do not want to exclude the possibility to work on
      "something else" :D 

    

    
Our proposal is to provide a more efficient way to deliver the
      service that can still be used with current protocols (e.g., OCSP
      stapling) - this addresses the medium-term deployment and, we
      believe, provide an additional tool for the PKI architects when
      planning / designing the revocation infrastructure for their PKIs.

    
If there are other proposals on the table for improving
      efficiency, it would be great to hear them - this can spark an
      healthy discussion around handling revocation in PKIX (maybe a
      dedicated WG if LAMPS is not the right place... ?) :D However,
      until then, our proposal is to work on something rather than not
      do anything :D

    

    

      

        

          

            
[ ...]

            

          

          
On a conceptual level, how is the concept of "Signed
            status information for a range of certificates" functionally
            or conceptually different than a CRL, potentially sharded
            (e.g. by varying the issuerDistributionPoint extension
            within the CRL and the crlDistributionPoint within the range
            of certificates).

          


          

          
As best I can tell, the only difference is that it allows
            the CA to rebalance the ranges post-issuance, but it's
            unclear if that's either good or desirable from a validator
            perspective.

        

      

    

    I think you got it right :D The main difference is that the
    issuerDistributionPoint is a static assignment and that might not be
    optimal. As you point out, it is a possibility today to do this,
    however there is no guarantee for the client that the target CRLs
    will not be big in size (since it is a static assignment, that is an
    unknown). Therefore, to provide the same level of flexibility, you
    might need to plan for thousands or even millions of different
    endpoints for a single CA. Conceptually, not a big issue. From a
    DevOps perspective... very scary, IMHO.

    

      

        

          
 

          [...]

          

          Similarly, this is unclear the set of problems you're trying
          to solve. Did you mean to provide status information about the
          full chain? Or did you actually meant the full chain?
          


          

          
Clients already presumably have the full chain, as
            they're using OCSP in the context of RFC 5280 path
            validation. If the goal is to be able to use this within
            protocols that make OCSP available (e.g. TLS), then you
            already have the means to deliver the additional
            certificates.

          


          

          
So I'm not sure how to interpret this suggestion here,
            and/or why OCSP is somehow the appropriate technology for
            it.

        

      

    

    
Sorry for the lack of clarity here - I
      meant providing the revocation information for the full chain, not
      the full chain itself :D In particular, although this is possible
      with today's protocol, it is a feature that is not used by
      clients. There might be several considerations as to why this is
      (my personal point of view is because of a series of different
      practical reasons - trust model, AIA in certificates, how
      path-building and validation is approached by crypto libraries).

    


    

    
As discussed before, there might be some
      other technologies for this - our proposal is to provide an
      updated version of the OCSP that optimizes responses for the
      non-revoked case and lowers the operational requirements and costs
      associated with it.

    


    

    
Does this address your questions ? Would
      you be interested in participating to the work ?

    

    


    

    
Cheers,

      Max

    

    


    

    
-- 

      

        Best Regards,
        

          Massimiliano Pala, Ph.D.

          OpenCA Labs Director

        

        OpenCA Logo

      

    

  


--------------62BBEC4CBA511630EB030559
Content-Type: image/png;
 name="dpfpiahmepoofedn.png"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="dpfpiahmepoofedn.png"

iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX
BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq
MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1
SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27
PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae
VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV
WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq
aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv
cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7
gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl
eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5
giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e
o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw
tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc
zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y
ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF
sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g
EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp
lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE
y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U
jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/
85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf
70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc
AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N
puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq
1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO
cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM
9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb
juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9
wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX
3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme
gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco
9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy
Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C
Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf
b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f
fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu
BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW
hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d
Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R
grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH
dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu
aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm
GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC
BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY
IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q
KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv
JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh
mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/
JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM
VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC
N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl
gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv
Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3
+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT
Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59
qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd
XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a
8XoAAAAASUVORK5CYII=
--------------62BBEC4CBA511630EB030559--

--------------7E30010E0AE6F07E5C36392F--


From nobody Fri Oct 25 08:38:11 2019
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB90120123 for ; Fri, 25 Oct 2019 08:38:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 S04yf6p3VAaR for ; Fri, 25 Oct 2019 08:38:06 -0700 (PDT)
Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 868291200C5 for ; Fri, 25 Oct 2019 08:38:06 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 34F5F374288F; Fri, 25 Oct 2019 15:38:06 +0000 (UTC)
X-Virus-Scanned: amavisd-new at katezarealty.com
Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7GJvKqo6Hi4i; Fri, 25 Oct 2019 11:38:04 -0400 (EDT)
Received: from Maxs-MBP-2.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 71DEA3741074; Fri, 25 Oct 2019 11:38:04 -0400 (EDT)
To: Phillip Hallam-Baker 
Cc: LAMPS WG 
References: <8c84cf2c-c192-c13b-17e5-7ae09b748530@openca.org> 
From: "Dr. Pala" 
Message-ID: 
Date: Fri, 25 Oct 2019 09:38:03 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------0D41C387A37495BC3423BEE8"
Content-Language: en-US
Archived-At: 
Subject: Re: [lamps] The Status of OCSP and its future
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2019 15:38:10 -0000

This is a multi-part message in MIME format.
--------------0D41C387A37495BC3423BEE8
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Phillip, All,

thanks for the reply - lots of interesting considerations. Please 
forgive me if I am not familiar with the details around your proposal 
(Mesh), however I think it is a good idea to work in the space - as you 
say, although the approach might be different, the problem is actually 
the same.

 From what you write, it seems that your approach is more "radical" and 
try to tackle the problem for a specific angle - the security of keys. I 
do not see this to be a competitor solution, but more as a comprehensive 
approach. In this vision, the two solutions might also have different 
time horizons: shorter for the OCSP optimization and longer for more 
comprehensive changes.

This said, I would like to re-focus the conversation on the proposed 
idea and ask you if you see any issue related to the proposal itself. 
Without more text and an I-D it is difficult to have a clear vision 
around it, but at least the core idea is there :D

Also, in case we do move forward, would you like to participate in the 
effort ?

Cheers,
Max

On 10/24/19 10:11 AM, Phillip Hallam-Baker wrote:
> On Thu, Oct 24, 2019 at 11:01 AM Dr. Pala  > wrote:
>
>     Given these considerations - and the fact that large PKIs are
>     being deployed, today, for the IoT case - we would like to start
>     the discussion around the current status of OCSP and possibly work
>     on a proposal for moving forward with a more efficient protocol.
>
>     What do you think ? Anybody would like to tackle this problem
>     together ?
>
> I am interested in the problem. I just disagree with the notion that 
> X.509/PKIX is a useful way to think about IoT devices. It is not what 
> the architecture was originally designed to serve and it doesn't 
> actually serve it at all well.
>
> The reason we need revocation in the WebPKI is that the primary 
> concern that infrastructure was originally designed to address was the 
> appearance of fake Web Merchants. The design brief was to make online 
> commerce as safe as bricks and mortar. The fundamental concern 
> VeriSign Class 3 was designed to meet was to establish accountability 
> so that posing as a fake Web merchant was unprofitable. And that 
> limited goal was achieved with enormous success. Or at least it was 
> before big tech thought it a good idea to strip out the security 
> signal from the browsers.
>
> The problem with the WebPKI is that it does not serve every purpose 
> well. And it has been co-opted to a rather sordid dispute into who can 
> invade users privacy to bombard them with ads and who can't. So we 
> have the current Congressional hearings and the looming anti-Trust 
> lawsuits. People who thought PKIX would be so much better without the 
> lawyers and were happy to see them disappear are going to be in for a 
> nasty shock in the next couple of years.
>
> We are long past the point where it is prudent for any of the Web 
> Browser providers with more than 5% market share to allow any of their 
> employees to contribute to discussions on the WebPKI without having 
> every email vetted by company lawyers and company lawyers attend every 
> meeting.
>
>
> The question to ask is why we need revocation at all. In the WebPKI it 
> is because:
>
> 1) Private keys are weakly bound to the devices and are prone to 
> disclosure.
> 2) WebPKI certificates conflate authentication and authorization and 
> it is necessary to revoke certificates that are being used by 
> criminals to steal money.
>
> Neither of these need be a concern in the IoT space. But certificate 
> expiry and revocation are deeply bound into the architecture. If you 
> decide neither is needed, you can greatly simplify the architecture: 
> Bind a keypair into the device during manufacture so that it can never 
> be extracted without serious effort and 99% of the causes of key 
> compromise disappear. Separate authentication and authorization and 
> there is no need for the PKI to be concerned with it.
>
> This is of course the approach I have taken in the Mesh (Singapore, 
> Friday 10:00am). But before people accuse me of using this to promote 
> my own work, it was this exact set of concerns that led me to design 
> the Mesh in the first place.
>
> And yes, we can't trust keys that come from a manufacturer and nor do 
> I suggest that we ever should. PKIX was designed according to the 
> cryptographic capabilities as they were understood in 1978 when 
> Kohnfelder wrote his master's thesis. We have moved on since. The 
> techniques I am applying were invented in the 1990s but since people 
> are loathe to recognize technology unless it is all bright and shiny, 
> I have re-branded them 'meta-cryptography'.
>
> Point is that today we face a number of concerns that were almost 
> entirely theoretical or limited to the most sensitive applications in 
> the 1990s:
>
> * Alice used to share her computer with more than 50 other students, 
> now she owns more than 50 computers. The key provisioning problem has 
> changed completely as a result.
>
> * Compromise in the supply chain is no longer a theoretical problem, 
> nor is the problem a single state actor as some suggest. The supply 
> chains are large, complex and opaque. Nobody really knows the 
> provenance of anything unless it is one of the handful of devices from 
> a trustworthy foundry.
>
> * The shortest password that is secure is far longer than the longest 
> password that is memorable and this cannot be solved by changing the 
> hash function. The capabilities of massively parallel machines 
> outstrips the capacity of a single core by many orders of magnitude. 
> There is no technical means of making exhaustive search prohibitive.
>
> * We are no longer just providing security to government employees, 
> academics and students. We can't expect them to adapt to our 
> technologies any more. _*Don't try to change the user*_.
>
> * The Internet has 5 billion users and 50 billion devices. Deployment 
> of technology is a vastly harder challenge than designing or 
> implementing it. We have to design for deployment and we cannot do 
> that with a design from the 1970s.
>
> This does not mean that PKIX is irrelevant, far from it. What I have 
> done in the Mesh is to take the use patterns that emerged from the 
> deployment and use of PKIX and reified them as architecture. So Alice 
> can now use online/offline key management to protect her data but 
> don't tell Alice that because she doesn't need to know thats what she 
> is doing.
>
>
> To paraphrase Keynes: We have unused cryptography in a world of 
> security need.
>
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

--------------0D41C387A37495BC3423BEE8
Content-Type: multipart/related;
 boundary="------------2175A7698B03A3FB0CAC9329"


--------------2175A7698B03A3FB0CAC9329
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Phillip, All,

    

    
thanks for the reply - lots of interesting considerations. Please
      forgive me if I am not familiar with the details around your
      proposal (Mesh), however I think it is a good idea to work in the
      space - as you say, although the approach might be different, the
      problem is actually the same.

    
From what you write, it seems that your approach is more "radical"
      and try to tackle the problem for a specific angle - the security
      of keys. I do not see this to be a competitor solution, but more
      as a comprehensive approach. In this vision, the two solutions
      might also have different time horizons: shorter for the OCSP
      optimization and longer for more comprehensive changes.

    

    
This said, I would like to re-focus the conversation on the
      proposed idea and ask you if you see any issue related to the
      proposal itself. Without more text and an I-D it is difficult to
      have a clear vision around it, but at least the core idea is there
      :D

    
Also, in case we do move forward, would you like to participate
      in the effort ?

    
Cheers,

      Max

      

    

    
On 10/24/19 10:11 AM, Phillip
      Hallam-Baker wrote:

    

    

      
      

        

          
On Thu, Oct
            24, 2019 at 11:01 AM Dr. Pala <madwolf@openca.org>
            wrote:

          

        

        

          

            

              
Given these considerations - and the fact that large
                PKIs are being deployed, today, for the IoT case - we
                would like to start the discussion around the current
                status of OCSP and possibly work on a proposal for
                moving forward with a more efficient protocol. 

              

              
What do you think ? Anybody would like to tackle this
                problem together ?

            

          

          

            
I am
              interested in the problem. I just disagree with the notion
              that X.509/PKIX is a useful way to think about IoT
              devices. It is not what the architecture was originally
              designed to serve and it doesn't actually serve it at all
              well.

            


            

            
The
              reason we need revocation in the WebPKI is that the
              primary concern that infrastructure was originally
              designed to address was the appearance of fake Web
              Merchants. The design brief was to make online commerce as
              safe as bricks and mortar. The fundamental concern
              VeriSign Class 3 was designed to meet was to establish
              accountability so that posing as a fake Web merchant was
              unprofitable. And that limited goal was achieved with
              enormous success. Or at least it was before big tech
              thought it a good idea to strip out the security signal
              from the browsers.

            


            

            
The
              problem with the WebPKI is that it does not serve every
              purpose well. And it has been co-opted to a rather sordid
              dispute into who can invade users privacy to bombard them
              with ads and who can't. So we have the current
              Congressional hearings and the looming anti-Trust
              lawsuits. People who thought PKIX would be so much better
              without the lawyers and were happy to see them disappear
              are going to be in for a nasty shock in the next couple of
              years.

            


            

            
We are
              long past the point where it is prudent for any of the Web
              Browser providers with more than 5% market share to allow
              any of their employees to contribute to discussions on the
              WebPKI without having every email vetted by company
              lawyers and company lawyers attend every meeting. 

            


            

            

          

          

            
The
              question to ask is why we need revocation at all. In the
              WebPKI it is because:

            


            

            
1)
              Private keys are weakly bound to the devices and are prone
              to disclosure.

            
2) WebPKI
              certificates conflate authentication and authorization and
              it is necessary to revoke certificates that are being used
              by criminals to steal money.

            

          

          

            
Neither
              of these need be a concern in the IoT space. But
              certificate expiry and revocation are deeply bound into
              the architecture. If you decide neither is needed, you can
              greatly simplify the architecture: Bind a keypair into the
              device during manufacture so that it can never be
              extracted without serious effort and 99% of the causes of
              key compromise disappear. Separate authentication and
              authorization and there is no need for the PKI to be
              concerned with it.

            


            

            
This is
              of course the approach I have taken in the Mesh
              (Singapore, Friday 10:00am). But before people accuse me
              of using this to promote my own work, it was this exact
              set of concerns that led me to design the Mesh in the
              first place.

            


            

            
And yes,
              we can't trust keys that come from a manufacturer and nor
              do I suggest that we ever should. PKIX was designed
              according to the cryptographic capabilities as they were
              understood in 1978 when Kohnfelder wrote his master's
              thesis. We have moved on since. The techniques I am
              applying were invented in the 1990s but since people are
              loathe to recognize technology unless it is all bright and
              shiny, I have re-branded them 'meta-cryptography'.

            

          

          

            
Point is
              that today we face a number of concerns that were almost
              entirely theoretical or limited to the most sensitive
              applications in the 1990s:

            


            

            
* Alice
              used to share her computer with more than 50 other
              students, now she owns more than 50 computers. The key
              provisioning problem has changed completely as a result.

            


            

            
*
              Compromise in the supply chain is no longer a theoretical
              problem, nor is the problem a single state actor as some
              suggest. The supply chains are large, complex and opaque.
              Nobody really knows the provenance of anything unless it
              is one of the handful of devices from a trustworthy
              foundry.

            


            

            
* The
              shortest password that is secure is far longer than the
              longest password that is memorable and this cannot be
              solved by changing the hash function. The capabilities of
              massively parallel machines outstrips the capacity of a
              single core by many orders of magnitude. There is no
              technical means of making exhaustive search prohibitive.

            


            

            
* We are
              no longer just providing security to government employees,
              academics and students. We can't expect them to adapt to
              our technologies any more. Don't try to change the
                  user.

            


            

            
* The
              Internet has 5 billion users and 50 billion devices.
              Deployment of technology is a vastly harder challenge than
              designing or implementing it. We have to design for
              deployment and we cannot do that with a design from the
              1970s.

            

          

          

            
This does
              not mean that PKIX is irrelevant, far from it. What I have
              done in the Mesh is to take the use patterns that emerged
              from the deployment and use of PKIX and reified them as
              architecture. So Alice can now use online/offline key
              management to protect her data but don't tell Alice that
              because she doesn't need to know thats what she is doing.

            

          

          


          

          

            
To
              paraphrase Keynes: We have unused cryptography in a world
              of security need.

            

          

        

      

    

    
-- 

      

        Best Regards,
        

          Massimiliano Pala, Ph.D.

          OpenCA Labs Director

        

        OpenCA Logo

      

    

  


--------------2175A7698B03A3FB0CAC9329
Content-Type: image/png;
 name="dpnoiamhhgfmaeap.png"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="dpnoiamhhgfmaeap.png"

iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX
BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq
MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1
SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27
PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae
VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV
WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq
aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv
cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7
gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl
eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5
giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e
o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw
tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc
zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y
ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF
sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g
EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp
lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE
y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U
jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/
85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf
70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc
AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N
puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq
1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO
cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM
9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb
juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9
wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX
3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme
gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco
9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy
Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C
Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf
b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f
fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu
BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW
hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d
Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R
grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH
dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu
aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm
GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC
BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY
IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q
KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv
JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh
mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/
JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM
VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC
N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl
gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv
Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3
+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT
Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59
qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd
XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a
8XoAAAAASUVORK5CYII=
--------------2175A7698B03A3FB0CAC9329--

--------------0D41C387A37495BC3423BEE8--


From nobody Fri Oct 25 08:51:15 2019
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17FE120911 for ; Fri, 25 Oct 2019 08:51:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 GxGp4LxeWvMu for ; Fri, 25 Oct 2019 08:51:12 -0700 (PDT)
Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) (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 BEF351200F7 for ; Fri, 25 Oct 2019 08:51:11 -0700 (PDT)
Received: by mail-ed1-f48.google.com with SMTP id a21so2198316edj.8 for ; Fri, 25 Oct 2019 08:51:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xxqkjXlsTKnwa06dpITa5GBKyu4Vph8d7rwRThwN8d8=; b=QDeFTigMlercc9kJ0utAZ+VvvRwGAFSgW5JJ+GdJ9r91OpLIToYwf56pzSvXHutMFP 6UcFcCkc9OTUGb6mnIrH2nlYY/vJqmOp/Mkk5Hn5ATcyRKs2M4Y55opb91/Fsk24K2bW A3aQ/2souE/fsQc02PKWsMU0W3GlsLGaKJSXsT0Bu0nxJUpZh2tBKMVHkTvLoAKYtePk YUEmTDuZuuqneeOlrkQ1Jjh63adREEOVhy14VBCRO7DvG+u8sjiN7BZ6g5VrzuwUFalZ mw1TchHJxKSx9T2h5KTRp0geHYrBLWzgWEWqjJ4gVMfqEdH9GVpLwCUL2LL6KzRhXEa/ q0TQ==
X-Gm-Message-State: APjAAAU5I4RHA8l7SliRR7CJpVgcAYtNflBSXOm1P8BRxeAixqpnYieK DoLkHd1tDT0WsojWUod4QJCYIwoz
X-Google-Smtp-Source: APXvYqw6q0iQ8sEe/XpKLjA7pxpCD7EAELOgQNNp8zUdTpvtbu9YQBtXy+rPOW/o3zitC5UgmTg0qQ==
X-Received: by 2002:a17:906:181b:: with SMTP id v27mr4287102eje.117.1572018669883;  Fri, 25 Oct 2019 08:51:09 -0700 (PDT)
Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com. [209.85.128.45]) by smtp.gmail.com with ESMTPSA id v13sm72984ede.82.2019.10.25.08.51.09 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Oct 2019 08:51:09 -0700 (PDT)
Received: by mail-wm1-f45.google.com with SMTP id q70so2678332wme.1 for ; Fri, 25 Oct 2019 08:51:09 -0700 (PDT)
X-Received: by 2002:a7b:cf36:: with SMTP id m22mr3952241wmg.98.1572018668880;  Fri, 25 Oct 2019 08:51:08 -0700 (PDT)
MIME-Version: 1.0
References: <8c84cf2c-c192-c13b-17e5-7ae09b748530@openca.org>  <07ee43b6-a1b2-c2d4-2361-e6f87d0197c0@openca.org>
In-Reply-To: <07ee43b6-a1b2-c2d4-2361-e6f87d0197c0@openca.org>
From: Ryan Sleevi 
Date: Fri, 25 Oct 2019 11:50:57 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: "Dr. Pala" 
Cc: Ryan Sleevi , LAMPS WG 
Content-Type: multipart/related; boundary="0000000000005732d40595be1e00"
Archived-At: 
Subject: Re: [lamps] The Status of OCSP and its future
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2019 15:51:14 -0000

--0000000000005732d40595be1e00
Content-Type: multipart/alternative; boundary="0000000000005732d20595be1eff"

--0000000000005732d20595be1eff
Content-Type: text/plain; charset="UTF-8"

On Fri, Oct 25, 2019 at 11:18 AM Dr. Pala  wrote:

> [ ...]
>>
> On a conceptual level, how is the concept of "Signed status information
> for a range of certificates" functionally or conceptually different than a
> CRL, potentially sharded (e.g. by varying the issuerDistributionPoint
> extension within the CRL and the crlDistributionPoint within the range of
> certificates).
>
> As best I can tell, the only difference is that it allows the CA to
> rebalance the ranges post-issuance, but it's unclear if that's either good
> or desirable from a validator perspective.
>
> I think you got it right :D The main difference is that the
> issuerDistributionPoint is a static assignment and that might not be
> optimal. As you point out, it is a possibility today to do this, however
> there is no guarantee for the client that the target CRLs will not be big
> in size (since it is a static assignment, that is an unknown). Therefore,
> to provide the same level of flexibility, you might need to plan for
> thousands or even millions of different endpoints for a single CA.
> Conceptually, not a big issue. From a DevOps perspective... very scary,
> IMHO.
>

I suppose I'm still not sure I fully understand your concerns here.

That is, it seems like as an operational consideration, the balancing of
the issuerDistributionPoint allows you to bound your worst-case
performance, while making suitable tradeoffs for your average and best case
scenarios. As others have suggested, it seems like more work would be
needed to show the math as to why this is a problem, given the rather
extensive flexibility already afforded to address this using existing
technologies.


> As discussed before, there might be some other technologies for this - our
> proposal is to provide an updated version of the OCSP that optimizes
> responses for the non-revoked case and lowers the operational requirements
> and costs associated with it.
>

As others have suggested (e.g. in PKIX), I think that it'd be far more
useful to not suggest it's a "OCSPv2" and instead highlight that you're
interested in providing an alternative revocation protocol, one that
seemingly combines elements of SCVP with the design of underlying protocols
like TLS.


> Does this address your questions ? Would you be interested in
> participating to the work ?
>

I have no interest in this work. I think that, for the problem described,
it would be incompatible and undesirable for the PKIs I work with (that is,
the Web PKI used by Chrome).

That doesn't preclude there being value in exploring this for other PKIs;
my only interest would be in trying to effectively communicate the lack of
interest to avoid overfit for an implementation that won't adopt :)

To echo other's remarks, I think an improved approach that clearly
communicated the problem statement, and the comparison with the existing
technologies and operational capabilities, would be very useful in helping
others determine the relevance to their PKIs and/or products. From both
this and the PKIX thread, I do feel I've got sufficient information to say
"Not interested", but it took me quite a bit of confusion to get there ;)

--0000000000005732d20595be1eff
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Fri, Oct 25, 2019 at 11:18 AM Dr. =
Pala <madwolf@openca.org> w=
rote:

    

      

        

          

            
[ ...]

            

          

          
On a conceptual level, how is the concept of "Signed
            status information for a range of certificates" functional=
ly
            or conceptually different than a CRL, potentially sharded
            (e.g. by varying the issuerDistributionPoint extension
            within the CRL and the crlDistributionPoint within the range
            of certificates).

          


          

          
As best I can tell, the only difference is that it allows
            the CA to rebalance the ranges post-issuance, but it's
            unclear if that's either good or desirable from a validator
            perspective.

        

      

    

    I think you got it right :D The main difference is that the
    issuerDistributionPoint is a static assignment and that might not be
    optimal. As you point out, it is a possibility today to do this,
    however there is no guarantee for the client that the target CRLs
    will not be big in size (since it is a static assignment, that is an
    unknown). Therefore, to provide the same level of flexibility, you
    might need to plan for thousands or even millions of different
    endpoints for a single CA. Conceptually, not a big issue. From a
    DevOps perspective... very scary, IMHO.

=

I suppose I'm still not sure I fully understand your concern=
s here.

That is, it seems like as an operational c=
onsideration, the balancing of the issuerDistributionPoint allows you to bo=
und your worst-case performance, while making suitable tradeoffs for your a=
verage and best case scenarios. As others have suggested, it seems like mor=
e work would be needed to show the math as to why this is a problem, given =
the rather extensive flexibility already afforded to address this using exi=
sting technologies.
=C2=A0

    
As discussed before, there might be some
      other technologies for this - our proposal is to provide an
      updated version of the OCSP that optimizes responses for the
      non-revoked case and lowers the operational requirements and costs
      associated with it.

As ot=
hers have suggested (e.g. in PKIX), I think that it'd be far more usefu=
l to not suggest it's a "OCSPv2" and instead highlight that y=
ou're interested in providing an alternative revocation protocol, one t=
hat seemingly combines elements of SCVP with the design of underlying proto=
cols like TLS.
=C2=A0

    
Does this address your questions ? Would
      you be interested in participating to the work ?

I have no interest in this work. I think that, for =
the problem described, it would be incompatible and undesirable for the PKI=
s I work with (that is, the Web PKI used by Chrome).

That doesn't preclude there being value in exploring this for other =
PKIs; my only interest would be in trying to effectively communicate the la=
ck of interest to avoid overfit for an implementation that won't adopt =
:)

To echo other's remarks, I think an improve=
d approach that clearly communicated the problem statement, and the compari=
son with the existing technologies and operational capabilities, would be v=
ery useful in helping others determine the relevance to their PKIs and/or p=
roducts. From both this and the PKIX thread, I do feel I've got suffici=
ent information to say "Not interested", but it took me quite a b=
it of confusion to get there ;)


--0000000000005732d20595be1eff--

--0000000000005732d40595be1e00
Content-Type: image/png; name="dpfpiahmepoofedn.png"
Content-Disposition: inline; filename="dpfpiahmepoofedn.png"
Content-Transfer-Encoding: base64
Content-ID: <16e0397526c490de0021>
X-Attachment-Id: 16e0397526c490de0021

iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoXBwES
CQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAqMjpXKgs/
MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1SGdDR0lDSFJf
RDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27PgCaSANtUT57VBer
SQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXaeVR+lVRZrYld1ZiB7YEuS
YQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDVWQJ1blapYjbXWgDRXACMaU6W
bgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3WqaS6BcGeobwndXwzkXwLgYgDaYwyM
eCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuvcEPrZQDQaSyockrFbSvmZwnabQLvZwDp
aQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqK
gnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXleSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQ
iwCximixim/EkAORkZGVkYrOh0rPiVL5giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvK
lGqpnJLdlF2boKy+m324nImkoZ+eo6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/S
rI7dq4bqqXTOrpWttL+6s6uwtbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfR
wbXFyMvbxbPNyMP8zgTczMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp
7/Hy9PHw9fj6/v3YktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPX
GT6E+l9BZ0EFsTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+U
SgFL4r9gEaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqE
SrMplYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE
y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75UjLZf
p6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/85sH2KeX
vj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf70RPUPjxLouB
EgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxcAwyWTbacW0sTDGoJ
en4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+NpuKpq32qLVaexOCCJB91
aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq1LzUMQ4uxxycjl0LWO1bBsY6
yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XOcajZb6GDu7PTFEdPkVu0k4vQyd3J
c/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV
2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRbjuxtfqRypNACK28+j3FsqcilAD0ADuIWCt0y
Ra7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7
QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxar
lr0grlQn92DQt1vBUk+nUFeHGZmegUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJ
o+2PGLb2d9WE5bw1L4DcnOco9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bF
zhw3eZylM2dgwkbWW3IyJp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwd
ElJmarxedr/u3P6CNn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivo
BjrfUgNB69zfb6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toV
EevCi9/ffmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzS
Y3FuBkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW
hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/dY1p7
qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1RgrYlfrRe
SqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxHdRJFGJkhfKxg
mM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3luaLNe1F++bjXGyWyz
ZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCmGIzpqKlm27KTSWUcAX1g
oBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJCBVkrrBJ1BewMmlVpgRUQF7wp
ItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQYIOhklDKzo2C1IV2sijzdhjorqwef
NdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41qKFl02YaswYNkULTeLC9CFFK4bDHDMmZb
hnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYvJpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkc
Hz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkhmt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlC
XaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7Wfg
ZOv4uLLl0w8wUah71QLBpJeXq/eMVVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6
vjt1z/ghMehVKiUpyt1VYBXCN6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oE
DQ6jB9Wc3Z6bm6zLTtLlgLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgX
s2kV4WUC0YR/KOLvPby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP
7LnTfsd42at3+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw90
1G+ttVlTJa34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K
+f59qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd
XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a8XoA
AAAASUVORK5CYII=
--0000000000005732d40595be1e00--


From nobody Fri Oct 25 09:55:16 2019
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9643120992 for ; Fri, 25 Oct 2019 09:55:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.781
X-Spam-Level: 
X-Spam-Status: No, score=0.781 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.159, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 1XCI10BEAOCo for ; Fri, 25 Oct 2019 09:55:13 -0700 (PDT)
Received: from mail-oi1-f195.google.com (mail-oi1-f195.google.com [209.85.167.195]) (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 E570112098B for ; Fri, 25 Oct 2019 09:55:12 -0700 (PDT)
Received: by mail-oi1-f195.google.com with SMTP id v186so2060203oie.5 for ; Fri, 25 Oct 2019 09:55:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=pp5wmep3nCGCvI+vcf01QwBRFhYXCPzVI78kj+QM+L4=; b=UUwwgkbYJWc2X81PCFfUNxKfnQ3Paww3s+bL/DutxiHmDdExNbYVUzBHJUxIhDmg5D JdbcNlh3j+z1bVkfgh1TKyXhn+oGzPEEWweShevR5Pqrd3vBEOqtyOw6eQNxgqh2eRNO JYDrdN8jKBZBmXEB6tMtJ/IbTOu2OuejwPqPX1RYr8wJU8jp0rjTA/Q9iHUiP0ioRSzq KK2XVQshH5E754lajGCajcZ5v6eiSpNJK6vnUD1w/RNZ57tZYgd/TP6kRqkLNucyJTe5 cw12XqzNkm284OT7tJd+veki3ROJ5hDxSlFzvE31wgPEu9zqIqJLAgumX9b4YoM2KQH6 m0VQ==
X-Gm-Message-State: APjAAAUCBr6ICTrMT/JTOEit1aABzeagpc1lqSyT9+XeH/qJgJQC/JRH Rh4mKhGyRSBUlq32y+5yOUWX9fMUmg6FdTr9Rwj98q1IRKw=
X-Received: by 2002:aca:4a49:: with SMTP id x70mt3611608oia.17.1572022511996;  Fri, 25 Oct 2019 09:55:11 -0700 (PDT)
MIME-Version: 1.0
References: <8c84cf2c-c192-c13b-17e5-7ae09b748530@openca.org>  <07ee43b6-a1b2-c2d4-2361-e6f87d0197c0@openca.org> 
In-Reply-To: 
From: Phillip Hallam-Baker 
Date: Fri, 25 Oct 2019 12:55:00 -0400
Message-ID: 
Cc: "Dr. Pala" , LAMPS WG 
Content-Type: multipart/alternative; boundary="00000000000069320d0595bf03ad"
Archived-At: 
Subject: Re: [lamps] The Status of OCSP and its future
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2019 16:55:15 -0000

--00000000000069320d0595bf03ad
Content-Type: text/plain; charset="UTF-8"

Returning to the original point, yes, there is indeed a problem with the
scalability of issuerDistributionPoints as we discovered when we visited
this whole discussion in 1998.

At the time we had a whole set of IPR issues covering a patent claim as
well. I don't recall whether it got anywhere but I suggested a mechanism
which avoids the scaling issue.

The problem with distribution points is that the partition of the
certificate space has to be decided in advance. Which forces the issuers to
be conservative in their partitioning. Worse, you are then obliged to
maintain separate CRLs for each partition whether you want to or not.

This is avoided by the introduction of a scope extension in the CRLs
specifying that it applies to a range of certificate serial numbers. This
means that if there are 500 revoked certs, the issuer can issue five CRLs
with 100 each. And then if the number increases to 750, they can increase
to 8 CRLs each of which is less than a hundred.

There are other schemes that can be used. It is actually possible to
compress CRLs even when the serial numbers are random numbers, Rob
Straddling and myself made some proposals in that area which I will
probably adopt at some point in the Mesh.

To respond to the specific points:

On Fri, Oct 25, 2019 at 11:38 AM Dr. Pala  wrote:

> Hi Phillip, All,
>
> thanks for the reply - lots of interesting considerations. Please forgive
> me if I am not familiar with the details around your proposal (Mesh),
> however I think it is a good idea to work in the space - as you say,
> although the approach might be different, the problem is actually the same.
>
> From what you write, it seems that your approach is more "radical" and try
> to tackle the problem for a specific angle - the security of keys. I do not
> see this to be a competitor solution, but more as a comprehensive approach.
> In this vision, the two solutions might also have different time horizons:
> shorter for the OCSP optimization and longer for more comprehensive changes.
>
There is a BOF in Singapore on Friday. I am currently working with people
to get the Web site put in order.
http://mathmesh.com/

There is a video series presenting the technical approach, the first parts
of which are available here:
https://www.youtube.com/playlist?list=PLK2hHAOxepEgGUx4SitfD4pIPHi86KHpi

These will be available as a download for people who are looking for some
in-flight entertainment for the flights to/from Singapore.

We also have some Internet drafts of which about 6 are reasonably complete
at this point (but not final of course).

This said, I would like to re-focus the conversation on the proposed idea
> and ask you if you see any issue related to the proposal itself. Without
> more text and an I-D it is difficult to have a clear vision around it, but
> at least the core idea is there :D
>
> Also, in case we do move forward, would you like to participate in the
> effort ?
>
Yes, I am interested in both. There might even be existing (but long
expired!) drafts.

I don't necessarily think the Mesh is in competition with or irrelevant to
PKIX. It might well be that what we end up doing is deciding that we want
to take advantage of the technology but want it in an ASN.1 idiom. That is
certainly possible but would obviously be a lot more design effort as one
of the reasons I was able to develop the Mesh in such a short time with
limited resources was that I ignored legacy constraints.

--00000000000069320d0595bf03ad
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Ret=
urning to the original point, yes, there is indeed a problem with the scala=
bility of issuerDistributionPoints as we discovered when we visited this wh=
ole discussion in 1998.

A=
t the time we had a whole set of IPR issues covering a patent claim as well=
. I don't recall whether it got anywhere but I suggested a mechanism wh=
ich avoids the scaling issue.

The problem with distribution points is that the partition of the cert=
ificate space has to be decided in advance. Which forces the issuers to be =
conservative in their partitioning. Worse, you are then obliged to maintain=
 separate CRLs for each partition whether you want to or not.

This is avoided by the introduction of=
 a scope extension in the CRLs specifying that it applies to a range of cer=
tificate serial numbers. This means that if there are 500 revoked certs, th=
e issuer can issue five CRLs with 100 each. And then if the number increase=
s to 750, they can increase to 8 CRLs each of which is less than a hundred.=


There are other schemes =
that can be used. It is actually possible to compress CRLs even when the se=
rial numbers are random numbers, Rob Straddling and myself made some propos=
als in that area which I will probably adopt at some point in the Mesh.

To respond to the specific p=
oints:

On Fri, Oct 25, 2019 at 11:38 AM Dr. Pala <madwolf@openca.org> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
 =20
   =20
 =20
  

    
Hi Phillip, All,

    

    
thanks for the reply - lots of interesting considerations. Please
      forgive me if I am not familiar with the details around your
      proposal (Mesh), however I think it is a good idea to work in the
      space - as you say, although the approach might be different, the
      problem is actually the same.

    
From what you write, it seems that your approach is more "radic=
al"
      and try to tackle the problem for a specific angle - the security
      of keys. I do not see this to be a competitor solution, but more
      as a comprehensive approach. In this vision, the two solutions
      might also have different time horizons: shorter for the OCSP
      optimization and longer for more comprehensive changes.
There is a BOF in Singapore on Friday. I am currently working=
 with people to get the Web site put in order.

There =
is a video series presenting the technical approach, the first parts of whi=
ch are available here:

These will be available as a download for people who are looking for som=
e in-flight entertainment for the flights to/from Singapore.

=

We also have some Internet drafts of which about 6 are reasonabl=
y complete at this point (but not final of course).

=
This said, I would like to re-focus the conversation on the
      proposed idea and ask you if you see any issue related to the
      proposal itself. Without more text and an I-D it is difficult to
      have a clear vision around it, but at least the core idea is there
      :D

    
Also, in case we do move forward, would you like to participate
      in the effort ?
Yes, I am interested in bo=
th. There might even be existing (but long expired!) drafts.

=

I don't necessarily think the Mesh is in competition with or=
 irrelevant to PKIX. It might well be that what we end up doing is deciding=
 that we want to take advantage of the technology but want it in an ASN.1 i=
diom. That is certainly possible but would obviously be a lot more design e=
ffort as one of the reasons I was able to develop the Mesh in such a short =
time with limited resources was that I ignored legacy constraints.

=C2=A0


--00000000000069320d0595bf03ad--


From nobody Fri Oct 25 14:15:17 2019
Return-Path: 
X-Original-To: spasm@ietf.org
Delivered-To: spasm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 425701209AA; Fri, 25 Oct 2019 14:12:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
Cc: spasm@ietf.org, rdd@cert.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.108.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <157203792526.2724.8433389945695227233.idtracker@ietfa.amsl.com>
Date: Fri, 25 Oct 2019 14:12:05 -0700
Archived-At: 
Subject: [lamps] lamps - Requested session has been scheduled for IETF 106
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2019 21:12:16 -0000

Dear Russ Housley,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 


    lamps Session 1 (1:00 requested)
    Monday, 18 November 2019, Afternoon Session III 1810-1910
    Room Name: Sophia size: 200
    ---------------------------------------------


iCalendar: https://datatracker.ietf.org/meeting/106/sessions/lamps.ics

Request Information:


---------------------------------------------------------
Working Group Name: Limited Additional Mechanisms for PKIX and SMIME
Area Name: Security Area
Session Requester: Russ Housley

Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 45
Conflicts to Avoid: 
 Chair Conflict: ipwave lamps suit
 Technology Overlap: acme cfrg ace
 Key Participant Conflict: oauth secdispatch saag sipbrandy tls mls teep


People who must be present:
  Russ Housley
  Rich Salz
  Sean Turner
  Alexey Melnikov
  Roman Danyliw
  Richard Barnes
  Bernie Hoeneisen
  Jim Schaad
  Tim Hollebeek
  Hendrik Brockhaus

Resources Requested:

Special Requests:
  
---------------------------------------------------------


From nobody Tue Oct 29 06:49:03 2019
Return-Path: 
X-Original-To: spasm@ietf.org
Delivered-To: spasm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A494D12000F; Tue, 29 Oct 2019 06:48:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: spasm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.108.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: spasm@ietf.org
Message-ID: <157235693459.6549.10489338447406353935@ietfa.amsl.com>
Date: Tue, 29 Oct 2019 06:48:54 -0700
Archived-At: 
Subject: [lamps] I-D Action: draft-ietf-lamps-header-protection-requirements-01.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2019 13:48:55 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF.

        Title           : Problem Statement and Requirements for Header Protection
        Authors         : Alexey Melnikov
                          Bernie Hoeneisen
	Filename        : draft-ietf-lamps-header-protection-requirements-01.txt
	Pages           : 24
	Date            : 2019-10-29

Abstract:
   Privacy and security issues with email header protection in S/MIME
   have been identified for some time.  However, the desire to fix these
   issues has only recently been expressed in the IETF LAMPS Working
   Group.  The existing S/MIME specification is likely to be updated
   regarding header protection.

   This document describes the problem statement, generic use cases, and
   requirements of header protection.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection-requirements/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lamps-header-protection-requirements-01
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-header-protection-requirements-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-header-protection-requirements-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Oct 29 07:34:30 2019
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65E012001E for ; Tue, 29 Oct 2019 07:34:28 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=x0YHq6Vn; dkim=pass (1024-bit key) header.d=primekey.com header.b=x0YHq6Vn
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 aVKJZzAVTIkR for ; Tue, 29 Oct 2019 07:34:26 -0700 (PDT)
Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9FEB12000F for ; Tue, 29 Oct 2019 07:34:25 -0700 (PDT)
Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id BF22C6AA0090 for ; Tue, 29 Oct 2019 15:34:12 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1572359652; bh=0EJhylCG6VBbohDFb80EN8hTDcIDvXrYCUnR7UT5d1M=; h=Subject:To:References:From:Date:In-Reply-To:From; b=x0YHq6Vnkt300Mfyk8e1ijZ7vXnBGaa+xQQu8Tk14Is5O7y1e03rIq5/6L4L5tmlg Und/ssZc/IjEl7zZfWQPL7VK+uDdOhO6fyAqJx7FKpog6cn/0QhZe1hi00TAdFGl0w f/bvvNQ7Aaosfw10A8vndA53yaK0NHc2uQtmKY/Y=
Received: from [192.168.43.52] (m80-170-216-165.cust.tele2.se [80.170.216.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id 9A32C6AA006B for ; Tue, 29 Oct 2019 15:34:09 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1572359652; bh=0EJhylCG6VBbohDFb80EN8hTDcIDvXrYCUnR7UT5d1M=; h=Subject:To:References:From:Date:In-Reply-To:From; b=x0YHq6Vnkt300Mfyk8e1ijZ7vXnBGaa+xQQu8Tk14Is5O7y1e03rIq5/6L4L5tmlg Und/ssZc/IjEl7zZfWQPL7VK+uDdOhO6fyAqJx7FKpog6cn/0QhZe1hi00TAdFGl0w f/bvvNQ7Aaosfw10A8vndA53yaK0NHc2uQtmKY/Y=
To: spasm@ietf.org
References: <8c84cf2c-c192-c13b-17e5-7ae09b748530@openca.org> <84e130d2-2df2-2f96-0200-716b333a1390@primekey.com> <7c618415-21d7-64c8-e43d-2617d59185f4@openca.org>
From: Tomas Gustavsson 
Openpgp: preference=signencrypt
Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= mQENBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAG0MFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPokB NwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5uQENBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAGJAR8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw==
Message-ID: <573f540c-288d-5f7a-26da-9b7266f2ad45@primekey.com>
Date: Tue, 29 Oct 2019 21:34:10 +0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <7c618415-21d7-64c8-e43d-2617d59185f4@openca.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [lamps] The Status of OCSP and its future
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2019 14:34:29 -0000

Hi Max,

On 2019-10-25 21:30, Dr. Pala wrote:
> Hi Tomas,
> 
> On 10/25/19 12:52 AM, Tomas Gustavsson wrote:
>> On 2019-10-24 17:01, Dr. Pala wrote:
>>> Hi All,
>>>
>>> I just wanted to start the conversation around the status of revocation
>>> [...]
>>> today, the larger the PKI is, the higher the costs of providing a good
>>> revocation infrastructure is.
>> As there are many PKIs today with 100M+ entities, some with and some
>> without revocation infrastructure, I think it's a bit too broad claim
>> for all use cases.
>> It is certainly true of all operations, the larger the scale the larger
>> infrastructure costs usually are, where OCSP I'd say is generally a very
>> minor part.
>> It differs from use case to use case though, I think it would be good
>> for the discussion to provide more details on your problematic use case,
>> architecture, use pattern etc. Many things are use case and
>> implementation choice specific.
> 
> This is a good point - very practical approach. A sample use-case is our
> industry (Cable). In particular, in our industry, we leverage PKIs to
> secure the communication in our networks: each Cable Modem and DVRs come
> with one or more certificates from our infrastructure. This covers all
> modems from all vendors from all operators.
> 
> Our Network, though, are going through radical changes that are aimed at
> providing the 10Gig platform we just released the standard for. In
> particular, the new architectures will see an increasing number of
> "entities" that require authentication.
> 
> As you can see, our PKI tend to be larger than what you typically see in
> the Web PKI (quite small in comparison - even combining all providers),
> therefore improving the efficiency and reducing the costs is a big win
> for the industry in general and for the users since we can now provide
> OCSP responses with shorter validity periods, thus reducing the risk
> level of our Access Networks.
> 
> This is not the only use-case, though.
> 
> Many IoT environments are starting to use digital certificates for
> authentication at a scale. Some environments, like the Power Grid, are
> already deploying solutions that use certificates to protect the
> communication up to the customers' premises.
> 
> Another use-case that I am bringing forward is Cellular. In particular,
> we already have standardized the use of certificates in some
> environments (e.g., CBRS-A, 5G Fixed, etc.) and it is expected that by
> freeing the network authentication from the need of a physical SIM (and
> associated licensing costs) we will see more and more devices (e.g., Fix
> and Industrial) using this technology.

These are all good examples of where PKI is used. Perhaps I am too eager
to quickly dive into technical details :-). What I was looking for was
some sort of calculations in the cost today using current technologies,
and the possible gains.

For example, (a very speculative one so please forgive my ignorance. I
am quite familiar with telecom and smart metering, but not with cable
modems):
- 100M set top boxes
- 100 media servers
Each set top box talks to media servers, load balanced.
Mutual TLS authentication, and revocation checks on all certificates
OCPS response lifetime 24h
Certificate lifetime of 1 year, renewal after 7 months

We will have somewhere around 150M certificates active. Servers can use
OCSP stapling, hence only 100 OCSP requests per day.
Each server may have contact with all set top boxes during an evening,
so each server has to make 150M OCSP requests per day. Servers cache
responses and don't make the same request twice if it already have a
fresh response. Everyone start their set top box during a two hour
window in the evening, so 150M*100/7200 OCSP requests must be handled
per second during this two hour window (it's almost 2M/second). Is this
something that you are thinking about where OCSP does not scale enough?

It is more about being able to respond quickly enough than to provision
the revocation information to OCSP responders though, so I'm not sure I
got the problem picture clear still.

> 
> This said, I think that reducing the costs of providing revocation
> information is a good goal in general and can help reducing
> authentication risks by providing shorter validity responses.
> 
>>> Our approach stem from two practical considerations: the occasion to
>>> provide optimized responses for the non-revoked case, and the
>>> [...]
>>>     planet :D
>> What could a "range" of certificates be based on?
>> (I consider sequential serialnumbers to be dead by now)
> 
> Our current approach is very simple. Take a CRL and produce (a) one
> response for each revoked certificate, and (b) one response for each
> range between revoked serial numbers. For example, if you have the
> following serial numbers revoked { 3, 5, 12 }, then you would sign 3
> responses for the 3 revoked certificates, plus the response from "0" to
> "3", two responses for the gaps between {3 and 5} and {5 and 12}, plus
> the last response for 5+. In this case, the number of revoked
> certificates is 3 and the number of signed responses is 2N + 1 = { 3
> revoked } + { 1 from 0 to the first entry } + { 2 gaps } + { 1 from last
> to infinity } = 7
> 
> Therefore, with this approach, if you are good at keeping the number of
> revoked certificates low, you can see how efficient this technique can
> be - especially when you revoked/valid certificate ratio is very low.

I think relying on sequential serialnumbers to be a big risk. It assumes
a lot of the PKI implementation, which may not be true. It is certainly
not true for the Web PKI, and also not for the IoT, Enterprise and smart
grid deployments we have been involved with. Any standard should not
rely on such PKI implementation details.

> 
>>>   * /*Providing Full Chain responses.*/ Although single OCSP responders
>>>     can be authoritative for their own CA only, they can attach the
>>>     responses for the full chain as additional data. If we add this
>>>     possibility, then a single OCSP request can provide the
>>>     client/server with the full chain of certificates up to the Root.
>>>     This might be tricky in complex scenarios where cross-certification
>>>     is used, but it would definitely work for the Web PKI and IoT use cases.
>> If extra round-tripping is needed it is certainly a concern. This is
>> also valid and discussed in the Web PKI case.
> It is to be mentioned that providing the full chain is possible today -
> however, no clients I know leverages this option. This, I think, it is
> because of several factors (i.e., trust model, AIA in certificates,
> etc.) that, if you are interested, we can explore separately.
>>> Given these considerations - and the fact that large PKIs are being
>>> deployed, today, for the IoT case - we would like to start the
>>> discussion around the current status of OCSP and possibly work on a
>>> proposal for moving forward with a more efficient protocol.
>> We do se working use cases with OCSP for huge number of devices, but in
>> IoT it's all use case dependent so I'm interested in more on your use case.
> 
> I hope that I provided you with some compelling scenarios here - I think
> that by optimizing the provisioning of revocation information we can
> help not only our specific use cases, but also the deployment of
> revocation information infrastructures that are low-cost for
> environments where using CDNs, Load Balancers, etc. is not an option
> because of the cost :D
> 
> Thanks for the reply - I do really appreciate the feedback!
> 
> Cheers,
> Max
> 
> -- 
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
> OpenCA Logo
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
> 


From nobody Tue Oct 29 13:07:29 2019
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C611200A3 for ; Tue, 29 Oct 2019 13:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 gpfgUYrST_Oe for ; Tue, 29 Oct 2019 13:07:26 -0700 (PDT)
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 1FC9612007A for ; Tue, 29 Oct 2019 13:07:25 -0700 (PDT)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1iPXlz-00041r-KG for spasm@ietf.org; Tue, 29 Oct 2019 21:07:23 +0100
Date: Tue, 29 Oct 2019 21:07:23 +0100 (CET)
From: Bernie Hoeneisen 
X-X-Sender: bhoeneis@softronics.hoeneisen.ch
To: IETF LAMPS WG 
Message-ID: 
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Archived-At: 
Subject: [lamps] How to proceed with Header Protection requirements
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2019 20:07:28 -0000

Dear LAMPS WG

We have submitted a new version of Header Protection Requirement that 
includes feedback from the LAMPS WG session in Montreal. Please find it at
https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection-requirements/


1) There are several open issues to be resolved, including

    o  In which form requirements for backward compatibility
       to legacy Header Protection should remain in this document?

    o  Should requirement G3 remain?
       "There SHOULD be a single format that covers all protection levels."

    o  Are there requirements missing?

    o  Should some requirement be stripped from the document?

Any comments?


2) Content-Type Parameter "forwarded"

During the LAMPS session in Montreal the introdution of a new Content-Type 
Parameter "forwarded" (as described in appendix A.1.2.1.) received quite 
some support. Several members of the LAMPS session expressed this to be 
useful. Not only in the context of encapsulated vs. forwarded message 
(incl. Header Protection), but also for helping with mailing list 
operations. At least two implementations using the Content-Type Parameter 
"forwarded" exist at this time.

Proposal:

   Standardize Content-Type Parameter "forwarded" as Working Group item of
   the LAMPS WG (to assist Header Protection and mailing lists).

Note: Which option to choose for Header Protection shall remain open. This 
proposal is not contradictionary to any of the options described in A1, 
but rather complementary.

Any opinions on this proposal?


Looking forward to your feedback and comments.


cheers,
  Bernie

--

http://ucom.ch/
Modern Telephony Solutions and Tech Consulting for Internet Technology


From nobody Wed Oct 30 05:40:25 2019
Return-Path: 
X-Original-To: spasm@ietf.org
Delivered-To: spasm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D14312010C; Wed, 30 Oct 2019 05:40:23 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= 
To: "The IESG" 
Cc: lamps-chairs@ietf.org, spasm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.108.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= 
Message-ID: <157243922359.32502.3188254132229524843.idtracker@ietfa.amsl.com>
Date: Wed, 30 Oct 2019 05:40:23 -0700
Archived-At: 
Subject: [lamps] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_charter-i?= =?utf-8?q?etf-lamps-04-00=3A_=28with_COMMENT=29?=
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2019 12:40:24 -0000

Éric Vyncke has entered the following ballot position for
charter-ietf-lamps-04-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-lamps/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

About the lightweight CMP, I suggest to have a close relationship with LWIG WG
(notably sharing the WG last call in both WG).

-éric



From nobody Wed Oct 30 11:35:16 2019
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977C01200FE; Wed, 30 Oct 2019 11:35:07 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.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 HBmgZANPTHlK; Wed, 30 Oct 2019 11:35:05 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 34FAA120873; Wed, 30 Oct 2019 11:35:04 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x9UIZ1m7009859; Wed, 30 Oct 2019 14:35:01 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x9UIZ1m7009859
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1572460501; bh=SjpWEYcqld82QAVvOUk5EHhgfqBd41HyML8v5EjTRd8=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=jV0kdEjqL/b1ohWKjdX7vtLiVFlls0wuOVEHjvu7jQG0T9fGejtmG+Dlvt5peAqWQ /9BRinBRE7z412HJsC4zqHPNZJVy55YRe3AgnB99WS9pB81Uk12pPPZzw1vT4WDQJR H02n4L4Wwah9SpwC0wW5g7pYzSDtuIFS5cQ1o7Fc=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x9UIYxEU002532; Wed, 30 Oct 2019 14:34:59 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0468.000; Wed, 30 Oct 2019 14:34:58 -0400
From: Roman Danyliw 
To: =?utf-8?B?w4lyaWMgVnluY2tl?= , The IESG 
CC: "spasm@ietf.org" , "lamps-chairs@ietf.org" 
Thread-Topic: =?utf-8?B?W2xhbXBzXSDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gY2hhcnRl?= =?utf-8?Q?r-ietf-lamps-04-00:_(with_COMMENT)?=
Thread-Index: AQHVjx845yV9e9iWG0ODEFSxa4JApqdzgxew
Date: Wed, 30 Oct 2019 18:34:58 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B34A5A58@marathon>
References: <157243922359.32502.3188254132229524843.idtracker@ietfa.amsl.com>
In-Reply-To: <157243922359.32502.3188254132229524843.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [lamps]  =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_charter-i?= =?utf-8?q?etf-lamps-04-00=3A_=28with_COMMENT=29?=
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2019 18:35:08 -0000

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU3Bhc20gW21haWx0bzpz
cGFzbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Ygw4lyaWMgVnluY2tlIHZpYQ0KPiBE
YXRhdHJhY2tlcg0KPiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMzAsIDIwMTkgODo0MCBBTQ0K
PiBUbzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjOiBzcGFzbUBpZXRmLm9yZzsgbGFt
cHMtY2hhaXJzQGlldGYub3JnDQo+IFN1YmplY3Q6IFtsYW1wc10gw4lyaWMgVnluY2tlJ3MgTm8g
T2JqZWN0aW9uIG9uIGNoYXJ0ZXItaWV0Zi1sYW1wcy0wNC0wMDoNCj4gKHdpdGggQ09NTUVOVCkN
Cj4gDQo+IMOJcmljIFZ5bmNrZSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3Np
dGlvbiBmb3INCj4gY2hhcnRlci1pZXRmLWxhbXBzLTA0LTAwOiBObyBPYmplY3Rpb24NCj4gDQo+
IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5k
IHJlcGx5IHRvIGFsbCBlbWFpbA0KPiBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBD
QyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkNCj4gcGFyYWdyYXBo
LCBob3dldmVyLikNCj4gDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVy
IGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFj
a2VyLmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYtbGFtcHMvDQo+IA0KPiANCj4gDQo+IC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gQWJvdXQgdGhlIGxp
Z2h0d2VpZ2h0IENNUCwgSSBzdWdnZXN0IHRvIGhhdmUgYSBjbG9zZSByZWxhdGlvbnNoaXAgd2l0
aCBMV0lHDQo+IFdHIChub3RhYmx5IHNoYXJpbmcgdGhlIFdHIGxhc3QgY2FsbCBpbiBib3RoIFdH
KS4NCg0KTWFrZXMgc2Vuc2UuICBJJ3ZlIGFkZGVkIHRleHQgdG8gbm90ZSB0aGlzIGNvb3JkaW5h
dGlvbiB3aXRoIExXSUcuDQoNClJvbWFuDQo=