From prvs=233ef1ebb=Justin.Cranford@entrustdatacard.com Tue Dec 3 15:54: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 5AE6512006F for ; Tue, 3 Dec 2019 15:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 h3EMj46rJEb4 for ; Tue, 3 Dec 2019 15:54:36 -0800 (PST) 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 18211120018 for ; Tue, 3 Dec 2019 15:54:35 -0800 (PST) IronPort-SDR: gHjPruNUvk57F3iAi8YOSgMeqZVIiBaWi0CZHZawamnYlZ7kR/Np0xKLL0bV+ziWqoOtdmrmfv EdnyE7MamyIA== X-IronPort-AV: E=Sophos;i="5.69,275,1571720400"; d="scan'208";a="62997803" 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; 03 Dec 2019 17:54:36 -0600 Received: from pmspex01.corporate.datacard.com (192.168.211.29) by pmspex02.corporate.datacard.com (192.168.211.30) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 3 Dec 2019 17:54:35 -0600 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (172.28.1.8) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 3 Dec 2019 17:54:34 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=of7GlC7yETrDCXt++Ou9ao933Dp3dROiKLkp6VBDibdS2iORokayHM6gJ9mGy8TTKGq7JFHlbDrPrbqBTeg7JO7tToh5QvltEsFr7D60ivo5rSTqFbO8HJ8OXflrDuFfu8mnwWL7y/dqON/2FtGlyVc+V6AouGv8APbRbkB8AmQ3P7c3LbIWQInTdzYQuhf61AnK9JNjyuF3iF+psypk4W0KmJA0DxSBRX/rgyaNc8rZ6eU66gpVr8NK2BnUbEpVLaIOfwbO0cO86gxKfV8hFcn2OAWu+91+04b1qo3fqnpyhRJKdZt2dYVC73oCC468KiLLRKDfr5lRh3lBT8tebw== 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=wNz1QfiDfldAzIUlGuL/L1FLT+XnqlZYACfDMyWmM4I=; b=OqrkytEMnzJCm+pCY4OrUL5yzlmDlOBjEewgfYZs2UL/0InyDYqlqFkn7A5J27Opuj+k1EDfKwE2h0KnKDVIoUd4JDOtihC2mTonc9cXSOAZ/ahVwVH/BRThUK/rR4of9/4A5WzVO5xkw96uZJHP2o2E211x8205qAXBVJAVT5VxWz73QKvqGeCtvDsfQZXLaOWwIPtJbMKJaAEmGxBGEf9fflvglDC/4pcm6obiUjLu6egy8wTH305yXcRnSWZxG6Q5DJkyaDb6X9J7Fi8UzloQJQD2G4TqQoI3hLuqynLnXskofvlkteGdxv18DkJmhpEiQASJzA/B9gS0OCc7cg== 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=selector1-entrustdatacardcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wNz1QfiDfldAzIUlGuL/L1FLT+XnqlZYACfDMyWmM4I=; b=YUZpjw+I+7ZcEQ45T9LHv5CDG0kDI1XraolOmpbkqvPsdLSIB4Tcj3980imx0c1ol16EOjpBYGkytFqrpWYnhSrZeceYCCi6EdiVZrHlolPi7Qdfk6PilkebAXLUkyeQaUFFUUzKq2m1vSYizPkGm4aicoUpFnQe7FtX2QGX+hE= Received: from CY4PR1101MB2246.namprd11.prod.outlook.com (10.174.52.144) by CY4PR1101MB2150.namprd11.prod.outlook.com (10.172.76.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.20; Tue, 3 Dec 2019 23:54:31 +0000 Received: from CY4PR1101MB2246.namprd11.prod.outlook.com ([fe80::197a:5e09:de68:555]) by CY4PR1101MB2246.namprd11.prod.outlook.com ([fe80::197a:5e09:de68:555%5]) with mapi id 15.20.2495.014; Tue, 3 Dec 2019 23:54:31 +0000 From: Justin Cranford To: "spasm@ietf.org" Thread-Topic: Feedback on figure 3 in draft-brockhaus-lamps-lightweight-cmp-profile-01 Thread-Index: AdWqNJPpfHT9y+XHSjCsxT/8ALDI9Q== Date: Tue, 3 Dec 2019 23:54:31 +0000 Message-ID: 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=Justin.Cranford@entrustdatacard.com; x-originating-ip: [216.191.252.67] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c345817b-3fd4-458a-263a-08d7784c244e x-ms-traffictypediagnostic: CY4PR1101MB2150: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(346002)(136003)(396003)(366004)(199004)(189003)(316002)(6116002)(966005)(14454004)(5660300002)(86362001)(478600001)(3846002)(186003)(6916009)(55016002)(5640700003)(9686003)(66556008)(66476007)(76116006)(6436002)(74316002)(64756008)(66946007)(71200400001)(8936002)(7696005)(33656002)(6506007)(8676002)(71190400001)(2501003)(26005)(1730700003)(6306002)(66446008)(2906002)(81156014)(81166006)(52536014)(7736002)(305945005)(14444005)(256004)(102836004)(99286004)(2351001)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR1101MB2150; H:CY4PR1101MB2246.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: pJFhOsCLQszpJkGwgim1WrX0ZfZ2OGqYF5642Y+fmPNZb46WNQDFLQVIhg439ANNDDFz+Y0mJJQodvjemky1kZa67D11F4brVU0Sc4TwU/EMRBlYdddXQKN7GGr601PBktAuVBuEDT0ZSCSHqWPhyL66o0d0bE07JF7VMI8nngyA7qIBB93cRi3Kx8/z3yUUKz+oKn+MWDu2tFE55uDUQOODHAw+REfp+7H36ZBLp0OEWW0eUAeKqlc3hFOiqlktHsQLXdlBYSCOsyZEeUUhJrIDhzCPP3aUIva7ihAXw52LTo7PHM4GcqZ73aXOoHNpQLijOsnBNh/r9SYQEgBief8jrJA9Ll9OJRbjUnKAQAqZaeKTwILeGA7vmmvRIsgML4AzNkr+EBkCn563N9cAKud1istSb5ZIpwuDKWsWWRubPFQS4DsphaPEXjYkemgtY4jEJNkmssDTjnb2efMHX8H76Lmxcsa0mww9WzUrVRU= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c345817b-3fd4-458a-263a-08d7784c244e X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2019 23:54:31.6764 (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: /B+uzeV4sm8ZN/Z33KnY/v3rbE1D7hj3P0/2nUqqq8PNWztl4koVx5mbKGBR7iWG4E50FPO6ShxpOg8/JlFqKJm/Uzh9Pu5A+oPJdrIaVuk8J+t2CacX/d4XhiAz1TO/ X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1101MB2150 X-OriginatorOrg: entrustdatacard.com Archived-At: Subject: [lamps] Feedback on figure 3 in draft-brockhaus-lamps-lightweight-cmp-profile-01 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, 03 Dec 2019 23:57:19 -0000 Hello, Figure 3 shows the proposed message format for securely returning a remote = generated privateKey to a lightweight CMP client. - https://tools.ietf.org/html/draft-brockhaus-lamps-lightweight-cmp-profile= -01#page-31 Feedback summary: 1. CMS SignedData should be the outer layer. 2. CMS ContentInfo should be used to wrap both of the CMS EnvelopedData and= CMS SignedData layers. 3. CMS Data may be useful to wrap the privateKey payload. Feedback details: 1. CMS SignedData should be the outer layer. a) When a lightweight IOT client receives a response, it should do the ligh= tweight SignedData verification first. b) In other words, if a lightweight client does heavyweight EnvelopedData d= ecryption first, and SignedData verification fails second, the client just = wasted a lot of processing power, battery life, and time. c) CMS SignedData can be used to provide extra data needed by the client to= decrypt EnvelopedData. Consider if client and server both use EC key pairs= . Example: EnvelopedData contains KeyAgreeRecipentInfo using static-static EC= DH algorithm. Client needs the server EC public key to compute EnvelopedDat= a KEK. Server options for the originator KeyIdentifier in KARI include Issu= erAndSerialNumber, SubjectKeyIdentifier, or OriginatorPublicKey. If server = chooses IssuerAndSerialNumber, the client must find the server's EC public = cert. That somewhere can be the SignedData certificates set if-and-only-if = SignedData is outside EnvelopedData. 2. CMS ContentInfo should be used to identify the CMS EnvelopedData and CMS= SignedData layers. a) The lightweight client's CMS parser can to do more strict verification o= f the response structure without incurring significant overhead. 3. CMS Data can be used to wrap the privateKey. a) This is optional, but it might be useful to wrap the payloads. b) If you choose to add a CMS Data layer, also wrap it with CMS ContentInfo= like in point #2. References: I based my feedback on SCEP pkiMessage format from Gutmann SCEP draft 14. S= CEP is a lightweight enrollment protocol with similar goals to lightweight = CMP profile draft. Gutmann SCEP draft 14 does a good job of explaining the structure of its se= cure pkiMessage format with different layers of ContentInfo, SignedData, En= velopedData, and Data. - https://tools.ietf.org/html/draft-gutmann-scep-14#page-13 (June 9 2019) Gutmann inherited this message format from Nourse SCEP draft 23. However, G= utmann does a much better job showing and explaining the structure, so use = the Gutmann reference. - https://tools.ietf.org/html/draft-nourse-scep-23#section-3 (September 201= 1) Here is a compact summary of the SCEP pkiMessage format. SCEP uses it for r= equests and responses. - SCEP's pkiMessage =3D ContentInfo[SignedData[ContentInfo[EnvelopedData[Co= ntentInfo[Data[payload]]]]]] Summary: Ignore SCEP payload formats since they are not applicable. Optionally use t= he same CMS Data layer. Definitely put SignedData first, and consider addi= ng ContentInfo wrappers for all CMS layers. Thank you, Justin Cranford Prin Software Developer Entrust Datacard From nobody Thu Dec 5 02:13:02 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 0600E1200A4; Thu, 5 Dec 2019 02:13:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: lamps-chairs@ietf.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <157554078098.16478.1397974597271236050.idtracker@ietfa.amsl.com> Date: Thu, 05 Dec 2019 02:13:00 -0800 Archived-At: Subject: [lamps] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_chart?= =?utf-8?q?er-ietf-lamps-04-01=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: Thu, 05 Dec 2019 10:13:01 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-lamps-04-01: 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: ---------------------------------------------------------------------- It's not fully clear to me what is meant with "these environments". I guess something with constraint devices...? Would be nice to be at least slightly more concrete to make the charter less ambiguous/less open-ended. From nobody Thu Dec 5 04:29:21 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 6E05F120041; Thu, 5 Dec 2019 04:29:19 -0800 (PST) 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 lgqRPpSyeJ_9; Thu, 5 Dec 2019 04:29:17 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70078.outbound.protection.outlook.com [40.107.7.78]) (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 6C49E120013; Thu, 5 Dec 2019 04:29:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MzPbfyF1e/aXvgmFll8V3UZP5oGil/n5fum8L4RpQiEwSIR+Sl0tS62OT1Yj0B28ENkZSO+pegKyeYdIVKFII6esWpzpm2X1LpGvYAxsE/KiPj5EGi7Ysepj3NGZoAWzoia583A8zkVlqFHx3cWvNSnXKcSwJWnhaPQghe9PbE0IlJqpsPqJtWQ2z0RudOMEITBWf+o2JlxsrbelWKvgdSNbfsFLEQ/QfuvrBLp/g0ARlhXIwHdyUTfZcetqHvu28az5vk4ncEbjB+//xxw3aUDJq1ufI27sFPfR4wwZUYbFtfN32ROhPhRM/IKmg94YCXioZrvRPkRsOCEs+3eWAg== 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=0pydllry50q1r+qdB8xdRXrO4jnkS6RnfO1CpA2zbe8=; b=dSt7Jog/PsGun3FVKLEjkN2zEiF2r4XjA0HPzFk94U+qZ93kXcCxjstbaRWCS5z2EFcsDNP5GZCeIMGSJDW4ZhDk59dDKSSlCE797NG1HISqFH0IxM+XOxYH4L+74OClpYd02n3dLUEQCjBkNg0uvJqszLSTdAORj5MhDQx3Zr10WhBaplEbsa+QlyuFgYt0bov2b3PMkcG88TCKmvUVCLV3uilj9vg6GePB7NBJjSNMtxixhJVvgnxcwVEp9d3LitW6DgsUNgUE0vxL6pL5/KtofptoccKrrkvm3i9nENL3qBtyR3CmahNl7LJplb9+UPagr4dhcZ+QJXm8m/qfhg== 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=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0pydllry50q1r+qdB8xdRXrO4jnkS6RnfO1CpA2zbe8=; b=gYIWJ3ltOWpNgYFHOpqlITVMMRi0bU2FxxfKQQukl/gUo46U5DRz70w+L0+ePUJ+Pqyrveqm8odvOMOVGl9BLPHLw5qBz/H7Tb8cM9P0HMzP9v8wcoxmbh4ic+ucyuozVKGSbQfRCUS3GX/8DvaisfKHW1mqEQccQJT6bU4ytlA= Received: from DB7PR10MB2411.EURPRD10.PROD.OUTLOOK.COM (20.176.238.95) by DB7PR10MB2059.EURPRD10.PROD.OUTLOOK.COM (52.134.97.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.13; Thu, 5 Dec 2019 12:29:14 +0000 Received: from DB7PR10MB2411.EURPRD10.PROD.OUTLOOK.COM ([fe80::e1f3:8a6c:f50f:f207]) by DB7PR10MB2411.EURPRD10.PROD.OUTLOOK.COM ([fe80::e1f3:8a6c:f50f:f207%7]) with mapi id 15.20.2516.014; Thu, 5 Dec 2019 12:29:14 +0000 From: "Brockhaus, Hendrik" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG CC: "spasm@ietf.org" , "lamps-chairs@ietf.org" Thread-Topic: =?utf-8?B?W2xhbXBzXSBNaXJqYSBLw7xobGV3aW5kJ3MgTm8gT2JqZWN0aW9uIG9uIGNo?= =?utf-8?Q?arter-ietf-lamps-04-01:_(with_COMMENT)?= Thread-Index: AQHVq1SdpaUWKFwVDU+OAxnbCYuY9qerdQtw Date: Thu, 5 Dec 2019 12:29:14 +0000 Message-ID: References: <157554078098.16478.1397974597271236050.idtracker@ietfa.amsl.com> In-Reply-To: <157554078098.16478.1397974597271236050.idtracker@ietfa.amsl.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.177] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8faaa834-8798-4a00-a9c5-08d7797ebd94 x-ms-traffictypediagnostic: DB7PR10MB2059: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02426D11FE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(366004)(39860400002)(346002)(376002)(199004)(189003)(5660300002)(99286004)(74316002)(305945005)(2906002)(76176011)(7696005)(52536014)(66446008)(66556008)(81156014)(66946007)(66476007)(64756008)(71190400001)(71200400001)(81166006)(9686003)(224303003)(76116006)(8936002)(4326008)(186003)(102836004)(11346002)(6506007)(14454004)(25786009)(478600001)(86362001)(33656002)(316002)(110136005)(54906003)(55016002)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR10MB2059; H:DB7PR10MB2411.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: GgujvquZCy72LOjAgj1Z3rcfvqCsoUU+IvUKA6vMme3QeTWbyp98RxRX1L2AyJguVxHkCWTXMNttiuulQ4BQFxHIHsIuGyaVLf7uHe60NpZA6mG2nCKMEMD3VixTjbisB7TIbemnW/7nyG1rPPdPhtV0PpWBgye416flPtxBFLANv0U6bJ9OUh5x57kX3voJGdQPQC2QgEzz4L9Yvia/Rsjus3RbUCQMmtdNxw1Pyne8sMKy3RM+ujeu0+PtXocSrKI1eZTJXaPSqnFvKhBI6DScgHs71A9I/kPnB9vfq4MtxM8+r3xKZaee6uuJNhtvvgbOK1A1GHVr256+rAmQIQbLkRu8m5OY2xodtVgF/7rzp11vdpY2v1e/iIbKOuf8R4ch9zS+cmOqygNgmB6ibnXsxbPhWC5lGIGifYJ628p76JxARMeeegsNATNjjwe1 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: 8faaa834-8798-4a00-a9c5-08d7797ebd94 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2019 12:29:14.8452 (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: 9M0J1XL3637uIsml1HRG3Z9wIgimU05vAahSZ9gjGx0ukquHCe/qC5LiU07Kan7E2c9Ue2hXayBhLDT05kfQuV0LIc22618xXzHA0lMcPs8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR10MB2059 Archived-At: Subject: Re: [lamps] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_chart?= =?utf-8?q?er-ietf-lamps-04-01=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: Thu, 05 Dec 2019 12:29:19 -0000 DQpIaSBNaXJqYQ0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudC4gWW91IGFyZSBwZXJmZWN0 bHkgcmlnaHQsIHRoZSB3b3JkaW5nICJ0aGVzZXMgZW52aXJvbm1lbnRzIiBpcyBxdWl0ZSB2YWd1 ZS4NCg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ IA0KPiBJdCdzIG5vdCBmdWxseSBjbGVhciB0byBtZSB3aGF0IGlzIG1lYW50IHdpdGggInRoZXNl IGVudmlyb25tZW50cyIuIEkgZ3Vlc3MNCj4gc29tZXRoaW5nIHdpdGggY29uc3RyYWludCBkZXZp Y2VzLi4uPyBXb3VsZCBiZSBuaWNlIHRvIGJlIGF0IGxlYXN0IHNsaWdodGx5IG1vcmUNCj4gY29u Y3JldGUgdG8gbWFrZSB0aGUgY2hhcnRlciBsZXNzIGFtYmlndW91cy9sZXNzIG9wZW4tZW5kZWQu DQo+IA0KDQpBcyBwb2ludGVkIG91dCBpbiB0aGUgaW50cm9kdWN0aW9uIG9mIHRoZSBJLUQgdGhl IENNUCBwcm9maWxlIGFkZHJlc3NlcyBtYWNoaW5lLXRvLW1hY2hpbmUgdXNlIGNhc2VzIGFuZCBm b2N1c3NlcyBvbiBtYXhpbXVtIGF1dG9tYXRpb24gb2YgY2VydGlmaWNhdGUgbWFuYWdlbWVudCBv ZiBzdWNoIG1hY2hpbmUgZW5kIGVudGl0aWVzIGFzIHdlbGwgYXMgZnVydGhlciBjb21tdW5pY2F0 aW9uIG9mIHRoZSBpbnZvbHZlZCBQS0kgbWFuYWdlbWVudCBlbnRpdGllcy4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tc25pcC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoyLiAg SW50cm9kdWN0aW9uDQoNCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIFBLSSBtYW5hZ2VtZW50 IG9wZXJhdGlvbnMgc3VwcG9ydGluZyBtYWNoaW5lLQ0KICAgdG8tbWFjaGluZSBhbmQgSW9UIHVz ZSBjYXNlcy4gIFRoZSBmb2N1cyBsaWVzIG9uIG1heGltdW0gYXV0b21hdGlvbg0KICAgYW5kIGlu dGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb24gb2YgYWxsIGludm9sdmVkIFBLSSBlbnRpdGllcyBm cm9tDQogICBlbmQgZW50aXRpZXMgKEVFKSB0aHJvdWdoIGFuIG9wdGlvbmFsIExvY2FsIFJlZ2lz dHJhdGlvbiBBdXRob3JpdHkNCiAgIChMUkEpIGFuZCB0aGUgUkEgdXAgdG8gdGhlIENBLiBbLi4u XQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1zbmlwLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KSSBhbSBoYXBweSB0byBjaGFuZ2UgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgdGV4 dCBhY2NvcmRpbmdseSB0byBtYWtlIGl0IG1vcmUgY2xlYXIuIFdvdWxkIHRoaXMgd29yZGluZyBi ZSBiZXR0ZXI/DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXNuaXAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KMy4gVGhlIENlcnRpZmljYXRlIE1hbmFnZW1lbnQgUHJvdG9jb2wg KENNUCkgaXMgc3BlY2lmaWVkIGluIFJGQyA0MjEwLA0KYW5kIGl0IG9mZmVycyBhIHZhc3QgcmFu Z2Ugb2YgY2VydGlmaWNhdGUgbWFuYWdlbWVudCBvcHRpb25zLiAgQ01QIGlzDQpjdXJyZW50bHkg YmVpbmcgdXNlZCBpbiBtYW55IGRpZmZlcmVudCBpbmR1c3RyaWFsIGVudmlyb25tZW50cywgYnV0 IGl0DQpuZWVkcyB0byBiZSB0YWlsb3JlZCB0byB0aGUgc3BlY2lmaWMgbmVlZHMgb2Ygc3VjaCBt YWNoaW5lLXRvLW1hY2hpbmUgDQpzY2VuYXJpb3MgYW5kIGNvbW11bmljYXRpb24gYW1vbmcgUEtJ IG1hbmFnZW1lbnQgZW50aXRpZXMuICBUaGUNCkxBTVBTIFdHIHdpbGwgZGV2ZWxvcCBhICJsaWdo dHdlaWdodCIgcHJvZmlsZSBvZiBDTVAgdG8gbW9yZSBlZmZpY2llbnRseQ0Kc3VwcG9ydCBvZiB0 aGVzZSBlbnZpcm9ubWVudHMgYW5kIGJldHRlciBmYWNpbGl0YXRlIGludGVyb3BlcmFibGUNCmlt cGxlbWVudGF0aW9uLCB3aGlsZSBwcmVzZXJ2aW5nIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtIGFn aWxpdHkuICBJbg0KYWRkaXRpb24sIG5lY2Vzc2FyeSB1cGRhdGVzIGFuZCBjbGFyaWZpY2F0aW9u cyB0byBDTVAgd2lsbCBiZSBzcGVjaWZpZWQNCmluIGEgc2VwYXJhdGUgZG9jdW1lbnQuICBUaGlz IHdvcmsgd2lsbCBiZSBjb29yZGluYXRlZCB3aXRoIHRoZSBMV0lHIFdHLg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS1zbmlwLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KSGVu ZHJpaw0K From nobody Thu Dec 5 05:29: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 9FC24120020; Thu, 5 Dec 2019 05:29:47 -0800 (PST) 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, 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 7Z56IFB9WXZE; Thu, 5 Dec 2019 05:29:45 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 3A0B6120013; Thu, 5 Dec 2019 05:29:45 -0800 (PST) Received: from 200116b82cc7ef0034996fbfb45dc371.dip.versatel-1u1.de ([2001:16b8:2cc7:ef00:3499:6fbf:b45d:c371]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1icrCQ-00022P-LL; Thu, 05 Dec 2019 14:29:42 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Thu, 5 Dec 2019 14:29:41 +0100 Cc: The IESG , "spasm@ietf.org" , "lamps-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <891A01E6-631D-4DCD-9145-FCCCB9077B47@kuehlewind.net> References: <157554078098.16478.1397974597271236050.idtracker@ietfa.amsl.com> To: "Brockhaus, Hendrik" X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1575552585;4d1bce7b; X-HE-SMSGID: 1icrCQ-00022P-LL Archived-At: Subject: Re: [lamps] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_chart?= =?utf-8?q?er-ietf-lamps-04-01=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: Thu, 05 Dec 2019 13:29:48 -0000 Yes, I think that would be better. Thanks! > On 5. Dec 2019, at 13:29, Brockhaus, Hendrik = wrote: >=20 >=20 > Hi Mirja >=20 > Thank you for your comment. You are perfectly right, the wording = "theses environments" is quite vague. >=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> It's not fully clear to me what is meant with "these environments". I = guess >> something with constraint devices...? Would be nice to be at least = slightly more >> concrete to make the charter less ambiguous/less open-ended. >>=20 >=20 > As pointed out in the introduction of the I-D the CMP profile = addresses machine-to-machine use cases and focusses on maximum = automation of certificate management of such machine end entities as = well as further communication of the involved PKI management entities. > -----------------------------snip----------------------------- > 2. Introduction >=20 > This document specifies PKI management operations supporting = machine- > to-machine and IoT use cases. The focus lies on maximum automation > and interoperable implementation of all involved PKI entities from > end entities (EE) through an optional Local Registration Authority > (LRA) and the RA up to the CA. [...] > -----------------------------snip----------------------------- >=20 > I am happy to change the proposed charter text accordingly to make it = more clear. Would this wording be better? > -----------------------------snip----------------------------- > 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 such machine-to-machine=20= > scenarios and communication among PKI management entities. 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. This work will be coordinated with the LWIG = WG. > -----------------------------snip----------------------------- >=20 > Hendrik From nobody Thu Dec 5 06:01:01 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 C05EC12004A; Thu, 5 Dec 2019 06:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 gOBflLn3oPEc; Thu, 5 Dec 2019 06:00:54 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 CEEB2120013; Thu, 5 Dec 2019 06:00:53 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id xB5E0qlN042024; Thu, 5 Dec 2019 09:00:52 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu xB5E0qlN042024 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1575554452; bh=ZddW4RUGjIxUFZn1btYHXkUMIPit6PlJxrfYda4Wc90=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=UbbcyCL+gqXWBPSbyykvA3eufgU376MmKU3KCHE8evmGrkx8Ex/lcLOWpWeciX/3h lN8zjZeYLExPD0gPNQagVNbgTqRy/ueqh5heAbWijqPCpUV8MP18sfS3finYSMacDp cG1xCnudMIsiX7RU+yQeubQ8JmJnW1y+jQIDOImo= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id xB5E0miG011402; Thu, 5 Dec 2019 09:00:48 -0500 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0468.000; Thu, 5 Dec 2019 09:00:48 -0500 From: Roman Danyliw To: Mirja Kuehlewind , "Brockhaus, Hendrik" CC: "spasm@ietf.org" , "lamps-chairs@ietf.org" , The IESG Thread-Topic: =?iso-8859-1?Q?[lamps]_Mirja_K=FChlewind's_No_Objection_on_charter-ietf-l?= =?iso-8859-1?Q?amps-04-01:_(with_COMMENT)?= Thread-Index: AQHVq1SZdPUfUhsuTkC3P2c1NohRZKerzF0AgAAQ5ID//7SukA== Date: Thu, 5 Dec 2019 14:00:47 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01E70CF0D1@marchand> References: <157554078098.16478.1397974597271236050.idtracker@ietfa.amsl.com> <891A01E6-631D-4DCD-9145-FCCCB9077B47@kuehlewind.net> In-Reply-To: <891A01E6-631D-4DCD-9145-FCCCB9077B47@kuehlewind.net> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_cha?= =?iso-8859-1?q?rter-ietf-lamps-04-01=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: Thu, 05 Dec 2019 14:00:56 -0000 This change is now reflected in the 04-02 version of the charter. Roman > -----Original Message----- > From: iesg On Behalf Of Mirja Kuehlewind > Sent: Thursday, December 05, 2019 8:30 AM > To: Brockhaus, Hendrik > Cc: spasm@ietf.org; lamps-chairs@ietf.org; The IESG > Subject: Re: [lamps] Mirja K=FChlewind's No Objection on charter-ietf-lam= ps- > 04-01: (with COMMENT) >=20 > Yes, I think that would be better. Thanks! >=20 > > On 5. Dec 2019, at 13:29, Brockhaus, Hendrik > wrote: > > > > > > Hi Mirja > > > > Thank you for your comment. You are perfectly right, the wording "these= s > environments" is quite vague. > > > >> > >> --------------------------------------------------------------------- > >> - > >> COMMENT: > >> --------------------------------------------------------------------- > >> - > >> > >> It's not fully clear to me what is meant with "these environments". I > >> guess something with constraint devices...? Would be nice to be at > >> least slightly more concrete to make the charter less ambiguous/less > open-ended. > >> > > > > As pointed out in the introduction of the I-D the CMP profile addresses > machine-to-machine use cases and focusses on maximum automation of > certificate management of such machine end entities as well as further > communication of the involved PKI management entities. > > -----------------------------snip----------------------------- > > 2. Introduction > > > > This document specifies PKI management operations supporting machine- > > to-machine and IoT use cases. The focus lies on maximum automation > > and interoperable implementation of all involved PKI entities from > > end entities (EE) through an optional Local Registration Authority > > (LRA) and the RA up to the CA. [...] > > -----------------------------snip----------------------------- > > > > I am happy to change the proposed charter text accordingly to make it > more clear. Would this wording be better? > > -----------------------------snip----------------------------- > > 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 such machine-to-machine > > scenarios and communication among PKI management entities. 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. This work will be coordinated with t= he > LWIG WG. > > -----------------------------snip----------------------------- > > > > Hendrik From nobody Thu Dec 5 06:37: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 ECF1D120013 for ; Thu, 5 Dec 2019 06:37:49 -0800 (PST) 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=unavailable 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 U40F8ANXvx2a for ; Thu, 5 Dec 2019 06:37:47 -0800 (PST) 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 8DD7E120019 for ; Thu, 5 Dec 2019 06:37:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0DE75300B08 for ; Thu, 5 Dec 2019 09:37:46 -0500 (EST) 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 ChCHzBhVZpVf for ; Thu, 5 Dec 2019 09:37:44 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id A2661300A3B; Thu, 5 Dec 2019 09:37:44 -0500 (EST) 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: <157554078098.16478.1397974597271236050.idtracker@ietfa.amsl.com> Date: Thu, 5 Dec 2019 09:37:45 -0500 Cc: IESG , LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <157554078098.16478.1397974597271236050.idtracker@ietfa.amsl.com> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_chart?= =?utf-8?q?er-ietf-lamps-04-01=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: Thu, 05 Dec 2019 14:37:50 -0000 > On Dec 5, 2019, at 5:13 AM, Mirja K=C3=BChlewind via Datatracker = wrote: >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > charter-ietf-lamps-04-01: No Objection >=20 > 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.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-lamps/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > It's not fully clear to me what is meant with "these environments". I = guess > something with constraint devices...? Would be nice to be at least = slightly > more concrete to make the charter less ambiguous/less open-ended. Perhaps it would be more clear to say: ... support of environments that include constrained devices and better facilitate interoperable implementation ...= From nobody Thu Dec 5 06:48:23 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 B1CFE120104; Thu, 5 Dec 2019 06:48:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: lamps-chairs@ietf.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <157555728863.16390.3630034252134851529.idtracker@ietfa.amsl.com> Date: Thu, 05 Dec 2019 06:48:08 -0800 Archived-At: Subject: [lamps] Magnus Westerlund's Block on charter-ietf-lamps-04-02: (with BLOCK) 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: Thu, 05 Dec 2019 14:48:10 -0000 Magnus Westerlund has entered the following ballot position for charter-ietf-lamps-04-02: Block 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/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- Regarding: The LAMPS WG may produce clarifications where needed, but the LAMPS WG shall not adopt anything beyond clarifications without rechartering. ... may produce clarifications ... I would argue that this allows for updates specifications that doesn't change the scope of the specification. Some clarifications may result in a actual change of a prior WG consensus decision. If that is what is intended, then fine. But I would appreciate some clarification on what type of work is actually expected here. From nobody Thu Dec 5 06:56:41 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 39B50120013 for ; Thu, 5 Dec 2019 06:56:35 -0800 (PST) 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=unavailable 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 H3Oscduq9b1j for ; Thu, 5 Dec 2019 06:56:33 -0800 (PST) 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 100D112002E for ; Thu, 5 Dec 2019 06:56:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6730A300B31 for ; Thu, 5 Dec 2019 09:56:31 -0500 (EST) 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 aryDIBZCTrhZ for ; Thu, 5 Dec 2019 09:56:29 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id EA5DE300A3B; Thu, 5 Dec 2019 09:56:28 -0500 (EST) 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: <157555728863.16390.3630034252134851529.idtracker@ietfa.amsl.com> Date: Thu, 5 Dec 2019 09:56:29 -0500 Cc: IESG , LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <437ABB37-76FB-4BA1-A619-3B4DB04C82DB@vigilsec.com> References: <157555728863.16390.3630034252134851529.idtracker@ietfa.amsl.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Magnus Westerlund's Block on charter-ietf-lamps-04-02: (with BLOCK) 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, 05 Dec 2019 14:56:35 -0000 > On Dec 5, 2019, at 9:48 AM, Magnus Westerlund via Datatracker = wrote: >=20 > Magnus Westerlund has entered the following ballot position for > charter-ietf-lamps-04-02: Block >=20 > 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.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-lamps/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- >=20 > Regarding: >=20 > The LAMPS WG may produce > clarifications where needed, but the LAMPS WG shall not adopt > anything beyond clarifications without rechartering. >=20 > ... may produce clarifications ... >=20 > I would argue that this allows for updates specifications that doesn't = change > the scope of the specification. Some clarifications may result in a = actual > change of a prior WG consensus decision. If that is what is intended, = then > fine. But I would appreciate some clarification on what type of work = is > actually expected here. There is not intent to change previous consensus. In Singapore, these = were discussed as likely work: - draft-richardson-lamps-rfc7030est-clarify - draft-turner-5480-ku-clarifications - draft-housley-lamps-cms-update-alg-id-protect I'm not sure how you want to constrain the charter beyond = clarifications. Russ From nobody Thu Dec 5 07:00: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 E616F12002E; Thu, 5 Dec 2019 06:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 HEar2TYQY_hq; Thu, 5 Dec 2019 06:59:57 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 BADDD120013; Thu, 5 Dec 2019 06:59:57 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id xB5ExpWD046988; Thu, 5 Dec 2019 09:59:51 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu xB5ExpWD046988 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1575557991; bh=H7RyyINGHyN7KLMLz+d8jrk4sR8VmykVOo4IXLE7tCo=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=MJA7G1DxjsJTqfV1bnohTY68wiHqhzZg0QcYbOUHVuiJ+V69zqftkqNgtRgbsq3Kh oAcDBvHpZqzJUd/Rt66tkGObH+AZ2PuJ2GWEcXkId+dciGQbqKvSv8BnekOL6KLhJ1 qPaCUX6R1WCFjqQNG2Hq8eAx2Q/oTsXOHdET6mDI= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id xB5Exnmb023645; Thu, 5 Dec 2019 09:59:49 -0500 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0468.000; Thu, 5 Dec 2019 09:59:49 -0500 From: Roman Danyliw To: Russ Housley , Magnus Westerlund CC: LAMPS WG , IESG Thread-Topic: Magnus Westerlund's Block on charter-ietf-lamps-04-02: (with BLOCK) Thread-Index: AQHVq3sLy6Tq9t7M+UG/tmKJpfMAZKer9TSA//+sejA= Date: Thu, 5 Dec 2019 14:59:48 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01E70CF64E@marchand> References: <157555728863.16390.3630034252134851529.idtracker@ietfa.amsl.com> <437ABB37-76FB-4BA1-A619-3B4DB04C82DB@vigilsec.com> In-Reply-To: <437ABB37-76FB-4BA1-A619-3B4DB04C82DB@vigilsec.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] Magnus Westerlund's Block on charter-ietf-lamps-04-02: (with BLOCK) 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, 05 Dec 2019 15:00:00 -0000 Hi Magnus! Briefly. We can talk in a few minutes during the telechat ... > -----Original Message----- > From: iesg On Behalf Of Russ Housley > Sent: Thursday, December 05, 2019 9:56 AM > To: Magnus Westerlund > Cc: LAMPS WG ; IESG > Subject: Re: Magnus Westerlund's Block on charter-ietf-lamps-04-02: (with > BLOCK) >=20 >=20 >=20 > > On Dec 5, 2019, at 9:48 AM, Magnus Westerlund via Datatracker > wrote: > > > > Magnus Westerlund has entered the following ballot position for > > charter-ietf-lamps-04-02: Block > > > > 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/ > > > > > > > > ---------------------------------------------------------------------- > > BLOCK: > > ---------------------------------------------------------------------- > > > > Regarding: > > > > The LAMPS WG may produce > > clarifications where needed, but the LAMPS WG shall not adopt anything > > beyond clarifications without rechartering. > > > > ... may produce clarifications ... > > > > I would argue that this allows for updates specifications that doesn't > > change the scope of the specification. Some clarifications may result > > in a actual change of a prior WG consensus decision. If that is what > > is intended, then fine. But I would appreciate some clarification on > > what type of work is actually expected here. >=20 > There is not intent to change previous consensus. In Singapore, these we= re > discussed as likely work: >=20 > - draft-richardson-lamps-rfc7030est-clarify > - draft-turner-5480-ku-clarifications > - draft-housley-lamps-cms-update-alg-id-protect >=20 > I'm not sure how you want to constrain the charter beyond clarifications. "May produce clarifications" is intended to capture small scope clarificati= ons to work from the closed PKIX and S/MIME working group like Russ identif= ied above.. Any new work or extensions would require a re-charter. Roman From nobody Thu Dec 5 08:57:36 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 ED1CD1209D8 for ; Thu, 5 Dec 2019 08:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 9Zv3XnHTdfMK for ; Thu, 5 Dec 2019 08:57:30 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150077.outbound.protection.outlook.com [40.107.15.77]) (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 35AE91209CC for ; Thu, 5 Dec 2019 08:57:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MfJks5VpfMubqv8JRw9bh3+tz/jIs7dtDyQvUXoX/VFeyE50IbIFLv9yiMcHxRKLBq4Wst5iiIH9ot44cLKerIXwAD+4eJurq1A4jbpTV+Nh/HPgmkmUeSCKc5q8K6j/2BsFbHaNGPqmcatxcgmdWoxYh711gMxAbw1bz/jbTOnYNRJ5msbyNx5mDxN3z+PCwfIvlzaQRp6Wbv7L+5pZ4KTJdeNb98cd4HyNLF5LvIlzB/0WxDo6qUBppwTryr4RIMGHVMqLkOkYymAkQMf/lGsekceBvxFKxYXB5ghpdHL2HnbgDejT+YQYnyKjJ0CEZAwf21sL9V0USGC9WDbGVw== 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=W9qn6LRkZ0uO46liU+do1AoSDNiGW5rf4lMm/aQeLJk=; b=DqXLkKseQsr4l2FRpGvViMvymeUbYkGwdbfJcVTveccGa5tfF18bTjSzq3JeyN7xIpmf0HOyAaXiPrCKL2SwFtiowe68pdEFL4zgPrDeFW4qB0HKJBPeIHoHeEdzsafjmGZK/TDVgezAVkWjW29oYyBLk1UsEmDDRJKva48NiY6pJQWIoFttO/ldvaGsqYOK5N+bn3kKhnEmFYO8/8DmDiH6cW2ld/f10GItF/khQ/N/RpDFwBvUrOdUUYwKOTr7593ORhRXjQCDh7rAnk13T+4fDsQsru4oIlTwHvv0JK/I89mGiqH8mTd+nskpg23BG9T2NDLtXXKuthy22edLbw== 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=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W9qn6LRkZ0uO46liU+do1AoSDNiGW5rf4lMm/aQeLJk=; b=osEBxg6m4c+y/R5ttkkAzsFmhYpfzuuQ04UWx0Rnon6qyrWymb18F+H31v6PtyTPl1nySWXQvyVY9OUp2RDxmAR6lmkhvaTQD9PKpzqhpcezA570nVGX0Gu2RIJBT6Fmo+mRIQ1+RxuFmbKLS7sAEGPaLg/9dWyUIN2G/huFvkU= Received: from DB7PR10MB2411.EURPRD10.PROD.OUTLOOK.COM (20.176.238.95) by DB7PR10MB2380.EURPRD10.PROD.OUTLOOK.COM (20.177.121.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.12; Thu, 5 Dec 2019 16:57:26 +0000 Received: from DB7PR10MB2411.EURPRD10.PROD.OUTLOOK.COM ([fe80::e1f3:8a6c:f50f:f207]) by DB7PR10MB2411.EURPRD10.PROD.OUTLOOK.COM ([fe80::e1f3:8a6c:f50f:f207%7]) with mapi id 15.20.2516.014; Thu, 5 Dec 2019 16:57:26 +0000 From: "Brockhaus, Hendrik" To: Justin Cranford , "spasm@ietf.org" Thread-Topic: Feedback on figure 3 in draft-brockhaus-lamps-lightweight-cmp-profile-01 Thread-Index: AdWqNJPpfHT9y+XHSjCsxT/8ALDI9QBSY7zQ Date: Thu, 5 Dec 2019 16:57:26 +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.177] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f0aa4d39-6af4-4f90-dd53-08d779a4351b x-ms-traffictypediagnostic: DB7PR10MB2380: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02426D11FE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(199004)(189003)(305945005)(71200400001)(66574012)(81156014)(30864003)(74316002)(8936002)(33656002)(52536014)(66446008)(110136005)(71190400001)(2906002)(5660300002)(8676002)(64756008)(86362001)(81166006)(26005)(186003)(6506007)(7696005)(9686003)(102836004)(498600001)(45080400002)(11346002)(966005)(66556008)(66946007)(76176011)(25786009)(99286004)(55016002)(14444005)(76116006)(66476007)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR10MB2380; H:DB7PR10MB2411.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: DbnNRAk526Poti/mE+CULdVYHn61+/u6shYwc5ysVvZByxKIy76GpyeoiRkMA/xL63lsULSjfLtNCvuas7p6vF4lsTRTcNhghxPU0Af/VuAPv6Wi0ErR1ZSDzrqIIR4OhrQtohS20ccFoBELwv1S4OzX6RK7DGcF7NcLyWUxXk3dcyAH6PKW2AQt/dA7Py5OmRFtb6NvBrlZ8KfLOmwkdSgSN8FfzI+4KLK/7Id6Pydi3NY2LNkGg/W9CkM6ldZuHpvq0fOKGiJXB4sqdPI44BhH/TI05ww9CeugmVxdMUN8rkUEuqzqGrIkLezcmaI8EXcjIALTBusTqarskaM4w9UD6+WlYualboxkTJJ5xH69ZnNuJFyo9t7QMAGVaNcR6cd8ur01tIQTrtHZZStt+p+rtcMhPtt5+OmH/Yt+Vwzu4wlYS0PnpV4U9iZUugBSj0FmU+v4jUyXzQhm06Isst2brOd07uRa+YpmJHnGe+g= 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: f0aa4d39-6af4-4f90-dd53-08d779a4351b X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2019 16:57:26.7711 (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: bv7cqSrpyK3PZc7MrCSH9HEj1bepNYWb3De8fSjynDZf3MNCpGlwXTyQm0mKQ7OR7afP1x/v2Y0f1arhyRqBnpX3Ah3TPd9aQAMKoVIe2B8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR10MB2380 Archived-At: Subject: Re: [lamps] Feedback on figure 3 in draft-brockhaus-lamps-lightweight-cmp-profile-01 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, 05 Dec 2019 16:57:35 -0000 Justin thank you very much for you feedback and ideas to ease the use of the light= weight CMP profile for constrained entities. Please see my comments inline below. > -----Urspr=FCngliche Nachricht----- > Von: Spasm Im Auftrag von Justin Cranford > Gesendet: Mittwoch, 4. Dezember 2019 00:55 > An: spasm@ietf.org > Betreff: [lamps] Feedback on figure 3 in draft-brockhaus-lamps-lightweigh= t- > cmp-profile-01 >=20 > Hello, >=20 > Figure 3 shows the proposed message format for securely returning a remot= e > generated privateKey to a lightweight CMP client. >=20 > - > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf. > org%2Fhtml%2Fdraft-brockhaus-lamps-lightweight-cmp-profile-01%23page- > 31&data=3D02%7C01%7Chendrik.brockhaus%40siemens.com%7C4c12326f0f > 9e4680fdcf08d7784c8cfc%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1 > %7C637110142482661729&sdata=3DgrVrLN8a43hCZC93QIbKELZFxENB0q1Y > zs2hFhEKMUc%3D&reserved=3D0 >=20 >=20 > Feedback summary: >=20 > 1. CMS SignedData should be the outer layer. > 2. CMS ContentInfo should be used to wrap both of the CMS EnvelopedData a= nd > CMS SignedData layers. > 3. CMS Data may be useful to wrap the privateKey payload. >=20 >=20 >=20 > Feedback details: >=20 > 1. CMS SignedData should be the outer layer. > a) When a lightweight IOT client receives a response, it should do the > lightweight SignedData verification first. [Bro] I see your goal and appreciate it. Actually there is the outer signat= ure provided by the CMP protection. But to explain a bit further, I had two= points in mind while defining the structure like this. i) Currently the structure specified in CMP to carry the private key is Enc= ryptedValue. EncryptedValue is defined in CRMF and is depreciated in favor = of EnvelopedData for a long time already. Therefore I would like to make us= e of the EncryptedKey, as also specified in CRMF, to allow EnvelopedData ne= xt to EncryptedValue. This procedure was also recommended by Jim Schaad whi= le discussion this at IETF104 as this is backward compatible with current s= yntax on the bitstream and requires only a minimal extension to CMP. This c= hange is documented in CMP Updates section 3.4 (https://tools.ietf.org/html= /draft-brockhaus-lamps-cmp-updates-01#section-3.4 ). ii) While specifying the structure I used guidance from "CMS Encrypted Key = Package Content Type" RFC6032 (https://www.rfc-editor.org/rfc/rfc6032.html = ). As the CMP response message is signed, I have a layering like this: CMPP= rotection(EnvelopedData(SignedData(privateKey))) Finally, the inner signedData serves the goal to proof who generated the ke= y-pair and therefore has knowledge of the privateKey next to the end entity= . This can only be achieved by putting the signature into the envelopedData= structure. Therefore I would say, I also follow the procedure of Gutmann with regard t= o the outer signature provided by the CMPProtection and the envelopedData e= ncrypting the privateKey. But I added an inner signature to proof who has k= nowledge of the privateKey. This is required especially in a scenario where= the key-pair was not generated by the PKI management entity the end entity= directly talks to. In such scenarios, where the encrypted privateKey is tr= ansferred over several hops, the inner signature is necessary. May be Peter= Gutmann should consider adding such inner signature to his syntax to also = offer this feature. In case the end entity does not care or has very limite= d resources, it can skip the validation of this inner signature. Did this clarify my design goals and constraints. If you have concrete sugg= estions to improve this with regard to simplification of validation, please= let me know. In case I misunderstood your suggestion, please also come back to me. :-) > b) In other words, if a lightweight client does heavyweight EnvelopedData > decryption first, and SignedData verification fails second, the client ju= st wasted > a lot of processing power, battery life, and time. [Bro] This is right. Therefor the functional extension to deliver centrally= generated keys is optional and not recommended. As motivated in https://to= ols.ietf.org/html/draft-brockhaus-lamps-lightweight-cmp-profile-01#section-= 5.1.6 it is recommended to locally generated the key material if possible.= =20 If the end entity has to request for central key generation it anyhow first= validates the signature of the CMP protection when receiving the response = message and therefore has some evidence that the response message comes fro= m a legitimate PKI management entity. > c) CMS SignedData can be used to provide extra data needed by the client = to > decrypt EnvelopedData. Consider if client and server both use EC key pair= s. > Example: EnvelopedData contains KeyAgreeRecipentInfo using static-static > ECDH algorithm. Client needs the server EC public key to compute > EnvelopedData KEK. Server options for the originator KeyIdentifier in KAR= I > include IssuerAndSerialNumber, SubjectKeyIdentifier, or OriginatorPublicK= ey. If > server chooses IssuerAndSerialNumber, the client must find the server's E= C > public cert. That somewhere can be the SignedData certificates set if-and= -only- > if SignedData is outside EnvelopedData. [Bro] I tried to make use of data already used in the CMPHeader of the resp= onse message, for example to identify the end entities key to be used for t= he keyManagement. recipientEncryptedKey REQUIRED rid REQUIRED rKeyId REQUIRED subjectKeyID REQUIRED -- MUST contain the same value as the senderKID in the respective -- request messages Generally I am not in favor of static-static DH. I prefer static-ephemeral = DH to have more variation in the agreed symmetric keys, in case the same PK= I management entity generates another key pair for the same end entity. You= may argue, that it will not happen that this will be performed using the s= ame key-pairs on both sides, but you never know. Therefore, I mandated to u= se the OriginatorPublicKey field in the section 5.1.6.2 (https://tools.ietf= .org/html/draft-brockhaus-lamps-lightweight-cmp-profile-01#section-5.1.6.2 = ). Doing so I reduce the options in the syntax and offere the server side t= o align with the algorithm the client uses. Therefore I do not have to requ= ire that client and server both have EC key pairs. =20 >=20 > 2. CMS ContentInfo should be used to identify the CMS EnvelopedData and C= MS > SignedData layers. > a) The lightweight client's CMS parser can to do more strict verification= of the > response structure without incurring significant overhead. [Bro] You are right, CMS recommends to use ContentInfo. For the outer Envel= opedData the use of EncryptedKey does not allow wrapping in ContentInfo. In= the EnvelopedData structure I do use the contentType field to specify the = id-signedData type and in SignedData I also used the contentType id-data to= specify the type for the privateKey.=20 See section 5.1.6 (https://tools.ietf.org/html/draft-brockhaus-lamps-lightw= eight-cmp-profile-01#section-5.1.6 ): [...] encryptedContentInfo REQUIRED contentType REQUIRED -- MUST be id-signedData contentEncryptionAlgorithm REQUIRED -- MUST be the algorithm identifier of the symmetric -- content-encryption algorithm used -- As private keys need long-term protection, the use of AES-256 -- or a stronger symmetric algorithm is RECOMMENDED encryptedContent REQUIRED -- MUST be the encrypted signedData structure as specified in -- CMS [RFC5652] section 5 [...] contentType REQUIRED -- MUST be id-data content REQUIRED -- MUST be the privateKey as OCTET STRING [...] Would you still recommend to wrap the SignedData and the privateKey in a Co= nentInfo structure first, before putting it into the surrounding structure? I feel like this would be too much. >=20 > 3. CMS Data can be used to wrap the privateKey. > a) This is optional, but it might be useful to wrap the payloads. > b) If you choose to add a CMS Data layer, also wrap it with CMS ContentIn= fo > like in point #2. [Bro] As described, I do mandate to use the contentType id-data for the pri= vateKey. >=20 >=20 >=20 > References: >=20 > I based my feedback on SCEP pkiMessage format from Gutmann SCEP draft 14. > SCEP is a lightweight enrollment protocol with similar goals to lightweig= ht CMP > profile draft. >=20 > Gutmann SCEP draft 14 does a good job of explaining the structure of its = secure > pkiMessage format with different layers of ContentInfo, SignedData, > EnvelopedData, and Data. >=20 > - > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf. > org%2Fhtml%2Fdraft-gutmann-scep-14%23page- > 13&data=3D02%7C01%7Chendrik.brockhaus%40siemens.com%7C4c12326f0f > 9e4680fdcf08d7784c8cfc%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1 > %7C637110142482661729&sdata=3DG4zoSgXCHDD2zJUDNwo268Gdsp6teT > MPt10647UrXCI%3D&reserved=3D0 (June 9 2019) >=20 > Gutmann inherited this message format from Nourse SCEP draft 23. However, > Gutmann does a much better job showing and explaining the structure, so u= se > the Gutmann reference. >=20 > - > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf. > org%2Fhtml%2Fdraft-nourse-scep-23%23section- > 3&data=3D02%7C01%7Chendrik.brockhaus%40siemens.com%7C4c12326f0f9 > e4680fdcf08d7784c8cfc%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1% > 7C637110142482671723&sdata=3Dh3lJnuPkm8nRdndj0Wb7ptKIAsngK8EG%2 > FrRdBqRuALQ%3D&reserved=3D0 (September 2011) >=20 > Here is a compact summary of the SCEP pkiMessage format. SCEP uses it for > requests and responses. >=20 > - SCEP's pkiMessage =3D > ContentInfo[SignedData[ContentInfo[EnvelopedData[ContentInfo[Data[payload= ] > ]]]]] >=20 >=20 > Summary: >=20 > Ignore SCEP payload formats since they are not applicable. Optionally use= the > same CMS Data layer. Definitely put SignedData first, and consider addin= g > ContentInfo wrappers for all CMS layers. >=20 > Thank you, > Justin Cranford > Prin Software Developer > Entrust Datacard >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf. > org%2Fmailman%2Flistinfo%2Fspasm&data=3D02%7C01%7Chendrik.brockha > us%40siemens.com%7C4c12326f0f9e4680fdcf08d7784c8cfc%7C38ae3bcd9579 > 4fd4addab42e1495d55a%7C1%7C1%7C637110142482671723&sdata=3DLU4 > UFLDKg4Lru40ZcmdYvk%2BCXPkS4UkfoA59cp8aFNg%3D&reserved=3D0 From nobody Fri Dec 6 09:54:52 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 B7AF7120059; Fri, 6 Dec 2019 09:54:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Cc: spasm@ietf.org, lamps-chairs@ietf.org, The IESG Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157565488674.20972.1375233435337911158.idtracker@ietfa.amsl.com> Date: Fri, 06 Dec 2019 09:54:46 -0800 Archived-At: Subject: [lamps] WG Action: Rechartered Limited Additional Mechanisms for PKIX and SMIME (lamps) 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, 06 Dec 2019 17:54:47 -0000 The Limited Additional Mechanisms for PKIX and SMIME (lamps) WG in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Limited Additional Mechanisms for PKIX and SMIME (lamps) ----------------------------------------------------------------------- Current status: Active WG Chairs: Russ Housley Tim Hollebeek Assigned Area Director: Roman Danyliw Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: spasm@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/spasm Archive: https://mailarchive.ietf.org/arch/browse/spasm/ Group page: https://datatracker.ietf.org/group/lamps/ Charter: https://datatracker.ietf.org/doc/charter-ietf-lamps/ 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. 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. 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 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 such machine-to-machine scenarios and communication among PKI management entities. 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. This work will be coordinated with the LWIG WG. 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. Milestones: Nov 2019 - Adopt a draft for short-lived certificate conventions Dec 2019 - Adopt a draft for header protection conventions Dec 2019 - Adopt a draft for CMP updates Dec 2019 - Adopt a draft for Lightweight CMP profile Nov 2020 - Short-lived certificate conventions sent to IESG for BCP publication Nov 2020 - CMP updates sent to IESG for standards track publication Nov 2020 - Lightweight CMP profile sent to IESG for informational publication Mar 2021 - Header protection conventions sent to IESG for standards track publication From nobody Fri Dec 6 10:29: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 27CC41200A3 for ; Fri, 6 Dec 2019 10:29:29 -0800 (PST) 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 Ank7G3cc9Qa0 for ; Fri, 6 Dec 2019 10:29:27 -0800 (PST) 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 BE10F120086 for ; Fri, 6 Dec 2019 10:29:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 18570300AEA for ; Fri, 6 Dec 2019 13:29:25 -0500 (EST) 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 nCVeN0rwhN8t for ; Fri, 6 Dec 2019 13:29:23 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 5C887300AE0 for ; Fri, 6 Dec 2019 13:29:23 -0500 (EST) 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: Fri, 6 Dec 2019 13:29:24 -0500 References: <157565488674.20972.1375233435337911158.idtracker@ietfa.amsl.com> To: LAMPS WG In-Reply-To: <157565488674.20972.1375233435337911158.idtracker@ietfa.amsl.com> Message-Id: <70C9F343-CFCE-44E0-9A6B-723C1CF17D76@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] WG Action: Rechartered Limited Additional Mechanisms for PKIX and SMIME (lamps) 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, 06 Dec 2019 18:29:29 -0000 Good news. Over the next few weeks we will conduct calls for adoption = for the documents that are now in scope. Russ > On Dec 6, 2019, at 12:54 PM, The IESG wrote: >=20 > The Limited Additional Mechanisms for PKIX and SMIME (lamps) WG in the > Security Area of the IETF has been rechartered. For additional = information, > please contact the Area Directors or the WG Chairs. >=20 > Limited Additional Mechanisms for PKIX and SMIME (lamps) > = ----------------------------------------------------------------------- > Current status: Active WG >=20 > Chairs: > Russ Housley > Tim Hollebeek >=20 > Assigned Area Director: > Roman Danyliw >=20 > Security Area Directors: > Benjamin Kaduk > Roman Danyliw >=20 > Mailing list: > Address: spasm@ietf.org > To subscribe: https://www.ietf.org/mailman/listinfo/spasm > Archive: https://mailarchive.ietf.org/arch/browse/spasm/ >=20 > Group page: https://datatracker.ietf.org/group/lamps/ >=20 > Charter: https://datatracker.ietf.org/doc/charter-ietf-lamps/ >=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 such machine-to-machine > scenarios and communication among PKI management entities. 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. This work will be coordinated with > the LWIG WG. >=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 > Milestones: >=20 > Nov 2019 - Adopt a draft for short-lived certificate conventions >=20 > Dec 2019 - Adopt a draft for header protection conventions >=20 > Dec 2019 - Adopt a draft for CMP updates >=20 > Dec 2019 - Adopt a draft for Lightweight CMP profile >=20 > Nov 2020 - Short-lived certificate conventions sent to IESG for BCP > publication >=20 > Nov 2020 - CMP updates sent to IESG for standards track publication >=20 > Nov 2020 - Lightweight CMP profile sent to IESG for informational > publication >=20 > Mar 2021 - Header protection conventions sent to IESG for standards = track > publication >=20 >=20 From nobody Fri Dec 6 10:31:59 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 CE84D120086 for ; Fri, 6 Dec 2019 10:31:56 -0800 (PST) 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 Oos0FD6zIHt1 for ; Fri, 6 Dec 2019 10:31:55 -0800 (PST) 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 448C71200A3 for ; Fri, 6 Dec 2019 10:31:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BA871300AEA for ; Fri, 6 Dec 2019 13:31:53 -0500 (EST) 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 uicu6gJZcqxF for ; Fri, 6 Dec 2019 13:31:53 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id EA8B4300AE0 for ; Fri, 6 Dec 2019 13:31:52 -0500 (EST) 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: Fri, 6 Dec 2019 13:31:53 -0500 References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> To: LAMPS WG In-Reply-To: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> Message-Id: <268790BF-0620-4230-BC81-D857A2061B58@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] Call For Adoption of draft-turner-5480-ku-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: Fri, 06 Dec 2019 18:31:57 -0000 Please indicate whether you support adoption of = draft-turner-5480-ku-clarifications by the LAMPS WG by December 20th. Russ From nobody Fri Dec 6 10:32:47 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 15BA31200FE; Fri, 6 Dec 2019 10:32:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157565716508.20989.12065498794269777487.idtracker@ietfa.amsl.com> Date: Fri, 06 Dec 2019 10:32:45 -0800 Archived-At: Subject: [lamps] The LAMPS WG has placed draft-turner-5480-ku-clarifications in state "Candidate for WG Adoption" 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, 06 Dec 2019 18:32:45 -0000 The LAMPS WG has placed draft-turner-5480-ku-clarifications in state Candidate for WG Adoption (entered by Russ Housley) The document is available at https://datatracker.ietf.org/doc/draft-turner-5480-ku-clarifications/ From nobody Fri Dec 6 11:07: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 9E12112004A for ; Fri, 6 Dec 2019 11:07:18 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=letsencrypt.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 CeEfHselN-sy for ; Fri, 6 Dec 2019 11:07:17 -0800 (PST) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 11670120059 for ; Fri, 6 Dec 2019 11:07:17 -0800 (PST) Received: by mail-wm1-x32e.google.com with SMTP id p9so8913778wmc.2 for ; Fri, 06 Dec 2019 11:07:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=wD1nQUZEcZK0NiQP+vu4/VcxccSHav5bU+efOFioeIA=; b=PyZrVBVt+YWIgY0rfSAgzDMWmLZpRyH7bRrb5LvWdnO/2wG8wbKcUcHqjxs4tmWZt2 JpDeIBlUC13mNJoaSHdU3oRZWanyvbDtlU1/iJzvgafjuZpJVgPmzOrfdXLxFfj+n6t2 hOtktFa+VzST4v5eiF4l4QDwXexrDExdppd1c= 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:reply-to :from:date:message-id:subject:to:cc; bh=wD1nQUZEcZK0NiQP+vu4/VcxccSHav5bU+efOFioeIA=; b=gqzXYXcYe9TcaT8DdIa/k0f/Pv/+tYkhDR8njaK0j3G8YdjF8OUjjgfKLjzy6hW198 3WbYtJDoihoNNPSouxUKTtLQkQ2363YtTDiDfRT6Js9lzcmXkY7NaGKVpAS83mNAkbbP QPdl40J5787La6YoLcucHIldctQ/2k7E6Brq8CdSt6fEpQikzydwCwKhHgtLj409D1N7 waEUDtY/hA4y1KkAVj2npckPZQAh2NHbmoT44XDjX8GIaXHvbvy2f7EXnh0a6JoYWQiU ER/txz3T4IRdT35tb1Sf0fJjr+fE1E1y8csCxslPbsPbIA9VOZHuv2QIGGBryGi+62VU GeXw== X-Gm-Message-State: APjAAAXzgNFGnC4kGZ7nZ9CMHhfvp2GjNmwEc6EGq6v9tY5Tay/XLpfy JQ6rDREpWJU7YWrW5CC9/WuTlbHCMLWlY6R0MTlEacTJCGU= X-Google-Smtp-Source: APXvYqyBH5S6NEkptWW6mAiYRN6pDg18MwLL/ybD6S+l+Vfw0fUlPWb6k9usqQ18Zavb4vPZ4jQ4kwF75GN2uvODiu8= X-Received: by 2002:a7b:c552:: with SMTP id j18mr12189065wmk.123.1575659235566; Fri, 06 Dec 2019 11:07:15 -0800 (PST) MIME-Version: 1.0 References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <268790BF-0620-4230-BC81-D857A2061B58@vigilsec.com> In-Reply-To: <268790BF-0620-4230-BC81-D857A2061B58@vigilsec.com> Reply-To: cpu@letsencrypt.org From: Daniel McCarney Date: Fri, 6 Dec 2019 14:07:04 -0500 Message-ID: To: Russ Housley Cc: LAMPS WG Content-Type: multipart/alternative; boundary="000000000000061f4305990dc1d2" Archived-At: Subject: Re: [lamps] Call For Adoption of draft-turner-5480-ku-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: Fri, 06 Dec 2019 19:07:18 -0000 --000000000000061f4305990dc1d2 Content-Type: text/plain; charset="UTF-8" I support adoption of draft-turner-5480-ku-clarifications by the LAMPS WG. On Fri, Dec 6, 2019 at 1:32 PM Russ Housley wrote: > Please indicate whether you support adoption of > draft-turner-5480-ku-clarifications by the LAMPS WG by December 20th. > > Russ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --000000000000061f4305990dc1d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption of draft-turner-5480-ku-clarifications = by the LAMPS WG.

On Fri, Dec 6, 2019 at 1:32 PM Russ Housley <housley@vigilsec.com> 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">Please indicate whether yo= u support adoption of draft-turner-5480-ku-clarifications by the LAMPS WG b= y December 20th.

Russ

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--000000000000061f4305990dc1d2-- From nobody Fri Dec 6 11:55:17 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 8DFF11200EB for ; Fri, 6 Dec 2019 11:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, 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.073, 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 5bwXn7wXxb6V for ; Fri, 6 Dec 2019 11:55:14 -0800 (PST) Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.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 D6D871200CD for ; Fri, 6 Dec 2019 11:55:13 -0800 (PST) Received: by mail-ed1-f45.google.com with SMTP id v28so6894494edw.12 for ; Fri, 06 Dec 2019 11:55:13 -0800 (PST) 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=HkydAybifYUohZ4wWwNJV6gPnEq48hqdbbTnglDLNHs=; b=AEOL8rRLo+UE3aFcAuTtND49qlrtnMoXHUWCh53Vw0ZpFPdQOn5gytTQ4AuXuxhUE1 cZbmix2GaxHJTPMg4ATUaLNYNt+4JfyppLTbzqLjUhLyOm21tx3unjeamWWFZ/Xlk+Ay MLItApfWm29mAxHR6xVMczAkNYIY0rhFZ4Z7KcXc8Ulkgh6wV1KONmG059NnZXF02xJt +9QkU7AG7CayPW2honi1YnOFJLS3AeVZaa1PBT0xGwmSLp7VYWQDCD+gFN5TIu6IfmS3 zmg6l8t3Ygq/Ol/ZGLTcLaPzKeXKvDPsZFNDRb+1FV60l0NCAGvlA1mYIIma1iWgWzDZ BdpA== X-Gm-Message-State: APjAAAXLD98wyqZY/NDNJl+Rh0KBc/mIC8yubr8cxROuZucUxEHKJP/y SJOk369FWNaH0mOJo/Hrj1KUTrQ1 X-Google-Smtp-Source: APXvYqxA008E4zVgPNPjmPA2fyO/fQPeHdRnWBsSpYlB105z367/LhtIv0Ai0FIefOdnhwCEYe8wxQ== X-Received: by 2002:a17:906:ce4a:: with SMTP id se10mr17027200ejb.157.1575662112025; Fri, 06 Dec 2019 11:55:12 -0800 (PST) Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com. [209.85.221.41]) by smtp.gmail.com with ESMTPSA id t18sm231475ejo.49.2019.12.06.11.55.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Dec 2019 11:55:11 -0800 (PST) Received: by mail-wr1-f41.google.com with SMTP id c14so9063146wrn.7 for ; Fri, 06 Dec 2019 11:55:11 -0800 (PST) X-Received: by 2002:adf:dd46:: with SMTP id u6mr17906896wrm.13.1575662111411; Fri, 06 Dec 2019 11:55:11 -0800 (PST) MIME-Version: 1.0 References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <268790BF-0620-4230-BC81-D857A2061B58@vigilsec.com> In-Reply-To: From: Ryan Sleevi Date: Fri, 6 Dec 2019 14:55:00 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Daniel McCarney Cc: Russ Housley , LAMPS WG Content-Type: multipart/alternative; boundary="0000000000006fd64405990e6cea" Archived-At: Subject: Re: [lamps] Call For Adoption of draft-turner-5480-ku-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: Fri, 06 Dec 2019 19:55:16 -0000 --0000000000006fd64405990e6cea Content-Type: text/plain; charset="UTF-8" +1 On Fri, Dec 6, 2019 at 2:07 PM Daniel McCarney wrote: > I support adoption of draft-turner-5480-ku-clarifications by the LAMPS WG. > > On Fri, Dec 6, 2019 at 1:32 PM Russ Housley wrote: > >> Please indicate whether you support adoption of >> draft-turner-5480-ku-clarifications by the LAMPS WG by December 20th. >> >> Russ >> >> _______________________________________________ >> 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 > --0000000000006fd64405990e6cea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

On Fri, Dec 6, 2019 at 2:07 PM Daniel McCarney <cpu@letsencrypt.org> wrote:
I sup= port adoption of draft-turner-5480-ku-clarifications by the LAMPS WG.
=
On Fri= , Dec 6, 2019 at 1:32 PM Russ Housley <housley@vigilsec.com> wrote:
Please indicate whether you su= pport adoption of draft-turner-5480-ku-clarifications by the LAMPS WG by De= cember 20th.

Russ

_______________________________________________
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
--0000000000006fd64405990e6cea-- From nobody Fri Dec 6 17:03:59 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 DC08B12010C for ; Fri, 6 Dec 2019 17:03:55 -0800 (PST) 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 zTWH3KSZPsPm for ; Fri, 6 Dec 2019 17:03:54 -0800 (PST) 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 8FEDA12003E for ; Fri, 6 Dec 2019 17:03:54 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xB70whmF015650; Sat, 7 Dec 2019 01:03:50 GMT 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=WBGsI0JEeAAyd2frR0o1qDGw4xIeUEyr9hooxLHKlWw=; b=aKcViSjJprPKS3Geecl7e+61NGggL4wDgbB8LwkT5py6WeJCrbPy3SCkB/lK49L9jey9 adp37MkXEanjFTnn2WLir2baGF4GGXeFsBSDls8VRPQ21bwH4U4zwgs4fdAzt+hQWVD5 Dnq9mWDEGA1063aYX8jNyQNGrE01qYHsWxuhX0ICjh+DAf8JMWQYqlJj7efw0ttj5fda hlAFYxnyEBFFM8LnzPz9OHCzU7bnWTCtKkWoOLm7erRLI2b6/GFInCiL5RMVRCDS6eHk UBsUhnu4WKjBr8yio/o/96G43yU05ds8NcL29E9uTUYOQHqrjurUPX99ObGeR793C9EA 6w== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2wr1txr19t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 07 Dec 2019 01:03:50 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xB712VRF023454; Fri, 6 Dec 2019 17:03:49 -0800 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint5.akamai.com with ESMTP id 2wkq9bseqr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 06 Dec 2019 17:03:49 -0800 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Dec 2019 20:03:48 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Fri, 6 Dec 2019 20:03:48 -0500 From: "Salz, Rich" To: Russ Housley , LAMPS WG Thread-Topic: [lamps] Call For Adoption of draft-turner-5480-ku-clarifications Thread-Index: AQHVrGN0PuoM1lX1EUW0UhjvPKjUzKet25SA Date: Sat, 7 Dec 2019 01:03:47 +0000 Message-ID: <90DA71C5-EE12-4D88-8460-AAC0172DD671@akamai.com> References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <268790BF-0620-4230-BC81-D857A2061B58@vigilsec.com> In-Reply-To: <268790BF-0620-4230-BC81-D857A2061B58@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191202 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.112.209] 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-12-06_08:, , 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=759 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912070002 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-06_08:2019-12-05,2019-12-06 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 spamscore=0 clxscore=1015 lowpriorityscore=0 adultscore=0 impostorscore=0 phishscore=0 bulkscore=0 malwarescore=0 suspectscore=0 mlxlogscore=734 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912070002 Archived-At: Subject: Re: [lamps] Call For Adoption of draft-turner-5480-ku-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: Sat, 07 Dec 2019 01:03:56 -0000 PiAgICBQbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3Ugc3VwcG9ydCBhZG9wdGlvbiBvZiBkcmFm dC10dXJuZXItNTQ4MC1rdS1jbGFyaWZpY2F0aW9ucyBieSB0aGUgTEFNUFMgV0cgYnkgRGVjZW1i ZXIgMjB0aC4NCiAgDQpJIHN1cHBvcnQgdGhpcyBhbmQgcHJvbWlzZSB0byByZWFkIGFuZCByZXZp ZXcgaXQuDQoNCg== From nobody Sat Dec 7 12:30: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 61F4F120830 for ; Sat, 7 Dec 2019 12:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 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, HTML_OBFUSCATE_05_10=0.26, 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 (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 6N4Qb5NCmCOk for ; Sat, 7 Dec 2019 12:30:13 -0800 (PST) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 9C4FC12082E for ; Sat, 7 Dec 2019 12:30:13 -0800 (PST) Received: by mail-il1-x129.google.com with SMTP id u16so9288176ilg.10 for ; Sat, 07 Dec 2019 12:30:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=PkvxCJ+7lMDDuM+bUlnd3jtayPZsK9Pc+c0TVKbRies=; b=pmURJhZsbmqFYvHW+0kNt6eQk1PjEackT+n/NC6aM8IiFG8VsNATGx8+eZvYIE8Mtk Lcopj7YRen1gjTrUxa8NUhLeHV79Am9SGeeidyVk+2d3eYE3VLLjNo6luV1MrFZj71wu IOLa83iey22B0FvJhmZQzk4r8DKiEvmlxFjPGHrotnz9+y7iYt7g05TMczJGwSVlCRlX raxm1tAlf+hnadEe1Mj/pq+cPY+IrpREv+sYPnrNcqhKIX4GN9KCqG2bny2z1cJFbusq CRlQ/QA+LtQ2cq7uR43iKJCJXTZfBk1WjpSv13uulzMSaiu4mkp98NfTrfWwDSAyU2pe Ht8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PkvxCJ+7lMDDuM+bUlnd3jtayPZsK9Pc+c0TVKbRies=; b=mcGCtbHsAuKoywPzAb9RG+AdVWd9sosOIlg3We+hx0IjElx/+D4OYBd4Bx9MVxkKZl fOO5NB9KL+F4B/j6CCUyJWjyFvdT1Yp6LTzKDs9so+exSOM+77WCfonw28XxP7cb4KtQ ejjfj2B35FRb/r26/XwTyWlEFQGx+TRzRe42v+y5jAiv0ZBLRYs1eIkOyGLjQ/ljGisw LdqNWBV3A6Yszx2gpOrLsIPkuVhlTw5aOVjVXmJ3L1j9aKmVqm8Q1dQBwrL7xKCAJTkF F1NCDLQwWwQxVchP6ElUA2hK9ZXRlS0dbTbmrgZe1UE9m4V99aU8rtNMpv45bWFhGdrY Ojiw== X-Gm-Message-State: APjAAAWuKg7/Q8vxv+9HNvFXfPM35/OlwpzO8/+V2VCoMnpqPx5nlToy Bz8+trbZa917CbUWDgNLITTPM3dRqmysEGSgvepsOah0 X-Google-Smtp-Source: APXvYqyktSzPVFwLMzoAj1kCc+hA6ZG2RWiAW++fa4i5h0jtJUbZy3Ntqr09oEh64hdIONsRn9nzgZijj7VEkfCBEwc= X-Received: by 2002:a92:d609:: with SMTP id w9mr22250441ilm.46.1575750612742; Sat, 07 Dec 2019 12:30:12 -0800 (PST) MIME-Version: 1.0 From: Mohit Sahni Date: Sat, 7 Dec 2019 12:30:02 -0800 Message-ID: To: spasm@ietf.org Content-Type: multipart/alternative; boundary="00000000000086f664059923071b" Archived-At: Subject: [lamps] RFC6960: Issue with the OCSP Nonce extension 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: Sat, 07 Dec 2019 20:30:15 -0000 --00000000000086f664059923071b Content-Type: text/plain; charset="UTF-8" Hi All, The section 4.1.1 of the RFC6960 describes the format and ID for the Nonce extension in the OCSP request and response. According to the RFC the nonce will have the identifier id-pkix-ocsp-nonce and the type of the Nonce is an OCTATE STRING. The problem I see is that the RFC does not mention whether the nonce should be of fixed length or should have a maximum length. Due to this reason the current implementations that follow this standard can accept very large OCSP requests and are vulnerable to denial of service attacks and various evasion tricks using the nonce field as a tunnel. Since most of the OCSP requests don't use TLS as transport someone in the path can also modify the HTTP request to inject large nonce thus making the situation worse. I would like to propose that the standard MUST define a maximum length for Nonce or the Nonce MUST be of a defined fixed length. I lean towards proposing the standard to have a maximum value of 256 bytes and minimum value of 1 byte to make it backward compatible. Do you guys think it makes sense and if I should propose a draft for making Nonce length with a maximum of 256 and minimum of 1. Here is the text from section 4.1.1 of RFC6960: The nonce cryptographically binds a request and a response to prevent replay attacks. The nonce is included as one of the requestExtensions in requests, while in responses it would be included as one of the responseExtensions. In both the request and the response, the nonce will be identified by the object identifier id-pkix-ocsp-nonce, while the extnValue is the value of the nonce. id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } Nonce ::= OCTET STRING -Mohit --00000000000086f664059923071b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,
The section 4.1.1 of the=C2=A0RFC6960=C2=A0des= cribes the format and ID for the Nonce extension in the OCSP request=C2=A0a= nd response. According to the RFC the nonce will have the identifier id-pki= x-ocsp-nonce and the type of the Nonce is a= n OCTATE STRING.=C2=A0 The problem I see is that the RFC does not mention w= hether the nonce should be of fixed length or should have a maximum length.= Due to this reason the current implementations that follow this standard c= an accept very large OCSP requests and are vulnerable to denial of service = attacks and various evasion tricks using the nonce field as a tunnel. Since= most of the OCSP requests don't use TLS as transport someone in the pa= th can also modify the=C2=A0HTTP request to inject large nonce thus making = the situation worse.=C2=A0

I would like to propose= that the standard MUST define a maximum length for Nonce or the Nonce MUST= be of a defined fixed length. I lean towards proposing the standard to hav= e a maximum value of 256 bytes and minimum value of 1 byte to make it backw= ard compatible.=C2=A0

Do you guys think it makes s= ense=C2=A0and if I should propose a draft for making Nonce length with a ma= ximum of 256 and minimum of 1.=C2=A0

Here is the t= ext from section 4.1.1 of RFC6960:=C2=A0

=C2=A0 = =C2=A0The nonce cryptographically binds a request and a response to prevent=
=C2=A0 =C2=A0replay attacks.=C2=A0 The nonce is included as one of the<= br>=C2=A0 =C2=A0requestExtensions in requests, while in responses it would = be
=C2=A0 =C2=A0included as one of the responseExtensions.=C2=A0 In both= the request and
=C2=A0 =C2=A0the response, the nonce will be identified= by the object identifier
=C2=A0 =C2=A0id-pkix-= ocsp-nonce, while the extnValue is the value of the nonce.

= =C2=A0 =C2=A0 =C2=A0id-pkix-ocsp=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OBJECT IDENTIFIER ::=3D { id-ad-ocsp=C2=A0}
=C2=A0 =C2=A0 =C2=A0id-pkix-ocsp-nonce=C2=A0 =C2=A0 =C2=A0OBJECT IDENTIFIER ::=3D = { id-pkix-ocsp=C2=A02 }

=C2=A0 =C2= =A0 =C2=A0Nonce ::=3D OCTET STRING

-Mohit=C2= =A0
--00000000000086f664059923071b-- From nobody Sat Dec 7 12:47: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 E2516120128 for ; Sat, 7 Dec 2019 12:47:45 -0800 (PST) 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 wCAS4_dNuBHB for ; Sat, 7 Dec 2019 12:47:43 -0800 (PST) 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 6400E12004A for ; Sat, 7 Dec 2019 12:47:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A037D300688 for ; Sat, 7 Dec 2019 15:47:41 -0500 (EST) 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 7ZCw-obud2gW for ; Sat, 7 Dec 2019 15:47:40 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 49AD3300460; Sat, 7 Dec 2019 15:47:40 -0500 (EST) 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: Sat, 7 Dec 2019 15:47:40 -0500 Cc: spasm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mohit Sahni X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] RFC6960: Issue with the OCSP Nonce extension 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: Sat, 07 Dec 2019 20:47:46 -0000 It seems like the easiest fix is to update the ASN.1 to be: Nonce ::=3D OCTET STRING (SIZE(1..256)) Your paragraph seems like the introduction to the update document. Russ > On Dec 7, 2019, at 3:30 PM, Mohit Sahni wrote: >=20 > Hi All, > The section 4.1.1 of the RFC6960 describes the format and ID for the = Nonce extension in the OCSP request and response. According to the RFC = the nonce will have the identifier id-pkix-ocsp-nonce and the type of = the Nonce is an OCTATE STRING. The problem I see is that the RFC does = not mention whether the nonce should be of fixed length or should have a = maximum length. Due to this reason the current implementations that = follow this standard can accept very large OCSP requests and are = vulnerable to denial of service attacks and various evasion tricks using = the nonce field as a tunnel. Since most of the OCSP requests don't use = TLS as transport someone in the path can also modify the HTTP request to = inject large nonce thus making the situation worse.=20 >=20 > I would like to propose that the standard MUST define a maximum length = for Nonce or the Nonce MUST be of a defined fixed length. I lean towards = proposing the standard to have a maximum value of 256 bytes and minimum = value of 1 byte to make it backward compatible.=20 >=20 > Do you guys think it makes sense and if I should propose a draft for = making Nonce length with a maximum of 256 and minimum of 1.=20 >=20 > Here is the text from section 4.1.1 of RFC6960:=20 >=20 > The nonce cryptographically binds a request and a response to = prevent > replay attacks. The nonce is included as one of the > requestExtensions in requests, while in responses it would be > included as one of the responseExtensions. In both the request and > the response, the nonce will be identified by the object identifier > id-pkix-ocsp-nonce, while the extnValue is the value of the nonce. >=20 > id-pkix-ocsp OBJECT IDENTIFIER ::=3D { id-ad-ocsp } > id-pkix-ocsp-nonce OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 2 } >=20 > Nonce ::=3D OCTET STRING >=20 > -Mohit=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Sat Dec 7 13:54:23 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 B3ABF12004A for ; Sat, 7 Dec 2019 13:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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] 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 tCut1bstDGZW for ; Sat, 7 Dec 2019 13:54:20 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 4116F120830 for ; Sat, 7 Dec 2019 13:54:20 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id i11so10868414iol.13 for ; Sat, 07 Dec 2019 13:54:20 -0800 (PST) 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=e8vQBvXA+0bAGC6OdzZhSS2f9p+G6ngsQqDuK4uyk9s=; b=reeGG+QSE3eSNj2FMc6XkHROpvXxJv89+cju5QM4shb1tG4wUYA5psKETBSA5cIfG/ qcrzN9CbznTGzCEovWhLCA6tcdyLcnfqVPAV+YBKoAC6cXJx5zjuF9EZAI9Z9p6zluUk guCGOtpK5+sBorCxlIuJCpDX3COk8yPF8FgHjflw6TIOcZUoLzHjrtirjknIZ2vWxWg3 12mI3GgMFST/U/eFgAs9qQ1S6iUE9wZPczccLh480bPfQgvswKULN5+0cxE3wNLSM8iH o8EcjReL+97LtGQSdzatNcl/9Tf9Ok0dF45lvVJ8vdTFJav/woG5+dYtyBiVXiZXGDVw LLlQ== 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=e8vQBvXA+0bAGC6OdzZhSS2f9p+G6ngsQqDuK4uyk9s=; b=Vvsgbv1kSsSIB8khBS2m2xA6Adqzm+aCX7J3/x/2K6PO9xQto3VDryafYHIYI1j3lu 0ykwsyBwCvAzuLuP5ky2mTp40I4s1xmYnikAfcQKi+R5U4gGltVIKerPSzpHCo52t47V 80X1jTdYGTPUxbw1RngMDKCTRC6TJD0Q5z9CQSQLeKZrLgeMV9ubdqmRkVfs0yj7ovIs FCrus6MRbftu5s6E6G4OwSp6eTyJLu2QSCWmb1ndc1ekKsDnZcZTOu9ubOv0Vme2vEkw KsMMtB7Xm3OAuy6wdTXbYUhBXpH+jw5oreaoSaCeGrDKWfWOt9toOsbmRq4xnIEhwz3i MqDw== X-Gm-Message-State: APjAAAVLmrxYn4zbDCPcO5NvKNtJmruLai1SUj8KaMBZsB06ZZ0q9mpJ yrYllIvekEF/GrbVYs6sKCokniYXVwdAAdT1btSBn7b0 X-Google-Smtp-Source: APXvYqysJtw3whAw1vawTAKFpV+yx6sCQ9VwJsK6t6Kbyl57OGZ9zMUJmXMp81s8S0l399g5u6ccnWnNqdwOJiKBeRM= X-Received: by 2002:a05:6638:93a:: with SMTP id 26mr20605060jak.16.1575755659377; Sat, 07 Dec 2019 13:54:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Mohit Sahni Date: Sat, 7 Dec 2019 13:54:08 -0800 Message-ID: To: Russ Housley Cc: spasm@ietf.org Content-Type: multipart/alternative; boundary="0000000000005480e10599243447" Archived-At: Subject: Re: [lamps] RFC6960: Issue with the OCSP Nonce extension 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: Sat, 07 Dec 2019 21:54:23 -0000 --0000000000005480e10599243447 Content-Type: text/plain; charset="UTF-8" Thanks Russ, I will work on writing a draft. On Sat, Dec 7, 2019 at 12:47 PM Russ Housley wrote: > It seems like the easiest fix is to update the ASN.1 to be: > > Nonce ::= OCTET STRING (SIZE(1..256)) > > Your paragraph seems like the introduction to the update document. > > Russ > > > > On Dec 7, 2019, at 3:30 PM, Mohit Sahni wrote: > > > > Hi All, > > The section 4.1.1 of the RFC6960 describes the format and ID for the > Nonce extension in the OCSP request and response. According to the RFC the > nonce will have the identifier id-pkix-ocsp-nonce and the type of the Nonce > is an OCTATE STRING. The problem I see is that the RFC does not mention > whether the nonce should be of fixed length or should have a maximum > length. Due to this reason the current implementations that follow this > standard can accept very large OCSP requests and are vulnerable to denial > of service attacks and various evasion tricks using the nonce field as a > tunnel. Since most of the OCSP requests don't use TLS as transport someone > in the path can also modify the HTTP request to inject large nonce thus > making the situation worse. > > > > I would like to propose that the standard MUST define a maximum length > for Nonce or the Nonce MUST be of a defined fixed length. I lean towards > proposing the standard to have a maximum value of 256 bytes and minimum > value of 1 byte to make it backward compatible. > > > > Do you guys think it makes sense and if I should propose a draft for > making Nonce length with a maximum of 256 and minimum of 1. > > > > Here is the text from section 4.1.1 of RFC6960: > > > > The nonce cryptographically binds a request and a response to prevent > > replay attacks. The nonce is included as one of the > > requestExtensions in requests, while in responses it would be > > included as one of the responseExtensions. In both the request and > > the response, the nonce will be identified by the object identifier > > id-pkix-ocsp-nonce, while the extnValue is the value of the nonce. > > > > id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } > > id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } > > > > Nonce ::= OCTET STRING > > > > -Mohit > > _______________________________________________ > > Spasm mailing list > > Spasm@ietf.org > > https://www.ietf.org/mailman/listinfo/spasm > > --0000000000005480e10599243447 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Russ, I will work on writing a draft.=C2=A0
On Sat, = Dec 7, 2019 at 12:47 PM Russ Housley <housley@vigilsec.com> wrote:
It seems like the easiest fix is to update the AS= N.1 to be:

=C2=A0 =C2=A0 Nonce ::=3D OCTET STRING (SIZE(1..256))

Your paragraph seems like the introduction to the update document.

Russ


> On Dec 7, 2019, at 3:30 PM, Mohit Sahni <mohit06jan@gmail.com> wrote:
>
> Hi All,
> The section 4.1.1 of the RFC6960 describes the format and ID for the N= once extension in the OCSP request and response. According to the RFC the n= once will have the identifier id-pkix-ocsp-nonce and the type of the Nonce = is an OCTATE STRING.=C2=A0 The problem I see is that the RFC does not menti= on whether the nonce should be of fixed length or should have a maximum len= gth. Due to this reason the current implementations that follow this standa= rd can accept very large OCSP requests and are vulnerable to denial of serv= ice attacks and various evasion tricks using the nonce field as a tunnel. S= ince most of the OCSP requests don't use TLS as transport someone in th= e path can also modify the HTTP request to inject large nonce thus making t= he situation worse.
>
> I would like to propose that the standard MUST define a maximum length= for Nonce or the Nonce MUST be of a defined fixed length. I lean towards p= roposing the standard to have a maximum value of 256 bytes and minimum valu= e of 1 byte to make it backward compatible.
>
> Do you guys think it makes sense and if I should propose a draft for m= aking Nonce length with a maximum of 256 and minimum of 1.
>
> Here is the text from section 4.1.1 of RFC6960:
>
>=C2=A0 =C2=A0 The nonce cryptographically binds a request and a respons= e to prevent
>=C2=A0 =C2=A0 replay attacks.=C2=A0 The nonce is included as one of the=
>=C2=A0 =C2=A0 requestExtensions in requests, while in responses it woul= d be
>=C2=A0 =C2=A0 included as one of the responseExtensions.=C2=A0 In both = the request and
>=C2=A0 =C2=A0 the response, the nonce will be identified by the object = identifier
>=C2=A0 =C2=A0 id-pkix-ocsp-nonce, while the extnValue is the value of t= he nonce.
>
>=C2=A0 =C2=A0 =C2=A0 id-pkix-ocsp=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0OBJECT IDENTIFIER ::=3D { id-ad-ocsp }
>=C2=A0 =C2=A0 =C2=A0 id-pkix-ocsp-nonce=C2=A0 =C2=A0 =C2=A0OBJECT IDENT= IFIER ::=3D { id-pkix-ocsp 2 }
>
>=C2=A0 =C2=A0 =C2=A0 Nonce ::=3D OCTET STRING
>
> -Mohit
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org=
> https://www.ietf.org/mailman/listinfo/spasm

--0000000000005480e10599243447-- From nobody Sun Dec 8 23:56:26 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 10A5312011A for ; Sun, 8 Dec 2019 23:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=primekey.com header.b=D4inZKrU; dkim=pass (1024-bit key) header.d=primekey.com header.b=D4inZKrU 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 AKB068ypNqSR for ; Sun, 8 Dec 2019 23:56:23 -0800 (PST) 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 D0072120118 for ; Sun, 8 Dec 2019 23:56:22 -0800 (PST) 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 833726AA0091 for ; Mon, 9 Dec 2019 08:56:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1575878168; bh=RySikH9tZ+18V47o3qn/eFtM6QLc4sV1eI551Wr7WdY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=D4inZKrUCQnPCjKrmBbHJaqITT+Pe7rt4BXTbKCU5eVDRChScuPNaQ4n10b0hnrw5 HSkhgfUVFJNR9iwWQUZlcJBv4vC3DYIuTKlXxp5sLsqGXMeiu3SQFXwhiW2NjvgyPb Oyn9JAxncp3oh9ub6jJsBuwyIVMox/Hg0TditBuk= Received: from [192.168.3.139] (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 6440A6AA008D for ; Mon, 9 Dec 2019 08:56:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1575878168; bh=RySikH9tZ+18V47o3qn/eFtM6QLc4sV1eI551Wr7WdY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=D4inZKrUCQnPCjKrmBbHJaqITT+Pe7rt4BXTbKCU5eVDRChScuPNaQ4n10b0hnrw5 HSkhgfUVFJNR9iwWQUZlcJBv4vC3DYIuTKlXxp5sLsqGXMeiu3SQFXwhiW2NjvgyPb Oyn9JAxncp3oh9ub6jJsBuwyIVMox/Hg0TditBuk= To: spasm@ietf.org References: 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: Date: Mon, 9 Dec 2019 08:56:24 +0100 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] RFC6960: Issue with the OCSP Nonce extension 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, 09 Dec 2019 07:56:25 -0000 Hi, There was a discussion about this a few years back in Mozilla dev security. https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/x3TOIJL7MGw Back then the motivation was the risk of a chosen-prefix attack. We ended up limiting Nonce to 32 bytes: https://jira.primekey.se/browse/ECA-4906 32 bytes has caused no issues globally during these past three years. Of course, moving the limit to 256 bytes is a no-brainer. Is there some common best practice limit (32 in our case) that could function as a basis for the new max value? Cheers, Tomas On 2019-12-07 22:54, Mohit Sahni wrote: > Thanks Russ, I will work on writing a draft.  > > On Sat, Dec 7, 2019 at 12:47 PM Russ Housley > wrote: > > It seems like the easiest fix is to update the ASN.1 to be: > >     Nonce ::= OCTET STRING (SIZE(1..256)) > > Your paragraph seems like the introduction to the update document. > > Russ > > > > On Dec 7, 2019, at 3:30 PM, Mohit Sahni > wrote: > > > > Hi All, > > The section 4.1.1 of the RFC6960 describes the format and ID for > the Nonce extension in the OCSP request and response. According to > the RFC the nonce will have the identifier id-pkix-ocsp-nonce and > the type of the Nonce is an OCTATE STRING.  The problem I see is > that the RFC does not mention whether the nonce should be of fixed > length or should have a maximum length. Due to this reason the > current implementations that follow this standard can accept very > large OCSP requests and are vulnerable to denial of service attacks > and various evasion tricks using the nonce field as a tunnel. Since > most of the OCSP requests don't use TLS as transport someone in the > path can also modify the HTTP request to inject large nonce thus > making the situation worse. > > > > I would like to propose that the standard MUST define a maximum > length for Nonce or the Nonce MUST be of a defined fixed length. I > lean towards proposing the standard to have a maximum value of 256 > bytes and minimum value of 1 byte to make it backward compatible. > > > > Do you guys think it makes sense and if I should propose a draft > for making Nonce length with a maximum of 256 and minimum of 1. > > > > Here is the text from section 4.1.1 of RFC6960: > > > >    The nonce cryptographically binds a request and a response to > prevent > >    replay attacks.  The nonce is included as one of the > >    requestExtensions in requests, while in responses it would be > >    included as one of the responseExtensions.  In both the request and > >    the response, the nonce will be identified by the object identifier > >    id-pkix-ocsp-nonce, while the extnValue is the value of the nonce. > > > >      id-pkix-ocsp           OBJECT IDENTIFIER ::= { id-ad-ocsp } > >      id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } > > > >      Nonce ::= OCTET STRING > > > > -Mohit > > _______________________________________________ > > 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 Mon Dec 9 05:15: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 AEA2A1201EA for ; Mon, 9 Dec 2019 05:15:40 -0800 (PST) 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 Mo3-_PJxLgG7 for ; Mon, 9 Dec 2019 05:15:39 -0800 (PST) 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 DF0001200C4 for ; Mon, 9 Dec 2019 05:15:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 59DC5300B23 for ; Mon, 9 Dec 2019 08:15:37 -0500 (EST) 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 Yxo-IMBaj2T7 for ; Mon, 9 Dec 2019 08:15:35 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 7B855300ABE; Mon, 9 Dec 2019 08:15:35 -0500 (EST) 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: Mon, 9 Dec 2019 08:15:36 -0500 Cc: spasm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tomas Gustavsson X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] RFC6960: Issue with the OCSP Nonce extension 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, 09 Dec 2019 13:15:41 -0000 I do not know of any situation where 32 bytes is not enough for a nonce. Russ > On Dec 9, 2019, at 2:56 AM, Tomas Gustavsson = wrote: >=20 > Hi, >=20 > There was a discussion about this a few years back in Mozilla dev = security. > = https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/x3TOIJ= L7MGw > Back then the motivation was the risk of a chosen-prefix attack. >=20 > We ended up limiting Nonce to 32 bytes: > https://jira.primekey.se/browse/ECA-4906 >=20 > 32 bytes has caused no issues globally during these past three years. = Of > course, moving the limit to 256 bytes is a no-brainer. >=20 > Is there some common best practice limit (32 in our case) that could > function as a basis for the new max value? >=20 > Cheers, > Tomas >=20 > On 2019-12-07 22:54, Mohit Sahni wrote: >> Thanks Russ, I will work on writing a draft.=20 >>=20 >> On Sat, Dec 7, 2019 at 12:47 PM Russ Housley > > wrote: >>=20 >> It seems like the easiest fix is to update the ASN.1 to be: >>=20 >> Nonce ::=3D OCTET STRING (SIZE(1..256)) >>=20 >> Your paragraph seems like the introduction to the update document. >>=20 >> Russ >>=20 >>=20 >>> On Dec 7, 2019, at 3:30 PM, Mohit Sahni > > wrote: >>>=20 >>> Hi All, >>> The section 4.1.1 of the RFC6960 describes the format and ID for >> the Nonce extension in the OCSP request and response. According to >> the RFC the nonce will have the identifier id-pkix-ocsp-nonce and >> the type of the Nonce is an OCTATE STRING. The problem I see is >> that the RFC does not mention whether the nonce should be of fixed >> length or should have a maximum length. Due to this reason the >> current implementations that follow this standard can accept very >> large OCSP requests and are vulnerable to denial of service = attacks >> and various evasion tricks using the nonce field as a tunnel. = Since >> most of the OCSP requests don't use TLS as transport someone in = the >> path can also modify the HTTP request to inject large nonce thus >> making the situation worse. >>>=20 >>> I would like to propose that the standard MUST define a maximum >> length for Nonce or the Nonce MUST be of a defined fixed length. I >> lean towards proposing the standard to have a maximum value of 256 >> bytes and minimum value of 1 byte to make it backward compatible. >>>=20 >>> Do you guys think it makes sense and if I should propose a draft >> for making Nonce length with a maximum of 256 and minimum of 1. >>>=20 >>> Here is the text from section 4.1.1 of RFC6960: >>>=20 >>> The nonce cryptographically binds a request and a response to >> prevent >>> replay attacks. The nonce is included as one of the >>> requestExtensions in requests, while in responses it would be >>> included as one of the responseExtensions. In both the request = and >>> the response, the nonce will be identified by the object = identifier >>> id-pkix-ocsp-nonce, while the extnValue is the value of the = nonce. >>>=20 >>> id-pkix-ocsp OBJECT IDENTIFIER ::=3D { id-ad-ocsp } >>> id-pkix-ocsp-nonce OBJECT IDENTIFIER ::=3D { id-pkix-ocsp = 2 } >>>=20 >>> Nonce ::=3D OCTET STRING >>>=20 >>> -Mohit >>> _______________________________________________ >>> Spasm mailing list >>> Spasm@ietf.org >>> https://www.ietf.org/mailman/listinfo/spasm >>=20 >>=20 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >>=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Wed Dec 11 13:10: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 91A56120132 for ; Wed, 11 Dec 2019 13:10:48 -0800 (PST) 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 Pep-ms2k74XB for ; Wed, 11 Dec 2019 13:10:47 -0800 (PST) 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 700E912004C for ; Wed, 11 Dec 2019 13:10:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C55B8300B23 for ; Wed, 11 Dec 2019 16:10:45 -0500 (EST) 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 qmFRd63vzmOi for ; Wed, 11 Dec 2019 16:10:44 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id DFE7F300B0C for ; Wed, 11 Dec 2019 16:10:44 -0500 (EST) 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: Wed, 11 Dec 2019 16:10:45 -0500 References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> To: LAMPS WG In-Reply-To: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] Call For Adoption of draft-richardson-lamps-rfc7030est-clarify 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, 11 Dec 2019 21:10:48 -0000 Please indicate whether you support adoption of = draft-turner-5480-ku-clarifications by the LAMPS WG by December 27th. Russ From nobody Wed Dec 11 14:35: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 E1B0E1200B1; Wed, 11 Dec 2019 14:35:18 -0800 (PST) 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_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 kD4_YWd3wG4i; Wed, 11 Dec 2019 14:35:17 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77EDB120005; Wed, 11 Dec 2019 14:35:17 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A300AF40719; Wed, 11 Dec 2019 14:35:06 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, spasm@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20191211223506.A300AF40719@rfc-editor.org> Date: Wed, 11 Dec 2019 14:35:06 -0800 (PST) Archived-At: Subject: [lamps] =?utf-8?q?RFC_8692_on_Internet_X=2E509_Public_Key_Infras?= =?utf-8?q?tructure=3A_Additional_Algorithm_Identifiers_for_RSASSA-PSS_and?= =?utf-8?q?_ECDSA_Using_SHAKEs?= 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, 11 Dec 2019 22:35:19 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8692 Title: Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs Author: P. Kampanakis, Q. Dang Status: Standards Track Stream: IETF Date: December 2019 Mailbox: pkampana@cisco.com, quynh.dang@nist.gov Pages: 14 Updates: RFC 3279 I-D Tag: draft-ietf-lamps-pkix-shake-15.txt URL: https://www.rfc-editor.org/info/rfc8692 DOI: 10.17487/RFC8692 Digital signatures are used to sign messages, X.509 certificates, and Certificate Revocation Lists (CRLs). This document updates the "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" (RFC 3279) and describes the conventions for using the SHAKE function family in Internet X.509 certificates and revocation lists as one-way hash functions with the RSA Probabilistic signature and Elliptic Curve Digital Signature Algorithm (ECDSA) signature algorithms. The conventions for the associated subject public keys are also described. This document is a product of the Limited Additional Mechanisms for PKIX and SMIME Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Dec 12 08:53: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 84C631209D4 for ; Thu, 12 Dec 2019 08:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=0.001] autolearn=unavailable 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 8bKxv1kdxyhk for ; Thu, 12 Dec 2019 08:52:58 -0800 (PST) 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 5882A1209D2 for ; Thu, 12 Dec 2019 08:52:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CB5C7300B2F for ; Thu, 12 Dec 2019 11:52:56 -0500 (EST) 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 7KklAGSGvPJ3 for ; Thu, 12 Dec 2019 11:52:55 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 0B2CB300472; Thu, 12 Dec 2019 11:52:54 -0500 (EST) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_C3E85441-A476-4BC7-A34C-E47AA0E8AF0B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <15EDAA9F-C715-4FB3-955E-ADB2647C914B@vigilsec.com> Date: Thu, 12 Dec 2019 11:52:55 -0500 To: LAMPS WG , cose X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] NIST posts a draft on stateful hash-based signatures 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, 12 Dec 2019 16:53:00 -0000 --Apple-Mail=_C3E85441-A476-4BC7-A34C-E47AA0E8AF0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii https://csrc.nist.gov/publications/detail/sp/800-208/draft = The draft includes HSS/LMS and XMSS, both have RFCs out of the CFRG. Russ --Apple-Mail=_C3E85441-A476-4BC7-A34C-E47AA0E8AF0B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
https://csrc.nist.gov/publications/detail/sp/800-208/draft<= br class=3D"">

The draft = includes HSS/LMS and XMSS, both have RFCs out of the CFRG.

Russ

= --Apple-Mail=_C3E85441-A476-4BC7-A34C-E47AA0E8AF0B-- From nobody Sun Dec 15 10:18:32 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 25B5B1200F6 for ; Wed, 11 Dec 2019 18:43:35 -0800 (PST) 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_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 aNt4kJxDmVOQ for ; Wed, 11 Dec 2019 18:43:33 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF4A41200C5 for ; Wed, 11 Dec 2019 18:43:33 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9DA55F4071A; Wed, 11 Dec 2019 18:43:22 -0800 (PST) To: phill@hallambaker.com, rob@sectigo.com, jsha@letsencrypt.org, rdd@cert.org, kaduk@mit.edu, housley@vigilsec.com, tim.hollebeek@digicert.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: y-iida@secom.co.jp, spasm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20191212024322.9DA55F4071A@rfc-editor.org> Date: Wed, 11 Dec 2019 18:43:22 -0800 (PST) Archived-At: X-Mailman-Approved-At: Sun, 15 Dec 2019 10:18:31 -0800 Subject: [lamps] [Editorial Errata Reported] RFC8659 (5934) 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, 12 Dec 2019 02:43:35 -0000 The following errata report has been submitted for RFC8659, "DNS Certification Authority Authorization (CAA) Resource Record". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5934 -------------------------------------- Type: Editorial Reported by: IIDA Yosiaki Section: 7 Original Text ------------- It also allows hyphens in Property Tags. Corrected Text -------------- It also allows hyphens in tags of Property Value of issue and issuewild Property Tags. Notes ----- Subsection 4.1 explicitly prohibits hyphens in Property Tags. While obsoleted RFC 6844 did not allow hyphens in tags of Property Value of issue and issuewild Property Tags, new ABNF definition in subsection 4.2 allows them. 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 can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8659 (draft-ietf-lamps-rfc6844bis-07) -------------------------------------- Title : DNS Certification Authority Authorization (CAA) Resource Record Publication Date : November 2019 Author(s) : P. Hallam-Baker, R. Stradling, J. Hoffman-Andrews Category : PROPOSED STANDARD Source : Limited Additional Mechanisms for PKIX and SMIME Area : Security Stream : IETF Verifying Party : IESG From nobody Sun Dec 15 10:18: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 66DD9120099; Sat, 14 Dec 2019 19:00:33 -0800 (PST) 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 VMyqf9BAllix; Sat, 14 Dec 2019 19:00:31 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 CE0D012004C; Sat, 14 Dec 2019 19:00:30 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBF304C0015062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 14 Dec 2019 22:00:06 -0500 Date: Sat, 14 Dec 2019 19:00:03 -0800 From: Benjamin Kaduk To: pkix@ietf.org, spasm@ietf.org Cc: david.cooper@nist.gov, stefans@microsoft.com, stephen.farrell@cs.tcd.ie, sharon.boeyen@entrust.com, housley@vigilsec.com, wpolk@nist.gov, rdd@cert.org, kent@bbn.com, stefan@aaa-sec.com, chenyt@sjtu.edu.cn, RFC Errata System Message-ID: <20191215030003.GP81833@kduck.mit.edu> References: <20191215023419.6B0ACF406CD@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191215023419.6B0ACF406CD@rfc-editor.org> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: X-Mailman-Approved-At: Sun, 15 Dec 2019 10:18:30 -0800 Subject: Re: [lamps] [Technical Errata Reported] RFC5280 (5938) 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: Sun, 15 Dec 2019 03:00:34 -0000 I think this looks pretty straightforward (though I'd tweak the "corrected text" to do the right thing with the automated tooling and possibly the "notes" as well before verifying). Any thoughts for or against "verified"/"editorial"? Thanks, Ben On Sat, Dec 14, 2019 at 06:34:19PM -0800, RFC Errata System wrote: > The following errata report has been submitted for RFC5280, > "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5938 > > -------------------------------------- > Type: Technical > Reported by: Yuting Chen > > Section: 6.1 > > Original Text > ------------- > The primary goal of path validation is to verify the binding between > a subject distinguished name or a subject alternative name and > subject public key, as represented in the target certificate, based > on the public key of the trust anchor. In most cases, the target > > Corrected Text > -------------- > The primary goal of path validation is to verify the binding between > | a subject distinguished name and/or a subject alternative name and > subject public key, as represented in the target certificate, based > on the public key of the trust anchor. In most cases, the target > > Notes > ----- > The correction conforms to the first paragraph, Sec. 6, "Certification > path processing verifies the binding between the subject distinguished > name and/or subject alternative name and subject public key." > > In addition, it is not very clear in RFC 5280, given a certificate with > a non-empty subject DN and an SAN extension instance (critical or > non-critical), which one (the subject DN, the SAN extension, or they > both) should be bound to the subject public key during path validation. > More explanations are needed. > > 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 > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5280 (draft-ietf-pkix-rfc3280bis-11) > -------------------------------------- > Title : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile > Publication Date : May 2008 > Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk > Category : PROPOSED STANDARD > Source : Public-Key Infrastructure (X.509) > Area : Security > Stream : IETF > Verifying Party : IESG From nobody Sun Dec 15 10:18: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 D899C12004A for ; Sun, 15 Dec 2019 08:23:36 -0800 (PST) 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 ugY3s2bvid9L for ; Sun, 15 Dec 2019 08:23:34 -0800 (PST) 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 23BF212001A for ; Sun, 15 Dec 2019 08:23:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 59CA3300B2E for ; Sun, 15 Dec 2019 11:23:32 -0500 (EST) 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 TmV7PhcpYt5D for ; Sun, 15 Dec 2019 11:23:27 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 0C25D300460; Sun, 15 Dec 2019 11:23:27 -0500 (EST) 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: <20191215030003.GP81833@kduck.mit.edu> Date: Sun, 15 Dec 2019 11:23:26 -0500 Cc: IETF PKIX , LAMPS WG , David Cooper , Stephen Farrell , wpolk@nist.gov, "Roman D. Danyliw" , Stefan Santesson , chenyt@sjtu.edu.cn, RFC Editor Content-Transfer-Encoding: quoted-printable Message-Id: References: <20191215023419.6B0ACF406CD@rfc-editor.org> <20191215030003.GP81833@kduck.mit.edu> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: X-Mailman-Approved-At: Sun, 15 Dec 2019 10:18:30 -0800 Subject: Re: [lamps] [Technical Errata Reported] RFC5280 (5938) 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: Sun, 15 Dec 2019 16:23:37 -0000 I think the original text is fine. It is not an exclusive or. Russ > On Dec 14, 2019, at 10:00 PM, Benjamin Kaduk wrote: >=20 > I think this looks pretty straightforward (though I'd tweak the = "corrected > text" to do the right thing with the automated tooling and possibly = the > "notes" as well before verifying). Any thoughts for or against > "verified"/"editorial"? >=20 > Thanks, >=20 > Ben >=20 > On Sat, Dec 14, 2019 at 06:34:19PM -0800, RFC Errata System wrote: >> The following errata report has been submitted for RFC5280, >> "Internet X.509 Public Key Infrastructure Certificate and Certificate = Revocation List (CRL) Profile". >>=20 >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid5938 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Yuting Chen >>=20 >> Section: 6.1 >>=20 >> Original Text >> ------------- >> The primary goal of path validation is to verify the binding between >> a subject distinguished name or a subject alternative name and >> subject public key, as represented in the target certificate, based >> on the public key of the trust anchor. In most cases, the target >>=20 >> Corrected Text >> -------------- >> The primary goal of path validation is to verify the binding between >> | a subject distinguished name and/or a subject alternative name and >> subject public key, as represented in the target certificate, based >> on the public key of the trust anchor. In most cases, the target >>=20 >> Notes >> ----- >> The correction conforms to the first paragraph, Sec. 6, = "Certification=20 >> path processing verifies the binding between the subject = distinguished >> name and/or subject alternative name and subject public key."=20 >>=20 >> In addition, it is not very clear in RFC 5280, given a certificate = with >> a non-empty subject DN and an SAN extension instance (critical or=20 >> non-critical), which one (the subject DN, the SAN extension, or they=20= >> both) should be bound to the subject public key during path = validation. >> More explanations are needed. >>=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 >> -------------------------------------- >> RFC5280 (draft-ietf-pkix-rfc3280bis-11) >> -------------------------------------- >> Title : Internet X.509 Public Key Infrastructure = Certificate and Certificate Revocation List (CRL) Profile >> Publication Date : May 2008 >> Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, = R. Housley, W. Polk >> Category : PROPOSED STANDARD >> Source : Public-Key Infrastructure (X.509) >> Area : Security >> Stream : IETF >> Verifying Party : IESG From nobody Sun Dec 15 10:18: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 CB76D12004D for ; Sun, 15 Dec 2019 08:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.438 X-Spam-Level: * X-Spam-Status: No, score=1.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_NONE=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 RHR08sYxU8R7 for ; Sun, 15 Dec 2019 08:38:19 -0800 (PST) Received: from smtp2.outgoing.loopia.se (smtp2.outgoing.loopia.se [93.188.3.37]) (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 46B8212003F for ; Sun, 15 Dec 2019 08:38:18 -0800 (PST) Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id BEE9D2E46860 for ; Sun, 15 Dec 2019 17:38:14 +0100 (CET) Received: from s498.loopia.se (unknown [172.22.191.5]) by s807.loopia.se (Postfix) with ESMTP id 9944C2E27DC0; Sun, 15 Dec 2019 17:38:14 +0100 (CET) Received: from s474.loopia.se (unknown [172.22.191.5]) by s498.loopia.se (Postfix) with ESMTP id 8E8E9470800; Sun, 15 Dec 2019 17:38:14 +0100 (CET) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s499.loopia.se ([172.22.191.6]) by s474.loopia.se (s474.loopia.se [172.22.190.14]) (amavisd-new, port 10024) with LMTP id fISH_teyK8vf; Sun, 15 Dec 2019 17:38:14 +0100 (CET) X-Loopia-Auth: user X-Loopia-User: mailstore2@aaa-sec.com X-Loopia-Originating-IP: 195.67.91.185 Received: from [10.30.3.163] (195-67-91-185.customer.telia.com [195.67.91.185]) (Authenticated sender: mailstore2@aaa-sec.com) by s499.loopia.se (Postfix) with ESMTPSA id B324F1CDAE4E; Sun, 15 Dec 2019 17:38:13 +0100 (CET) User-Agent: Microsoft-MacOutlook/10.20.0.191208 Date: Sun, 15 Dec 2019 17:38:12 +0100 From: Stefan Santesson To: Russ Housley , Ben Kaduk CC: IETF PKIX , LAMPS WG , David Cooper , Stephen Farrell , , "Roman D. Danyliw" , , RFC Editor Message-ID: <1E29AA8C-1153-40B6-BEB9-5E6F4F6E6E97@aaa-sec.com> Thread-Topic: [Technical Errata Reported] RFC5280 (5938) References: <20191215023419.6B0ACF406CD@rfc-editor.org> <20191215030003.GP81833@kduck.mit.edu> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Sun, 15 Dec 2019 10:18:30 -0800 Subject: Re: [lamps] [Technical Errata Reported] RFC5280 (5938) 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: Sun, 15 Dec 2019 16:38:22 -0000 I agree. I don't think this type of nit picking belongs in an errata. The concept of biding a key to information in a certificate is well underst= ood. Stefan Santesson=20 =EF=BB=BFOn 2019-12-15, 17:23, "Russ Housley" wrote: I think the original text is fine. It is not an exclusive or. =20 Russ =20 > On Dec 14, 2019, at 10:00 PM, Benjamin Kaduk wrote: >=20 > I think this looks pretty straightforward (though I'd tweak the "corr= ected > text" to do the right thing with the automated tooling and possibly t= he > "notes" as well before verifying). Any thoughts for or against > "verified"/"editorial"? >=20 > Thanks, >=20 > Ben >=20 > On Sat, Dec 14, 2019 at 06:34:19PM -0800, RFC Errata System wrote: >> The following errata report has been submitted for RFC5280, >> "Internet X.509 Public Key Infrastructure Certificate and Certificat= e Revocation List (CRL) Profile". >>=20 >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid5938 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Yuting Chen >>=20 >> Section: 6.1 >>=20 >> Original Text >> ------------- >> The primary goal of path validation is to verify the binding between >> a subject distinguished name or a subject alternative name and >> subject public key, as represented in the target certificate, based >> on the public key of the trust anchor. In most cases, the target >>=20 >> Corrected Text >> -------------- >> The primary goal of path validation is to verify the binding betwee= n >> | a subject distinguished name and/or a subject alternative name and >> subject public key, as represented in the target certificate, based >> on the public key of the trust anchor. In most cases, the target >>=20 >> Notes >> ----- >> The correction conforms to the first paragraph, Sec. 6, "Certificati= on=20 >> path processing verifies the binding between the subject distinguish= ed >> name and/or subject alternative name and subject public key."=20 >>=20 >> In addition, it is not very clear in RFC 5280, given a certificate w= ith >> a non-empty subject DN and an SAN extension instance (critical or=20 >> non-critical), which one (the subject DN, the SAN extension, or the= y=20 >> both) should be bound to the subject public key during path validati= on. >> More explanations are needed. >>=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 >> -------------------------------------- >> RFC5280 (draft-ietf-pkix-rfc3280bis-11) >> -------------------------------------- >> Title : Internet X.509 Public Key Infrastructure Certi= ficate and Certificate Revocation List (CRL) Profile >> Publication Date : May 2008 >> Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen= , R. Housley, W. Polk >> Category : PROPOSED STANDARD >> Source : Public-Key Infrastructure (X.509) >> Area : Security >> Stream : IETF >> Verifying Party : IESG =20 =20 From nobody Sun Dec 15 13:01: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 3D32212003F; Sun, 15 Dec 2019 13:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.497 X-Spam-Level: X-Spam-Status: No, score=-14.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=SoQM8+E7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Jox66GGf 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 j58cJV0Mb638; Sun, 15 Dec 2019 13:01:33 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65F51120013; Sun, 15 Dec 2019 13:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25823; q=dns/txt; s=iport; t=1576443693; x=1577653293; h=from:to:subject:date:message-id:mime-version; bh=iWFc3oFtBY4eHWhCiqJqpJQb7HKWE2pInRxAKYE60UA=; b=SoQM8+E74s3tcIwOivY7dOo3v1RbVIYXhGOhi560N7oZLFzHjoAlI/7H LGlUB4ffUKejtrUajZD/TIZBJ8b57wNSAzoQchA0wx1TTqdPAYtCz/Gpu ITNzW+FbdpmNoUW1vYGGQt+ytclCpDmjs+znc4/ozI8AUNiLhApQgLiS5 E=; IronPort-PHdr: =?us-ascii?q?9a23=3Aceu77RCn3LMVrucYho4aUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qg83kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuK/DwbiE+NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B5AABKnvZd/5tdJa1cBwIbAQEBAQE?= =?us-ascii?q?BAQUBAQERAQEDAwEBAYFsBAEBAQsBgRsvJCwFbFggBAsqCodAA4sNTpoXgS6?= =?us-ascii?q?BJANUCQEBAQwBASMKAgEBhEACgg8kNgcOAgMNAQEEAQEBAgEFBG2FNwyFdxs?= =?us-ascii?q?TAQE4EQE2AghAJgEEARoagwGBeU0DLgECDKFdAoE4iGGCJ4J+AQEFgTkCAgx?= =?us-ascii?q?BgwcYghcDBoE2AYwXGoFBP4ERR4VuAQECAQGBNRQYKxsHBYJugiyNPzOIFpg?= =?us-ascii?q?EcgqCNIcpjneaSIIMhAyINIhPkXoCBAIEBQIOAQEFgVkELiqBLnAVgydQERS?= =?us-ascii?q?NEgwXg1CFFIU/dAGBJ4xcDRUCB4EEAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.69,319,1571702400"; d="scan'208,217";a="454144045" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Dec 2019 21:01:29 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id xBFKr4kP005273 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 15 Dec 2019 20:53:05 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 15 Dec 2019 14:53:03 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 15 Dec 2019 14:53:02 -0600 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 15 Dec 2019 15:53:02 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JSAj9xroy35D/1+a62Uzq3fZe66VQxyDlvTxFUgJ9ywtf/g20TROWmLRIH7QLSYDdjkUUwQMhAWNmcL67oPyt67P8q8QyMujjm8ERTmMtTuETCfWdLxyeaf8r9AvXI/A+BMZpUZwrCuu4GGPP2sIia5m5Vlg1icq6KAJoGPwT4RR0BBiTk24i//47JoehZthicgC7du9Ulu15i9rnU1fll+tLJW+OoLfE+Dw/2oDV1nT5R+dfIiTkM7A6VN47bkUtstQTXIGEX30wLNixeyU1mpbsIRFtwkuNeOPmqb/J7InKdjkQ6uIEfC+ug/Nfx8mgeri5FlZWITTLTymsvhQOw== 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=AEwQL2UQUgH1dXPKKV400I5DJ70/UZb2SehZakZ+iCM=; b=dPvKaMzMJF8Vd6wZ8XNH2po/pe65X8YO0qNFSM8H+5nB+A7sv5onJJkXMvTDuOL/yZL3/vJLYoK//5vwnfWVNySGtoq+uDozbg4r1dShLnyqM5CohAwpdVYdu2K3UB2LY98prHsYHtU7mh2GZ0xld0LZmEGVpTG/lg3je6gxab1JhPJkHszPeXYWlNgIrZXec3fKsVRlGDrTjzRu5Bv0q6rY7BIohqbpOO7DFPmhosMOOXkgHq+MEtseeCkWXnp6YhBs+sY6sivNNLcM8NUkJalrRHf9vwit9Y/3GAUV8jZ7sSNcY3Czme3QhRGjUqj8h55QNBynoaRX0gsxFnzGAw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AEwQL2UQUgH1dXPKKV400I5DJ70/UZb2SehZakZ+iCM=; b=Jox66GGfg4dmICqmeXLPBRugnOlMF63omE/nBaSTS02rJWO79hHtI6cxenReEt5HsOrtfMqh2WoPgaS+iGDLpiZAZJUJMq72cRWO7MQ3gRb4kicsYeGeB7o6jzEzvk50DzLEk+is0zbSl3Sn59NrzVcqUoExDbZEuhvOWPIrAIU= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB3823.namprd11.prod.outlook.com (20.178.254.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.14; Sun, 15 Dec 2019 20:53:01 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::a0c1:4add:251d:c9a4]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::a0c1:4add:251d:c9a4%7]) with mapi id 15.20.2538.019; Sun, 15 Dec 2019 20:53:01 +0000 From: "Owen Friel (ofriel)" To: "spasm@ietf.org" , EMU WG Thread-Topic: EAP/EMU recommendations for client cert validation logic Thread-Index: AdWxNKzqTmo8NKHtQwSIp+NEgFXHNA== Date: Sun, 15 Dec 2019 20:53:01 +0000 Message-ID: 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=ofriel@cisco.com; x-originating-ip: [75.104.70.26] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7acbaf8b-a843-4dbe-ca3a-08d781a0c64c x-ms-traffictypediagnostic: MN2PR11MB3823: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02524402D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(366004)(396003)(346002)(136003)(189003)(199004)(478600001)(9326002)(81156014)(86362001)(81166006)(316002)(966005)(8676002)(33656002)(64756008)(66446008)(66946007)(110136005)(9686003)(66556008)(2906002)(71200400001)(66476007)(6506007)(8936002)(450100002)(26005)(7696005)(5660300002)(76116006)(186003)(55016002)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3823; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Q2OcPralsCKvYXSAeLit6f61Hi8gJpRpwn1fE46/TQkqTtliHBIrCyn0qH3w4HtO5aQIpXaOiJwEZXTTBqUmIS2kqIkaKHx/9wOgrkXiwQI+Ly/Pqe41BndepfM41z79VtJoVZlUmKO2xON8Tgi55Y/GgB547NAuFSJyjQX8ZgHOBonCTKBQOlH4wvFeEisrEGAU5ybAmdG2gMMr8/e8HM0dEDgEuidydQPw/nhGqGLzbCTwavv1s1VyoQouUPiJYVQ5fTPe727tRi/exi25B0upzK94qeyc2oDr4vQOiJ5LQx7jN9Sytanl+ChiEizjjeNIfdQT0DQdrzgTA0rmDVBIBqCuA5LUuFPEeG1z12keqrNcLV1yZb38H1xdAsp59pXeMIUth8bXHmwKDv5hFr5F2MfOZBtutEjLq6mTd+NuoD2Vmgg6PWKzoDtdGvRrqm3jZXl1ZblnNlo7/e1G+O4oYKumrkROHr9npICkE7g= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3901F9B86DAC83AF67FBA49DDB560MN2PR11MB3901namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7acbaf8b-a843-4dbe-ca3a-08d781a0c64c X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2019 20:53:01.7296 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: oLm0lke4CtZKtU18dbwTkxpNhSLKx9VA2sEF2k11jxgp/iAaLmv4vd+MzAEcoNyQUB2k8SRV+N/6Va5gRN7qlw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3823 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: [lamps] EAP/EMU recommendations for client cert validation logic 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: Sun, 15 Dec 2019 21:01:36 -0000 --_000_MN2PR11MB3901F9B86DAC83AF67FBA49DDB560MN2PR11MB3901namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, At ACME meeting at IETF106, the last discussion of the week was around EMU = looking for recommendations for EAP client/peer/supplicant cert verificatio= n logic when the client is verifying the cert that the EAP server presents.= Minutes here: https://datatracker.ietf.org/doc/minutes-106-acme/ The reco= mmendation was to ask lamps. This was also discussed on EMU mailer recently= . Quoting some additional background that Alan gave on EMU mailer: "Background: a) the current practice in TLS-based EAP methods is to use certificates wit= h "id-kp-serverAuth" OID set for Extended Key Usage. b) many supplicants check for this OID, and refuse to perform authenticatio= n if it is missing c) supplicants do not check DNS names or any other field in the certificate= s d) as a result of this lack of verification, supplicants ship with all know= n CAs disabled for TLS-based EAP methods" The key consideration is that RFCs that recommend cert fields for EAP serve= rs that clients should check for are not currently issued by public CAs, an= d in some instances (e.g. SSID) ownership can often not be proven by CAs. For example: https://tools.ietf.org/html/rfc4334#section-2 id-kp-eapOverLAN EKU https://tools.ietf.org/html/rfc4334#section-3 id-pe-wlanSSID https://tools.ietf.org/html/rfc7585#section-2.2 NAIRealm If an EAP server operator wants to use a public CA identity cert on their E= AP server, what recommendations should we give to EAP clients so that the s= upplicant code can handle public or private CA issued EAP server identity i= n a secure a fashion as possible? If at some point in the future, public CAs are willing to issue certs with = some or all of the above fields, then what is the migration plan, what do w= e tell EAP clients to do now, and how to they migrate their verification lo= gic? The ideal experience would be along these lines for a client with real user= interactions: - client connects to an EAP server - client prompts user for userId + realm and password - client verifies server cert has id-kp-eapOverLAN set - NAIRealm in cert matches user's realm - verify the cert signing chain The reality today is that if the server cert is issued by a public CA, then= all that client can really check is: - id-kp-serverAuth is set - dNSName in cert matches user's realm - verify the cert signing chain We would like to document some recommendations for EAP clients and EAP oper= ators so that public CAs could be used, and recommend checks for public vs.= private CA issued EAP server certs. It seems like logic should be something like: - recommend EAP operators with private CA issued certs on their EAP servers= set id-kp-eapOverLAN and NAIRealm set - recommend EAP operators using public CAs get EAP server certs with id-kp-= serverAuth and dNSName set - recommend clients enable trust in public CAs - recommend clients implement different cert verification logic depending o= n whether the EAP server cert is issued by a public CA or private CA - for public CA certs, client checks that id-kp-serverAuth is set *and* dNS= Name matches user realm. If either check fails, reject. - for private CA certs, client checks that id-kp-serverAuth or id-kp-eapOve= rLAN is set *and* NAIRealm matches user realm. If either check fails, rejec= t. - as a longer term goal see if public CAs will issue id-kp-eapOverLAN and N= AIRealm. Although of course if some were to start doing this, then there is= a migration challenge, and clients cannot make a hard check for these valu= es against all public CAs. This doesn't really seem practical in the near t= erm at all. Note that for an IoT device, there is some work to do to define how to e.g.= extend the RFC8366 so that it can specify the dNSName that devices should = check for when verifying EAP identity where they EAP server uses a public C= A. Some related options are outlined in https://tools.ietf.org/html/draft-f= riel-anima-brski-cloud-01. Comments/thoughts? Regards, Owen --_000_MN2PR11MB3901F9B86DAC83AF67FBA49DDB560MN2PR11MB3901namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

At ACME meeting at IETF106, the last discussion of t= he week was around EMU looking for recommendations for EAP client/peer/supp= licant cert verification logic when the client is verifying the cert that t= he EAP server presents. Minutes here: https://data= tracker.ietf.org/doc/minutes-106-acme/  The recommendation was to = ask lamps. This was also discussed on EMU mailer recently.

 

Quoting some additional background that Alan gave on= EMU mailer:

 

“Background:

 

a) the current practice in TLS-based EAP methods = is to use certificates with "id-kp-serverAuth" OID set for Extend= ed Key Usage.

b) many supplicants check for this OID, and refus= e to perform authentication if it is missing

c) supplicants do not check DNS names or any othe= r field in the certificates

d) as a result of this lack of verification, supp= licants ship with all known CAs disabled for TLS-based EAP methods”

 

The key consideration is that RFCs that recommend ce= rt fields for EAP servers that clients should check for are not currently i= ssued by public CAs, and in some instances (e.g. SSID) ownership can often = not be proven by CAs.

 

For example:

 

https://tools.ietf.org/html/rfc4334#section-2 id-kp-eapOverLAN EK= U

 

https://tools.ietf.org/html/rfc4334#section-3 id-pe-wlanSSID=

 

https://tools.ietf.org/html/rfc7585#section-2.2 NAIRealm

 

If an EAP server operator wants to use a public CA i= dentity cert on their EAP server, what recommendations should we give to EA= P clients so that the supplicant code can handle public or private CA issue= d EAP server identity in a secure a fashion as possible?

 

If at some point in the future, public CAs are willi= ng to issue certs with some or all of the above fields, then what is the mi= gration plan, what do we tell EAP clients to do now, and how to they migrat= e their verification logic?

 

The ideal experience would be along these lines for = a client with real user interactions:

- client connects to an EAP server

- client prompts user for userId + realm and pas= sword

- client verifies server cert has id-kp-eapOverLAN s= et

- NAIRealm in cert matches user’s realm

- verify the cert signing chain

 

The reality today is that if the server cert is issu= ed by a public CA, then all that client can really check is:

- id-kp-serverAuth is set

- dNSName in cert matches user’s realm

- verify the cert signing chain

 

We would like to document some recommendations for E= AP clients and EAP operators so that public CAs could be used, and recommen= d checks for public vs. private CA issued EAP server certs.

 

It seems like logic should be something like:

 

- recommend EAP operators with private CA issued cer= ts on their EAP servers set id-kp-eapOverLAN and NAIRealm set

- recommend EAP operators using public CAs get EAP s= erver certs with id-kp-serverAuth and dNSName set

- recommend clients enable trust in public CAs<= /o:p>

- recommend clients implement different cert verific= ation logic depending on whether the EAP server cert is issued by a public = CA or private CA

- for public CA certs, client checks that id-kp-serv= erAuth is set *and* dNSName matches user realm. If either check fail= s, reject.

- for private CA certs, client checks that id-kp-ser= verAuth or id-kp-eapOverLAN is set *and* NAIRealm matches user realm= . If either check fails, reject.

 

- as a longer term goal see if public CAs will issue= id-kp-eapOverLAN and NAIRealm. Although of course if some were to start do= ing this, then there is a migration challenge, and clients cannot make a ha= rd check for these values against all public CAs. This doesn’t really seem practical in the near term = at all.

 

Note that for an IoT device, there is some work to d= o to define how to e.g. extend the RFC8366 so that it can specify the dNSNa= me that devices should check for when verifying EAP identity where they EAP= server uses a public CA. Some related options are outlined in https://tools.ietf.org/html/draft-friel-anima-brski-cloud-01.

 

Comments/thoughts?

 

Regards,

Owen

 

 

 

 

 

 

 

 

--_000_MN2PR11MB3901F9B86DAC83AF67FBA49DDB560MN2PR11MB3901namp_-- From nobody Sun Dec 15 15:43: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 17F5A12000F; Sun, 15 Dec 2019 15:43:44 -0800 (PST) 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 S2tHr1vgy_jp; Sun, 15 Dec 2019 15:43:42 -0800 (PST) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) (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 A29D7120013; Sun, 15 Dec 2019 15:43:41 -0800 (PST) Received: by mail-ed1-f46.google.com with SMTP id cy15so3571349edb.4; Sun, 15 Dec 2019 15:43:41 -0800 (PST) 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=y2sKwyZa3HBjLiB+zhzrBiGGdAWFJPDdS0Tap0M1XA8=; b=PTB+EgGVTwLe3pDKoIZY/8KBxa3udcEp7LDamjGk/14WGRiZ7HcFLVrRuMaG+D2s+I L6BQL1sJlVwC//wXAFiLMn0km2pCTU4hsNHga5qyJi+jUZnY9loBT7yUotWjW58P1bhM vKS+DxIGmdyR2IcOfzuoyTzbXeh8pTsW92BldTKvxqcK2ODlQm3PSnCzUgh+vvnGAbLX YS7bkVMaSyW8yFY+e1hrSnayqaPNxzvkNdhEYgDJ4lCeu26sR8Ha3m2X83D0L0KmX8X8 xxkTpnhO8yPG6In4PG2kjTB1Mj3okcrh2y7xSmRCiuPJomA7sYogBxbg0V4htsTqYE8i poAg== X-Gm-Message-State: APjAAAUc+LOsgdK/yV4JVMm/ke0vQ1o2Ib7BsTnZv+1yT3DYGGAFHX9B e/A5dFQK8Ne0/YlEDB/7QCa5EEVS X-Google-Smtp-Source: APXvYqxhqMckAVNAVJ8Tlbh96tooK+luSeoGYTIBZdizgQFUic/GeiROex7NP/HDhjEWJY8fM12b1g== X-Received: by 2002:a17:906:681:: with SMTP id u1mr29617292ejb.81.1576453419435; Sun, 15 Dec 2019 15:43:39 -0800 (PST) Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com. [209.85.221.48]) by smtp.gmail.com with ESMTPSA id ck19sm1046082ejb.48.2019.12.15.15.43.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Dec 2019 15:43:39 -0800 (PST) Received: by mail-wr1-f48.google.com with SMTP id q10so5077146wrm.11; Sun, 15 Dec 2019 15:43:39 -0800 (PST) X-Received: by 2002:adf:ebc1:: with SMTP id v1mr25609591wrn.351.1576453418798; Sun, 15 Dec 2019 15:43:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ryan Sleevi Date: Sun, 15 Dec 2019 18:43:24 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Owen Friel (ofriel)" Cc: EMU WG , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="00000000000008542e0599c6aaf1" Archived-At: Subject: Re: [lamps] EAP/EMU recommendations for client cert validation logic 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: Sun, 15 Dec 2019 23:43:44 -0000 --00000000000008542e0599c6aaf1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Dec 15, 2019 at 4:01 PM Owen Friel (ofriel) wrote: > Hi, > > > > At ACME meeting at IETF106, the last discussion of the week was around EM= U > looking for recommendations for EAP client/peer/supplicant cert > verification logic when the client is verifying the cert that the EAP > server presents. Minutes here: > https://datatracker.ietf.org/doc/minutes-106-acme/ The recommendation > was to ask lamps. This was also discussed on EMU mailer recently. > > > > Quoting some additional background that Alan gave on EMU mailer: > > > > =E2=80=9CBackground: > > > > a) the current practice in TLS-based EAP methods is to use certificates > with "id-kp-serverAuth" OID set for Extended Key Usage. > > b) many supplicants check for this OID, and refuse to perform > authentication if it is missing > > c) supplicants do not check DNS names or any other field in the > certificates > > d) as a result of this lack of verification, supplicants ship with all > known CAs disabled for TLS-based EAP methods=E2=80=9D > > > > The key consideration is that RFCs that recommend cert fields for EAP > servers that clients should check for are not currently issued by public > CAs, and in some instances (e.g. SSID) ownership can often not be proven = by > CAs. > > > > For example: > > > > https://tools.ietf.org/html/rfc4334#section-2 id-kp-eapOverLAN EKU > > > > https://tools.ietf.org/html/rfc4334#section-3 id-pe-wlanSSID > > > > https://tools.ietf.org/html/rfc7585#section-2.2 NAIRealm > > > > If an EAP server operator wants to use a public CA identity cert on their > EAP server, what recommendations should we give to EAP clients so that th= e > supplicant code can handle public or private CA issued EAP server identit= y > in a secure a fashion as possible? > Define =E2=80=9Cpublic CA=E2=80=9D first, and it=E2=80=99ll be clearer that= the question is really supplicant-specific. That is, most definitions for =E2=80=9Cpublic CAs=E2=80=9D come down to =E2= =80=9CI don=E2=80=99t want to think about / analyze the security or validation practices of the CA, I want my supplicant / software / hardware vendor to do it for me, against some criteria the vendor is responsible for, and hope it all works out=E2= =80=9D. To the extent TLS uses =E2=80=98public CAs=E2=80=99, it either boils down to t= he OS or browser vendors reaching rough (independent) consensus on who is worth trusting, or the vendor going along with everyone else=E2=80=99s decisions for cost (too expensive for the vendor to evaluate) or compatibility (everyone else trusts them and it=E2=80=99d break things if the vendor doesn=E2=80=99t) re= asons. Is the supplicant market likely to reach that consensus? It seems unlikely, unless and until you define the =E2=80=9Cthing everyone can and wants and n= eeds to validate=E2=80=9D, and that thing is either globally unique (like DNS) or sufficiently domain specific (e.g. Passpoint) that vendors can agree. If at some point in the future, public CAs are willing to issue certs with > some or all of the above fields, then what is the migration plan, what do > we tell EAP clients to do now, and how to they migrate their verification > logic? > This statement similarly requires untangling. There are =E2=80=9Cpublic CAs= =E2=80=9D as =E2=80=9CThe set of keys/certificates used for authenticating particular se= rvices=E2=80=9D and =E2=80=9Cpublic CAs=E2=80=9D as the set of organizations that own/opera= te those keys. The case of the former is extremely unlikely, as the industry is actively moving away from that approach to PKI, by trying to ensure separate keys for separate use cases or authentication realms, of which EAP would surely be. The case of the latter is already available from said organizations as part of =E2=80=9Cmanaged CA=E2=80=9D or =E2=80=9Cprivate CA=E2=80=9D offeri= ngs, which are operated by that public CA organization, but that=E2=80=99s effectively greenfield because y= ou aren=E2=80=99t having to interoperate with any extant keys or certificate p= rofiles. The ideal experience would be along these lines for a client with real user > interactions: > > - client connects to an EAP server > > - client prompts user for userId + realm and password > > - client verifies server cert has id-kp-eapOverLAN set > What assurance is this to provide? - NAIRealm in cert matches user=E2=80=99s realm > This only works iff the NAIs are globally unique (e.g. map to DNS), which imposes requirements on NAIs that aren=E2=80=99t present in RFC 7542, and s= eemingly intentionally, compared to 4282. - verify the cert signing chain > > > > The reality today is that if the server cert is issued by a public CA, > then all that client can really check is: > > - id-kp-serverAuth is set > > - dNSName in cert matches user=E2=80=99s realm > > - verify the cert signing chain > > > > We would like to document some recommendations for EAP clients and EAP > operators so that public CAs could be used, and recommend checks for publ= ic > vs. private CA issued EAP server certs. > If you mean the same set of CAs and keys used for TLS by common operating systems and browsers, it bears highlighting again: industry is moving away from that. Which is to say that contracts and requirements for PKIs used =E2=80=9Cby default=E2=80=9D by browsers and operating systems are being ex= plicit about the need to segment purpose and use case and not use such certificates for such purposes. Already, TLS and e-mail, the two dominant uses of PKI in such systems, are required to be distinguished at their intermediate level. Browsers are looking to explicitly only trust the TLS-Web side of the PKI, and making sure that the TLS-Web PKI side is highly agile. Other cases, such as restricted use server to server PKI or industry bespoke cases (such as financial services or system networking) are being restricted to PKIs that aren=E2=80=99t federated-by-default. For example, X9 recently revived their PKI WG, to define PKI requirements appropriate for financial services customers (like ATM to bank), because financial services struggle to move at the same speed as modern software, for understandable reasons. The use of domain/purpose-specific PKIs is something we can and should be embracing more of. It seems like logic should be something like: > > > > - recommend EAP operators with private CA issued certs on their EAP > servers set id-kp-eapOverLAN and NAIRealm set > > - recommend EAP operators using public CAs get EAP server certs with > id-kp-serverAuth and dNSName set > - recommend clients enable trust in public CAs > This is why I started with trying to define what =E2=80=9Cpublic CAs=E2=80= =9D are. If you mean the extant CAs trusted by browsers and operating systems, both this recommendation and the one proceeding it may not be good recommendations or long-term viable practices. That=E2=80=99s not to say you couldn=E2=80=99t, but it means your EAP servi= ces and servers need to be prepared to be as agile as the Web ecosystem is and modern operating systems are converging on. The ability to support or be beholden to =E2=80=9Clegacy=E2=80=9D - whether algorithms, profiles, or trust in par= ticular organizations - is something that industry is recognizing does not align with user needs. This means adopting practices like automation, being able to quantify compatibility risks, and being able to move quickly as expectations change, in response to ecosystem challenges. Maybe that=E2=80=99s fine for EAP, but I=E2=80=99m willing to suspect that = it because updates may involve physically replacing client hardware or physically installing firmware, you really don=E2=80=99t want EAP needing to be behold= en to those agility needs of the Web and OSes. And, again, that=E2=80=99s perfect= ly OK, it just means defining a PKI and set of procedures that is appropriate for that use case, and convincing industry to adopt it as an =E2=80=9Cout of th= e box=E2=80=9D configuration. Or, alternatively, embracing private PKI. - recommend clients implement different cert verification logic depending > on whether the EAP server cert is issued by a public CA or private CA > Why is this good? To the extent browsers or OSes make this distinction, it=E2=80=99s largely = based on simply phasing rollouts of new requirements, with the goal to eventually require consistent and uniform treatment to ensure simpler code with consistent and uniform security properties. Having a long-term segmentation of requirements, or even encouraging them without a clear vision back to harmonization, is definitely an anti-pattern here. - for public CA certs, client checks that id-kp-serverAuth is set **and** > dNSName matches user realm. If either check fails, reject. > > - for private CA certs, client checks that id-kp-serverAuth or > id-kp-eapOverLAN is set **and** NAIRealm matches user realm.. If either > check fails, reject. > > > > - as a longer term goal see if public CAs will issue id-kp-eapOverLAN and > NAIRealm. Although of course if some were to start doing this, then there > is a migration challenge, and clients cannot make a hard check for these > values against all public CAs. This doesn=E2=80=99t really seem practical= in the > near term at all. > The effect of the separate EKU, which is actually quite desirable, is that it functionally makes it difficult for CAs to issue these certificates from intermediated that lack this EKU or any EKU. Further, CAs subject to browser/OS vendor oversight are consistently required to segment out their EKUs at the intermediate level, and required to always specify EKUs. The end result is that, to achieve this long term goal, you=E2=80=99ve effe= ctively required the establishment of a new PKI - just at the intermediate level rather than the root. And as many of the public CAs can tell you, having recently encountered challenges regarding non-TLS intermediates from roots that are subject to browser/OS oversight, it=E2=80=99s often easier to use = separate roots as well. Again, I think that=E2=80=99s desirable, to define an entirely new PKI with= zero overlap with the server auth/TLS PKI used by OSes/browsers, but that does change your recommendations and design a bit :) The short term recommendation becomes =E2=80=9Cdon=E2=80=99t use public CAs=E2=80=9D, and = that seems easier to explain and easier to evolve the technical requirements, until the time that such a new, EAP-specific public PKI can be introduced. In my mind, this is no different from organizations that want TLS certificates for their servers named =E2=80=9Cwebmail=E2=80=9D (not globall= y unique) or =E2=80=9Cmail_01.company.example=E2=80=9D (not preferred name form / LDH). = The answer is =E2=80=9Cuse private CAs, don=E2=80=99t use public CAs=E2=80=9D > > Note that for an IoT device, there is some work to do to define how to > e.g. extend the RFC8366 so that it can specify the dNSName that devices > should check for when verifying EAP identity where they EAP server uses a > public CA. Some related options are outlined in > https://tools.ietf.org/html/draft-friel-anima-brski-cloud-01. > > > > Comments/thoughts? > > > > Regards, > > Owen > > > > > > > > > > > > > > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --00000000000008542e0599c6aaf1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Dec 15, 2019 at 4:01 PM Owen Friel (ofriel) <ofriel@cisco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rg= b(204,204,204)">

Hi,

=C2=A0

At ACME meeting at IETF106, the last discussion of t= he week was around EMU looking for recommendations for EAP client/peer/supp= licant cert verification logic when the client is verifying the cert that t= he EAP server presents. Minutes here: https://datatracker.ietf.org/doc/minutes-106-acme/=C2=A0 The reco= mmendation was to ask lamps. This was also discussed on EMU mailer recently= .

=C2=A0

Quoting some additional background that Alan gave on= EMU mailer:

=C2=A0

=E2=80=9CBackground:

=C2=A0

a) the current practice in TLS-based EAP methods is to use certificates = with "id-kp-serverAuth" OID set for Extended Key Usage.=

b) many supplicants check for this OID, and refuse to perform authentica= tion if it is missing

c) supplicants do not check DNS names or any other field in the certific= ates

d) as a result of this lack of verification, supplicants ship with all k= nown CAs disabled for TLS-based EAP methods=E2=80=9D

=C2=A0

The key consideration is that RFCs that recommend ce= rt fields for EAP servers that clients should check for are not currently i= ssued by public CAs, and in some instances (e.g. SSID) ownership can often = not be proven by CAs.

=C2=A0

For example:

=C2=A0

https://tools.ietf.org/html/rfc4334#section-2 i= d-kp-eapOverLAN EKU

=C2=A0

https://tools.ietf.org/html/rfc4334#section-3 i= d-pe-wlanSSID

=C2=A0

https://tools.ietf.org/html/rfc7585#section-2.2 NAIRealm

=C2=A0

If an EAP server operator wants to use a public CA i= dentity cert on their EAP server, what recommendations should we give to EA= P clients so that the supplicant code can handle public or private CA issue= d EAP server identity in a secure a fashion as possible?



This statement similarly requires untangling. Th= ere are =E2=80=9Cpublic CAs=E2=80=9D as =E2=80=9CThe set of keys/certificat= es used for authenticating particular services=E2=80=9D and =E2=80=9Cpublic= CAs=E2=80=9D as the set of organizations that own/operate those keys.

The case of the former is ex= tremely unlikely, as the industry is actively moving away from that approac= h to PKI, by trying to ensure separate keys for separate use cases or authe= ntication realms, of which EAP would surely be. The case of the latter is a= lready available from said organizations as part of =E2=80=9Cmanaged CA=E2= =80=9D or =E2=80=9Cprivate CA=E2=80=9D offerings, which are operated by tha= t public CA organization, but that=E2=80=99s effectively greenfield because= you aren=E2=80=99t having to interoperate with any extant keys or certific= ate profiles.

The ideal experience would be along these lines for = a client with real user interactions:

- client connects to an EAP server

- client prompts user for userId + realm and passwor= d

- client verifies server cert has id-kp-eapOverLAN s= et


What assurance is this to provide?

- NAIRealm in cert matches user=E2=80=99s realm

<= /div>

This = only works iff the NAIs are globally unique (e.g. map to DNS), which impose= s requirements on NAIs that aren=E2=80=99t present in RFC 7542, and seeming= ly intentionally, compared to 4282.

- verify the cert signing chain

=C2=A0

The reality today is that if the server cert is issu= ed by a public CA, then all that client can really check is:<= /p>

- id-kp-serverAuth is set

- dNSName in cert matches user=E2=80=99s realm

- verify the cert signing chain

=C2=A0

We would like to document some recommendations for E= AP clients and EAP operators so that public CAs could be used, and recommen= d checks for public vs. private CA issued EAP server certs.

=

If you mean the = same set of CAs and keys used for TLS by common operating systems and brows= ers, it bears highlighting again: industry is moving away from that. Which = is to say that contracts and requirements for PKIs used =E2=80=9Cby default= =E2=80=9D by browsers and operating systems are being explicit about the ne= ed to segment purpose and use case and not use such certificates for such p= urposes.

Already, TLS an= d e-mail, the two dominant uses of PKI in such systems, are required to be = distinguished at their intermediate level. Browsers are looking to explicit= ly only trust the TLS-Web side of the PKI, and making sure that the TLS-Web= PKI side is highly agile. Other cases, such as restricted use server to se= rver PKI or industry bespoke cases (such as financial services or system ne= tworking) are being restricted to PKIs that aren=E2=80=99t federated-by-def= ault.

For example, X9 re= cently revived their PKI WG, to define PKI requirements appropriate for fin= ancial services customers (like ATM to bank), because financial services st= ruggle to move at the same speed as modern software, for understandable rea= sons. The use of domain/purpose-specific PKIs is something we can and shoul= d be embracing more of.

=

It seems like logic should be something like:=

=C2=A0

- recommend EAP operators with private CA issued cer= ts on their EAP servers set id-kp-eapOverLAN and NAIRealm set=

- recommend EAP operators using public CAs get EAP s= erver certs with id-kp-serverAuth and dNSName set

=

- recommend clients enable trust in public CAs<= /p>


<= span style=3D"border-color:rgb(0,0,0)">This is why I started with trying to= define what =E2=80=9Cpublic CAs=E2=80=9D are. If you mean the extant CAs t= rusted by browsers and operating systems, both this recommendation and the = one proceeding it may not be good recommendations or long-term viable pract= ices.

That=E2=80=99s not to say you couldn=E2=80=99t, but it means your EAP = services and servers need to be prepared to be as agile as the Web ecosyste= m is and modern operating systems are converging on. The ability to support= or be beholden to =E2=80=9Clegacy=E2=80=9D - whether algorithms, profiles,= or trust in particular organizations - is something that industry is recog= nizing does not align with user needs. This means adopting practices like a= utomation, being able to quantify compatibility risks, and being able to mo= ve quickly as expectations change, in response to ecosystem challenges.

Maybe th= at=E2=80=99s fine for EAP, but I=E2=80=99m willing to suspect that it becau= se updates may involve physically replacing client hardware or physically i= nstalling firmware, you really don=E2=80=99t want EAP needing to be beholde= n to those agility needs of the Web and OSes. And, again, that=E2=80=99s pe= rfectly OK, it just means defining a PKI and set of procedures that is appr= opriate for that use case, and convincing industry to adopt it as an =E2=80= =9Cout of the box=E2=80=9D configuration. Or, alternatively, embracing priv= ate PKI.

<= u>

- recommend clients implement different cert verific= ation logic depending on whether the EAP server cert is issued by a public = CA or private CA


Why is this good?

To the extent browsers or OSes make this distinction, it=E2=80=99= s largely based on simply phasing rollouts of new requirements, with the go= al to eventually require consistent and uniform treatment to ensure simpler= code with consistent and uniform security properties. Having a long-term s= egmentation of requirements, or even encouraging them without a clear visio= n back to harmonization, is definitely an anti-pattern here.

- for public CA certs, client checks that id-kp-serv= erAuth is set *and* dNSName matches user realm. If either check fail= s, reject.

- for private CA certs, client checks that id-kp-ser= verAuth or id-kp-eapOverLAN is set *and* NAIRealm matches user realm= .. If either check fails, reject.

=C2=A0

- as a longer term goal see if public CAs will issue= id-kp-eapOverLAN and NAIRealm. Although of course if some were to start do= ing this, then there is a migration challenge, and clients cannot make a ha= rd check for these values against all public CAs. This doesn=E2=80=99t really seem practical in the near ter= m at all.


The effect of the separate EKU, which is actually quite desirable= , is that it functionally makes it difficult for CAs to issue these certifi= cates from intermediated that lack this EKU or any EKU. Further, =C2=A0CAs = subject to browser/OS vendor oversight are consistently required to segment= out their EKUs at the intermediate level, and required to always specify E= KUs.

The end result is t= hat, to achieve this long term goal, you=E2=80=99ve effectively required th= e establishment of a new PKI - just at the intermediate level rather than t= he root. And as many of the public CAs can tell you, having recently encoun= tered challenges regarding non-TLS intermediates from roots that are subjec= t to browser/OS oversight, it=E2=80=99s often easier to use separate roots = as well.

Again, I think = that=E2=80=99s desirable, to define an entirely new PKI with zero overlap w= ith the server auth/TLS PKI used by OSes/browsers, but that does change you= r recommendations and design a bit :) The short term recommendation becomes= =E2=80=9Cdon=E2=80=99t use public CAs=E2=80=9D, and that seems easier to e= xplain and easier to evolve the technical requirements, until the time that= such a new, EAP-specific public PKI can be introduced.

In my mind, this is no different from organ= izations that want TLS certificates for their servers named =E2=80=9Cwebmai= l=E2=80=9D (not globally unique) or =E2=80=9Cmail_01.company.example=E2=80= =9D (not preferred name form / LDH). The answer is =E2=80=9Cuse private CAs= , don=E2=80=99t use public CAs=E2=80=9D

 _______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--00000000000008542e0599c6aaf1-- From nobody Sun Dec 15 16:51: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 B51A912008F; Sun, 15 Dec 2019 16:50:59 -0800 (PST) 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, 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 fDZPOrMQgrmB; Sun, 15 Dec 2019 16:50:57 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 568AA120059; Sun, 15 Dec 2019 16:50:57 -0800 (PST) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id BFBB863D; Mon, 16 Dec 2019 00:50:53 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Alan DeKok In-Reply-To: Date: Sun, 15 Dec 2019 19:50:52 -0500 Cc: "Owen Friel (ofriel)" , "spasm@ietf.org" , EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ryan Sleevi X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic 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, 16 Dec 2019 00:51:00 -0000 On Dec 15, 2019, at 6:43 PM, Ryan Sleevi wrote: > That is, most definitions for =E2=80=9Cpublic CAs=E2=80=9D come down = to =E2=80=9CI don=E2=80=99t want to think about / analyze the security = or validation practices of the CA, I want my supplicant / software / = hardware vendor to do it for me, against some criteria the vendor is = responsible for, and hope it all works out=E2=80=9D. To the extent TLS = uses =E2=80=98public CAs=E2=80=99, it either boils down to the OS or = browser vendors reaching rough (independent) consensus on who is worth = trusting, or the vendor going along with everyone else=E2=80=99s = decisions for cost (too expensive for the vendor to evaluate) or = compatibility (everyone else trusts them and it=E2=80=99d break things = if the vendor doesn=E2=80=99t) reasons. It's also a way to move trust out of the individual machine, and into = the network. Given the complexity of supplicant configuration, I think = that's a good thing. > Is the supplicant market likely to reach that consensus? It seems = unlikely, unless and until you define the =E2=80=9Cthing everyone can = and wants and needs to validate=E2=80=9D, and that thing is either = globally unique (like DNS) or sufficiently domain specific (e.g. = Passpoint) that vendors can agree. >=20 > > If at some point in the future, public CAs are willing to issue = certs with some or all of the above fields, then what is the migration = plan, what do we tell EAP clients to do now, and how to they migrate = their verification logic? My goal is to answer that question. Which involves some discussion = and analysis. > This statement similarly requires untangling. There are =E2=80=9Cpublic = CAs=E2=80=9D as =E2=80=9CThe set of keys/certificates used for = authenticating particular services=E2=80=9D and =E2=80=9Cpublic CAs=E2=80=9D= as the set of organizations that own/operate those keys. >=20 > The case of the former is extremely unlikely, as the industry is = actively moving away from that approach to PKI, by trying to ensure = separate keys for separate use cases or authentication realms, of which = EAP would surely be.=20 Yes. > > - client verifies server cert has id-kp-eapOverLAN set >=20 > What assurance is this to provide? The use-case for the certificate matches the intended use-case. Right now, I can use the same server certificate for HTTPS, EAP, or = any other TLS-based protocol. That seems wrong. > - NAIRealm in cert matches user=E2=80=99s realm >=20 > This only works iff the NAIs are globally unique (e.g. map to DNS), = which imposes requirements on NAIs that aren=E2=80=99t present in RFC = 7542, and seemingly intentionally, compared to 4282. Huh? RFC 7542 explicitly calls out NAI Realms as mapping to DNS. See = Section 2.5: --- In order to ensure a canonical representation, characters of the realm portion in an NAI MUST match the ABNF in this specification as well as the requirements specified in [RFC5891]. In practice, these requirements consist of the following item: * Realms MUST be of the form that can be registered as a Fully Qualified Domain Name (FQDN) within the DNS. This list is significantly shorter and simpler than the list in Section 2.4 of [RFC4282]. --- The intention of RFC 7542 is that NAI Realms are *exactly* DNS names. = This is a change from 4282, where realms were, well, we don't know. = That failure motivated 7542. > Again, I think that=E2=80=99s desirable, to define an entirely new PKI = with zero overlap with the server auth/TLS PKI used by OSes/browsers, = but that does change your recommendations and design a bit :) The short = term recommendation becomes =E2=80=9Cdon=E2=80=99t use public CAs=E2=80=9D= , and that seems easier to explain and easier to evolve the technical = requirements, until the time that such a new, EAP-specific public PKI = can be introduced. The recommendation for EAP has generally been "don't use public CAs". = Originally it was in part because implementations didn't do certificate = pinning. i.e. once a root CA was trusted, a supplicant would accept any = server certificate signed by that root, and send credentials over. Now, over a decade of practice has shown the private CAs for EAP allow = for greater flexibility and control. I've personally had CAs take my = money for a cert, and refuse to give me anything in return. No amount = of complaining will convince them that it's a problem. It's much = simpler to just use a private CA. > In my mind, this is no different from organizations that want TLS = certificates for their servers named =E2=80=9Cwebmail=E2=80=9D (not = globally unique) or =E2=80=9Cmail_01.company.example=E2=80=9D (not = preferred name form / LDH). The answer is =E2=80=9Cuse private CAs, = don=E2=80=99t use public CAs=E2=80=9D I agree. Alan DeKok. From nobody Mon Dec 16 12:08:39 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 3215E12008C for ; Mon, 16 Dec 2019 12:08:31 -0800 (PST) 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=unavailable 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 e6q-GSyebjPG for ; Mon, 16 Dec 2019 12:08:29 -0800 (PST) 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 F2BEF120909 for ; Mon, 16 Dec 2019 12:08:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2718D300B33 for ; Mon, 16 Dec 2019 15:08:27 -0500 (EST) 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 mS1yJ4BGLFo2 for ; Mon, 16 Dec 2019 15:08:21 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id CC8FA30046F; Mon, 16 Dec 2019 15:08:20 -0500 (EST) 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: <000001d5b40c$b29da220$17d8e660$@sjtu.edu.cn> Date: Mon, 16 Dec 2019 15:08:21 -0500 Cc: Stefan Santesson , Ben Kaduk , IETF PKIX , LAMPS WG , David Cooper , Stephen Farrell , wpolk@nist.gov, "Roman D. Danyliw" Content-Transfer-Encoding: quoted-printable Message-Id: <631490CF-AE40-4D16-8A1D-A799806A302E@vigilsec.com> References: <000001d5b40c$b29da220$17d8e660$@sjtu.edu.cn> To: chenyt-sjtu X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] [Technical Errata Reported] RFC5280 (5938) 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, 16 Dec 2019 20:08:31 -0000 Yuting: You need to perform path validation to a trust anchor, and then you can = trust the binding of the subject public key to any or all of the names = in the certificate. Russ > On Dec 16, 2019, at 7:31 AM, chenyt-sjtu wrote: >=20 > Thank you, Stefan. >=20 > It seems that a path validation may not necessarily bind the subject=20= > public key and the subject DN and/or the subjectAltName extension. > I really suggest that the text can be tweaked for the right thing, :-) >=20 > Yuting >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Stefan Santesson =20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B412=E6=9C=8816=E6=97=A5= 17:59 > =E6=94=B6=E4=BB=B6=E4=BA=BA: chenyt-sjtu ; = 'Benjamin Kaduk' > =E6=8A=84=E9=80=81: 'Russ Housley' ; 'IETF PKIX' = ; 'LAMPS WG' ; 'David Cooper' = ; 'Stephen Farrell' ; = wpolk@nist.gov; 'Roman D. Danyliw' ; 'RFC Editor' = > =E4=B8=BB=E9=A2=98: Re: [Technical Errata Reported] RFC5280 (5938) >=20 > Yuting, >=20 > There is nothing you must verify. > If you trust the CA, you trust the CA to provide accurate information = about the subject. > You can safely ignore name information that is not relevant for you. >=20 >=20 > Stefan Santesson=20 >=20 > =EF=BB=BFOn 2019-12-16, 01:42, "chenyt-sjtu" = wrote: >=20 > I'm still curious of path validation. >=20 > When we have a certificate with a subject DN and a subjectAltName, = what should=20 > be "verified"? Is it the binding between the public key and (the = subject DN and the=20 > subjectAltName)? Or it will be fine if we just need to bind the key = to the subject DN.=20 > The validation results can be different when we have some bogus = certificates. >=20 > Regards, > Yuting >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Stefan Santesson =20= > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B412=E6=9C=8816=E6=97= =A5 4:26 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Benjamin Kaduk > =E6=8A=84=E9=80=81: Russ Housley ; IETF PKIX = ; LAMPS WG ; David Cooper = ; Stephen Farrell ; = wpolk@nist.gov; Roman D. Danyliw ; chenyt@sjtu.edu.cn; RFC = Editor > =E4=B8=BB=E9=A2=98: Re: [Technical Errata Reported] RFC5280 (5938) >=20 > So I have no objection either. Technically you are right of course. >=20 > My only point is that if you would pick any standards document of = size apart to this level, you would probably come up with a large number = of possible editorial erratas. > But again. There is nothing wrong with the suggested edit. >=20 >=20 > Stefan Santesson=20 >=20 > =EF=BB=BFOn 2019-12-15, 19:49, "Benjamin Kaduk" = wrote: >=20 > While I agree that the original text is fine in isolation, I = think the > document looks internally inconsistent when it says = "Certification path > processing verifies the binding between the subject = distinguished name > and/or subject alternative name and subject public key" in = Section 6 and > then "The primary goal of path validation is to verify the = binding between > a subject distinguished name or a subject alternative name and = subject > public key, as represented in the target certificate, based on = the public > key of the trust anchor" in Section 6.1. A reader would = rightly ask "what > is different?" between these two situations with one using = "subject > distinguished name and/or subject alternative name" and the = other using > "subject distinguished name or a subject alternative name". >=20 > Resolving this sort of minor discrepancy even when the meaning = is clear is > exactly what editorial errata are for. >=20 > -Ben >=20 > On Sun, Dec 15, 2019 at 05:38:12PM +0100, Stefan Santesson = wrote: >> I agree. >>=20 >> I don't think this type of nit picking belongs in an errata. >> The concept of biding a key to information in a certificate is well = understood. >>=20 >> Stefan Santesson=20 >>=20 >> =EF=BB=BFOn 2019-12-15, 17:23, "Russ Housley" = wrote: >>=20 >> I think the original text is fine. It is not an exclusive or. >>=20 >> Russ >>=20 >>> On Dec 14, 2019, at 10:00 PM, Benjamin Kaduk wrote: >>>=20 >>> I think this looks pretty straightforward (though I'd tweak the = "corrected >>> text" to do the right thing with the automated tooling and possibly = the >>> "notes" as well before verifying). Any thoughts for or against >>> "verified"/"editorial"? >>>=20 >>> Thanks, >>>=20 >>> Ben >>>=20 >>> On Sat, Dec 14, 2019 at 06:34:19PM -0800, RFC Errata System wrote: >>>> The following errata report has been submitted for RFC5280, >>>> "Internet X.509 Public Key Infrastructure Certificate and = Certificate Revocation List (CRL) Profile". >>>>=20 >>>> -------------------------------------- >>>> You may review the report below and at: >>>> https://www.rfc-editor.org/errata/eid5938 >>>>=20 >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Yuting Chen >>>>=20 >>>> Section: 6.1 >>>>=20 >>>> Original Text >>>> ------------- >>>> The primary goal of path validation is to verify the binding = between >>>> a subject distinguished name or a subject alternative name and >>>> subject public key, as represented in the target certificate, based >>>> on the public key of the trust anchor. In most cases, the target >>>>=20 >>>> Corrected Text >>>> -------------- >>>> The primary goal of path validation is to verify the binding = between >>>> | a subject distinguished name and/or a subject alternative name = and >>>> subject public key, as represented in the target certificate, based >>>> on the public key of the trust anchor. In most cases, the target >>>>=20 >>>> Notes >>>> ----- >>>> The correction conforms to the first paragraph, Sec. 6, = "Certification=20 >>>> path processing verifies the binding between the subject = distinguished >>>> name and/or subject alternative name and subject public key."=20 >>>>=20 >>>> In addition, it is not very clear in RFC 5280, given a certificate = with >>>> a non-empty subject DN and an SAN extension instance (critical or=20= >>>> non-critical), which one (the subject DN, the SAN extension, or = they=20 >>>> both) should be bound to the subject public key during path = validation. >>>> More explanations are needed. >>>>=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 >>>> -------------------------------------- >>>> RFC5280 (draft-ietf-pkix-rfc3280bis-11) >>>> -------------------------------------- >>>> Title : Internet X.509 Public Key Infrastructure = Certificate and Certificate Revocation List (CRL) Profile >>>> Publication Date : May 2008 >>>> Author(s) : D. Cooper, S. Santesson, S. Farrell, S. = Boeyen, R. Housley, W. Polk >>>> Category : PROPOSED STANDARD >>>> Source : Public-Key Infrastructure (X.509) >>>> Area : Security >>>> Stream : IETF >>>> Verifying Party : IESG >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 >=20 >=20 From nobody Mon Dec 16 16:57: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 6BBA8120965 for ; Mon, 16 Dec 2019 16:57:40 -0800 (PST) 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 kDil32M9lhcp for ; Mon, 16 Dec 2019 16:57:38 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 39C54120013 for ; Mon, 16 Dec 2019 16:57:38 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBH0vO2T013694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Dec 2019 19:57:27 -0500 Date: Mon, 16 Dec 2019 16:57:24 -0800 From: Benjamin Kaduk To: spasm@ietf.org Cc: phill@hallambaker.com, rob@sectigo.com, jsha@letsencrypt.org, rdd@cert.org, housley@vigilsec.com, tim.hollebeek@digicert.com, y-iida@secom.co.jp Message-ID: <20191217005724.GW81833@kduck.mit.edu> References: <20191212024322.9DA55F4071A@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191212024322.9DA55F4071A@rfc-editor.org> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [lamps] [Editorial Errata Reported] RFC8659 (5934) 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, 17 Dec 2019 00:57:40 -0000 I think I'm failing to find an ABNF construction that differs from 6844 to 8659 in the indicated manner ... help? -Ben On Wed, Dec 11, 2019 at 06:43:22PM -0800, RFC Errata System wrote: > The following errata report has been submitted for RFC8659, > "DNS Certification Authority Authorization (CAA) Resource Record". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5934 > > -------------------------------------- > Type: Editorial > Reported by: IIDA Yosiaki > > Section: 7 > > Original Text > ------------- > It also allows hyphens in Property Tags. > > Corrected Text > -------------- > It also allows hyphens in tags of Property Value of > issue and issuewild Property Tags. > > Notes > ----- > Subsection 4.1 explicitly prohibits hyphens in Property Tags. > While obsoleted RFC 6844 did not allow hyphens in tags of Property Value of issue and issuewild Property Tags, new ABNF definition in subsection 4.2 allows them. > > 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 > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8659 (draft-ietf-lamps-rfc6844bis-07) > -------------------------------------- > Title : DNS Certification Authority Authorization (CAA) Resource Record > Publication Date : November 2019 > Author(s) : P. Hallam-Baker, R. Stradling, J. Hoffman-Andrews > Category : PROPOSED STANDARD > Source : Limited Additional Mechanisms for PKIX and SMIME > Area : Security > Stream : IETF > Verifying Party : IESG From nobody Mon Dec 16 18:16:05 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 C46F01208FF for ; Mon, 16 Dec 2019 18:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 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_H3=0.001, RCVD_IN_MSPIKE_WL=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 OpHhPFKILZEY for ; Mon, 16 Dec 2019 18:16:03 -0800 (PST) Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (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 2414B12008F for ; Mon, 16 Dec 2019 18:16:03 -0800 (PST) Received: by mail-ot1-f53.google.com with SMTP id p8so11590627oth.10 for ; Mon, 16 Dec 2019 18:16:03 -0800 (PST) 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=+O9WqbPSn5EuczafWC+bmpRhWbzd3x5tJDmpHI/FNII=; b=UXQ4l0Nf8MV/0F/jrDDhKGKUcDePXeG4A3sVy/s5HPdGM1SsAS+P9qqs5QWajzoFJ/ ZERet3PLyHjLiF3OMvh7OFCbvL0ozCN55t8LcYeE8T5erxmusg4AifqEMPIE0AL2E0JS 8kFLCYUFRUfcjBzc94JkHuD2wuAYR6hP7GZHhAxYRuTLFpOrA19NJsA9z4FhS0md4WmD NiDx2CkMVthshGk6xJyfc+iMw/4/oAkF7nhMFEOYph6f2DKJGBOw18XHgyn3RlV5ZR7V i5alFlIF2J4PkneHxfvgEFvYpLsqmu8J5hPvoIiygvMM3j8a/+i+c81WC5atC6eNZeDe rVzg== X-Gm-Message-State: APjAAAWELFGdud+nYvQO4cxi0SAvhuXLLv+LdvtI1zsv4Mkt/MJCnLJG 8ERUyqRBxoZLkiq9cLVy+dagknwcFerLft31CcE= X-Google-Smtp-Source: APXvYqz5Rh8OCHA7f2KGiRB3+qwmy4IYC7h8AHJcvuuCKSpnioT2NP5y+Ndr9t/57co48ReVrLljfgQE04WEYjk7S7g= X-Received: by 2002:a05:6830:147:: with SMTP id j7mr19600531otp.44.1576548962324; Mon, 16 Dec 2019 18:16:02 -0800 (PST) MIME-Version: 1.0 References: <20191212024322.9DA55F4071A@rfc-editor.org> <20191217005724.GW81833@kduck.mit.edu> In-Reply-To: <20191217005724.GW81833@kduck.mit.edu> From: Phillip Hallam-Baker Date: Mon, 16 Dec 2019 21:15:51 -0500 Message-ID: To: Benjamin Kaduk Cc: SPASM , Rob Stradling , Jacob Hoffman-Andrews , Roman Danyliw , "housley@vigilsec.com" , Tim Hollebeek , y-iida@secom.co.jp Content-Type: multipart/alternative; boundary="000000000000ded7440599dce854" Archived-At: Subject: Re: [lamps] [Editorial Errata Reported] RFC8659 (5934) 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, 17 Dec 2019 02:16:05 -0000 --000000000000ded7440599dce854 Content-Type: text/plain; charset="UTF-8" It seems to be a confusion in RFC6844. The ABNF is actually referring to the value section of the CAA field which contains a sequence of tag-value productions. Those tags being distinct from the CAA tags. The CAA issue property value has the following sub-syntax (specified in ABNF as per [RFC5234 ]). On Mon, Dec 16, 2019 at 7:57 PM Benjamin Kaduk wrote: > I think I'm failing to find an ABNF construction that differs from 6844 to > 8659 in the indicated manner ... help? > > -Ben > > On Wed, Dec 11, 2019 at 06:43:22PM -0800, RFC Errata System wrote: > > The following errata report has been submitted for RFC8659, > > "DNS Certification Authority Authorization (CAA) Resource Record". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid5934 > > > > -------------------------------------- > > Type: Editorial > > Reported by: IIDA Yosiaki > > > > Section: 7 > > > > Original Text > > ------------- > > It also allows hyphens in Property Tags. > > > > Corrected Text > > -------------- > > It also allows hyphens in tags of Property Value of > > issue and issuewild Property Tags. > > > > Notes > > ----- > > Subsection 4.1 explicitly prohibits hyphens in Property Tags. > > While obsoleted RFC 6844 did not allow hyphens in tags of Property Value > of issue and issuewild Property Tags, new ABNF definition in subsection 4.2 > allows them. > > > > 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 > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC8659 (draft-ietf-lamps-rfc6844bis-07) > > -------------------------------------- > > Title : DNS Certification Authority Authorization (CAA) > Resource Record > > Publication Date : November 2019 > > Author(s) : P. Hallam-Baker, R. Stradling, J. Hoffman-Andrews > > Category : PROPOSED STANDARD > > Source : Limited Additional Mechanisms for PKIX and SMIME > > Area : Security > > Stream : IETF > > Verifying Party : IESG > --000000000000ded7440599dce854 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It = seems to be a confusion in RFC6844. The ABNF is actually referring to the v= alue section of the CAA field which contains a sequence of tag-value produc= tions. Those tags being distinct from the CAA tags.

The CAA issue property value has the following sub-syntax (specified
   in ABNF as per [RFC5234]).<=
/pre>




On Mon, Dec 16, 201= 9 at 7:57 PM Benjamin Kaduk <kaduk@mit.= edu> wrote:
I think I'm failing to find an ABNF construction that differs from 6= 844 to
8659 in the indicated manner ... help?

-Ben

On Wed, Dec 11, 2019 at 06:43:22PM -0800, RFC Errata System wrote:
> The following errata report has been submitted for RFC8659,
> "DNS Certification Authority Authorization (CAA) Resource Record&= quot;.
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5934
>
> --------------------------------------
> Type: Editorial
> Reported by: IIDA Yosiaki <y-iida@secom.co.jp>
>
> Section: 7
>
> Original Text
> -------------
> It also allows hyphens in Property Tags.
>
> Corrected Text
> --------------
> It also allows hyphens in tags of Property Value of
> issue and issuewild Property Tags.
>
> Notes
> -----
> Subsection 4.1 explicitly prohibits hyphens in Property Tags.
> While obsoleted RFC 6844 did not allow hyphens in tags of Property Val= ue of issue and issuewild Property Tags, new ABNF definition in subsection = 4.2 allows them.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party=C2=A0
> can log in to change the status and edit the report, if necessary. >
> --------------------------------------
> RFC8659 (draft-ietf-lamps-rfc6844bis-07)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: DNS Cert= ification Authority Authorization (CAA) Resource Record
> Publication Date=C2=A0 =C2=A0 : November 2019
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: P. Hallam-Baker, R= . Stradling, J. Hoffman-Andrews
> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<= br> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Limited Addit= ional Mechanisms for PKIX and SMIME
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security=
> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
--000000000000ded7440599dce854-- From nobody Mon Dec 16 18:44:37 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 99A4D12092C for ; Mon, 16 Dec 2019 18:44:35 -0800 (PST) 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 ln8nunef6EAF for ; Mon, 16 Dec 2019 18:44:33 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 4BEA512009C for ; Mon, 16 Dec 2019 18:44:33 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBH2iNJH006363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Dec 2019 21:44:26 -0500 Date: Mon, 16 Dec 2019 18:44:23 -0800 From: Benjamin Kaduk To: Phillip Hallam-Baker Cc: SPASM , Rob Stradling , Jacob Hoffman-Andrews , Roman Danyliw , "housley@vigilsec.com" , Tim Hollebeek , y-iida@secom.co.jp Message-ID: <20191217024423.GZ81833@kduck.mit.edu> References: <20191212024322.9DA55F4071A@rfc-editor.org> <20191217005724.GW81833@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [lamps] [Editorial Errata Reported] RFC8659 (5934) 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, 17 Dec 2019 02:44:36 -0000 Phill, were you going to paste an ABNF construction in there? Anyways, it sounds like this errata report is destined for "rejected" with a note about the confusing naming of ABNF productions from 6844? Thanks, Ben On Mon, Dec 16, 2019 at 09:15:51PM -0500, Phillip Hallam-Baker wrote: > It seems to be a confusion in RFC6844. The ABNF is actually referring to > the value section of the CAA field which contains a sequence of tag-value > productions. Those tags being distinct from the CAA tags. > > The CAA issue property value has the following sub-syntax (specified > in ABNF as per [RFC5234 ]). > > > > > > On Mon, Dec 16, 2019 at 7:57 PM Benjamin Kaduk wrote: > > > I think I'm failing to find an ABNF construction that differs from 6844 to > > 8659 in the indicated manner ... help? > > > > -Ben > > > > On Wed, Dec 11, 2019 at 06:43:22PM -0800, RFC Errata System wrote: > > > The following errata report has been submitted for RFC8659, > > > "DNS Certification Authority Authorization (CAA) Resource Record". > > > > > > -------------------------------------- > > > You may review the report below and at: > > > https://www.rfc-editor.org/errata/eid5934 > > > > > > -------------------------------------- > > > Type: Editorial > > > Reported by: IIDA Yosiaki > > > > > > Section: 7 > > > > > > Original Text > > > ------------- > > > It also allows hyphens in Property Tags. > > > > > > Corrected Text > > > -------------- > > > It also allows hyphens in tags of Property Value of > > > issue and issuewild Property Tags. > > > > > > Notes > > > ----- > > > Subsection 4.1 explicitly prohibits hyphens in Property Tags. > > > While obsoleted RFC 6844 did not allow hyphens in tags of Property Value > > of issue and issuewild Property Tags, new ABNF definition in subsection 4.2 > > allows them. > > > > > > 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 > > > can log in to change the status and edit the report, if necessary. > > > > > > -------------------------------------- > > > RFC8659 (draft-ietf-lamps-rfc6844bis-07) > > > -------------------------------------- > > > Title : DNS Certification Authority Authorization (CAA) > > Resource Record > > > Publication Date : November 2019 > > > Author(s) : P. Hallam-Baker, R. Stradling, J. Hoffman-Andrews > > > Category : PROPOSED STANDARD > > > Source : Limited Additional Mechanisms for PKIX and SMIME > > > Area : Security > > > Stream : IETF > > > Verifying Party : IESG > > From nobody Tue Dec 17 06:28: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 4D339120091; Sun, 15 Dec 2019 10:49:20 -0800 (PST) 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 UXzQ7JV_Jc0T; Sun, 15 Dec 2019 10:49:18 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 8311E120058; Sun, 15 Dec 2019 10:49:18 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBFIn2n4024502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 15 Dec 2019 13:49:04 -0500 Date: Sun, 15 Dec 2019 10:49:01 -0800 From: Benjamin Kaduk To: Stefan Santesson Cc: Russ Housley , IETF PKIX , LAMPS WG , David Cooper , Stephen Farrell , wpolk@nist.gov, "Roman D. Danyliw" , chenyt@sjtu.edu.cn, RFC Editor Message-ID: <20191215184901.GQ81833@kduck.mit.edu> References: <20191215023419.6B0ACF406CD@rfc-editor.org> <20191215030003.GP81833@kduck.mit.edu> <1E29AA8C-1153-40B6-BEB9-5E6F4F6E6E97@aaa-sec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1E29AA8C-1153-40B6-BEB9-5E6F4F6E6E97@aaa-sec.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: X-Mailman-Approved-At: Tue, 17 Dec 2019 06:28:46 -0800 Subject: Re: [lamps] [Technical Errata Reported] RFC5280 (5938) 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: Sun, 15 Dec 2019 18:49:20 -0000 While I agree that the original text is fine in isolation, I think the document looks internally inconsistent when it says "Certification path processing verifies the binding between the subject distinguished name and/or subject alternative name and subject public key" in Section 6 and then "The primary goal of path validation is to verify the binding between a subject distinguished name or a subject alternative name and subject public key, as represented in the target certificate, based on the public key of the trust anchor" in Section 6.1. A reader would rightly ask "what is different?" between these two situations with one using "subject distinguished name and/or subject alternative name" and the other using "subject distinguished name or a subject alternative name". Resolving this sort of minor discrepancy even when the meaning is clear is exactly what editorial errata are for. -Ben On Sun, Dec 15, 2019 at 05:38:12PM +0100, Stefan Santesson wrote: > I agree. > > I don't think this type of nit picking belongs in an errata. > The concept of biding a key to information in a certificate is well understood. > > Stefan Santesson > > On 2019-12-15, 17:23, "Russ Housley" wrote: > > I think the original text is fine. It is not an exclusive or. > > Russ > > > On Dec 14, 2019, at 10:00 PM, Benjamin Kaduk wrote: > > > > I think this looks pretty straightforward (though I'd tweak the "corrected > > text" to do the right thing with the automated tooling and possibly the > > "notes" as well before verifying). Any thoughts for or against > > "verified"/"editorial"? > > > > Thanks, > > > > Ben > > > > On Sat, Dec 14, 2019 at 06:34:19PM -0800, RFC Errata System wrote: > >> The following errata report has been submitted for RFC5280, > >> "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". > >> > >> -------------------------------------- > >> You may review the report below and at: > >> https://www.rfc-editor.org/errata/eid5938 > >> > >> -------------------------------------- > >> Type: Technical > >> Reported by: Yuting Chen > >> > >> Section: 6.1 > >> > >> Original Text > >> ------------- > >> The primary goal of path validation is to verify the binding between > >> a subject distinguished name or a subject alternative name and > >> subject public key, as represented in the target certificate, based > >> on the public key of the trust anchor. In most cases, the target > >> > >> Corrected Text > >> -------------- > >> The primary goal of path validation is to verify the binding between > >> | a subject distinguished name and/or a subject alternative name and > >> subject public key, as represented in the target certificate, based > >> on the public key of the trust anchor. In most cases, the target > >> > >> Notes > >> ----- > >> The correction conforms to the first paragraph, Sec. 6, "Certification > >> path processing verifies the binding between the subject distinguished > >> name and/or subject alternative name and subject public key." > >> > >> In addition, it is not very clear in RFC 5280, given a certificate with > >> a non-empty subject DN and an SAN extension instance (critical or > >> non-critical), which one (the subject DN, the SAN extension, or they > >> both) should be bound to the subject public key during path validation. > >> More explanations are needed. > >> > >> 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 > >> can log in to change the status and edit the report, if necessary. > >> > >> -------------------------------------- > >> RFC5280 (draft-ietf-pkix-rfc3280bis-11) > >> -------------------------------------- > >> Title : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile > >> Publication Date : May 2008 > >> Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk > >> Category : PROPOSED STANDARD > >> Source : Public-Key Infrastructure (X.509) > >> Area : Security > >> Stream : IETF > >> Verifying Party : IESG > > > > From nobody Tue Dec 17 06:28:53 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 06705120091 for ; Sun, 15 Dec 2019 12:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.439 X-Spam-Level: * X-Spam-Status: No, score=1.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_NONE=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 2ExffCBIBRNQ for ; Sun, 15 Dec 2019 12:26:30 -0800 (PST) Received: from smtp2.outgoing.loopia.se (smtp2.outgoing.loopia.se [93.188.3.37]) (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 7D425120058 for ; Sun, 15 Dec 2019 12:26:30 -0800 (PST) Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id 9B41E2E56128 for ; Sun, 15 Dec 2019 21:26:24 +0100 (CET) Received: from s498.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with ESMTP id 7AB462E27F6B; Sun, 15 Dec 2019 21:26:24 +0100 (CET) Received: from s472.loopia.se (unknown [172.22.191.6]) by s498.loopia.se (Postfix) with ESMTP id 6DF694707CD; Sun, 15 Dec 2019 21:26:24 +0100 (CET) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s500.loopia.se ([172.22.191.6]) by s472.loopia.se (s472.loopia.se [172.22.190.12]) (amavisd-new, port 10024) with LMTP id 87eZ1J1KjdXq; Sun, 15 Dec 2019 21:26:23 +0100 (CET) X-Loopia-Auth: user X-Loopia-User: mailstore2@aaa-sec.com X-Loopia-Originating-IP: 195.67.91.185 Received: from [10.30.3.163] (195-67-91-185.customer.telia.com [195.67.91.185]) (Authenticated sender: mailstore2@aaa-sec.com) by s500.loopia.se (Postfix) with ESMTPSA id 268E71E1466E; Sun, 15 Dec 2019 21:26:23 +0100 (CET) User-Agent: Microsoft-MacOutlook/10.20.0.191208 Date: Sun, 15 Dec 2019 21:26:22 +0100 From: Stefan Santesson To: Benjamin Kaduk CC: Russ Housley , IETF PKIX , LAMPS WG , David Cooper , Stephen Farrell , , "Roman D. Danyliw" , , RFC Editor Message-ID: Thread-Topic: [Technical Errata Reported] RFC5280 (5938) References: <20191215023419.6B0ACF406CD@rfc-editor.org> <20191215030003.GP81833@kduck.mit.edu> <1E29AA8C-1153-40B6-BEB9-5E6F4F6E6E97@aaa-sec.com> <20191215184901.GQ81833@kduck.mit.edu> In-Reply-To: <20191215184901.GQ81833@kduck.mit.edu> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Tue, 17 Dec 2019 06:28:45 -0800 Subject: Re: [lamps] [Technical Errata Reported] RFC5280 (5938) 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: Sun, 15 Dec 2019 20:26:33 -0000 So I have no objection either. Technically you are right of course. My only point is that if you would pick any standards document of size apar= t to this level, you would probably come up with a large number of possible = editorial erratas. But again. There is nothing wrong with the suggested edit. Stefan Santesson=20 =EF=BB=BFOn 2019-12-15, 19:49, "Benjamin Kaduk" wrote: While I agree that the original text is fine in isolation, I think the document looks internally inconsistent when it says "Certification path processing verifies the binding between the subject distinguished name and/or subject alternative name and subject public key" in Section 6 an= d then "The primary goal of path validation is to verify the binding betw= een a subject distinguished name or a subject alternative name and subject public key, as represented in the target certificate, based on the publ= ic key of the trust anchor" in Section 6.1. A reader would rightly ask "w= hat is different?" between these two situations with one using "subject distinguished name and/or subject alternative name" and the other using "subject distinguished name or a subject alternative name". =20 Resolving this sort of minor discrepancy even when the meaning is clear= is exactly what editorial errata are for. =20 -Ben =20 On Sun, Dec 15, 2019 at 05:38:12PM +0100, Stefan Santesson wrote: > I agree. >=20 > I don't think this type of nit picking belongs in an errata. > The concept of biding a key to information in a certificate is well u= nderstood. >=20 > Stefan Santesson=20 >=20 > =EF=BB=BFOn 2019-12-15, 17:23, "Russ Housley" wrote: >=20 > I think the original text is fine. It is not an exclusive or. > =20 > Russ > =20 > > On Dec 14, 2019, at 10:00 PM, Benjamin Kaduk wr= ote: > >=20 > > I think this looks pretty straightforward (though I'd tweak the= "corrected > > text" to do the right thing with the automated tooling and poss= ibly the > > "notes" as well before verifying). Any thoughts for or against > > "verified"/"editorial"? > >=20 > > Thanks, > >=20 > > Ben > >=20 > > On Sat, Dec 14, 2019 at 06:34:19PM -0800, RFC Errata System wro= te: > >> The following errata report has been submitted for RFC5280, > >> "Internet X.509 Public Key Infrastructure Certificate and Cert= ificate Revocation List (CRL) Profile". > >>=20 > >> -------------------------------------- > >> You may review the report below and at: > >> https://www.rfc-editor.org/errata/eid5938 > >>=20 > >> -------------------------------------- > >> Type: Technical > >> Reported by: Yuting Chen > >>=20 > >> Section: 6.1 > >>=20 > >> Original Text > >> ------------- > >> The primary goal of path validation is to verify the binding b= etween > >> a subject distinguished name or a subject alternative name and > >> subject public key, as represented in the target certificate, = based > >> on the public key of the trust anchor. In most cases, the targ= et > >>=20 > >> Corrected Text > >> -------------- > >> The primary goal of path validation is to verify the binding = between > >> | a subject distinguished name and/or a subject alternative na= me and > >> subject public key, as represented in the target certificate,= based > >> on the public key of the trust anchor. In most cases, the tar= get > >>=20 > >> Notes > >> ----- > >> The correction conforms to the first paragraph, Sec. 6, "Certi= fication=20 > >> path processing verifies the binding between the subject disti= nguished > >> name and/or subject alternative name and subject public key."=20 > >>=20 > >> In addition, it is not very clear in RFC 5280, given a certifi= cate with > >> a non-empty subject DN and an SAN extension instance (critical= or=20 > >> non-critical), which one (the subject DN, the SAN extension, = or they=20 > >> both) should be bound to the subject public key during path va= lidation. > >> More explanations are needed. > >>=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 necess= ary.=20 > >>=20 > >> -------------------------------------- > >> RFC5280 (draft-ietf-pkix-rfc3280bis-11) > >> -------------------------------------- > >> Title : Internet X.509 Public Key Infrastructure= Certificate and Certificate Revocation List (CRL) Profile > >> Publication Date : May 2008 > >> Author(s) : D. Cooper, S. Santesson, S. Farrell, S. = Boeyen, R. Housley, W. Polk > >> Category : PROPOSED STANDARD > >> Source : Public-Key Infrastructure (X.509) > >> Area : Security > >> Stream : IETF > >> Verifying Party : IESG > =20 > =20 >=20 >=20 =20 From chenyt@sjtu.edu.cn Sun Dec 15 16:42: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 13307120059; Sun, 15 Dec 2019 16:42:15 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 VLnwSkpAH8Nc; Sun, 15 Dec 2019 16:42:12 -0800 (PST) Received: from smtp180.sjtu.edu.cn (smtp180.sjtu.edu.cn [202.120.2.180]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C18F612004A; Sun, 15 Dec 2019 16:42:11 -0800 (PST) Received: from proxy06.sjtu.edu.cn (smtp188.sjtu.edu.cn [202.120.2.188]) by smtp180.sjtu.edu.cn (Postfix) with ESMTPS id 976A4100AFC1E; Mon, 16 Dec 2019 08:42:07 +0800 (CST) Received: from localhost (localhost.localdomain [127.0.0.1]) by proxy06.sjtu.edu.cn (Postfix) with ESMTP id 79DB4AAF682; Mon, 16 Dec 2019 08:42:07 +0800 (CST) X-Virus-Scanned: amavisd-new at proxy06.sjtu.edu.cn Received: from proxy06.sjtu.edu.cn ([127.0.0.1]) by localhost (proxy06.sjtu.edu.cn [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id khtksGWZmGbr; Mon, 16 Dec 2019 08:42:07 +0800 (CST) Received: from DESKTOPJG33ADI (unknown [10.162.65.160]) by proxy06.sjtu.edu.cn (Postfix) with ESMTPA id 18FBD7DBE0; Mon, 16 Dec 2019 08:41:56 +0800 (CST) From: "chenyt-sjtu" To: "'Stefan Santesson'" , "'Benjamin Kaduk'" Cc: "'Russ Housley'" , "'IETF PKIX'" , "'LAMPS WG'" , "'David Cooper'" , "'Stephen Farrell'" , , "'Roman D. Danyliw'" , "'RFC Editor'" Date: Mon, 16 Dec 2019 08:41:49 +0800 Message-ID: <000001d5b3a9$a40bcf60$ec236e20$@sjtu.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdWzpy6ts6W9ujyYSxWni+uAxbp2eQ== Content-Language: zh-cn Archived-At: X-Mailman-Approved-At: Tue, 17 Dec 2019 06:28:45 -0800 Subject: Re: [lamps] [Technical Errata Reported] RFC5280 (5938) 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, 16 Dec 2019 00:59:15 -0000 I'm still curious of path validation. When we have a certificate with a subject DN and a subjectAltName, what = should=20 be "verified"? Is it the binding between the public key and (the subject = DN and the=20 subjectAltName)? Or it will be fine if we just need to bind the key to = the subject DN.=20 The validation results can be different when we have some bogus = certificates. Regards, Yuting -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Stefan Santesson =20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2019=E5=B9=B412=E6=9C=8816=E6=97=A5 4:26 =E6=94=B6=E4=BB=B6=E4=BA=BA: Benjamin Kaduk =E6=8A=84=E9=80=81: Russ Housley ; IETF PKIX = ; LAMPS WG ; David Cooper = ; Stephen Farrell ; = wpolk@nist.gov; Roman D. Danyliw ; chenyt@sjtu.edu.cn; RFC = Editor =E4=B8=BB=E9=A2=98: Re: [Technical Errata Reported] RFC5280 (5938) So I have no objection either. Technically you are right of course. My only point is that if you would pick any standards document of size = apart to this level, you would probably come up with a large number of = possible editorial erratas. But again. There is nothing wrong with the suggested edit. Stefan Santesson=20 =EF=BB=BFOn 2019-12-15, 19:49, "Benjamin Kaduk" wrote: While I agree that the original text is fine in isolation, I think = the document looks internally inconsistent when it says "Certification = path processing verifies the binding between the subject distinguished = name and/or subject alternative name and subject public key" in Section 6 = and then "The primary goal of path validation is to verify the binding = between a subject distinguished name or a subject alternative name and = subject public key, as represented in the target certificate, based on the = public key of the trust anchor" in Section 6.1. A reader would rightly ask = "what is different?" between these two situations with one using "subject distinguished name and/or subject alternative name" and the other = using "subject distinguished name or a subject alternative name". =20 Resolving this sort of minor discrepancy even when the meaning is = clear is exactly what editorial errata are for. =20 -Ben =20 On Sun, Dec 15, 2019 at 05:38:12PM +0100, Stefan Santesson wrote: > I agree. >=20 > I don't think this type of nit picking belongs in an errata. > The concept of biding a key to information in a certificate is = well understood. >=20 > Stefan Santesson=20 >=20 > =EF=BB=BFOn 2019-12-15, 17:23, "Russ Housley" = wrote: >=20 > I think the original text is fine. It is not an exclusive or. > =20 > Russ > =20 > > On Dec 14, 2019, at 10:00 PM, Benjamin Kaduk = wrote: > >=20 > > I think this looks pretty straightforward (though I'd tweak = the "corrected > > text" to do the right thing with the automated tooling and = possibly the > > "notes" as well before verifying). Any thoughts for or = against > > "verified"/"editorial"? > >=20 > > Thanks, > >=20 > > Ben > >=20 > > On Sat, Dec 14, 2019 at 06:34:19PM -0800, RFC Errata System = wrote: > >> The following errata report has been submitted for RFC5280, > >> "Internet X.509 Public Key Infrastructure Certificate and = Certificate Revocation List (CRL) Profile". > >>=20 > >> -------------------------------------- > >> You may review the report below and at: > >> https://www.rfc-editor.org/errata/eid5938 > >>=20 > >> -------------------------------------- > >> Type: Technical > >> Reported by: Yuting Chen > >>=20 > >> Section: 6.1 > >>=20 > >> Original Text > >> ------------- > >> The primary goal of path validation is to verify the = binding between > >> a subject distinguished name or a subject alternative name = and > >> subject public key, as represented in the target = certificate, based > >> on the public key of the trust anchor. In most cases, the = target > >>=20 > >> Corrected Text > >> -------------- > >> The primary goal of path validation is to verify the = binding between > >> | a subject distinguished name and/or a subject alternative = name and > >> subject public key, as represented in the target = certificate, based > >> on the public key of the trust anchor. In most cases, the = target > >>=20 > >> Notes > >> ----- > >> The correction conforms to the first paragraph, Sec. 6, = "Certification=20 > >> path processing verifies the binding between the subject = distinguished > >> name and/or subject alternative name and subject public = key."=20 > >>=20 > >> In addition, it is not very clear in RFC 5280, given a = certificate with > >> a non-empty subject DN and an SAN extension instance = (critical or=20 > >> non-critical), which one (the subject DN, the SAN = extension, or they=20 > >> both) should be bound to the subject public key during path = validation. > >> More explanations are needed. > >>=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 > >> -------------------------------------- > >> RFC5280 (draft-ietf-pkix-rfc3280bis-11) > >> -------------------------------------- > >> Title : Internet X.509 Public Key = Infrastructure Certificate and Certificate Revocation List (CRL) Profile > >> Publication Date : May 2008 > >> Author(s) : D. Cooper, S. Santesson, S. Farrell, = S. Boeyen, R. Housley, W. Polk > >> Category : PROPOSED STANDARD > >> Source : Public-Key Infrastructure (X.509) > >> Area : Security > >> Stream : IETF > >> Verifying Party : IESG > =20 > =20 >=20 >=20 =20 From nobody Tue Dec 17 06:29:03 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 7D944120130 for ; Mon, 16 Dec 2019 01:58:52 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, 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 L2iaC1UScV4g for ; Mon, 16 Dec 2019 01:58:49 -0800 (PST) Received: from smtp2.outgoing.loopia.se (smtp2.outgoing.loopia.se [93.188.3.37]) (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 B8362120128 for ; Mon, 16 Dec 2019 01:58:49 -0800 (PST) Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id 7647F2E56278 for ; Mon, 16 Dec 2019 10:58:32 +0100 (CET) Received: from s630.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with ESMTP id 5593D2E27904; Mon, 16 Dec 2019 10:58:32 +0100 (CET) Received: from s474.loopia.se (unknown [172.22.191.5]) by s630.loopia.se (Postfix) with ESMTP id 40CAF13ABDF2; Mon, 16 Dec 2019 10:58:32 +0100 (CET) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s499.loopia.se ([172.22.191.5]) by s474.loopia.se (s474.loopia.se [172.22.190.14]) (amavisd-new, port 10024) with LMTP id 0_R9oPyP6CoH; Mon, 16 Dec 2019 10:58:31 +0100 (CET) X-Loopia-Auth: user X-Loopia-User: mailstore2@aaa-sec.com X-Loopia-Originating-IP: 85.235.7.89 Received: from [192.168.2.38] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: mailstore2@aaa-sec.com) by s499.loopia.se (Postfix) with ESMTPSA id 377F11CDAEC9; Mon, 16 Dec 2019 10:58:31 +0100 (CET) User-Agent: Microsoft-MacOutlook/10.20.0.191208 Date: Mon, 16 Dec 2019 10:58:30 +0100 From: Stefan Santesson To: chenyt-sjtu , 'Benjamin Kaduk' CC: 'Russ Housley' , 'IETF PKIX' , 'LAMPS WG' , 'David Cooper' , 'Stephen Farrell' , , "'Roman D. Danyliw'" , 'RFC Editor' Message-ID: Thread-Topic: [Technical Errata Reported] RFC5280 (5938) References: <000001d5b3a9$a40bcf60$ec236e20$@sjtu.edu.cn> In-Reply-To: <000001d5b3a9$a40bcf60$ec236e20$@sjtu.edu.cn> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Tue, 17 Dec 2019 06:28:45 -0800 Subject: Re: [lamps] [Technical Errata Reported] RFC5280 (5938) 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, 16 Dec 2019 09:58:52 -0000 Yuting, There is nothing you must verify. If you trust the CA, you trust the CA to provide accurate information about= the subject. You can safely ignore name information that is not relevant for you. Stefan Santesson=20 =EF=BB=BFOn 2019-12-16, 01:42, "chenyt-sjtu" wrote: I'm still curious of path validation. =20 When we have a certificate with a subject DN and a subjectAltName, what= should=20 be "verified"? Is it the binding between the public key and (the subjec= t DN and the=20 subjectAltName)? Or it will be fine if we just need to bind the key to = the subject DN.=20 The validation results can be different when we have some bogus certifi= cates. =20 Regards, Yuting =20 -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Stefan Santesson =20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B412=E6=9C=8816=E6=97=A5 4:26 =E6=94=B6=E4=BB=B6=E4=BA=BA: Benjamin Kaduk =E6=8A=84=E9=80=81: Russ Housley ; IETF PKIX ;= LAMPS WG ; David Cooper ; Stephen Fa= rrell ; wpolk@nist.gov; Roman D. Danyliw ; chenyt@sjtu.edu.cn; RFC Editor =E4=B8=BB=E9=A2=98: Re: [Technical Errata Reported] RFC5280 (5938) =20 So I have no objection either. Technically you are right of course. =20 My only point is that if you would pick any standards document of size = apart to this level, you would probably come up with a large number of possi= ble editorial erratas. But again. There is nothing wrong with the suggested edit. =20 =20 Stefan Santesson=20 =20 =EF=BB=BFOn 2019-12-15, 19:49, "Benjamin Kaduk" wrote: =20 While I agree that the original text is fine in isolation, I think = the document looks internally inconsistent when it says "Certification = path processing verifies the binding between the subject distinguished n= ame and/or subject alternative name and subject public key" in Section = 6 and then "The primary goal of path validation is to verify the binding = between a subject distinguished name or a subject alternative name and subj= ect public key, as represented in the target certificate, based on the = public key of the trust anchor" in Section 6.1. A reader would rightly as= k "what is different?" between these two situations with one using "subject distinguished name and/or subject alternative name" and the other u= sing "subject distinguished name or a subject alternative name". =20 Resolving this sort of minor discrepancy even when the meaning is c= lear is exactly what editorial errata are for. =20 -Ben =20 On Sun, Dec 15, 2019 at 05:38:12PM +0100, Stefan Santesson wrote: > I agree. >=20 > I don't think this type of nit picking belongs in an errata. > The concept of biding a key to information in a certificate is we= ll understood. >=20 > Stefan Santesson=20 >=20 > =EF=BB=BFOn 2019-12-15, 17:23, "Russ Housley" wr= ote: >=20 > I think the original text is fine. It is not an exclusive or= . > =20 > Russ > =20 > > On Dec 14, 2019, at 10:00 PM, Benjamin Kaduk wrote: > >=20 > > I think this looks pretty straightforward (though I'd tweak= the "corrected > > text" to do the right thing with the automated tooling and = possibly the > > "notes" as well before verifying). Any thoughts for or aga= inst > > "verified"/"editorial"? > >=20 > > Thanks, > >=20 > > Ben > >=20 > > On Sat, Dec 14, 2019 at 06:34:19PM -0800, RFC Errata System= wrote: > >> The following errata report has been submitted for RFC5280= , > >> "Internet X.509 Public Key Infrastructure Certificate and = Certificate Revocation List (CRL) Profile". > >>=20 > >> -------------------------------------- > >> You may review the report below and at: > >> https://www.rfc-editor.org/errata/eid5938 > >>=20 > >> -------------------------------------- > >> Type: Technical > >> Reported by: Yuting Chen > >>=20 > >> Section: 6.1 > >>=20 > >> Original Text > >> ------------- > >> The primary goal of path validation is to verify the bindi= ng between > >> a subject distinguished name or a subject alternative name= and > >> subject public key, as represented in the target certifica= te, based > >> on the public key of the trust anchor. In most cases, the = target > >>=20 > >> Corrected Text > >> -------------- > >> The primary goal of path validation is to verify the bind= ing between > >> | a subject distinguished name and/or a subject alternativ= e name and > >> subject public key, as represented in the target certific= ate, based > >> on the public key of the trust anchor. In most cases, the= target > >>=20 > >> Notes > >> ----- > >> The correction conforms to the first paragraph, Sec. 6, "C= ertification=20 > >> path processing verifies the binding between the subject d= istinguished > >> name and/or subject alternative name and subject public ke= y."=20 > >>=20 > >> In addition, it is not very clear in RFC 5280, given a cer= tificate with > >> a non-empty subject DN and an SAN extension instance (crit= ical or=20 > >> non-critical), which one (the subject DN, the SAN extensio= n, or they=20 > >> both) should be bound to the subject public key during pat= h validation. > >> More explanations are needed. > >>=20 > >> Instructions: > >> ------------- > >> This erratum is currently posted as "Reported". If necessa= ry, please > >> use "Reply All" to discuss whether it should be verified o= r > >> rejected. When a decision is reached, the verifying party = =20 > >> can log in to change the status and edit the report, if ne= cessary.=20 > >>=20 > >> -------------------------------------- > >> RFC5280 (draft-ietf-pkix-rfc3280bis-11) > >> -------------------------------------- > >> Title : Internet X.509 Public Key Infrastruc= ture Certificate and Certificate Revocation List (CRL) Profile > >> Publication Date : May 2008 > >> Author(s) : D. Cooper, S. Santesson, S. Farrell,= S. Boeyen, R. Housley, W. Polk > >> Category : PROPOSED STANDARD > >> Source : Public-Key Infrastructure (X.509) > >> Area : Security > >> Stream : IETF > >> Verifying Party : IESG > =20 > =20 >=20 >=20 =20 =20 =20 =20 From nobody Tue Dec 17 06:29:07 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 3AD10120836; Mon, 16 Dec 2019 04:31:25 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 usXH1oQPc6u2; Mon, 16 Dec 2019 04:31:21 -0800 (PST) Received: from smtp180.sjtu.edu.cn (smtp180.sjtu.edu.cn [202.120.2.180]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB28D12082B; Mon, 16 Dec 2019 04:31:18 -0800 (PST) Received: from proxy06.sjtu.edu.cn (smtp188.sjtu.edu.cn [202.120.2.188]) by smtp180.sjtu.edu.cn (Postfix) with ESMTPS id 7F79C100AFC1F; Mon, 16 Dec 2019 20:31:12 +0800 (CST) Received: from localhost (localhost.localdomain [127.0.0.1]) by proxy06.sjtu.edu.cn (Postfix) with ESMTP id 6A5E77DBE0; Mon, 16 Dec 2019 20:31:12 +0800 (CST) X-Virus-Scanned: amavisd-new at proxy06.sjtu.edu.cn Received: from proxy06.sjtu.edu.cn ([127.0.0.1]) by localhost (proxy06.sjtu.edu.cn [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Rs3jaVcGt3Wx; Mon, 16 Dec 2019 20:31:12 +0800 (CST) Received: from DESKTOPJG33ADI (unknown [202.120.37.144]) by proxy06.sjtu.edu.cn (Postfix) with ESMTPA id 34ECFAAF685; Mon, 16 Dec 2019 20:31:03 +0800 (CST) From: "chenyt-sjtu" To: "'Stefan Santesson'" , "'Benjamin Kaduk'" Cc: "'Russ Housley'" , "'IETF PKIX'" , "'LAMPS WG'" , "'David Cooper'" , "'Stephen Farrell'" , , "'Roman D. Danyliw'" , "'RFC Editor'" Date: Mon, 16 Dec 2019 20:31:01 +0800 Message-ID: <000001d5b40c$b29da220$17d8e660$@sjtu.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdW0CW+sNArxskyzTVuI/UkiIYq4TQ== Content-Language: zh-cn Archived-At: X-Mailman-Approved-At: Tue, 17 Dec 2019 06:28:45 -0800 Subject: Re: [lamps] [Technical Errata Reported] RFC5280 (5938) 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, 16 Dec 2019 12:31:25 -0000 Thank you, Stefan. It seems that a path validation may not necessarily bind the subject=20 public key and the subject DN and/or the subjectAltName extension. I really suggest that the text can be tweaked for the right thing, :-) Yuting -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Stefan Santesson =20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2019=E5=B9=B412=E6=9C=8816=E6=97=A5 17:59 =E6=94=B6=E4=BB=B6=E4=BA=BA: chenyt-sjtu ; 'Benjamin = Kaduk' =E6=8A=84=E9=80=81: 'Russ Housley' ; 'IETF PKIX' = ; 'LAMPS WG' ; 'David Cooper' = ; 'Stephen Farrell' ; = wpolk@nist.gov; 'Roman D. Danyliw' ; 'RFC Editor' = =E4=B8=BB=E9=A2=98: Re: [Technical Errata Reported] RFC5280 (5938) Yuting, There is nothing you must verify. If you trust the CA, you trust the CA to provide accurate information = about the subject. You can safely ignore name information that is not relevant for you. Stefan Santesson=20 =EF=BB=BFOn 2019-12-16, 01:42, "chenyt-sjtu" wrote: I'm still curious of path validation. =20 When we have a certificate with a subject DN and a subjectAltName, = what should=20 be "verified"? Is it the binding between the public key and (the = subject DN and the=20 subjectAltName)? Or it will be fine if we just need to bind the key = to the subject DN.=20 The validation results can be different when we have some bogus = certificates. =20 Regards, Yuting =20 -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Stefan Santesson =20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2019=E5=B9=B412=E6=9C=8816=E6=97=A5 4:26 =E6=94=B6=E4=BB=B6=E4=BA=BA: Benjamin Kaduk =E6=8A=84=E9=80=81: Russ Housley ; IETF PKIX = ; LAMPS WG ; David Cooper = ; Stephen Farrell ; = wpolk@nist.gov; Roman D. Danyliw ; chenyt@sjtu.edu.cn; RFC = Editor =E4=B8=BB=E9=A2=98: Re: [Technical Errata Reported] RFC5280 (5938) =20 So I have no objection either. Technically you are right of course. =20 My only point is that if you would pick any standards document of = size apart to this level, you would probably come up with a large number = of possible editorial erratas. But again. There is nothing wrong with the suggested edit. =20 =20 Stefan Santesson=20 =20 =EF=BB=BFOn 2019-12-15, 19:49, "Benjamin Kaduk" = wrote: =20 While I agree that the original text is fine in isolation, I = think the document looks internally inconsistent when it says = "Certification path processing verifies the binding between the subject = distinguished name and/or subject alternative name and subject public key" in = Section 6 and then "The primary goal of path validation is to verify the = binding between a subject distinguished name or a subject alternative name and = subject public key, as represented in the target certificate, based on = the public key of the trust anchor" in Section 6.1. A reader would rightly = ask "what is different?" between these two situations with one using = "subject distinguished name and/or subject alternative name" and the = other using "subject distinguished name or a subject alternative name". =20 Resolving this sort of minor discrepancy even when the meaning = is clear is exactly what editorial errata are for. =20 -Ben =20 On Sun, Dec 15, 2019 at 05:38:12PM +0100, Stefan Santesson = wrote: > I agree. >=20 > I don't think this type of nit picking belongs in an errata. > The concept of biding a key to information in a certificate is = well understood. >=20 > Stefan Santesson=20 >=20 > =EF=BB=BFOn 2019-12-15, 17:23, "Russ Housley" = wrote: >=20 > I think the original text is fine. It is not an exclusive = or. > =20 > Russ > =20 > > On Dec 14, 2019, at 10:00 PM, Benjamin Kaduk = wrote: > >=20 > > I think this looks pretty straightforward (though I'd = tweak the "corrected > > text" to do the right thing with the automated tooling = and possibly the > > "notes" as well before verifying). Any thoughts for or = against > > "verified"/"editorial"? > >=20 > > Thanks, > >=20 > > Ben > >=20 > > On Sat, Dec 14, 2019 at 06:34:19PM -0800, RFC Errata = System wrote: > >> The following errata report has been submitted for = RFC5280, > >> "Internet X.509 Public Key Infrastructure Certificate = and Certificate Revocation List (CRL) Profile". > >>=20 > >> -------------------------------------- > >> You may review the report below and at: > >> https://www.rfc-editor.org/errata/eid5938 > >>=20 > >> -------------------------------------- > >> Type: Technical > >> Reported by: Yuting Chen > >>=20 > >> Section: 6.1 > >>=20 > >> Original Text > >> ------------- > >> The primary goal of path validation is to verify the = binding between > >> a subject distinguished name or a subject alternative = name and > >> subject public key, as represented in the target = certificate, based > >> on the public key of the trust anchor. In most cases, = the target > >>=20 > >> Corrected Text > >> -------------- > >> The primary goal of path validation is to verify the = binding between > >> | a subject distinguished name and/or a subject = alternative name and > >> subject public key, as represented in the target = certificate, based > >> on the public key of the trust anchor. In most cases, = the target > >>=20 > >> Notes > >> ----- > >> The correction conforms to the first paragraph, Sec. 6, = "Certification=20 > >> path processing verifies the binding between the = subject distinguished > >> name and/or subject alternative name and subject public = key."=20 > >>=20 > >> In addition, it is not very clear in RFC 5280, given a = certificate with > >> a non-empty subject DN and an SAN extension instance = (critical or=20 > >> non-critical), which one (the subject DN, the SAN = extension, or they=20 > >> both) should be bound to the subject public key during = path validation. > >> More explanations are needed. > >>=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 > >> -------------------------------------- > >> RFC5280 (draft-ietf-pkix-rfc3280bis-11) > >> -------------------------------------- > >> Title : Internet X.509 Public Key = Infrastructure Certificate and Certificate Revocation List (CRL) Profile > >> Publication Date : May 2008 > >> Author(s) : D. Cooper, S. Santesson, S. = Farrell, S. Boeyen, R. Housley, W. Polk > >> Category : PROPOSED STANDARD > >> Source : Public-Key Infrastructure (X.509) > >> Area : Security > >> Stream : IETF > >> Verifying Party : IESG > =20 > =20 >=20 >=20 =20 =20 =20 =20 From nobody Tue Dec 17 06:29:14 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 5D73A120971; Mon, 16 Dec 2019 17:47:45 -0800 (PST) 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, 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=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 lC4oZDntHhRP; Mon, 16 Dec 2019 17:47:42 -0800 (PST) Received: from smtp180.sjtu.edu.cn (smtp180.sjtu.edu.cn [202.120.2.180]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C01D12009C; Mon, 16 Dec 2019 17:47:41 -0800 (PST) Received: from proxy06.sjtu.edu.cn (smtp188.sjtu.edu.cn [202.120.2.188]) by smtp180.sjtu.edu.cn (Postfix) with ESMTPS id E0594100AFC25; Tue, 17 Dec 2019 09:47:36 +0800 (CST) Received: from localhost (localhost.localdomain [127.0.0.1]) by proxy06.sjtu.edu.cn (Postfix) with ESMTP id C2371AAF685; Tue, 17 Dec 2019 09:47:36 +0800 (CST) X-Virus-Scanned: amavisd-new at proxy06.sjtu.edu.cn Received: from proxy06.sjtu.edu.cn ([127.0.0.1]) by localhost (proxy06.sjtu.edu.cn [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TKMHw14B9r2v; Tue, 17 Dec 2019 09:47:36 +0800 (CST) Received: from DESKTOPJG33ADI (unknown [202.120.38.50]) by proxy06.sjtu.edu.cn (Postfix) with ESMTPA id AB0C1AAF682; Tue, 17 Dec 2019 09:47:29 +0800 (CST) From: "chenyt-sjtu" To: "'Russ Housley'" Cc: "'Stefan Santesson'" , "'Ben Kaduk'" , "'IETF PKIX'" , "'LAMPS WG'" , "'David Cooper'" , "'Stephen Farrell'" , , "'Roman D. Danyliw'" Date: Tue, 17 Dec 2019 09:47:21 +0800 Message-ID: <000601d5b47b$f4114fd0$dc33ef70$@sjtu.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdW0cCVsgkDVD4PSThWRcVBd2E2Cew== Content-Language: zh-cn Archived-At: X-Mailman-Approved-At: Tue, 17 Dec 2019 06:28:45 -0800 Subject: Re: [lamps] [Technical Errata Reported] RFC5280 (5938) 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, 17 Dec 2019 01:47:45 -0000 Russ, I agree. The goal of path validation is sufficiently clear; it is to = verify the=20 target key certificate, based on the public key of the trust anchor.=20 I'd still suggest that "the binding between a subject distinguished name = or=20 a subject alternative name and subject public key" needs be changed to=20 "the binding between a subject distinguished name and/or a subject = alternative=20 name and subject public key". It helps the readers understand the fact, = i.e., everything in the certificate, if present, can be trusted after a path = validation. Regards, Yuting -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Russ Housley =20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2019=E5=B9=B412=E6=9C=8817=E6=97=A5 4:08 =E6=94=B6=E4=BB=B6=E4=BA=BA: chenyt-sjtu =E6=8A=84=E9=80=81: Stefan Santesson ; Ben Kaduk = ; IETF PKIX ; LAMPS WG ; = David Cooper ; Stephen Farrell = ; wpolk@nist.gov; Roman D. Danyliw = =E4=B8=BB=E9=A2=98: Re: [Technical Errata Reported] RFC5280 (5938) Yuting: You need to perform path validation to a trust anchor, and then you can = trust the binding of the subject public key to any or all of the names = in the certificate. Russ > On Dec 16, 2019, at 7:31 AM, chenyt-sjtu wrote: >=20 > Thank you, Stefan. >=20 > It seems that a path validation may not necessarily bind the subject=20 > public key and the subject DN and/or the subjectAltName extension. > I really suggest that the text can be tweaked for the right thing, :-) >=20 > Yuting >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Stefan Santesson > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2019=E5=B9=B412=E6=9C=8816=E6=97=A5 17:59 > =E6=94=B6=E4=BB=B6=E4=BA=BA: chenyt-sjtu ; = 'Benjamin Kaduk'=20 > > =E6=8A=84=E9=80=81: 'Russ Housley' ; 'IETF PKIX' = > ; 'LAMPS WG' ; 'David Cooper'=20 > ; 'Stephen Farrell'=20 > ; wpolk@nist.gov; 'Roman D. Danyliw'=20 > ; 'RFC Editor' > =E4=B8=BB=E9=A2=98: Re: [Technical Errata Reported] RFC5280 (5938) >=20 > Yuting, >=20 > There is nothing you must verify. > If you trust the CA, you trust the CA to provide accurate information = about the subject. > You can safely ignore name information that is not relevant for you. >=20 >=20 > Stefan Santesson >=20 > =EF=BB=BFOn 2019-12-16, 01:42, "chenyt-sjtu" = wrote: >=20 > I'm still curious of path validation. >=20 > When we have a certificate with a subject DN and a subjectAltName, = what should=20 > be "verified"? Is it the binding between the public key and (the = subject DN and the=20 > subjectAltName)? Or it will be fine if we just need to bind the key = to the subject DN.=20 > The validation results can be different when we have some bogus = certificates. >=20 > Regards, > Yuting >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Stefan Santesson =20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2019=E5=B9=B412=E6=9C=8816=E6=97=A5 4:26 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Benjamin Kaduk > =E6=8A=84=E9=80=81: Russ Housley ; IETF PKIX = ; LAMPS WG ; David Cooper = ; Stephen Farrell ; = wpolk@nist.gov; Roman D. Danyliw ; chenyt@sjtu.edu.cn; RFC = Editor > =E4=B8=BB=E9=A2=98: Re: [Technical Errata Reported] RFC5280 (5938) >=20 > So I have no objection either. Technically you are right of course. >=20 > My only point is that if you would pick any standards document of = size apart to this level, you would probably come up with a large number = of possible editorial erratas. > But again. There is nothing wrong with the suggested edit. >=20 >=20 > Stefan Santesson >=20 > =EF=BB=BFOn 2019-12-15, 19:49, "Benjamin Kaduk" = wrote: >=20 > While I agree that the original text is fine in isolation, I = think the > document looks internally inconsistent when it says = "Certification path > processing verifies the binding between the subject = distinguished name > and/or subject alternative name and subject public key" in = Section 6 and > then "The primary goal of path validation is to verify the = binding between > a subject distinguished name or a subject alternative name and = subject > public key, as represented in the target certificate, based on = the public > key of the trust anchor" in Section 6.1. A reader would = rightly ask "what > is different?" between these two situations with one using = "subject > distinguished name and/or subject alternative name" and the = other using > "subject distinguished name or a subject alternative name". >=20 > Resolving this sort of minor discrepancy even when the meaning = is clear is > exactly what editorial errata are for. >=20 > -Ben >=20 > On Sun, Dec 15, 2019 at 05:38:12PM +0100, Stefan Santesson = wrote: >> I agree. >>=20 >> I don't think this type of nit picking belongs in an errata. >> The concept of biding a key to information in a certificate is well = understood. >>=20 >> Stefan Santesson >>=20 >> =EF=BB=BFOn 2019-12-15, 17:23, "Russ Housley" = wrote: >>=20 >> I think the original text is fine. It is not an exclusive or. >>=20 >> Russ >>=20 >>> On Dec 14, 2019, at 10:00 PM, Benjamin Kaduk wrote: >>>=20 >>> I think this looks pretty straightforward (though I'd tweak the=20 >>> "corrected text" to do the right thing with the automated tooling=20 >>> and possibly the "notes" as well before verifying). Any thoughts=20 >>> for or against "verified"/"editorial"? >>>=20 >>> Thanks, >>>=20 >>> Ben >>>=20 >>> On Sat, Dec 14, 2019 at 06:34:19PM -0800, RFC Errata System wrote: >>>> The following errata report has been submitted for RFC5280,=20 >>>> "Internet X.509 Public Key Infrastructure Certificate and = Certificate Revocation List (CRL) Profile". >>>>=20 >>>> -------------------------------------- >>>> You may review the report below and at: >>>> https://www.rfc-editor.org/errata/eid5938 >>>>=20 >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Yuting Chen >>>>=20 >>>> Section: 6.1 >>>>=20 >>>> Original Text >>>> ------------- >>>> The primary goal of path validation is to verify the binding=20 >>>> between a subject distinguished name or a subject alternative name=20 >>>> and subject public key, as represented in the target certificate,=20 >>>> based on the public key of the trust anchor. In most cases, the=20 >>>> target >>>>=20 >>>> Corrected Text >>>> -------------- >>>> The primary goal of path validation is to verify the binding=20 >>>> between >>>> | a subject distinguished name and/or a subject alternative name=20 >>>> | and >>>> subject public key, as represented in the target certificate, based = >>>> on the public key of the trust anchor. In most cases, the target >>>>=20 >>>> Notes >>>> ----- >>>> The correction conforms to the first paragraph, Sec. 6,=20 >>>> "Certification path processing verifies the binding between the=20 >>>> subject distinguished name and/or subject alternative name and = subject public key." >>>>=20 >>>> In addition, it is not very clear in RFC 5280, given a certificate=20 >>>> with a non-empty subject DN and an SAN extension instance (critical = >>>> or non-critical), which one (the subject DN, the SAN extension, or = >>>> they >>>> both) should be bound to the subject public key during path = validation. >>>> More explanations are needed. >>>>=20 >>>> Instructions: >>>> ------------- >>>> This erratum is currently posted as "Reported". If necessary,=20 >>>> please use "Reply All" to discuss whether it should be verified or=20 >>>> rejected. When a decision is reached, the verifying party can log=20 >>>> in to change the status and edit the report, if necessary. >>>>=20 >>>> -------------------------------------- >>>> RFC5280 (draft-ietf-pkix-rfc3280bis-11) >>>> -------------------------------------- >>>> Title : Internet X.509 Public Key Infrastructure = Certificate and Certificate Revocation List (CRL) Profile >>>> Publication Date : May 2008 >>>> Author(s) : D. Cooper, S. Santesson, S. Farrell, S. = Boeyen, R. Housley, W. Polk >>>> Category : PROPOSED STANDARD >>>> Source : Public-Key Infrastructure (X.509) >>>> Area : Security >>>> Stream : IETF >>>> Verifying Party : IESG >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 >=20 >=20 From y-iida@secom.co.jp Mon Dec 16 19:16:10 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 7DD56120041 for ; Mon, 16 Dec 2019 19:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 olJxl4e_xGr7 for ; Mon, 16 Dec 2019 19:16:08 -0800 (PST) Received: from mx05.secom.co.jp (mx05.secom.co.jp [61.114.178.248]) by ietfa.amsl.com (Postfix) with ESMTP id DC5BF12004A for ; Mon, 16 Dec 2019 19:16:07 -0800 (PST) Received: from unknown (HELO exmrp1_ext.intra.secom.co.jp) ([172.21.1.72]) by mx05.secom.co.jp with ESMTP; 17 Dec 2019 12:16:06 +0900 Received: from ex12.secom.corp ([10.4.171.74]) by exmrp1.intra.secom.co.jp with ESMTP; 17 Dec 2019 12:16:06 +0900 Received: from EX01.SECOM.corp (10.4.171.61) by EX12.SECOM.corp (10.4.171.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1466.3; Tue, 17 Dec 2019 12:16:06 +0900 Received: from EX01.SECOM.corp ([192.168.254.61]) by EX01.SECOM.corp ([10.4.171.61]) with mapi id 15.01.1466.008; Tue, 17 Dec 2019 12:16:06 +0900 From: =?utf-8?B?6aOv55SwIOe+qeaclw==?= To: =?utf-8?B?6aOv55SwIOe+qeaclw==?= CC: Phillip Hallam-Baker , Benjamin Kaduk , SPASM , Rob Stradling , Jacob Hoffman-Andrews , Roman Danyliw , "housley@vigilsec.com" , Tim Hollebeek Thread-Topic: [Editorial Errata Reported] RFC8659 (5934) Thread-Index: AQHVtHT/X9m8NcGv7UOeBOcNyfcpO6e9AASAgACnRWA= Date: Tue, 17 Dec 2019 03:16:06 +0000 Message-ID: <3e118af6b7d74fde871175286b1d8205@secom.co.jp> References: <20191212024322.9DA55F4071A@rfc-editor.org> <20191217005724.GW81833@kduck.mit.edu> In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.32.250] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 17 Dec 2019 06:28:45 -0800 Subject: Re: [lamps] [Editorial Errata Reported] RFC8659 (5934) 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, 17 Dec 2019 03:20:18 -0000 SGVsbG8gcGVvcGxlLg0KIkNvcnJlY3RlZCBUZXh0IiBjb3VsZCBiZSBzaW1wbHk6DQogIEl0IGFs c28gYWxsb3dzIGh5cGhlbnMgaW4gcGFyYW1ldGVyIHRhZ3MuDQotLQ0KICBpaWRhDQoNCj4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IFBoaWxsaXAgSGFsbGFtLUJha2VyIFttYWls dG86cGhpbGxAaGFsbGFtYmFrZXIuY29tXQ0KPlNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDE3LCAy MDE5IDExOjE2IEFNDQo+VG86IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1Pg0KPkNjOiBT UEFTTSA8c3Bhc21AaWV0Zi5vcmc+OyBSb2IgU3RyYWRsaW5nIDxyb2JAc2VjdGlnby5jb20+OyBK YWNvYg0KPkhvZmZtYW4tQW5kcmV3cyA8anNoYUBsZXRzZW5jcnlwdC5vcmc+OyBSb21hbiBEYW55 bGl3IDxyZGRAY2VydC5vcmc+Ow0KPmhvdXNsZXlAdmlnaWxzZWMuY29tOyBUaW0gSG9sbGViZWVr IDx0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbT47IOmjr+eUsCDnvqkNCj7mnJcgPHktaWlkYUBz ZWNvbS5jby5qcD4NCj5TdWJqZWN0OiBSZTogW0VkaXRvcmlhbCBFcnJhdGEgUmVwb3J0ZWRdIFJG Qzg2NTkgKDU5MzQpDQo+DQo+SXQgc2VlbXMgdG8gYmUgYSBjb25mdXNpb24gaW4gUkZDNjg0NC4g VGhlIEFCTkYgaXMgYWN0dWFsbHkgcmVmZXJyaW5nIHRvDQo+dGhlIHZhbHVlIHNlY3Rpb24gb2Yg dGhlIENBQSBmaWVsZCB3aGljaCBjb250YWlucyBhIHNlcXVlbmNlIG9mIHRhZy12YWx1ZQ0KPnBy b2R1Y3Rpb25zLiBUaG9zZSB0YWdzIGJlaW5nIGRpc3RpbmN0IGZyb20gdGhlIENBQSB0YWdzLg0K Pg0KPlRoZSBDQUEgaXNzdWUgcHJvcGVydHkgdmFsdWUgaGFzIHRoZSBmb2xsb3dpbmcgc3ViLXN5 bnRheCAoc3BlY2lmaWVkDQo+ICAgaW4gQUJORiBhcyBwZXIgW1JGQzUyMzQgPGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjM0PiBdKS4NCj4NCj4NCj4NCj4NCj5PbiBNb24sIERlYyAx NiwgMjAxOSBhdCA3OjU3IFBNIEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1DQo+PG1haWx0 bzprYWR1a0BtaXQuZWR1PiA+IHdyb3RlOg0KPg0KPg0KPglJIHRoaW5rIEknbSBmYWlsaW5nIHRv IGZpbmQgYW4gQUJORiBjb25zdHJ1Y3Rpb24gdGhhdCBkaWZmZXJzIGZyb20NCj42ODQ0IHRvDQo+ CTg2NTkgaW4gdGhlIGluZGljYXRlZCBtYW5uZXIgLi4uIGhlbHA/DQo+DQo+CS1CZW4NCj4NCj4J T24gV2VkLCBEZWMgMTEsIDIwMTkgYXQgMDY6NDM6MjJQTSAtMDgwMCwgUkZDIEVycmF0YSBTeXN0 ZW0gd3JvdGU6DQo+CT4gVGhlIGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1p dHRlZCBmb3IgUkZDODY1OSwNCj4JPiAiRE5TIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEF1dGhv cml6YXRpb24gKENBQSkgUmVzb3VyY2UNCj5SZWNvcmQiLg0KPgk+DQo+CT4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4JPiBZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0 IGJlbG93IGFuZCBhdDoNCj4JPiBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGEvZWlk NTkzNA0KPgk+DQo+CT4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4J PiBUeXBlOiBFZGl0b3JpYWwNCj4JPiBSZXBvcnRlZCBieTogSUlEQSBZb3NpYWtpIDx5LWlpZGFA c2Vjb20uY28uanANCj48bWFpbHRvOnktaWlkYUBzZWNvbS5jby5qcD4gPg0KPgk+DQo+CT4gU2Vj dGlvbjogNw0KPgk+DQo+CT4gT3JpZ2luYWwgVGV4dA0KPgk+IC0tLS0tLS0tLS0tLS0NCj4JPiBJ dCBhbHNvIGFsbG93cyBoeXBoZW5zIGluIFByb3BlcnR5IFRhZ3MuDQo+CT4NCj4JPiBDb3JyZWN0 ZWQgVGV4dA0KPgk+IC0tLS0tLS0tLS0tLS0tDQo+CT4gSXQgYWxzbyBhbGxvd3MgaHlwaGVucyBp biB0YWdzIG9mIFByb3BlcnR5IFZhbHVlIG9mDQo+CT4gaXNzdWUgYW5kIGlzc3Vld2lsZCBQcm9w ZXJ0eSBUYWdzLg0KPgk+DQo+CT4gTm90ZXMNCj4JPiAtLS0tLQ0KPgk+IFN1YnNlY3Rpb24gNC4x IGV4cGxpY2l0bHkgcHJvaGliaXRzIGh5cGhlbnMgaW4gUHJvcGVydHkgVGFncy4NCj4JPiBXaGls ZSBvYnNvbGV0ZWQgUkZDIDY4NDQgZGlkIG5vdCBhbGxvdyBoeXBoZW5zIGluIHRhZ3Mgb2YgUHJv cGVydHkNCj5WYWx1ZSBvZiBpc3N1ZSBhbmQgaXNzdWV3aWxkIFByb3BlcnR5IFRhZ3MsIG5ldyBB Qk5GIGRlZmluaXRpb24gaW4gc3Vic2VjdGlvbg0KPjQuMiBhbGxvd3MgdGhlbS4NCj4JPg0KPgk+ IEluc3RydWN0aW9uczoNCj4JPiAtLS0tLS0tLS0tLS0tDQo+CT4gVGhpcyBlcnJhdHVtIGlzIGN1 cnJlbnRseSBwb3N0ZWQgYXMgIlJlcG9ydGVkIi4gSWYgbmVjZXNzYXJ5LA0KPnBsZWFzZQ0KPgk+ IHVzZSAiUmVwbHkgQWxsIiB0byBkaXNjdXNzIHdoZXRoZXIgaXQgc2hvdWxkIGJlIHZlcmlmaWVk IG9yDQo+CT4gcmVqZWN0ZWQuIFdoZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5 aW5nIHBhcnR5DQo+CT4gY2FuIGxvZyBpbiB0byBjaGFuZ2UgdGhlIHN0YXR1cyBhbmQgZWRpdCB0 aGUgcmVwb3J0LCBpZiBuZWNlc3NhcnkuDQo+CT4NCj4JPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPgk+IFJGQzg2NTkgKGRyYWZ0LWlldGYtbGFtcHMtcmZjNjg0NGJp cy0wNykNCj4JPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPgk+IFRp dGxlICAgICAgICAgICAgICAgOiBETlMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgQXV0aG9yaXph dGlvbg0KPihDQUEpIFJlc291cmNlIFJlY29yZA0KPgk+IFB1YmxpY2F0aW9uIERhdGUgICAgOiBO b3ZlbWJlciAyMDE5DQo+CT4gQXV0aG9yKHMpICAgICAgICAgICA6IFAuIEhhbGxhbS1CYWtlciwg Ui4gU3RyYWRsaW5nLCBKLg0KPkhvZmZtYW4tQW5kcmV3cw0KPgk+IENhdGVnb3J5ICAgICAgICAg ICAgOiBQUk9QT1NFRCBTVEFOREFSRA0KPgk+IFNvdXJjZSAgICAgICAgICAgICAgOiBMaW1pdGVk IEFkZGl0aW9uYWwgTWVjaGFuaXNtcyBmb3IgUEtJWCBhbmQNCj5TTUlNRQ0KPgk+IEFyZWEgICAg ICAgICAgICAgICAgOiBTZWN1cml0eQ0KPgk+IFN0cmVhbSAgICAgICAgICAgICAgOiBJRVRGDQo+ CT4gVmVyaWZ5aW5nIFBhcnR5ICAgICA6IElFU0cNCj4NCg0K From nobody Tue Dec 17 06:42: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 2B27912084F; Tue, 17 Dec 2019 06:40:34 -0800 (PST) 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 rMmOf6dKZrOw; Tue, 17 Dec 2019 06:40:32 -0800 (PST) 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 3D1FF120848; Tue, 17 Dec 2019 06:40:31 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xBHEdK9j026800; Tue, 17 Dec 2019 14:40:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=9c5nvHcQ6LoNaLs/I5Sx0mhnw954zW8NpKOpwKwK8zM=; b=Ym7yFL2MBYyzQSv4nmMcJW1TYYEO5gNwKtAsaF3mXQAzB8jFLCej3EJkAdFQoZalKFDp VmRQ01M1tdsinbWMZq+rUz+Fht7L0fKTihwHLEWrWqKQRlvalQ7LiZNhjfzuoT964TjE QSnr/SQPfHViAdfZSl1LLiuziXMbDsoWK1QAaI/7i0btGvZ0c+gg1GZGIgKKVQmo/FO6 xKfHFWPPH1iRHnBOtWPwhf6+/L5cc5Sh3wLnK2Y5QpgVZXoNMjjss4J3R8conx+icDl8 U7dyO3LuHWa5v6OyWHzc0OllSze6aPOu8nnc7UEoE4qB/fTyLPVFUELTsGLDxQbhUahR aA== Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2wvs1d4k3h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Dec 2019 14:40:08 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xBHEWh6c028101; Tue, 17 Dec 2019 09:40:07 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint4.akamai.com with ESMTP id 2wvuy4x3pr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 17 Dec 2019 09:40:04 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Dec 2019 09:39:33 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Tue, 17 Dec 2019 09:39:32 -0500 From: "Salz, Rich" To: chenyt-sjtu , 'Stefan Santesson' , 'Benjamin Kaduk' CC: "'Roman D. Danyliw'" , 'David Cooper' , "wpolk@nist.gov" , 'Russ Housley' , 'LAMPS WG' , 'IETF PKIX' , 'RFC Editor' , 'Stephen Farrell' Thread-Topic: [lamps] [Technical Errata Reported] RFC5280 (5938) Thread-Index: AdW0CW+sGnAhp8BniUO0RLXW31zwogA3lu0A Date: Tue, 17 Dec 2019 14:39:32 +0000 Message-ID: References: <000001d5b40c$b29da220$17d8e660$@sjtu.edu.cn> In-Reply-To: <000001d5b40c$b29da220$17d8e660$@sjtu.edu.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.115.193] 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-12-17_02:, , 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=797 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912170123 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-17_02:2019-12-17,2019-12-17 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 bulkscore=0 clxscore=1011 adultscore=0 spamscore=0 phishscore=0 lowpriorityscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=767 suspectscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912170123 Archived-At: X-Mailman-Approved-At: Tue, 17 Dec 2019 06:42:50 -0800 Subject: Re: [lamps] [Technical Errata Reported] RFC5280 (5938) 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, 17 Dec 2019 14:40:34 -0000 VGhlIENBLCB3aGVuIGl0IHNpZ25zIGEgY2VydGlmaWNhdGUsIGlzIHNheWluZyB0aGF0IGFsbCBv ZiB0aGUgaW5mb3JtYXRpb24gaW4gdGhlIGNlcnRpZmljYXRlIGlzIGNvcnJlY3QuDQoNCkJ5IGNv bnZlbnRpb24sIHdlIHRhbGsgYWJvdXQgImJpbmRpbmciIHRoZSBrZXkgdG8gdGhlIFN1YmplY3RE TiwgYnV0IGFsbCBvZiB0aGUgaW5mb3JtYXRpb24gLS0gbm90QWZ0ZXIsIHN1YmplY3RBbHROYW1l LCBldGMgLS0gYXJlIHZhbGlkLCBpZiB5b3UgdHJ1c3QgdGhlIENBIChvciBoYXZlIGEgcGF0aCB0 byBhIGNoYWluIHVwIHRvIGEgQ0EgdGhhdCB5b3UgZG8gdHJ1c3QpLiBXZSBkb24ndCB0YWxrIGFi b3V0ICJiaW5kaW5nIiB0aGUga2V5IHRvIGl0cyB2YWxpZGl0eSBwZXJpb2QuDQoNCg0KDQo= From nobody Tue Dec 17 10:52: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 DFB2B1208C1; Tue, 17 Dec 2019 10:52:16 -0800 (PST) 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 5IMr0vevHG8c; Tue, 17 Dec 2019 10:52:13 -0800 (PST) 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 41E69120870; Tue, 17 Dec 2019 10:51:11 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CD1BA38981; Tue, 17 Dec 2019 13:51:06 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B4BD2D36; Tue, 17 Dec 2019 13:51:09 -0500 (EST) From: Michael Richardson To: "spasm\@ietf.org" , EMU WG In-Reply-To: References: 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] [Emu] EAP/EMU recommendations for client cert validation logic 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, 17 Dec 2019 18:52:17 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Owen Friel (ofriel) wrote: > =E2=80=9CBackground: > a) the current practice in TLS-based EAP methods is to use certificat= es with > "id-kp-serverAuth" OID set for Extended Key Usage. > b) many supplicants check for this OID, and refuse to perform authent= ication > if it is missing > c) supplicants do not check DNS names or any other field in the certi= ficates > d) as a result of this lack of verification, supplicants ship with al= l known > CAs disabled for TLS-based EAP methods=E2=80=9D > The key consideration is that RFCs that recommend cert fields for EAP= servers > that clients should check for are not currently issued by public CAs,= and in > some instances (e.g. SSID) ownership can often not be proven by CAs. > For example: > https://tools.ietf.org/html/rfc4334#section-2 id-kp-eapOverLAN EKU > https://tools.ietf.org/html/rfc4334#section-3 id-pe-wlanSSID > https://tools.ietf.org/html/rfc7585#section-2.2 NAIRealm > If an EAP server operator wants to use a public CA identity cert on t= heir EAP > server, what recommendations should we give to EAP clients so that the > supplicant code can handle public or private CA issued EAP server ide= ntity in > a secure a fashion as possible? > If at some point in the future, public CAs are willing to issue certs= with > some or all of the above fields, then what is the migration plan, wha= t do we > tell EAP clients to do now, and how to they migrate their verification > logic? I think that this is a really big if. So, I want to change the question, which I think can make this problem a lot easier to get traction on. } If at some point in the future, there is one or more well-known trust } anchors that (IoT?) devices can build in, and these CAs are willing to is= sue } certs with some or all of the above fields, can we design a transition } process from one-touch provisioned private CAs to a common DN+extension } based common anchor? > The ideal experience would be along these lines for a client with rea= l user > interactions: 1> - client connects to an EAP server 2> - client prompts user for userId + realm and password 3> - client verifies server cert has id-kp-eapOverLAN set 4> - NAIRealm in cert matches user=E2=80=99s realm 5> - verify the cert signing chain <2> and <3> seem in the wrong order. If the certificate has NAIRealm, why would we need to ask the user for the realm? Wouldn't we instead ask them: "What is your userID in REALM FOO" > The reality today is that if the server cert is issued by a public CA= , then > all that client can really check is: 1> - id-kp-serverAuth is set 2> - dNSName in cert matches user=E2=80=99s realm 3> - verify the cert signing chain I think that <3> happens first, and the connection is dropped if it does not validate. Maybe you aren't expressing an order here at all. > It seems like logic should be something like: > - recommend EAP operators with private CA issued certs on their EAP s= ervers > set id-kp-eapOverLAN and NAIRealm set > - recommend EAP operators using public CAs get EAP server certs with > id-kp-serverAuth and dNSName set > - recommend clients enable trust in public CAs > - recommend clients implement different cert verification logic depen= ding on > whether the EAP server cert is issued by a public CA or private CA Would setting dNSNAME on private CA issued certs reduce complexity? > - as a longer term goal see if public CAs will issue id-kp-eapOverLAN= and > NAIRealm. Although of course if some were to start doing this, then t= here is > a migration challenge, and clients cannot make a hard check for these= values > against all public CAs. This doesn=E2=80=99t really seem practical in= the near term > at all. Trust NAIRealm extension only if id-kp-eapOverLAN is set. having implemented the dNSNAME code path, it seems like there is no point in implementing the other path. > Note that for an IoT device, there is some work to do to define how t= o e.g. > extend the RFC8366 so that it can specify the dNSName that devices sh= ould > check for when verifying EAP identity where they EAP server uses a pu= blic CA. > Some related options are outlined in > https://tools.ietf.org/html/draft-friel-anima-brski-cloud-01. Owen and I have wrangled about the topic of how exactly the pinning is done. The above document does not really outline the problem space in my opinion, focusing on other dimensions of the process. The requirements that Owen has expressed to me are: 1) 8366bis must be able to pin CA + DN/SAN, such that the operator can ro= tate their public key without invalidating the voucher. (possibly including changing public key algorithm) 2) 8366bis must be able to pin (?-public key), such that the operator can switch (public) CAs without invalidating the voucher. There might be a (3) that I can't think of right now. But, if these two requirements seem to contradict each other, then high-five to you, you were paying attention :-) =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl35I50ACgkQgItw+93Q 3WUaOwf/a0fRfUVp+1o96EyuuMGwppJVPRU17Au4Rnayq1+FoPiCWGkm9MdBm4Bt agzlJUsKBb1mJZ//prb+L4DR6l3EodggsiDP2mfztKdIc0HS3TaHUa/fheE4g2h8 abf9CEYjDg4a4Kj6o3oZq78vXoSC4vtN+xRV+bCKuiMPIw6NkfVoatnT2+VPL3mg ZtIhu3ZlPZM60gK+VyPdvlLpt4IJHLQPHk3QPMCso6suKBz2L7/9PEpGO/dDOYVU 47Ic2CeHaNNzRQ0sQhuBwJsPdowv9Hc5awc4X+lcaHfHpLESbIeEDS8zOF+Gokyn vsIz8sDsHfnTh8alxrRO8zGgO7sx+A== =Iskc -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 17 11:07:39 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 DCC361208CC; Tue, 17 Dec 2019 11:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Wl-5gXamTRKr; Tue, 17 Dec 2019 11:07:30 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D75D1208C9; Tue, 17 Dec 2019 11:07:22 -0800 (PST) Received: from [192.168.20.177] (206-248-138-162.dsl.teksavvy.com [206.248.138.162]) by mail.networkradius.com (Postfix) with ESMTPSA id E450A64E; Tue, 17 Dec 2019 19:07:16 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Alan DeKok In-Reply-To: <6719.1576608669@localhost> Date: Tue, 17 Dec 2019 14:07:15 -0500 Cc: "spasm@ietf.org" , EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: <83F3F036-4D6A-4899-AC02-FAEE7685D8C9@deployingradius.com> References: <6719.1576608669@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic 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, 17 Dec 2019 19:07:33 -0000 On Dec 17, 2019, at 1:51 PM, Michael Richardson = wrote: > } If at some point in the future, there is one or more well-known = trust > } anchors that (IoT?) devices can build in, and these CAs are willing = to issue > } certs with some or all of the above fields, can we design a = transition > } process from one-touch provisioned private CAs to a common = DN+extension > } based common anchor? I hope so. My $0.02 is that configuration belongs in a machine-readable format, = not in fields in a GUI. i.e. fields in a cert. Once we have a machine-readable format, transition plans become = simpler, because we have a better handle on what systems are doing. >> The ideal experience would be along these lines for a client with = real user >> interactions: >=20 > 1> - client connects to an EAP server > 2> - client prompts user for userId + realm and password > 3> - client verifies server cert has id-kp-eapOverLAN set > 4> - NAIRealm in cert matches user=E2=80=99s realm > 5> - verify the cert signing chain >=20 > <2> and <3> seem in the wrong order. > If the certificate has NAIRealm, why would we need to ask the user for = the > realm? Wouldn't we instead ask them: "What is your userID in REALM = FOO" The server certificate is presented before the user credentials are = sent (PEAP / TTLS). So the client can automatically derive the = NAIRealm. The issue is that users are slow. It's bad to have the EAP session = hang while the user enters "name / password" in a GUI. That's the only = real reason why name / password is requested before the EAP session = starts. >> The reality today is that if the server cert is issued by a public = CA, then >> all that client can really check is: >=20 > 1> - id-kp-serverAuth is set > 2> - dNSName in cert matches user=E2=80=99s realm > 3> - verify the cert signing chain >=20 > I think that <3> happens first, and the connection is dropped if it = does not > validate. Maybe you aren't expressing an order here at all. The only reason to order these checks is cost. i.e. simple checks = should run first, before complex checks. >> It seems like logic should be something like: >=20 >> - recommend EAP operators with private CA issued certs on their EAP = servers >> set id-kp-eapOverLAN and NAIRealm set >> - recommend EAP operators using public CAs get EAP server certs with >> id-kp-serverAuth and dNSName set >> - recommend clients enable trust in public CAs >> - recommend clients implement different cert verification logic = depending on >> whether the EAP server cert is issued by a public CA or private CA >=20 > Would setting dNSNAME on private CA issued certs reduce complexity? No. The DNS names at at least the realm names (example.com), but they = could be more (radius.example.com). There's no good way to automatically derive the NAIrealm from a DNS = name. Given both, you can check if they're compatible. But that's it. >> - as a longer term goal see if public CAs will issue id-kp-eapOverLAN = and >> NAIRealm. Although of course if some were to start doing this, then = there is >> a migration challenge, and clients cannot make a hard check for these = values >> against all public CAs. This doesn=E2=80=99t really seem practical in = the near term >> at all. >=20 > Trust NAIRealm extension only if id-kp-eapOverLAN is set. > having implemented the dNSNAME code path, it seems like there is no = point in > implementing the other path. The NAIRealm tells you exactly which Realm you're using. The DNSName = path doesn't. The NAIRealm can be used to skip the step where the user is prompted = for the realm. Alan DeKok. From nobody Tue Dec 17 18:20:10 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 B1D45120090; Tue, 17 Dec 2019 17:50:31 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 khydXcnPcj0m; Tue, 17 Dec 2019 17:50:29 -0800 (PST) Received: from smtp180.sjtu.edu.cn (smtp180.sjtu.edu.cn [202.120.2.180]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 063A8120073; Tue, 17 Dec 2019 17:50:28 -0800 (PST) Received: from proxy06.sjtu.edu.cn (smtp188.sjtu.edu.cn [202.120.2.188]) by smtp180.sjtu.edu.cn (Postfix) with ESMTPS id BC3DF100AFC25; Wed, 18 Dec 2019 09:50:24 +0800 (CST) Received: from localhost (localhost.localdomain [127.0.0.1]) by proxy06.sjtu.edu.cn (Postfix) with ESMTP id AD5103B1AE48; Wed, 18 Dec 2019 09:50:24 +0800 (CST) X-Virus-Scanned: amavisd-new at proxy06.sjtu.edu.cn Received: from proxy06.sjtu.edu.cn ([127.0.0.1]) by localhost (proxy06.sjtu.edu.cn [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id n3uA4tbeu7TI; Wed, 18 Dec 2019 09:50:24 +0800 (CST) Received: from DESKTOPJG33ADI (unknown [202.120.38.50]) by proxy06.sjtu.edu.cn (Postfix) with ESMTPA id 2F092AAF686; Wed, 18 Dec 2019 09:50:16 +0800 (CST) From: "chenyt-sjtu" To: "'Salz, Rich'" , "'Stefan Santesson'" , "'Benjamin Kaduk'" Cc: "'Roman D. Danyliw'" , "'David Cooper'" , , "'Russ Housley'" , "'LAMPS WG'" , "'IETF PKIX'" , "'RFC Editor'" , "'Stephen Farrell'" Date: Wed, 18 Dec 2019 09:50:09 +0800 Message-ID: <000001d5b545$836c4760$8a44d620$@sjtu.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdW1PnA70HsspeCJQj2yNd0wBYvY2A== Content-Language: zh-cn Archived-At: X-Mailman-Approved-At: Tue, 17 Dec 2019 18:20:09 -0800 Subject: Re: [lamps] [Technical Errata Reported] RFC5280 (5938) 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, 18 Dec 2019 01:50:32 -0000 Hi, Rich, Thank you for explaining the word "binding". The validity and the = subjectAltName can be trusted if the certificate can pass "path validation", right?=20 Binding is not a strict word. I found that public key certificates are = defined as data=20 structures that "bind" public key values to subjects (Sec. 3.1). Should = the "binding=20 between a subject and a subject key", rather than the "binding between a = subject=20 distinguished name or a subject alternative name and subject public key" = (Sec. 6.1),=20 get verified in a path validation? Yuting -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Salz, Rich =20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2019=E5=B9=B412=E6=9C=8817=E6=97=A5 22:40 =E6=94=B6=E4=BB=B6=E4=BA=BA: chenyt-sjtu ; 'Stefan = Santesson' ; 'Benjamin Kaduk' =E6=8A=84=E9=80=81: 'Roman D. Danyliw' ; 'David Cooper' = ; wpolk@nist.gov; 'Russ Housley' = ; 'LAMPS WG' ; 'IETF PKIX' = ; 'RFC Editor' ; 'Stephen = Farrell' =E4=B8=BB=E9=A2=98: Re: [lamps] [Technical Errata Reported] RFC5280 = (5938) The CA, when it signs a certificate, is saying that all of the = information in the certificate is correct. By convention, we talk about "binding" the key to the SubjectDN, but all = of the information -- notAfter, subjectAltName, etc -- are valid, if you = trust the CA (or have a path to a chain up to a CA that you do trust). = We don't talk about "binding" the key to its validity period. From nobody Wed Dec 18 00:33:53 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 E41DF120105 for ; Wed, 18 Dec 2019 00:33:52 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, 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 Nh3BimPTs9vN for ; Wed, 18 Dec 2019 00:33:50 -0800 (PST) Received: from smtp2.outgoing.loopia.se (smtp2.outgoing.loopia.se [93.188.3.37]) (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 C914E1200DF for ; Wed, 18 Dec 2019 00:33:49 -0800 (PST) Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id B8D462E58F12 for ; Wed, 18 Dec 2019 09:33:43 +0100 (CET) Received: from s645.loopia.se (unknown [172.22.191.5]) by s807.loopia.se (Postfix) with ESMTP id 98CE02E275E9; Wed, 18 Dec 2019 09:33:43 +0100 (CET) Received: from s475.loopia.se (unknown [172.22.191.6]) by s645.loopia.se (Postfix) with ESMTP id 6C0B7156E521; Wed, 18 Dec 2019 09:33:43 +0100 (CET) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s645.loopia.se ([172.22.191.5]) by s475.loopia.se (s475.loopia.se [172.22.190.15]) (amavisd-new, port 10024) with UTF8LMTP id 7N6xK8veffLN; Wed, 18 Dec 2019 09:33:42 +0100 (CET) X-Loopia-Auth: user X-Loopia-User: mailstore2@aaa-sec.com X-Loopia-Originating-IP: IPv6:2001:6b0:7:1:25a0:2891:ac55:4c01 Received: from [193.10.0.161] (unknown [IPv6:2001:6b0:7:1:25a0:2891:ac55:4c01]) (Authenticated sender: mailstore2@aaa-sec.com) by s645.loopia.se (Postfix) with ESMTPSA id C6E28156E51E; Wed, 18 Dec 2019 09:33:41 +0100 (CET) User-Agent: Microsoft-MacOutlook/10.20.0.191208 Date: Wed, 18 Dec 2019 09:33:41 +0100 From: Stefan Santesson To: chenyt-sjtu , "'Salz, Rich'" , 'Benjamin Kaduk' CC: "'Roman D. Danyliw'" , 'David Cooper' , , 'Russ Housley' , 'LAMPS WG' , 'Stephen Farrell' Message-ID: <4E58770D-82A0-431D-9633-4D62BDA716C3@aaa-sec.com> Thread-Topic: [lamps] [Technical Errata Reported] RFC5280 (5938) References: <000001d5b545$836c4760$8a44d620$@sjtu.edu.cn> In-Reply-To: <000001d5b545$836c4760$8a44d620$@sjtu.edu.cn> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [lamps] [Technical Errata Reported] RFC5280 (5938) 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, 18 Dec 2019 08:33:53 -0000 Yuting, It seems that you are still stuck in backwards thinking, and I'm not sure I= can unstack you in a single sentence. We are trying to tell you that you don't verify the binding of a name as pa= rt of certificate validation. You perform certificate validation so you can trust the information in the = certificate. Stefan Santesson=20 =EF=BB=BFOn 2019-12-18, 02:50, "chenyt-sjtu" wrote: Hi, Rich, =20 Thank you for explaining the word "binding". The validity and the subje= ctAltName can be trusted if the certificate can pass "path validation", right?=20 =20 Binding is not a strict word. I found that public key certificates are = defined as data=20 structures that "bind" public key values to subjects (Sec. 3.1). Should= the "binding=20 between a subject and a subject key", rather than the "binding between = a subject=20 distinguished name or a subject alternative name and subject public key= " (Sec. 6.1),=20 get verified in a path validation? =20 Yuting =20 -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Salz, Rich =20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B412=E6=9C=8817=E6=97=A5 22:40 =E6=94=B6=E4=BB=B6=E4=BA=BA: chenyt-sjtu ; 'Stefan Santesson' ; 'Benjamin Kaduk' =E6=8A=84=E9=80=81: 'Roman D. Danyliw' ; 'David Cooper' ; wpolk@nist.gov; 'Russ Housley' ; 'LAMPS WG= ' ; 'IETF PKIX' ; 'RFC Editor' ; 'Stephen Farrell' =E4=B8=BB=E9=A2=98: Re: [lamps] [Technical Errata Reported] RFC5280 (5938) =20 The CA, when it signs a certificate, is saying that all of the informat= ion in the certificate is correct. =20 By convention, we talk about "binding" the key to the SubjectDN, but al= l of the information -- notAfter, subjectAltName, etc -- are valid, if you t= rust the CA (or have a path to a chain up to a CA that you do trust). We don= 't talk about "binding" the key to its validity period. =20 =20 =20 =20 =20 From nobody Wed Dec 18 06:57: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 AC08D120105; Wed, 18 Dec 2019 00:36:09 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 cQGWCPnQ3Isi; Wed, 18 Dec 2019 00:36:06 -0800 (PST) Received: from smtp180.sjtu.edu.cn (smtp180.sjtu.edu.cn [202.120.2.180]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE9B11200DF; Wed, 18 Dec 2019 00:36:04 -0800 (PST) Received: from proxy06.sjtu.edu.cn (smtp188.sjtu.edu.cn [202.120.2.188]) by smtp180.sjtu.edu.cn (Postfix) with ESMTPS id 43B8E100C7034; Wed, 18 Dec 2019 16:36:00 +0800 (CST) Received: from localhost (localhost.localdomain [127.0.0.1]) by proxy06.sjtu.edu.cn (Postfix) with ESMTP id 2F7CF3B1AE4C; Wed, 18 Dec 2019 16:36:00 +0800 (CST) X-Virus-Scanned: amavisd-new at proxy06.sjtu.edu.cn Received: from proxy06.sjtu.edu.cn ([127.0.0.1]) by localhost (proxy06.sjtu.edu.cn [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2trTbMlYAraW; Wed, 18 Dec 2019 16:36:00 +0800 (CST) Received: from DESKTOPJG33ADI (unknown [202.120.38.50]) by proxy06.sjtu.edu.cn (Postfix) with ESMTPA id 12639AAF685; Wed, 18 Dec 2019 16:35:51 +0800 (CST) From: "chenyt-sjtu" To: "'Salz, Rich'" , "'Stefan Santesson'" , "'Benjamin Kaduk'" Cc: "'Roman D. Danyliw'" , "'David Cooper'" , , "'Russ Housley'" , "'LAMPS WG'" , "'IETF PKIX'" , "'RFC Editor'" , "'Stephen Farrell'" Date: Wed, 18 Dec 2019 16:35:50 +0800 Message-ID: <000001d5b57e$2bfdfcb0$83f9f610$@sjtu.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdW1PnA70HsspeCJQj2yNd0wBYvY2AAO/Iqw Content-Language: zh-cn Archived-At: X-Mailman-Approved-At: Wed, 18 Dec 2019 06:57:26 -0800 Subject: Re: [lamps] [Technical Errata Reported] RFC5280 (5938) 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, 18 Dec 2019 08:36:10 -0000 Actually my concern is same as Ben's. There are three types of bindings=20 (between the key and the subject) in RFC 5280.=20 "binding between the public key material and the subject of the certificate" (Sec. 4.1.1.3), "binding between the subject=20 and public key" (Sec. 8), "binding between a key and certificate=20 subject" (Sec. 8), "binding between the subject distinguished name and/or=20 subject alternative name and subject public key" (Sec. 6) and=20 "binding between the name and subject public key" (Sec. 6.1), "binding between a subject distinguished name or a subject=20 alternative name and subject public key" (Sec. 6.1). If the three types of bindings are the same thing, it will be good if we = can=20 make them consistently presented.=20 If they are different, some explanations can be made in Section 6. = =20 should contain or . Then what are the other = bindings in=20 ? Are they remained unverified after a path validation? Regards, Yuting -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: chenyt-sjtu =20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2019=E5=B9=B412=E6=9C=8818=E6=97=A5 9:50 =E6=94=B6=E4=BB=B6=E4=BA=BA: 'Salz, Rich' ; 'Stefan = Santesson' ; 'Benjamin Kaduk' =E6=8A=84=E9=80=81: 'Roman D. Danyliw' ; 'David Cooper' = ; 'wpolk@nist.gov' ; 'Russ = Housley' ; 'LAMPS WG' ; 'IETF = PKIX' ; 'RFC Editor' ; = 'Stephen Farrell' =E4=B8=BB=E9=A2=98: Re: [lamps] [Technical Errata Reported] RFC5280 = (5938) Hi, Rich, Thank you for explaining the word "binding". The validity and the = subjectAltName can be trusted if the certificate can pass "path = validation", right?=20 Binding is not a strict word. I found that public key certificates are = defined as data structures that "bind" public key values to subjects = (Sec. 3.1). Should the "binding between a subject and a subject key", = rather than the "binding between a subject distinguished name or a = subject alternative name and subject public key" (Sec. 6.1), get = verified in a path validation? Yuting -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Salz, Rich =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2019=E5=B9=B412=E6=9C=8817=E6=97=A5 22:40 =E6=94=B6=E4=BB=B6=E4=BA=BA: chenyt-sjtu ; 'Stefan = Santesson' ; 'Benjamin Kaduk' =E6=8A=84=E9=80=81: 'Roman D. Danyliw' ; 'David Cooper' = ; wpolk@nist.gov; 'Russ Housley' = ; 'LAMPS WG' ; 'IETF PKIX' = ; 'RFC Editor' ; 'Stephen = Farrell' =E4=B8=BB=E9=A2=98: Re: [lamps] [Technical Errata Reported] RFC5280 = (5938) The CA, when it signs a certificate, is saying that all of the = information in the certificate is correct. By convention, we talk about "binding" the key to the SubjectDN, but all = of the information -- notAfter, subjectAltName, etc -- are valid, if you = trust the CA (or have a path to a chain up to a CA that you do trust). = We don't talk about "binding" the key to its validity period. From nobody Wed Dec 18 06:57:33 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 8EC0B12013C for ; Wed, 18 Dec 2019 03:08:33 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 CNCW9cisn_qA for ; Wed, 18 Dec 2019 03:08:31 -0800 (PST) Received: from smtp180.sjtu.edu.cn (smtp180.sjtu.edu.cn [202.120.2.180]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53F8F120059 for ; Wed, 18 Dec 2019 03:08:30 -0800 (PST) Received: from proxy06.sjtu.edu.cn (smtp188.sjtu.edu.cn [202.120.2.188]) by smtp180.sjtu.edu.cn (Postfix) with ESMTPS id EDEF3100AFC25; Wed, 18 Dec 2019 19:08:23 +0800 (CST) Received: from localhost (localhost.localdomain [127.0.0.1]) by proxy06.sjtu.edu.cn (Postfix) with ESMTP id E0482AAF682; Wed, 18 Dec 2019 19:08:23 +0800 (CST) X-Virus-Scanned: amavisd-new at proxy06.sjtu.edu.cn Received: from proxy06.sjtu.edu.cn ([127.0.0.1]) by localhost (proxy06.sjtu.edu.cn [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wrietJZj4Z0b; Wed, 18 Dec 2019 19:08:23 +0800 (CST) Received: from DESKTOPJG33ADI (unknown [202.120.38.50]) by proxy06.sjtu.edu.cn (Postfix) with ESMTPA id DBE4CAAF685; Wed, 18 Dec 2019 19:08:17 +0800 (CST) From: "chenyt-sjtu" To: "'Stefan Santesson'" , "'Salz, Rich'" , "'Benjamin Kaduk'" Cc: "'Roman D. Danyliw'" , "'David Cooper'" , , "'Russ Housley'" , "'LAMPS WG'" , "'Stephen Farrell'" Date: Wed, 18 Dec 2019 19:08:16 +0800 Message-ID: <000501d5b593$76681410$63383c30$@sjtu.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdW1h2iqiFbsGDgES/qrC6cB+qI5tw== Content-Language: zh-cn Archived-At: X-Mailman-Approved-At: Wed, 18 Dec 2019 06:57:26 -0800 Subject: Re: [lamps] [Technical Errata Reported] RFC5280 (5938) 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, 18 Dec 2019 11:08:33 -0000 Hi, Stefan, Got it! I was actually stuck by some (but not many) inconsistent words and = phrases (e.g.,=20 subject name, subject field, and then binding), although I could tweak = them in my=20 mind, :-)=20 For example, in Section 4.1.2.6, The subject name MAY be carried in the subject field and/or the = subjectAltName extension.=20 ..If subject naming information is present only in the subjectAltName = extension (e.g., a key bound only to an email address or URI), then the subject name MUST be an empty sequence and the subjectAltName extension MUST be critical. Here it should say, "...then the subject field MUST contain an empty = sequence...". Yuting =E5=8F=91=E4=BB=B6=E4=BA=BA: Stefan Santesson =20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2019=E5=B9=B412=E6=9C=8818=E6=97=A5 16:34 =E6=94=B6=E4=BB=B6=E4=BA=BA: chenyt-sjtu ; 'Salz, = Rich' ; 'Benjamin Kaduk' =E6=8A=84=E9=80=81: 'Roman D. Danyliw' ; 'David Cooper' = ; wpolk@nist.gov; 'Russ Housley' = ; 'LAMPS WG' ; 'Stephen Farrell' = =E4=B8=BB=E9=A2=98: Re: [lamps] [Technical Errata Reported] RFC5280 = (5938) Yuting, It seems that you are still stuck in backwards thinking, and I'm not = sure I can unstack you in a single sentence. We are trying to tell you that you don't verify the binding of a name as = part of certificate validation. You perform certificate validation so you can trust the information in = the certificate. Stefan Santesson=20 =EF=BB=BFOn 2019-12-18, 02:50, "chenyt-sjtu" wrote: Hi, Rich, =20 Thank you for explaining the word "binding". The validity and the = subjectAltName can be trusted if the certificate can pass "path validation", right? = =20 Binding is not a strict word. I found that public key certificates = are defined as data=20 structures that "bind" public key values to subjects (Sec. 3.1). = Should the "binding=20 between a subject and a subject key", rather than the "binding = between a subject=20 distinguished name or a subject alternative name and subject public = key" (Sec. 6.1),=20 get verified in a path validation? =20 Yuting =20 -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Salz, Rich =20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2019=E5=B9=B412=E6=9C=8817=E6=97=A5 22:40 =E6=94=B6=E4=BB=B6=E4=BA=BA: chenyt-sjtu ; = 'Stefan Santesson' ; 'Benjamin Kaduk' = =E6=8A=84=E9=80=81: 'Roman D. Danyliw' ; 'David = Cooper' ; wpolk@nist.gov; 'Russ Housley' = ; 'LAMPS WG' ; 'IETF PKIX' = ; 'RFC Editor' ; 'Stephen = Farrell' =E4=B8=BB=E9=A2=98: Re: [lamps] [Technical Errata Reported] RFC5280 = (5938) =20 The CA, when it signs a certificate, is saying that all of the = information in the certificate is correct. =20 By convention, we talk about "binding" the key to the SubjectDN, but = all of the information -- notAfter, subjectAltName, etc -- are valid, if = you trust the CA (or have a path to a chain up to a CA that you do = trust). We don't talk about "binding" the key to its validity period. =20 =20 =20 =20 =20 From nobody Wed Dec 18 08:29:23 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 B356F120170 for ; Wed, 18 Dec 2019 08:29:20 -0800 (PST) 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 5n_UqnJHsty7 for ; Wed, 18 Dec 2019 08:29:19 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 3DE3E12012C for ; Wed, 18 Dec 2019 08:29:19 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xBIGPXaF019460; Wed, 18 Dec 2019 16:29:12 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=IjQq0Xq3Cz5o3E4U5jX5+M8UcV0dhLbJWc6NncbWL60=; b=Q5SrFyIzu5VFkKZJZigEKgZHeBWDDD2TGvOZWBMLO8H0xM3Dl86bxiISGVjhlAnGppU7 ZROaAR1H3XUduISAeoXNmLZnkSOKqMKsfLdeHNgig4hsrmlC6OwNbFIRfDUm0D7R4iMw NS/HW4C2ubP2p4PO2QMBsXVvKbZ+4BaF6emd2qwJqA73bVFPBWOIJ2NKqs8hwOqJ5ejC wCz7NbmAYMdKlgZTcrOjtgdqZcobmX2uSmZm0NfsLqzHC648Ld9Qb5husSRPuFwQ03HG Cxof39tvf+OWvfEw3lzz/k0ICjF04n4XBKGr3UurXuCkAgC6KXuFqzSC6YdH3GHlaa+e IQ== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2wvqvust28-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Dec 2019 16:29:12 +0000 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xBIGS7u3010798; Wed, 18 Dec 2019 11:29:11 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint6.akamai.com with ESMTP id 2wvuxyu7na-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Dec 2019 11:29:11 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Dec 2019 11:29:10 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Wed, 18 Dec 2019 11:29:10 -0500 From: "Salz, Rich" To: Stefan Santesson , chenyt-sjtu , 'Benjamin Kaduk' CC: 'LAMPS WG' Thread-Topic: [lamps] [Technical Errata Reported] RFC5280 (5938) Thread-Index: AdW1PnA7GnAhp8BniUO0RLXW31zwogAaVKWAAAYgzIA= Date: Wed, 18 Dec 2019 16:29:09 +0000 Message-ID: <745C1705-EDDC-43BB-9B00-FBB1E46FD297@akamai.com> References: <000001d5b545$836c4760$8a44d620$@sjtu.edu.cn> <4E58770D-82A0-431D-9633-4D62BDA716C3@aaa-sec.com> In-Reply-To: <4E58770D-82A0-431D-9633-4D62BDA716C3@aaa-sec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.117.187] 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-12-18_05:, , 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=633 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912180134 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-18_04:2019-12-17,2019-12-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 priorityscore=1501 malwarescore=0 spamscore=0 mlxscore=0 suspectscore=0 bulkscore=0 phishscore=0 clxscore=1015 lowpriorityscore=0 mlxlogscore=598 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912180134 Archived-At: Subject: Re: [lamps] [Technical Errata Reported] RFC5280 (5938) 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, 18 Dec 2019 16:29:21 -0000 PiAgICBXZSBhcmUgdHJ5aW5nIHRvIHRlbGwgeW91IHRoYXQgeW91IGRvbid0IHZlcmlmeSB0aGUg YmluZGluZyBvZiBhIG5hbWUgYXMgcGFydCBvZiBjZXJ0aWZpY2F0ZSB2YWxpZGF0aW9uLg0KICAg IFlvdSBwZXJmb3JtIGNlcnRpZmljYXRlIHZhbGlkYXRpb24gc28geW91IGNhbiB0cnVzdCB0aGUg aW5mb3JtYXRpb24gaW4gdGhlIGNlcnRpZmljYXRlLg0KICANCkVYQUNUTFkhDQogDQoNCg== From nobody Wed Dec 18 14:48: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 CD373120836; Wed, 18 Dec 2019 13:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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] 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 kfgjkomwixKs; Wed, 18 Dec 2019 13:40:03 -0800 (PST) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 ACB5A12001A; Wed, 18 Dec 2019 13:40:02 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id y1so2779374lfb.6; Wed, 18 Dec 2019 13:40:02 -0800 (PST) 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=mqroNkNRAJLMPNsYk8wf9BknxyPvheqNAdqj0FrKcG0=; b=qu6UlTUPuce97LBq2ThvdSfvVwqwi3SuEOir4CWQY3RO3zy6+hChDG6DAvMk8piq5R pXxwYMQBSbhlTXewFgPqnNnFCoMzOOjuPHw3cdhpGHw30ginYTgSgsdJd3UPCbnqYLnq 8Eh/8p0kPtFzyNjc+oDIdDjznu/2KpoNAnOljGxReBsF3wF34+Tjky8GWLOJL5gsUfMR JSfxXGYN8GWl9FpjGi88MOwBDnYkGFCREYSajRPuWHTf+qGcqGwXa8qaBkZgAtv4z3na bM5avXCoyduKC5+o8dnc0mmfHbJb/3EAFA6qe1X+wj/d8buPgm+TppyWGjjukmTfPMVa mwAQ== 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=mqroNkNRAJLMPNsYk8wf9BknxyPvheqNAdqj0FrKcG0=; b=bVPN8ZC8h0v/EeRkl1+yWsrHarf+9dcxuZK6lSDFZz+BRCZCpi2LgZyC++MP7kr4I5 OOf7rpQf9sZo6r9eVBzTX5kvMHyayyD9oCisIGKMAHG4UqbEp5hN/9YDNXLRTQV3VmKU W0ckD12B/kMrQl8Xp1UpSJ9Yh8+DgAMet/tpUTRGuCg88y+39W7mE4Ar/yQe5OAD7FqF YXBQhwHNxNb9RuR9jdQbLtaFJIpLA5AJyynzcXnd3Cu+cGy4F470URFUhNSMF479LJGD oOdQfn3h5FwI6lTn+YdZop5h5Rn0yvPl2pyCFCxS/fltHdNVse0yKzKFDG0IpIn+d/Hi 8FaQ== X-Gm-Message-State: APjAAAX3cVZzFDj1sSZ27moLCOGJRHPvlwKAZncWcxEcvVMiZmeUa5nt 8RJ0fUNTuoqctCCnJOym5lkM3HFyusgPzjKDXYU= X-Google-Smtp-Source: APXvYqxbRmgInjwEeQGt2e4siURPDqUKVxlcQEn5LkklWI1Q2C26uJAWAj4vsON0s9Hd4EOo2uRVQkZGfVwhNmzJKG0= X-Received: by 2002:a19:cc49:: with SMTP id c70mr3204468lfg.73.1576705200858; Wed, 18 Dec 2019 13:40:00 -0800 (PST) MIME-Version: 1.0 References: <000001d5b57e$2bfdfcb0$83f9f610$@sjtu.edu.cn> In-Reply-To: <000001d5b57e$2bfdfcb0$83f9f610$@sjtu.edu.cn> From: Peter Bowen Date: Wed, 18 Dec 2019 13:39:49 -0800 Message-ID: To: chenyt-sjtu Cc: "Salz, Rich" , Stefan Santesson , Benjamin Kaduk , "Roman D. Danyliw" , David Cooper , wpolk@nist.gov, Russ Housley , LAMPS WG , IETF PKIX , Stephen Farrell , RFC Editor Content-Type: multipart/alternative; boundary="00000000000069b121059a01499b" Archived-At: X-Mailman-Approved-At: Wed, 18 Dec 2019 14:48:52 -0800 Subject: Re: [lamps] [Technical Errata Reported] RFC5280 (5938) 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, 18 Dec 2019 21:40:06 -0000 --00000000000069b121059a01499b Content-Type: text/plain; charset="UTF-8" On Wed, Dec 18, 2019 at 6:57 AM chenyt-sjtu wrote: > Actually my concern is same as Ben's. There are three types of bindings > (between the key and the subject) in RFC 5280. > > "binding between the public key material and the subject > of the certificate" (Sec. 4.1.1.3), "binding between the subject > and public key" (Sec. 8), "binding between a key and certificate > subject" (Sec. 8), > > "binding between the subject distinguished name and/or > subject alternative name and subject public key" (Sec. 6) and > "binding between the name and subject public key" (Sec. 6.1), > > "binding between a subject distinguished name or a subject > alternative name and subject public key" (Sec. 6.1). > > If the three types of bindings are the same thing, it will be good if we > can > make them consistently presented. > > If they are different, some explanations can be made in Section 6. > > should contain or . Then what are the other > bindings in > ? Are they remained unverified after a path validation? > In X.509 certificates, as defined in RFC 5280, contain fields. A field is roughly analogous to a ASN.1 component. In 5280, each certificate has a single public key. This public key is the Subject Public Key and is stored in the Subject Public Key Info field in the certificate (which can also be called the Subject Public Key field). The Subject of a certificate is a person, service, system, or other entity. The Subject can have multiple identifiers (or names) that all refer to the same Subject. These identifiers can be encoded in the certificate in Subject field (as a Distinguished Name), the Subject Alternative Name extension, or both. The certificate asserts a binding between the Subject and the Subject Public Key. As the various identifiers in the Subject and Subject Alternative Name extension are all synonyms, they all refer to the same entity and all are bound to the same public key. While phrased slightly differently, as you point out, they all mean the same thing. Having inconsistent terminology makes translation very tricky, as you have to understand whether there is meaningful difference that needs to be retained. I think the fully expressed version would be something like: "The primary goal of path validation is to verify the binding between the subject identifier(s) and the subject public key info, as represented in the target certificate, based on the public key of the trust anchor." Note that in current implementations of PKI, there are usually multiple trust anchors, so you have to attempt path validation for each anchor and accept the binding if any path validates. Thanks, Peter --00000000000069b121059a01499b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 18, 2019 at 6:57 AM chenyt-sj= tu <chenyt@sjtu.edu.cn> wro= te:
Actually my concern is same as Ben's. There are three ty= pes of bindings
(between the key and the subject) in RFC 5280.

<Binding 1> "binding between the public key material and the sub= ject
of the certificate" (Sec. 4.1.1.3), "binding between the subject =
and public key" (Sec. 8), "binding between a key and certificate =
subject" (Sec. 8),

<Binding 2> "binding between the subject distinguished name and/= or
subject alternative name and subject public key" (Sec. 6) and
"binding between the name and subject public key" (Sec. 6.1),

<Binding 3> "binding between a subject distinguished name or a s= ubject
alternative name and subject public key" (Sec. 6.1).

If the three types of bindings are the same thing, it will be good if we ca= n
make them consistently presented.

If they are different, some explanations can be made in Section 6. <Bind= ing 1>
should contain <Binding 2> or <Binding 3>. Then what are the ot= her bindings in
<Binding 1>? Are they remained unverified after a path validation?

In X.509 certificates, as defined in RFC = 5280, contain fields.=C2=A0 A field is roughly analogous to a ASN.1 compone= nt.

In 5280, each certificate has a single public = key.=C2=A0 This public key is the Subject Public Key and is stored in the S= ubject Public Key Info field in the certificate (which can also be called t= he Subject Public Key field).

The Subject of a cer= tificate is a person, service, system, or other entity.=C2=A0 The Subject c= an have multiple identifiers (or names) that all refer to the same Subject.= =C2=A0 These identifiers can be encoded in the certificate in Subject field= (as a Distinguished Name), the Subject Alternative Name extension, or both= .

The certificate asserts a binding between the Su= bject and the Subject Public Key.=C2=A0 As the various identifiers in the S= ubject and Subject Alternative Name extension are all synonyms, they all re= fer to the same entity and all are bound to the same public key.
=
While phrased slightly differently, as you point out, they a= ll mean the same thing.=C2=A0 Having inconsistent terminology makes transla= tion very tricky, as you have to understand whether there is meaningful dif= ference that needs to be retained.=C2=A0 I think the fully expressed versio= n would be something like:

"The primary goal = of path validation is to verify the binding between the subject identifier(= s) and the subject public key info, as represented in the target certificat= e,=C2=A0based=C2=A0on the public key = of the trust anchor."=C2=A0 Note that in current implementation= s of PKI, there are usually multiple trust anchors, so you have to attempt = path validation for each anchor and accept the binding if any path validate= s.

Thanks,
Peter
--00000000000069b121059a01499b-- From nobody Wed Dec 18 21:32:53 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 54A0712006E; Wed, 18 Dec 2019 21:32:51 -0800 (PST) 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_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 LTcse7eSK3BM; Wed, 18 Dec 2019 21:32:49 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84761120018; Wed, 18 Dec 2019 21:32:49 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 4A057F40721; Wed, 18 Dec 2019 21:32:30 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, spasm@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20191219053230.4A057F40721@rfc-editor.org> Date: Wed, 18 Dec 2019 21:32:30 -0800 (PST) Archived-At: Subject: [lamps] =?utf-8?q?RFC_8696_on_Using_Pre-Shared_Key_=28PSK=29_in_?= =?utf-8?q?the_Cryptographic_Message_Syntax_=28CMS=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: Thu, 19 Dec 2019 05:32:51 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8696 Title: Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) Author: R. Housley Status: Standards Track Stream: IETF Date: December 2019 Mailbox: housley@vigilsec.com Pages: 31 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-lamps-cms-mix-with-psk-07.txt URL: https://www.rfc-editor.org/info/rfc8696 DOI: 10.17487/RFC8696 The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms that could be broken by the invention of such a quantum computer. By storing communications that are protected with the CMS today, someone could decrypt them in the future when a large-scale quantum computer becomes available. Once quantum-secure key management algorithms are available, the CMS will be extended to support the new algorithms if the existing syntax does not accommodate them. This document describes a mechanism to protect today's communication from the future invention of a large-scale quantum computer by mixing the output of key transport and key agreement algorithms with a pre-shared key. This document is a product of the Limited Additional Mechanisms for PKIX and SMIME Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Dec 19 15:19:24 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 00C40120089 for ; Thu, 19 Dec 2019 15:19:23 -0800 (PST) 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 t2RYLuqXQUcE for ; Thu, 19 Dec 2019 15:19:21 -0800 (PST) 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 5398312001A for ; Thu, 19 Dec 2019 15:19:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C2C1B300B30 for ; Thu, 19 Dec 2019 18:19:19 -0500 (EST) 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 ZBwGP1MwxhAg for ; Thu, 19 Dec 2019 18:19:18 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id E9BC63001CC; Thu, 19 Dec 2019 18:19:17 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_63095490-DAF0-4D5B-B31A-BE0D53E98A07"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 19 Dec 2019 18:19:18 -0500 In-Reply-To: <87blt4i2ye.fsf@fifthhorseman.net> Cc: LAMPS WG To: Daniel Kahn Gillmor References: <87blt4i2ye.fsf@fifthhorseman.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Advertising S/MIME capabilities in a certificate? 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, 19 Dec 2019 23:19:23 -0000 --Apple-Mail=_63095490-DAF0-4D5B-B31A-BE0D53E98A07 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 DKG: This seems very similar to the attribute specified in RFC 5751 that = indicates binary message bodies can be handled: Implementations MAY "know" that recipient implementations are capable of handling inner binary MIME entities either by interpreting the id-cap-preferBinaryInside SMIMECapabilities attribute ... Russ > On Nov 22, 2019, at 6:07 AM, Daniel Kahn Gillmor = wrote: >=20 > Hi folks-- >=20 > It occurs to me that i'd like at least one of the certificates in > https://www.ietf.org/id/draft-dkg-lamps-samples-01.html to announce = some > SMIMECapabilities. For example, maybe it could advertise that it is > capable of handling a PKCS#7 Compression layer? Or that it is capable > of processing authEnveloped-data? >=20 > However, reading RFC 8551 and related specs i realize how rusty my = ASN.1 > is (and my knowledge of CMS is so paltry that there was never even > enough of it to rust). >=20 > It looks to me like S/MIME capabilities are never advertised in the = cert > itself, but rather expected to be included as a signedAttribute in a > signedData object. Is that right? Is there no way that the > advertisement can be included in the certificate? >=20 > I suppose if the advertisement could be included in both the = signedData > object *and* the certificate itself then the algorithm in =C2=A72.7.1 = of RFC > 8551 would need to be much more complicated. >=20 > Any pointers or examples would be welcome, >=20 > --dkg --Apple-Mail=_63095490-DAF0-4D5B-B31A-BE0D53E98A07 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCXfwFdgAKCRCK5O7Q9ZwR y1yRAJ0VsVxaXoqOhLIi5xIiqqtmLFJcqQCbBL7lKWIcXwsN/2eY2EH9zfSBHJU= =CnuT -----END PGP SIGNATURE----- --Apple-Mail=_63095490-DAF0-4D5B-B31A-BE0D53E98A07-- From nobody Thu Dec 19 15:32:34 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 A9677120077 for ; Thu, 19 Dec 2019 15:32:32 -0800 (PST) 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 zQx4i2gr97cB for ; Thu, 19 Dec 2019 15:32:31 -0800 (PST) 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 001F412001A for ; Thu, 19 Dec 2019 15:32:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4BD43300B23 for ; Thu, 19 Dec 2019 18:32:29 -0500 (EST) 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 ab2fz1qfaERI for ; Thu, 19 Dec 2019 18:32:28 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 05ED23001CC for ; Thu, 19 Dec 2019 18:32:27 -0500 (EST) 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, 19 Dec 2019 18:32:28 -0500 References: <878sodm0j3.fsf@fifthhorseman.net> To: LAMPS WG In-Reply-To: <878sodm0j3.fsf@fifthhorseman.net> Message-Id: <23953F0E-F919-4BBD-998F-11FF0DDBD95F@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] LAMPS sample keys and certificates 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, 19 Dec 2019 23:32:33 -0000 All: We set a goal at IETF 106 of learning how different user agents handle = the two approaches to header protection. I would like to see reports on = the mail list so that we can choose a way forward. Please help! Russ > On Nov 18, 2019, at 2:45 PM, Daniel Kahn Gillmor = wrote: >=20 > Hi all-- >=20 > I've just published: >=20 > https://www.ietf.org/id/draft-dkg-lamps-samples-00.html >=20 > This draft contains sample X.509v3 certificates, and corresponding > secret keys for a sample CA, and for two e-mail users, Alice and Bob. > It provides the certificates and keys in PEM-encoded form and (for = Alice > and Bob) in PKCS#12 bundles, so they should be relatively easy to > import. >=20 > My hope is that they are useful for generating and interpreting sample > S/MIME (CMS) messages, and part of a larger plan to generate test > vectors that will be useful in demonstrating protected header behavior > on existing clients. >=20 > I'd appreciate any feedback or suggestions on the draft and the sample > keys and certificates and PKCS#12 files. >=20 > I'm currently building the draft from the git repo at > https://gitlab.com/dkg/lamps-samples -- editorial patches, issues, etc > are welcome at the gitlab interface, though i would prefer if any > substantive issues are also addressed to the list here. >=20 > --dkg From nobody Thu Dec 19 20:15:14 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 6FDC2120045 for ; Thu, 19 Dec 2019 20:15:12 -0800 (PST) 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_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 2PTYe-x45JwK for ; Thu, 19 Dec 2019 20:15:11 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518F2120047 for ; Thu, 19 Dec 2019 20:15:11 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0FE6FF40743; Thu, 19 Dec 2019 20:14:51 -0800 (PST) To: housley@vigilsec.com, rdd@cert.org, kaduk@mit.edu, housley@vigilsec.com, tim.hollebeek@digicert.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: berasmus05@gmail.com, spasm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20191220041451.0FE6FF40743@rfc-editor.org> Date: Thu, 19 Dec 2019 20:14:51 -0800 (PST) Archived-At: Subject: [lamps] [Technical Errata Reported] RFC8649 (5942) 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, 20 Dec 2019 04:15:12 -0000 The following errata report has been submitted for RFC8649, "Hash Of Root Key Certificate Extension". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5942 -------------------------------------- Type: Technical Reported by: Brian Section: 0620730705 Original Text ------------- Corrected Text -------------- Notes ----- 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 can log in to change the status and edit the report, if necessary. -------------------------------------- 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 From nobody Thu Dec 19 20:18: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 B0975120047 for ; Thu, 19 Dec 2019 20:18:09 -0800 (PST) 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 UwntvCjljWu8 for ; Thu, 19 Dec 2019 20:18:08 -0800 (PST) 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 89D74120045 for ; Thu, 19 Dec 2019 20:18:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id BDC07203352; Thu, 19 Dec 2019 20:15:26 -0800 (PST) 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 YIZ2hISgY25x; Thu, 19 Dec 2019 20:15:26 -0800 (PST) Received: from [172.31.98.5] (unknown [96.229.48.220]) by c8a.amsl.com (Postfix) with ESMTPA id 74DDC20334C; Thu, 19 Dec 2019 20:15:26 -0800 (PST) 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: <20191220041451.0FE6FF40743@rfc-editor.org> Date: Thu, 19 Dec 2019 20:18:07 -0800 Cc: Russ Housley , "Roman D. Danyliw" , kaduk@mit.edu, Tim Hollebeek , spasm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <17A26D6B-06D5-4002-BCD0-23F98745A36C@amsl.com> References: <20191220041451.0FE6FF40743@rfc-editor.org> To: RFC System X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [lamps] [Technical Errata Reported] RFC8649 (5942) 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, 20 Dec 2019 04:18:10 -0000 Greetings, FYI - we have deleted this report as junk. Thank you. RFC Editor/mf On Dec 19, 2019, at 8:14 PM, 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/eid5942 >=20 > -------------------------------------- > Type: Technical > Reported by: Brian >=20 > Section: 0620730705 >=20 > Original Text > ------------- >=20 >=20 > Corrected Text > -------------- >=20 >=20 > Notes > ----- >=20 >=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 Fri Dec 20 07:28:53 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 F0577120124 for ; Fri, 20 Dec 2019 07:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=digicert.com header.b=MzOQR5EV; dkim=pass (1024-bit key) header.d=digicert.com header.b=qNQRhZvU 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 YdkUuL8uM0gz for ; Fri, 20 Dec 2019 07:28:41 -0800 (PST) Received: from us-smtp-delivery-173.mimecast.com (us-smtp-delivery-173.mimecast.com [63.128.21.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B009E12011F for ; Fri, 20 Dec 2019 07:28:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1576855716; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=ydRueaStuutHvu2lsemxbT1cacE73giT9f2+8KRwMLE=; b=MzOQR5EVfy77cKTPDiR9uo7IglmDjVTYTyf0z9gpqFd9NTb04Ax6yz0YiQzVNnCVDrPMZF DmthKctEqSbGuIkjWULcf0+1+RPKia5ecbmtw1QHhg7h2NNHAqPfIKYqIe+uXSN92UAq/W 0Ia3SC4pnKEgvKCvkHSoIuA0n8Sesm4= Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2174.outbound.protection.outlook.com [104.47.58.174]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-338-bceTvBE-MbS7Lp9eFFJH0g-1; Fri, 20 Dec 2019 10:28:33 -0500 X-MC-Unique: bceTvBE-MbS7Lp9eFFJH0g-1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g/YlrcdlmwTXzJd0K14SygQe5aHSd50jkr9hmSmq0krfsZCCQMJmSw2u0i+T7FG4zx5KngMQPE55L6rLZFkC+pSCgqMu/qAjHmzTMWJ1L4LG7QrCKZxx6dFIeZLNnVGSjkry7K39ZPa2PuhgJ10MGZIF4kHyCNs66PlsCELtrKcceiBWA1ri3YNYGZbl2c4lYkB179xTLpevpGJOIWIFYb5+Dma3yD/CDSQ52XAqyTKYhiFQPDEg1rCAanSTOkeY4dAhod8fDXNiMOV2s5xKFPMAb8Gyd3aWHQ24bKsmoQeBgzM4n3/L22+03E5xyR4xC5dQFYH5xqEmMUB4wryUfg== 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=ydRueaStuutHvu2lsemxbT1cacE73giT9f2+8KRwMLE=; b=AiuDxRNJAhcIYQ0ROIK7FrzjQI74BMyRov7ksCBpbDz5tpQVN9QpXEfzQD/YzJ76DeASR+XNQ8QYGP10xhvbaJipega/DdwKA8Hn97tErR6OmUdv/wByDzFnChmWzGa0n7Ad3xU5mb0psioWrdKQDneVg8MrlS5DG5dF/Fm628Elv34ftoNFCePr8kYABtK5FObBkfJTVOVceHTrHVp5lVbOjzmNBHEC2UEjgZLndIQ0zdqlR/68pgzAjt+FZIP9Ull0l9YdhqTkvG4LffcJZTHjhEc2/KHlDdl8Wxk4sMLb2lbhWu7frrlY6klekFp0sk9V4USBwSOoVYJuBlJiSg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=digicert.com; dmarc=pass action=none header.from=digicert.com; dkim=pass header.d=digicert.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ydRueaStuutHvu2lsemxbT1cacE73giT9f2+8KRwMLE=; b=qNQRhZvU5x3TLh0s6dh4b6HALqpYHk1u9+K/pJFA9ej4iLcxvDtH+4qxu3n8V6QXJkzsVTBSwiazAq7/uIea4ErekrENLCmiH7cUlC1R+edMlMfI9w2DjrGNYhmww6T04HEsIaZp0zEsoW6qxHk+i0VQSqE5ginXjgpKBtlXz9U= Received: from BN8PR14MB3059.namprd14.prod.outlook.com (20.179.138.155) by BN8PR14MB2643.namprd14.prod.outlook.com (20.178.208.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.15; Fri, 20 Dec 2019 15:28:32 +0000 Received: from BN8PR14MB3059.namprd14.prod.outlook.com ([fe80::8c98:edf7:315d:b5db]) by BN8PR14MB3059.namprd14.prod.outlook.com ([fe80::8c98:edf7:315d:b5db%5]) with mapi id 15.20.2538.019; Fri, 20 Dec 2019 15:28:32 +0000 From: Tim Hollebeek To: SPASM Thread-Topic: Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect Thread-Index: AdW3SgT7TzvannoqRPuIFXJ92Hzy6Q== Date: Fri, 20 Dec 2019 15:28:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tim.hollebeek@digicert.com; x-originating-ip: [98.111.253.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ba478feb-37b1-4769-a287-08d7856145a3 x-ms-traffictypediagnostic: BN8PR14MB2643: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4125; x-forefront-prvs: 025796F161 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(346002)(366004)(376002)(136003)(189003)(199004)(86362001)(6916009)(6506007)(8936002)(64756008)(66556008)(66476007)(478600001)(66446008)(71200400001)(66946007)(66616009)(52536014)(8676002)(44832011)(76116006)(186003)(26005)(7696005)(5660300002)(15650500001)(2906002)(33656002)(316002)(9686003)(81166006)(558084003)(55016002)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:BN8PR14MB2643; H:BN8PR14MB3059.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yVuF+ApRWhXr1Slz+B0aReqaLAJF3E6/Rrn18l+tdNvzO09Q4B6vAvOP4jJ0dpTlwPxuD/sTTP3pbEArmgUsNdwtWXPpznExQNTkvbTVqtAbrQlMguZgSEiviRE7HcoHFVrfcKI2CTJpyc0aU0zkbn8zEqxOF56XfIDNU7IMXh/CYUpt3AInmUdD7pkDD30Ss9Y0qaTesw0q3155115/tZghRTKOIYL5iM0s16GOxLYxvV1tRI20h+xn0sXCFCrR4iWcsJlAVZqI20NH8RFNNzVMlLLavMdTENtXED6t7Oa/Vj6XD6aIEKRE+lfDKiEGy+K31R1gaAJnCGWIcI01+HqhWUPMJv6UvVNQOrdaliHSsfFwHCUNUSyCHPjGCuG69VPL6F0G00Bbo8Rh1qLeE+VValnq19AjL0fmb5tnb8Yi1wsfoVaK+lPP1Jp+h1Pf x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_06C1_01D5B720.3998F660" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: ba478feb-37b1-4769-a287-08d7856145a3 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2019 15:28:32.1259 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xcXhMW56Gn8fWxjujsNr6ILMtk99Erdx7nrYvG7by2O9EVML+Etrac3mbieJ2oow1DnCisapPPz9HfYGqg0HhxPVOZiLZKoWt18jMYMqkpc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR14MB2643 Archived-At: Subject: [lamps] Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect 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, 20 Dec 2019 15:28:51 -0000 ------=_NextPart_000_06C1_01D5B720.3998F660 Content-Type: multipart/alternative; boundary="----=_NextPart_001_06C2_01D5B720.3998F660" ------=_NextPart_001_06C2_01D5B720.3998F660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please indicate whether you support adoption of Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect by the LAMPS WG by January 17th. -Tim ------=_NextPart_001_06C2_01D5B720.3998F660 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Please = indicate whether you support adoption of Call for Adoption of = draft-housley-lamps-cms-update-alg-id-protect by the LAMPS WG by January = 17th.

 

-Tim

------=_NextPart_001_06C2_01D5B720.3998F660-- ------=_NextPart_000_06C1_01D5B720.3998F660 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTkxMjIwMTUyODMxWjAvBgkqhkiG9w0BCQQxIgQgVk2yP6PGYlzv3U9TiX+PX3HAsbXO iw/mIg6WNnbKKb8wgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAMajoPD3jIaYzbgpNCtyywcc+7xVUvNnJj/NtGCdcEUobDpjHtkK30LuQ3XURCzgfsmD2qxN 0hL4SapOPLnGlq0WZxbVFHd9Rn/l8th821I+wDGJ9iIKLzhCA9VsnOBPsQmZSizmWkcOoqJIanGa Otc3wwikMvv9I/jF/cwgO/0d/7qqgV6B+htYtAg8ysxaGeq82zrheJZqQZxKP5HsigLqvuvsxyhM WMs9QKw7ME9utMjxM3pVcRXWXiUucmiH2EshIFjqReBYOWjNwoyn9bvxzw0A6yy8VqGgaOorlQ0H Ss6vcbetDisNcpIPHLQ+xSeApTDSQb+nTy1korT6yBEAAAAAAAA= ------=_NextPart_000_06C1_01D5B720.3998F660-- From nobody Fri Dec 20 11:09: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 85B09120980 for ; Fri, 20 Dec 2019 11:09:44 -0800 (PST) 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 DNKmf7q-j05X for ; Fri, 20 Dec 2019 11:09:43 -0800 (PST) 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 F11451208CB for ; Fri, 20 Dec 2019 11:09:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 718E8300ADE for ; Fri, 20 Dec 2019 14:09:41 -0500 (EST) 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 XA4HjZZejxEh for ; Fri, 20 Dec 2019 14:09:40 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 82A013001CC for ; Fri, 20 Dec 2019 14:09:40 -0500 (EST) 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: Fri, 20 Dec 2019 14:09:41 -0500 References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <268790BF-0620-4230-BC81-D857A2061B58@vigilsec.com> To: LAMPS WG In-Reply-To: <268790BF-0620-4230-BC81-D857A2061B58@vigilsec.com> Message-Id: <8BDE7EC3-91BF-46CE-A0E0-60F9030D348A@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Call For Adoption of draft-turner-5480-ku-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: Fri, 20 Dec 2019 19:09:44 -0000 Many people spoke in support of adoption, and no one spoke against it. = So, the LAMPS WG has adopted it. Sean, please post draft-ietf-lamps-5480-ku-clarifications-00. Russ > On Dec 6, 2019, at 1:31 PM, Russ Housley wrote: >=20 > Please indicate whether you support adoption of = draft-turner-5480-ku-clarifications by the LAMPS WG by December 20th. >=20 > Russ From nobody Fri Dec 20 11:12:00 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 297A21209A3; Fri, 20 Dec 2019 11:11:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.114.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157686911916.4133.6621785676985866321.idtracker@ietfa.amsl.com> Date: Fri, 20 Dec 2019 11:11:59 -0800 Archived-At: Subject: [lamps] The LAMPS WG has placed draft-turner-5480-ku-clarifications in state "Adopted by a WG" 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, 20 Dec 2019 19:11:59 -0000 The LAMPS WG has placed draft-turner-5480-ku-clarifications in state Adopted by a WG (entered by Russ Housley) The document was previously in state Candidate for WG Adoption The document is available at https://datatracker.ietf.org/doc/draft-turner-5480-ku-clarifications/ From nobody Fri Dec 20 11:15:33 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 D7CD4120999; Fri, 20 Dec 2019 11:15:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: spasm@ietf.org, lamps-chairs@ietf.org, housley@vigilsec.com, rdd@cert.org X-Test-IDTracker: no X-IETF-IDTracker: 6.114.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157686933184.4090.10691136324464986337.idtracker@ietfa.amsl.com> Date: Fri, 20 Dec 2019 11:15:31 -0800 Archived-At: Subject: [lamps] lamps - New Meeting Session Request for IETF 107 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, 20 Dec 2019 19:15:32 -0000 A new meeting session request has just been submitted by Russ Housley, a Chair of the lamps working group. --------------------------------------------------------- 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): 2 Hours 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 Sean Turner Alexey Melnikov Roman Danyliw Bernie Hoeneisen Jim Schaad Tim Hollebeek Hendrik Brockhaus Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Dec 20 15:48: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 410541209D3 for ; Fri, 20 Dec 2019 15:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, 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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=Mu9nh3a0; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=hd6+Zq/H 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 YIu6JCEGxZ0t for ; Fri, 20 Dec 2019 15:48:45 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799351208D5 for ; Fri, 20 Dec 2019 15:48:45 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1576885724; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=bBND5WK9fA9L/LRxes9PFCOJzXhCWQcveqCF4Kph3CA=; b=Mu9nh3a09XDr4YC7Dysx2MRlT/BL/P9CG1tdbKFiJSlPop6Sqb+Yl5z3 Lt1NTqGJB0/5HQv28l+nU9leQQiJAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1576885724; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=bBND5WK9fA9L/LRxes9PFCOJzXhCWQcveqCF4Kph3CA=; b=hd6+Zq/HP5lQ2HOd8TXds4U26Fc2Pj5JdLCdNCpF4yPjJ2h0UIrLCb3C zpcc7hAQHLvWL27FKFRvKaPi3oKhZi94g75Fb5wuRZeXnC97La9NuhNJQE Ll/w+5iDlluy0qHHyoTvvGb2GmhSrPDmc3yHXDnmA6UJK29BbrM8zMyexz BsUb8bUKoudKXfYnrQRnGh5Gkp2pLyU04PP5vCobRU648U3qpd3CQh4PML o5sArNROITiaY8tGr/bad5vxBAp96opKEci2PSK7c+W/1dG6dTogC/axEK iQA1gqj7DYjkNzswIc+4cSiqaAeET4UpRSMNPcTYg9AVnPqYVuRVRQ== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 3463CF9A5; Fri, 20 Dec 2019 18:48:43 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 17E99203D6; Fri, 20 Dec 2019 18:48:40 -0500 (EST) From: Daniel Kahn Gillmor To: Russ Housley , LAMPS WG In-Reply-To: <23953F0E-F919-4BBD-998F-11FF0DDBD95F@vigilsec.com> References: <878sodm0j3.fsf@fifthhorseman.net> <23953F0E-F919-4BBD-998F-11FF0DDBD95F@vigilsec.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Fri, 20 Dec 2019 18:48:39 -0500 Message-ID: <87r20ya78o.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] LAMPS sample keys and certificates 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, 20 Dec 2019 23:48:47 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi LAMPS folks-- On Thu 2019-12-19 18:32:28 -0500, Russ Housley wrote: > We set a goal at IETF 106 of learning how different user agents handle > the two approaches to header protection. I would like to see reports > on the mail list so that we can choose a way forward. Please help! Thanks for the nudge, Russ. Turns out i've learned a lot more about S/MIME than i ever wanted to know, in the process of creating S/MIME test vectors for the Autocrypt-style protected headers. I've just published https://www.ietf.org/id/draft-autocrypt-lamps-protected-headers-02.html From=20the in-document changelog: Significant changes between version -01 and -02: - Added S/MIME test vectors in addition to PGP/MIME - Legacy Display parts should now be text/plain and not text/rfc822-headers (see https://github.com/autocrypt/protected-headers/issues/23) - Cryptographic Payload must have protected-headers parameter set to v1 (see https://github.com/autocrypt/protected-headers/issues/21) - Test vector sample Message-Ids have been normalized - Added encrypted-only (unsigned) test vectors, at the suggestion of Russ Housley In addition, the test vectors are programmatically available at: imap://bob@protected-headers.cmrg.net/inbox (use any password, should be a read-only mailbox, with ephemeral IMAP tags) I'm asking folks who have clients capable of handling cryptographic e-mail (either S/MIME or PGP/MIME or both, you don't have to handle everything!) to submit screenshots! It should be useful to collect screenshots following the guidance outlined here: https://github.com/autocrypt/protected-headers/tree/master/screenshots If you'd an example, take a look at the Thunderbird + Enigmail screenshots here: https://github.com/autocrypt/protected-headers/tree/master/screenshots/= thunderbird%2Benigmail/68.3.1%2B2.1.3 I'd appreciate any feedback about this work, particularly on: - the screenshot process (can we make it easier for people to generate screenshots from a given client)? - the test vectors themselves (are problems with any of them? do they follow the draft correctly?) - the text in the draft (as an implementer, is it easy to understand and implement)? Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXf1d1wAKCRB2GBllKa5f +AeNAP97rPhLE+J+Z1YqNMXP4lDzj2fqE10mKv98F+8qhQYt9QD+IQols2MV/DUV RRKMHLGctx3Hj3tx9chHVr43SWsGPAw= =qa9U -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Dec 21 13: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 59AF2120074 for ; Sat, 21 Dec 2019 13:29:41 -0800 (PST) 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 DWbSFTVZQ9dx for ; Sat, 21 Dec 2019 13:29:39 -0800 (PST) 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 79A85120025 for ; Sat, 21 Dec 2019 13:29:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 07C33300B24 for ; Sat, 21 Dec 2019 16:29:38 -0500 (EST) 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 o-ofI-XuU_he for ; Sat, 21 Dec 2019 16:29:36 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 8B3F2300B16; Sat, 21 Dec 2019 16:29:36 -0500 (EST) From: Russ Housley Message-Id: <9B4B40AF-D7F0-4815-BE71-F4E930251A05@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_7968665B-D72A-4294-8C55-F3C5215A52F6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 21 Dec 2019 16:29:37 -0500 In-Reply-To: Cc: SPASM To: Tim Hollebeek References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect 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: Sat, 21 Dec 2019 21:29:41 -0000 --Apple-Mail=_7968665B-D72A-4294-8C55-F3C5215A52F6 Content-Type: multipart/alternative; boundary="Apple-Mail=_A05C65B6-7E4A-4A01-9D52-B7CEB384BB25" --Apple-Mail=_A05C65B6-7E4A-4A01-9D52-B7CEB384BB25 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Of course, I am in favor of adopting this draft. Russ > On Dec 20, 2019, at 10:28 AM, Tim Hollebeek = wrote: >=20 >=20 > Please indicate whether you support adoption of Call for Adoption of = draft-housley-lamps-cms-update-alg-id-protect by the LAMPS WG by January = 17th. >=20 > -Tim > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm = --Apple-Mail=_A05C65B6-7E4A-4A01-9D52-B7CEB384BB25 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Of = course, I am in favor of adopting this draft.

Russ


On Dec 20, 2019, at 10:28 AM, Tim Hollebeek <tim.hollebeek@digicert.com> wrote:

 
Please = indicate whether you support adoption of Call for Adoption of = draft-housley-lamps-cms-update-alg-id-protect by the LAMPS WG by January = 17th.
 
-Tim
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

= --Apple-Mail=_A05C65B6-7E4A-4A01-9D52-B7CEB384BB25-- --Apple-Mail=_7968665B-D72A-4294-8C55-F3C5215A52F6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCXf6OwQAKCRCK5O7Q9ZwR yx0uAKDoJXiOnt4TJHHoNzBG4Bp4krZH9wCg8pr+XR4SomJnCVvZIZsuW1RIa5E= =XGGJ -----END PGP SIGNATURE----- --Apple-Mail=_7968665B-D72A-4294-8C55-F3C5215A52F6-- From nobody Sat Dec 21 13:39:26 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 A86D7120025 for ; Sat, 21 Dec 2019 13:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, HTML_MESSAGE=0.001, 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 zDT9uLwsolna for ; Sat, 21 Dec 2019 13:39:23 -0800 (PST) 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 F09E9120074 for ; Sat, 21 Dec 2019 13:39:22 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xBLLTkLA028757; Sat, 21 Dec 2019 21:39:20 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=NrkamDirFkxzGm9y+Frp3T6gYYfZy87IZQKUkPkS3to=; b=fZGkVb2CsCP8Qm+Sm0Ske+ZYCLJqE0/qtXlW4xLkxmuHSQFyySyUC0yeKdH2uw29eFJr krUCZG+j3WleL1VGiEUclclxZ5dNmz4fXcS/BJGWe0qgfg5cRSeuOVeGv1Wl42sIo1Nq CxcxZzT1j9+HlYvZnNxq/lcANnNtND1C7EaAJJKtqbcmg/qKMf/odUsqEBwtS/uuraap 76cpOEVjEnIK1AVFpUlT/YsAl+4lhd6EkmWUfp9qWuxpgxO5x6OEPetP9UwFspBnHxBq 9ijvv5LKy4rK/AK/QR5csVQlFA5cBbcF59AuOdSiK2OGwAABHzv8Xy/5rerCJpHrdpsm lQ== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2x1950tqer-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 21 Dec 2019 21:39:20 +0000 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 xBLLWPki022225; Sat, 21 Dec 2019 16:39:19 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint3.akamai.com with ESMTP id 2x1fkyvr04-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 21 Dec 2019 16:39:19 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 21 Dec 2019 16:39:18 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Sat, 21 Dec 2019 16:39:18 -0500 From: "Salz, Rich" To: Russ Housley , Tim Hollebeek CC: SPASM Thread-Topic: [lamps] Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect Thread-Index: AdW3SgT7TzvannoqRPuIFXJ92Hzy6QBJaKeA//+u4YA= Date: Sat, 21 Dec 2019 21:39:17 +0000 Message-ID: <06353CC6-F30E-47BE-94C0-BC9B179D2B19@akamai.com> References: <9B4B40AF-D7F0-4815-BE71-F4E930251A05@vigilsec.com> In-Reply-To: <9B4B40AF-D7F0-4815-BE71-F4E930251A05@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.81] Content-Type: multipart/alternative; boundary="_000_06353CC6F30E47BE94C0BC9B179D2B19akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-21_06:, , 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912210192 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-21_06:2019-12-17,2019-12-21 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011 lowpriorityscore=0 bulkscore=0 malwarescore=0 adultscore=0 impostorscore=0 priorityscore=1501 mlxlogscore=999 suspectscore=0 spamscore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912210191 Archived-At: Subject: Re: [lamps] Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect 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: Sat, 21 Dec 2019 21:39:25 -0000 --_000_06353CC6F30E47BE94C0BC9B179D2B19akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TUUgYWxzby4NCg0KRnJvbTogUnVzcyBIb3VzbGV5IDxob3VzbGV5QHZpZ2lsc2VjLmNvbT4NCkRh dGU6IFNhdHVyZGF5LCBEZWNlbWJlciAyMSwgMjAxOSBhdCA0OjI5IFBNDQpUbzogVGltIEhvbGxl YmVlayA8dGltLmhvbGxlYmVla0BkaWdpY2VydC5jb20+DQpDYzogInNwYXNtQGlldGYub3JnIiA8 c3Bhc21AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2xhbXBzXSBDYWxsIGZvciBBZG9wdGlvbiBv ZiBkcmFmdC1ob3VzbGV5LWxhbXBzLWNtcy11cGRhdGUtYWxnLWlkLXByb3RlY3QNCg0KT2YgY291 cnNlLCBJIGFtIGluIGZhdm9yIG9mIGFkb3B0aW5nIHRoaXMgZHJhZnQuDQoNClJ1c3MNCg0KDQoN Ck9uIERlYyAyMCwgMjAxOSwgYXQgMTA6MjggQU0sIFRpbSBIb2xsZWJlZWsgPHRpbS5ob2xsZWJl ZWtAZGlnaWNlcnQuY29tPG1haWx0bzp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbT4+IHdyb3Rl Og0KDQoNClBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlvdSBzdXBwb3J0IGFkb3B0aW9uIG9mIENh bGwgZm9yIEFkb3B0aW9uIG9mIGRyYWZ0LWhvdXNsZXktbGFtcHMtY21zLXVwZGF0ZS1hbGctaWQt cHJvdGVjdCBieSB0aGUgTEFNUFMgV0cgYnkgSmFudWFyeSAxN3RoLg0KDQotVGltDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU3Bhc20gbWFpbGluZyBs aXN0DQpTcGFzbUBpZXRmLm9yZzxtYWlsdG86U3Bhc21AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwYXNtDQoNCg== --_000_06353CC6F30E47BE94C0BC9B179D2B19akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NRSBhbHNvLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+UnVzcyBIb3VzbGV5ICZsdDtob3VzbGV5QHZpZ2lsc2Vj LmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+U2F0dXJkYXksIERlY2VtYmVyIDIxLCAyMDE5IGF0 IDQ6MjkgUE08YnI+DQo8Yj5UbzogPC9iPlRpbSBIb2xsZWJlZWsgJmx0O3RpbS5ob2xsZWJlZWtA ZGlnaWNlcnQuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7c3Bhc21AaWV0Zi5vcmcmcXVv dDsgJmx0O3NwYXNtQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW2xhbXBz XSBDYWxsIGZvciBBZG9wdGlvbiBvZiBkcmFmdC1ob3VzbGV5LWxhbXBzLWNtcy11cGRhdGUtYWxn LWlkLXByb3RlY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T2YgY291cnNlLCBJIGFtIGluIGZhdm9yIG9mIGFkb3B0aW5nIHRoaXMgZHJhZnQu IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UnVzczxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBEZWMgMjAsIDIw MTksIGF0IDEwOjI4IEFNLCBUaW0gSG9sbGViZWVrICZsdDs8YSBocmVmPSJtYWlsdG86dGltLmhv bGxlYmVla0BkaWdpY2VydC5jb20iPnRpbS5ob2xsZWJlZWtAZGlnaWNlcnQuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBs ZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlvdSBzdXBwb3J0IGFkb3B0aW9uIG9mIENhbGwgZm9yIEFk b3B0aW9uIG9mIGRyYWZ0LWhvdXNsZXktbGFtcHMtY21zLXVwZGF0ZS1hbGctaWQtcHJvdGVjdCBi eSB0aGUgTEFNUFMgV0cgYnkgSmFudWFyeSAxNzxzdXA+dGg8L3N1cD4uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1UaW08bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KU3Bhc20gbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxh IGhyZWY9Im1haWx0bzpTcGFzbUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6Izk1NEY3MiI+U3Bhc21AaWV0Zi5vcmc8L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNh Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zcGFzbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2 ZXRpY2E7Y29sb3I6Izk1NEY3MiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zcGFzbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_06353CC6F30E47BE94C0BC9B179D2B19akamaicom_-- From nobody Sat Dec 21 18:21:09 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 6253512008C for ; Sat, 21 Dec 2019 18:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Uzv2TEx/; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=wi7obhAr 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 VqnvyphpzT3D for ; Sat, 21 Dec 2019 18:21:05 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CBBC120072 for ; Sat, 21 Dec 2019 18:21:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13126; q=dns/txt; s=iport; t=1576981265; x=1578190865; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Q3G6gZ5Zs4DxZBYxTcGUDVXpLFJh3ymkK9Lq4vNX5ak=; b=Uzv2TEx/d2Qu+opw0KbXJ30NTIIY/B2ThMtztO+u9v4NT5YywmDFBMbs mlXhR++gFwh3ot6cpR6OGFtQHWynDuS14lu8/1KYb86QJoz2N4Hn2tNBH DZDeyo56xehx+HIsJfx9EIsQ1E2M/+17x4gKwfMBNu/vXGDHdqMy/8G4G Y=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3ASN2exxADMsRx5SQaeWFZUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNP3jajQzGs1qX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BoAAAr0v5d/51dJa1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWgHAQELAYEdL1AFbCstIAQLKoQHg0YDhFqGHYJfhzuLbIRhgS6?= =?us-ascii?q?BJANUAgcBAQEJAwEBGAEKCgIBAYRAAoIcJDQJDgIDDQEBBAEBAQIBBQRthTc?= =?us-ascii?q?MhV4BAQEEAQEQCwYKEwEBLAsBDwIBCBEDAQEBKAMCAgIlCxQJCAEBBAENBQg?= =?us-ascii?q?GFIMBgXlNAx8PAQIMoE4CgTiIYXWBMoJ+AQEFhSEYggUHAwaBNgGBUopGGoF?= =?us-ascii?q?BP4FYgkw+gmQBAYFlHg0JgloygiyQOoZciFyPIgqCNINhgjeQHIJGh3uQFoh?= =?us-ascii?q?VhX2BRpkQAgQCBAUCDgEBBYFSOYFYcBU7gmxQGA2NEoNzhRSFP3SBKJIDAQE?= X-IronPort-AV: E=Sophos;i="5.69,342,1571702400"; d="p7s'?scan'208,217";a="395496192" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Dec 2019 02:21:04 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xBM2L4DP013662 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 22 Dec 2019 02:21:04 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 21 Dec 2019 20:21:03 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 21 Dec 2019 20:21:03 -0600 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 21 Dec 2019 20:21:02 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a+ZrzM54qH8rkOiBsXMbeebbHcXZSIL+pC3XaOGmI2coYLTqKV9DRCGGrhQlwijl4WIs0XPgms99xZ74gDZxI+zA1Aw9P+RUgTv2TRicyGIyI/gG45eSt783C7YkFrBcueMBvNe5qA3MOMh6I+/RUGav+Niko/lzhV6/uXTbmGdpSXckJmhTFnwbPn78/6c3rO9LqTNlVA9Z+6pCmKzDrZ6ieYRb+LPmEONwFKWBGRndg/daV/6S3x+FDtmL//2mxHek0doR0feYd1HlrhHIIY/WsL+PJCtRUi85utGKEr9W8Efudyf/vOUp5V3G33OygUOCSGW186xEcj8/mnf0wA== 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=guAzYdwGinRoz9j3n4//Rsv1XPu4s3bKBrwwrPICdFk=; b=jW+xhd561Yf1hWHwEVVIbXicNjaGQQyS94HrTviIPIyYoJKIHE6CCJZRT0UZ/gKZkUx2cWvF+I0TE8kCIns5AZhLfDuQxhhdfWh/iTI6DhBzldOAcj32+D3Ij+LVagz5gkyjgMbEliu1uWXMj8FRpNMPiq9u61csl7DyJc+1rbjvBGW3pPRoO41acnSN8Kzj6DID40ZjOTHSxFsY/tfaaGx7nQ2fgpQQanYh2vu81o0rvE2F1JQbrFc1qWd9z9a2AJ0RAQAcZ9bh8buUu8ks/cUbjtxcb9YDbSnIjTOIk15Z5rJhEEHgSNup11qDC9WCrxWJeZ+VQcXZ+A3pCU7Q6A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=guAzYdwGinRoz9j3n4//Rsv1XPu4s3bKBrwwrPICdFk=; b=wi7obhArgbLPyyewlcF0JAsU47Epe1sCqo7IMSrv2NIUawocAWK7qub7zul+yXql1PUkZkjdrzCz6CjXgQ2L6gv8ptmrzDbqSLtioZ+IlF4i4dpKz7t8PNTn1CQL7DafWa9/8sbmlVzqakeViQp/l0rZsOODwASi5xzO9b4ycVE= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2580.namprd11.prod.outlook.com (52.135.246.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14; Sun, 22 Dec 2019 02:21:02 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2559.017; Sun, 22 Dec 2019 02:21:01 +0000 From: "Panos Kampanakis (pkampana)" To: "Salz, Rich" , Russ Housley , "Tim Hollebeek" CC: SPASM Thread-Topic: [lamps] Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect Thread-Index: AdW3SgT7TzvannoqRPuIFXJ92Hzy6QA+7nGAAABWboAACdKYMA== Date: Sun, 22 Dec 2019 02:21:01 +0000 Message-ID: References: <9B4B40AF-D7F0-4815-BE71-F4E930251A05@vigilsec.com> <06353CC6-F30E-47BE-94C0-BC9B179D2B19@akamai.com> In-Reply-To: <06353CC6-F30E-47BE-94C0-BC9B179D2B19@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1004::3d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 699e9cd7-b9ad-44a4-a61c-08d786859700 x-ms-traffictypediagnostic: BN7PR11MB2580: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3968; x-forefront-prvs: 02596AB7DA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(366004)(396003)(39860400002)(189003)(199004)(5660300002)(33656002)(76116006)(110136005)(966005)(478600001)(6506007)(186003)(53546011)(71200400001)(52536014)(55016002)(7696005)(9686003)(2906002)(4326008)(8936002)(66556008)(81166006)(66616009)(81156014)(66476007)(8676002)(66446008)(86362001)(66946007)(15650500001)(316002)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2580; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EuXQXTp3YpRO6vO3Ri3EAlucBBMl1qEf+kLGTqqXIdXdmoWRinpMWPcPsQFde+xNwDwEDDPa3AvPR7SezAnrvleMdtztmyoSE1EeecBP3xZRHWHB7jovDel2BUUk7fG6/Bh+8LGiNxWYi52XwrR61vlm0vDV1zse/tDZtPpMLPeuprj02bQ+R0nO2T3WTm6M50hgF2vrazD5Z+gqhUekoKwNoWIMSzo1SaPSm5AdCNTVmUHkGOURX5siAVFxM+aYUnorCQ8a13+tqHl0Cen1NToQFxrCl0BLruRuqUFJxdYY4uplrhVEDvsD/fEGjlnXj7x9s/rRng0T0EHWUkGvPHOztQMqVuP6YdqYzKzpcA76IUNarGxl79p4Bx9wQT0Qf06tnzrf455kRCPVeevW/jPO4vDECYfrBsNljRDlrwHDSYdNdmW/RR2PWF3stWK/b9K+S0MQcLq5AAjh+IBKDpLuSU+t2C64Au5om2z9+nA= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0007_01D5B844.8AA90FC0" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 699e9cd7-b9ad-44a4-a61c-08d786859700 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2019 02:21:01.6709 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fUeuLS/+A7aQvqPcN7r4maocRCpomoBiWeUrgrJSp0cm5SSBSUjUhTwbwizI1bwbWLbEI5ty9Tdgh8Lh7mlYuA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2580 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [lamps] Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect 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: Sun, 22 Dec 2019 02:21:07 -0000 ------=_NextPart_000_0007_01D5B844.8AA90FC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01D5B844.8AA90FC0" ------=_NextPart_001_0008_01D5B844.8AA90FC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit +1. I am willing to review. From: Spasm On Behalf Of Salz, Rich Sent: Saturday, December 21, 2019 4:39 PM To: Russ Housley ; Tim Hollebeek Cc: SPASM Subject: Re: [lamps] Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect ME also. From: Russ Housley > Date: Saturday, December 21, 2019 at 4:29 PM To: Tim Hollebeek > Cc: "spasm@ietf.org " > Subject: Re: [lamps] Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect Of course, I am in favor of adopting this draft. Russ On Dec 20, 2019, at 10:28 AM, Tim Hollebeek > wrote: Please indicate whether you support adoption of Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect by the LAMPS WG by January 17th. -Tim _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm ------=_NextPart_001_0008_01D5B844.8AA90FC0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

+1.

I am willing to = review.

 

From: Spasm = <spasm-bounces@ietf.org> On Behalf Of Salz, = Rich
Sent: Saturday, December 21, 2019 4:39 PM
To: = Russ Housley <housley@vigilsec.com>; Tim Hollebeek = <tim.hollebeek@digicert.com>
Cc: SPASM = <spasm@ietf.org>
Subject: Re: [lamps] Call for Adoption = of = draft-housley-lamps-cms-update-alg-id-protect

<= p class=3DMsoNormal> 

ME = also.

 

From: Russ Housley <housley@vigilsec.com>
D= ate: Saturday, December 21, 2019 at 4:29 PM
To: Tim = Hollebeek <tim.hollebeek@digicert.com= >
Cc: "spasm@ietf.org" <spasm@ietf.org>
Subject: = Re: [lamps] Call for Adoption of = draft-housley-lamps-cms-update-alg-id-protect

=

 

Of course, I am in favor of adopting this draft. =

 

Russ

 

 

On Dec 20, 2019, at 10:28 AM, Tim Hollebeek <tim.hollebeek@digicert.com= > wrote:

 

 

Please indicate whether you support adoption of Call = for Adoption of draft-housley-lamps-cms-update-alg-id-protect by the = LAMPS WG by January 17th.

 

-Tim

____________= ___________________________________
Spasm mailing list
Spasm@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/spasm">https://www.ietf.org/mailman/listinfo/spasm

 

------=_NextPart_001_0008_01D5B844.8AA90FC0-- ------=_NextPart_000_0007_01D5B844.8AA90FC0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTkxMjIyMDIyMTAwWjAvBgkqhkiG9w0BCQQxIgQgEbfQnxDxFWEuRwsKULEBdNuy2xx8iIno z3UMkBP93j4wSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA XlPIiSR08QVXhZ1K62tZRC5p5EaY0T0qQ18J3gRWrH7HpDIZ5BFa7aFOgv/eVAjc0XxdXfEePS7v AGkRjiUmZq5Te72f8I7+0EDkwmP+206NTj0z0B6qqj2pI6JBjiQcsZwVKoRcYfih+4J0j0IUBW5c nzE9eQh9YLSTOLWewXyIJs8SJUceQC98wl1O1HFgkSvmVrr8TshpnyPvWTVWy5g1dUgB1S575/Dx Mq7msE6xBFibK6WKreVAlAK2dkP/kBTUFdySuDQKuFgMZL78Odeao/nqZm8+hueiJ1tRypdESd1K yZh0arRaM6jUHjcie8MkYI4tHnQqJQpWaRxKkgAAAAAAAA== ------=_NextPart_000_0007_01D5B844.8AA90FC0-- From nobody Sun Dec 22 18:46:57 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 B870E12006F for ; Sun, 22 Dec 2019 18:46:55 -0800 (PST) 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 KAiYyNYULtXA for ; Sun, 22 Dec 2019 18:46:54 -0800 (PST) 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 A7C83120025 for ; Sun, 22 Dec 2019 18:46:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1EB78300A3B for ; Sun, 22 Dec 2019 21:46:53 -0500 (EST) 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 jHTzK2oucakT for ; Sun, 22 Dec 2019 21:46:52 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 3777630022B for ; Sun, 22 Dec 2019 21:46:52 -0500 (EST) 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: Sun, 22 Dec 2019 21:46:52 -0500 References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> To: LAMPS WG In-Reply-To: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] Call For Adoption of draft-richardson-lamps-rfc7030est-clarify 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, 23 Dec 2019 02:46:56 -0000 Please indicate whether you support adoption of = draft-richardson-lamps-rfc7030est-clarify by the LAMPS WG by January = 3rd. I previously sent a message with this correct subject, but the body = contained the wrong draft name. This restarts the call with a new date. Russ From nobody Sun Dec 22 18:56:59 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 AAA62120073 for ; Sun, 22 Dec 2019 18:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ouzWohKbXv2C for ; Sun, 22 Dec 2019 18:56:55 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 8D9EC12006F for ; Sun, 22 Dec 2019 18:56:55 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 25CA68AF9D2F8DAA7BA9 for ; Mon, 23 Dec 2019 02:56:52 +0000 (GMT) Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 23 Dec 2019 02:56:51 +0000 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml705-chm.china.huawei.com (10.98.57.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 23 Dec 2019 10:56:49 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1713.004; Mon, 23 Dec 2019 10:56:49 +0800 From: "Panwei (William)" To: LAMPS WG CC: "housley@vigilsec.com" Thread-Topic: [lamps] Call For Adoption of draft-richardson-lamps-rfc7030est-clarify Thread-Index: AQHVuTtCIJ0oQy+IXkGNrnIU4LI1u6fHBSqQ Date: Mon, 23 Dec 2019 02:56:48 +0000 Message-ID: References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.33.152] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [lamps] Call For Adoption of draft-richardson-lamps-rfc7030est-clarify 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, 23 Dec 2019 02:56:58 -0000 SGkgYWxsLA0KDQpBcyBhIGNvLWF1dGhvciwgSSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlz IGRyYWZ0Lg0KDQpCdXQgSSBhbHNvIHN1c3BlY3QgdGhhdCBtYW55IHBlb3BsZSBtYXkgbm90IG5v dGljZSB0aGlzIGFkb3B0aW9uIGNhbGwgYmVjYXVzZSBvZiB0aGUgQ2hyaXN0bWFzIGhvbGlkYXku DQoNClJlZ2FyZHMgJiBUaGFua3MhDQrFy86wIFdlaSBQYW4NCruqzqq8vMr109DP3rmry74gSHVh d2VpIFRlY2hub2xvZ2llcyBDby4sIEx0ZC4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IFNwYXNtIFttYWlsdG86c3Bhc20tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFJ1c3MgSG91c2xleQ0KPiBTZW50OiBNb25kYXksIERlY2VtYmVyIDIzLCAyMDE5IDEw OjQ3IEFNDQo+IFRvOiBMQU1QUyBXRyA8c3Bhc21AaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFtsYW1w c10gQ2FsbCBGb3IgQWRvcHRpb24gb2YNCj4gZHJhZnQtcmljaGFyZHNvbi1sYW1wcy1yZmM3MDMw ZXN0LWNsYXJpZnkNCj4gDQo+IFBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlvdSBzdXBwb3J0IGFk b3B0aW9uIG9mDQo+IGRyYWZ0LXJpY2hhcmRzb24tbGFtcHMtcmZjNzAzMGVzdC1jbGFyaWZ5IGJ5 IHRoZSBMQU1QUyBXRyBieSBKYW51YXJ5IDNyZC4NCj4gDQo+IEkgcHJldmlvdXNseSBzZW50IGEg bWVzc2FnZSB3aXRoIHRoaXMgY29ycmVjdCBzdWJqZWN0LCBidXQgdGhlIGJvZHkNCj4gY29udGFp bmVkIHRoZSB3cm9uZyBkcmFmdCBuYW1lLiAgVGhpcyByZXN0YXJ0cyB0aGUgY2FsbCB3aXRoIGEg bmV3IGRhdGUuDQo+IA0KPiBSdXNzDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBTcGFzbSBtYWlsaW5nIGxpc3QNCj4gU3Bhc21AaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcGFzbQ0K From nobody Mon Dec 23 08:29: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 6902D12097F for ; Mon, 23 Dec 2019 08:29:55 -0800 (PST) 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 2GvFqLWh633s for ; Mon, 23 Dec 2019 08:29:53 -0800 (PST) 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 BE6D512097D for ; Mon, 23 Dec 2019 08:29:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 357C6300B23 for ; Mon, 23 Dec 2019 11:29:52 -0500 (EST) 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 4XRoYl6e_VLu for ; Mon, 23 Dec 2019 11:29:50 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id AA36F3001D6; Mon, 23 Dec 2019 11:29:50 -0500 (EST) 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: <87r20ya78o.fsf@fifthhorseman.net> Date: Mon, 23 Dec 2019 11:29:51 -0500 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <4AE80A23-9698-4C6D-8DE9-320AAEA71E10@vigilsec.com> References: <878sodm0j3.fsf@fifthhorseman.net> <23953F0E-F919-4BBD-998F-11FF0DDBD95F@vigilsec.com> <87r20ya78o.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] LAMPS sample keys and certificates 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, 23 Dec 2019 16:29:55 -0000 A comment about Section 8.6: Triple-Wrapping was never envisioned as a = mechanism for integrity protection of mail header. Rather, when a mail = list agent is involved, the outermost signature is applied by the mail = list agent to protect the mail list expansion history. This history is = needed to detect loops. Russ > On Dec 20, 2019, at 6:48 PM, Daniel Kahn Gillmor = wrote: >=20 > Hi LAMPS folks-- >=20 > On Thu 2019-12-19 18:32:28 -0500, Russ Housley wrote: >=20 >> We set a goal at IETF 106 of learning how different user agents = handle >> the two approaches to header protection. I would like to see reports >> on the mail list so that we can choose a way forward. Please help! >=20 > Thanks for the nudge, Russ. Turns out i've learned a lot more about > S/MIME than i ever wanted to know, in the process of creating S/MIME > test vectors for the Autocrypt-style protected headers. >=20 > I've just published > = https://www.ietf.org/id/draft-autocrypt-lamps-protected-headers-02.html >=20 > =46rom the in-document changelog: >=20 >=20 > Significant changes between version -01 and -02: >=20 > - Added S/MIME test vectors in addition to PGP/MIME >=20 > - Legacy Display parts should now be text/plain and not > text/rfc822-headers (see > https://github.com/autocrypt/protected-headers/issues/23) >=20 > - Cryptographic Payload must have protected-headers parameter set > to v1 (see > https://github.com/autocrypt/protected-headers/issues/21) >=20 > - Test vector sample Message-Ids have been normalized >=20 > - Added encrypted-only (unsigned) test vectors, at the suggestion = of > Russ Housley >=20 > In addition, the test vectors are programmatically available at: >=20 > imap://bob@protected-headers.cmrg.net/inbox >=20 > (use any password, should be a read-only mailbox, with ephemeral IMAP > tags) >=20 > I'm asking folks who have clients capable of handling cryptographic > e-mail (either S/MIME or PGP/MIME or both, you don't have to handle > everything!) to submit screenshots! >=20 > It should be useful to collect screenshots following the guidance > outlined here: >=20 > = https://github.com/autocrypt/protected-headers/tree/master/screenshots >=20 > If you'd an example, take a look at the Thunderbird + Enigmail > screenshots here: >=20 > = https://github.com/autocrypt/protected-headers/tree/master/screenshots/thu= nderbird%2Benigmail/68.3.1%2B2.1.3 >=20 > I'd appreciate any feedback about this work, particularly on: >=20 > - the screenshot process (can we make it easier for people to generate > screenshots from a given client)? >=20 > - the test vectors themselves (are problems with any of them? do they > follow the draft correctly?) >=20 > - the text in the draft (as an implementer, is it easy to understand > and implement)? >=20 > Regards, >=20 > --dkg From nobody Mon Dec 23 12:15: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 8A0E3120863 for ; Mon, 23 Dec 2019 12:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=XxJbUjCw; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=fb++meNE 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 a0LXqcu9l1df for ; Mon, 23 Dec 2019 12:15:13 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D0DB12004E for ; Mon, 23 Dec 2019 12:15:13 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1577132112; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=zeVjDeI0wgTgqEjLNOvw3ZxTuvz9J3CaQ6xmjGGdfv8=; b=XxJbUjCw1PN3NL+If+mifcA9RNy4ibo7poXLE5Rz1ry6qZvT3/abKYkW qmxmZx6FTBlbQoYqPVMVcJbURZZLAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1577132112; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=zeVjDeI0wgTgqEjLNOvw3ZxTuvz9J3CaQ6xmjGGdfv8=; b=fb++meNExiB6tceIE803VLgROouZbZLVZLEEU7aGD1VMfxuyHdW1qQL2 JGwXuVcYdme62vMiv6CMG1ANIXEbWARo0N0VbmOqf1UkRXrO0WLdztHdbm Ib8YYHykyBIM7kNo1hTYZlL64n8UbbVbYcgW2sPOnpx41YuEg1bmIZHVVh HOzoBNLCc/vtrL9dkJEKbsqqdH9sChHHkLyazeWD+OF3GR1iSGW1MUIQtO jTeUldcgeNy1l+P+h423jf3iw8t34i13378d1y28GBRfXErtApM7JpLMWH EiLM3guBvVhhfvZ2JrTc/vpN5G0rnbP3NYtcOemdta8vHBMerBQHig== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 1CABEF9A5 for ; Mon, 23 Dec 2019 15:14:41 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 570182040A; Mon, 23 Dec 2019 13:47:46 -0500 (EST) From: Daniel Kahn Gillmor To: Russ Housley Cc: LAMPS WG In-Reply-To: <4AE80A23-9698-4C6D-8DE9-320AAEA71E10@vigilsec.com> References: <878sodm0j3.fsf@fifthhorseman.net> <23953F0E-F919-4BBD-998F-11FF0DDBD95F@vigilsec.com> <87r20ya78o.fsf@fifthhorseman.net> <4AE80A23-9698-4C6D-8DE9-320AAEA71E10@vigilsec.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Mon, 23 Dec 2019 13:47:45 -0500 Message-ID: <877e2manfy.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] LAMPS sample keys and certificates 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, 23 Dec 2019 20:15:14 -0000 --=-=-= Content-Type: text/plain On Mon 2019-12-23 11:29:51 -0500, Russ Housley wrote: > A comment about Section 8.6: Triple-Wrapping was never envisioned as a > mechanism for integrity protection of mail header. Rather, when a > mail list agent is involved, the outermost signature is applied by the > mail list agent to protect the mail list expansion history. This > history is needed to detect loops. Thanks for the feedback, Russ. I've actually heard people contemplating the use of triple-wrapping for providing cryptographic authenticity and integrity in a non-mail-list context as well, but i've hardly ever seen it used in practice. If you have any suggested text amendments for this section, i'd be happy to incorporate your feedback. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXgEL0gAKCRB2GBllKa5f +HI/AP43wr6CKqgerJiRlWlIYEZ2rhkeKapKwbaeyN0LHyHCOgEAmyBZOpsr8Nwt cO4PbdW5+PuY1tIcDE3SbLK7j4G1AQE= =bfQK -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 24 08:55:47 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 367C91200A1 for ; Tue, 24 Dec 2019 08:55:45 -0800 (PST) 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 hyIpXlXTiBi3 for ; Tue, 24 Dec 2019 08:55:43 -0800 (PST) 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 A481212009C for ; Tue, 24 Dec 2019 08:55:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E0B7D300B2F for ; Tue, 24 Dec 2019 11:55:41 -0500 (EST) 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 Ful7bB6__KkF for ; Tue, 24 Dec 2019 11:55:40 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id B447C300A9E; Tue, 24 Dec 2019 11:55:40 -0500 (EST) 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: <877e2manfy.fsf@fifthhorseman.net> Date: Tue, 24 Dec 2019 11:55:41 -0500 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <6CD5B115-345B-49B1-AF54-BBD6888096AE@vigilsec.com> References: <878sodm0j3.fsf@fifthhorseman.net> <23953F0E-F919-4BBD-998F-11FF0DDBD95F@vigilsec.com> <87r20ya78o.fsf@fifthhorseman.net> <4AE80A23-9698-4C6D-8DE9-320AAEA71E10@vigilsec.com> <877e2manfy.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] LAMPS sample keys and certificates 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, 24 Dec 2019 16:55:45 -0000 > On Dec 23, 2019, at 1:47 PM, Daniel Kahn Gillmor = wrote: >=20 > On Mon 2019-12-23 11:29:51 -0500, Russ Housley wrote: >> A comment about Section 8.6: Triple-Wrapping was never envisioned as = a >> mechanism for integrity protection of mail header. Rather, when a >> mail list agent is involved, the outermost signature is applied by = the >> mail list agent to protect the mail list expansion history. This >> history is needed to detect loops. >=20 > Thanks for the feedback, Russ. I've actually heard people = contemplating > the use of triple-wrapping for providing cryptographic authenticity = and > integrity in a non-mail-list context as well, but i've hardly ever = seen > it used in practice. >=20 > If you have any suggested text amendments for this section, i'd be = happy > to incorporate your feedback. I propose: [RFC2634] defines "Triple Wrapping" as a means of providing cleartext = signatures over signed and encrypted material. A mail list agent uses = triple wrapping to sign is the mail list expansion history. Others have = observed that triple wrapping could be used in combination with the = mechanism described in [RFC7508] to authenticate some headers for = transport using S/MIME. Russ From nobody Tue Dec 24 09:54:14 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 7BCB712011D for ; Tue, 24 Dec 2019 09:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=vdHRSM5+; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=fEg/bHCs 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 wd6nitmxVJ8j for ; Tue, 24 Dec 2019 09:54:09 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B591120868 for ; Tue, 24 Dec 2019 09:54:09 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1577210048; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=aoDu7hB6b9lodz3lR/MjFwqUvOrWbad+0+YCCnuThtw=; b=vdHRSM5+fMoyrHK485UpbMZIRRApQCViquXeuGaVIECH/mqihZMbB7ZJ ixgx41c0pgXjAhMnIL5E22dI698xAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1577210048; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=aoDu7hB6b9lodz3lR/MjFwqUvOrWbad+0+YCCnuThtw=; b=fEg/bHCsLD8horoi1lPSPSV+BefGF2ZKWrQO3m/CKsp2KSN3pkN6RD5e hnfFAGf7LeAOVzqL1LLn4tuMjHeHumgwNRamvC/Ms0CTDmtaJXwpMDmUQx UaA6GUAAO1200NakuXYKCNHc8ZSVTMyGVlIxFuy97nxL31t1rpskyEBKsh kQv7BmhXh7KFpP4fL2X4EBBrVMPUrAREiBGoUybXrmwmZMO+zbJH2u7Rpm UMw7/EBJmrjkVlvF7YtqZH4GS9aEO3AJcMIT8YRzu7MQkTQxQsCOz48l/5 QVEhDVAGf4RSd8OjxeyxB85YPcJFQZqEMMfMyD/6+BR82X+1Lc1o5Q== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 2E240F9A5 for ; Tue, 24 Dec 2019 12:53:37 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id BB95620433; Tue, 24 Dec 2019 12:53:35 -0500 (EST) From: Daniel Kahn Gillmor To: Russ Housley Cc: LAMPS WG In-Reply-To: <6CD5B115-345B-49B1-AF54-BBD6888096AE@vigilsec.com> References: <878sodm0j3.fsf@fifthhorseman.net> <23953F0E-F919-4BBD-998F-11FF0DDBD95F@vigilsec.com> <87r20ya78o.fsf@fifthhorseman.net> <4AE80A23-9698-4C6D-8DE9-320AAEA71E10@vigilsec.com> <877e2manfy.fsf@fifthhorseman.net> <6CD5B115-345B-49B1-AF54-BBD6888096AE@vigilsec.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Tue, 24 Dec 2019 12:53:35 -0500 Message-ID: <87pngd8va8.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] LAMPS sample keys and certificates 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, 24 Dec 2019 17:54:12 -0000 --=-=-= Content-Type: text/plain On Tue 2019-12-24 11:55:41 -0500, Russ Housley wrote: > [RFC2634] defines "Triple Wrapping" as a means of providing cleartext > signatures over signed and encrypted material. A mail list agent uses > triple wrapping to sign is the mail list expansion history. I think "is" is a misplaced word here and can be dropped, right? > Others have observed that triple wrapping could be used in combination > with the mechanism described in [RFC7508] to authenticate some headers > for transport using S/MIME. Thanks! I've pushed this change into the latest draft, modulo the grammar fix above. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXgJQnwAKCRB2GBllKa5f +OMFAP95Ld9n0VLCDLXTFLiYnH0ipOapMCB4ZSjUM7lFhi7IEgD/auIYbsv4OSpl SEueAlWrcDkzfYIcsm6zMtmch/RMBw0= =ayN7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 24 10:51:57 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 38AD9120168 for ; Tue, 24 Dec 2019 10:51:55 -0800 (PST) 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 N7WfQpZ4XC3G for ; Tue, 24 Dec 2019 10:51:53 -0800 (PST) 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 93987120125 for ; Tue, 24 Dec 2019 10:51:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2236F300B21 for ; Tue, 24 Dec 2019 13:51:52 -0500 (EST) 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 oW6Cu5j3Rji4 for ; Tue, 24 Dec 2019 13:51:51 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id ED210300464; Tue, 24 Dec 2019 13:51:50 -0500 (EST) From: Russ Housley Message-Id: <71C7FF07-3C62-4213-A411-558A15BE917D@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D4FB86C1-E7A0-4C08-AC2C-8841BFA19BEB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 24 Dec 2019 13:51:51 -0500 In-Reply-To: <87pngd8va8.fsf@fifthhorseman.net> Cc: LAMPS WG To: Daniel Kahn Gillmor References: <878sodm0j3.fsf@fifthhorseman.net> <23953F0E-F919-4BBD-998F-11FF0DDBD95F@vigilsec.com> <87r20ya78o.fsf@fifthhorseman.net> <4AE80A23-9698-4C6D-8DE9-320AAEA71E10@vigilsec.com> <877e2manfy.fsf@fifthhorseman.net> <6CD5B115-345B-49B1-AF54-BBD6888096AE@vigilsec.com> <87pngd8va8.fsf@fifthhorseman.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] LAMPS sample keys and certificates 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, 24 Dec 2019 18:51:55 -0000 --Apple-Mail=_D4FB86C1-E7A0-4C08-AC2C-8841BFA19BEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Dec 24, 2019, at 12:53 PM, Daniel Kahn Gillmor = wrote: >=20 > Signed PGP part > On Tue 2019-12-24 11:55:41 -0500, Russ Housley wrote: >> [RFC2634] defines "Triple Wrapping" as a means of providing cleartext >> signatures over signed and encrypted material. A mail list agent = uses >> triple wrapping to sign is the mail list expansion history. >=20 > I think "is" is a misplaced word here and can be dropped, right? Yes. Sorry, I did this very quickly between errands today. Russ --Apple-Mail=_D4FB86C1-E7A0-4C08-AC2C-8841BFA19BEB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCXgJeRwAKCRCK5O7Q9ZwR yy93AJ91hYm6ZkbquibrzbaB/S+ODD1qBQCg5kTfpwCWI741dldOWVqVYj2j9NM= =rcdr -----END PGP SIGNATURE----- --Apple-Mail=_D4FB86C1-E7A0-4C08-AC2C-8841BFA19BEB-- From nobody Thu Dec 26 08:54:36 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 0668A12004A; Thu, 26 Dec 2019 08:54:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: spasm@ietf.org, lamps-chairs@ietf.org, housley@vigilsec.com, rdd@cert.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157737927393.25216.7765851274566214157.idtracker@ietfa.amsl.com> Date: Thu, 26 Dec 2019 08:54:33 -0800 Archived-At: Subject: [lamps] lamps - Update to a Meeting Session Request for IETF 107 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: Thu, 26 Dec 2019 16:54:34 -0000 An update to a meeting session request has just been submitted by Russ Housley, a Chair of the lamps working group. --------------------------------------------------------- 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): 2 Hours Number of Attendees: 45 Conflicts to Avoid: Chair Conflict: ipwave stir suit Technology Overlap: acme cfrg ace Key Participant Conflict: oauth secdispatch saag sipbrandy tls mls teep People who must be present: Russ Housley Sean Turner Alexey Melnikov Roman Danyliw Bernie Hoeneisen Jim Schaad Tim Hollebeek Hendrik Brockhaus Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Dec 26 21:29:53 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 946E612004F for ; Thu, 26 Dec 2019 21:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=HNNKiV/A; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=FjGnd9Mq 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 eX11p9Ss6guX for ; Thu, 26 Dec 2019 21:29:50 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF78612001E for ; Thu, 26 Dec 2019 21:29:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6747; q=dns/txt; s=iport; t=1577424589; x=1578634189; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=fiiW+ww2HrNU06EP8wRAdkuB9bvTzlC3oBs1I0vnlBw=; b=HNNKiV/A5r367aWlGF8G9s65hwaYhiX5rFtKVwYG/apKVM07cdRDphCo hPDE/ROUqcdzTDPAYeKRCoMYgKNgsGOgN7H1UC4FUPjQB75QxyCPXJniO v/8p007Igz9dRBImmuGitlXC/478HBiVg36Hnf9a3ERGqWFi/AFx/Oz3H 8=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3Ay/+21xSqnp+SwfMhfg22p11Pg9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQ5FcFaXVls13q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2EgBslgVe/4YNJK1kH4IjgVRQBWw?= =?us-ascii?q?rLSAECyqHTgOKeE6CEZgJgS6BJANUAgcBAQEJAwEBGAsKAgEBhEACgh8kNQg?= =?us-ascii?q?OAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQEDAQEQCyMBASwMCwQCAQgRBAEBLwI?= =?us-ascii?q?lCx0IAgQBEggGFIMBgXlNAx8PAQIMn1oCgTiIYYIngn4BAQWFARiCBQcDBoE?= =?us-ascii?q?2gVOKRhqBQT+BWIJMPoJkAQGBZYNAgiyWOGGXfgqCNINhgjeQHIJGh3uQFo5?= =?us-ascii?q?SmlYCBAIEBQIOAQEFgVQCNYFYcBU7gmxQGA2RBYUUhT90gSiSJgEB?= X-IronPort-AV: E=Sophos;i="5.69,361,1571702400"; d="p7s'?scan'208";a="687707199" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Dec 2019 05:29:43 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id xBR5Th3U012220 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 Dec 2019 05:29:43 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 26 Dec 2019 23:29:42 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 26 Dec 2019 23:29:42 -0600 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 26 Dec 2019 23:29:42 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KUvkcBT98JD8t6fnSZY97u6BekExvuY6exgDijqovT/uFGJiwCm5LfVDkptzlQD0JZjHeyL5QP9XkPBHSnd7kWXV+sIAl4qWAQNlZbKU7Nj6ogh/NMFgzT3CEp3itg87Lcf9YC0pmU5wWUHTfFEkKaTpza/tkT7GSnTSyoOOoxBtny+jUgP1pb1KziW2LStF3vb8RBv5esq25TVpdx9154LE75kwJtrbj1SI/s3ieDgfuxrTTy+Bh6ux5TGm6uiuAbtGLEE8YM4WfZXWWeeFJfkg9iiGe74ujtX8US9bpsWfqXsCcztwHnSPDLxXTc2W/w5sIZLv5fdBy3pXwJ/U4A== 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=KPvcHmos9aT6QGHMc6zJ6sx8DR3nDRv5Ancnc30cMpo=; b=E4oVTQzr2UmB47sxAijTXwYxt/j7s7yw8VCfOQKglxVmXu4PVLCYB3/EQHN8/irFX6nE7EJw/2mh2SK3d/nc6CRcPG3c0cEg8RyAnL9z4zvr8UTZHk0uy+NgNkvKkEA3w0Qtn7+M/DlcrWiQzoFYRlAkDixvjMhJ79dU6PAxDFxZt7I/s5pCf0CKnIZ+g/2WagYYrQYA/5Oyalqr3RFEaeBwa64ZFFyJR8yoLpINQaIVJsS8gjpWZviF7dJwpvwyxzSW7E/LP6wTmwAB8qOot9hFindJDdSkBExO2ambfs6PE40JBYMSCssY/r1NZFx7MBcO1hrNngbcoSOCQJWxxA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KPvcHmos9aT6QGHMc6zJ6sx8DR3nDRv5Ancnc30cMpo=; b=FjGnd9Mqo2WQUfeoqoILAGxNZOS57HKmiXQYQXr0vmN/cn0iLmCkoUPi6bmTHn5jKtsESjOrrGOF70lW4/Q/LSA4YJO6O1e0h26H2ZTBuKzuTkcDIoFEV6Vk2ojEi12bViPCaen5gXB+65r908Gz6hE97GUHp4aOBkYY5AnjaJM= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2769.namprd11.prod.outlook.com (52.135.245.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11; Fri, 27 Dec 2019 05:29:42 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2581.007; Fri, 27 Dec 2019 05:29:41 +0000 From: "Panos Kampanakis (pkampana)" To: Russ Housley , LAMPS WG Thread-Topic: [lamps] Call For Adoption of draft-richardson-lamps-rfc7030est-clarify Thread-Index: AQHVuTs6CIsB1rxJbUWUDidg29Tqn6fNeLwQ Date: Fri, 27 Dec 2019 05:29:41 +0000 Message-ID: References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1003::61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dd2e121c-3660-4d7e-019c-08d78a8dc663 x-ms-traffictypediagnostic: BN7PR11MB2769: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0264FEA5C3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(346002)(136003)(396003)(189003)(199004)(13464003)(86362001)(8676002)(81156014)(966005)(76116006)(81166006)(8936002)(64756008)(66446008)(66556008)(66476007)(66946007)(66616009)(71200400001)(478600001)(2906002)(55016002)(7696005)(9686003)(186003)(110136005)(4744005)(316002)(53546011)(52536014)(5660300002)(33656002)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2769; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /Oe3zYVWw5HpZYngTivTjHmU+OwCB2Yt2OXP0jBwteu84vr91k/aacL+esBBynJt+48lgfSsHlwJQbvUu5jNRQ2+AwniZrn/8x729Hm1MxTHUAtqYtbcusZbI0cejy1Qanl035lr/Czm074ycadnj35jQwoNMSVkkm3MrTilq4MKu/EKJ+c6OlZJ0ZxOt+TU2hM3I+RcObHZq6JI2If+byJ3ENIAfj3T23z/+LEJOsS+ch2FGcci7Rxyo2SU3s4chN+iRsHzpvwbpNntmeODT594lfJpy19komEbzewJEeJ27AuFR5feFnFwpKUpCy2IYpd3KQNgAUanvMz2h17Ghzcv6XVWNAXWCx8u4+5SlS8hsyuMAOL9eYhBoMg8DWpu9JMiWU8waQVqprIRuquwdKgRGHI4J5Ssie3w0f0Ie3yM9Oy6LYuZjskHGpBH5iV15AhnualIUPAB889k7LjW3UVC9lHU9qK6HrCNugjBZ0KPxmhXuddAGVVy9FO37yJGTGwFvctDf9nDvSCq1Oe6kxFabQxtBvYq4ycdeRqtz98= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_000E_01D5BC4C.B8D46000" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: dd2e121c-3660-4d7e-019c-08d78a8dc663 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Dec 2019 05:29:41.4246 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ir2jHZFp+Jv1rGz0EqJ1s5p0xd8H18Nr7xXLxSrktHeH42Z3qhhwQCyHh4gTBmjkWqJn4cRVuiydgIwweCvNgg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2769 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [lamps] Call For Adoption of draft-richardson-lamps-rfc7030est-clarify 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, 27 Dec 2019 05:29:52 -0000 ------=_NextPart_000_000E_01D5BC4C.B8D46000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I support adoption for this draft to address RFC7030 errata and ASN.1 inconsistencies. The Abstract mentions GRASP discovery as well which falls out of scope for LAMPS imo though. Panos -----Original Message----- From: Spasm On Behalf Of Russ Housley Sent: Sunday, December 22, 2019 9:47 PM To: LAMPS WG Subject: [lamps] Call For Adoption of draft-richardson-lamps-rfc7030est-clarify Please indicate whether you support adoption of draft-richardson-lamps-rfc7030est-clarify by the LAMPS WG by January 3rd. I previously sent a message with this correct subject, but the body contained the wrong draft name. This restarts the call with a new date. Russ _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm ------=_NextPart_000_000E_01D5BC4C.B8D46000 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTkxMjI3MDUyOTM4WjAvBgkqhkiG9w0BCQQxIgQg7vDwniH9mlbhKPEJWGxeSt8y/sXHqgI5 Uxx37xz0X9kwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA NMgbyro/qAzD2w2wSy4412xtZIrOtexAiVE3i0GEs5l4+PoOBcYRPlrDQV+qNR9EN1+NCWtzuROY HqcgRM9Kam+J8E8qK8yohOTtGHBNWqllh/WmqygOmCxXXwHhreWfnPt6yAZtyev+PGM/EgHMCoSF U1GWSP+fhXmxbQFuQHHT4N3bGYWw3fqkosdpColtw21Ey95PgSvsf4T46XSUHnO/kh8CuYtI5sT3 gsTOD5yBmwJBMHYo38UKLZxaxihL9AagtIkFEvhaQ5wgCEiRosGSvTsQPtbiU0WyXNJ3ehG9k0C1 SLXfUmorndxyuw9OPf6bcMgCwArMxMEvFeAD6wAAAAAAAA== ------=_NextPart_000_000E_01D5BC4C.B8D46000-- From nobody Fri Dec 27 06:46: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 D88E1120052; Fri, 27 Dec 2019 06:46:37 -0800 (PST) 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 s_qWmBUC8Hik; Fri, 27 Dec 2019 06:46:36 -0800 (PST) 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 E866012004A; Fri, 27 Dec 2019 06:46:35 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CEE683897B; Fri, 27 Dec 2019 09:46:23 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C080BAAD; Fri, 27 Dec 2019 09:46:34 -0500 (EST) From: Michael Richardson To: "Panos Kampanakis \(pkampana\)" , anima@ietf.org, LAMPS WG In-Reply-To: References: <157429966624.922.6336772483106473689.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] Call For Adoption of draft-richardson-lamps-rfc7030est-clarify 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, 27 Dec 2019 14:46:38 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Panos Kampanakis (pkampana) wrote: > The Abstract mentions GRASP discovery as well which falls out of scope > for LAMPS imo though. Oh, yes. I never actually wrote the text to go with it, I will remove it! We actually don't need that as it turns out, as draft-ietf-anima-autonomic-= control-plane provides for that, but I didn't remember that last spring when I wrote the document. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4GGUoACgkQgItw+93Q 3WUW3Af+Ow7laqBwR0kXeRmZl1OgsIbV28XoIJES21yZ7O7kZuhX/vm+oFJLdHQm EVlML7oh9nK1NPArhno20jv8qZhi69Ugs1zRLsRycCiURfrrYEMhHlfjwubx3go4 Ya6dgk9yzv5kJmB5CFg/NboMhL3v0q+x5UU63rYt7XPogyfB3KDegvnQttsnTzkY S4D6VQlZZW9eYQ4EzQXfqdrHdMvMLrsSqxHiwW/GJ4S0Q/XWlb8K5t2eJwnF18PP B1Z09yN45tMl2LqdEI0wXt+BztGQijaB8QBhitQAlb+VudvLOv4dYBAj7sX8XxjX JaI6+LZ76VNy8V2qnGgCCsbLXxAVig== =36Do -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 27 17:16: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 5CA0B1200E5 for ; Fri, 27 Dec 2019 17:16:38 -0800 (PST) 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_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 elL_4jRiA7hr for ; Fri, 27 Dec 2019 17:16:37 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DDBE1200A1 for ; Fri, 27 Dec 2019 17:16:37 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6DD09F40742; Fri, 27 Dec 2019 17:16:27 -0800 (PST) To: housley@vigilsec.com, rdd@cert.org, kaduk@mit.edu, housley@vigilsec.com, tim.hollebeek@digicert.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: jarek198732@wp.pl, spasm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20191228011627.6DD09F40742@rfc-editor.org> Date: Fri, 27 Dec 2019 17:16:27 -0800 (PST) Archived-At: Subject: [lamps] [Editorial Errata Reported] RFC8649 (5947) 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: Sat, 28 Dec 2019 01:16:38 -0000 The following errata report has been submitted for RFC8649, "Hash Of Root Key Certificate Extension". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5947 -------------------------------------- Type: Editorial Reported by: jarek Section: 5 Original Text ------------- Corrected Text -------------- Notes ----- 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 can log in to change the status and edit the report, if necessary. -------------------------------------- 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 From nobody Fri Dec 27 19:02: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 C19251200B3 for ; Fri, 27 Dec 2019 19:02:41 -0800 (PST) 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 nHmWLlR4gQ6p for ; Fri, 27 Dec 2019 19:02:39 -0800 (PST) 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 BC836120086 for ; Fri, 27 Dec 2019 19:02:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D8346300B31 for ; Fri, 27 Dec 2019 22:02:37 -0500 (EST) 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 4-xfUlfpWCd4 for ; Fri, 27 Dec 2019 22:02:35 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 71E6D300B04; Fri, 27 Dec 2019 22:02:35 -0500 (EST) 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: <20191228011627.6DD09F40742@rfc-editor.org> Date: Fri, 27 Dec 2019 22:02:36 -0500 Cc: "Roman D. Danyliw" , Ben Kaduk , Tim Hollebeek , LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <20191228011627.6DD09F40742@rfc-editor.org> To: RFC Editor X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] [Editorial Errata Reported] RFC8649 (5947) 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: Sat, 28 Dec 2019 03:02:42 -0000 Looks like spam to me. Russ > On Dec 27, 2019, at 8:16 PM, RFC Errata System = wrote: >=20 > 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/eid5947 >=20 > -------------------------------------- > Type: Editorial > Reported by: jarek >=20 > Section: 5 >=20 > Original Text > ------------- >=20 >=20 > Corrected Text > -------------- >=20 >=20 > Notes > ----- >=20 >=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 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Sat Dec 28 09:58:21 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 14176120154; Sat, 28 Dec 2019 09:58:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157755589907.25722.15649636914410211833.idtracker@ietfa.amsl.com> Date: Sat, 28 Dec 2019 09:58:19 -0800 Archived-At: Subject: [lamps] The LAMPS WG has placed draft-housley-lamps-cms-update-alg-id-protect in state "Candidate for WG Adoption" 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: Sat, 28 Dec 2019 17:58:19 -0000 The LAMPS WG has placed draft-housley-lamps-cms-update-alg-id-protect in state Candidate for WG Adoption (entered by Russ Housley) The document is available at https://datatracker.ietf.org/doc/draft-housley-lamps-cms-update-alg-id-protect/ From nobody Sat Dec 28 17:09:03 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 0BD94120018 for ; Sat, 28 Dec 2019 17:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=sn3rd.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 U9UXXxd-ym1A for ; Sat, 28 Dec 2019 17:09:00 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 13BFD1201EF for ; Sat, 28 Dec 2019 17:09:00 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id t129so24085944qke.10 for ; Sat, 28 Dec 2019 17:09:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=afwTPMe1Ihx+N082QjQpVvmn9oHHBVU6bk036xNaVwM=; b=gsBb+fn3vVtnImRL66fxHdmBpvNicf9wxOrc6BesAeNDIOZPjL7uhU0ue3HX5cYWIQ gNA+oxkEsyRe3kEBOROBXOFTWsw4xuhi5VWctiBdIQHYwD4MfxTIQQDMZc5I+TMBPdJk Tdnuo4vXF9yfKul49Wc+vb5VzR4WRwK+h5V+I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=afwTPMe1Ihx+N082QjQpVvmn9oHHBVU6bk036xNaVwM=; b=qWzwcuAM9BVKjnaX5Za7YIXD6ZuMPf9fe5PvvoaOxgF60W2gAd/Wj+YCib7OSWZ9rO 9LAc35dGCH5IMbyxssS9MQWKnE9c6FaNxZeKNYOAfQRaLRQXrjCmuBQXG6X6pXyzLdrI v88mp4GSR1HwF7M9bKV+G80OcsA4Jw9q93cDAhfCqI3djZczIkCzmRMJeLvEmhdITTlR L81jDwN4l9ep3JBXeRCQ75SQZn62xOCy46pOOGUd8w1j/6y9EwWHUbJe64UkF8GRcj5j nyLmYSdeyYjJPTAx2kvP/6wqt02JJPDA4BSCzJN7+vIKNSFoYPXjJirgZlfbmsvQnzJf 9jSg== X-Gm-Message-State: APjAAAXIlfeAZKBR1uDXFDcBBqh+hYyZTSdYlasZtTORb7qm26lWvKNB SfduUlzIJ5qOYFYboWpAa+TXDg== X-Google-Smtp-Source: APXvYqzBnzcdULvv+ql3T8l8WiaR35McpxTW2K+8b2ylYFOra2kgRSzBzU1OH5cEtOW1X4ZFABBdpg== X-Received: by 2002:ae9:e702:: with SMTP id m2mr48859059qka.208.1577581739222; Sat, 28 Dec 2019 17:08:59 -0800 (PST) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id 13sm11056971qke.85.2019.12.28.17.08.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Dec 2019 17:08:58 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: Date: Sat, 28 Dec 2019 20:08:57 -0500 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <2B49CA74-D9A7-4E06-AF2B-889FD6DF748E@sn3rd.com> References: To: Tim Hollebeek X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect 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: Sun, 29 Dec 2019 01:09:02 -0000 Support adoption and will review. spt > On Dec 20, 2019, at 10:28, Tim Hollebeek = wrote: >=20 > =20 > Please indicate whether you support adoption of Call for Adoption of = draft-housley-lamps-cms-update-alg-id-protect by the LAMPS WG by January = 17th. > =20 > -Tim > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Sat Dec 28 21:35: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 1F480120178 for ; Sat, 28 Dec 2019 21:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=sn3rd.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 ag-deVc16DVc for ; Sat, 28 Dec 2019 21:35:01 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 53BDF120018 for ; Sat, 28 Dec 2019 21:35:01 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id l12so27583027qtq.12 for ; Sat, 28 Dec 2019 21:35:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3pBaHW8DISSUlQkYaBcw7vnQkEwKLz3CMuJzFe/W8d8=; b=B8153jyB31GmZd7uFZFZknyZJghZAzXHbCy1jWonN00s+D8ejeleuEs/+KEie86u8I G+5HaV4Jmxu+WjAJF6jsnayC91olmaMg0FgHFerJrGLk11XjzB2j3OsWr/d6GWK0ZGie VSHncVRuZjktJNc+21m0p++MRo2B/q0KkL4lk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3pBaHW8DISSUlQkYaBcw7vnQkEwKLz3CMuJzFe/W8d8=; b=edrGrB8U2DwA7IAmpVsPlW4z8gQLpWUIk1sXD//i5T6He1tFNpiscUteAuBC+GG9nB SLwxjJ/svyBpuzhiY3K8lTFDab28yZewWbXQtZFEgbzllJGXlM6LcgWS77nXXrPJBii+ KnNflQl3k2/HE9XKyiQV/Y7aeW7CrUeJ5WzJhVGI0AcBk0Eny5x5/0HbE7+bs7kCpFUi HRfawpBNfbVy/hBuV5U7CZvH3eejBoc5MesimmB1b94YoIZiVWiv/10UgMDqZeMgFAKC ZfkcwQ574d+KNQdohFZxXPEEPVVGWxV8marGks8NWHAM7cHAabOoemNVWYxWqkG1OAcb rpSw== X-Gm-Message-State: APjAAAUR9Y9MhggWUFAZwrBpAKpH0ZWm4O5OjhRiJnE2ZtTtH2wC6PpW zS8y4Ro9YdBEEjSPctFD9ikMag== X-Google-Smtp-Source: APXvYqwc7YoJsoBm8KYtaeZfcsGPdGC0qfLlE41rqzVUzTnfFTSM2qBczVDVNfZfaqZufYtfqQ59ww== X-Received: by 2002:aed:3786:: with SMTP id j6mr45214942qtb.62.1577597700519; Sat, 28 Dec 2019 21:35:00 -0800 (PST) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id w1sm12634993qtk.31.2019.12.28.21.34.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Dec 2019 21:35:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: Date: Sun, 29 Dec 2019 00:34:59 -0500 Cc: RFC Editor , Roman Danyliw , LAMPS WG , Benjamin Kaduk , Tim Hollebeek Content-Transfer-Encoding: quoted-printable Message-Id: <980768F9-4B7A-4951-BEC8-B2B0A72F92FC@sn3rd.com> References: <20191228011627.6DD09F40742@rfc-editor.org> To: Russ Housley X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] [Editorial Errata Reported] RFC8649 (5947) 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: Sun, 29 Dec 2019 05:35:03 -0000 Can we just delete this one? spt > On Dec 27, 2019, at 22:02, Russ Housley wrote: >=20 > Looks like spam to me. >=20 > Russ >=20 >=20 >> On Dec 27, 2019, at 8:16 PM, RFC Errata System = wrote: >>=20 >> 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/eid5947 >>=20 >> -------------------------------------- >> Type: Editorial >> Reported by: jarek >>=20 >> Section: 5 >>=20 >> Original Text >> ------------- >>=20 >>=20 >> Corrected Text >> -------------- >>=20 >>=20 >> Notes >> ----- >>=20 >>=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 >> _______________________________________________ >> 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