From nobody Wed Dec 2 08:40:38 2020 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 1E9553A147A for ; Wed, 2 Dec 2020 08:40:37 -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, 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 Mp7Wc4GNE5QX for ; Wed, 2 Dec 2020 08:40:35 -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 750E43A138F for ; Wed, 2 Dec 2020 08:40:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D35B4300B53 for ; Wed, 2 Dec 2020 11:40: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 ffjqUj8lMlOj for ; Wed, 2 Dec 2020 11:40:31 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 8425C300AB0 for ; Wed, 2 Dec 2020 11:40:31 -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.17\)) Message-Id: <6A1D7198-CC26-4082-B874-ACD36DD05482@vigilsec.com> Date: Wed, 2 Dec 2020 11:40:32 -0500 To: LAMPS X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: [lamps] NIST NCCoE Virtual Workshop on Considerations in Migrating to Post-Quantum Cryptographic Algorithms 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, 02 Dec 2020 16:40:37 -0000 On Wednesday, 7 October 2020, NIST NCCoE held a virtual workshop on = Considerations in Migrating to Post-Quantum Cryptographic Algorithms. = The workshop recording and presentation materials are now available. If = you were not at the workshop, I thought you might find the material = interesting. = https://www.nccoe.nist.gov/events/virtual-workshop-considerations-migratin= g-post-quantum-cryptographic-algorithms Russ= From nobody Wed Dec 2 13:09:38 2020 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 5530F3A14F2 for ; Wed, 2 Dec 2020 13:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=digicert.com header.b=ov3pN+hx; dkim=pass (1024-bit key) header.d=digicert.com header.b=vlwGxrYM 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 juAOsELKJ_9Y for ; Wed, 2 Dec 2020 13:09:35 -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 91ED73A153A for ; Wed, 2 Dec 2020 13:09:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1606943374; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ud4FO1p7wdFTuJKuBiTMjrZn+Goly7Uuc4lHo8Ytyxo=; b=ov3pN+hxaGcONi47LSPu1RtCZALpgTrapI5rX8T0jjTck/WBl79fR+oXIB1EMsvwazALm+ 5pXMkGnT0yAhN9OGZpLszg4tomdu8yC+RUq68adaz0ZBtMQhoq0Vr0RENgL35att9VjODq WHeQIuxvcmBIqBV01Msbobu2461nMNA= Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2170.outbound.protection.outlook.com [104.47.59.170]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-530-nDU-c8OdNsO7r_vktHcHeg-1; Wed, 02 Dec 2020 16:09:32 -0500 X-MC-Unique: nDU-c8OdNsO7r_vktHcHeg-1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aonVjLWqAt4rsw2zC/tZG8wmnWQ/aP6mPsDuD9USI04lw1oxwXxMxWPx6G0f1mAazgKqhgnwvmBl8Rn/Bp+7jowFaShATq5xMIxJR6+fqc0pZ+4G4GPL4oiJPtVXv3XgeBVQil6r9GWcjra7RsUfz3ctJyBMKYT3MtrMdcrYbIYm8g6aEv/QC9KcudBv+LekK1x87cWiI/B3Uhp1SZcOVMQ0PGnZ7SP4xE8YgqrpQRQd3eexURcul/UrwoUXYvYy2Oyi4UGfGiiubLnaZ8JDBhfPaG/v77p444STzExKvO0yppMeEOx/S7ISE3OUp4sAD2ZqeU/t68Mgk819qoVwNw== 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=ud4FO1p7wdFTuJKuBiTMjrZn+Goly7Uuc4lHo8Ytyxo=; b=Oafc0aYLk5IdDuyhE4hrCeWFasIrHF9YBQyZ8rKAGo632RfpwYBJbGiIRLcjWkKc0+05Zq/KAQLDC3ifQqGXYDawBS7kuEMfdHhK9nX6z6Xq4PCp2NMBBdYUOZ+/b4DD+o+k9jbo34L0cZmnXbojvAILUGBIQkR+MtN7yCVR52EQ0eZTyTdr7+zgJyDn+zWcBnUlZbIOY9HzXmWjuTEjwllUyyepUfxcjqHg8wL9fv515uaS0AAoF6Bbtbt2WsbjyXWCqdJdjPD3wM9Jf0/ulxQkfBg40aB0H5BBO00HxYsZFJQ5iJJThmD6vO1c6hvpAiP7NmgYw6NpQ0zTtL3m2g== 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=ud4FO1p7wdFTuJKuBiTMjrZn+Goly7Uuc4lHo8Ytyxo=; b=vlwGxrYMLRDp4Jyj7ZA7JB3FWxI8ArJUDf8/Uk/sSrVVEHjb+saBK9OQs/asNPi7xWt96I0EvBHnOdf4dRqzIy4VDCm16WisH3MlOfVn0tVTa1oTyqCy0Kfb0LGx2y0mvIAA4JCnxSdCMWbU1co8Lg/PyssMa1vSxO4lRmrLEZI= Received: from MN2PR14MB3167.namprd14.prod.outlook.com (2603:10b6:208:12e::28) by MN2PR14MB2493.namprd14.prod.outlook.com (2603:10b6:208:cf::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.20; Wed, 2 Dec 2020 21:09:25 +0000 Received: from MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::e1ea:51bf:a4b0:2f82]) by MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::e1ea:51bf:a4b0:2f82%7]) with mapi id 15.20.3632.017; Wed, 2 Dec 2020 21:09:25 +0000 From: Tim Hollebeek To: Tim Hollebeek , LAMPS Thread-Topic: Call for adoption of draft-housley-lamps-cms-aes-mac-alg Thread-Index: Ada5PUeDTi8Ao42uSE2MX/yt85ISNwPsfopg Date: Wed, 2 Dec 2020 21:09:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=digicert.com; x-originating-ip: [74.111.113.115] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 091d10a8-d308-401a-c88a-08d897068c78 x-ms-traffictypediagnostic: MN2PR14MB2493: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: js12wqjZZ6eeNRuAxPJnV35orTZdyuPl9nbUwPmwqU4d/66XaJuyGrHdXbuVPuM6Bw/X/5lL6xOOUxmJ5+gsIu6Ukv3MAHd4PCY4L5cKLpL3Pteit60nhGIxYh+fqiWfs1h79vVbR+qsD2KYT9fWLJURi+pimCNdJtNzIufG2NgnXZ0ZZWh7Jzn1x+sTy0x50MroeIUWj5sED7OHAaK9tuRx9K9MJqLto1TXXa36fOAGdnQP5gLVRUT2VIQywkTkSGHwLlFzF/fWU1r4zMhrdxVIuVh5QF2Nv7EpH9yNSdSGgKRVKZvopXJOn7vWVOIlPwqBRpAro5L23A1TJaz7gai6IGcKT2nTwwNHMLUP9k7py30VvqzaxKz5xBgOrbGG65IYzeElq+SLmVYzDltA6A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR14MB3167.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(136003)(366004)(39850400004)(346002)(76116006)(66476007)(966005)(478600001)(99936003)(7696005)(2906002)(44832011)(53546011)(66556008)(186003)(6506007)(316002)(26005)(4744005)(166002)(5660300002)(8936002)(66946007)(71200400001)(86362001)(66616009)(52536014)(9686003)(8676002)(66446008)(64756008)(33656002)(110136005)(55016002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?8grm/e/7bVllOoaKM5VR2Uf20mxFzD1cKUEiilC7lYw6t/K+fQe6bFVxgJvD?= =?us-ascii?Q?IPtDzXoKH8f9VlJ3Xoev5dZxMKA3LA1kZG8cmRHVlAjJWFuu3Sl6Ys3MTfMu?= =?us-ascii?Q?cJXiAqbO8LOQ15WXZZImVc7908rNXzaNdljNCiDnAjuZiEgnpz45ypBlowJH?= =?us-ascii?Q?q9QtlEtL0wtg/mqjOIY2QFPUEV18VJxKeB7GvQBKoa/ZMYNGoCBWX3n9TRXd?= =?us-ascii?Q?1IiPuIkSBEONI6ny3fV9U9RXixIEvX3M7s9Wj0pyzc0evPARyMUgcRrm3Ji4?= =?us-ascii?Q?WSkx9XDIpJ6Y8zqgM8nwzgPAwJnboNkB9qNimIM0Q3tyi3fjz6LtayB+ue0m?= =?us-ascii?Q?SqyTjy+0E4rC8U5FwPxvjK7NZ70LMNn02xc2GhoEc8sgXD8IDwJHrfXE17cC?= =?us-ascii?Q?H4ycIYvXa2mqKFTd8lMn/EddapyGITAoaoTAg85rDDZQjWy9mGDV4nuMQwpm?= =?us-ascii?Q?iKGqe9s7iiOwdFfa9Hq+ZmujpQkWwiubuRlf4nj5twqdLMrP9F0ftxvxkuO2?= =?us-ascii?Q?pa7d68+aU8nvjoP0DjbFTJvUCC51FLQocI6mq69k7O0WZJ5RPRzygdGC79ud?= =?us-ascii?Q?ndRnXix0QQG0bA9iGlJSu62ZrmTHz3L+dhK2nOotlxfIZYTR8ZQMkCfoclxt?= =?us-ascii?Q?KsOytjfAJYfDG+zGjPxi5+LckUvg9cC6ltsnsqSIOyPfSAO9cWoCm1W3Dwv8?= =?us-ascii?Q?K9zEc250HXQhjhE8CtvQmHx5ZmvpyU4nfcCTCBPJnEP95k7FePjzgvsgYSUk?= =?us-ascii?Q?gX+VhCVzMjW55mkM0Kk2Ku+BbzpcO2nTcHh3+FSgd8wTpqA8+cQ87qpsECjm?= =?us-ascii?Q?trJvZ5pU6UQQj7tPckTZ36RSY1AzYbADvs7iydVgKZTNyCU9Tdk3Bn9Fa4ce?= =?us-ascii?Q?GEfBD7PDZiRi2VfS5/AHDoIUSjMIYZW2kT/iORJNJcFjVOJ21oWcF75/nZwE?= =?us-ascii?Q?UxXsrS9kE7uzGrrFWB6y1n/JW1M3jqP/OLNoey4Tfwg=3D?= 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_05E9_01D6C8C5.804E3590" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR14MB3167.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 091d10a8-d308-401a-c88a-08d897068c78 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2020 21:09:25.4399 (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: iR/uw7ResCluEDfb2A6/NKJzNJOWbbM3vvb8nI5Pu8SXbTkS6htWGP092EbPR+FOQ6CvQwkR6zDTBtOMbUD7sxIGC6cJsWJ7uL5jr1mqzaY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB2493 Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg 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, 02 Dec 2020 21:09:37 -0000 ------=_NextPart_000_05E9_01D6C8C5.804E3590 Content-Type: multipart/alternative; boundary="----=_NextPart_001_05EA_01D6C8C5.804E3590" ------=_NextPart_001_05EA_01D6C8C5.804E3590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It looks like there is support for this document, as several people support it and no one expressed opposition during the call. -Tim From: Spasm On Behalf Of Tim Hollebeek Sent: Thursday, November 12, 2020 4:51 PM To: LAMPS Subject: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg For those of you who are following the discussion, you're probably aware of the following brief draft that is related to the CMP work. It allocates an OID for AES-GMAC, and contains provisions for its use within CMS. The draft is available here: https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-00.txt Please indicate by November 25th whether you support adoption of draft-housley-lamps-cms-aes-mac-alg by the LAMPS WG. -Tim ------=_NextPart_001_05EA_01D6C8C5.804E3590 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It looks like there is support = for this document, as several people support it and no one expressed = opposition during the call.

 

-Tim

 

From: Spasm = <spasm-bounces@ietf.org> On Behalf Of Tim = Hollebeek
Sent: Thursday, November 12, 2020 4:51 = PM
To: LAMPS <spasm@ietf.org>
Subject: [lamps] = Call for adoption of = draft-housley-lamps-cms-aes-mac-alg

 

For those of = you who are following the discussion, you’re probably aware of the = following brief draft that is related to the CMP work.

It allocates an OID for AES-GMAC, and contains = provisions for its use within CMS.  The draft is available = here:

 

https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-ma= c-alg-00.txt

 

Please = indicate by November 25th whether you support adoption of = draft-housley-lamps-cms-aes-mac-alg by the LAMPS WG.

 

-Tim

 

------=_NextPart_001_05EA_01D6C8C5.804E3590-- ------=_NextPart_000_05E9_01D6C8C5.804E3590 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 CQUxDxcNMjAxMjAyMjEwOTI0WjAvBgkqhkiG9w0BCQQxIgQgzXZSgE53XFZAlgPZcx4aKsHg26y7 WKGOXM/NUw0CLYQwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAAOKLfWIAwPYZMn9n3gUos6JrC1uCDUlXH61+D9FAJ4uyTKCOhjrvN0RseAJeiVSfsLaavUT IJeSFyGnSQXiknktlozOkw5KBVL2jWXImdZuBnkrCmcppjmwM3O7L6KMxyePT3ur7mKbbhLBy+da EHSn0bNvHUjuR2yrzYT4AFzRdaZ5Z7b1m9CxYoHIS99R5Sikxe7KS9K7jju87orFg6+CeT/KODmP m6XremPy8+IHMclbQceqJq++ZBP4TAgP6rYunfbUQFOc0Jhmod/qEk4J5Z3iHKaxnclBxSUYgb2R jZP+HT65d6MeEdi6wtzyxQ2ANReJT8ea5cbpr7P4IhgAAAAAAAA= ------=_NextPart_000_05E9_01D6C8C5.804E3590-- From nobody Wed Dec 2 13:17:27 2020 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 8A5643A19EA; Wed, 2 Dec 2020 13:17:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <160694383653.28042.16867511135804078171@ietfa.amsl.com> Date: Wed, 02 Dec 2020 13:17:16 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-aes-gmac-alg-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 21:17:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-lamps-cms-aes-gmac-alg-00.txt Pages : 7 Date : 2020-12-02 Abstract: This document specifies the conventions for using the AES-GMAC Message Authentication Code algorithms with the Cryptographic Message Syntax (CMS) as specified in RFC 5652. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-aes-gmac-alg/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-aes-gmac-alg-00 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-aes-gmac-alg-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 2 13:23:20 2020 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 B40053A1861 for ; Wed, 2 Dec 2020 13:23:11 -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, 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 mn7k6a9Pgi3o for ; Wed, 2 Dec 2020 13:23:09 -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 D66893A1881 for ; Wed, 2 Dec 2020 13:21:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 848E2300B2B for ; Wed, 2 Dec 2020 16:21: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 wTll5P1WC8wr for ; Wed, 2 Dec 2020 16:21:29 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 70378300512 for ; Wed, 2 Dec 2020 16:21:29 -0500 (EST) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_A752139C-7E4E-4508-94D1-2982DD77043A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Wed, 2 Dec 2020 16:21:30 -0500 References: To: LAMPS In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg 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, 02 Dec 2020 21:23:19 -0000 --Apple-Mail=_A752139C-7E4E-4508-94D1-2982DD77043A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I posted the I-D. It addresses all of the comments that were recieved = during the call for adoption. I think it is ready for WG Last Call. Tim, do you agree? Russ - - - - - - - - - Name: draft-ietf-lamps-cms-aes-gmac-alg Revision: 00 Title: Using the AES-GMAC Algorithm with the Cryptographic = Message Syntax (CMS) Document date: 2020-12-02 Group: lamps Pages: 7 URL: = https://www.ietf.org/archive/id/draft-ietf-lamps-cms-aes-gmac-alg-00.txt = = Status: = https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-aes-gmac-alg/ = Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-aes-gmac-alg = Htmlized: = https://tools.ietf.org/html/draft-ietf-lamps-cms-aes-gmac-alg-00 = Abstract: This document specifies the conventions for using the AES-GMAC Message Authentication Code algorithms with the Cryptographic Message Syntax (CMS) as specified in RFC 5652. > On Dec 2, 2020, at 4:09 PM, Tim Hollebeek = wrote: >=20 > It looks like there is support for this document, as several people = support it and no one expressed opposition during the call. > =20 > -Tim > =20 > From: Spasm > = On Behalf Of Tim Hollebeek > Sent: Thursday, November 12, 2020 4:51 PM > To: LAMPS > > Subject: [lamps] Call for adoption of = draft-housley-lamps-cms-aes-mac-alg > =20 > For those of you who are following the discussion, you=E2=80=99re = probably aware of the following brief draft that is related to the CMP = work. > It allocates an OID for AES-GMAC, and contains provisions for its use = within CMS. The draft is available here: > =20 > = https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-00.txt= = > =20 > Please indicate by November 25th whether you support adoption of = draft-housley-lamps-cms-aes-mac-alg by the LAMPS WG. > =20 > -Tim > =20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm = --Apple-Mail=_A752139C-7E4E-4508-94D1-2982DD77043A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = posted the I-D.  It addresses all of the comments that were = recieved during the call for adoption.  I think it is ready for WG = Last Call.

Tim, do = you agree?

Russ

- - - - - - - - -

Name: draft-ietf-lamps-cms-aes-gmac-alg
Revision: 00
Title: Using the AES-GMAC Algorithm with = the Cryptographic Message Syntax (CMS)
Document date: = 2020-12-02
Group: lamps
Pages: 7
URL: =            https://www.ietf.org/archive/id/draft-ietf-lamps-cms-aes-gmac-a= lg-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-aes-gmac-= alg/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-aes-= gmac-alg
Htmlized: =       https://tools.ietf.org/html/draft-ietf-lamps-cms-aes-gmac-alg-0= 0


Abstract:
  This document specifies the conventions for using = the AES-GMAC
  Message Authentication Code = algorithms with the Cryptographic Message
  Syntax= (CMS) as specified in RFC 5652.


On Dec = 2, 2020, at 4:09 PM, Tim Hollebeek <tim.hollebeek=3D40digicert.com@dmarc.ietf.org> = wrote:

It looks like there is = support for this document, as several people support it and no one = expressed opposition during the call.
 
-Tim
 
From: Spasm <spasm-bounces@ietf.org> On Behalf = Of Tim = Hollebeek
Sent: Thursday, November 12, 2020 = 4:51 PM
To: LAMPS <spasm@ietf.org>
Subject: [lamps] Call for adoption = of draft-housley-lamps-cms-aes-mac-alg
 
For those of you who are = following the discussion, you=E2=80=99re probably aware of the following = brief draft that is related to the CMP work.
It allocates an OID for = AES-GMAC, and contains provisions for its use within CMS.  The = draft is available here:
 
https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac= -alg-00.txt
 
Please indicate by = November 25th whether you support = adoption of draft-housley-lamps-cms-aes-mac-alg by the LAMPS WG.
 
-Tim
 
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

= --Apple-Mail=_A752139C-7E4E-4508-94D1-2982DD77043A-- From nobody Thu Dec 3 10:15:06 2020 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 11D033A0B2D for ; Thu, 3 Dec 2020 10:15:05 -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_MSPIKE_H2=-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=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 1giMw9gYisOB for ; Thu, 3 Dec 2020 10:15:03 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2058.outbound.protection.outlook.com [40.107.22.58]) (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 EEB343A0B2C for ; Thu, 3 Dec 2020 10:15:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XIdlQztkvVP0LOIBwzvZeYiD3Rf+gk9DzZ2XL7K2Co+wZ1ZqTskuNbXQ4iAO/bP9MoNfZb4Ksu1ORhnH0TKXjRZDhK0iV8u3C5MP52gywkDUq3yxDryhSopc/bFv5maqFPXOcJPxzr561q2SQJT1dywnoGy5iyVd2OcZfh3GAnh5o36nID4R6nyjWqwgVPa9q93qefTxDPu709FpbipO1Zo95utdZlcIXUa64j7lsWhqRj3mahEiqunK3aU8I5gGSLXdinWiCX8MLbBCIFyYRnoqBKC16XOwupULs4Z4me6cfhn+OSgqNqhqmlQJyRjT0zcOLoXfwcQwbKuY/yvGEw== 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=tJR2i+1FzzzjqV5wHAwdlF90Z3I68faYcVooaCO7OnI=; b=G90iKu0xysWspP84VIjOWet2OwVn9R3hNG4QFk69w4pIMmwHrYBzvyoZqb2LwBgjb/9GY2tDSrUldJ59ofj7DMRwTdVDVHrVxwTiH5eDkzws1e2t1RaGeT0GmKvhoYQCRWSh6i5welEX1P4HxPGp53mPjBzh5PqB445f0/JVBzlCbMgGjnB8mXmZyb9T8BHpQEQEH7hcX/+dendWAqcs650pgVXi795HomlerieQD74jwr1TdBrDAq77B+mP+1iuFEMZnxwWnkmDqqq+dA8I2AldeG7AWL+JGkfmfkIfI6QgOFmeGsH+Bm5wxcI61Jze9uaS/749DHdtCm6vhmtsqg== 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=tJR2i+1FzzzjqV5wHAwdlF90Z3I68faYcVooaCO7OnI=; b=eNKb7o0vLpK/KrzebETs06gHPULglJyWZyTGk1nL+i4kacXkGmYme51NVRiwYQUZmmTJXegrnTkgXVSrpNry7hwZcMhJH3eEzAd8TTAP7pheVRnXRsH6z9Am5TqXoRwUA89n4epRvzBBZHJe4MCfIiqtgCiawHm0p9gnVFN54H0= Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM9PR10MB4151.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:1fd::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.21; Thu, 3 Dec 2020 18:14:56 +0000 Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69%6]) with mapi id 15.20.3611.031; Thu, 3 Dec 2020 18:14:56 +0000 From: "Brockhaus, Hendrik" To: Russ Housley , LAMPS CC: Rene Struik Thread-Topic: [lamps] supporting ECDSA25519, i.e., ECDSA/SHA256 with Curve25519 under the hood (was: Re: LAMPS Minutes for IETF 109) Thread-Index: AQHWxDbR0EhAzY57XEy919hEVdd8R6nlsKbQ Date: Thu, 3 Dec 2020 18:14:56 +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: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-12-03T18:14:54Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=2e6f43a7-e1f7-4783-97ba-0ffdf3546bb9; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.146] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: da250d0a-8d5b-4493-48d0-08d897b756ac x-ms-traffictypediagnostic: AM9PR10MB4151: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hWyGPjYbsIYHxuuMzAg+Bm0BNlSf/8yb5gMZu/3OLRrfxj5Xd3ZTby8eI1wQygAOyj50iuzz/FGu4fCcWhAhpdpjqw6aE9Sl7I5RRT9d9DfEXaqXQq1Zj8eU+98AsMtRDYLXsRewas2EQD28EXSpN70hTAI6r6R/WKTWnKnuLIRuQFGvIzrjOJ+BI2zHd2D6l8vW3xWLe+8JQDg+1GrnmTo1HC4LHBFW0nwTSEYLoz3jDDhflYmIo8esVmxSR01pt8/mqQ3xNk8ZR6I7MOCRS6Ts8IjehsW5a3H2gONwYsSXAN5J+kbtHEi+PIdfLFkd x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(346002)(376002)(136003)(396003)(76116006)(66556008)(66446008)(66476007)(64756008)(110136005)(66946007)(6506007)(4326008)(83380400001)(33656002)(86362001)(55016002)(478600001)(5660300002)(9686003)(316002)(71200400001)(7696005)(52536014)(55236004)(8936002)(8676002)(26005)(2906002)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?ODBQSSttUHpHOFNERnN5NlloR0piYWE0dmJVWGxoNDVNU3hoUVFwUTZNMWlZ?= =?utf-8?B?R09LSThlWlVTeCt3cmhBOGw1TTZYREJKSzlyMlN6M2t2SzlZZE9Lc1lEcGc0?= =?utf-8?B?RTBLWjgzcHhFUllzVHoyT29iN0w3SWdwVjJFTFZIVGFiaWNkSDdUSXhXT0JT?= =?utf-8?B?OGJhZ0JYSktuQkgwTGZZUzhrU3JINytNbnRyTHl3Tkx0TklLMC9PN1ZJV1NW?= =?utf-8?B?R3k0cDFreDNSVVFlOERvSnRTTTUyR0pEbzY1N1FSaWMvWGpQU043UkxGU1Bx?= =?utf-8?B?VVR4R0ZOT3UwaEF2Y0wrbUkxV2gza3VPQThJN1h3bEZEdnNnd1RPQVhPMk90?= =?utf-8?B?SmVWMXdFdDhDLzJialFxVFg5RWYydXhZNGlWaEpqMi9RVThOOHBqS1I5YTk4?= =?utf-8?B?K3Z3K0dubDJvMXNIdm83MFNRQWlORnFzb2xWOGsxR2c2dXczek8xaEtFK3lZ?= =?utf-8?B?U1BaZ3NBQy8rSEtyUCtoYjRXaEZVTXl1RTcvSEduNSt0L2RLdWt5Nk5tbVRv?= =?utf-8?B?VlhKd2hyS2xoTTJKb1pTcGRuRi8rOENvaTNleUNLT0lML2pHR2hNK04wc1Q5?= =?utf-8?B?V0wxL2F6UGF3dU5EN05zUE9wbXlCSlNYOTBGQXZqM3NuVlp6NFBOYWtRYTdj?= =?utf-8?B?MWFDbndvZk00WnhoTlVLZXJocXBWL3BQL21VcXhYczYrUCtDaFh2L0JMeWNo?= =?utf-8?B?VEJ5NHErWVBFK01HbVdCQ0E2Q0lGQXdYWE1jb1ZmbGpxanNOWWMweko0UHlL?= =?utf-8?B?bHJsQnVsem54cmNsVlEzbVBncUI1WGxjakpwcjh3K3hUWlpiSzI0TzlKemRh?= =?utf-8?B?eURTSEFkWXo5KzhxQURxMUp3WEdZZUxQelBxU0Zncm5abG8zYlF2SEQ3R0Y2?= =?utf-8?B?SWliQk00M2JpaURKSHV1RXU5T09LVkh2b0pCOVQ3U3pYREZ2OW1KVEdRQ2F2?= =?utf-8?B?SGJTdmRWMURJRStDbFo3SlIyMmlGU295RE5pOGJ2K1owWUNmaDRoeTlIZEJS?= =?utf-8?B?QUZFS1pBYUY1Sk9tRW1xR2VYUTViZXp0MXVhMTh5RjVabXg2b2xlcEVyVHdz?= =?utf-8?B?eFV0TGlOT1pOVjFmUTNpU0xHRTZ2WlhLaUx1THRwODlMQiszQmFnVlRQa3FQ?= =?utf-8?B?aEtrUVhSVDhDMVhNeXh4NmswM1RxRFcvMHFUQjZGWmw0Z2hCSVNOcndLNWQr?= =?utf-8?B?UWwvb0NTMDFkZVp0OXJ0Rm56dmU1M09yeTI5dXZlaDlXTDAvelk3a3NGOCtH?= =?utf-8?B?bUlDblRTT1RYcU95bmFkdTYrcG1WdlROdENicGVIc1k0UE9aMVMwaEpsVHNI?= =?utf-8?Q?znAQPnJy0emuLTd9GIIPP8I1B+nYt3tcxr?= 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: da250d0a-8d5b-4493-48d0-08d897b756ac X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2020 18:14:56.1016 (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: WHSM44TDMl4H3LciBQfug7n1wfMCrjxgTDCzxnvlpy7W0lBKMSKJcqn0owzXMr6veCxNEJUVDHsOxuWKFCO/oULpaY2H+I00MWTbabmkzqw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR10MB4151 Archived-At: Subject: Re: [lamps] supporting ECDSA25519, i.e., ECDSA/SHA256 with Curve25519 under the hood (was: Re: LAMPS Minutes for IETF 109) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 18:15:05 -0000 VGhhbmtzIHRvIFRvbWFzIGZvciBoaXMgZmVlZGJhY2sgYW5kIGluc2lnaHQgaW50byBIVyBzdXBw b3J0IGFuZCBQS0NTIzExLg0KDQo+IFZvbjogU3Bhc20gPHNwYXNtLWJvdW5jZXNAaWV0Zi5vcmc+ IEltIEF1ZnRyYWcgdm9uIFJlbmUgU3RydWlrDQo+IEdlc2VuZGV0OiBEb25uZXJzdGFnLCAyNi4g Tm92ZW1iZXIgMjAyMCAyMTo1OA0KPg0KPiBEZWFyIGNvbGxlYWd1ZXM6DQo+DQo+IERvIHlvdSB0 aGluayBzdXBwb3J0aW5nIEVDRFNBMjU1MTkgd291bGQgbWFrZSBzZW5zZSBhcyB3ZWxsPyANCj4g DQo+IFRoaXMgaXMgd2VsbC1kZWZpbmVkIGFuZCBub24tZGV0ZXJtaW5pc3RpYyBhbmQgYWxzbyBj YW4gdXNlIGV4aXN0aW5nIEN1cnZlMjU1MTkgbGFkZGVycyB1bmRlciB0aGUgaG9vZCAoc2VlIFsx XSkgYXMgd2VsbCBhcyBleGlzdGluZyBnZW5lcmljIGhhcmR3YXJlIHN1cHBvcnRpbmcgc2hvcnQt V2VpZXJzdHJhc3MgY3VydmVzIChzZWUgWzJdKS4NCj4NCj4gRHVlIHRvIHRoZSBQS0lYL0NNUyBP SUQgcmVxdWVzdGVkIGR1cmluZyBJRVRGIExhc3QtQ2FsbCBvbiBsd2lnLWN1cnZlIGRyYWZ0IFsz XSwgaXQgc2VlbXMgdGhpcyBjb3VsZCBqdXN0IGJlIHVzZWQgd2l0aG91dCBmdXJ0aGVyIGFkby4N Cg0KRG9lcyBhbnlvbmUgZnJvbSBMQU1QUyByZXZpZXdlZCB0aGUgZHJhZnQgYW5kIGhhcyBhbiBv cGluaW9uIG9uIHRoZSB3b3JrPyANCg0KQWZ0ZXIgZGlzY3Vzc2luZyB0aGUgc3VwcG9ydCBvZiBj dXJ2ZTI1NTE5IGFuZCBjdXJ2ZTQ0OCBhdCBJRVRGMTA5IEkgdGVuZCB0byBhZGQgRWREU0EgKHJl ZmVycmVkIHRvIGFzIEVkMjU1MTkgYW5kIEVkNDQ4KSBhY2NvcmRpbmcgdG8gUkZDODQxOSBhbmQg RUNESCAocmVmZXJyZWQgdG8gYXMgWDI1NTE5IGFuZCBYNDQ4KSBhY2NvcmRpbmcgdG8gUkZDODQx OSB0byBDTVAgQWxnb3JpdGhtcy4NCkkgdGhpbmsgSSB1bmRlcnN0YW5kIHdoYXQgUmVuZXMgYWlt cyBhdCByZWFkaW5nIHRoZSBkcmFmdC4gSSB3b3VsZCBsaWtlIHRvIGFzayB0aGUgV0csIHNob3Vs ZCBJIGFkZCBzdXBwb3J0IG9mIFdlaTI1NTE5IGFuZCBXZWk0NDggKHJlZmVycmVkIHRvIGFzIHNp Z25hdHVyZSBzY2hlbWVzIEVDRFNBMjU1MTkgYW5kIEVDRFNBNDQ4IGFuZCBrZXkgYWdyZWVtZW50 IHNjaGVtZXMgRUNESDI1NTE5IGFuZCBFQ0RINDQ4KS4NCg0KSGVuZHJpaw0K From nobody Fri Dec 4 08:14:45 2020 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 6786C3A10DF for ; Thu, 3 Dec 2020 16:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=entrust.com header.b=Ik75XgEF; dkim=pass (2048-bit key) header.d=entrust.com header.b=EWR3nQca 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 GIjZhBhvdhzd for ; Thu, 3 Dec 2020 16:10:11 -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 2E6D23A10DD for ; Thu, 3 Dec 2020 16:10:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=entrust.com; i=@entrust.com; q=dns/txt; s=esa1; t=1607040611; x=1638576611; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Xl0akxOXwIwB5yHZqmoJNpCG+q7lRO06dhMe73skfuU=; b=Ik75XgEFr1IhCxwaUfAdQotYGnQxxjQOojK01NWbnIxOs4zQKsJDkRzQ vEV0S5bbY8UaCimlCU77J1JX8gSJr2pXDMcY1wz6Lp4YTP8eIT/txXtNa HT/YbSxLFkryvBlvO6bvW2oeKX6PB9B6mnFOyUhkRj61ABuNhEZHQTtX3 5Gu8DpLO/VtlBAJZcqv5tXoI3Ww0K/6OUdT/R/J4KTh81duDWlFKw7NVZ fiycd0NnE9u+sswsIvV8+LvtB0wHN2froCM+D+Mj3jj9BCCfyDTffyNWs HBf1BnHvdU0CajtT3Cg+UAbbL8Tw5//yS9+eh0TgzABJSg2CpJFRq3ZAs w==; IronPort-SDR: bVjLkbU5Q325rHJs8UOzQpmLrCvYaNCxY69cpaqOkfJj8M5Ln9RdHDHfYgJ0oiqmK2CPFgZep2 C/Bnlg0/4eig== X-IronPort-AV: E=Sophos;i="5.78,390,1599541200"; d="scan'208";a="93303447" Received: from pmspex01.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.29]) by pmspesa03inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 03 Dec 2020 18:10:10 -0600 Received: from pmspex01.corporate.datacard.com (192.168.211.29) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 3 Dec 2020 18:10:10 -0600 Received: from NAM04-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; Thu, 3 Dec 2020 18:10:09 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XMqH3emLKaYyYmQFn4/eP3XZOSsoJ1UPvWYE/O9R3lu4AhFusgKuhDIHuNlQEfTSN1MVw2X3AMM69H+CMISU9oL5/PDFlyqFHwa/39tIVWM0M6kYZBVf2GFsdXzX4CU3bW+CA6W+qMZOcFsil83DE/CiwXxLfHvjjauzckDxwiX7XNUacM1N+2ZE1pn+gxsf7FD9Vgb5nUl7Y7y+21guvj443hQbWgYXgQ/AWVKXyIOCKL7qfkF980qy/7UFpVudFL0nvowYTv2Atgi1jbA/k+hFPTsdKDdFuftVFhFbdFP4yAtkZZj1V8c6LSf120jLzb5xNVNOa94eqd+zjHPRig== 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=Xl0akxOXwIwB5yHZqmoJNpCG+q7lRO06dhMe73skfuU=; b=O/c/IYv581Q2KBEw620pewbv4V31NIpvLwPks42twix4x8WIZBTWzAUDpIV8foQ+oolW0yHfaXbMPaYKti0K3/xlw++hHmk2fKAISE8OfeAfDpfwrScu80f3staND/IsxPIwb8sNyPxzOFbJu5ekqL231pCXT45MLhqTx8oDuAodJLr79/NbPuExmpqooaZhH5EM/D2p72z+WXZtCFNuAC+M1llY6LQI8WbwOC/j0u72EjiiTXx9dEPcUvA5c38vXVGClC6CaK0DDlX7eV4lI9MMxZzh8/d2p3EgNEO1TZ+i328ZxP4oe+0B78kZScysmxZrG7hFszxXEuDERFyTtg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrust.com; dmarc=pass action=none header.from=entrust.com; dkim=pass header.d=entrust.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrust.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xl0akxOXwIwB5yHZqmoJNpCG+q7lRO06dhMe73skfuU=; b=EWR3nQcai5vXCyuvDJUvNW0jvOgGrBDxXotdYiHQw50YIV/4pdmnqhI4EzM3149bIL2qPZHTruWJRnq/TIw7Fq0XOVowdH6bIR2pvF9m+ArUHkl8xF2CocZ7ZAplglqDHx4fksCbaj9dLLU1BzzxMrG0ivTwAlmpfWyZkBgiz7lMldHdcps7wEdXfEbeB3lBGE/VkC6ocBqXWMdfUfWi3H9boDNANYx3XrEEEZUm1X2x3NCzoGbwrEPfp+75QEqlOVhLph4aQsJrkbEqLXcuh4kIwSqxb6kDb1Kp/PnbNN5s/z4fkyEtchPDySK/8PaDwoZa65DZI7464ie6SIua7A== Received: from BY5PR11MB3912.namprd11.prod.outlook.com (2603:10b6:a03:190::18) by BYAPR11MB3672.namprd11.prod.outlook.com (2603:10b6:a03:fa::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.31; Fri, 4 Dec 2020 00:10:07 +0000 Received: from BY5PR11MB3912.namprd11.prod.outlook.com ([fe80::b88f:df82:269e:b205]) by BY5PR11MB3912.namprd11.prod.outlook.com ([fe80::b88f:df82:269e:b205%6]) with mapi id 15.20.3611.031; Fri, 4 Dec 2020 00:10:07 +0000 From: Mike Ounsworth To: 'LAMPS' Thread-Topic: CMP and PBKDF2-MAC (use RFC 8018's PBMAC1?) Thread-Index: AdbJ0P8rWe8VkkwJQiygQBWyNOJifQ== Date: Fri, 4 Dec 2020 00:10:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=entrust.com; x-originating-ip: [2605:8d80:6a0:8d2b:48fa:f592:f5bb:d821] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c4c9c031-cf0f-4651-4db9-08d897e8f531 x-ms-traffictypediagnostic: BYAPR11MB3672: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dpfEYg+prMlZPuekqViPbXf1Hl9ArCmAUSdguVAk2eItkPGY3QYIgqGzF2GqByxTGDu99dr4gTmbBb4oML9lQuTGSxJJY6ctcOMUOzJd+6nN0TDosB1rOduLfIAVIJ4URlw851RIc/Rcz5OWpzObDp0NSOPCnisYefhdtOb90XWgINOmGeXVAtc/nC37NDvT4QyqSBu5R/Yeb+aN/RKjCwK1I0fX6LYXrUVfaBkSMZiNV/dl4ufvtE3sthkBrLbSnilC+H4aQAMQgGdiRtzuQBX0vX7Jtv7XSn5ga84vSj+RpXHgjD7zjIwk6Mfk/edb x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB3912.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(346002)(376002)(39860400002)(136003)(8936002)(186003)(4744005)(5660300002)(7696005)(6506007)(64756008)(316002)(83380400001)(71200400001)(66556008)(52536014)(9686003)(6916009)(55016002)(86362001)(33656002)(66476007)(76116006)(478600001)(66446008)(2906002)(8676002)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?9oQoGJQgh+FoabpRbh0IT1gJOGtaZvKinu0UeQ4FyByQcW1Isy7ho0A1CC1Q?= =?us-ascii?Q?9MZEu/+99zktBQ17B8dQsODwYY4hAxwKplU+5DruolNBFwUOdyAWkYmsCT90?= =?us-ascii?Q?eAeNMMODeOPQFJO8CIl5NdtDas4qA9obcjgShqxWVQ917Kzf8wiV8TT0WFLc?= =?us-ascii?Q?X0vROCrKpFTHGuZPc/GdkgLVkU3UUJtSZIs642o0aWTzfI+V+4VUEd5JALbL?= =?us-ascii?Q?5jzucqaTSSVnghpW9gcFo/ROT4vS9uCIMhI5aSQMuhv8xEJYKACTqI5OkL2V?= =?us-ascii?Q?ZsaE/FW7q5qJIthk9R5f+Th5YveBsKnH4cgHFSfpH2JM7Cd3Om9mWWIjAPex?= =?us-ascii?Q?67pG3XvghvXhIZ1nwFPo44+indI5NnRLMNW/3g3/rL6toNbXEuu+d6DPmoxv?= =?us-ascii?Q?d7fvyz4CQUQ97QB7yCu6pPh7xLPfbL8sP6TiRB3OQESvp13S5IYcerMoAFEC?= =?us-ascii?Q?bR3HCUHPNQM0RZQSkCHYYeRjSJ1+CPM+8HtzXS2kMGlVkgrvRmDLfqWEbZCV?= =?us-ascii?Q?KfsAcdzlOeH7c05SuMU6LgyR4jlflil8+v78dOP+noau9SI/eZKk4XASFtwM?= =?us-ascii?Q?YORKnWjYOmzzCkaESy25hli33RpCqklOjvnh0Ixl/QeYQg2zoZA/Zai7Sig8?= =?us-ascii?Q?onvwIOlH2ps7GAm6/PHBFr/JOlz1qEekC3ge4xoz0quJ5ZOkg0iZtl8rXXBU?= =?us-ascii?Q?vamVa4qDpt3pdVrd3jVaOw1WclyMwyhAMEBHdIcm3J7LyA9scdWLw7pC1M51?= =?us-ascii?Q?Zz7ioeODLjrBPTNJoX5HJOxtsAQQ9z6KDuN2FMEOsbTn3wFpmCDs1ItrlDQr?= =?us-ascii?Q?t6QeuBgIHCqcwL8a6lTlxkoXZ3tgLm8YZC6k1LdGr3LozwBo+cn6JTrr0ZXd?= =?us-ascii?Q?KeLifLW8THr8zRY/PvUxfvGNQrnHGtyWFf7kk85bKVOLwWGjQ00VbH4SMJY8?= =?us-ascii?Q?42tNbdEWafojbIg/nmufiaADOW2Hm6NxGEsuXULOQnjUAkvhJvxdAeFwu1K5?= =?us-ascii?Q?LGT3PazQPGW1FCfnBT+kLp0bVQiER8Zc7YjnZovvUmlSBgk=3D?= 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB3912.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c4c9c031-cf0f-4651-4db9-08d897e8f531 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2020 00:10:07.3431 (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: PtBYNRirb+qf+yccjOhTwOfWJ7jXpRLkGO+fJsdMWcNxP2TmlxDji/nFua1zlv2fTn901sq+w08xWoiHczy4rUnV1OArYOhYBZaoM5b3DfQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3672 X-OriginatorOrg: entrust.com Archived-At: X-Mailman-Approved-At: Fri, 04 Dec 2020 08:14:45 -0800 Subject: [lamps] CMP and PBKDF2-MAC (use RFC 8018's PBMAC1?) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 00:10:12 -0000 RFC 4210 (CMP) allows for shared secret (MAC) protection of the message. Se= ction 5.1.3.1 specifies the use of id-PasswordBasedMac which is defined in = section 4.4 of RFC 4211. This algorithm looks a lot like PBKDF1 with a roun= d of MAC at the end. Question1: We are not seeing a RFC 4210 (CMP) update that provides a PBKDF2= -based MAC. Is that correct or have we missed something? RFC 8018 defines PBMAC1 using PBKDF2 and a MAC of your choice. Looks great! Question2: Are you aware of any CMP implementations that have implemented P= BKDF2-MAC, and did they use RFC 8018's PBMAC1 to do it, or some other Algor= ithmIdentifier? --- Mike Ounsworth From nobody Fri Dec 4 10:11:19 2020 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 202A63A0E65 for ; Fri, 4 Dec 2020 10:11:18 -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_MSPIKE_H2=-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=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 KtUPiqyyTcf8 for ; Fri, 4 Dec 2020 10:11:16 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2073.outbound.protection.outlook.com [40.107.22.73]) (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 362913A0E1B for ; Fri, 4 Dec 2020 10:11:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kr8uHt+yD2ujRaYzakY92M3S+Tb95I3tT2Pl/Fu+yDYWswM/M3bhO9QYPpu1YxXOicLPY9TvryOqRaHWH8DQyVeZwqZLjAXBvO6c1xgHO3xqsytgUp8xbMqs+CcOosue39SdGLCkiZjUd1KtPoRJl3O3I/YQOUD3G8L0s1DqQ/+r0OhrZkz7svSHL7dzmuCBbrj+p3SVTDxYDIiMaP7xZTdtqo1kdh7b1G3ZQYX+3Dqav9H/TdYneciTj2fBXw8wTvo3sPOHLDvJX12p6hW3vJx9cwQkNGvulzyyq0URU0b48ZMqJsGLpuvwjM8UcBiO/BgO6R3c5FapKxK+q/AfMg== 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=DUhcYh56jYtgmDv1ba9UvXjmz18HzCntDgq97phRpr8=; b=DHldSlNRdrlTjza27YU/P7Ey+W8Hi37OtYkGiAVL5JiNiXL1LWGY9cD02gp1TLG0sL2mPEP+Wv7PetRlZmDnxeJ9kLmx92+Pg60i9WFN/nNnSdavad4vGtTu/zrGrCH5t1gWI2El3TAVypGODX6amIYY5sf9i2qYhyKEacKo5aA0MqgpOJJxDfb3T/PskU6ubXsxR+wiE6P4VDCarDIWZniS9hs7MMLr2iISyXwML/D2j7DBiHvDJbWTHhaaaQQwCn4dssluhD3xH/oA3WyqOmVqf4T8EZCLf22gHcb7sKvZq/HWgKwV91HOsEc9wUuNzREOY3ZXEaison9+3E7Vkg== 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=DUhcYh56jYtgmDv1ba9UvXjmz18HzCntDgq97phRpr8=; b=TY34yAnNZQVfGdK1WZgLjQZqzTCcmGvIbAfJQogoBRJB9t+A4iyB/W0t7zf5VbRP5/Crema/J+ShLr53BBDyPFAGTYFKI27crl4sCL7WPC0j5tTA/hOHCAEDzPpSC5tyQKM1mLcnGsZpXcJPBzhoBWOBeCSZzf/GUqDqDWS3fbw= Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM8PR10MB4067.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:1eb::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17; Fri, 4 Dec 2020 18:11:14 +0000 Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69%6]) with mapi id 15.20.3611.031; Fri, 4 Dec 2020 18:11:14 +0000 From: "Brockhaus, Hendrik" To: Mike Ounsworth , 'LAMPS' Thread-Topic: CMP and PBKDF2-MAC (use RFC 8018's PBMAC1?) Thread-Index: AdbJ0P8rWe8VkkwJQiygQBWyNOJifQAl0vqA Date: Fri, 4 Dec 2020 18:11:13 +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: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-12-04T18:11:12Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=5d705b44-1e79-4d96-a968-e258123fa4db; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.163] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8fc99c36-f7df-4fe0-f9e1-08d8987ffcbc x-ms-traffictypediagnostic: AM8PR10MB4067: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +6BA+QX5qL7i0cMhGJp8nGJYL6AdeszO3G3FXn+ZZ311ifl/j5KX0pQ8zBKfEy1yKkUz5rKU2mXO+Ukj5Gl+FCdSNRRbGxE0R71MfwYl5Ug1X3Dyp9d/6ZSO1jFK1e6h+yhguA8+L32QxzFaGvC8hSUUznMmJBlaOGfGydUjB6Cyqnj5HrasHPEdGdfaKkURkgwnoMMFr0lAswhMjbd5xRZV3/RT2jSSydAYF6HJBVpfJf4OI+g5ihdMibkGsJW/YIXNbDhnH9j5kMnwvS2UBKeizyH5eKLJ4kq3eKBOsD9gSXOohPFFGkspJlucTwic6b9FvXDhp/7FeI+Q4Yg9+A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(136003)(396003)(346002)(376002)(366004)(8936002)(66946007)(33656002)(6506007)(478600001)(4744005)(83380400001)(186003)(7696005)(316002)(110136005)(26005)(86362001)(55016002)(5660300002)(55236004)(76116006)(8676002)(66556008)(52536014)(71200400001)(66476007)(64756008)(66446008)(9686003)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?Ay+c7yOvUBJCqYSt6R3yZlxrfXEGgvEjR1VXP2noxYFC17IzNHrR0W4Yvcy+?= =?us-ascii?Q?l97C7e3DisJwWEZM20douzW+FWg5wbqth4/oxIsRGxjL99zKBykJEjD0RPx1?= =?us-ascii?Q?K+AQcgSzdQXyyC9OxiGXrKoqTz5J7aZbuGiJmXmE2qZ2gYsYQ08DWV59bQl8?= =?us-ascii?Q?ma+S9YSENKqIhDirVWvyc21mTctovhgSz2O8x6MuOG37G37PObYhy648GApI?= =?us-ascii?Q?r2G+o2TYE9Y6aioXqNaPEq0Xy28/DwpFBDByerMnOWVH+fRJnNFs6wkR5FQW?= =?us-ascii?Q?jey5ybPmhso+Ln8xh75zCQrBsqJj3bp9354D91VfMH1TnYNmPIXi5H6Nd04J?= =?us-ascii?Q?WLVngzhfuu4lXS6YtJAeyCHYC8UWC7lE/16b7aPQsvLguqw6X6JJdRwrEkZD?= =?us-ascii?Q?Aeot/BZlFCu3DWQvmPWUv7JTu+fTA/FXFN/2rEBpx5x+XLP8gkV/tF1GxZej?= =?us-ascii?Q?26H9AWkoTc2EWfuQkW6RFwwGmaj0IeR3PyAaMeGtZKP6K2R4bU7nDe0PYCCg?= =?us-ascii?Q?BT919JUTigbJU2Bi2RE72S2vJz2HMjCIquWJDLB79k62M5RMTzH55t3tcmVt?= =?us-ascii?Q?+58ONPboY2AV14A/R+c5PgyB6NRJBWHa3bnBvIQLHKXagHa0GEBDLROYmLja?= =?us-ascii?Q?idCpQa22UtAqNWEjlz31wdyLOicXW0IhUEg4ue4Thy3rAFrcPNvodu3Gb4sU?= =?us-ascii?Q?PRRz/jI6b3oTvUZ2pZcDT8yQ38vvd6XWIRCTlRII7Dr/KGtqlPyq0ekjDOvX?= =?us-ascii?Q?P89BRUo2B2nM5c67IVgrOjKtX9OJO8bgabLhFXStGwWkyL5dlV3slgtoR3z0?= =?us-ascii?Q?YZG5j0utq6QJo2wPTnxN8Meu7sGHarzPGpABT4aBr808ChwqjGMH3VZuM31S?= =?us-ascii?Q?scWG/ZF/EOmy2DP7e3iurzhfzd6k4eQRAORh01oFSYRCprVxXNOzxoHcQ/Sj?= =?us-ascii?Q?LJOXpAp125r1lj7MnAu3uh687XgeKtAFkR2Z1L8Rc47RWzBo63Hzk4ocioyp?= =?us-ascii?Q?LbmO?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 8fc99c36-f7df-4fe0-f9e1-08d8987ffcbc X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2020 18:11:13.6189 (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: oKPr6rN+gEGKmsQMN7RKaCI+XclFCBhUyBFQWzhRmLCJ8yE2eccBSYlBBADdeO9zWV+SqfwX+JVnJjNtK7ENNVXXAMtXp8/VSvuamUFDaoo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR10MB4067 Archived-At: Subject: Re: [lamps] CMP and PBKDF2-MAC (use RFC 8018's PBMAC1?) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 18:11:18 -0000 Mike > Von: Spasm Im Auftrag von Mike Ounsworth >=20 > RFC 4210 (CMP) allows for shared secret (MAC) protection of the message. > Section 5.1.3.1 specifies the use of id-PasswordBasedMac which is defined= in > section 4.4 of RFC 4211. This algorithm looks a lot like PBKDF1 with a ro= und of > MAC at the end. >=20 > Question1: We are not seeing a RFC 4210 (CMP) update that provides a > PBKDF2-based MAC. Is that correct or have we missed something? As the password-based MAC is identified by an OID, we are free to specify a= n alternative to id-PasswordBasedMac in draft-ietf-lamps-cmp-algorithms. >=20 > RFC 8018 defines PBMAC1 using PBKDF2 and a MAC of your choice. Looks > great! >=20 > Question2: Are you aware of any CMP implementations that have > implemented PBKDF2-MAC, and did they use RFC 8018's PBMAC1 to do it, or > some other AlgorithmIdentifier? No I am not aware of any implementation using something other than id-Passw= ordBasedMac. - Hendrik From nobody Fri Dec 4 12:31:11 2020 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 D4AF23A0BB1 for ; Fri, 4 Dec 2020 12:31:09 -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, 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 ce9JB5J05QOr for ; Fri, 4 Dec 2020 12:31:08 -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 2E5E03A0982 for ; Fri, 4 Dec 2020 12:31:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9B68F300BAF for ; Fri, 4 Dec 2020 15:31:05 -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 M6hzsMCsuWcU for ; Fri, 4 Dec 2020 15:31:04 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 43A7F3005DB for ; Fri, 4 Dec 2020 15:31:04 -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.17\)) Message-Id: <2C7FE71D-D3DA-49CF-B133-EAC979309951@vigilsec.com> Date: Fri, 4 Dec 2020 15:31:05 -0500 To: LAMPS X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: [lamps] Timing for LAMPS Interim Meeting X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 20:31:10 -0000 Since we need to re-charter the LAMPS WG to take on = draft-dkg-lamps-e2e-mail-guidance, this seems like a good time to ask = what other topics the group might want to tackle. The WG chairs have = hear interest in topics related to the transition to PQ cryptographic = algorithms. We think that a virtual interim on that will help determine = what, if anything, should be included in the re-charter. Please fill out the Doodle poll for dates in January that might work for = you. https://doodle.com/poll/38kraeib4zbws554?utm_source=3Dpoll&utm_medium=3Dli= nk Russ & Tim From nobody Fri Dec 4 13:05:39 2020 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 192CF3A0C33 for ; Fri, 4 Dec 2020 13:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.109 X-Spam-Level: X-Spam-Status: No, score=-3.109 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, 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=digicert.com header.b=LDON0ciR; dkim=pass (1024-bit key) header.d=digicert.com header.b=DP38nQFq 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 3f706mc6T0Ug for ; Fri, 4 Dec 2020 13:05:34 -0800 (PST) Received: from us-smtp-delivery-173.mimecast.com (us-smtp-delivery-173.mimecast.com [216.205.24.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 90EFA3A0C04 for ; Fri, 4 Dec 2020 13:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1607115933; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EDLZIjp89LYQnE3K8cj4jsKmEUgCcvtwwXscm4pNX9A=; b=LDON0ciRlZC54aM4LRF5MXN9r7pSwEnQtUnIfQVCl5ZaP6ToawFxotKAksUOx1V/QNGQXw aRBvQhvhECvbbjpeXytrmkW9wqKjFQp4BFqSdxVX65r74p3PBWNiF/Nr4FeaCwOkLFCqRm A7n7A8+c/3X3S92YbjIGgi3MYu6Rzvw= Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2104.outbound.protection.outlook.com [104.47.70.104]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-9-HT3-LT0IPJefYfZpLoG4Jg-1; Fri, 04 Dec 2020 16:05:30 -0500 X-MC-Unique: HT3-LT0IPJefYfZpLoG4Jg-1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MonU8O3na/aNDDHSToAWk0R0b8AoS9iXDHR2e9nagjf1JrVO/HTx71foR4FZJIETBezk3IRyj9oyadOZTWqeAVp+M+87dLiOgZfBsVLJesHDFYP5z/XSu08PgyikMuEFXAxGvv+GuOYnyUcc9PImM+OdDfgKZ0L3mdhcvM/Wk8gHo1qFpTE2gkFF98XkS5DArvp/KMFeNQq5Tl1gzXlprdo6RpqX3l2NY4osi7ijhMxhKUdGFuxCCyS6sJ1dSsBDakL+SIEBtY+6SevovkT/myriUddmMRFA6FOyQMfEeo7q35QuEMo0Dl0pqr7EPKoOV9WmebecPa1VTsjx6/PmvQ== 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=EDLZIjp89LYQnE3K8cj4jsKmEUgCcvtwwXscm4pNX9A=; b=Wg9f94rv+VNYtx/CSU9/Wz/5WZaaRGQNA+6wsMI2E86qxKyZfm3G2rUTyErViQYp9sI1yRqTqL6xxBq+XiFwBh98ZAKwSBswjHrlN22Lrb89UmVtz2cj8MtGz0qBvKtU+GJT/DfH5a1Jex/EvGlxuXs1jKRdqvTWJu7Nrey0EC8k6M/PfJs6Wg9YZX7Mk6WYJSwZb4UdMjTOt3y0dSFc+KlXmi4M9ocOhnEnZPsxZIEv2WBR9YY87bJ1eIhluzzsjj84mlpULQYEGGLfrigd0aeROSEwrHvzj+R3Gbvrp+goQV+Ydwy2AWk4zBf0VKOa/woFatui6vnpO2+ExxvQ6w== 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=EDLZIjp89LYQnE3K8cj4jsKmEUgCcvtwwXscm4pNX9A=; b=DP38nQFq7TjBAb5BXJg0MGY7P/zKGL+pUTHbz/jp24kILRjL5XbhcBrqZQfOFq89ViZNFoLK5w/AAnvKOZfPYh1atyP5b2J+nEhXpe2ahmwIZO0OjJpMX8yBodKXEE+5Jlno3OeYYsK4YivjZUARG/TN8PfzBoYm9uYcCOFhDp8= Received: from MN2PR14MB3167.namprd14.prod.outlook.com (2603:10b6:208:12e::28) by MN2PR14MB2717.namprd14.prod.outlook.com (2603:10b6:208:c2::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.25; Fri, 4 Dec 2020 21:05:27 +0000 Received: from MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::e1ea:51bf:a4b0:2f82]) by MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::e1ea:51bf:a4b0:2f82%7]) with mapi id 15.20.3632.017; Fri, 4 Dec 2020 21:05:27 +0000 From: Tim Hollebeek To: Russ Housley , LAMPS Thread-Topic: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg Thread-Index: Ada5PUeDTi8Ao42uSE2MX/yt85ISNwPsfopgAAB2CgAAZALOgA== Date: Fri, 4 Dec 2020 21:05:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=digicert.com; x-originating-ip: [74.111.113.115] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9ae26ae2-7cd9-46a9-e7fc-08d8989853ad x-ms-traffictypediagnostic: MN2PR14MB2717: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xGVRxo5R5SO4Ci7w1Gs3D/FUxrX8O0dKTQvelDAD8HlwC1gRKPuV0eBT6bcr60OA3ej/ZwyuQn6WWRUrtNNLigbOCz8Czs95rkF3vQt61MmmH8HlA17QWYIL1UHtUBxIbyIe1iMtkczOo3ACxnRp8QY/ykLpI1iIJBYf/2rdVTMolWUk8hPyzeEK4NbzYsXN36QyBrDy9EgG1an8CDeNUcS5qfJjpf1RwGsN+i/pj29L6w4jyflM1EOXD//l9FPv56+68a/sYuA2G+wLH2V81AVqazh1Dn3rm1t5idoqcET0/9rEOtaCkSZY0vEdGJdI9oPqPu0C9YNV7idL96z6o826VXqEoeBTVxWeo6rV2vczYxZ4RbT6iPDH+7cCfe9huuqo9n0RlRKUerv49fACLA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR14MB3167.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(346002)(136003)(39850400004)(376002)(366004)(99936003)(166002)(2906002)(7696005)(66476007)(966005)(5660300002)(66446008)(71200400001)(76116006)(8676002)(26005)(110136005)(66616009)(64756008)(86362001)(186003)(52536014)(66556008)(6506007)(53546011)(8936002)(83380400001)(55016002)(44832011)(9686003)(66946007)(33656002)(316002)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?bEZCeDVyMVRNYWZLWE50ZjNwTFBXME0xZmZTRHY0dGczbHd3bHRwZGdRKzNh?= =?utf-8?B?Q0RyQXJFVTIrR0Z5TFNNYkVMNWI2TzB1aS94WTdCMm44My8yYnk1S1g3YlU5?= =?utf-8?B?SCthTHB3akVyaUxEZUZrZnR4VEc0SEZ4TXZyZHN6WXllbGV5VFZVcVZsWExD?= =?utf-8?B?UUlJWnE3cWNqaXEwNGM4Wm0rQ1dqYVhwb1ZXYnZJZWR6LzBJTjJueWJrbTFO?= =?utf-8?B?NFJjK3d5cnl3V3dObVhwWENPMUdsNzhBSnRyUkg5d0cxM0dNdFJSdGhWdDR6?= =?utf-8?B?RnlFWG5OeGUvVXZiRnRKTjE5YWhFUU1nUThNcXkwYUZvYk5iRUZ6cUVrMlFz?= =?utf-8?B?Z1VsUUtMcTl1TlVHSHdaRHNDb2U3ekMvQmthM1oyWUtXemRlb1JOYWVMZFpO?= =?utf-8?B?YkRrZ3BIS3FDaVV1aVFiRFo2RWp5cGcxWi8rWjZscWh3UG54RTd4VmRPMHRG?= =?utf-8?B?Y2RETTFOUVRWcG5iM2JiWDlxWWxqQmo1WnRZVUtxd0cvODFjdHllRlFkTDJn?= =?utf-8?B?NjEvME5BbzZwS3ZHRGZndWRnRnpBRXlHdndnNnJyMWhWLzJUTEErcTZYR1BK?= =?utf-8?B?UjIvK1JwQW1oUEdSTkVuLzFrSmRtcDZNbTZBRmlORG5tWmEyUVR2K2Y0b1ly?= =?utf-8?B?NDlLN0ZmbUcxallaK0ViVjJpQzJNVkpNRmVpZ2ZPSnlCSDJWMUFZM1FXcUxE?= =?utf-8?B?VEpoZWF3eFR2bFJCbmdRYWFjdEx6U1FoTE1jbEk5c01Cd1FqVWZBTTQxV1Uz?= =?utf-8?B?OHRCbjR0RU9ncG43VFRodnBmRXlZdjAwQXF0YXR0RGlkWmdkWDl0aUZ1QU8y?= =?utf-8?B?NXNidmxlWkR3NnozK0pOOUZQNW1xNDBzTVhDZy8xakErZWFkTG5jeEZGVFJn?= =?utf-8?B?c0tmQlZ1LzdublZGc2hka0VmZWFyaDdaOEJuaHRsS3cvRmFLOXV3LzZlSDY5?= =?utf-8?B?TXEzcFhUWVNyZ05XMi9HU2szbHVhTkpWT1lNcU16VDcva0M5N3A4S2kvOG1U?= =?utf-8?B?VTI2SHZHZWVHd2VXUWRPY0JsNHdCY3g1aEdCSTAxaFZTdjRHSTMxVk91Y2w3?= =?utf-8?B?RzNDclJDd2R0aUw5ZDhXZzZLTVhEaGNQTEgveEpKeWsyS1NhV2ZvSFZZZnh3?= =?utf-8?B?NEpmREVpbXBkcUg4ZmRENGRpYzYwMXdvU2xQY2dFR2xKOWdBdkVtZXRDaTNq?= =?utf-8?B?VmROZmkwZ1E5aGNLRml6K2hwZ2MydURHekhwbTR3Ly92d3RBMmtkYTVkSGhF?= =?utf-8?B?eDJXd3N2OFdXSFRTR0J6bDFYK1lqUVIyZ1JReVJBTXJNKzdhMXZ5ZDN1MC94?= =?utf-8?Q?gdhx8Q6HC3vEk=3D?= 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_0779_01D6CA57.46F47640" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR14MB3167.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9ae26ae2-7cd9-46a9-e7fc-08d8989853ad X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2020 21:05:27.7862 (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: jUR3E3DO9XY/jvx6Fo0sYL98EEzD6s2c0LkYGPGVyAKg+dIaw4n8pjx5zbHN+i631AgtdybIDVgstvteoedtRXoPx+dN+scf8hzJM9PUgd8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB2717 Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 21:05:38 -0000 ------=_NextPart_000_0779_01D6CA57.46F47640 Content-Type: multipart/alternative; boundary="----=_NextPart_001_077A_01D6CA57.46F47640" ------=_NextPart_001_077A_01D6CA57.46F47640 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree. I=E2=80=99ll try to get a WG Last Call out today. =20 -Tim =20 From: Spasm On Behalf Of Russ Housley Sent: Wednesday, December 2, 2020 4:22 PM To: LAMPS Subject: Re: [lamps] Call for adoption of = draft-housley-lamps-cms-aes-mac-alg =20 I posted the I-D. It addresses all of the comments that were recieved = during the call for adoption. I think it is ready for WG Last Call. =20 Tim, do you agree? =20 Russ =20 - - - - - - - - - Name: draft-ietf-lamps-cms-aes-gmac-alg Revision: 00 Title: Using the AES-GMAC Algorithm with the = Cryptographic Message Syntax (CMS) Document date: 2020-12-02 Group: lamps Pages: 7 URL: = https://www.ietf.org/archive/id/draft-ietf-lamps-cms-aes-gmac-alg-00.txt Status: = https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-aes-gmac-alg/ Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-aes-gmac-alg Htmlized: = https://tools.ietf.org/html/draft-ietf-lamps-cms-aes-gmac-alg-00 Abstract: This document specifies the conventions for using the AES-GMAC Message Authentication Code algorithms with the Cryptographic Message Syntax (CMS) as specified in RFC 5652. On Dec 2, 2020, at 4:09 PM, Tim Hollebeek = > wrote: =20 It looks like there is support for this document, as several people = support it and no one expressed opposition during the call. =20 -Tim =20 From: Spasm < spasm-bounces@ietf.org> On = Behalf Of Tim Hollebeek Sent: Thursday, November 12, 2020 4:51 PM To: LAMPS < spasm@ietf.org> Subject: [lamps] Call for adoption of = draft-housley-lamps-cms-aes-mac-alg =20 For those of you who are following the discussion, you=E2=80=99re = probably aware of the following brief draft that is related to the CMP = work. It allocates an OID for AES-GMAC, and contains provisions for its use = within CMS. The draft is available here: =20 = = https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-00.tx= t =20 Please indicate by November 25th whether you support adoption of = draft-housley-lamps-cms-aes-mac-alg by the LAMPS WG. =20 -Tim =20 _______________________________________________ Spasm mailing list Spasm@ietf.org = https://www.ietf.org/mailman/listinfo/spasm =20 ------=_NextPart_001_077A_01D6CA57.46F47640 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I agree.=C2=A0 I=E2=80=99ll = try to get a WG Last Call out today.

 

-Tim

 

From: Spasm = <spasm-bounces@ietf.org> On Behalf Of Russ = Housley
Sent: Wednesday, December 2, 2020 4:22 = PM
To: LAMPS <spasm@ietf.org>
Subject: Re: = [lamps] Call for adoption of = draft-housley-lamps-cms-aes-mac-alg

 

I posted the = I-D.  It addresses all of the comments that were recieved during = the call for adoption.  I think it is ready for WG Last = Call.

 

Tim, do you agree?

 

Russ

 

- = - - - - - - - -


Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = draft-ietf-lamps-cms-aes-gmac-alg
Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 00
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Using the = AES-GMAC Algorithm with the Cryptographic Message Syntax = (CMS)
Document date:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 2020-12-02
Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = lamps
Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 7
URL: =            https://www.ietf.org/archive/id/draft-ietf-lamps-cms-aes-gmac-al= g-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-aes-gmac-alg/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-aes-gm= ac-alg
Htmlized:       https://tools.ietf.org/html/draft-ietf-lamps-cms-aes-gmac-alg-00
=

Abstract:
  This document specifies the conventions = for using the AES-GMAC
  Message Authentication Code = algorithms with the Cryptographic Message
  Syntax (CMS) as = specified in RFC 5652.



On Dec 2, 2020, at 4:09 PM, Tim Hollebeek <tim.hollebe= ek=3D40digicert.com@dmarc.ietf.org> wrote:

 

It = looks like there is support for this document, as several people support = it and no one expressed opposition during the = call.

 

-Tim

 

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Tim = Hollebeek
Sent: Thursday, November 12, 2020 = 4:51 PM
To: LAMPS <spasm@ietf.org>
Subject:<= span class=3Dapple-converted-space> [lamps] Call for = adoption of = draft-housley-lamps-cms-aes-mac-alg

=

 

For those of you who are following the discussion, = you=E2=80=99re probably aware of the following brief draft that is = related to the CMP work.

It allocates an OID for AES-GMAC, and contains = provisions for its use within CMS.  The draft is available = here:

 

 

Please indicate by November 25th whether you support adoption = of draft-housley-lamps-cms-aes-mac-alg by the LAMPS = WG.

 

-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_077A_01D6CA57.46F47640-- ------=_NextPart_000_0779_01D6CA57.46F47640 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 CQUxDxcNMjAxMjA0MjEwNTI1WjAvBgkqhkiG9w0BCQQxIgQgd2JPN1XMJ4o94WXBlL6QwNmn6LjD OKItCIVfWKxD+hswgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAIgbx1GRflqvXfzUeDI0M5HaXbanG1xxO12HuqJAvjyTkls9wGYRpM6ek/+ZtmD9sU0uhqVl 1htWXGkofu0PPSh4o9UErY/SVzN/+WmD9B3+xM9w9fA2oV8cGc3+AfjilUTnyfKa9n7ZVxRSVEBA 8SkSwk3J16qkl0cSI8EYKAdNSYwazOM9Eu3YuwhwU8WKIdxFR/LKn7MGtTNLKCM9BxCxQkKkpeht a5yqwO4D+cmjDYycBCGKYIYfKnoP/JbFbu1hzkYz6YrwmSXy/93cgxZyM89hjCLx9YfQsCbsT/Ug hkexNfyvWijdaKiCwY+XqPtRiv0WuNUNVaOPgxfNsPQAAAAAAAA= ------=_NextPart_000_0779_01D6CA57.46F47640-- From nobody Fri Dec 4 13:17:18 2020 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 773553A0C37 for ; Fri, 4 Dec 2020 13:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=digicert.com header.b=mQxaMskX; dkim=pass (1024-bit key) header.d=digicert.com header.b=UdDwSuJl 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 MjPfg4HlcDQC for ; Fri, 4 Dec 2020 13:17:15 -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 AE0F13A0C1B for ; Fri, 4 Dec 2020 13:17:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1607116634; 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=lJSMX/AfUqVtbfQYO101X211Fylxpw9tqNzfg5lE2qc=; b=mQxaMskXPgPOCZuSRt08AA0Bw9NoPjBzXf68HOU2xvPtdpAnb/3NHfjYzbC+H8wed9ah14 TlN0eloNyjr1q8qZTkuGbiDcLj6aVReX7U6xZWs1lga1+I4sawIFyZgb3Uuaps5Bzg8dxe hACVMYrEJXLm3i9JIv7tQsygAYl5IQ8= Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2106.outbound.protection.outlook.com [104.47.55.106]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-342-P7VGBhfkMMi-__WN3U1Xkg-1; Fri, 04 Dec 2020 16:17:12 -0500 X-MC-Unique: P7VGBhfkMMi-__WN3U1Xkg-1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RdHRpm7ZRn7z0QJBSsYzjgU7E8iYnmPNEncupwf362c+5GyyGyWcl+8A7BOKuTPMB6L5os/ECIlg23VwAQLxmmwBdUgP5KIO4ulJkaDn/cShL8SidTxTCZuoWgnPuJbH0wae71iOeYOKN6MA2LfORY+JlJgaup4CXoObr7Qly3meIsNd7LyI9DoxuBRBqby7XwW72gj/mchPnuzjEbdp9/bkK8Shga68hPdXAKG4c7MktCCcs4KFz7RZq9+fCv1eKmYk7fBr75Kq7cTcbKZpabAbEgfrrEYjK5spjoZhv35zKRVvS70gqTQy43gdSAoN8O9TdRp6cMbeB9rB6wHcqw== 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=lJSMX/AfUqVtbfQYO101X211Fylxpw9tqNzfg5lE2qc=; b=Ga9ZxgiCnXPfvN6jRcoXt5lElo8wTWHHp28ESYBtP3+8gbUtaalPKaTnhVBWXsSpNaDLu194EiRDwYIYcu2FmRmKL29RH+ILp8qO78gUjgN82Ar5ILN3iwo42YhuitkjzROouZAA+Utg02GzLnJyu/HTtSLp3Yc8tWr3gig2v6OrBdOXsl8uhrQJNYAFWyeml64BxWnbCDQbWNFxEvWlH/o3Ky1Ntwq8R93KSWl57wrUjP13cPshAMHUwcvVNOBD94YCi+jLxYc2sHC0MB7EDQ9KXikWdaQ1ppv9vc5nP5CxJm2AkHx2mva0ZwvfDp7VadBm5ZOXTEuK0FDb02TUcQ== 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=lJSMX/AfUqVtbfQYO101X211Fylxpw9tqNzfg5lE2qc=; b=UdDwSuJl2MWV1xwRZZi027F/4zcDDVW4ef0vTB1FecN5/eCQkBZLvbhB6OcycywZHNK+h2RoUB0TAFf3lMyf3NgFjTIbyI9/TuOxNE+hxJ+a9CTKHoUc+2GN8cp+GIW2b10KyvZC/QguYiQCQJDICYo8PzG9Blq8oh71gd7m+wg= Received: from MN2PR14MB3167.namprd14.prod.outlook.com (2603:10b6:208:12e::28) by MN2PR14MB4189.namprd14.prod.outlook.com (2603:10b6:208:1d4::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17; Fri, 4 Dec 2020 21:17:09 +0000 Received: from MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::e1ea:51bf:a4b0:2f82]) by MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::e1ea:51bf:a4b0:2f82%7]) with mapi id 15.20.3632.017; Fri, 4 Dec 2020 21:17:09 +0000 From: Tim Hollebeek To: LAMPS Thread-Topic: WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg Thread-Index: AdbKgl0GZVRVKEllR6iGycD6D5x5ZA== Date: Fri, 4 Dec 2020 21:17:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=digicert.com; x-originating-ip: [74.111.113.115] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bee539ab-70f3-480d-ecf8-08d89899f5c8 x-ms-traffictypediagnostic: MN2PR14MB4189: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vhBVR+Ib1EdgqZ543kA3cuRhuCOJPoAIKwcv+HAcXxSwC9gjMHLkpUWrwkZMrNq0QDu2psp49gltc3qdns3Vh43bScClvel6wDnTcVMvMl47uoB5OVu7dKMYf5PF/FeuQpND4rDM6PCiUMombIJX3gZWEOm2AI3O360nIAdfnugxv/nHwoTZMy0FPlMc1er8H9WqwOPaIVH6/iclXUQzjfXtJ7Zlc+bMNtblvJDTE8NltU56BBjS5O3du7XIleg9TcXKe1tlVX3Oiaut4ouU7FojgpNGXJjK6aj1EPA+87fKwXTSBSjunlp1h3320iV7Hp8EHABGhYGwrRMBGE77l2xOTeMqIq4VTwBZ/izZ6skhODbia1We0IsKV0R8He9f09kfvdEfvSRBdLuvqSnZrg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR14MB3167.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(136003)(376002)(346002)(39850400004)(2906002)(8676002)(6916009)(55016002)(316002)(52536014)(71200400001)(86362001)(66446008)(33656002)(66556008)(66616009)(7696005)(66476007)(66946007)(76116006)(9686003)(6506007)(99936003)(44832011)(966005)(26005)(4744005)(186003)(478600001)(166002)(5660300002)(8936002)(64756008)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?QRLMFg855zWGLBtHMX/gByi8z1PTYaSVBhjt6aH8X8trJ3cmMb8rd+nMzvmg?= =?us-ascii?Q?qBervmWb2h+SGeKtBHSmVEKO3QA63joCi4/MoYjen5FMWO4vKprLElpE6G/2?= =?us-ascii?Q?XH2663Lz1n2wFSPEbCSj+bJQimHbaP4pttZ91a5zvD13C34unKbM1EmfYpqK?= =?us-ascii?Q?v2tKLFfegaC561nWicMYGN3dn8hD9Ynast4ofxnXSIxREhPfvsgpU+//OHNT?= =?us-ascii?Q?Vr0dB6LLhsHBo/hmjkS03MORqijksA+Ba57OdoyHzz1WrrfKCZO6kMlc5Eqv?= =?us-ascii?Q?yPama7GOy6YSAbBZj6UXGvWM6OX4k8gGQN1CYZxWQZspQ8LkLuM1mTm9ddSA?= =?us-ascii?Q?qzt3ythSlr7fAlvSJM66SW5XfC21dHIw1/VvUTHfiB+mls4WFI7KkGwcOJOX?= =?us-ascii?Q?5RAThagH1tMSAPwR2dhPdWjGxIDl8YgfV12Pexye0D2F4Iym8bToFbHVmnrI?= =?us-ascii?Q?r00694wCVpuJId7tsGKCg+xoKiS2V7bhWHSEjKCpyg6Rxf+UpnP74e3OFWfT?= =?us-ascii?Q?gWpBBSNOkgtrNYFkWjiJ3f5G4GohH5GbQ7GdwSt7nv4YrvZSGaJb5kIafMpG?= =?us-ascii?Q?I/142hZvvCfoUGI0XFSX8WPyGMmuEGCrriJpGGXspLZ7lVkflIaJhQOiXXRf?= =?us-ascii?Q?oESuzaDiernmn4xs0oKYhUAoRlfUBx3mHAi2+Y+iMewzRoFS9GpeF1K59SLL?= =?us-ascii?Q?m1Ka5wSISvsDQcxqUQc3xZgrzAppdcwCrY4TpAs2IpWZ5pjOI6GGqCVgEGIw?= =?us-ascii?Q?4bmlI1fOBJ93vG8xwSPDQ4Jx/XVyeEnLIcFBOqN5TinrkQJHGDPFb9RaayDP?= =?us-ascii?Q?H47clS/n5qSwXfNWttvxf+1Sdyj4b8Ql76gwNRGz43dwQnnjraq013eEB30g?= =?us-ascii?Q?BcohHqO3581e0eILORqkk4vA5rOvHXHV5yV99yJ6bmtEMZ8MFU9PNX7Kt0+6?= =?us-ascii?Q?qhNM/BTZQXJhbjd1dsxbuBGKA0xbo+kzVzIXbX+JenQ=3D?= 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_0780_01D6CA58.E9BDA120" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR14MB3167.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bee539ab-70f3-480d-ecf8-08d89899f5c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2020 21:17:09.2759 (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: y6HSMJ6231uxJJpBOpFC2zNg4EL1wIYa4peXTPcfOD5ROhDDRkvBfDrJGp/ib0rq68gzTEKXPA/PG3qDueOpYS2n34fC2mxsJyTQztHPYrQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB4189 Archived-At: Subject: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 21:17:18 -0000 ------=_NextPart_000_0780_01D6CA58.E9BDA120 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0781_01D6CA58.E9BDA120" ------=_NextPart_001_0781_01D6CA58.E9BDA120 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is the LAMPS WG Last Call for "Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS)" . Please review the document and send your comments to the list by 18 December 2020. The datatracker page for the document is https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-aes-gmac-alg/ -Tim ------=_NextPart_001_0781_01D6CA58.E9BDA120 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is the LAMPS WG Last Call = for "Using the AES-GMAC Algorithm with the Cryptographic Message = Syntax (CMS)” <draft-ietf-lamps-cms-aes-gmac-alg-00>.  = Please review the document and send your comments to the list by 18 = December 2020.

 

The = datatracker page for the document is https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-aes-gmac-alg/

 

-Tim

------=_NextPart_001_0781_01D6CA58.E9BDA120-- ------=_NextPart_000_0780_01D6CA58.E9BDA120 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 CQUxDxcNMjAxMjA0MjExNzA4WjAvBgkqhkiG9w0BCQQxIgQgev+v37t3VuzUnt3Lrx/d4hMRUBfW LQjxBqTyeW30NJ4wgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAJCZEqtsIdQlU4RyYJzp6hfDNIsMJWuXGIzRHe4AqMN2N2WZUM8Iy+u7xvJOVv4POUdERLEQ bWhL7xky/ph/SRng3ayR/c3xsAus4syCPDGWA176gqjwNBMnZ1on0p30uVltvvWuyEXJRWtzfFAK FN5aCFPhgQ/52nt4ZkfkWa1LzXo8f6dZUlSRFfUUyN1oO89uOZ11on+THPe2EmfLXaoAHzDr1ppy 4hmHEmkegOi49aVVyOcW+/FBZGut4q/QyGvGSjfT0A7oc2gJvQ833CXGrrzNgcV59NSeDJChmzAb GU8iJQSeSCz3IU+z07d/oFDNZQRVxqE30nGq7PFTkagAAAAAAAA= ------=_NextPart_000_0780_01D6CA58.E9BDA120-- From nobody Sun Dec 6 13:12:07 2020 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 CAC4E3A0C00 for ; Sun, 6 Dec 2020 13:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 GZyCk5At3VmC for ; Sun, 6 Dec 2020 13:12:03 -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 34BA13A0BFD for ; Sun, 6 Dec 2020 13:12:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 87DEE300BB7 for ; Sun, 6 Dec 2020 16:12:00 -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 HyEeanK8baPR for ; Sun, 6 Dec 2020 16:11:59 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 5E824300ADB for ; Sun, 6 Dec 2020 16:11:59 -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.17\)) Date: Sun, 6 Dec 2020 16:12:00 -0500 References: <2C7FE71D-D3DA-49CF-B133-EAC979309951@vigilsec.com> To: LAMPS In-Reply-To: <2C7FE71D-D3DA-49CF-B133-EAC979309951@vigilsec.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [lamps] Timing for LAMPS Interim Meeting 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, 06 Dec 2020 21:12:06 -0000 So far, there is only one spot that all of the people responding to the = poll can make. We will go with that unless others shift the balance in = the next few days. Please respond to the pool! Russ > On Dec 4, 2020, at 3:31 PM, Russ Housley wrote: >=20 > Since we need to re-charter the LAMPS WG to take on = draft-dkg-lamps-e2e-mail-guidance, this seems like a good time to ask = what other topics the group might want to tackle. The WG chairs have = hear interest in topics related to the transition to PQ cryptographic = algorithms. We think that a virtual interim on that will help determine = what, if anything, should be included in the re-charter. >=20 > Please fill out the Doodle poll for dates in January that might work = for you. >=20 > = https://doodle.com/poll/38kraeib4zbws554?utm_source=3Dpoll&utm_medium=3Dli= nk >=20 > Russ & Tim From nobody Mon Dec 7 07:48:56 2020 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 077BC3A11D3 for ; Mon, 7 Dec 2020 01:06:58 -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_MSPIKE_H2=-0.001, 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 XQC2vsE-AeWw for ; Mon, 7 Dec 2020 01:06:56 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB7A43A11EE for ; Mon, 7 Dec 2020 01:06:40 -0800 (PST) Received: from macsilver-2.fritz.box ([62.54.177.99]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.183]) with ESMTPSA (Nemesis) id 1M42Ss-1kmCTe29aq-0002gk for ; Mon, 07 Dec 2020 10:06:38 +0100 From: Metin Savignano Content-Type: multipart/signed; boundary="Apple-Mail=_8460EF65-6043-42BA-9AD3-093A3AAA087D"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Message-Id: References: <5F4E87EE-4CD1-4A9F-BDE2-82AD8FD6EFB1@savignano.net> To: spasm@ietf.org Date: Mon, 7 Dec 2020 10:06:37 +0100 X-Mailer: Apple Mail (2.3445.104.17) X-Provags-ID: V03:K1:cfMAHIA4FAhV73jf/yzgHVpzicQRyyeKDOgK77tJi6AW8koD3TH LCVV2k6oR7qNIugw//niyInZ9Ow++hkeLrliuw1Y5Sq9iZNxQa6+Km3pedq0NtYeo8IOBS3 9o1EdgRXRCRj+IBgHbqKUCx9moIaEmrF/PL4lbuacKAbDrH4DzbMdwZdtUf7MhomMHFAPGC vslnmG/Gltm4QI4l3W6LQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:OQlXEI0W0s8=:4Om2w4gRhgVO8i6FbUlTX6 Kc+JkvNJSN3o+3shtgwQq6bWSNqTQ443LNALfZA5RfleW3TFsaGPq/WTqxMYPq3SIcA8rBXG2 oNvJqYpTjXv/RBcLwYUI9wU0inQBRD3U0/AcD6NJOuN3eCy7H+W1Ik8Zmq/5MTHcXCw3hz3Tf +X35vU5Vy1N30Rh/BDcZUQ6XUslgxPvpdLo6nBr+TCvnWdbryHOucVcIzBv/EmDgN47oPNWPy ayUwLKw+fi4aeEKiBvltCcAFvNmDq6vIpLaW86fXcyNa1/Q77qHSkasNkXqUUc+h+U1afIbdm gGvU1QG/ifcLVQNxarsjJMOhTOi7fF5qVUrURrgqM95iLslWP6Pjz3NBdAQguToQchaa1izmv TUuYqT67vOqNI3UpMlsUX02f6V3LT6UY/bHT7MekrGjOfrg/LoXrLNRnTpunp Archived-At: X-Mailman-Approved-At: Mon, 07 Dec 2020 07:48:55 -0800 Subject: [lamps] Fwd: Possible inconsistencies or ambiguities in RFC 8551 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 09:06:58 -0000 --Apple-Mail=_8460EF65-6043-42BA-9AD3-093A3AAA087D Content-Type: multipart/alternative; boundary="Apple-Mail=_E6C0F7FC-7229-42F1-9D0E-793B85D10CE0" --Apple-Mail=_E6C0F7FC-7229-42F1-9D0E-793B85D10CE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, referring to my email quoted below of 7th August, may I ask if and how I = would get a reply? I haven=E2=80=99t seen one, and I am wondering if I = would have to look at some other place? Thanks Metin > Anfang der weitergeleiteten Nachricht: >=20 > Von: Metin Savignano > Betreff: Possible inconsistencies or ambiguities in RFC 8551 > Datum: 7. August 2020 um 13:01:53 MESZ > An: spasm@ietf.org >=20 > Dear authors, >=20 > First of all, thank you very much for your work to create a new and = better version of S/MIME!=20 >=20 > As an author of an S/MIME app, we are working through RFC 8551 to = determine the changes we have to implement in order to fully comply to = the S/MIME 4.0 specs. >=20 > However, I=E2=80=99ve come to a point where I seem unable to = understand what the RFC actually recommends with regard to the backward = compatibility. I=E2=80=99ve also discussed this with another software = developer, but we both weren=E2=80=99t sure how to read it. It would be = awesome if you could help me with a clarification. >=20 > In the relevant scenario, the sending agent wants to send encrypted = email to a recipient with unknown capabilities. >=20 > With regard to backward compatibility, RFC 8551 states in section 1.4: >=20 > S/MIME version 4.0 agents ought to attempt to have the greatest > interoperability possible with agents for prior versions of S/MIME. >=20 > Although this is a very general statement, I believe it is = contradictory to the description about how to decide which content = encryption cipher to use in section 2.7.1.2: >=20 > If the following two conditions are met, the sending agent SHOULD = use > AES-256 GCM, as AES-256 GCM is a stronger algorithm and is required > by S/MIME v4.0: > - The sending agent has no knowledge of the encryption = capabilities > of the recipient. >=20 > - The sending agent has no knowledge of the version of S/MIME used > or supported by the recipient. >=20 > I don=E2=80=99t understand why we should choose AES-256-GCM if we = don=E2=80=99t know about the recipients capabilities and S/MIME version.=20= >=20 > For example, if the recipient uses an S/MIME 3.2 compliant software, = as I understand RFC 5751, that software need not know about AES-256-GCM. = The GCM block mode is not even mentioned in earlier S/MIME versions.=20 >=20 > As a consequence, doesn=E2=80=99t the selection of AES-256-GCM = contradict the "attempt to have the greatest interoperability possible = with agents for prior versions of S/MIME=E2=80=9C?=20 >=20 > The common capability in both S/MIME versions would be AES-128-CBC, = wouldn=E2=80=99t it? >=20 >=20 > Also, I do not really understand the following sentence: >=20 > If the sending agent chooses not to use AES-256 GCM in this step, > given the presumption is that a client implementing AES-GCM would = do > both AES-256 and AES-128, it SHOULD use AES-128 CBC. >=20 > It appears to me as if this sentence was grammatically either wrong or = uses a construct that I don=E2=80=99t understand (I=E2=80=99m not a = native speaker). I don=E2=80=99t understand what "given the presumption = is that a client implementing AES-GCM would do both AES-256 and = AES-128=E2=80=9C is meant to tell me in that context. Also, I=E2=80=99m = not sure if the word =E2=80=9Eclient=E2=80=9C is meant to refer to the = sending or receiving client. At first, I thought it=E2=80=99s the = receiving client, but after re-reading a few times, I=E2=80=99m unsure = if it=E2=80=99s the sending agent, because I don=E2=80=99t understand = why I should make presumptions about the receiving client implementing = AES-GCM when I don=E2=80=99t know anything about it. >=20 > I would recommend that this sentence maybe rephrase to make it more = understandable for non-native speakers. >=20 > What I would have expected in section 2.7.1.2: >=20 > To maintain "greatest interoperability possible with agents for prior = versions of S/MIME=E2=80=9C, the RFC would select AES-128-CBC if the = recipient=E2=80=99s capabilities and S/MIME version aren=E2=80=99t = known. >=20 > Where am I off the track? >=20 >=20 > Thanks a lot! >=20 > Metin Savignano >=20 >=20 >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_E6C0F7FC-7229-42F1-9D0E-793B85D10CE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

referring to my email quoted below of 7th August, may I ask = if and how I would get a reply? I haven=E2=80=99t seen one, and I am = wondering if I would have to look at some other place?

Thanks
Metin


Anfang = der weitergeleiteten Nachricht:

Von: = Metin Savignano <ms@savignano.net>
Betreff: = Possible = inconsistencies or ambiguities in RFC 8551
Datum: = 7. August 2020 um 13:01:53 = MESZ
An: = spasm@ietf.org

Dear authors,

First of all, thank you very much for your work to create a = new and better version of S/MIME! 

As an author of an S/MIME app, we are = working through RFC 8551 to determine the changes we have to implement = in order to fully comply to the S/MIME 4.0 specs.
However, I=E2=80=99ve come to a point = where I seem unable to understand what the RFC actually recommends with = regard to the backward compatibility. I=E2=80=99ve also discussed this = with another software developer, but we both weren=E2=80=99t sure how to = read it. It would be awesome if you could help me with a = clarification.

In the relevant scenario, the sending agent wants to send = encrypted email to a recipient with unknown capabilities.

With regard to backward = compatibility, RFC 8551 states in section 1.4:

   S/MIME version 4.0 agents =
ought to attempt to have the greatest
   interoperability possible with agents for prior versions of =
S/MIME.

Although this is a very general statement, I believe it is = contradictory to the description about how to decide which content = encryption cipher to use in section 2.7.1.2:

   If the following two =
conditions are met, the sending agent SHOULD use
   AES-256 GCM, as AES-256 GCM is a stronger algorithm and is required
   by S/MIME v4.0:
   -  The sending agent has no knowledge of the encryption =
capabilities
      of the recipient.

   -  The sending agent has no knowledge of the version of S/MIME used
      or supported by the recipient.

I don=E2=80=99t=
 understand why we should choose AES-256-GCM if we don=E2=80=99t know =
about the recipients capabilities and S/MIME version. 

For example, if the recipient uses an S/MIME =
3.2 compliant software, as I understand RFC 5751, that software need not =
know about AES-256-GCM. The GCM block mode is not even mentioned in =
earlier S/MIME versions. 

As a =
consequence, doesn=E2=80=99t the selection of AES-256-GCM contradict =
the "attempt to have the greatest interoperability possible =
with agents for prior versions of =
S/MIME=E2=80=9C? 

The =
common capability in both S/MIME versions would be AES-128-CBC, =
wouldn=E2=80=99t it?


Also, I do = not really understand the following = sentence:

   If the sending agent chooses =
not to use AES-256 GCM in this step,
   given the presumption is that a client implementing AES-GCM would do
   both AES-256 and AES-128, it SHOULD use AES-128 CBC.

It = appears to me as if this sentence was grammatically either wrong or uses = a construct that I don=E2=80=99t understand (I=E2=80=99m not a native = speaker). I don=E2=80=99t understand what "given the presumption is that = a client implementing AES-GCM would do both AES-256 and AES-128=E2=80=9C =  is meant to tell me in that context. Also, I=E2=80=99m not sure if = the word =E2=80=9Eclient=E2=80=9C is meant to refer to the sending or = receiving client. At first, I thought it=E2=80=99s the receiving client, = but after re-reading a few times, I=E2=80=99m unsure if it=E2=80=99s the = sending agent, because I don=E2=80=99t understand why I should make = presumptions about the receiving client implementing AES-GCM when I = don=E2=80=99t know anything about it.

I would recommend that this sentence = maybe rephrase to make it more understandable for non-native = speakers.

What = I would have expected in section 2.7.1.2:

To maintain = "greatest interoperability possible with agents for prior versions = of S/MIME=E2=80=9C, the RFC would select AES-128-CBC if the = recipient=E2=80=99s capabilities and S/MIME version = aren=E2=80=99t known.

Where am I off the track?


Thanks a lot!

Metin Savignano








= --Apple-Mail=_E6C0F7FC-7229-42F1-9D0E-793B85D10CE0-- --Apple-Mail=_8460EF65-6043-42BA-9AD3-093A3AAA087D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBDQw ggQwMIIDGKADAgECAgEgMA0GCSqGSIb3DQEBCwUAMIG1MRowGAYDVQQDDBFzYXZpZ25hbm8gQ0VS VC1pMzElMCMGA1UECgwcc2F2aWduYW5vIHNvZnR3YXJlIHNvbHV0aW9uczEdMBsGA1UECwwUQ2Vy dGlmY2F0aW9uIFNlcnZpY2UxCzAJBgNVBAgMAkJXMQswCQYDVQQGEwJERTEUMBIGA1UEBwwLTHVk d2lnc2J1cmcxITAfBgkqhkiG9w0BCQEWEmNlcnRAc2F2aWduYW5vLm5ldDAeFw0xOTExMDUyMDI2 MjJaFw0yMjAxMzEyMDI2MjJaMIGSMRgwFgYDVQQDDA9NZXRpbiBTYXZpZ25hbm8xJTAjBgNVBAoM HHNhdmlnbmFubyBzb2Z0d2FyZSBzb2x1dGlvbnMxCzAJBgNVBAgMAkJXMQswCQYDVQQGEwJERTEU MBIGA1UEBwwLTHVkd2lnc2J1cmcxHzAdBgkqhkiG9w0BCQEWEG1zQHNhdmlnbmFuby5uZXQwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCxnKn6b7wTrY7G4ov3Hdt6Z9Q4p3obZ8WFzXyg ++Vlf7FnPQL9wIYNfpMRexAZK1/y6kiaPhVFArm6/RZicRDv8/89IB8SlITGqXx0/Y+S4jSxre8E FUXi/BFhbI/F/jMv+YUUgUf/cMpu62F726u0PSUgX+4UQgmV9ksex3UV2KF7juHjuibUqYmHldWt 6lfDaAf5fBBlhL/x8cF6KjPjTC3DUrL1GMga8ZQfNfyPRpwVudgrK40yaTda+eHU8dLjOtrc6K/p PM/cx90RfL9IrLiyx1dZMPvjNHcxVwPdsTIrqom4DSNX9s4wRf70f/MpHL6aZ7IxuhdQO1bqd3Ah AgMBAAGjbDBqMA4GA1UdDwEB/wQEAwIFoDAmBgNVHSUEHzAdBggrBgEFBQcDBAYIKwYBBQUHAwIG BysGAQUCAwQwMAYDVR0RBCkwJ4EQbXNAc2F2aWduYW5vLm5ldIETbWV0aW5Ac2F2aWduYW5vLm5l dDANBgkqhkiG9w0BAQsFAAOCAQEAnvw8CEHRy3xCSHrcmCh1/b6PlxCURYynWgABvJgd3+0Acw4V DRgtA7vnozkSu/FHZy2pNv1wOf2F3AWIU9qUxqssZogvIgI1LwKQZ2YO+ymkous4qBWc44Twmhi2 2juBjuxEUPC3+x/ZEmkCz4z95qtHeL+B3EqpcGgDemkTgtT7mv0053mN+vyFOxpxQiSKfMAVwvJe lTLax2g3MXbT7ycZpHXJ2nnA/ZprqJg5+bFMg9J/Q9Vvc5q3d6qFU+Od7JzKg79gWe8p7S8Dul0b Bcl0phLIgPHk++lxlGDtizzOt5DZWcVyKKGeMDNPPKtopb9ZQulRKJj20szhznopKzGCA/QwggPw AgEBMIG7MIG1MRowGAYDVQQDDBFzYXZpZ25hbm8gQ0VSVC1pMzElMCMGA1UECgwcc2F2aWduYW5v IHNvZnR3YXJlIHNvbHV0aW9uczEdMBsGA1UECwwUQ2VydGlmY2F0aW9uIFNlcnZpY2UxCzAJBgNV BAgMAkJXMQswCQYDVQQGEwJERTEUMBIGA1UEBwwLTHVkd2lnc2J1cmcxITAfBgkqhkiG9w0BCQEW EmNlcnRAc2F2aWduYW5vLm5ldAIBIDANBglghkgBZQMEAgEFAKCCAgkwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAxMjA3MDkwNjM4WjAvBgkqhkiG9w0BCQQxIgQg blJKQmB7q2L9Lr/uRl5SyCJNj7OU0BB2/2RO+/IeS70wgcwGCSsGAQQBgjcQBDGBvjCBuzCBtTEa MBgGA1UEAwwRc2F2aWduYW5vIENFUlQtaTMxJTAjBgNVBAoMHHNhdmlnbmFubyBzb2Z0d2FyZSBz b2x1dGlvbnMxHTAbBgNVBAsMFENlcnRpZmNhdGlvbiBTZXJ2aWNlMQswCQYDVQQIDAJCVzELMAkG A1UEBhMCREUxFDASBgNVBAcMC0x1ZHdpZ3NidXJnMSEwHwYJKoZIhvcNAQkBFhJjZXJ0QHNhdmln bmFuby5uZXQCASAwgc4GCyqGSIb3DQEJEAILMYG+oIG7MIG1MRowGAYDVQQDDBFzYXZpZ25hbm8g Q0VSVC1pMzElMCMGA1UECgwcc2F2aWduYW5vIHNvZnR3YXJlIHNvbHV0aW9uczEdMBsGA1UECwwU Q2VydGlmY2F0aW9uIFNlcnZpY2UxCzAJBgNVBAgMAkJXMQswCQYDVQQGEwJERTEUMBIGA1UEBwwL THVkd2lnc2J1cmcxITAfBgkqhkiG9w0BCQEWEmNlcnRAc2F2aWduYW5vLm5ldAIBIDANBgkqhkiG 9w0BAQEFAASCAQBXeqbG/AFhxoIPwE1NIE7km03JbRavFXCjLkDm/5Fad0LuIFD3SJFN7Ss8Lo1k e8FrDLiz/o8xfWZsn5ry0ufrzmfcAznJ0u2eorGk49b3B2EZfYifjWf8JUuLVwKSV+1Umt0iYi27 Ut93awmW5gesKF5gkgqDujyMqeWlTWXWfsBbk5Pqf/8FU/O+sf9EQO36abIbc+60PlcEQzLGZ59Y gGjnViNkoRbh0L31cmyLvf4b0fRmYwTCGLCxjCZsej/9hFYBFiCTn7y5J+9GxbDVYp59SYAty2fF Z2NnmXTR5tmJCHtXYFmhcpctYELIcooSFmuAd5o/cuchGjA34GwqAAAAAAAA --Apple-Mail=_8460EF65-6043-42BA-9AD3-093A3AAA087D-- From nobody Mon Dec 7 10:23:16 2020 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 1E0413A1649; Mon, 7 Dec 2020 10:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 rvixzi3o3wja; Mon, 7 Dec 2020 10:23:01 -0800 (PST) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 CA2053A1402; Mon, 7 Dec 2020 10:23:00 -0800 (PST) Received: by mail-vs1-xe31.google.com with SMTP id h6so8090572vsr.6; Mon, 07 Dec 2020 10:23:00 -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:cc; bh=j1pp6IGffPEr12SzP+/GRmkgseP5ECtY0t4Alb91ETo=; b=BOXno+xuIAlIOXj7whlmlZSydZYtqKJs5lVkT1M+Gb+8vPz4JYVOeww31OnShLKQVM 5lIbjshv9f1nEp09NeCofnfc7tfWxXXVvp1j+elOg630e8X19s4pUsROXHUm/0M5MyEY sRiCxpZvptI0WesC2OO51aBARDcz1YdKY5sVpbfggwL3+PMLWrpfS8uxRgQ1Di3+GLdk Lz4GpeEnMuzABn1tCOEtqj4wds1+wwdnaO5rztxHeXOMvm1GTenrWJPJIW97Ki3KaUBY 5GjvyMCthX1GyjiMe+Dqz+xtYiCjsW0Ubr0N8Q/WBFPYhCXqi60LT03VWKsIkv/kOUwO dEqA== 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:cc; bh=j1pp6IGffPEr12SzP+/GRmkgseP5ECtY0t4Alb91ETo=; b=uMzkO6hcRyq0nYGKNmka3apMvj4JxdJtdCUkInk+O3RPxyb9IccAFX3XAQtxl9k2vC mHRyx7x/7kJV1YCD8YlZv0zVczKPmrMObinWXIujgnOf7vyzTvjWjWU94Mi2XUnRIszv +P7Fuha0Hm5N+wHLIk+qoOO8+BDsIyfTmfHjnZ2JrCFsFEqHeag6P+C1QIX//aMqmy4j jSSeDxJnwVkTPc2ngdKmNku1YBc7IHlyziEKVOXZjjrv6t2vNNgOK/TxMExN7+9lkOeR 3MEzX8rcvbc8hUbZXUJxClWKcdgKKm5Mof6ADtzjPSO3eQs9vpYHzyVcqz0EYWWnN3DL p/BQ== X-Gm-Message-State: AOAM5306ahsC0JDjszzQhfWLCRSGcJ7Jz/fSP68k+SlkAbGgTLo9dKsN B3wDtlI5bo2FuwqctbNn5Otk3PFUNZPdX6jpRUOpzv264Oo= X-Google-Smtp-Source: ABdhPJwK7HyDC5ftaGmWII6nvHW9TicCjlUHdFqhqTDPPtcABrbsGf0Xh1qWlp1eNrlErc7U1CVtFJAbE96iVbm0b/A= X-Received: by 2002:a05:6102:3ce:: with SMTP id n14mr3674912vsq.56.1607365379582; Mon, 07 Dec 2020 10:22:59 -0800 (PST) MIME-Version: 1.0 From: Daniel Migault Date: Mon, 7 Dec 2020 13:22:48 -0500 Message-ID: To: SPASM , anima@ietf.org, iotops@ietf.org Cc: Ace Wg Content-Type: multipart/alternative; boundary="000000000000796ddd05b5e3eac4" Archived-At: Subject: [lamps] ACE new charter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 18:23:03 -0000 --000000000000796ddd05b5e3eac4 Content-Type: text/plain; charset="UTF-8" Hi, The ACE WG though you might be interested in knowing that the current ACE charter considers, among other things, working on CMPv2 over CoAP. The current charter can be found here [1]. If you think the work should be done in another WG, please let us know before Friday December 11, so we can move the charter forward. Yours, Daniel [1] https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing -- Daniel Migault Ericsson --000000000000796ddd05b5e3eac4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

The ACE WG though you might b= e interested in knowing that the current ACE charter considers, among other= =C2=A0things, working on CMPv2 over CoAP. The current charter can be found = here [1].=C2=A0
If you think the work should=C2=A0be done in anot= her WG, please let us know before Friday December 11, so we can move the ch= arter forward.=C2=A0

Yours,=C2=A0
Daniel=C2=A0<= /div>

=
--000000000000796ddd05b5e3eac4-- From nobody Mon Dec 7 14:39:32 2020 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 0741E3A0B50 for ; Mon, 7 Dec 2020 14:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=entrust.com header.b=fbD5dF9+; dkim=pass (2048-bit key) header.d=entrust.com header.b=X9mOdjP0 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 sgUd3odY25dH for ; Mon, 7 Dec 2020 14:39:29 -0800 (PST) Received: from mx2.entrustdatacard.com (mx2.entrustdatacard.com [204.124.80.222]) (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 6BBEC3A09D6 for ; Mon, 7 Dec 2020 14:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=entrust.com; i=@entrust.com; q=dns/txt; s=esa1; t=1607380769; x=1638916769; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=icguPR+wJSUr/7V3QKm8ExE6CEVrERQPEJ141rdLxX0=; b=fbD5dF9+jM6ei9o/1tuxiKRtfMxVETqyW7yfmTQX9z3NpJWFKEULHp53 /1wkcTjeUD04kTrHBzv/XammtazvRKPmXmAFk+0OGZWP5p45q0U73btpd z8ltb4IDHsoAf+tO1tPE0lCry7gUFvvs3McJ8x0NllkWrQAWJrSyF7qVF M+dA+gC+Mad+vvMHPWGuMXrS1mbf9apStS1lHdFCj7GOtn5gRZS1JZAb3 8oNal4fAymnpJJfZAz5V1p21YiTsD9n528DvVYxAVVK8bIAL6YWz4QCyM ssv19DDc8T08y1g0Tq5AutL1UBqBVlQwRqossGeRVC1H9ImgQW8qB3Et3 w==; IronPort-SDR: GsPpy9S5iLk2+uRm06J0Ku6GvBf2ug7WQSHGxRECl1wjyaGVmMl0lyX+quU8Li++jDdrnBJwx8 vLV/v5qp5b9A== X-IronPort-AV: E=Sophos;i="5.78,400,1599541200"; d="scan'208";a="25001203" Received: from pmspex01.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.29]) by pmspesa04inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 07 Dec 2020 16:39:28 -0600 Received: from pmspex01.corporate.datacard.com (192.168.211.29) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 7 Dec 2020 16:39:28 -0600 Received: from NAM10-MW2-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; Mon, 7 Dec 2020 16:39:28 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fK8fc6ZLc5xKPhoC6DMZYYy/XKUJ1/tCKVT3SUknth6qKmnawFxyQ19HOBm515QNT0YV62ApGfdstgLl5MMwTCW4Ho/xicPZOEoTebusNUwwHDdioXblzP0w9MJkZeyCizertD+7OzcehtFWHpBUqAc8YCVV9XIzC1D1Ih47ti88PjhESOvaQpTp+x2DPAJWvUekNPQKK2zDmYXXgCTryjKhp++gxtiTvj9sgs2fuBLZAyyf9FXuybTWoPlLTwWYcbiPmgXDd6V2MnURSPNpJ9ONwSaRc40qU0UWmXNOLN74EAHJljr/iq2xvoVA0uRBdrH/60e3cp+T3ug6pIaZkQ== 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=icguPR+wJSUr/7V3QKm8ExE6CEVrERQPEJ141rdLxX0=; b=XFmftF5aE8TDTeRzJcBvsk6PU2WklVnehjS9zEohkDSrNpLEHnP+F9pKk0M2BYTGfuqrZ/XWedtpx62R6Hvkr94d5ixaA00Yu/+N6qBOGNxrhevbXg9pnafKZoZl5gldxJRDbSLk0sBTrQU0LzefFGsLlerZM2Fem+pSstfa+3sFVLwPFw5CdyRDJPzY+ak8efghyxeGDuri03gnGma3mxEICYhOn9tnRIHIj7eYRrFVkOh2XTCuCbB/0Kd4BMGj1DIeM6ee8SLJxGMmPti1Gl0Ta7XMh6sWJCo2Tz4gTDHKzoyrXBUDdQ44dCZYRK5kgCN/7KbCqP/0Cy2OvA6bqQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrust.com; dmarc=pass action=none header.from=entrust.com; dkim=pass header.d=entrust.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrust.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=icguPR+wJSUr/7V3QKm8ExE6CEVrERQPEJ141rdLxX0=; b=X9mOdjP0ieDvzL972IH0ouQXLBYQWeL8JwIXIWB94jjGCs5UkMBKuZ+EGNgfnkMYdej1FpC1QVPy8Z2jkLKoMAEYcgTk/ibvxM9QJcTa/SS+2Cp5hSyeRtC7JrSxC/JtArTAlFwHjsqlK2SSXcW49I/YwtSIUanFQdaM7ZGsM1mASEJ8uJybJZ8uwmE1ra62vUZsRWEC1he7PnhDes36HA1WpwFJNoTNuAEsfzy/SAXqybydqPyUPnEkuV2zuK4O9yp6lWhf+GHg3NJOyA0fm3G7KXuLf4JjYkzJSddAgSzzxU6+Fi8D4hAKkwdCPNX1TX9qD2+0k1R0uAs4AEGluA== Received: from DM6PR11MB3915.namprd11.prod.outlook.com (2603:10b6:5:19c::11) by DM6PR11MB4577.namprd11.prod.outlook.com (2603:10b6:5:2a1::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17; Mon, 7 Dec 2020 22:39:26 +0000 Received: from DM6PR11MB3915.namprd11.prod.outlook.com ([fe80::3c6a:d17b:805e:dc6c]) by DM6PR11MB3915.namprd11.prod.outlook.com ([fe80::3c6a:d17b:805e:dc6c%3]) with mapi id 15.20.3632.023; Mon, 7 Dec 2020 22:39:26 +0000 From: Mike Ounsworth To: "Brockhaus, Hendrik" , 'LAMPS' Thread-Topic: CMP and PBKDF2-MAC (use RFC 8018's PBMAC1?) Thread-Index: AdbJ0P8rWe8VkkwJQiygQBWyNOJifQAl0vqAAKBLTEA= Date: Mon, 7 Dec 2020 22:39:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-12-04T18:11:12Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=5d705b44-1e79-4d96-a968-e258123fa4db; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 authentication-results: siemens.com; dkim=none (message not signed) header.d=none;siemens.com; dmarc=none action=none header.from=entrust.com; x-originating-ip: [76.71.21.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0fef6bd7-6d55-45c7-6a92-08d89b00f3dd x-ms-traffictypediagnostic: DM6PR11MB4577: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zXib7zKs2Qq2MG0VR3OibWi1BA7RqH19xgHwVqNpwXI+FsbB8HNnJiPBnqXFnXsdpA48RnilZGh9W1JEM2TxzFgzfuWPcnMsLxDBTDsqB9L9qzfAG1DxA2oh4b8aFY8Opyu2gqe/5tw0LAC877FbRbVWuEBc3Q9AqgNiUcHpYHnmuoTLDvn4O2lN++pi+s8W3erR9N4I6wmtnDX38b5/ROdfaafASv6fBbRqjtXhQgzgXqMCMU5/l+1mdemPOIqxf+pbPN47xDse/P39KQmFDSbCD9PgVHrS+Lc2lV0xcu7pQx5VSUBX4vzLu7D8KJuqM4iMqXWPh/Y+pG2BUMCfOQ1GIzsqmOjNnGm+RfcogNhT0ypSjhVHUPzBX92b2RIKlgwn/kc04i8Qigm0B+2MGg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3915.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(136003)(376002)(396003)(366004)(346002)(71200400001)(66556008)(76116006)(55016002)(186003)(9686003)(86362001)(83380400001)(110136005)(5660300002)(2906002)(33656002)(8676002)(478600001)(6506007)(53546011)(64756008)(66946007)(66476007)(26005)(66446008)(966005)(52536014)(316002)(7696005)(8936002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?5UbG9hsaImREWoknl9/1bQJPhfH5To/qZ7sTVR+a3UeFliilJDQRlsmnBIJQ?= =?us-ascii?Q?gWunxKoMaHYBdQ8sxeNHQ7sfwnpJppRV2YIWSK6FqEYF5m9tupmjg7yWoPQy?= =?us-ascii?Q?vT0SOA4VSfkztauiPtvOuwf1NTBa0sA7gztec0PJGiMGphGF0jVbtqKr0EyQ?= =?us-ascii?Q?zcqzn1H4SqAEEnGktYq+MhaFp5GV5kVGiEH5pg5Qo7fTY7WUvAnmCqNHEE4Z?= =?us-ascii?Q?oCtiIW8hS6Y5TvwFcLfi1LSa+TFJe102OCOdp1Q+F/1dfh1B1gbIHSLr+V08?= =?us-ascii?Q?qO2sz8lS9vHNzUTwm1FYZWiRNVOR9KQPleBXNMdnQmOpNnY+cvC5Fm/r6if7?= =?us-ascii?Q?RTgzqoICp4ubP3GZlc4sH86CzFzmX+YF4G10M6e/NhT8OYQG8OBTTHvBt0+K?= =?us-ascii?Q?h1vmdOvh22KcEBOG7loEqSaSz+505CjETL0nHjAg9WxFAUNin0vTEPSQLZ+e?= =?us-ascii?Q?5JfRIMU/JrgbgKHSs/8pKkC+38BBbT5pM70B8oh+UXBq6pxssltRYHY6IdOL?= =?us-ascii?Q?rhurYL0P5ngt5qAcJlfQ5kmPPFbrKJGx3mZTv26NVyPPua5f1g36vO3ZH9pc?= =?us-ascii?Q?sx74Q06xGMYyP8/Ub52tNfp4TOF6WTLe907kGh3trET9nq3fYhNx4aQIgCMn?= =?us-ascii?Q?owhcNAFsQKyBz9MB3Fl9N9uq/0t9jV3HOc5WH+HXezdWyaT0xEB5TwLUH527?= =?us-ascii?Q?ZJdqfAsKihkXwrLIk85zaachSrDxvVNuUQURz4q5/0P8PeKulZBZVmlEf/Hf?= =?us-ascii?Q?PfwIdq39aHzvYwtrApeBarpZ4bY86QMgXV+vTlIi8dd3mBMLdpQyXuBS6YuQ?= =?us-ascii?Q?rIpQRcOkHZMNNibMWjGy6rnMuQC8oy6P8UZF0j1KvV+jrczMT/jbQDMOvBNh?= =?us-ascii?Q?uvC/tOG2vLxIT8eUDG4kapD7tR6R19wiPwPf8VqL9GL02gTDCN5PNxA3JJk6?= =?us-ascii?Q?G4H+v+Ht1tkF8Glt+FTYSmlnnsFPhuqPkM9rMZrwexM=3D?= 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3915.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0fef6bd7-6d55-45c7-6a92-08d89b00f3dd X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2020 22:39:26.5355 (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: Rmbdi+/DEbS9CRYLGsqwvlpboDa0tnou6NkQNZjn4BsC3GwXJ5comTghjSCLLv56GdktXWnxKl0ghocETEWS2UsnItOIKfyH48sT2xSHBTs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4577 X-OriginatorOrg: entrust.com Archived-At: Subject: Re: [lamps] CMP and PBKDF2-MAC (use RFC 8018's PBMAC1?) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 22:39:31 -0000 Hi Hendrik, Are you interested in collaborators on draft-ietf-lamps-cmp-algorithms-01? = We would love to help you update your section 6.1 to define a PBKDF2-based = mechanism. --- Mike Ounsworth Software Security Architect, Entrust -----Original Message----- From: Spasm On Behalf Of Brockhaus, Hendrik Sent: December 4, 2020 12:11 PM To: Mike Ounsworth ; 'LAMPS'= Subject: [EXTERNAL]Re: [lamps] CMP and PBKDF2-MAC (use RFC 8018's PBMAC1?) WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the = content is safe. Mike > Von: Spasm Im Auftrag von Mike Ounsworth >=20 > RFC 4210 (CMP) allows for shared secret (MAC) protection of the message. > Section 5.1.3.1 specifies the use of id-PasswordBasedMac which is=20 > defined in section 4.4 of RFC 4211. This algorithm looks a lot like=20 > PBKDF1 with a round of MAC at the end. >=20 > Question1: We are not seeing a RFC 4210 (CMP) update that provides a=20 > PBKDF2-based MAC. Is that correct or have we missed something? As the password-based MAC is identified by an OID, we are free to specify a= n alternative to id-PasswordBasedMac in draft-ietf-lamps-cmp-algorithms. >=20 > RFC 8018 defines PBMAC1 using PBKDF2 and a MAC of your choice. Looks=20 > great! >=20 > Question2: Are you aware of any CMP implementations that have=20 > implemented PBKDF2-MAC, and did they use RFC 8018's PBMAC1 to do it,=20 > or some other AlgorithmIdentifier? No I am not aware of any implementation using something other than id-Passw= ordBasedMac. - Hendrik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Dec 7 23:44:00 2020 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 3E78D3A0D89 for ; Mon, 7 Dec 2020 23:43:58 -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_MSPIKE_H2=-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=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 290IZWD7V0qo for ; Mon, 7 Dec 2020 23:43:56 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10064.outbound.protection.outlook.com [40.107.1.64]) (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 3C4A23A0D88 for ; Mon, 7 Dec 2020 23:43:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ReoayFPB3LaidUesPDBj0HyW39tpObLdx4r06R+p4T513TqOvrt0/Gi+6ZiD9QqYGzilKa4JXCeLeUB/QdWFUcOESbIqKscaV2KqtPYQt1qBZClKmKOATBoreN42Pu+Ma0I9AOPpdWwSqZzHilet0Axk6bfpQsNH1mQ18sXeMrb+V6He1wnr8djX2RRpdtC5FMwq28Unf09pHQZhxo5ZeMkTI1Z/OCBBvtJv58xH1qruZ1dz6pVzwO/J8kWNdVXAgU1AG7biRWhpjWJtwY08J0gQMSD2HcXBTRbp3x8vSWSQi2eSW2CsCQZ24nOrfSCB0bYSxXG4UtNVg7W90WMoig== 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=hgTDlaSd03gvVFhjTB63M+q8cdMcrk2uHdlirDDI9KU=; b=YVQBGQI35ILKTSzSUJRk2pAvC7h9HnTZJKittYVOlAB8MJwN8+GV8kC1o+adKy8X9Qo6EfbdWFlNEcsu4EjObU8wjFNJThKPTykVhY33q7hcmLV9li7nR/7Y+OG7Khm3P3LQhSgweFI61ijUWj82Zu2WQW6fiXSsRVFkfLWxy2PUxVMX9qx5+oNfWe/PSyBkQN1JAlH/dWbehQqKGx3F48CAdFSB9MLKqMTR8IzoMXNqMBktC0W9KqsDd+XGpqJ9wyF5qdZk8o/CgQ8DOicwuV5TFvBc8I2gQ3dNTGBiz2Xf+grfYkLaegOTpZpfu8q+74IUUW3M3GW+4IvJ9T+uOQ== 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=hgTDlaSd03gvVFhjTB63M+q8cdMcrk2uHdlirDDI9KU=; b=cWJa5UTbxgGvx8KON0WUY0nySziu3Sz6jlUpFSA8hdQ65NO2wrOq0Nwm+olsXqaMpyOkcFxeJVXnuKKOx3aVjvU5GNbrVHi+ETIfNd4gMeWG0hkjscR4f8U1GjsMlue8950XbtTR1+QpZq+fRr7U74NM5kgyTlr7TicGGeFVjuw= Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM0PR10MB2979.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:15e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.20; Tue, 8 Dec 2020 07:43:53 +0000 Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69%6]) with mapi id 15.20.3632.023; Tue, 8 Dec 2020 07:43:53 +0000 From: "Brockhaus, Hendrik" To: Mike Ounsworth CC: "hans.aschauer@siemens.com" , 'LAMPS' Thread-Topic: CMP and PBKDF2-MAC (use RFC 8018's PBMAC1?) Thread-Index: AdbJ0P8rWe8VkkwJQiygQBWyNOJifQAl0vqAAKBLTEAAEuPgEA== Date: Tue, 8 Dec 2020 07:43:52 +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: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-12-08T07:43:51Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=5d705b44-1e79-4d96-a968-e258123fa4db; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: entrust.com; dkim=none (message not signed) header.d=none;entrust.com; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.170] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e98a0469-e7c5-49b9-2aaf-08d89b4d0289 x-ms-traffictypediagnostic: AM0PR10MB2979: x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5yFNgRK2bfYs79XeujEtcpVtpc+HPLa+CKU+n0DXNQfEaon+WluZpcsSOmfVv/AkoEASjVRLyxqPRWbodpmDI1I7Gnk2XgX3Pfq5AoFjLnUzrjXDNf1Tp6Ay2FV68YnF4LqblH2Jhq6NOnWjlXT2mwozGxTw+V5N7yScEMDyqiP2IUccKESgXwSXxRFPxcopZIygXnFetIkA5HVjbmDTNtcOvPeD/oJ+n7VUsh4sfYCuv2Yv+n3u7Pw7fRrQ1fmn+3DdBub4wLxr9+4atytT7YScF+gGREXRfLvWuxL+sjyeNL8x4GUdB1LwMwkUu02Yyh9Y8rvaTMew4lxFABEffICGJmfKwo76AnUFeNsVEBgZaVuwUpJJudlzXlHczjScwPCPpxdR5/Qyxxcixv5ErA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(376002)(346002)(8676002)(66946007)(54906003)(83380400001)(66446008)(6916009)(76116006)(66476007)(55016002)(8936002)(45080400002)(64756008)(26005)(66556008)(55236004)(508600001)(33656002)(52536014)(5660300002)(966005)(7696005)(186003)(9686003)(66574015)(2906002)(71200400001)(86362001)(53546011)(6506007)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?b/FtvmPID0kLtI2/MYvGdkKB+VrUdTo/74pjAn6Xdxuu52Sw/W4NRmp2jp?= =?iso-8859-1?Q?fx7AOO+gcHesaRvNlAsYFCQp2tyHoxVULlUtmYDBVx5DdvkjEL9xkKvoxB?= =?iso-8859-1?Q?IBfpQJJoO/kuzAfTvBNPWLsXvc/31pfgcayXfGYIdQb2dY66jVtzQQSrOG?= =?iso-8859-1?Q?lSmk86a/vLA5TwCnuHoSWDLeK22apUZ9yIPt+gE0biMmFrGvgUbvPqXmDO?= =?iso-8859-1?Q?QV7nt+lHfbgRxxv3THb4scMdLV/eiHS0cdO9kxK4KF0MatrG4NrgVt3A7K?= =?iso-8859-1?Q?bs6dKjRPV6YgrVkJl/5sXYSEnsLxj5GygtglNaVXSxl9LpkndM81J4rDZr?= =?iso-8859-1?Q?VtH4Eu+Q+w1l+HsKWM9jxsMMKDkIzhssnVUAmoD9iuJIW30mtD2fQwyMoz?= =?iso-8859-1?Q?HBEuO9t0QG6fZySQY+o388+nKapOIa7YWVnWS9tQHXtiJAd2IIUnp/rAzQ?= =?iso-8859-1?Q?Y0a7Y5wrop+1NH68zGy05BoC7wP8jGOGB3DH1S+RfC6A/JtgEDGsOLlPcI?= =?iso-8859-1?Q?uBxJe2DTm/jCpFA97qDAvy59t4+L13SFWg0tbNZhooO0lVVDGyR4x+VDGr?= =?iso-8859-1?Q?C38RZmhPGFQxtOk9lyIXPQ8pq6fKxJW52CPnVcvn3+XOUsprKEEOXTYH1s?= =?iso-8859-1?Q?IBu3xF6VcHRaNsilDRmQns1aQWOo54mHx3gKNUQ/ZtNsldAozDIi/TOlSw?= =?iso-8859-1?Q?saIvuGF9PP1nq8TNGqdrFt9jdo7L7OPU0QGpUq+lNgWl+HIEL/xWn5wul2?= =?iso-8859-1?Q?1ZA0i8nRGO5P1SBC9/wYLrs49U8sUcDbZ8VPsjOkrNcP/YjkG20vZYU9M7?= =?iso-8859-1?Q?/FywfHfEvwZdeKNYaBCjGJk2h9xDeFOiZEJf0gkwkND129qvwTHiJYLuf1?= =?iso-8859-1?Q?UYcak01rsKTDVMGnFftvdwiKF2QU7UpKAv4DMb8KDF/A8NiYlRlsLfTOil?= =?iso-8859-1?Q?j1MSkObKPY3lQjs+2gYAUykkaUyvQerNYSdlmy6H6Yr0NxwtJKgMcRdFur?= =?iso-8859-1?Q?eL5H1Md3F3KWrN8eYujnxLFSE/hUBdkk5FdD6k?= 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: e98a0469-e7c5-49b9-2aaf-08d89b4d0289 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2020 07:43:52.9786 (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: XrGWcsBVHZjkZaEIxRajIthanuXNHoi0QSBVow+xm7twpbX6K3ZkutmRf1rRBTkAERgS47PLIUfRvwgDyNp8MySHv9qeZgeJsNInBD8rltg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2979 Archived-At: Subject: Re: [lamps] CMP and PBKDF2-MAC (use RFC 8018's PBMAC1?) 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, 08 Dec 2020 07:43:58 -0000 Hi Mike Together with a colleague of mine, Hans Aschauer, I am working on an update= of the draft addressing the feedback from IETF109. If you are interested in support of alternatives to id-PasswordBasedMac in = Section 6.1, you are welcome to join in. I would anyhow be happy to have sparing's partner for this draft as I am no= t an expert on all of the different algorithm variants out there :-) Hendrik > -----Urspr=FCngliche Nachricht----- > Von: Mike Ounsworth > Gesendet: Montag, 7. Dezember 2020 23:39 > An: Brockhaus, Hendrik (T RDA CST SEA-DE) > ; 'LAMPS' > Betreff: RE: CMP and PBKDF2-MAC (use RFC 8018's PBMAC1?) >=20 > Hi Hendrik, >=20 > Are you interested in collaborators on draft-ietf-lamps-cmp-algorithms-01= ? > We would love to help you update your section 6.1 to define a PBKDF2-base= d > mechanism. >=20 > --- > Mike Ounsworth > Software Security Architect, Entrust >=20 > -----Original Message----- > From: Spasm On Behalf Of Brockhaus, Hendrik > Sent: December 4, 2020 12:11 PM > To: Mike Ounsworth ; > 'LAMPS' > Subject: [EXTERNAL]Re: [lamps] CMP and PBKDF2-MAC (use RFC 8018's > PBMAC1?) >=20 > WARNING: This email originated outside of Entrust. > DO NOT CLICK links or attachments unless you trust the sender and know th= e > content is safe. >=20 > Mike >=20 > > Von: Spasm Im Auftrag von Mike Ounsworth > > > > RFC 4210 (CMP) allows for shared secret (MAC) protection of the message= . > > Section 5.1.3.1 specifies the use of id-PasswordBasedMac which is > > defined in section 4.4 of RFC 4211. This algorithm looks a lot like > > PBKDF1 with a round of MAC at the end. > > > > Question1: We are not seeing a RFC 4210 (CMP) update that provides a > > PBKDF2-based MAC. Is that correct or have we missed something? >=20 > As the password-based MAC is identified by an OID, we are free to specify= an > alternative to id-PasswordBasedMac in draft-ietf-lamps-cmp-algorithms. >=20 > > > > RFC 8018 defines PBMAC1 using PBKDF2 and a MAC of your choice. Looks > > great! > > > > Question2: Are you aware of any CMP implementations that have > > implemented PBKDF2-MAC, and did they use RFC 8018's PBMAC1 to do it, > > or some other AlgorithmIdentifier? >=20 > No I am not aware of any implementation using something other than id- > PasswordBasedMac. >=20 > - Hendrik >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww > .ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D04%7C01%7Chendrik. > brockhaus%40siemens.com%7C4c85776a7bca4699af5108d89b00f708%7C38a > e3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637429775762026495%7CU > nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI > 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DGpRhv3oCupCoS%2BnG1 > b0VveVjWDptdWJwcPwr%2Fz5Cc5I%3D&reserved=3D0 From nobody Tue Dec 8 08:23:17 2020 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 06BCD3A1115; Tue, 8 Dec 2020 08:23:10 -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, rdd@cert.org, housley@vigilsec.com X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160744458993.10582.13404596656197810982@ietfa.amsl.com> Date: Tue, 08 Dec 2020 08:23:09 -0800 Archived-At: Subject: [lamps] lamps - New Meeting Session Request for IETF 110 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 16:23:15 -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 suit stir Technology Overlap: acme cfrg Key Participant Conflict: oauth secdispatch saag sipbrandy tls mls teep emu People who must be present: Russ Housley Rich Salz Sean Turner Alexey Melnikov Michael Richardson Roman Danyliw Bernie Hoeneisen Tim Hollebeek Hendrik Brockhaus Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Dec 8 09:49:45 2020 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 9F3AA3A1065 for ; Tue, 8 Dec 2020 09:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, 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=isode.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 Uwg55MdMZJYl for ; Tue, 8 Dec 2020 09:49:41 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id A77093A1068 for ; Tue, 8 Dec 2020 09:49:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1607449780; d=isode.com; s=june2016; i=@isode.com; bh=YF9iVvH+Wsd99EsoyUT0gIyC6i1deAgKEoE/ugqWk6A=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Z0zI2+fEqBBvX/zHo2COdzlrRb/G1gFPhJ5rBeqCNP77AcyLEJKxkOvkksSUNhdL5b0pXJ 1MW4Ltj0qQz/zDFt8XYpSerIWdGlrf8adykKeYVjb5BKo5KmJDNwle/t4IXHdTDTH0JEQE jZ1soDd7joYjlmxL0Mdnss6hyUM29Eo=; Received: from [172.27.249.243] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 8 Dec 2020 17:49:40 +0000 To: Metin Savignano , spasm@ietf.org References: <5F4E87EE-4CD1-4A9F-BDE2-82AD8FD6EFB1@savignano.net> From: Alexey Melnikov Message-ID: <017ca985-ac25-b318-c259-24b08344bd0e@isode.com> Date: Tue, 8 Dec 2020 17:48:39 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------8266CCBAD88EB7E61514F139" Content-Language: en-GB Archived-At: Subject: Re: [lamps] Fwd: Possible inconsistencies or ambiguities in RFC 8551 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, 08 Dec 2020 17:49:44 -0000 --------------8266CCBAD88EB7E61514F139 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Metin, I am not an author/editor of RFC 8551, but I will reply with my opinions=20 in order to stimulate some discussion of issues that you've raised. On 07/12/2020 09:06, Metin Savignano wrote: > Hi, > > referring to my email quoted below of 7th August, may I ask if and how=20 > I would get a reply? I haven=E2=80=99t seen one, and I am wondering if I w= ould=20 > have to look at some other place? > > Thanks > Metin > > >> Anfang der weitergeleiteten Nachricht: >> >> *Von: *Metin Savignano > >> *Betreff: **Possible inconsistencies or ambiguities in RFC 8551* >> *Datum: *7. August 2020 um 13:01:53 MESZ >> *An: *spasm@ietf.org >> >> Dear authors, >> >> First of all, thank you very much for your work to create a new and=20 >> better version of S/MIME! >> >> As an author of an S/MIME app, we are working through RFC 8551 to=20 >> determine the changes we have to implement in order to fully comply=20 >> to the S/MIME 4.0 specs. >> >> However, I=E2=80=99ve come to a point where I seem unable to understand w= hat=20 >> the RFC actually recommends with regard to the backward=20 >> compatibility. I=E2=80=99ve also discussed this with another software=20 >> developer, but we both weren=E2=80=99t sure how to read it. It would be= =20 >> awesome if you could help me with a clarification. >> >> In the relevant scenario, the sending agent wants to send encrypted=20 >> email to a recipient with unknown capabilities. >> >> With regard to backward compatibility, RFC 8551 states in section 1.4: >> >> S/MIME version 4.0 agents ought to attempt to have the greatest >> interoperability possible with agents for prior versions of S/MIME. >> >> Although this is a very general statement, I believe it is=20 >> contradictory to the description about how to decide which content=20 >> encryption cipher to use in section 2.7.1.2: >> >> If the following two conditions are met, the sending agent SHOULD use >> AES-256 GCM, as AES-256 GCM is a stronger algorithm and is required >> by S/MIME v4.0: >> - The sending agent has no knowledge of the encryption capabilities >> of the recipient. >> >> - The sending agent has no knowledge of the version of S/MIME used >> or supported by the recipient. >> I don=E2=80=99t understand why we should choose AES-256-GCM if we don=E2= =80=99t know=20 >> about the recipients capabilities and S/MIME version. I agree with you that text from Sections 1.4 and 2.7.1.2 is contradictory. >> For example, if the recipient uses an S/MIME 3.2 compliant software,=20 >> as I understand RFC 5751, that software need not know about=20 >> AES-256-GCM. The GCM block mode is not even mentioned in earlier=20 >> S/MIME versions. As a consequence, doesn=E2=80=99t the selection of=20 >> AES-256-GCM contradict the=C2=A0"attempt to have the=20 >> greatest=C2=A0interoperability possible with agents for prior versions of= =20 >> S/MIME=E2=80=9C? Yes, there is contradiction in the RFC as written. I think some implementations would value interoperability with earlier=20 versions of S/MIME higher than security and others would choose the=20 opposite. Text in 2.7.1.2 seems to be written with the latter case in mind. For new implementations or implementations more concerned with security,=20 using more modern crypto algorithms can be a good default. >> The common capability in both S/MIME versions would be AES-128-CBC,=20 >> wouldn=E2=80=99t it? >> Also, I do not really understand the following sentence: >> If the sending agent chooses not to use AES-256 GCM in this step, >> given the presumption is that a client implementing AES-GCM would do >> both AES-256 and AES-128, it SHOULD use AES-128 CBC. >> It appears to me as if this sentence was grammatically either wrong=20 >> or uses a construct that I don=E2=80=99t understand (I=E2=80=99m not a na= tive speaker). You are right, the above seems wrong. I think "is" needs to be dropped=20 after "presumption". >> I don=E2=80=99t understand what "given the presumption is that a client= =20 >> implementing AES-GCM would do both AES-256 and AES-128=E2=80=9C =C2=A0is = meant to=20 >> tell me in that context. Also, I=E2=80=99m not sure if the word =E2=80=9E= client=E2=80=9C is=20 >> meant to refer to the sending or receiving client. At first, I=20 >> thought it=E2=80=99s the receiving client, but after re-reading a few tim= es,=20 >> I=E2=80=99m unsure if it=E2=80=99s the sending agent, because I don=E2=80= =99t understand why=20 >> I should make presumptions about the receiving client implementing=20 >> AES-GCM when I don=E2=80=99t know anything about it. I think the text is trying to say that as the client supports AES, it is=20 likely to support AES-128 CBC. >> >> I would recommend that this sentence maybe rephrase to make it more=20 >> understandable for non-native speakers. >> >> What I would have expected in section 2.7.1.2: >> >> To maintain "greatest=C2=A0interoperability possible with agents for prio= r=20 >> versions of S/MIME=E2=80=9C, the RFC would select AES-128-CBC if the=20 >> recipient=E2=80=99s capabilities /and/ S/MIME version aren=E2=80=99t know= n. >> >> Where am I off the track? >> >> >> Thanks a lot! >> >> Metin Savignano Best Regards, Alexey --------------8266CCBAD88EB7E61514F139 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi Metin,

I am not an author/editor of RFC 8551, but I will reply with my opinions in order to stimulate some discussion of issues that you've raised.

On 07/12/2020 09:06, Metin Savignano wrote:

Hi,

referring to my email quoted below of 7th August, may I ask if and how I would get a reply? I haven=E2=80=99t seen one= , and I am wondering if I would have to look at some other place?

Thanks
Metin


Anfang der weitergeleiteten Nachricht:

Von: Metin Savignano <ms@savignano.net>
Betreff: Possible inconsistencies or ambiguities in RFC 8551
Datum: 7. August 2020 um 13:01:53 MESZ
An: spasm@ietf.org

Dear authors,

First of all, thank you very much for your work to create a new and better version of S/MIME!=C2=A0

As an author of an S/MIME app, we are working through RFC 8551 to determine the changes we have to implement in order to fully comply to the S/MIME 4.0 specs.

However, I=E2=80=99ve come to a point wher= e I seem unable to understand what the RFC actually recommends with regard to the backward compatibility. I=E2=80=99ve also discussed this with ano= ther software developer, but we both weren=E2=80=99t sure how= to read it. It would be awesome if you could help me with a clarification.

In the relevant scenario, the sending agent wants to send encrypted email to a recipient with unknown capabilities.

With regard to backward compatibility, RFC 8551 states in section 1.4:

   S/MIME=
 version 4.0 agents ought to attempt to have the greatest
   interoperability possible with agents for prior versions of S/MIME.

Although this is a very general statement, I believe it is contradictory to the description about how to decide which content encryption cipher to use in section 2.7.1.2:

   If the=
 following two conditions are met, the sending agent SHOULD use
   AES-256 GCM, as AES-256 GCM is a stronger algorithm and is required
   by S/MIME v4.0:
   -  The=
 sending agent has no knowledge of the encryption capabilities
      of the recipient.

   -  The sending agent has no knowledge of the version of S/MIME used
      or supported by the recipient.

                    
I don=E2=80=99t un=
derstand why we should choose AES-256-GCM if we don=E2=80=99t know about the=
 recipients capabilities and S/MIME version.=20


                  

                

              

            

          

        

      

    

    
I agree with you that text from Sections 1.4 and 2.7.1.2 is
      contradictory.

    

    

      

        

          

            

              

                

                  

                    
For example, if th=
e recipient uses an S/MIME 3.2 compliant software, as I understand RFC 5751,=
 that software need not know about AES-256-GCM. The GCM block mode is not ev=
en mentioned in earlier S/MIME versions.=C2=A0

As a consequence, doesn=E2=80=99t the selection of AES-256-GCM contradict th=
e=C2=A0"attempt to have the greatest=C2=A0interoperability possible with age=
nts for prior versions of S/MIME=E2=80=9C?=20


                  

                

              

            

          

        

      

    

    
Yes, there is contradiction in the RFC as
        written.

    
I think some implementations would value
        interoperability with earlier versions of S/MIME higher than
        security and others would choose the opposite. Text in 2.7.1.2
        seems to be written with the latter case in mind.

    
For new implementations or implementations
        more concerned with security, using more modern crypto
        algorithms can be a good default.

      

    

      

        

          

            

              

                

                  

                    


The common capability in both S/MIME version=
s would be AES-128-CBC, wouldn=E2=80=99t it?




Also, I do not really understand=
 the following sentence:

                    



                    
   If the sending agent chooses not to use=
 AES-256 GCM in this step,
   given the presumption is that a client implementing AES-GCM would do
   both AES-256 and AES-128, it SHOULD use AES-128 CBC.


                    

                  

                  
It appears to me as if this sentence was
                    grammatically either wrong or uses a construct that
                    I don=E2=80=99t understand (I=E2=80=99m not a native spe=
aker).

                

              

            

          

        

      

    

    You are right, the above seems wrong. I think "is" needs to be
    dropped after "presumption".

    

      

        

          

            

              

                

                  
 I don=E2=80=99t understand what "given th=
e
                    presumption is that a client implementing AES-GCM
                    would do both AES-256 and AES-128=E2=80=9C =C2=A0is mean=
t to tell
                    me in that context. Also, I=E2=80=99m not sure if the wo=
rd
                    =E2=80=9Eclient=E2=80=9C is meant to refer to the sendin=
g or
                    receiving client. At first, I thought it=E2=80=99s the
                    receiving client, but after re-reading a few times,
                    I=E2=80=99m unsure if it=E2=80=99s the sending agent, be=
cause I
                    don=E2=80=99t understand why I should make presumptions
                    about the receiving client implementing AES-GCM when
                    I don=E2=80=99t know anything about it.

                

              

            

          

        

      

    

    I think the text is trying to say that as the client supports AES,
    it is likely to support AES-128 CBC.

    

      

        

          

            

              

                

                  


                  

                  
I would recommend that this sentence
                    maybe rephrase to make it more understandable for
                    non-native speakers.

                  


                  

                  
What I would have expected in section
                    2.7.1.2:

                  


                  

                  
To maintain "greatest=C2=A0interoperabilit=
y
                    possible with agents for prior versions of S/MIME=E2=80=
=9C,
                    the RFC would select AES-128-CBC if the recipient=E2=80=
=99s
                    capabilities and S/MIME version
                    aren=E2=80=99t known.

                  


                  

                  
Where am I off the track?

                  


                  

                  


                  

                  
Thanks a lot!

                  


                  

                  
Metin Savignano

                

              

            

          

        

      

    

    
Best Regards,

    
Alexey

    


    

  


--------------8266CCBAD88EB7E61514F139--


From nobody Wed Dec  9 06:18:09 2020
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 0B6B73A0D43 for ; Wed,  9 Dec 2020 06:18:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level: 
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, 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 etd6Sj0-jPv2 for ; Wed,  9 Dec 2020 06:18:05 -0800 (PST)
Received: from welho-filter1.welho.com (welho-filter1b.welho.com [83.102.41.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8293A0D44 for ; Wed,  9 Dec 2020 06:18:04 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id CB8FE21C56; Wed,  9 Dec 2020 16:18:02 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id hrtVGHWERhfI; Wed,  9 Dec 2020 16:18:01 +0200 (EET)
Received: from LK-Perkele-VII (78-27-99-170.bb.dnainternet.fi [78.27.99.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 5C30A292; Wed,  9 Dec 2020 16:17:59 +0200 (EET)
Date: Wed, 9 Dec 2020 16:17:58 +0200
From: Ilari Liusvaara 
To: "Brockhaus, Hendrik" 
Cc: LAMPS 
Message-ID: 
References:   
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [lamps] supporting ECDSA25519, i.e., ECDSA/SHA256 with Curve25519 under the hood (was: Re: LAMPS Minutes for IETF 109)
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, 09 Dec 2020 14:18:07 -0000

On Thu, Dec 03, 2020 at 06:14:56PM +0000, Brockhaus, Hendrik wrote:
> Thanks to Tomas for his feedback and insight into HW support and PKCS#11.
> 
> > Von: Spasm  Im Auftrag von Rene Struik
> > Gesendet: Donnerstag, 26. November 2020 21:58
> >
> > Dear colleagues:
> >
> > Do you think supporting ECDSA25519 would make sense as well? 
> > 
> > This is well-defined and non-deterministic and also can use existing
> > Curve25519 ladders under the hood (see [1]) as well as existing
> > generic hardware supporting short-Weierstrass curves (see [2]).

1) It is not well defined enough for common sign/verify APIs that take
message hash. This is because it triggers special case inside ECDSA
that makes signature dependent on bit order of the hash function. SHA-2
defines it one way, SHAKE defines it the other, and other hash functions
may not define it at all.

2) Deterministic/noisy/non-deterministic is only about specification and
implementation, it is not about interoperability.

3) It is not trivial to use existing Curve25519 ladders for verification,
because those do not produce indication if the two products are same- or
opposite-sign. The cheap trick used by qDSA to check both at once does
not obviously work because of mod n at output.

> > Due to the PKIX/CMS OID requested during IETF Last-Call on lwig-curve
> > draft [3], it seems this could just be used without further ado.
> 
> Does anyone from LAMPS reviewed the draft and has an opinion on the
> work? 

My opinion is that ECDSA25519, ECDSA448, ECDH25519 and ECDH448 try to
shoehorn Curve25519 and Curve448 to obsolete constructions (nevermind
that those constructions obsolete even more obsolete constructions)
that mostly negate the simplicity advantages. And in case ECDSA, hit
a nasty edge case.

And if one wants complete arithmetic, one needs to transform all the
way to Edwards domain. Not an issue with Curve25519, since mapping
between montgomery and edwards forms is isomorphism, but for Curve448,
it is not, so this needs some extra thought. And then there are the
"-3" variants, which seem to involve mapping that is not isomorphism.


Now, EdDSA does have its problems. Mainly the fixed hash functions
causing issues with constrained environments, where one wants to use
single hash (which is most probably SHA-256) for everything. Since if
one wants to use Curve25519 with SHA-256 one needs a new signature
algorithm, one could define one that is simple.


-Ilari


From nobody Wed Dec  9 06:24:27 2020
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 AEB813A16AC for ; Wed,  9 Dec 2020 06:24:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level: 
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=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 Q9B3sGnIcbgC for ; Wed,  9 Dec 2020 06:24:17 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4b.welho.com [83.102.41.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F0443A16FC for ; Wed,  9 Dec 2020 06:24:16 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 3F8096885E for ; Wed,  9 Dec 2020 16:24:14 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id vSxlhoe1oMMW for ; Wed,  9 Dec 2020 16:24:14 +0200 (EET)
Received: from LK-Perkele-VII (78-27-99-170.bb.dnainternet.fi [78.27.99.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 044017A for ; Wed,  9 Dec 2020 16:24:12 +0200 (EET)
Date: Wed, 9 Dec 2020 16:24:12 +0200
From: Ilari Liusvaara 
To: IETF Lamps WG 
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: [lamps] Question about RFC8692 (SHAKE with RSA-PSS and ECDSA)
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, 09 Dec 2020 14:24:26 -0000

I am trying to implement RFC 8692, and hit a part I do not understand.

Specifically, the following part of section 4.2 (Public Keys):

> Conforming CA implementations MUST specify the X.509 public key
> algorithm explicitly by using the OIDs specified in Section 3 when
> encoding ECDSA with SHAKE public keys in certificates and CRLs.
> Conforming client implementations that process ECDSA with SHAKE
> public keys when processing certificates and CRLs MUST recognize the
> corresponding OIDs.
>
> The identifier parameters, as explained in Section 3, MUST be absent.

This seems to discuss algorithm identifier for ECDSA public keys
restricted to SHAKE128 or SHAKE256, and specifies that there are
no algorithm identifier parameters in public keys.

Normally, when using generic ECC keys, the curve used is encoded
as algorithm identifier parameter of public key. If multiple curves
of almost the same size are supported (e.g., there are multiple 
standard 256-bit curves), guessing the curve from encoding is
nontrivial at best, impossible at worst[1].

Now, since these restricted ECDSA keys seemingly do not have
similar curve identifiers, how is the curve used stored (Signature
identifiers do not specify that either)?


[1] E.g., compressed point with x=floor(10^76*pi)+4 is valid for the
256-bit NIST, Brainpool and ANSSI curves, plus the bitcoin curve.


-Ilari


From nobody Wed Dec  9 06:55:34 2020
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 EC8C13A0DBD for ; Wed,  9 Dec 2020 06:55:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 CW13mbDtOT2S for ; Wed,  9 Dec 2020 06:55:28 -0800 (PST)
Received: from smtp.outgoing.loopia.se (smtp.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 6E6B23A0DD6 for ; Wed,  9 Dec 2020 06:55:27 -0800 (PST)
Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id 851C6246305C for ; Wed,  9 Dec 2020 15:55:21 +0100 (CET)
Received: from s630.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with ESMTP id 66B262E68BFF; Wed,  9 Dec 2020 15:55:21 +0100 (CET)
Received: from s474.loopia.se (unknown [172.22.191.6]) by s630.loopia.se (Postfix) with ESMTP id 550EC13ADD3B; Wed,  9 Dec 2020 15:55:21 +0100 (CET)
X-Virus-Scanned: amavisd-new at amavis.loopia.se
Received: from s498.loopia.se ([172.22.191.6]) by s474.loopia.se (s474.loopia.se [172.22.190.14]) (amavisd-new, port 10024) with LMTP id DnmBDopAqMhx; Wed,  9 Dec 2020 15:55:20 +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.1.218] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: mailstore2@aaa-sec.com) by s498.loopia.se (Postfix) with ESMTPSA id AA48048937A; Wed,  9 Dec 2020 15:55:20 +0100 (CET)
User-Agent: Microsoft-MacOutlook/16.43.20110804
Date: Wed, 09 Dec 2020 15:55:19 +0100
From: Stefan Santesson 
To: LAMPS 
CC: Russ Housley 
Message-ID: <9128D489-AE1C-447B-BDFE-665739821659@aaa-sec.com>
Thread-Topic: Invitation to work on standards for signature validation tokens (SVT)
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: 
Subject: [lamps] Invitation to work on standards for signature validation tokens (SVT)
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, 09 Dec 2020 14:55:31 -0000

Hi,

I presented the work on signature validation tokens at the SecDispatch group at IETF 109.
The first set of internet drafts have been authored by me and Russ before this meeting.

We have since then got our mailing list setup within the IETF (svt@ietf.org)
I would like to invite anyone with interest in this area to join the mailing list and take part in the discussion whether to develop these specifications within the IETF.

If you want a quick introduction to this I made a short presentation video available here: https://www.youtube.com/watch?v=IEJBmHJklHY

Other resources are listed below:

Current drafts:
  https://datatracker.ietf.org/doc/draft-santesson-svt/
  https://datatracker.ietf.org/doc/draft-santesson-svt-pdf/
  https://datatracker.ietf.org/doc/draft-santesson-svt-xml/

IETF Draft development
  https://github.com/swedenconnect/IETF-SVT

IETF Mailing list (svt@ietf.org)
  General information about the mailing list is at: https://www.ietf.org/mailman/listinfo/svt

Open Source
  Basic SVT library: 
    https://github.com/idsec-solutions/sig-validation-svt
  Basic library for issuing SVT and signature validation with SVT (Java):
    https://github.com/idsec-solutions/sig-validation-base

Test SVT issuing validation service
  https://sandbox.swedenconnect.se/sigval/


Stefan Santesson 



From nobody Wed Dec  9 07:22:39 2020
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 3FC793A0E02 for ; Wed,  9 Dec 2020 07:22:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeLNUM8q_gTU for ; Wed,  9 Dec 2020 07:22:35 -0800 (PST)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 2D4B73A0E98 for ; Wed,  9 Dec 2020 07:22:33 -0800 (PST)
Received: by mail-qk1-x734.google.com with SMTP id 19so1513070qkm.8 for ; Wed, 09 Dec 2020 07:22:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=to:cc:references:from:subject:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=UJPl/ECCwMx4rjqMjYGHlaHKF5fihrJ+OOLdDGy9SgY=; b=YbeMLZ1nAGegF/G9gPj/QVRnsmb0h7NPskAhIEU/87BBZ94uAqPcIHEmCCzqpNKuOX 8EnCAs9Ss+6TWMulK+XY3OAmYpG2sBxVMbqQy61uAF1foHPEBssKegR271xeF9TBGxat v+LE9MoTnZxt2t3j7N6kH4/rnqJybQV/kfo01Tbi29CvSdCiE6Rofy0XXfObuZn/4xgD BNYtDW0awPffPg7JE2KQAdG9qwTY1Euw6N2aD+CcrtyxFhlr1pEDzsQfNRgF1RG61Rk6 PgsA60GDzB6f+Ab4IqVZrCJT+lqdZkTRcZydXDWe9kFKpj2JbevvgFDqyOnWfrV4bRte oP8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=UJPl/ECCwMx4rjqMjYGHlaHKF5fihrJ+OOLdDGy9SgY=; b=ZMRlFsiA3FbJmOrRpcn5v580/B2WZ5J5iG2SWl9AuQ4KLOcCDiDaR/bUv8w9fMpFga sFPGJnLA8NrKpf1A+N36XA9fWHwBw5ObxEusZf+ohXmyfcrVojK7S545Z9hkA4mQlskQ UO5TMXrtjJMTIf/zTi+w2Htoe5iMd66kYSmtAAT3uH4a3DVZSDmc36MiqlBvVWfoStM+ 62bG76scJ/XyTxsN/fMZRuW/NzNt8U72cvwcqG8GRNQ+s0BnfTdPFov/ReWzRJw3yiSm lzECY2cMYKqcQvrPhVq7yZCjWtseGzIpNmAyLQnqgB7nTtgEGIN9PSO+jDSBPwO6LZcd W0gw==
X-Gm-Message-State: AOAM530ewdaI9Kewym1znzy68jOPNtKfm71PCSrzPz4aKNOsvJuLumPm qq2cHFKvFdZV77K5NQUgDkXTIy7AnUA=
X-Google-Smtp-Source: ABdhPJyuIVuQ6Ik8LOmdPvI8grhCjzSdAPxTjEC1wbhAo92DMsABnZrhezZoMPP98r0iI4snq/WLtA==
X-Received: by 2002:a05:620a:13a6:: with SMTP id m6mr3343026qki.319.1607527351807;  Wed, 09 Dec 2020 07:22:31 -0800 (PST)
Received: from ?IPv6:2607:fea8:8a0:1397:a11e:9993:894b:7bd2? ([2607:fea8:8a0:1397:a11e:9993:894b:7bd2]) by smtp.gmail.com with ESMTPSA id u15sm1173800qkj.122.2020.12.09.07.22.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Dec 2020 07:22:30 -0800 (PST)
To: Ilari Liusvaara , "Brockhaus, Hendrik" 
Cc: LAMPS 
References:    
From: Rene Struik 
Message-ID: 
Date: Wed, 9 Dec 2020 10:22:28 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: 
Subject: Re: [lamps] supporting ECDSA25519, i.e., ECDSA/SHA256 with Curve25519 under the hood (was: Re: LAMPS Minutes for IETF 109)
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, 09 Dec 2020 15:22:37 -0000

Hi Ilari:

I am somewhat puzzled by your claims, since - if true - seem to suggest=20
ECDSA (which has been used in practice almost two decades by now and is=20
virtually ubiquitous) is not well-defined.

If anything in the specification of ECDSA25519 [1] or ECDSA448 is=20
unclear, please indicate how this could be improved and I will take your =

advice at heart.

Curve448, Ed448, and Wei448 are isomorphic (see [3]).

I do agree with you that the security posture of EdDSA schemes can be=20
improved, so as to remove trivial single-shot implementation attacks,=20
but that is out of scope for discussion of ECDSA as defined in [1] and=20
[2]. What about you fix RFC 8032 (you are one of the authors)?

Best regards, Rene


Ref:
[1]=20
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representatio=
ns-15#section-4.3
ECDSA25519 =3DECDSA with SHA256 and the short-Weierstrass curve Wei25519 =

(isomorphic to Curve25519)
[2]=20
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representatio=
ns-15#section-4.4
ECDSA448 =3D ECDSA with SHAKE256 with output-size d=3D512 bit (as also=20
specified in RFC 8692) and the short-Weierstrass curve Wei448=20
(isomorphic to Curve448)
[3]=20
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representatio=
ns-15#appendix-M
This section provides full details of isomorphic mappings between=20
Curve448 (Montgomery curve), Ed448 (twisted Edwards curve with complete=20
addition laws), and Wei448 (short-Weierstrass version)


On 2020-12-09 9:17 a.m., Ilari Liusvaara wrote:
> On Thu, Dec 03, 2020 at 06:14:56PM +0000, Brockhaus, Hendrik wrote:
>> Thanks to Tomas for his feedback and insight into HW support and PKCS#=
11.
>>
>>> Von: Spasm  Im Auftrag von Rene Struik
>>> Gesendet: Donnerstag, 26. November 2020 21:58
>>>
>>> Dear colleagues:
>>>
>>> Do you think supporting ECDSA25519 would make sense as well?
>>>
>>> This is well-defined and non-deterministic and also can use existing
>>> Curve25519 ladders under the hood (see [1]) as well as existing
>>> generic hardware supporting short-Weierstrass curves (see [2]).
> 1) It is not well defined enough for common sign/verify APIs that take
> message hash. This is because it triggers special case inside ECDSA
> that makes signature dependent on bit order of the hash function. SHA-2=

> defines it one way, SHAKE defines it the other, and other hash function=
s
> may not define it at all.
>
> 2) Deterministic/noisy/non-deterministic is only about specification an=
d
> implementation, it is not about interoperability.
>
> 3) It is not trivial to use existing Curve25519 ladders for verificatio=
n,
> because those do not produce indication if the two products are same- o=
r
> opposite-sign. The cheap trick used by qDSA to check both at once does
> not obviously work because of mod n at output.
>
>>> Due to the PKIX/CMS OID requested during IETF Last-Call on lwig-curve=

>>> draft [3], it seems this could just be used without further ado.
>> Does anyone from LAMPS reviewed the draft and has an opinion on the
>> work?
> My opinion is that ECDSA25519, ECDSA448, ECDH25519 and ECDH448 try to
> shoehorn Curve25519 and Curve448 to obsolete constructions (nevermind
> that those constructions obsolete even more obsolete constructions)
> that mostly negate the simplicity advantages. And in case ECDSA, hit
> a nasty edge case.
>
> And if one wants complete arithmetic, one needs to transform all the
> way to Edwards domain. Not an issue with Curve25519, since mapping
> between montgomery and edwards forms is isomorphism, but for Curve448,
> it is not, so this needs some extra thought. And then there are the
> "-3" variants, which seem to involve mapping that is not isomorphism.
>
>
> Now, EdDSA does have its problems. Mainly the fixed hash functions
> causing issues with constrained environments, where one wants to use
> single hash (which is most probably SHA-256) for everything. Since if
> one wants to use Curve25519 with SHA-256 one needs a new signature
> algorithm, one could define one that is simple.
>
>
> -Ilari
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


--=20
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867



From nobody Wed Dec  9 07:46:58 2020
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 63FFC3A0E4C for ; Wed,  9 Dec 2020 07:46:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4slhNhxtrJB for ; Wed,  9 Dec 2020 07:46:54 -0800 (PST)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 159193A0E5A for ; Wed,  9 Dec 2020 07:46:53 -0800 (PST)
Received: by mail-qk1-x733.google.com with SMTP id h20so1611138qkk.4 for ; Wed, 09 Dec 2020 07:46:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:cc:references:subject:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=no6kkxrWNOCitutlhoPG6g2oikKXecsigVpx12uKpyQ=; b=t6CeGlQRuLvszYRaDwV6kjfIexvF5jodiGmzJEUyxWy14Eu2fmgKoGtoFl9sjcd9qp bXBhazIjAwQqD7ys/xeOjS4AsCfDtnNLWk7Y7jAzOryHwZz2fM7u9LSoANGEcM62y0k+ t3qs5p4tfF6/Dy9OOaC8jR3gPd+YhdfV/1E/wyl54ITKqW0TKoM7Yw3CIWA9ZEz3rlAA 7R1KCf1R/2bWmCt2cY6krMfNecrVoQWiXwUXaTpsbS86K92CmPGwBQ72h47EjBRqTvmp NQZbhvJMOW/+FC3n+hSRHjN3eGiEbEWPLYKiGxDFxsLGla/viAxCWz14R2Kfvo0TwGex 2rFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=no6kkxrWNOCitutlhoPG6g2oikKXecsigVpx12uKpyQ=; b=UOUAcNDqni2CiVTiHjjtDTGLmBDW6HZJ5SiXH5jCOVvu0ZwHOxGbtbV9GSzEOwg9ta Ih1SyPe8QkR6Ci9Jq5awyCCNjuKee6Mlcv3ZhfsJmIJKR4JkicB+46uYnKerQnHTYqey PGS5l5kM7JrBrVlG/iiGH8q6XAWUTdVms+tXClThiCB/ybc1G4eu69JsEzbUGkpUuGay 4/qNMdO0jCBWuszPYBC5mXMBaoo0boXOzr8Zbwele0oJIygbdVM4au15OD3DMKX4UvRK SCd1ogkdD2ZvnMKtet29EZ0UlNkh7VORySMCkTpkEhBWZxADSLBmowvkOqYn+ChixvqR tG3w==
X-Gm-Message-State: AOAM532xElv5DUnQPzbdEco+2wFbLG95zp9ATnWk8G+nhhw5DdX04VJ2 49eicCWXRNeo+JJ5qzDvT7sa4clzhtk=
X-Google-Smtp-Source: ABdhPJyQ7TeJ/CulmKiaV8l//Fc5I5ver8E5LGHPze+MJ7IwhgEh4Qhm7YfGa+wNHCTGOyJBd0Qc1A==
X-Received: by 2002:a37:4a58:: with SMTP id x85mr3513982qka.83.1607528812783;  Wed, 09 Dec 2020 07:46:52 -0800 (PST)
Received: from ?IPv6:2607:fea8:8a0:1397:a11e:9993:894b:7bd2? ([2607:fea8:8a0:1397:a11e:9993:894b:7bd2]) by smtp.gmail.com with ESMTPSA id y192sm1336645qkb.12.2020.12.09.07.46.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Dec 2020 07:46:52 -0800 (PST)
From: Rene Struik 
To: Ilari Liusvaara , "Brockhaus, Hendrik" 
Cc: LAMPS 
References:     
Message-ID: <2e60bcb0-a92f-5cc3-54b2-1135a1a86a5b@gmail.com>
Date: Wed, 9 Dec 2020 10:46:49 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------1DF9B52A784B98893986F260"
Content-Language: en-US
Archived-At: 
Subject: Re: [lamps] supporting ECDSA25519, i.e., ECDSA/SHA256 with Curve25519 under the hood (was: Re: LAMPS Minutes for IETF 109)
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, 09 Dec 2020 15:46:56 -0000

This is a multi-part message in MIME format.
--------------1DF9B52A784B98893986F260
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Implementation of Curve25519 ladder, with y-coordinate recovery:

Inputs: point Q:=3D(u,v) with u nonzero field element of GF(p);=20
non-negative integer k;
Output ladder: x-coordinate xR of R, where R:=3D(xR,yR):=3Dk*Q; {note tha=
t=20
y-coordinate is missing};
Output fixed ladder, with minimal changes: x-coordinate k*Q and=20
x-coordinate (k+1)*Q
-- This allows computation of y-coordinate of k*Q (or of (k+1)*Q, as=20
spelled out in [1] with formula in [2] (also displayed below).=20
Incremental cost: few field multiplies (<1%).


 From the group laws above it follows that if P=3D(u, v), P1=3D(u1, v1),
    and P2=3D(u2, v2) are distinct affine points of the Montgomery curve
    M_{A,B} with P2:=3DP+P1 and if v is nonzero, then the v-coordinate of=

    P1 can be expressed in terms of the u-coordinates of P, P1, and P2,
    and the v-coordinate of P, since

        2*B*v*v1=3D(u*u1+1)*(u+u1+2*A)-2*A-u2*(u-u1)^2.


Ref: [1]=20
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representatio=
ns-15#section-4.2
[2]=20
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representatio=
ns-15#appendix-C.2

I hope this helps, Rene

=3D=3D
3) It is not trivial to use existing Curve25519 ladders for verification,=

because those do not produce indication if the two products are same- or
opposite-sign. The cheap trick used by qDSA to check both at once does
not obviously work because of mod n at output.



On 2020-12-09 10:22 a.m., Rene Struik wrote:
> Hi Ilari:
>
> I am somewhat puzzled by your claims, since - if true - seem to=20
> suggest ECDSA (which has been used in practice almost two decades by=20
> now and is virtually ubiquitous) is not well-defined.
>
> If anything in the specification of ECDSA25519 [1] or ECDSA448 is=20
> unclear, please indicate how this could be improved and I will take=20
> your advice at heart.
>
> Curve448, Ed448, and Wei448 are isomorphic (see [3]).
>
> I do agree with you that the security posture of EdDSA schemes can be=20
> improved, so as to remove trivial single-shot implementation attacks,=20
> but that is out of scope for discussion of ECDSA as defined in [1] and =

> [2]. What about you fix RFC 8032 (you are one of the authors)?
>
> Best regards, Rene
>
>
> Ref:
> [1]=20
> https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representat=
ions-15#section-4.3
> ECDSA25519 =3DECDSA with SHA256 and the short-Weierstrass curve Wei2551=
9=20
> (isomorphic to Curve25519)
> [2]=20
> https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representat=
ions-15#section-4.4
> ECDSA448 =3D ECDSA with SHAKE256 with output-size d=3D512 bit (as also =

> specified in RFC 8692) and the short-Weierstrass curve Wei448=20
> (isomorphic to Curve448)
> [3]=20
> https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representat=
ions-15#appendix-M
> This section provides full details of isomorphic mappings between=20
> Curve448 (Montgomery curve), Ed448 (twisted Edwards curve with=20
> complete addition laws), and Wei448 (short-Weierstrass version)
>
>
> On 2020-12-09 9:17 a.m., Ilari Liusvaara wrote:
>> On Thu, Dec 03, 2020 at 06:14:56PM +0000, Brockhaus, Hendrik wrote:
>>> Thanks to Tomas for his feedback and insight into HW support and=20
>>> PKCS#11.
>>>
>>>> Von: Spasm  Im Auftrag von Rene Struik
>>>> Gesendet: Donnerstag, 26. November 2020 21:58
>>>>
>>>> Dear colleagues:
>>>>
>>>> Do you think supporting ECDSA25519 would make sense as well?
>>>>
>>>> This is well-defined and non-deterministic and also can use existing=

>>>> Curve25519 ladders under the hood (see [1]) as well as existing
>>>> generic hardware supporting short-Weierstrass curves (see [2]).
>> 1) It is not well defined enough for common sign/verify APIs that take=

>> message hash. This is because it triggers special case inside ECDSA
>> that makes signature dependent on bit order of the hash function. SHA-=
2
>> defines it one way, SHAKE defines it the other, and other hash functio=
ns
>> may not define it at all.
>>
>> 2) Deterministic/noisy/non-deterministic is only about specification a=
nd
>> implementation, it is not about interoperability.
>>
>> 3) It is not trivial to use existing Curve25519 ladders for=20
>> verification,
>> because those do not produce indication if the two products are same- =
or
>> opposite-sign. The cheap trick used by qDSA to check both at once does=

>> not obviously work because of mod n at output.
>>
>>>> Due to the PKIX/CMS OID requested during IETF Last-Call on lwig-curv=
e
>>>> draft [3], it seems this could just be used without further ado.
>>> Does anyone from LAMPS reviewed the draft and has an opinion on the
>>> work?
>> My opinion is that ECDSA25519, ECDSA448, ECDH25519 and ECDH448 try to
>> shoehorn Curve25519 and Curve448 to obsolete constructions (nevermind
>> that those constructions obsolete even more obsolete constructions)
>> that mostly negate the simplicity advantages. And in case ECDSA, hit
>> a nasty edge case.
>>
>> And if one wants complete arithmetic, one needs to transform all the
>> way to Edwards domain. Not an issue with Curve25519, since mapping
>> between montgomery and edwards forms is isomorphism, but for Curve448,=

>> it is not, so this needs some extra thought. And then there are the
>> "-3" variants, which seem to involve mapping that is not isomorphism.
>>
>>
>> Now, EdDSA does have its problems. Mainly the fixed hash functions
>> causing issues with constrained environments, where one wants to use
>> single hash (which is most probably SHA-256) for everything. Since if
>> one wants to use Curve25519 with SHA-256 one needs a new signature
>> algorithm, one could define one that is simple.
>>
>>
>> -Ilari
>>
>> _______________________________________________
>> Spasm mailing list
>> Spasm@ietf.org
>> https://www.ietf.org/mailman/listinfo/spasm
>
>

--=20
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867


--------------1DF9B52A784B98893986F260
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Implementation of Curve25519 ladder,
      with y-coordinate recovery:

    

    


    

    
Inputs: point Q:=(u,v) with u nonzero
      field element of GF(p); non-negative integer k;

    
Output ladder: x-coordinate xR of R,
      where R:=(xR,yR):=k*Q; {note that y-coordinate is missing};

    
Output fixed ladder, with minimal
      changes: x-coordinate k*Q and x-coordinate (k+1)*Q

    
-- This allows computation of
      y-coordinate of k*Q (or of (k+1)*Q, as spelled out in [1] with
      formula in [2] (also displayed below). Incremental cost: few field
      multiplies (<1%).

    

    


    

    


      
From the group laws above it follows that if P=(u, v), P1=(u1, v1),
   and P2=(u2, v2) are distinct affine points of the Montgomery curve
   M_{A,B} with P2:=P+P1 and if v is nonzero, then the v-coordinate of
   P1 can be expressed in terms of the u-coordinates of P, P1, and P2,
   and the v-coordinate of P, since

       2*B*v*v1=(u*u1+1)*(u+u1+2*A)-2*A-u2*(u-u1)^2.

    

    


    

    
Ref: [1]
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-15#section-4.2

    
[2]
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-15#appendix-C.2

    


    

    
I hope this helps, Rene

    

    


    

    
==

    

    
3) It is not trivial to use existing
      Curve25519 ladders for verification,
      

      because those do not produce indication if the two products are
      same- or
      

      opposite-sign. The cheap trick used by qDSA to check both at once
      does
      

      not obviously work because of mod n at output. 

    

    


    

    


    

    


    

    
On 2020-12-09 10:22 a.m., Rene Struik
      wrote:

    

    
Hi
      Ilari:
      

      

      I am somewhat puzzled by your claims, since - if true - seem to
      suggest ECDSA (which has been used in practice almost two decades
      by now and is virtually ubiquitous) is not well-defined.
      

      

      If anything in the specification of ECDSA25519 [1] or ECDSA448 is
      unclear, please indicate how this could be improved and I will
      take your advice at heart.
      

      

      Curve448, Ed448, and Wei448 are isomorphic (see [3]).
      

      

      I do agree with you that the security posture of EdDSA schemes can
      be improved, so as to remove trivial single-shot implementation
      attacks, but that is out of scope for discussion of ECDSA as
      defined in [1] and [2]. What about you fix RFC 8032 (you are one
      of the authors)?
      

      

      Best regards, Rene
      

      

      

      Ref:
      

      [1]
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-15#section-4.3

      ECDSA25519 =ECDSA with SHA256 and the short-Weierstrass curve
      Wei25519 (isomorphic to Curve25519)
      

      [2]
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-15#section-4.4

      ECDSA448 = ECDSA with SHAKE256 with output-size d=512 bit (as also
      specified in RFC 8692) and the short-Weierstrass curve Wei448
      (isomorphic to Curve448)
      

      [3]
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-15#appendix-M

      This section provides full details of isomorphic mappings between
      Curve448 (Montgomery curve), Ed448 (twisted Edwards curve with
      complete addition laws), and Wei448 (short-Weierstrass version)
      

      

      

      On 2020-12-09 9:17 a.m., Ilari Liusvaara wrote:
      

      
On Thu, Dec 03, 2020 at 06:14:56PM +0000,
        Brockhaus, Hendrik wrote:
        

        
Thanks to Tomas for his feedback and
          insight into HW support and PKCS#11.
          

          

          
Von: Spasm
            <spasm-bounces@ietf.org> Im Auftrag von Rene Struik
            

            Gesendet: Donnerstag, 26. November 2020 21:58
            

            

            Dear colleagues:
            

            

            Do you think supporting ECDSA25519 would make sense as well?
            

            

            This is well-defined and non-deterministic and also can use
            existing
            

            Curve25519 ladders under the hood (see [1]) as well as
            existing
            

            generic hardware supporting short-Weierstrass curves (see
            [2]).
            

          

        

        1) It is not well defined enough for common sign/verify APIs
        that take
        

        message hash. This is because it triggers special case inside
        ECDSA
        

        that makes signature dependent on bit order of the hash
        function. SHA-2
        

        defines it one way, SHAKE defines it the other, and other hash
        functions
        

        may not define it at all.
        

        

        2) Deterministic/noisy/non-deterministic is only about
        specification and
        

        implementation, it is not about interoperability.
        

        

        3) It is not trivial to use existing Curve25519 ladders for
        verification,
        

        because those do not produce indication if the two products are
        same- or
        

        opposite-sign. The cheap trick used by qDSA to check both at
        once does
        

        not obviously work because of mod n at output.
        

        

        

          
Due to the PKIX/CMS OID requested
            during IETF Last-Call on lwig-curve
            

            draft [3], it seems this could just be used without further
            ado.
            

          

          Does anyone from LAMPS reviewed the draft and has an opinion
          on the
          

          work?
          

        

        My opinion is that ECDSA25519, ECDSA448, ECDH25519 and ECDH448
        try to
        

        shoehorn Curve25519 and Curve448 to obsolete constructions
        (nevermind
        

        that those constructions obsolete even more obsolete
        constructions)
        

        that mostly negate the simplicity advantages. And in case ECDSA,
        hit
        

        a nasty edge case.
        

        

        And if one wants complete arithmetic, one needs to transform all
        the
        

        way to Edwards domain. Not an issue with Curve25519, since
        mapping
        

        between montgomery and edwards forms is isomorphism, but for
        Curve448,
        

        it is not, so this needs some extra thought. And then there are
        the
        

        "-3" variants, which seem to involve mapping that is not
        isomorphism.
        

        

        

        Now, EdDSA does have its problems. Mainly the fixed hash
        functions
        

        causing issues with constrained environments, where one wants to
        use
        

        single hash (which is most probably SHA-256) for everything.
        Since if
        

        one wants to use Curve25519 with SHA-256 one needs a new
        signature
        

        algorithm, one could define one that is simple.
        

        

        

        -Ilari
        

        

        _______________________________________________
        

        Spasm mailing list
        

        Spasm@ietf.org
        

        https://www.ietf.org/mailman/listinfo/spasm
        

      

      

      

    

    


    

    
-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

  


--------------1DF9B52A784B98893986F260--


From nobody Thu Dec 10 09:43:13 2020
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 7FE003A1196 for ; Thu, 10 Dec 2020 09:43:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.109
X-Spam-Level: 
X-Spam-Status: No, score=-3.109 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, 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=digicert.com header.b=iAHAe77I; dkim=pass (1024-bit key) header.d=digicert.com header.b=WXR7Tme4
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 DZqenLhJrVdb for ; Thu, 10 Dec 2020 09:43:02 -0800 (PST)
Received: from us-smtp-delivery-173.mimecast.com (us-smtp-delivery-173.mimecast.com [216.205.24.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 B22C43A1183 for ; Thu, 10 Dec 2020 09:43:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1607622180; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CZwFILpBJUCZAy8Pwbr9MQ0VPZHMmDHmjA9Bcs+y+B4=; b=iAHAe77Itws7iC+d9PkoEn++34OrRLBZ/BINFZ1AlwTE9CRK7+7EBr2rowjUauVWzze+du 44oz7jA91Hst3A7+YhAhpDSARTGOA45yAEwtFlBRONPWho1vkDuPncCB3M7Qq5xaL+W6P+ V0cPqi+Ak+pBDccKHscIHHG5wMt+8Os=
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11lp2175.outbound.protection.outlook.com [104.47.56.175]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-591-sD3ZrBElOMaujjIgjEs6yQ-1; Thu, 10 Dec 2020 12:42:56 -0500
X-MC-Unique: sD3ZrBElOMaujjIgjEs6yQ-1
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mH+oa+GcdXUehVBqvStPHsZ+rsevhLU9ucownlfatocN+cezBLjQ3kjYbrRCoetfAy2KVGKiuUypdjign3hKzc9dVz55BH6PNSQmAB7OBYU49/YQgAHSwNWFLsQSBh6MEk/o/uIKrrgf99+RWbY++ZzhAE1MkUVTOQ7iZZR5+0D4Xer6mOc+wHKPbC1g+esM+yLfN9/mzJelksbWOoponz3HOAHGWFHGC9rV4dPIEt8JWVVxpPUgnboZbxbJLn82kpfu42YQWQOw3VECtnFufNlLTI7blBE7OZCxtbVebOk0OHsFAbJZEdkRsCT8PYdfnrOGNTsLnk/gG3xHO4VvUg==
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=CZwFILpBJUCZAy8Pwbr9MQ0VPZHMmDHmjA9Bcs+y+B4=; b=RbF3zc7yKXPan5tH5qRQB4Yz5QCIZKHzddIDfKjR3vysMex94UMz1EzsRy7PicKvJrV6PawlQODAfS/iqvxoQQ7xw+BZTEWTJ/IchD/7R8vNX9H5jZLZGFdDNse3t0PnzVpG1D0GiHdfVYnX++yw0v5GUQB4aEqgLvi4g6eNyrwHqnqEYJK6O+HsnHrRjmD8t2wO/buU5KEp73o7gk0jqzcnzmLJGlkBKYrJWSGLzomSp0vSzsaXzYbGX72fDJby54qRo+2kLn4/v7A/QMXrk2eGQ1eropo/dl7YYyJ4GuKqt1UEKrJUjzR+jBvC0mBfAEUcMzhE1GobTBSvTwlPew==
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=CZwFILpBJUCZAy8Pwbr9MQ0VPZHMmDHmjA9Bcs+y+B4=; b=WXR7Tme4gxVNlF6KpnhdXBDoEOspfKdFlYdBsP0OeRpusgoreQg02ICwKu3u2+UDPw6Yv0mnXIIV3LzKxr2TxrNrnfqIWftYAdIK7mMCZaq9poMq4fLctPc96tMnwRLb2uQG6eG3GS8s+OyQu73hZgDkYjr5YmSyDqt1TwZxZU8=
Received: from MN2PR14MB3167.namprd14.prod.outlook.com (2603:10b6:208:12e::28) by MN2PR14MB3087.namprd14.prod.outlook.com (2603:10b6:208:127::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.19; Thu, 10 Dec 2020 17:42:51 +0000
Received: from MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::e1ea:51bf:a4b0:2f82]) by MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::e1ea:51bf:a4b0:2f82%7]) with mapi id 15.20.3654.015; Thu, 10 Dec 2020 17:42:51 +0000
From: Tim Hollebeek 
To: Tim Hollebeek , LAMPS 
Thread-Topic: Call for adoption of draft-housley-lamps-crmf-update-alg
Thread-Index: Ada/claNYwRy3JmDRXS5UlaLVNU2IAPqWKmA
Date: Thu, 10 Dec 2020 17:42:51 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=digicert.com;
x-originating-ip: [74.111.113.115]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 49f11b8f-3c06-40b2-2360-08d89d330498
x-ms-traffictypediagnostic: MN2PR14MB3087:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: wW0Q5aFfWKo3VyN8mnlOcwPejh2tswdkRaJ+0G8B0XgC/kDy8RqIvWXhDjFxKx4+CBfXRQ5DeV4BsHwuJc7Hb/CRvUh3Qa1M40BploDq3dwM+N4+GNFLBb7+vTexQoK2F0U9WEN1DBjA188Ne9sqdDx0ILEC6Ou2I3HxqT8IPVVz5arkfY/VlTPNtxNvW/Q2QcD0zym1WP8mbNcSLGLx0NUvf1GyhTTS4v30Dak9nFIzvUbNJfD2HjYibkslfiuGjHtoGY+p051zLN7olYRTio54uXx5jpYtDdUl+HORtRyVhSByrKytJprl+UxgchaN8n28A2m3BNzmGWe3eTyvQOuFpv4Eam/J6rVj2OJ6ey03SmRSy+x355gH9thavQc8hkYTs34f34l2u85Nq3h/WQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MN2PR14MB3167.namprd14.prod.outlook.com; PTR:; CAT:NONE;  SFS:(366004)(376002)(136003)(346002)(186003)(83380400001)(66556008)(15650500001)(33656002)(508600001)(5660300002)(966005)(9686003)(7696005)(66476007)(6506007)(110136005)(8936002)(166002)(99936003)(53546011)(64756008)(26005)(86362001)(66616009)(76116006)(66446008)(55016002)(66946007)(4744005)(52536014)(8676002)(71200400001)(44832011)(2906002); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?9AhtGVNQblcL5S3G9jjxz+UvvB9nWdeJO/BRmw/qyOMLqecZFpup/XHG6ykK?= =?us-ascii?Q?Pwf9KmzHwNqKBHxS3vie6pB1NttZ/Fio2JDTZPyOS57Jq3ERjS6Jt+wXfYkq?= =?us-ascii?Q?cWOOB8sUz+dxf0ha/NW69d6tHqUspFAdp3ogqrjMYSE0ikScFetro6MldZ5s?= =?us-ascii?Q?wkToZuqA+yQd4d/WpKbOlApaw0WTwd4Nt+9Tyc+9Q4cwx8gFXy4aD+hQUIZP?= =?us-ascii?Q?jj5YY3RRsdIM+5n7lbmoIRcU1cNJTtnDOgSTNWE6t4UGo5n5qrKblvt6N2cf?= =?us-ascii?Q?FdR+e+HSY3rFp1Q69lFPKmlWq5ce9MiiePucEUK+ZxtJQaGro8n2LH0ihVBn?= =?us-ascii?Q?ej5eiJJFd+Nyl7Q7a6AtDrB+tmrEgMhA5SD6qh7ABLb5SmFM3aqeocqbKZCR?= =?us-ascii?Q?Gwliu+LYFAQKne0aw8lpUSIMoQ7u3FglUMclaeIE3v7+6c17OrLWWrVAI+1/?= =?us-ascii?Q?Ir2eG2F9Ejs7mcZzvrhoIuFmKIedGQ+fhrlV9UqgKaKGRaVXSpTU7cr/NcRe?= =?us-ascii?Q?wnsWE/HmmRd1OK0GL+2JYjAr9bdPs+ONQRyT319tRgm8wBi/qT2XuxK1SMrV?= =?us-ascii?Q?Vnkh0BrrEOuBqew03EpbUFM42MrfAm50i036iEzJeST/aXXGfwQHV4lvOxWY?= =?us-ascii?Q?TvbHdmuLzMxYtFq5dSKnkR8yGBFOsr+2+N8kw5tHjcHuTvDx1avdASPv77KJ?= =?us-ascii?Q?xfqoPwQgF3SOUB5sys/qlXY+NWQMk/ZOxt8mzF5FE1W+gmS9mcIBhp8j/aue?= =?us-ascii?Q?SJsRneOVH6WKqcrH1t3tmZ/5g6XNN98+T8/tAqdKS6m5/+yeBTwGU4/5dudM?= =?us-ascii?Q?HDr/hbpLpxYUa3mhPpKpujB0mbTPz2bIjH/Jo1NLFaeGSjbgeNhlQxSP8oJI?= =?us-ascii?Q?i6kyl8UY/Z0rKWQFi7m5X2TIJmIqFJF218/L0bff+n+lxo0T4RgWI8BUTlot?= =?us-ascii?Q?fkT1i63iyzLN0FHZsTpzUO4Je6kP52MOW9n/uHutzlc=3D?=
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_0030_01D6CEF1.F8840490"
MIME-Version: 1.0
X-OriginatorOrg: digicert.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR14MB3167.namprd14.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 49f11b8f-3c06-40b2-2360-08d89d330498
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2020 17:42:51.8197 (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: cLAJaowZhuUqa3toemp35FnK5DufqkWmmUZdvnuDgCdNnZcKLoXVAh13ycTw7RjkUAQXapAI5vaianSu9jwDN0NO5FsNOrNi/EEXSjDyPyo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB3087
Archived-At: 
Subject: Re: [lamps] Call for adoption of draft-housley-lamps-crmf-update-alg
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Dec 2020 17:43:12 -0000

------=_NextPart_000_0030_01D6CEF1.F8840490
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0031_01D6CEF1.F8840490"


------=_NextPart_001_0031_01D6CEF1.F8840490
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

It looks like this document has also achieved consensus on adoption.

 

-Tim

 

From: Spasm  On Behalf Of Tim Hollebeek
Sent: Friday, November 20, 2020 3:00 PM
To: LAMPS 
Subject: [lamps] Call for adoption of draft-housley-lamps-crmf-update-alg

 

We talked about Russ's other draft earlier this week that adds more
appropriate modern algorithm choices for password-based MACs in the
Certificate Request Message Format (RFC 4211).  The draft is here:

 

https://www.ietf.org/archive/id/draft-housley-lamps-crmf-update-algs-01.txt

 

Please indicate by December 9th whether you support adoption of
draft-housley-lamps-crmf-update-algs by the LAMPS WG.

 

-Tim

 


------=_NextPart_001_0031_01D6CEF1.F8840490
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


It looks like this document =
has also achieved consensus on adoption.
 
-Tim
 
From: Spasm =
<spasm-bounces@ietf.org> On Behalf Of Tim =
Hollebeek
Sent: Friday, November 20, 2020 3:00 =
PM
To: LAMPS <spasm@ietf.org>
Subject: [lamps] =
Call for adoption of =
draft-housley-lamps-crmf-update-alg
 
We talked =
about Russ’s other draft earlier this week that adds more =
appropriate modern algorithm choices for password-based MACs in the =
Certificate Request Message Format (RFC 4211).  The draft is =
here:
 
https://www.ietf.org/archive/id/draft-housley-lamps-crmf-upda=
te-algs-01.txt
 
Please =
indicate by December 9th whether you support adoption of =
draft-housley-lamps-crmf-update-algs by the LAMPS WG.
 
-Tim
 

------=_NextPart_001_0031_01D6CEF1.F8840490--

------=_NextPart_000_0030_01D6CEF1.F8840490
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
CQUxDxcNMjAxMjEwMTc0MjUwWjAvBgkqhkiG9w0BCQQxIgQgG7SacJkUZ3N9aR4UeibV2y9J39MM
VD7NmZkSqZvCgDYwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp
Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw
ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth
tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq
hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG
SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA
BIIBACgg84lebbOKqCH3DwQg7UBR5Y2HQ1xu6GhAEwqTrik5yaidy50GuH0wuiroxdzqDgefFpax
Kd1QTaPHNbHRY3RXNEnkM6VU6DM0wCXfKMIdnLMzbldi64ZGSfnyIXTnDZIp5gCTZ9lOB1lmJAdK
ZrRuuFFEqc+ydHHK1GLCslVXceOSiuQfCE1kVOvzylcejsmlIYkRzxvz1yRrv6/6uCAKRWVsrQap
53ZPIQl4pnYh8kxAnQsKlc85fgHpSnju5oBjyf0U6aA+ofYMCe3QxdYwjQ+bAUBGZfRZCuIhRsgL
vYdOb0F0QLLNsy+uH+cWIY9Z/sUdYYhPyWSHrvkhBocAAAAAAAA=

------=_NextPart_000_0030_01D6CEF1.F8840490--


From nobody Thu Dec 10 10:42:35 2020
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 4059F3A11F4; Thu, 10 Dec 2020 10:42:26 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: spasm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: spasm@ietf.org
Message-ID: <160762574622.28878.12700232679418693746@ietfa.amsl.com>
Date: Thu, 10 Dec 2020 10:42:26 -0800
Archived-At: 
Subject: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Dec 2020 18:42:33 -0000

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

        Title           : Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)
        Author          : Russ Housley
	Filename        : draft-ietf-lamps-crmf-update-algs-00.txt
	Pages           : 7
	Date            : 2020-12-10

Abstract:
   This document updates the cryptographic algorithm requirements for
   the Password-Based Message Authentication Code in the Internet X.509
   Public Key Infrastructure Certificate Request Message Format (CRMF)
   specified in RFC 4211.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lamps-crmf-update-algs/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lamps-crmf-update-algs-00
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-crmf-update-algs-00


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

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



From nobody Thu Dec 10 10:46:35 2020
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 5F1CA3A11B1 for ; Thu, 10 Dec 2020 10:46:34 -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, 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 ZU9qLXggMkfu for ; Thu, 10 Dec 2020 10:46:32 -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 CE0F23A11B0 for ; Thu, 10 Dec 2020 10:46:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B75A2300B23 for ; Thu, 10 Dec 2020 13:46:28 -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 9uD8PysXZJy8 for ; Thu, 10 Dec 2020 13:46:26 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 0C165300AB0 for ; Thu, 10 Dec 2020 13:46:25 -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.17\))
Date: Thu, 10 Dec 2020 13:46:27 -0500
References: <160762574622.28878.12700232679418693746@ietfa.amsl.com>
To: LAMPS 
In-Reply-To: <160762574622.28878.12700232679418693746@ietfa.amsl.com>
Message-Id: 
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Dec 2020 18:46:34 -0000

This version addresses all og the comments that I received during the =
call for adoption.

Please review.  I think it is ready for WG Last Call.

Russ


> On Dec 10, 2020, at 1:42 PM, internet-drafts@ietf.org wrote:
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Limited Additional Mechanisms for =
PKIX and SMIME WG of the IETF.
>=20
>        Title           : Algorithm Requirements Update to the Internet =
X.509 Public Key Infrastructure Certificate Request Message Format =
(CRMF)
>        Author          : Russ Housley
> 	Filename        : draft-ietf-lamps-crmf-update-algs-00.txt
> 	Pages           : 7
> 	Date            : 2020-12-10
>=20
> Abstract:
>   This document updates the cryptographic algorithm requirements for
>   the Password-Based Message Authentication Code in the Internet X.509
>   Public Key Infrastructure Certificate Request Message Format (CRMF)
>   specified in RFC 4211.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lamps-crmf-update-algs/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lamps-crmf-update-algs-00
> =
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-crmf-update-algs-00=

>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


From nobody Thu Dec 10 12:11:45 2020
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 89D443A126A for ; Thu, 10 Dec 2020 12:11:43 -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 9n2OOuGVyld4 for ; Thu, 10 Dec 2020 12:11:42 -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 9653A3A125D for ; Thu, 10 Dec 2020 12:11:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 25674300BB9 for ; Thu, 10 Dec 2020 15:11:40 -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 qfIyAKOBhOc7 for ; Thu, 10 Dec 2020 15:11:39 -0500 (EST)
Received: from dynamic-005-005-033-019.5.5.pool.telefonica.de (unknown [204.194.23.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 284A2300B10 for ; Thu, 10 Dec 2020 15:11:39 -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.17\))
Message-Id: <132888CA-AA3D-44B7-A5D7-9361CA0792DD@vigilsec.com>
Date: Thu, 10 Dec 2020 15:11:40 -0500
To: LAMPS 
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: [lamps] LAMPS Virtual Interim on 28 Jan 2021
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Dec 2020 20:11:44 -0000

An interim meeting for LAMPS has been approved.  The time was selected =
based on the doodle poll.

	Date: 2021-01-28

	Start Time: 1:00pm Eastern

	Duration: 2 hours

	Remote Participation: WebEx


From nobody Thu Dec 10 13:59:34 2020
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 8DA5C3A12DA for ; Thu, 10 Dec 2020 13:59:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=digicert.com header.b=Hm1Chnh5; dkim=pass (1024-bit key) header.d=digicert.com header.b=F+9OKJGE
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 5qTjFbskxG-X for ; Thu, 10 Dec 2020 13:59:30 -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 87C753A12D9 for ; Thu, 10 Dec 2020 13:59:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1607637569; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TA7MXyV1lr8l8PIFYkl8ouoktjLVyi6ESID91RdXU04=; b=Hm1Chnh5SGSptAbnrzQYX0fKYBREOEgQH4presJJyHubPvKa3HC6u48VObu1OCvjFeD0dh pE92OpEK66B4zb9+y8LQUGKE63sSIfz++gsDyyfd8lZylfif6m3h52fUpHAgwluNdCQJvI aZZmKOHFvqJg0npZFnNwdBNieWBFbDs=
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11lp2174.outbound.protection.outlook.com [104.47.56.174]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-6-4FQXYrOIMye8v0ntNWsjtg-1; Thu, 10 Dec 2020 16:59:27 -0500
X-MC-Unique: 4FQXYrOIMye8v0ntNWsjtg-1
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oM3kUYqPw4MCmyzg4K6bVsLk/JRVO676YFbWeT6o1z0HCsg1Wd03UoFEINxz9DCsj8W9h4VQnhFKQgYNq5p6Ipo14d/1mVRijeeQqlcBsoTD4B9v04M26/BIQl+xkGKyVGI76VMfjhu7MLy6ghzcyfqJgyVfW2xJ2B7Tl6UTKLxkHj//UvQbAyGyb2Gk3fvIw+2kqp7/r1K01WFHtVVdeNRwzRAHgpCKDMZTjm1OdrCyaeuTUbJKJ/xXvDmcwUP+E+iVmRLojZGS9rbU1eGtY6euof2sgZDA1ZnGPcTyuoBzYNaAXtgTNwbEx1WiRSSXwDw7MgZjqIaHYkNw9X/6xA==
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=TA7MXyV1lr8l8PIFYkl8ouoktjLVyi6ESID91RdXU04=; b=ivUaofgdL/DWzirkN9lLxLx3IFQWnB8ewShMxYJb7tunCTn9/Tsj0D1bYV6yyfRt9O3KxBbglCgdC8kfqQxhrQd0ev3BvLYVKH74MlCTsMjjfr+l/WQtU8Gid/0VoSDsaOWDsExUol0ph/eawrPLFZBdwxIyld2KQ0q6DeBry74IZhFAws4kvfPdkxfXCqobBDryiwnEy8qUW7O280U8BvhnVnacf6kMON8p1IZY6xzQtPMUypQihL8kmU5dDOdXHYExR/Tur4nqGP5ut1M+iFwxSoWpVNxs6kWRLz51VLUHfHTRq59Z0A4h2jNE6rm/iqK45Y2E5kC3glaFp/momw==
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=TA7MXyV1lr8l8PIFYkl8ouoktjLVyi6ESID91RdXU04=; b=F+9OKJGEJbQjlrQA5rQHOmrxaV1CT50ib5DDGzCzobkF+Ma4zCiqKY0nSlNUXj3Uh78wvWMxjm6pHAvISKUHt3HGh+BFr/86Y6jmfNLlrgDjuJbD4x6mass9Q7JBJhhjGdBJkYLeEj7lbifV/rU/BDU12VaPHR9vmcpd2Iw7xeQ=
Received: from MN2PR14MB3167.namprd14.prod.outlook.com (2603:10b6:208:12e::28) by MN2PR14MB2816.namprd14.prod.outlook.com (2603:10b6:208:d2::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.21; Thu, 10 Dec 2020 21:59:25 +0000
Received: from MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::e1ea:51bf:a4b0:2f82]) by MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::e1ea:51bf:a4b0:2f82%7]) with mapi id 15.20.3654.015; Thu, 10 Dec 2020 21:59:25 +0000
From: Tim Hollebeek 
To: Russ Housley , LAMPS 
Thread-Topic: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
Thread-Index: AQHWzyRSsMYOEs3BU0aLm4hwxUPCXKnwqz+AgAA1wWA=
Date: Thu, 10 Dec 2020 21:59:25 +0000
Message-ID: 
References: <160762574622.28878.12700232679418693746@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: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=digicert.com;
x-originating-ip: [74.111.113.115]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 530f7ce4-4a39-4cb0-d4d6-08d89d56dbbe
x-ms-traffictypediagnostic: MN2PR14MB2816:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:1824;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: n10LVpAxxBKTN2cwKQlGK4yMgEPWGrpcgVGvr0ByTfxrimRIKEfj2+ta/YOd6cp/64z2fpJZYziIPviQ1fLZhva730aQz2WLaIggVEjsR3BvFc+0+vHbSokXAeyFcHIb+0yhY5nXK5VLRM1t/V2yxIQhowdXpvwR9NDQ21GI517FJSfprvsNGl6nx9bfvz4BqcX4i/h3LD4aWSqoK0mzI+HhB39X2woP0ylpzlWZcPqQ0b+xkqet/vq0pKU9esCOAd10wrUnPuoq5Jf3CS6eDRtrZcSGjczNaZHGNK+ZzBFJn1d7BAswbcADnKxkPjE3kGAgKj6HF03xdp/AN2OyK2T/PtnRmNg8ilF7G1Rs2PJBFmnaa/x/pmDdYe1GVkwFsiMi4s1Tv5QrM6wyYB7RAw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MN2PR14MB3167.namprd14.prod.outlook.com; PTR:; CAT:NONE;  SFS:(346002)(366004)(136003)(376002)(8676002)(508600001)(66946007)(66574015)(2906002)(5660300002)(9686003)(55016002)(83380400001)(66616009)(33656002)(966005)(26005)(4001150100001)(15650500001)(6506007)(53546011)(64756008)(71200400001)(110136005)(66476007)(99936003)(66446008)(8936002)(66556008)(86362001)(52536014)(44832011)(7696005)(76116006)(186003); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?0HdM+uCTGPmrQHamGgHSHlEKi6E3DIWh471Wtl+wSZB7nhyO68TxatpQtPxk?= =?us-ascii?Q?l4O06vMllFXgNH+Uqat60KaWrNd5P4JHxdFzz+LXTS5Xj6kWtUPRoRiCR+u4?= =?us-ascii?Q?hfIl1NqY1Mm+XLZUP1ljOQKYFiYLZkbHA1iXqIP86Rf5U+tHGGEJRJhrHS0P?= =?us-ascii?Q?IgXvvuUqh1MEMW6T8GVTGcaE9IyNZQO9vxc59eUTPe+IPynOzHfzNAjPjUV6?= =?us-ascii?Q?foqNhNoOODtmgTwe18sOszMmw15Xo+4TbTdQ6giTpW0fr5BhSK+ftrq28HP0?= =?us-ascii?Q?neF8CrvHOw/XiuOSIGPQCwB5DC6bzW7xb9o69OtftbHU7WrXcrXWUY12Ldj1?= =?us-ascii?Q?pX8eZIP225xVMwuzt2egQeXz8w8GlQ6atNZkqbduPCNyswYxOkP893cYnFBt?= =?us-ascii?Q?2v5eV3MMdJetRB6e91sCiw8p1gjbWEmQ2Py3ar/1pgC+4/hVMeiYCTJkeaTa?= =?us-ascii?Q?EuA+rVDjJ6bUKwCbuw5jDOoRJyUaXSpvz+OCn4OGtC9zi4LDUx0iNjbu2QUq?= =?us-ascii?Q?7eJ1Ycnu7H/ssrQAn+A71SYq7/HYLW8moqO9RnuY/suBInFeiplteiinzmg3?= =?us-ascii?Q?HICRPfV8EwfElZhofpOcvTV4OvuMk5rCB4U3SAErSOVs2jQVrOh49D2oWlNw?= =?us-ascii?Q?9irAVoZpgISVj/JRzxw9VnW68P4yZknbqTyw9VbIUKRFgl3H8hUkQnm1VC5W?= =?us-ascii?Q?K12vYiFOpnnvyl/ONvdz/mJnnD45VbCqKCPvjpWcXhWF8drF8VCi0smBHsq2?= =?us-ascii?Q?0PVx28wkESubb2XXNIz9QWU0zjd2t9j2Ca1Xb8AwxRnbcC1NWBtq4NEtqDhK?= =?us-ascii?Q?1+puO8nVa+6aPJfdcRyYzlVO8RvKCIoPeiL5LzcKHlupLX8nfn5deAH83A9W?= =?us-ascii?Q?RdeAhkxqw4Sc08IA/LK/GqRNxIVJliPdhUXPcV14WqbdaKwn+e6lSuzDtS+M?= =?us-ascii?Q?AAnNED4/evZD/0bLaRWy7ZN5lCpwpnJrKwA1gAmLk04=3D?=
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_0170_01D6CF15.CF94B2E0"
MIME-Version: 1.0
X-OriginatorOrg: digicert.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR14MB3167.namprd14.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 530f7ce4-4a39-4cb0-d4d6-08d89d56dbbe
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2020 21:59:25.0920 (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: dho/LTqLxq4iCPg7tMpm4nujYJaY152DcAr+j6cO/xnzQS+OhWvYc5hUIHvNkucYHvFwXsSucARrK//KMS9bunCUFqBySQ/4oee50LgTjlQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB2816
Archived-At: 
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Dec 2020 21:59:33 -0000

------=_NextPart_000_0170_01D6CF15.CF94B2E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hendrik and Jonathan,

Have you had a chance to review the new draft, and do you believe your
concerns
have been adequately addressed?

-Tim

> -----Original Message-----
> From: Spasm  On Behalf Of Russ Housley
> Sent: Thursday, December 10, 2020 1:46 PM
> To: LAMPS 
> Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
> 
> This version addresses all og the comments that I received during the call
for
> adoption.
> 
> Please review.  I think it is ready for WG Last Call.
> 
> Russ
> 
> 
> > On Dec 10, 2020, at 1:42 PM, internet-drafts@ietf.org wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Limited Additional Mechanisms for PKIX
and
> SMIME WG of the IETF.
> >
> >        Title           : Algorithm Requirements Update to the Internet
X.509 Public
> Key Infrastructure Certificate Request Message Format (CRMF)
> >        Author          : Russ Housley
> > 	Filename        : draft-ietf-lamps-crmf-update-algs-00.txt
> > 	Pages           : 7
> > 	Date            : 2020-12-10
> >
> > Abstract:
> >   This document updates the cryptographic algorithm requirements for
> >   the Password-Based Message Authentication Code in the Internet X.509
> >   Public Key Infrastructure Certificate Request Message Format (CRMF)
> >   specified in RFC 4211.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-lamps-crmf-update-algs/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-lamps-crmf-update-algs-00
> > https://datatracker.ietf.org/doc/html/draft-ietf-lamps-crmf-update-alg
> > s-00
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at
tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > _______________________________________________
> > 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


------=_NextPart_000_0170_01D6CF15.CF94B2E0
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
CQUxDxcNMjAxMjEwMjE1OTIzWjAvBgkqhkiG9w0BCQQxIgQgxjhUh5kvEcYFDsppAPv1//NSE9CO
neOgML8csCcff34wgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp
Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw
ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth
tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq
hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG
SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA
BIIBAAKm0GEopK0i/h4D0crVktYsvW1wHWTBlIE1eYepxr9jjYrwtnUAxB5EDdr8BQkoIq2u0gS8
PULgfR7/mYzEieAFaur0qyhM8aqFyBvRgf5FbdNAruk+jvSLhVIgE696WQxjOUi8hFFJmo1mT0BV
PkeVEdk37STFCrOs7rAwRBZskVd18WroqMVzDpZDNRcAwEQEuzTQ7BrMHzv/vDCZil2N9KlYwWhS
8KnzDWPJ105eAlwfy011JLAXvF88A/erv+1pd96Mik1/onKsSsOQ8qdA1dCRl7rinOgUUHAsvOO2
gzMhBN3yPuj6fR+NPrmGXJNqp+pX2KOdjCFZ2xAg5FQAAAAAAAA=

------=_NextPart_000_0170_01D6CF15.CF94B2E0--


From nobody Fri Dec 11 11:13:23 2020
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 501623A0DEF for ; Fri, 11 Dec 2020 11:13:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 nXF2zGR9mn7u for ; Fri, 11 Dec 2020 11:13:19 -0800 (PST)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 E1AB33A0DED for ; Fri, 11 Dec 2020 11:13:19 -0800 (PST)
Received: by mail-pj1-x102d.google.com with SMTP id p21so2209556pjv.0 for ; Fri, 11 Dec 2020 11:13:19 -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=WPQrldv9y/1UT8tNISV+2HJJOz/7UhoUR32lOEOWjrs=; b=TLO9ORUVh0FLL9WquHrt3XceMH43keXHUXK6GjNNs5YME3RuDH1tE2ue5pED1bzZ5l /zGX9yM7jBzOKNR/BBjQmXMjQMS4jYTOIqRcIYkJ+UaFjzjwTUARlz7KqDGuVALUGuqR vCqlCp5oUWykjrJGLRgDDhRmAQ0uUJtPd3O/nBNsNNFuYq+hh+nEWbfHoG+8Hi1rY8yB vnVpez0/CpIa50u1WTBboYKJFdHeLHFyB1SIOqOZDjfAjSrrjKjsZcY+McQizsJtDO7c ckCYRUxgcinifhdncGPasISjh3PCl6hhEHvv97BJISZ74wTZKF+WjnukuUx5o5TWalQ4 hfWQ==
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=WPQrldv9y/1UT8tNISV+2HJJOz/7UhoUR32lOEOWjrs=; b=eI3vjzEI/lKKWgjDjO/qK9q0xX1eKa6lULcffauwMPRt7RLjWnmE+O6LwO0XrK3dfR f5iHGVs9089F34ZTgwRxRkWZDdXtW5Hy87gb/F2wW1Zz1lBdQ/2Xd7rsZokjattaAZWK 5X7xw4Ylnv0On6WEolb4TBS8CfcXrUhrBh58p4NHEEiIKvkzaFoPMVukEDkccxyoLqw3 yeEju+bM8dg8S0JjKq+dz7MyLtBIBMmMdaTZ/0eJTSkkKxAIms9caplUJwKDpmidtKug mtReJV+LbqHyb4L+5+JJ2VIxAD9Bv41wRSRTGOsTLQmFsOk7wZXsqGcyMnZrKOASel5w 8ZWQ==
X-Gm-Message-State: AOAM53176++bany6b9/8qmBKpde4G2CuX9641dbesbZ4pHKatsG1xtQN TDQbsnfP+niwc6Waw3YOTAXomckVpukwKs14EmC1Z1qBlSbynQ==
X-Google-Smtp-Source: ABdhPJyduBE+mVfUSTqT2N8tzJJekjbJ5kfbJm00NbvMz4ygmQdFOj7wClGFZT/AVuLGV8Nhd+3cfDkRxGCsMB3acjM=
X-Received: by 2002:a17:902:be02:b029:da:c6c9:c9db with SMTP id r2-20020a170902be02b02900dac6c9c9dbmr12143898pls.69.1607713998988; Fri, 11 Dec 2020 11:13:18 -0800 (PST)
MIME-Version: 1.0
From: Lijun Liao 
Date: Fri, 11 Dec 2020 20:13:08 +0100
Message-ID: 
To: spasm@ietf.org
Content-Type: multipart/alternative; boundary="000000000000cf6a0405b63515ad"
Archived-At: 
Subject: [lamps] Mail regarding draft-ietf-lamps-cmp-updates
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, 11 Dec 2020 19:13:21 -0000

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

Dear authors,

I am extending my open-source project xipki to support this draft. In case
that the CA generates the keypair, it needs to send the private key
encrypted back to the client. In this draft, you change the type of
privateKey and encryptedCert from EncryptedValue to EncryptedKey.

Here the definition of EncryptedKey:
 EncryptedKey ::= CHOICE {
   encryptedValue EncryptedValue, -- deprecated
  envelopedData [0] EnvelopedData
}

If the CA uses the envelopedData choice, the CMP client that does not
support this draft, cannot process the response. So the CA needs a
mechanism to determine whether the CMP client supports this draft or not.
You should increase the CMP version or add some other fields in the CMP
request to provide the CA such information.

BTW, please change the following text block in page 4 (there is no section
2.1.9):

"RFC 4211 [RFC4211] section 2.1.9" to "RFC 4211 [RFC4211] section 2.1 point
9"

Best regards

Lijun Liao

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


Dear authors,

I am extending=
 my open-source project xipki to support this draft. In case that the CA ge=
nerates the keypair, it needs to send the private key encrypted back to the=
 client. In this draft, you change the type of privateKey and encryptedCert=
 from EncryptedValue to EncryptedKey.

Here the def=
inition of EncryptedKey: 
=C2=A0EncryptedKey ::=3D CHOICE {
=
=C2=A0=C2=A0 encryptedValue EncryptedValue, -- deprecated
=C2=A0 =
envelopedData [0] EnvelopedData
 }

If th=
e CA uses the envelopedData choice, the CMP client that does not support th=
is draft, cannot process the response. So the CA needs a mechanism to deter=
mine whether the CMP client supports this draft or not. You should increase=
 the CMP version or add some other fields  in the CMP request to provide th=
e CA such information. 

BTW, please change the=
 following text block in page 4 (there is no section 2.1.9):

=

"RFC 4211 [RFC4211] section 2.1.9" to "RFC 4211 [=
RFC4211] section 2.1 point 9"

Best regards

Lijun Liao



--000000000000cf6a0405b63515ad--


From nobody Fri Dec 11 11:24:41 2020
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 421953A0E71 for ; Fri, 11 Dec 2020 11:24:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2zKdr6ik8hn for ; Fri, 11 Dec 2020 11:24:37 -0800 (PST)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 909F33A0E76 for ; Fri, 11 Dec 2020 11:24:37 -0800 (PST)
Received: by mail-pf1-x42d.google.com with SMTP id q22so7577155pfk.12 for ; Fri, 11 Dec 2020 11:24:37 -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;  bh=XWfSNGmL0clIhK+C4GuoOURLx+RJ/lHjYhlCDP0/JVs=; b=deRGkGwjQrZUyn1aPaJobmniq+o554OPn8QdfBT0jpQ1PXtbyRxv2zaeWuDRF8NTUf sWTUjYGXcxF2H0BWgfmiMsDHjU/5J37P8AaNt0sLnDOBH4+8djZhtPVcSxkNwbbyfnvu WN/+fDJoiJYVYHk04j9zE/zSe5TI37YZxIY6uXbkbErMPGdXYwAUovSb+9oOVGTvLhW+ /Rmd2OIECv4HBGNPrQiLQPfNp6c5yOjDh6v9ZJ3nLQywTZdSwEcg59aOBncIOfHSnj4a WUEoTaqq30PbiR1pxbSOR8SFiAfXR4OIpFQaIhjLde+Fdki2fd+NU4f68AnyOBXlCOtt /OVQ==
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; bh=XWfSNGmL0clIhK+C4GuoOURLx+RJ/lHjYhlCDP0/JVs=; b=Y/R46aWecwTNzWu18OqduOiKYVsrEI//2gcpUrO9R3HnKp7Xc/qIRXMc2RtvtN/j76 Nz/ZNEsb9JzXi2ox9t2nrubDWrQ8S94QGYvXNBWP4y9LDbE9l77tnXFkI0iWzUW3+sgV 2WIJqSzkqt2vA0byn47u1UePsXImgtCHaQD4X25KMixmbAYp7rUeWpju0+WGwEKt7Ntf Zq+Hgtt9Z27sRi9zPzNXLuHtL8LSw5fj/isdK6iYWkuzDP4lbRG9E8KHwb2en5X0uYre vD9Gt4J7sn4P0QO7+RWm1g/OjlHy0DnVVwE9I0dcgey4XSffzkJULjQmCJuTOLt/P6n2 orYQ==
X-Gm-Message-State: AOAM530FXKB/sykuokJV0ExNU863VjKKJoDPsrYS/yTnTjsIcSttUL6m ii/oQoqcjg3X/ht0q5r1VS6zL9sHS0Y9ufBmxjmM5KTiGMMrBg==
X-Google-Smtp-Source: ABdhPJz6zhiB5PAPmscdmam1Q87Hdx/tYsMkN+HVkIhWDJaERVB2PZwrOJZWGHM0qdhusa/Q8HZAq2e2hLtlAQJui4E=
X-Received: by 2002:a63:cb47:: with SMTP id m7mr13261183pgi.395.1607714676870;  Fri, 11 Dec 2020 11:24:36 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Lijun Liao 
Date: Fri, 11 Dec 2020 20:24:25 +0100
Message-ID: 
To: spasm@ietf.org
Content-Type: multipart/alternative; boundary="00000000000037113805b6353ef8"
Archived-At: 
Subject: Re: [lamps] Mail regarding draft-ietf-lamps-cmp-updates
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, 11 Dec 2020 19:24:39 -0000

--00000000000037113805b6353ef8
Content-Type: text/plain; charset="UTF-8"

Sorry please ignore this email. It should be targeted to the authors (
draft-ietf-lamps-cmp-updates@ietf.org).

On Fri, Dec 11, 2020 at 8:13 PM Lijun Liao  wrote:

> Dear authors,
>
> I am extending my open-source project xipki to support this draft. In case
> that the CA generates the keypair, it needs to send the private key
> encrypted back to the client. In this draft, you change the type of
> privateKey and encryptedCert from EncryptedValue to EncryptedKey.
>
> Here the definition of EncryptedKey:
>  EncryptedKey ::= CHOICE {
>    encryptedValue EncryptedValue, -- deprecated
>   envelopedData [0] EnvelopedData
> }
>
> If the CA uses the envelopedData choice, the CMP client that does not
> support this draft, cannot process the response. So the CA needs a
> mechanism to determine whether the CMP client supports this draft or not.
> You should increase the CMP version or add some other fields in the CMP
> request to provide the CA such information.
>
> BTW, please change the following text block in page 4 (there is no section
> 2.1.9):
>
> "RFC 4211 [RFC4211] section 2.1.9" to "RFC 4211 [RFC4211] section 2.1
> point 9"
>
> Best regards
>
> Lijun Liao
>
>

-- 
Lijun Liao

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


Sorry please ignore this email. It should be targeted to t=
he authors (draft-=
ietf-lamps-cmp-updates@ietf.org).

<=
div dir=3D"ltr" class=3D"gmail_attr">On Fri, Dec 11, 2020 at 8:13 PM Lijun =
Liao <lijun.liao@gmail.com&g=
t; wrote:
Dear authors,

I am extending my op=
en-source project xipki to support this draft. In case that the CA generate=
s the keypair, it needs to send the private key encrypted back to the clien=
t. In this draft, you change the type of privateKey and encryptedCert from =
EncryptedValue to EncryptedKey.

Here the definitio=
n of EncryptedKey: 
=C2=A0EncryptedKey ::=3D CHOICE {
=C2=A0=
=C2=A0 encryptedValue EncryptedValue, -- deprecated
=C2=A0 envelo=
pedData [0] EnvelopedData
 }

If the CA u=
ses the envelopedData choice, the CMP client that does not support this dra=
ft, cannot process the response. So the CA needs a mechanism to determine w=
hether the CMP client supports this draft or not. You should increase the C=
MP version or add some other fields  in the CMP request to provide the CA s=
uch information. 

BTW, please change the follo=
wing text block in page 4 (there is no section 2.1.9):

=

"RFC 4211 [RFC4211] section 2.1.9" to "RFC 4211 [RFC421=
1] section 2.1 point 9"

Best regards

Lijun Liao





-- 
Lijun Liao


--00000000000037113805b6353ef8--


From nobody Fri Dec 11 11:48:36 2020
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 004F03A0E92 for ; Fri, 11 Dec 2020 11:48:35 -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_MSPIKE_H2=-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=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 Ft2V3PTytAsY for ; Fri, 11 Dec 2020 11:48:33 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60082.outbound.protection.outlook.com [40.107.6.82]) (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 958C63A0E90 for ; Fri, 11 Dec 2020 11:48:33 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d7adfm3VAk0onkkkuKccP3HN3/pYcSRGZmKPbnFf9Cfu9I17+dxfMWlwU5KEs4cSfJEpO6844qxv1tIJrCYH3bvDiXran1VEpd1MSNYmEBEbA/9P/8JtaF1weNYinTkBT5hN0kZrWoSIfuCZqq0docpU2FnR2K+L/yO2VwARZONHGyNKb0+tCWQ+HoUmEajgYxy8amCKzYRHdmIyIUVKeA58UFdGJwR/syHamlHczuTkUhx5Tjr/itCAu7gUKT4raqta3a5aJI9QVTomolXcc2RMm+/cTaIOZ1/HqazhpyrsRKLKgzmgWWfWFGSi3XpzEhfdyz4E8NakRCUe/hoYpA==
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=ma98V/A4hxrQnqu/BNNg6w+wDpzweFOwfXspZ6w0mDw=; b=LGqpM//mkSyQhlxhpZxh2LKSTeG44lLrNxOkmWk4UOf1CeK1ThSrCD74ULzUGZZIJl9ULuvxjbC5hLZuXp5xUPO5pQdwIQdIFBmnqoA5bMdEhXf52/EOdK1PXgMl6KJqbaqzStD/CKg1qmwSRtTpOgR3snW8z7hRmh+uZoa2QADSryXNYj1o3qqo3mdI7QkTwUfoi9eavoK8HiYQGytns3AZYeHsIDB//3HHvdDSqwt8B4oSRidDwKhpA5BWduE4JP7wVT6bn8Y/WbX2MNTC442HPzyNKwXLMycMAXwFGgZHY7vZb1yHQtUX75qOZpAe83IFjl+ty3Zlg8sCTK25HA==
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=ma98V/A4hxrQnqu/BNNg6w+wDpzweFOwfXspZ6w0mDw=; b=Fmaw7mxCHLUhpolGbpdFutl3fyOInsteiw10j3Rb9IzH8eKLhICoFsWbGWsZDagPZKRdEA8jeeibV1dqZ+TTaFwW7SJefeeoWi1oRHwEcMk/BiE7ag5OCjUNB6tFQAp272kiaIspn5SJo3tx0o0tb1J/e6c2oBCNBKCOatuWJp0=
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM0PR10MB3604.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:15a::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Fri, 11 Dec 2020 19:48:28 +0000
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69%7]) with mapi id 15.20.3654.013; Fri, 11 Dec 2020 19:48:28 +0000
From: "Brockhaus, Hendrik" 
To: Lijun Liao 
CC: "spasm@ietf.org" 
Thread-Topic: [lamps] Mail regarding draft-ietf-lamps-cmp-updates
Thread-Index: AQHWz/G52ReRDe2aYUmX7qyUfOqxtanyRpew
Date: Fri, 11 Dec 2020 19:48:27 +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: 
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-12-11T19:48:26Z;  MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=41bb9ec5-5fef-4b93-97ba-aaabe8c94668; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=siemens.com;
x-originating-ip: [165.225.200.165]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 6234a2c8-5728-4e41-b8e9-08d89e0dbae5
x-ms-traffictypediagnostic: AM0PR10MB3604:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: UV5732wS4+xb5C1MmWtI4epioelFWb/7h5quQtcqjGT4j8gwxyBQqNhO3RI5X3M6CL5oRKjOjYZ3mlXVUW1GBfO1zrCSjBwmtSbmfXpjU/x9ov7snQPSA8t57rVlgMfawOzEanL+/yGfxwgd2sXv6xnBGcdkmqIw8ygTqgi3iJCriA+xlmKCVr3GUEGuyfBAIJeybfeuPV4aF1KP3fpIrhTJgDY8d1iJiY0U+Jj9lhXEegmtZLZMUMJGyUDpGkoA8mSn8FydNlsFgyWtkbGoYM7D28pH+XVCDkPy8z+5BYpudWXFAAh6T3XP45dHIHFSvLK6Ksy5XXGAONsPvPHk4w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(4636009)(396003)(39860400002)(366004)(136003)(376002)(346002)(316002)(33656002)(66476007)(66946007)(52536014)(66556008)(83380400001)(6506007)(55236004)(6916009)(4326008)(9686003)(86362001)(7696005)(478600001)(64756008)(8936002)(71200400001)(186003)(26005)(76116006)(8676002)(2906002)(66446008)(5660300002)(55016002); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?utf-8?B?UmV2RVFjcDAwR2ZwWnBIVlYxOGE3LzRHOHpBOHBkL1JIUDYzU2gzMTMwUHZi?= =?utf-8?B?UjB5SDdtRHlMbVpGTDNEZjZGejUwNU9oYkVCYmcyd0JFNUQyUCttSzc1dFUz?= =?utf-8?B?eVNFVW13aFh2bi9hSXlBMzg3WHlIN0J4U2JIS28vTXpmN2Y0Mm9jYTVZUjlh?= =?utf-8?B?YllXMUY1dTBlUGdRT1RSU3JPeC9QNW51OCszdkl5aCtkMWRMc3VtUjJ6Y3B5?= =?utf-8?B?RWtXRHNtV0RRR25vU1RlMkk1anNKOGFHTE1kMG56S2RlZld3c09ybWMvVGtZ?= =?utf-8?B?RTJKTEVrMmludUI4ZjVSVEUrbzNIcTRiTHphSmljQjJCMXBPZ1o5VVFBSmJQ?= =?utf-8?B?Q1ZYM0hCcWxXRk1aSENMQTlxdlVENTFScHgyNmdDcmJhcE9rZkJHSjRtSEZ3?= =?utf-8?B?MEZPSTc2MnViUXEreFJ0K1hVbWJxL0tVdEtYanhmdUdReU15U05UTVFYQ0RF?= =?utf-8?B?ajVTQzBaRGhxOW0yQVU4blZhaTd2SkN5eTBndWtxcXdpcjZxWjhXQlBBaHUr?= =?utf-8?B?R2F0eFJpSmdFbk1zTmtvaVNWRjZQOEV1MVVOZDRqZElVQUhYYlA0WG0wSnJh?= =?utf-8?B?OEdXYTdldW5yNklZNVljT3A2c3E1ZDFsS3N3M1k4VFY5NEI0aWtXOERPYTcw?= =?utf-8?B?elBOdVVwV1JpWksydkwvRnIxdnBGTzBUN2Z0Sk5YZk9aS3p1Z2RIMytQNERH?= =?utf-8?B?cDJ1YlcyMVQ2ZlAwa3FscHdpU0Nvb3NjdnJoa1BqNGxSdklwelJHdGtMN3lu?= =?utf-8?B?Ry9MdWQ3YWFLTVg5L0pMd3h4Vkl2dWsvNjNVWXRoZjQyWVJySU12SVdpS0du?= =?utf-8?B?QUZlMFlTK0svbHlFWCtldUQzTHBrNlAwaE1MUnFkTDVFZGYxamJ4NW9zL2tp?= =?utf-8?B?KzRpMXRmcGxNcWg3TTBtKzlaRmE1MmhtaktZZjc4QWVoMGd6elJjMXppTS9V?= =?utf-8?B?S0ZrTGNBWlpOaEJLUEs1cVNJRmZYV2ZjeHcvR3RVL0lCMjM0UFVteDZHTmJD?= =?utf-8?B?TTZpWklSKzBQMFpKay9FVnBaVnlkVnlKd3dFMnlOYTZjMUVxcGxtdnBHOXJi?= =?utf-8?B?TDRCWGE4Y3NaZDBvZzJkdUFtcUE0VUVYTlBrOUc2L0I3MGFKQWtvSWtIRHpT?= =?utf-8?B?NFk1U3RPQnFIQVd2NWlxWkVKOFRFN0xXaU1WZkNJcGpMdXN6c3VIMWtidVVM?= =?utf-8?B?bW1mSDR5bXFVbWE5Q3VmSWFsdENleFI4dkhQTzF2WHFxckU4QmcyQWYzeU5H?= =?utf-8?B?WnVGbXY1ODVCbFpuMlRTNXV2YllYQVNUQ2w3QWpQZkFqY1NvaW5Ub242WThE?= =?utf-8?Q?IdZPJ3wmJbOhEIINHItx5ptCGHdyZrknyE?=
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-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 6234a2c8-5728-4e41-b8e9-08d89e0dbae5
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2020 19:48:27.9676 (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: uCqP7KxF3X1Zh3zry2ikdMkJWwx23qGK1f0VDUrY2stcqqgkRilteEwXnSfMXD3IW44bQEPbrnAdw1od07zs5yD/reE3tjfXR9Fqe7uIXdE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB3604
Archived-At: 
Subject: Re: [lamps] Mail regarding draft-ietf-lamps-cmp-updates
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, 11 Dec 2020 19:48:35 -0000

RGVhciBMaWp1biBMaWFvDQoNClRoYW5rIHlvdSBmb3IgeW91ciBlbWFpbC4NCk5pY2UgdG8gaGVh
ciwgdGhhdCB5b3UgYXJlIGFib3V0IHRvIGltcGxlbWVudCB0aGUgY2hhbmdlcy4NCg0KPiBWb246
IFNwYXNtIDxzcGFzbS1ib3VuY2VzQGlldGYub3JnPiBJbSBBdWZ0cmFnIHZvbiBMaWp1biBMaWFv
DQo+IEdlc2VuZGV0OiBGcmVpdGFnLCAxMS4gRGV6ZW1iZXIgMjAyMCAyMDoxMw0KPg0KPiBEZWFy
IGF1dGhvcnMsDQo+DQo+IEkgYW0gZXh0ZW5kaW5nIG15IG9wZW4tc291cmNlIHByb2plY3QgeGlw
a2kgdG8gc3VwcG9ydCB0aGlzIGRyYWZ0LiBJbiBjYXNlIHRoYXQgdGhlIENBIGdlbmVyYXRlcyB0
aGUga2V5cGFpciwgaXQgbmVlZHMgdG8gc2VuZCB0aGUgcHJpdmF0ZSBrZXkgZW5jcnlwdGVkIGJh
Y2sgdG8gdGhlIGNsaWVudC4gSW4gdGhpcyBkcmFmdCwgeW91IGNoYW5nZSB0aGUgdHlwZSBvZiBw
cml2YXRlS2V5IGFuZCBlbmNyeXB0ZWRDZXJ0IGZyb20gRW5jcnlwdGVkVmFsdWUgdG8gRW5jcnlw
dGVkS2V5Lg0KPg0KPiBIZXJlIHRoZSBkZWZpbml0aW9uIG9mIEVuY3J5cHRlZEtleTogDQo+wqBF
bmNyeXB0ZWRLZXkgOjo9IENIT0lDRSB7DQo+wqDCoCBlbmNyeXB0ZWRWYWx1ZSBFbmNyeXB0ZWRW
YWx1ZSwgLS0gZGVwcmVjYXRlZA0KPsKgIGVudmVsb3BlZERhdGEgWzBdIEVudmVsb3BlZERhdGEN
Cj4gfQ0KPg0KPiBJZiB0aGUgQ0EgdXNlcyB0aGUgZW52ZWxvcGVkRGF0YSBjaG9pY2UsIHRoZSBD
TVAgY2xpZW50IHRoYXQgZG9lcyBub3Qgc3VwcG9ydCB0aGlzIGRyYWZ0LCBjYW5ub3QgcHJvY2Vz
cyB0aGUgcmVzcG9uc2UuIFNvIHRoZSBDQSBuZWVkcyBhIG1lY2hhbmlzbSB0byBkZXRlcm1pbmUg
d2hldGhlciB0aGUgQ01QIGNsaWVudCBzdXBwb3J0cyA+IHRoaXMgZHJhZnQgb3Igbm90LiBZb3Ug
c2hvdWxkIGluY3JlYXNlIHRoZSBDTVAgdmVyc2lvbiBvciBhZGQgc29tZSBvdGhlciBmaWVsZHMg
aW4gdGhlIENNUCByZXF1ZXN0IHRvIHByb3ZpZGUgdGhlIENBIHN1Y2ggaW5mb3JtYXRpb24uIA0K
DQpZb3UgYXJlIHJpZ2h0LCB0aGUgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBpcyBlbnN1cmUsIGFz
IHRoZSBvbGQgYW5kIHRoZSBuZXcgc3ludGF4IGFyZSBpZGVudGljYWwgd2hlbiB1c2luZyB0aGUg
Y2hvaWNlIEVuY3J5cHRlZCBWYWx1ZS4NCkkgdGhpbmsgeW91IGFyZSByaWdodCwgaWYgYSBDQSB1
c2VzIEVudmVsb3BlZERhdGEgaW5zdGVhZCwgdGhlIGNsaWVudCB3aWxsIG5vdCBiZSBhYmxlIHRv
IHBhcnNlIHRoZSB2YWx1ZS4NCk91ciBpZGVhIHdhcywgdGhhdCB0aGUgY2xpZW50IGluIHRoaXMg
Y2FzZSByZXNwb25kcyB3aXRoIGFuIGVycm9yIGNvZGUsIGUuZy4sIGJhZERhdGFGb3JtYXQuDQog
ICAgICAgICBiYWREYXRhRm9ybWF0ICAgICAgICg1KSwNCiAgICAgICAgIC0tIHRoZSBkYXRhIHN1
Ym1pdHRlZCBoYXMgdGhlIHdyb25nIGZvcm1hdA0KQnV0IHlvdSBtYXkgYmUgcmlnaHQsIG1heSBi
ZSBpdCBpcyBjbGVhcmVyIHRvIGluY3JlYXNlIHRoZSBDTVAgdmVyc2lvbiBudW1iZXIuIFRoZW4g
dGhlIENBIGtub3dzIGluIGFkdmFuY2UgYWJvdXQgdGhlIGNhcGFiaWxpdGllcyBvZiB0aGUgY2xp
ZW50Lg0KT3VyIGdvYWwgd2FzIHRvIG1ha2Ugb25seSBtaW5pbWFsIGNoYW5nZXMgdG8gQ01QIHRv
IGNpcmN1bXZlbnQgaW5jcmVhc2luZyB0aGUgQ01QIHZlcnNpb24uIA0KV2UgZGlzY3Vzc2VkIHRo
ZSBkaWZmZXJlbnQgb3B0aW9ucyB3aXRoIEppbSBTaGFhZCBpbiAyMDE5LiBCdXQgc2FkbHkgd2Ug
d2lsbCBub3QgYmUgYWJsZSB0byBhc2sgaGltIGZvciBndWlkYW5jZSBhbnkgbW9yZS4gOi0oDQoN
CkFyZSB0aGVyZSBvdGhlciBpZGVhcyBvdXQgdGhlcmU/DQoNCj4NCj4gQlRXLCBwbGVhc2UgY2hh
bmdlIHRoZSBmb2xsb3dpbmcgdGV4dCBibG9jayBpbiBwYWdlIDQgKHRoZXJlIGlzIG5vIHNlY3Rp
b24gMi4xLjkpOg0KPg0KPiAiUkZDIDQyMTEgW1JGQzQyMTFdIHNlY3Rpb24gMi4xLjkiIHRvICJS
RkMgNDIxMSBbUkZDNDIxMV0gc2VjdGlvbiAyLjEgcG9pbnQgOSINCg0KVGhhbmtzIGZvciB0aGUg
aGludCENCg0KQmVzdCByZWdhcmRzDQpIZW5kcmlrDQo=


From nobody Fri Dec 11 11:55:53 2020
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 433083A0E98 for ; Fri, 11 Dec 2020 11:55:48 -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, 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 m4Hi_ja1s4L6 for ; Fri, 11 Dec 2020 11:55:46 -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 16AB83A0EB5 for ; Fri, 11 Dec 2020 11:55:46 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7E64E300BA5 for ; Fri, 11 Dec 2020 14:55:43 -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 m2Y7speBbeaW for ; Fri, 11 Dec 2020 14:55:41 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id A8D49300B6D; Fri, 11 Dec 2020 14:55:41 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Russ Housley 
In-Reply-To: 
Date: Fri, 11 Dec 2020 14:55:43 -0500
Cc: Lijun Liao , "spasm@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <44EBF4BD-7560-492B-A061-CC9CCB848D08@vigilsec.com>
References:  
To: "Brockhaus, Hendrik" 
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] Mail regarding draft-ietf-lamps-cmp-updates
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, 11 Dec 2020 19:55:48 -0000

> On Dec 11, 2020, at 2:48 PM, Brockhaus, Hendrik =
 wrote:
>=20
> Dear Lijun Liao
>=20
> Thank you for your email.
> Nice to hear, that you are about to implement the changes.
>=20
>> Von: Spasm  Im Auftrag von Lijun Liao
>> Gesendet: Freitag, 11. Dezember 2020 20:13
>>=20
>> Dear authors,
>>=20
>> I am extending my open-source project xipki to support this draft. In =
case that the CA generates the keypair, it needs to send the private key =
encrypted back to the client. In this draft, you change the type of =
privateKey and encryptedCert from EncryptedValue to EncryptedKey.
>>=20
>> Here the definition of EncryptedKey:=20
>>  EncryptedKey ::=3D CHOICE {
>>    encryptedValue EncryptedValue, -- deprecated
>>   envelopedData [0] EnvelopedData
>> }
>>=20
>> If the CA uses the envelopedData choice, the CMP client that does not =
support this draft, cannot process the response. So the CA needs a =
mechanism to determine whether the CMP client supports > this draft or =
not. You should increase the CMP version or add some other fields in the =
CMP request to provide the CA such information.=20
>=20
> You are right, the backward compatibility is ensure, as the old and =
the new syntax are identical when using the choice Encrypted Value.
> I think you are right, if a CA uses EnvelopedData instead, the client =
will not be able to parse the value.
> Our idea was, that the client in this case responds with an error =
code, e.g., badDataFormat.
>         badDataFormat       (5),
>         -- the data submitted has the wrong format
> But you may be right, may be it is clearer to increase the CMP version =
number. Then the CA knows in advance about the capabilities of the =
client.
> Our goal was to make only minimal changes to CMP to circumvent =
increasing the CMP version.=20
> We discussed the different options with Jim Shaad in 2019. But sadly =
we will not be able to ask him for guidance any more. :-(
>=20
> Are there other ideas out there?

When we have done things like this in CMS, we say when encryptedValue is =
used, the version MUST be X, and when envelopedData is used, the version =
MUST be x+1.  This allows an unsupported version error instead of a bad =
format.

Russ


From nobody Fri Dec 11 12:31:58 2020
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 1C74A3A0EBB for ; Fri, 11 Dec 2020 12:31:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 nfIPZF5U9vJw for ; Fri, 11 Dec 2020 12:31:56 -0800 (PST)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 1426C3A0EB3 for ; Fri, 11 Dec 2020 12:31:55 -0800 (PST)
Received: by mail-pl1-x635.google.com with SMTP id u4so5147673plr.12 for ; Fri, 11 Dec 2020 12:31:55 -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=LFoo/m2CE20p39rl9jeAGBDXfdKAcGG0j3Y3dyi5pb0=; b=FODLGiv7BQNTk/EZpZRUSeLVD4zRp2wulMOoTklonr4NXmIWoZBU5pWjrv5AUM50Pt azAS3pKOZmyzI4AJ+QOTTHVySn1esGd8ewdnL1Sg8+MYjR+0L6tZQ09ECqgNdXb+sZne 6Xtap1NXfy6xmzeNLcDJB1vwQlT2zXsMad087b2aFapMPCfAMyVd15yew+RQp96+/hQ9 YcJ5kXvfVcvikSAiyju+XjKYKV4fK54pz5Hz5ehk1Pg1hqjIeSCTeEfHvbTlcBNEZOsO Kowgplh7mWipj8ylnE12auv7Kt6srY5sgE29TmYhVPLHvp0lN1q5knt9v1ubhi4ho7rp VxtA==
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=LFoo/m2CE20p39rl9jeAGBDXfdKAcGG0j3Y3dyi5pb0=; b=P485/PAyI7J9vz6P2dq/ejBVay6/VjwDe1VIFyUmQe675MPhA8H9fRzb8DGDAi7TDg YVRuowCcfGchC929cDYoCtoWvrCdEsYD6B8dBFMv/2tVzcFj5CKBQPKI7WSvI6LWkp+3 dO68hoDnBY1uN8FlYuIUl2P4ayR+x7hHjvlS53Fvr4rn2lUlvNG1tqtIf5aaWdjisnIo 5Hu477ND4PaoRmv26nE9EeZdVVv1dxuYnusagr51kS1yy3URTYTRWfn6P3nb6IeA0C7d QJyxcpQNsnTD8G5ok9SZNdx4CIK6R53xii8IzrW+P0FJJ3lvSYnbJcNhGhXmC329tfU+ bFlA==
X-Gm-Message-State: AOAM532c7jnYAWfFlv4qIKG+KORUonf5WQlbdtNLQfBu7G1P/+6rGhJJ fwM7SEd0neHKccvzzXd9ANIsiV1Y2LOOBNYKwgQ=
X-Google-Smtp-Source: ABdhPJzes5gkFbpD3tLztlRS0nbq6CoabTqNk9mMfko7T0pCDoJj7SevfRJkhEuonrqTDAPIoXaaaRjheJqVYCVrhBs=
X-Received: by 2002:a17:902:7449:b029:da:c15c:e98e with SMTP id e9-20020a1709027449b02900dac15ce98emr12675274plt.2.1607718714518; Fri, 11 Dec 2020 12:31:54 -0800 (PST)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Lijun Liao 
Date: Fri, 11 Dec 2020 21:31:43 +0100
Message-ID: 
To: "Brockhaus, Hendrik" 
Cc: "spasm@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000e0afd905b6362e5a"
Archived-At: 
Subject: Re: [lamps] Mail regarding draft-ietf-lamps-cmp-updates
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, 11 Dec 2020 20:31:58 -0000

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

> You are right, the backward compatibility is ensure, as the old and the
> new syntax are identical when using the choice Encrypted Value.
> I think you are right, if a CA uses EnvelopedData instead, the client will
> not be able to parse the value.
> Our idea was, that the client in this case responds with an error code,
> e.g., badDataFormat.
>          badDataFormat       (5),
>          -- the data submitted has the wrong format
>
This may not work, in many cases, there is only one round (request -
response). The client does not get the chance to send the CA this
error message. Even this is possible, we waste here one round, and the CA
have to cache the previous response. As I understand one of
the reasons to update the CMP RFCs is to target the IoT area, which is very
sensitive on the communication and computation consumption.
Increasing the rounds does not fit to such scenarios.

But you may be right, may be it is clearer to increase the CMP version
> number. Then the CA knows in advance about the capabilities of the client.
> Our goal was to make only minimal changes to CMP to circumvent increasing
> the CMP version.
> We discussed the different options with Jim Shaad in 2019. But sadly we
> will not be able to ask him for guidance any more. :-(
>
Sorry to hear about this.

>
> Are there other ideas out there?
>
If you cannot increase the CMP version, what about adding a new
InfoTypeAndValue to the PKIHeader.generalInfo?

Best regards

Lijun

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



You are right, the backward compatibility is ensure, as the old and the new=
 syntax are identical when using the choice Encrypted Value.

I think you are right, if a CA uses EnvelopedData instead, the client will =
not be able to parse the value.

Our idea was, that the client in this case responds with an error code, e.g=
., badDataFormat.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0badDataFormat=C2=A0 =C2=A0 =C2=A0 =C2=A0(=
5),

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- the data submitted has the wrong forma=
t
This may not work, in many cases, there is only one =
round (request - response). The client does not get the chance to send the =
CA this
 error message. Even this is possible, we waste here one =
round, and the CA have to cache the previous response. As I understand one =
of
the reasons to update the CMP RFCs is to target the IoT area, =
which is very sensitive on the communication and computation consumption.
 Increasing the rounds does not fit to such scenarios.


But you may be right, may be it is clearer to increase the CMP version numb=
er. Then the CA knows in advance about the capabilities of the client.

Our goal was to make only minimal changes to CMP to circumvent increasing t=
he CMP version. 

We discussed the different options with Jim Shaad in 2019. But sadly we wil=
l not be able to ask him for guidance any more. :-(
So=
rry to hear about this. 



Are there other ideas out there?
If you cannot increas=
e the CMP version, what about adding a new InfoTypeAndValue to the PKIHeade=
r.generalInfo? 

Best regards

=
Lijun


--000000000000e0afd905b6362e5a--


From nobody Fri Dec 11 12:41:35 2020
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 9283F3A0EC9 for ; Fri, 11 Dec 2020 12:41:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 cfbBK1o4N3ZR for ; Fri, 11 Dec 2020 12:41:32 -0800 (PST)
Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 6A2583A0EC7 for ; Fri, 11 Dec 2020 12:41:32 -0800 (PST)
Received: by mail-pj1-x1032.google.com with SMTP id lj6so1359456pjb.0 for ; Fri, 11 Dec 2020 12:41:32 -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=Oc+5UC8pTmPRJ3LeGcfyZdk2LDRmWNJ//VikTO9v5w8=; b=ZF/1CXimQr1mpJ4LW2L3G7pTUshPzzNrE5d04qM1dzG8cOdz0bCnbpzMbDsyoK0uPr iiCkHTfCIl/+ziwvGlnWPVGvlFXNe7vPa01oLYaASQCg+HPcyLrSLBZIB9iVZn62gLT1 QAqxyTLLuWE20GwFgQFLzy2tzm21oYLYqrK8HtJd7UAs6/YBgUbOuEsxSXHIpl22xdRZ 7ogPa6DVdLu7GJnOMPBYWFWLSJbPnTCWohiuTb0YGM7QntJjdFU7EIyRptPYGeLnLqeE AVIffS1cS58B5AXMyo8LxzZoPG8KktbcRXacB4uiHJlj34RJ9TPM+bnRfQFj98324dkt tbmg==
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=Oc+5UC8pTmPRJ3LeGcfyZdk2LDRmWNJ//VikTO9v5w8=; b=k9Z+c6pad/OttIfTXyYuJ2FODY9PZfbk5cgj94cH4JL4CSQojDrH043yLHV25SbRCr o3lsFVMHrdg0RzC3dQ1UfWjg4tdvI8HOITsj2aTrlSncqRB9qZEmUR/tFy0OjYQHu4xY nSu8G8zrcxc7ck6fTPv8rbstW3dbgilBxAzP+yXI2pOEJXN67fXHb9WAEHm7Dv4fRLoG Qfyr73xosNtxc8R3h+IIMXr56QK9CSayOpud3sMRdUhon8ESbCbxOHib/JMKdhYrs9Us mt7dWfV2XC37LpqM7L6FmsxLaIuGGmOAMWsJ9vZBfVM0NRm0CZ86U+sTirml8VWOQxIP JylA==
X-Gm-Message-State: AOAM530Lg3YhjyF8OCahsETm8ayUtth4sxws3mHSI+3fr5I80NlJnyuY Di9bOLp7tNTtsqmTT0yuIiQ3ALwSZZ3y9VEQMUE=
X-Google-Smtp-Source: ABdhPJzaqVBQHEXUrxEGmmBMlkLInzWbdugmxa1SPJjEmhILN1US6RYCIy+p/7u3YRlAUBcKqWlqtof9JQgMdhdBFHM=
X-Received: by 2002:a17:902:be02:b029:da:c6c9:c9db with SMTP id r2-20020a170902be02b02900dac6c9c9dbmr12419092pls.69.1607719291820; Fri, 11 Dec 2020 12:41:31 -0800 (PST)
MIME-Version: 1.0
References:   <44EBF4BD-7560-492B-A061-CC9CCB848D08@vigilsec.com>
In-Reply-To: <44EBF4BD-7560-492B-A061-CC9CCB848D08@vigilsec.com>
From: Lijun Liao 
Date: Fri, 11 Dec 2020 21:41:20 +0100
Message-ID: 
To: Russ Housley 
Cc: "Brockhaus, Hendrik" , "spasm@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000499db405b63651ec"
Archived-At: 
Subject: Re: [lamps] Mail regarding draft-ietf-lamps-cmp-updates
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, 11 Dec 2020 20:41:34 -0000

--000000000000499db405b63651ec
Content-Type: text/plain; charset="UTF-8"

When we have done things like this in CMS, we say when encryptedValue is
> used, the version MUST be X, and when envelopedData is used, the version
> MUST be x+1.  This allows an unsupported version error instead of a bad
> format.
>
> Russ
>
> This solution helps the client to determine whether it can parse the
received response. And in my opinion should also be implemented. Otherwise
the client has to parse (almost) the whole received response before it
detects the unsupported feature.

The request should also contain information, e.g. different version
numbers,  indicating the client's capabilities, namely whether it can parse
the envelopedData choice or not.

Lijun

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




When we have done things like this in CMS, we say when encryptedValue is us=
ed, the version MUST be X, and when envelopedData is used, the version MUST=
 be x+1.=C2=A0 This allows an unsupported version error instead of a bad fo=
rmat.



Russ



This solution helps the client to determine whether=
 it can parse the received response. And in my opinion should also be imple=
mented. Otherwise the client has to parse (almost) the whole received respo=
nse before it detects the unsupported feature.

The=
 request should also contain information, e.g. different version numbers,=
=C2=A0 indicating the client's capabilities, namely whether it can pars=
e the envelopedData choice or not. 

Lijun


--000000000000499db405b63651ec--


From hans.aschauer@siemens.com  Fri Dec 11 08:13:16 2020
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 920973A0CEC for ; Fri, 11 Dec 2020 08:13:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level: 
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 g5A4k-5vsYzn for ; Fri, 11 Dec 2020 08:13:14 -0800 (PST)
Received: from gw-eagle2.siemens.com (gw-eagle2.siemens.com [194.138.20.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FB873A0CEA for ; Fri, 11 Dec 2020 08:13:14 -0800 (PST)
Received: from mail1.dc4ca.siemens.de (mail1.dc4ca.siemens.de [139.25.224.78]) by gw-eagle2.siemens.com (Postfix) with ESMTPS id 82D55468008 for ; Fri, 11 Dec 2020 17:13:12 +0100 (CET)
Received: from DEMCHDC8A2A.ad011.siemens.net (demchdc8a2a.ad011.siemens.net [139.25.226.108]) by mail1.dc4ca.siemens.de (Postfix) with ESMTPS id 7F04E179C8595 for ; Fri, 11 Dec 2020 17:13:12 +0100 (CET)
Received: from DEMCHDC8A0A.ad011.siemens.net (139.25.226.106) by DEMCHDC8A2A.ad011.siemens.net (139.25.226.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 11 Dec 2020 17:13:12 +0100
Received: from DEMCHDC8A0A.ad011.siemens.net ([139.25.226.106]) by DEMCHDC8A0A.ad011.siemens.net ([139.25.226.106]) with mapi id 15.01.2106.004;  Fri, 11 Dec 2020 17:13:12 +0100
From: "Aschauer, Hans" 
To: "spasm@ietf.org" 
CC: "Brockhaus, Hendrik" 
Thread-Topic: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
Thread-Index: AdbP1vUvVELByOIgQcuXfkvcmNywKA==
Date: Fri, 11 Dec 2020 16:13:11 +0000
Message-ID: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-12-11T16:12:51Z;  MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=020ce3d3-b7f0-4250-9c4b-7f1d33d3db3d; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
x-originating-ip: [144.145.220.66]
x-tm-snts-smtp: A6CD5EEE28419A85419F5A65EFB9292439444CFEA072E6534B8B6F7B3F7DA4B52000:8
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01EC_01D6CFE0.E5F68290"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Dec 2020 06:54:44 -0000

------=_NextPart_000_01EC_01D6CFE0.E5F68290
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Hendrik and Jonathan,
>
> Have you had a chance to review the new draft, and do you believe your
> concerns have been adequately addressed?
>
> -Tim

Hello,

After discussing the topics internally with Hendrik, there are some =
concerns left:

1. Iteration count:

 NEW:

      iterationCount identifies the number of times the hash is applied
      during the key computation process.  The iterationCount MUST be a
      least 10,000 [NISTSP800-63B].  There is a trade off between
      protection of the password from attacks and the time spent by the
      server processing the iterations.

Please note that the cited NIST publication does *not* say that =
iteration count must be at least 10,000. Actually, it states:

    Therefore, the iteration count SHOULD be as large as
    Verification server performance will allow, typically at least =
10,000 iterations.

The difference is subtle, but important. 10,000 merely is an estimate on =
what typical servers will be able to process. However, the important =
part is "SHOULD be as large as [...] performance will allow". This is =
due to the fact that even much higher iteration counts will not prevent =
an attacker from breaking a low-entropy password in an offline attack. =
NIST also knows this, and for this reason they continue:

    In addition, verifiers SHOULD perform an additional iteration of a =
key
    derivation function using a salt value that is secret and known only =
to
    the verifier.

However, the secret salt is not an option in the use case discussed here =
(it can only be used for storing password verifiers, not for password =
based key generation).

So IMHO it is not ok to cite the NIST SP in order to recommend 10,000 =
iterations as an acceptable minimum.

[[[
Let me just explain why this iteration count of 10,000 should be =
considered insecure.

Assume that the password has an entropy of 35 bits (*), and you use an =
iteration count of 10,000. Further assume that the attacker has an ASIC =
based hash machine, similar to one used for Bitcoin mining, with a hash =
rate of 14 Thash/second, i.e. 14e12 hashes per second (commercially =
available for USD 3000).

The time it takes to break the password is then

    t_pwd =3D 2^35 * 10,000 hashes / 14e12 hashes per second =3D 25 =
seconds

I would assume that this is a realistic threat, even for online attacks.

On the other hand, a typical server CPU can calculate about 10-100 M =
hashes per second, i.e. 1e7 to 1e8 hashes per second. Allowing for a =
password verification time of one second, this allows for an iteration =
count of 10,000,000 to 100,000,000. This is the number you should choose =
according to the NIST recommendation. Note that this choice will make =
online attacks difficult.

(*) The entropy of a typical password (chosen by a human) is difficult =
to assess. There is a paper from 2007 by Florencio et al [1] which =
calculates 40.5 bits as _mean_ entropy, but also newer research [2] =
which shows that 50% of real-world passwords can be broken with less =
than 150,000,000 trials, indicating a much lower _median_ entropy (27 =
bits).

[1] Florencio, Dinei; Herley, Cormac (May 8, 2007). =
http://research.microsoft.com/pubs/74164/www2007.pdf, Proceeds of the =
International World Wide Web Conference Committee

[2] Dell=92Amico, Matteo & Michiardi, Pietro & Roudier, Yves. (2010). =
Password Strength: An Empirical Analysis. Proceedings of INFOCOM 2010. 1 =
- 9. 10.1109/INFCOM.2010.5461951.
]]]



2. One-time passwords

NEW:
     The password used
      to compute this MAC SHOULD NOT be used for any other purpose.

Please note that while a password should in general be used for only a =
single purpose, due to the weakness of the password based MAC, in the =
use case under consideration it should really be used only *once*. This =
is the only way to thwart offline attacks.

I would suggest to use the formulation: "The password used to compute =
this MAC SHOULD be used only once."

3. Security Considerations:

I would cite a different paper: Pathirana, Amila & Halgamuge, Malka & =
Syed, Ali: "Energy Efficient Bitcoin Mining to Maximize the Mining =
Profit: Using Data from 119 Bitcoin Mining Hardware Setups", =
International Conference on Advances in Business Management and =
Information Technology Istanbul, Turkey (2019).


Best regards,
Hans



Mit freundlichen Gr=FC=DFen
Dr. Hans Aschauer

Siemens AG
Corporate Technology
Research in Digitalization and Automation
Security for Embedded Systems
CT RDA CST SES-DE
Otto-Hahn-Ring 6
81739 M=FCnchen, Deutschland
Tel.: +49 89 636-633706
Fax: +49 89 636-48000
mailto:hans.aschauer@siemens.com

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim Hagemann =
Snabe; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Klaus Helmrich, =
Cedrik Neike, Ralf P. Thomas; Sitz der Gesellschaft: Berlin und =
M=FCnchen, Deutschland; Registergericht: Berlin Charlottenburg, HRB =
12300, M=FCnchen, HRB 6684; WEEE-Reg.-Nr. DE 23691322

------=_NextPart_000_01EC_01D6CFE0.E5F68290
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIrDDCCBWAw
ggNIoAMCAQICFC71mwIop9t6/9Wjqe69A6DPEmodMA0GCSqGSIb3DQEBCwUAMEgxCzAJBgNVBAYT
AkJNMRkwFwYDVQQKExBRdW9WYWRpcyBMaW1pdGVkMR4wHAYDVQQDExVRdW9WYWRpcyBSb290IENB
IDMgRzMwHhcNMTIwMTEyMjAyNjMyWhcNNDIwMTEyMjAyNjMyWjBIMQswCQYDVQQGEwJCTTEZMBcG
A1UEChMQUXVvVmFkaXMgTGltaXRlZDEeMBwGA1UEAxMVUXVvVmFkaXMgUm9vdCBDQSAzIEczMIIC
IjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAs8sOEGeO6hSXpzIqClY2f2hMx7NvOiMUkf8Z
f6XKrO6zdp166Ysbq2sx2/oLU0yvxaUaeTyKTP+s3yXeTtmCMgtE3srbjKyjbhaDO6ZkSzKJ+xYW
OH7rQ+LTdErCYgpzCt1Js1fSsAqFnXE83qPLwDLzATkgQxs10VOzse7Fk2mCPha1KEah3uqJCe1D
uAVGiob1WUe+G28BIRC5/anSKMoQOQnKEzbPnK2tQHR5KwI/NP/6IGl90+5h9bqz5zDQNyOGcmFF
KUhZaG93pi6BvgdNb6/OxEUTkRRwBo8fn/iHabEO78OJGevqHGH8emyK3NYDC54muhLd1FQ5qyaj
M+p1gdotzQ9P5APR7xWXG2uQxQKQk2YCIbFH3ouaSoC5VY+1oi/A1jNn2n7Ep7QEROtH++ZYufcM
8HsrscBwKcNAYi07SGncIzxI63sJealt2qgwmM+AcgOIpltGrnJ5fAgDIWWut+EcpbEqojHeZgT3
wHTocd7/PVnMliYSi4WVVxqra3ULRD0RKDx7Ybfij2dP5ew8TGCAaVc4HgFbjVXox9/AzHcjNEl1
fPaYEest3u1BLhQFAn/g/iDrNecRrCLOVz3eyTBtEAOFzfH/jBa1wbI+iGxgf5BPlff2La0BOQcE
+nWAfb9JUO3vycR8HOuAftu20N0T/snTnNeyl6kCAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAO
BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFMYX0Lyo6gJD8hsGmV0rkCC515zkMA0GCSqGSIb3DQEB
CwUAA4ICAQA0YdlWtRKHVU3dozUxRrukB3K8X2Fi6KX7CzexPLaz+imdfwL1pMmok7d6cShpj3Ph
UpDa1b465bd2alaAId9d5uk6nuU+9qJpxyoKsBhH3CBwfVKjPll8wbrJyBVAYcpy1nCs0rfwHOSG
KfDO72hj0LUgihVhmn6GmLTJwnb7zLowFsyjYcZ0E+Vr76MV6gP+E4tk5NPB0uiE+0nREE15Zuuq
/fSNMR5wFK3c3mcTTIEVYby32ZF3cRmBYLvwWKW1nAv3jyJVJ8BLAW07mQ3UHZtjZy/Q7g3KZryU
T6at7fzuY6xXP2Ulz7KGj9AI/7h2FG7e5Sfsq3i1U7m2P+gg+dKovmFGyoeMhPP58aBomyIegSab
EASRccAGH9yg07lWp+OYLX+Dnd+MK5wyjjKU8AE8IiqfQ8Iuw5g5Bzh7/F4AQh/zMiZ5g4T25fDB
URLACx4EIwxUpUwvScVK0bZuYA1r/GuLhSRkt4kOqyVHWzzPfkm9x+kKxtr3fg4XCNNIl9BxkvAP
OT40ahx92PIirrtp9DO0pkhV0Q8OJujstgstp4U1zf1ZyJ/RzT5aKTS5PYTOsWXUWZGRVnUhwXee
+XrhYJ3TrQQY9HzrXpOPU0oiKfhIKz5Nhqxbf8sGmVlg2FhllY1E0fd/fid/fa6A9QdMtj6ccVSZ
BEv9WPmY9DCCBo8wggR3oAMCAQICFAwhY6RJJP+3/NtnWs3K7nIIzKlaMA0GCSqGSIb3DQEBCwUA
MEgxCzAJBgNVBAYTAkJNMRkwFwYDVQQKExBRdW9WYWRpcyBMaW1pdGVkMR4wHAYDVQQDExVRdW9W
YWRpcyBSb290IENBIDMgRzMwHhcNMTYwNjA2MTQ0MzU5WhcNMzEwNjA2MTQ0MzU5WjBUMQswCQYD
VQQGEwJCTTEZMBcGA1UECgwQUXVvVmFkaXMgTGltaXRlZDEqMCgGA1UEAwwhUXVvVmFkaXMgRW50
ZXJwcmlzZSBUcnVzdCBDQSAzIEczMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAoNCv
1ryQ1OqpZNtJv8AGisKpS0o9k5UKed059lgyWkafPA3OJqrIzzCMuRw7FPvFV86kupggxkmzeM8q
E0fqY9zw1hPAZOQgByfrm/7dNHmLRnqW1L0JNjIdBgoZTsGBBxRSoSEWzZoC72BpBw7ZGrqlzoAb
XV0pgYBQtbOJR1N1wx6x803as4owYCIlla4aTyS6hm9FohSvzu6jHXHVJlI2Kce9/wIGBXfl3yzT
yMVbzTE//cCR0tINH6tCl3hNQN6JIoTLHN0oup+oNzVOi0PnYeNq/Vu/ao9Z3PqC/+mXthv0Vs1y
u8FExTNBbPQETpXZyHkJ3qEb8uhL6wJ8XviLM12a6fRPg1QC+PJOnQvg6M5oqyrnnxDJdASxCgJt
MuSXkFw4vmok4manVYTuRwUEQXsadUe3V9sJh9ErHDKRzQoaxvfX7uHPBFIeG+FjWRz5Lilfq8Qo
bVFVBms+UjSGjVysG/Q6y6mic7yjPkzLwKg9Zvtk2Bt4lwA8u7GDssfbvlpTwAaCsg1Itke71M4R
AqxD5mLeNMlhrFov1Du+FKKc6/IJqJ8zKzBJg1IlnUsAt+r2lScSc+bxzNaqNkJA+fteTik4Pf9o
WHzi5f91fRtPteQ4JN4CGxU4rrySZk5bSVQfiExTFMBmwGjWdHS4MREwUsViiPnFxf344SsCAwEA
AaOCAWMwggFfMA8GA1UdEwEB/wQFMAMBAf8wSQYDVR0gBEIwQDA+BgRVHSAAMDYwNAYIKwYBBQUH
AgEWKGh0dHA6Ly93d3cucXVvdmFkaXNnbG9iYWwuY29tL3JlcG9zaXRvcnkwdAYIKwYBBQUHAQEE
aDBmMCoGCCsGAQUFBzABhh5odHRwOi8vb2NzcC5xdW92YWRpc2dsb2JhbC5jb20wOAYIKwYBBQUH
MAKGLGh0dHA6Ly90cnVzdC5xdW92YWRpc2dsb2JhbC5jb20vcXZyY2EzZzMuY3J0MA4GA1UdDwEB
/wQEAwIBBjAfBgNVHSMEGDAWgBTGF9C8qOoCQ/IbBpldK5Agudec5DA7BgNVHR8ENDAyMDCgLqAs
hipodHRwOi8vY3JsLnF1b3ZhZGlzZ2xvYmFsLmNvbS9xdnJjYTNnMy5jcmwwHQYDVR0OBBYEFPAW
YCKYNYkvhvzN2YccDWNVbTpHMA0GCSqGSIb3DQEBCwUAA4ICAQAncLpsrqvYETml16YEiJki9snc
HkFCcar3Ch81JpW8oYAPmk6e7jTB3HNe9q1ZbLLqtjvaULfBKtiBNtc2HBor4URI7N2aEix7NOIE
j/JjQe+4uxDIZh4AmI3m+4DX313PUQrJHTQg2wRZeYbsmxoZpye7eXtVcz2frDY1oJjV3F6fc/DV
CQaD2ZJt3/Au57SZDfeBB0knKv4WzknDJ/ZWgybaLku1vgMw/da90eKlNIOj2Dzp00GisGUUe0uA
tR4FTJvwiT2dWoi53+k8XXy7qK9N5GKbWUo+PO1wrBtrBcWBxuJINyfiq8O3rixWmYqaM4LUBlfT
Ng13mPZgc/ybfnmJ1r/MgwxpxcWWZntAKhOFBcmfvefw3jJ/jRUsaP2KIkeXkw8xqjUI7KHFJnHb
bStbpsj3i+I8YmYz41bA5Xt4fw7s89+5u1Z9i0yRguCWR5RxJJGea/DtLw2lrFIBMC/FLcOu8FjZ
EUpCzvIDWcaFPgpOfSXyEGI4Fy4TdAr7mx7JajrEfB9g31xgobiPfDBYLC5JfLOCcq4qYdwnkTns
mjJaLCzpA0j+KWP9NotwJLaXfYZg4SCcUzXYYcQSxqW2XiIfT6xePU+J2j9J0mGkzAIYUr0cuKqc
7MPXbORk67hGX6c9YamqEvehe8ZMh7q+ARFbJCwnAxVikEcKSTCCB1AwggU4oAMCAQICBGsj4iUw
DQYJKoZIhvcNAQELBQAwgZ4xCzAJBgNVBAYTAkRFMQ8wDQYDVQQIDAZCYXllcm4xETAPBgNVBAcM
CE11ZW5jaGVuMRAwDgYDVQQKDAdTaWVtZW5zMREwDwYDVQQFEwhaWlpaWlpBMzEdMBsGA1UECwwU
U2llbWVucyBUcnVzdCBDZW50ZXIxJzAlBgNVBAMMHlNpZW1lbnMgSXNzdWluZyBDQSBFRSBFbmMg
MjAxNjAeFw0xODAyMDIwODExNDlaFw0yMTAyMDIwODExNDlaMF8xETAPBgNVBAUTCFowMDNCRUha
MQ0wCwYDVQQqDARIYW5zMREwDwYDVQQEDAhBc2NoYXVlcjEQMA4GA1UECgwHU2llbWVuczEWMBQG
A1UEAwwNQXNjaGF1ZXIgSGFuczCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALQZ9xrT
Yaj8TruNfKMQO8jjyhG+UvDdYRwCiF9XI0ZkYPh+n5AIlUf+t7vXeXNYMf/sR/5V54uXJvx0wJqM
MFiEDuu37lzL3bqf0tNFNWOeBlh+Umo94tcF6HEUeSJLVJQ8wU67f8i6teztGk4TFK4fArv7oVRL
utItWrUbJjngKk2wrKhmkiDV5DZdC2+ejAiJZeB1Qc66Xec0QqyTHsRKRHtQfBVAC2PDjF007ffR
qDHa0WmZcZFJJGlGp7mbyfiUGfBN5eEZ/BsJWcasvQp6ElJMYP6m5zDqgF8DhlC6xOU5sngJr0F9
rBgw6gTaIp0+UV4j0xHeYd+KulyACQ0CAwEAAaOCAtIwggLOMIIBBAYIKwYBBQUHAQEEgfcwgfQw
MgYIKwYBBQUHMAKGJmh0dHA6Ly9haC5zaWVtZW5zLmNvbS9wa2k/WlpaWlpaQTMuY3J0MEEGCCsG
AQUFBzAChjVsZGFwOi8vYWwuc2llbWVucy5uZXQvQ049WlpaWlpaQTMsTD1QS0k/Y0FDZXJ0aWZp
Y2F0ZTBJBggrBgEFBQcwAoY9bGRhcDovL2FsLnNpZW1lbnMuY29tL0NOPVpaWlpaWkEzLG89VHJ1
c3RjZW50ZXI/Y0FDZXJ0aWZpY2F0ZTAwBggrBgEFBQcwAYYkaHR0cDovL29jc3AucGtpLXNlcnZp
Y2VzLnNpZW1lbnMuY29tMB8GA1UdIwQYMBaAFKGrLG6gevDTwk3qH/EeIYr8DK3vMAwGA1UdEwEB
/wQCMAAwRQYDVR0gBD4wPDA6Bg0rBgEEAaFpBwICAwEDMCkwJwYIKwYBBQUHAgEWG2h0dHA6Ly93
d3cuc2llbWVucy5jb20vcGtpLzCBygYDVR0fBIHCMIG/MIG8oIG5oIG2hiZodHRwOi8vY2guc2ll
bWVucy5jb20vcGtpP1paWlpaWkEzLmNybIZBbGRhcDovL2NsLnNpZW1lbnMubmV0L0NOPVpaWlpa
WkEzLEw9UEtJP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3SGSWxkYXA6Ly9jbC5zaWVtZW5zLmNv
bS9DTj1aWlpaWlpBMyxvPVRydXN0Y2VudGVyP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3QwLAYD
VR0lBCUwIwYIKwYBBQUHAwQGCisGAQQBgjcKAwQGCysGAQQBgjcKAwQBMA4GA1UdDwEB/wQEAwIE
MDAkBgNVHREEHTAbgRloYW5zLmFzY2hhdWVyQHNpZW1lbnMuY29tMB0GA1UdDgQWBBSJVQE75pwH
kLttcoKEz/5O8cml1jANBgkqhkiG9w0BAQsFAAOCAgEAUJz6LYc9lACcXU1QErY9ykojHQ6PjIJD
BwdP8r3eatvKrjMjNxylv6n/BTHa7D450GOddEvxIZE+NwX1k+VXTXMLbeQ2nC/XepEKTB2kLEuh
3QBleKYXzlpV8TCY2iex3G7VtXafkaR71xBleCdeTTECZQc+FaimLRO6z01K1djqW7MwLdk+Wo9y
+a9lm+233x9AZ+dDd8OKKB5gRexw/BZW8M7XO+ECO9yeZy1QH4FGkoknAfKbnVJLG/3s2jP+hXvh
Fpo6q2gI6tDwQYCZk6sEZJaymRdOo5x4mB4NFSpyXU6/go0nwfYt9RESDYuCP3WMoPXy/7cn5+KF
oFBJPTPdWx2zr53FHV48cybGhx+wYlm6zsRDsTQtuxw3S5bU5fu9WYnLCjo6YyxueF9/Oj7FUGwN
RV4iIQC7GRbVn2cmSQhr2SUQpwXdakOrwNjqiWhqDyop/vvnGD2cpRSjaRhIPLUz3oQqrhMN9Syr
x9Vw2oXzDzwOv8LCSaVn0yH2K1bwUKPTcZHKGu8y6iRIaQXoYTmQnmG6pu2wg7mFA8qWZT7bnlVD
zbaBVa5oocrxSdZkIq0Anj6GYSoIrAaS2io8wZ791/gJs9Btbztst4H9aEKSC8T2c/WlBYkRmnKT
icd2teUD0OGY6PxX2exLfChu6Boj3v+7jUSTOyzOM/cwggdoMIIFUKADAgECAhQbVduRcEpydXlX
74IPLtDneKD3BTANBgkqhkiG9w0BAQsFADBUMQswCQYDVQQGEwJCTTEZMBcGA1UECgwQUXVvVmFk
aXMgTGltaXRlZDEqMCgGA1UEAwwhUXVvVmFkaXMgRW50ZXJwcmlzZSBUcnVzdCBDQSAzIEczMB4X
DTIwMDcwODE5MzMyOVoXDTIyMDgwNDE1MzU1M1owgZ4xCzAJBgNVBAYTAkRFMQ8wDQYDVQQIDAZC
YXllcm4xETAPBgNVBAcMCE11ZW5jaGVuMRAwDgYDVQQKDAdTaWVtZW5zMREwDwYDVQQFEwhaWlpa
WlpBMzEdMBsGA1UECwwUU2llbWVucyBUcnVzdCBDZW50ZXIxJzAlBgNVBAMMHlNpZW1lbnMgSXNz
dWluZyBDQSBFRSBFbmMgMjAxNjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMs/Ys69
o8tx2KElAnyb6iMlhh3ZAmqrNn6c22qvtTK8cqStWWrCf/U7O6+djjzy3gWgvf1CzwsKJ8+e0FK/
EwL0IaqumjHCH86TqBt5OhCiCzws44SVrPeWbaA68iX2mBEoOyTzBHRC55431aimOSBmIpdJPJa9
T2pWyAIc0qAhC8TX3gXCWpPUcBGvNhnfM5/0IyZqRPVVjUN6GyYsi0Gq3Snp9mA2xa2hR8O/sN6J
HEaCpg/loWjHmrd9n0ZxnCYhwNRt/hbsexn1I9GN0FEahghMQn+KY5P8YZhuPM1OJJB7kqHsN52O
ATR2TzcHxn2/evkaF2AMYLlw9bzQ6Yy0R4tkjt/OVbdfKzu+kp+vKifGtFfUBMyVtKsR5h9Bma1h
uJB9TNpyl/XMxMOu6pG5a8VGbdBt5z1VFB1mkywedkNilsMARtYhv0C0SqhJnrRARHt/FufUvgvN
D1Djlmfe5bj5t4MCgKVnyXvtN0KeIQ0avjqBY4AQuY0EHzqQ1d8v9t8Ug5P3ufXfd/rOKbGqDcDY
4SKIJxsGeyt0o+DXFzunfpesiF+CFDfDsgQXEe+Np2Z31apPf6if/If6DXH/lHbQc77SfXa6M2fe
fl3jRYFeT96auXp/W93NyBFKF1yLstCtUyDEggAr3HmuzfEqH/z9RLMU/wrTThM7y9X/AgMBAAGj
ggHlMIIB4TASBgNVHRMBAf8ECDAGAQH/AgEAMB8GA1UdIwQYMBaAFPAWYCKYNYkvhvzN2YccDWNV
bTpHMIGBBggrBgEFBQcBAQR1MHMwOgYIKwYBBQUHMAKGLmh0dHA6Ly90cnVzdC5xdW92YWRpc2ds
b2JhbC5jb20vcXZlbnRjYTNnMy5jcnQwNQYIKwYBBQUHMAGGKWh0dHA6Ly9xdmVudGNhM2czLm9j
c3AucXVvdmFkaXNnbG9iYWwuY29tMIGJBgNVHSAEgYEwfzBGBgwrBgEEAb5YAAOOCAAwNjA0Bggr
BgEFBQcCARYoaHR0cDovL3d3dy5xdW92YWRpc2dsb2JhbC5jb20vcmVwb3NpdG9yeTA1BggrBgEE
AaFpBzApMCcGCCsGAQUFBwIBFhtodHRwOi8vd3d3LnNpZW1lbnMuY29tL3BraS8wLAYDVR0lBCUw
IwYIKwYBBQUHAwQGCysGAQQBgjcKAwQBBgorBgEEAYI3CgMEMD0GA1UdHwQ2MDQwMqAwoC6GLGh0
dHA6Ly9jcmwucXVvdmFkaXNnbG9iYWwuY29tL3F2ZW50Y2EzZzMuY3JsMB0GA1UdDgQWBBShqyxu
oHrw08JN6h/xHiGK/Ayt7zAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQELBQADggIBABWSZ4tL
/rtej0+rD6TGcmFL+IHx5JXBXT8byLonLaKcbUL+OeJ/slvdzJfTNnEASRv47j4eGu9RpHvmktXZ
2aoYSD7UGlOfxu4bBrHaCF3WAwzNDYBS2naiMFS26olACIhT8jrrjHXraDC7Js2kMoftPa3Cz5yC
3Vlhh8BbiX04ZGVDK7TVXRoH7soKGs780DmqTPC0JTLtwbl5luwR8p3BDUzHtGHgVENkP+7sJiBs
r6hPy6yrnBTFaXZKV8LkNguMQe5SGSxl/epsuoefl1QS+bF/hM8JNXdTTIEOmp1uXSRlrhlTXS/Q
xvJKy9nCy755P18GevmPmQftOyQXVUfv+BxRxIyJT9E/PgrAAK1SURccybuJB2VM9m6AR+Gj/lJK
Oe/r87SdfsnkNfHRYYDz1Dnra2Wo/q9zEoWjBUVMEp9jGo23W+xzl3FVHMAquX9dQYGJ0XA+Td++
q7LOvrIEFTJhVvhSARn3K/hVJyxHk0A4jh0QLIJA4eWN1Sl4JQUf16btcjtTeDCmTUcIW/cLhPn0
H3VMw4b1QYh+XUFnOTBrmjXSrGNE2yZ56EREyaW5GpCEmKw77rpisnB2fvLxv2pOrtherA35gSVA
cUIcNDnnd8Z2+EJfVC8dQPxvQL4LJ7yYWLl2WTqX6tBXZ4K+1YyDh9qgMoGtBO7EhnUeMIIHeTCC
BWGgAwIBAgIETBU9rjANBgkqhkiG9w0BAQsFADCBnzELMAkGA1UEBhMCREUxDzANBgNVBAgMBkJh
eWVybjERMA8GA1UEBwwITXVlbmNoZW4xEDAOBgNVBAoMB1NpZW1lbnMxETAPBgNVBAUTCFpaWlpa
WkEyMR0wGwYDVQQLDBRTaWVtZW5zIFRydXN0IENlbnRlcjEoMCYGA1UEAwwfU2llbWVucyBJc3N1
aW5nIENBIEVFIEF1dGggMjAxNjAeFw0xODAyMDIwODE3MzJaFw0yMTAyMDIwODExNDlaMF8xETAP
BgNVBAUTCFowMDNCRUhaMQ0wCwYDVQQqDARIYW5zMREwDwYDVQQEDAhBc2NoYXVlcjEQMA4GA1UE
CgwHU2llbWVuczEWMBQGA1UEAwwNQXNjaGF1ZXIgSGFuczCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBALUT7hlD3kzsTbbMaEDuqPXWt/BZbOkLdbaP18qE68DMAEWRoKWmghVKgiKt2fj7
VlFrnmIkf/5vvvP6EwpcxCb83j6ilTYOnKQJBLh7n8vgCQDEOEniKxEmaI189YJIimTpz+NgwL8t
6B8J1FMJJphHZiOfZdmwQ3n+futSWBhI529H5b0J4MzcRYvjAG7qBNRPUy+fN1nP5HBi1p+/OfEJ
KRE8UZMtA79B2z4/dhDDrzw/K3fRJ5S/EJQfhr2WrUyKkAT0t2Q0AlfITyjCn4kPzNg8GO/1VoqA
wExiXdDTSKvNXPfQQ5uso0/EpKy3lwiti3/B/HXnTWzR270TpM0CAwEAAaOCAvowggL2MB0GA1Ud
DgQWBBR6VNTKBpbBLD5u/5QaTOJISVymMzBPBgNVHREESDBGoCkGCisGAQQBgjcUAgOgGwwZaGFu
cy5hc2NoYXVlckBzaWVtZW5zLmNvbYEZaGFucy5hc2NoYXVlckBzaWVtZW5zLmNvbTAOBgNVHQ8B
Af8EBAMCB4AwKQYDVR0lBCIwIAYIKwYBBQUHAwIGCCsGAQUFBwMEBgorBgEEAYI3FAICMIHKBgNV
HR8EgcIwgb8wgbyggbmggbaGJmh0dHA6Ly9jaC5zaWVtZW5zLmNvbS9wa2k/WlpaWlpaQTIuY3Js
hkFsZGFwOi8vY2wuc2llbWVucy5uZXQvQ049WlpaWlpaQTIsTD1QS0k/Y2VydGlmaWNhdGVSZXZv
Y2F0aW9uTGlzdIZJbGRhcDovL2NsLnNpZW1lbnMuY29tL0NOPVpaWlpaWkEyLG89VHJ1c3RjZW50
ZXI/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdDBFBgNVHSAEPjA8MDoGDSsGAQQBoWkHAgIDAQEw
KTAnBggrBgEFBQcCARYbaHR0cDovL3d3dy5zaWVtZW5zLmNvbS9wa2kvMAwGA1UdEwEB/wQCMAAw
HwYDVR0jBBgwFoAUvb0qQyI9SEpXfpgxF6lwne6fqJkwggEEBggrBgEFBQcBAQSB9zCB9DAyBggr
BgEFBQcwAoYmaHR0cDovL2FoLnNpZW1lbnMuY29tL3BraT9aWlpaWlpBMi5jcnQwQQYIKwYBBQUH
MAKGNWxkYXA6Ly9hbC5zaWVtZW5zLm5ldC9DTj1aWlpaWlpBMixMPVBLST9jQUNlcnRpZmljYXRl
MEkGCCsGAQUFBzAChj1sZGFwOi8vYWwuc2llbWVucy5jb20vQ049WlpaWlpaQTIsbz1UcnVzdGNl
bnRlcj9jQUNlcnRpZmljYXRlMDAGCCsGAQUFBzABhiRodHRwOi8vb2NzcC5wa2ktc2VydmljZXMu
c2llbWVucy5jb20wDQYJKoZIhvcNAQELBQADggIBAC/tQzffClK9qk+u43+QpRRrbfyRAWBOx/+4
DIoHfbWRJHz0SQ9Ek1LTtTvmusCpyDRJU+r11lyOEJyoSg563YaWNxscnSLkPRcvcVtPuN4mW0by
d2RngNkOreZ3EK1Lu4nI4AZkkO4MUG/KvFWy84k7PR6W/w85FV7POp5HxoJusxLusMdPqJ/2oLvk
5YfsYioCJSYQlxhcmlLhs715WUAgRLiJI4sD1u/4UnHAK5hlmjMp5Z11tZXNHYQGe/hho3w2Ewn4
XabLlBoxc3TpG+QHZZ/FZ+qa78hPB81Nn9dl2aXlpcnHANq4VhD74fMzoaw/VH/1ArQdR9YUYGfc
HfdZtCNzb3c7qXQ1sDDyLGBQykgSrXT9B9IdQqvVseHLlGeIDNngAUA8t8MK0TfuIGQ3Snm47mU2
nIDAYUyATLl/h8V/UrPszTTXjO3wNsg/3iLeOrUWcLGsl6ZRm0sdreav3PHQEZ7fF2GTeLXSJqic
AvyRY/S0JHyoCP9/vmE3OQZ8rnOGXDTFzCxYan2yPzMErNXK8hjYuHwmIW2cGoyEOeowN0kcQ1Y1
N+JyAqy9X+SsKTPpwdwluYUVdUvK0cbxR0tZ5nh0tOtR07Rj1MRwRdWBtf6y2x195WE1G7iIdsU3
zqfBu8KLJC20Gbk5QSJLVXhJer1GOtpsojadx+eQMIII1DCCBrygAwIBAgIUVRmhnvTZzsP6EbWo
2MIKa+vQAKwwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCQk0xGTAXBgNVBAoMEFF1b1ZhZGlz
IExpbWl0ZWQxKjAoBgNVBAMMIVF1b1ZhZGlzIEVudGVycHJpc2UgVHJ1c3QgQ0EgMyBHMzAeFw0y
MDA3MDgxOTM0MTBaFw0yMjA4MDQxNTMzMDZaMIGfMQswCQYDVQQGEwJERTEPMA0GA1UECAwGQmF5
ZXJuMREwDwYDVQQHDAhNdWVuY2hlbjEQMA4GA1UECgwHU2llbWVuczERMA8GA1UEBRMIWlpaWlpa
QTIxHTAbBgNVBAsMFFNpZW1lbnMgVHJ1c3QgQ2VudGVyMSgwJgYDVQQDDB9TaWVtZW5zIElzc3Vp
bmcgQ0EgRUUgQXV0aCAyMDE2MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAy1aUq88D
jZYPge0vZnAr3KJHmMi0o5mphy54Xr592Vtf8u/B3TCyD+iGCYANPYUq4sG18qXcVxGadz7zeEm6
RI7jKKl3URAvzFGiYForZE0JKxwo956T/diLLpH1vHEQDbp8AjNK7aGoltZnm/Jn6IVQy9iBY0SE
lRIBhUlppS4/J2PHtKEvQVYJfkAwTtHuGpvPaesoJ8bHA0KhEZ4+/kIYQebaNDf0ltTmXd4Z8zeU
hE25d9MzoFnQUg+F01ewMfc0OsEFheKWP6dmo0MSLWARXxjI3K2RTHtJU5hxjb/+SA2wlfpqwNIA
kTECDBfqYxHReAT8PeezvzEkNZ9RrXl9qj0Cm2iZAjY1SL+asuxrGvFwEW/ZKJ2ARY/ot1cHh/I7
9srzh/jFieShVHbT6s6fyKXmkUjBOEnybUKUqcvNuOXnwEiJ/9jKT5UVBWTDxbEQucAarVNFBEf5
57o9ievbT+VAZKZ8F4tJge6jl2y19eppflresr7Xui9wekK2LYcLOF3X/MOCFq/9VyQDyE7X9KNG
tEx74V6J2QpbbRJryvavh3b0eQEtqDc65eiEaP8awqOErN8EEYh7Gdx4Um3QFcm1TBhkZTdQdLlW
v4LvIBnXiBEWRczQYEIm5wv5ZkyPwdL39Xwc72esPPBu8FtQFVcQlRdGI2t5Ywefq48CAwEAAaOC
A1AwggNMMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0jBBgwFoAU8BZgIpg1iS+G/M3ZhxwNY1Vt
OkcwgYEGCCsGAQUFBwEBBHUwczA6BggrBgEFBQcwAoYuaHR0cDovL3RydXN0LnF1b3ZhZGlzZ2xv
YmFsLmNvbS9xdmVudGNhM2czLmNydDA1BggrBgEFBQcwAYYpaHR0cDovL3F2ZW50Y2EzZzMub2Nz
cC5xdW92YWRpc2dsb2JhbC5jb20wggH2BgNVHSAEggHtMIIB6TBGBgwrBgEEAb5YAAOOCAAwNjA0
BggrBgEFBQcCARYoaHR0cDovL3d3dy5xdW92YWRpc2dsb2JhbC5jb20vcmVwb3NpdG9yeTA6Bg0r
BgEEAaFpBwICAwIBMCkwJwYIKwYBBQUHAgEWG2h0dHA6Ly93d3cuc2llbWVucy5jb20vcGtpLzA6
Bg0rBgEEAaFpBwICAwEBMCkwJwYIKwYBBQUHAgEWG2h0dHA6Ly93d3cuc2llbWVucy5jb20vcGtp
LzA6Bg0rBgEEAaFpBwICBAEBMCkwJwYIKwYBBQUHAgEWG2h0dHA6Ly93d3cuc2llbWVucy5jb20v
cGtpLzA6Bg0rBgEEAaFpBwICAwICMCkwJwYIKwYBBQUHAgEWG2h0dHA6Ly93d3cuc2llbWVucy5j
b20vcGtpLzA6Bg0rBgEEAaFpBwICAwECMCkwJwYIKwYBBQUHAgEWG2h0dHA6Ly93d3cuc2llbWVu
cy5jb20vcGtpLzA6Bg0rBgEEAaFpBwICBAECMCkwJwYIKwYBBQUHAgEWG2h0dHA6Ly93d3cuc2ll
bWVucy5jb20vcGtpLzA3BgorBgEEAaFpBwIFMCkwJwYIKwYBBQUHAgEWG2h0dHA6Ly93d3cuc2ll
bWVucy5jb20vcGtpLzApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcUAgIw
PQYDVR0fBDYwNDAyoDCgLoYsaHR0cDovL2NybC5xdW92YWRpc2dsb2JhbC5jb20vcXZlbnRjYTNn
My5jcmwwHQYDVR0OBBYEFL29KkMiPUhKV36YMRepcJ3un6iZMA4GA1UdDwEB/wQEAwIBBjANBgkq
hkiG9w0BAQsFAAOCAgEANYzkr5YnT7Nm/gBiguPkpv3AfKMGNtE0KVJEPVRwgEEYaxnCD0miXoEL
Fh3rvBynl7SZP0WEMRhhXAPnlBu3pSsOXJlqHJKxITiMGOHt9hsPvuV8vTGx6sZfw5MBNiUfTcai
SCWBDHXkMKLy4afVtjaJaZtk9yAKp6/Dx4YC7kpSRimTpsG3ihgTRzsQoyYgGwlZ9zMfm8/GNprT
tpcCL5s5JoK1xQS7QEHDD9ZWa7VH73RQxZeqdgkynLUzawwOdH+Thnb/4HKfaDqL93dH+xol2Sgx
Qrj8iZHRY4GxxX9w3vsceILY88Hu/gjajb5ygGmYy8jxAex6ALZrM+S0TI7TN3WZTfQ+sTPjebev
RVnaGi09t34u1LMXfspmPY8gkTORkSZBsuTrWdDpBuvyPLGVXbxetCrJ6V/rElUO41LITLnXf/is
kFC2sE4YqfnMJBJTykY+ZDFKl/7V3wLEnPnF46jLiDPFXgshaLYatKcS7zREHwl922/zkpYaXQJY
Q9UnG4zh/hZbHCDLML+eQw8fFDB32bpjg+UVY29txISmyBHcUcSNz199MfSaGxzboJEeETiNv8dv
Cs4fpxqGnMefEH+e5CX4B1NKqf0MLNDc5HvY5WpVAHCAmApbZ7eDLUDr/DsRCWz4MCSzHEO7u+rC
vC65thUSlEoahQNpgKExggQdMIIEGQIBATCBqDCBnzELMAkGA1UEBhMCREUxDzANBgNVBAgMBkJh
eWVybjERMA8GA1UEBwwITXVlbmNoZW4xEDAOBgNVBAoMB1NpZW1lbnMxETAPBgNVBAUTCFpaWlpa
WkEyMR0wGwYDVQQLDBRTaWVtZW5zIFRydXN0IENlbnRlcjEoMCYGA1UEAwwfU2llbWVucyBJc3N1
aW5nIENBIEVFIEF1dGggMjAxNgIETBU9rjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDEyMTExNjEzMDlaMCMGCSqGSIb3DQEJBDEWBBQX
2JDdib44xplf9psefvGyAPrbwDByBgkqhkiG9w0BCQ8xZTBjMAsGCWCGSAFlAwQBKjALBglghkgB
ZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQCATALBglghkgBZQMEAgMw
CwYJYIZIAWUDBAICMAcGBSsOAwIaMIG4BgkrBgEEAYI3EAQxgaowgacwgZ4xCzAJBgNVBAYTAkRF
MQ8wDQYDVQQIDAZCYXllcm4xETAPBgNVBAcMCE11ZW5jaGVuMRAwDgYDVQQKDAdTaWVtZW5zMREw
DwYDVQQFEwhaWlpaWlpBMzEdMBsGA1UECwwUU2llbWVucyBUcnVzdCBDZW50ZXIxJzAlBgNVBAMM
HlNpZW1lbnMgSXNzdWluZyBDQSBFRSBFbmMgMjAxNgIEayPiJTCBugYLKoZIhvcNAQkQAgsxgaqg
gacwgZ4xCzAJBgNVBAYTAkRFMQ8wDQYDVQQIDAZCYXllcm4xETAPBgNVBAcMCE11ZW5jaGVuMRAw
DgYDVQQKDAdTaWVtZW5zMREwDwYDVQQFEwhaWlpaWlpBMzEdMBsGA1UECwwUU2llbWVucyBUcnVz
dCBDZW50ZXIxJzAlBgNVBAMMHlNpZW1lbnMgSXNzdWluZyBDQSBFRSBFbmMgMjAxNgIEayPiJTAN
BgkqhkiG9w0BAQEFAASCAQB7HUxci88pG67pPS3wL/f9809yS8+SE76v4uSGoTvh+sieQff/O2M0
0T/qhs249nRZ+Oy5IyiF4BXmTSDnSJg++CC2aiZSn9QzhO3CxFgSUpIos8mMR/EdTfCqgziJyWBr
TFnvLyTHvRCqZKBIB0/xuyRyLdz/ej/eQcKkbATiZ/EF1WlL5bFr6OrERLvLjdiv5s08IhfzgbFZ
KnM3T/WNpUewUgj1yHLWqXWCotWwT0pnsuQ+THoh8qgWfzmR68+vl3p4xJV9CndTHqQdJk2lidSo
eXS/tzPGAj2TFed6dIpxttK/2Cr3XpfMHQxwrFfGRYJxlcNdt877ZUV27DyYAAAAAAAA

------=_NextPart_000_01EC_01D6CFE0.E5F68290--


From nobody Sun Dec 13 23:26:47 2020
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 792673A046B for ; Sun, 13 Dec 2020 23:26:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level: 
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=EpRk0F+r; dkim=pass (1024-bit key) header.d=primekey.com header.b=EpRk0F+r
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 mUwtiLZDoJXg for ; Sun, 13 Dec 2020 23:26:42 -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 E18C83A040B for ; Sun, 13 Dec 2020 23:26:41 -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 567DE6AA5D79 for ; Mon, 14 Dec 2020 08:26:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1607930799; bh=hJbJkdggDuVbIyb8j3CYup//+XOLckKsTZJA+kgjCb4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=EpRk0F+ryjYp06ZN0LDeoYpUvQw+JiYdGVWK5sLem9/FbETJpOY0YkPJxMYfpE1Fi Wu92tBMg2mum1z/XlZsOCmbwQbAnEAImqTxxOAXDAkYgJKLECTVqHF4ZdmAdYCZLkE O24615fEW3Jqe61A6RBwQCCX3fdrkv09WZNFdvio=
Received: from [10.11.0.17] (unknown [10.11.0.17]) (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 1C1536AA5AA5 for ; Mon, 14 Dec 2020 08:26:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1607930799; bh=hJbJkdggDuVbIyb8j3CYup//+XOLckKsTZJA+kgjCb4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=EpRk0F+ryjYp06ZN0LDeoYpUvQw+JiYdGVWK5sLem9/FbETJpOY0YkPJxMYfpE1Fi Wu92tBMg2mum1z/XlZsOCmbwQbAnEAImqTxxOAXDAkYgJKLECTVqHF4ZdmAdYCZLkE O24615fEW3Jqe61A6RBwQCCX3fdrkv09WZNFdvio=
To: spasm@ietf.org
References: 
From: Tomas Gustavsson 
Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= xsBNBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAHNMFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPsLA dwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5zsBNBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAHCwF8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw==
Message-ID: <6f0bee53-2945-025c-3edf-28fca898f7d2@primekey.com>
Date: Mon, 14 Dec 2020 08:26:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Dec 2020 07:26:45 -0000

Good notes on the affect of iterations.

Would it not make more sense to instead of focusing on iterations per
se, specify a minimum entropy required for the password? Does that not
have greater effect on security than the iteration count.

We do performance measurements for CMP and the iteration count have huge
performance impact. In real world projects we nowadays sometimes have
requirements for 100 tps certificate issuance (sometimes even more). And
what's more important latency requirements, for example <100ms per
transaction for 95% of requests. Mandating too high iteration count will
disqualify CMP with HMAC secret protection from such projects.

Not allowing too fast hashing absolutely makes sense, with a balance
that it must still be usable for real world usage.
Having a specified minimum entropy for secrets can also make sense, as
we see from other specifications.

Regards,
Tomas

On 2020-12-11 17:13, Aschauer, Hans wrote:
>> Hendrik and Jonathan,
>>
>> Have you had a chance to review the new draft, and do you believe your
>> concerns have been adequately addressed?
>>
>> -Tim
> 
> Hello,
> 
> After discussing the topics internally with Hendrik, there are some concerns left:
> 
> 1. Iteration count:
> 
>  NEW:
> 
>       iterationCount identifies the number of times the hash is applied
>       during the key computation process.  The iterationCount MUST be a
>       least 10,000 [NISTSP800-63B].  There is a trade off between
>       protection of the password from attacks and the time spent by the
>       server processing the iterations.
> 
> Please note that the cited NIST publication does *not* say that iteration count must be at least 10,000. Actually, it states:
> 
>     Therefore, the iteration count SHOULD be as large as
>     Verification server performance will allow, typically at least 10,000 iterations.
> 
> The difference is subtle, but important. 10,000 merely is an estimate on what typical servers will be able to process. However, the important part is "SHOULD be as large as [...] performance will allow". This is due to the fact that even much higher iteration counts will not prevent an attacker from breaking a low-entropy password in an offline attack. NIST also knows this, and for this reason they continue:
> 
>     In addition, verifiers SHOULD perform an additional iteration of a key
>     derivation function using a salt value that is secret and known only to
>     the verifier.
> 
> However, the secret salt is not an option in the use case discussed here (it can only be used for storing password verifiers, not for password based key generation).
> 
> So IMHO it is not ok to cite the NIST SP in order to recommend 10,000 iterations as an acceptable minimum.
> 
> [[[
> Let me just explain why this iteration count of 10,000 should be considered insecure.
> 
> Assume that the password has an entropy of 35 bits (*), and you use an iteration count of 10,000. Further assume that the attacker has an ASIC based hash machine, similar to one used for Bitcoin mining, with a hash rate of 14 Thash/second, i.e. 14e12 hashes per second (commercially available for USD 3000).
> 
> The time it takes to break the password is then
> 
>     t_pwd = 2^35 * 10,000 hashes / 14e12 hashes per second = 25 seconds
> 
> I would assume that this is a realistic threat, even for online attacks.
> 
> On the other hand, a typical server CPU can calculate about 10-100 M hashes per second, i.e. 1e7 to 1e8 hashes per second. Allowing for a password verification time of one second, this allows for an iteration count of 10,000,000 to 100,000,000. This is the number you should choose according to the NIST recommendation. Note that this choice will make online attacks difficult.
> 
> (*) The entropy of a typical password (chosen by a human) is difficult to assess. There is a paper from 2007 by Florencio et al [1] which calculates 40.5 bits as _mean_ entropy, but also newer research [2] which shows that 50% of real-world passwords can be broken with less than 150,000,000 trials, indicating a much lower _median_ entropy (27 bits).
> 
> [1] Florencio, Dinei; Herley, Cormac (May 8, 2007). http://research.microsoft.com/pubs/74164/www2007.pdf, Proceeds of the International World Wide Web Conference Committee
> 
> [2] Dell’Amico, Matteo & Michiardi, Pietro & Roudier, Yves. (2010). Password Strength: An Empirical Analysis. Proceedings of INFOCOM 2010. 1 - 9. 10.1109/INFCOM.2010.5461951.
> ]]]
> 
> 
> 
> 2. One-time passwords
> 
> NEW:
>      The password used
>       to compute this MAC SHOULD NOT be used for any other purpose.
> 
> Please note that while a password should in general be used for only a single purpose, due to the weakness of the password based MAC, in the use case under consideration it should really be used only *once*. This is the only way to thwart offline attacks.
> 
> I would suggest to use the formulation: "The password used to compute this MAC SHOULD be used only once."
> 
> 3. Security Considerations:
> 
> I would cite a different paper: Pathirana, Amila & Halgamuge, Malka & Syed, Ali: "Energy Efficient Bitcoin Mining to Maximize the Mining Profit: Using Data from 119 Bitcoin Mining Hardware Setups", International Conference on Advances in Business Management and Information Technology Istanbul, Turkey (2019).
> 
> 
> Best regards,
> Hans
> 
> 
> 
> Mit freundlichen Grüßen
> Dr. Hans Aschauer
> 
> Siemens AG
> Corporate Technology
> Research in Digitalization and Automation
> Security for Embedded Systems
> CT RDA CST SES-DE
> Otto-Hahn-Ring 6
> 81739 München, Deutschland
> Tel.: +49 89 636-633706
> Fax: +49 89 636-48000
> mailto:hans.aschauer@siemens.com
> 
> www.siemens.com/ingenuityforlife
> 
> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim Hagemann Snabe; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Klaus Helmrich, Cedrik Neike, Ralf P. Thomas; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322
> 
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
> 


From nobody Mon Dec 14 08:25:21 2020
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 BB1D53A14AB for ; Mon, 14 Dec 2020 08:25:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level: 
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[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 TxNeRrNx3rLs for ; Mon, 14 Dec 2020 08:25:17 -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 80AA13A149E for ; Mon, 14 Dec 2020 08:25:17 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DA3B8300BC1 for ; Mon, 14 Dec 2020 11:25:14 -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 DRPsFeDpD9Dx for ; Mon, 14 Dec 2020 11:25:12 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 43D18300A48; Mon, 14 Dec 2020 11:25:12 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Russ Housley 
In-Reply-To: <6f0bee53-2945-025c-3edf-28fca898f7d2@primekey.com>
Date: Mon, 14 Dec 2020 11:25:13 -0500
Cc: spasm@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2A98B48A-741E-4621-B2F1-739AC4B518D0@vigilsec.com>
References:  <6f0bee53-2945-025c-3edf-28fca898f7d2@primekey.com>
To: Tomas Gustavsson 
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Dec 2020 16:25:20 -0000

Tomas:

Tomas:

The Security Consideration already talk about entropy in the password.  =
What more needs to be said?

I think you are advocating:

      iterationCount identifies the number of times the hash is applied
      during the key computation process.  The iterationCount MUST be a
      minimum of X.  The iterationCount SHOULD be at least 10,000
      [NISTSP800-63B].  There is a trade off between protection of the
      password from attacks and the time spent by the server processing
      the iterations.

I think that X=3D100 is too low.  What number are you proposing?

Russ


> On Dec 14, 2020, at 2:26 AM, Tomas Gustavsson =
 wrote:
>=20
>=20
>=20
> Good notes on the affect of iterations.
>=20
> Would it not make more sense to instead of focusing on iterations per
> se, specify a minimum entropy required for the password? Does that not
> have greater effect on security than the iteration count.
>=20
> We do performance measurements for CMP and the iteration count have =
huge
> performance impact. In real world projects we nowadays sometimes have
> requirements for 100 tps certificate issuance (sometimes even more). =
And
> what's more important latency requirements, for example <100ms per
> transaction for 95% of requests. Mandating too high iteration count =
will
> disqualify CMP with HMAC secret protection from such projects.
>=20
> Not allowing too fast hashing absolutely makes sense, with a balance
> that it must still be usable for real world usage.
> Having a specified minimum entropy for secrets can also make sense, as
> we see from other specifications.
>=20
> Regards,
> Tomas
>=20
> On 2020-12-11 17:13, Aschauer, Hans wrote:
>>> Hendrik and Jonathan,
>>>=20
>>> Have you had a chance to review the new draft, and do you believe =
your
>>> concerns have been adequately addressed?
>>>=20
>>> -Tim
>>=20
>> Hello,
>>=20
>> After discussing the topics internally with Hendrik, there are some =
concerns left:
>>=20
>> 1. Iteration count:
>>=20
>> NEW:
>>=20
>>      iterationCount identifies the number of times the hash is =
applied
>>      during the key computation process.  The iterationCount MUST be =
a
>>      least 10,000 [NISTSP800-63B].  There is a trade off between
>>      protection of the password from attacks and the time spent by =
the
>>      server processing the iterations.
>>=20
>> Please note that the cited NIST publication does *not* say that =
iteration count must be at least 10,000. Actually, it states:
>>=20
>>    Therefore, the iteration count SHOULD be as large as
>>    Verification server performance will allow, typically at least =
10,000 iterations.
>>=20
>> The difference is subtle, but important. 10,000 merely is an estimate =
on what typical servers will be able to process. However, the important =
part is "SHOULD be as large as [...] performance will allow". This is =
due to the fact that even much higher iteration counts will not prevent =
an attacker from breaking a low-entropy password in an offline attack. =
NIST also knows this, and for this reason they continue:
>>=20
>>    In addition, verifiers SHOULD perform an additional iteration of a =
key
>>    derivation function using a salt value that is secret and known =
only to
>>    the verifier.
>>=20
>> However, the secret salt is not an option in the use case discussed =
here (it can only be used for storing password verifiers, not for =
password based key generation).
>>=20
>> So IMHO it is not ok to cite the NIST SP in order to recommend 10,000 =
iterations as an acceptable minimum.
>>=20
>> [[[
>> Let me just explain why this iteration count of 10,000 should be =
considered insecure.
>>=20
>> Assume that the password has an entropy of 35 bits (*), and you use =
an iteration count of 10,000. Further assume that the attacker has an =
ASIC based hash machine, similar to one used for Bitcoin mining, with a =
hash rate of 14 Thash/second, i.e. 14e12 hashes per second (commercially =
available for USD 3000).
>>=20
>> The time it takes to break the password is then
>>=20
>>    t_pwd =3D 2^35 * 10,000 hashes / 14e12 hashes per second =3D 25 =
seconds
>>=20
>> I would assume that this is a realistic threat, even for online =
attacks.
>>=20
>> On the other hand, a typical server CPU can calculate about 10-100 M =
hashes per second, i.e. 1e7 to 1e8 hashes per second. Allowing for a =
password verification time of one second, this allows for an iteration =
count of 10,000,000 to 100,000,000. This is the number you should choose =
according to the NIST recommendation. Note that this choice will make =
online attacks difficult.
>>=20
>> (*) The entropy of a typical password (chosen by a human) is =
difficult to assess. There is a paper from 2007 by Florencio et al [1] =
which calculates 40.5 bits as _mean_ entropy, but also newer research =
[2] which shows that 50% of real-world passwords can be broken with less =
than 150,000,000 trials, indicating a much lower _median_ entropy (27 =
bits).
>>=20
>> [1] Florencio, Dinei; Herley, Cormac (May 8, 2007). =
http://research.microsoft.com/pubs/74164/www2007.pdf, Proceeds of the =
International World Wide Web Conference Committee
>>=20
>> [2] Dell=E2=80=99Amico, Matteo & Michiardi, Pietro & Roudier, Yves. =
(2010). Password Strength: An Empirical Analysis. Proceedings of INFOCOM =
2010. 1 - 9. 10.1109/INFCOM.2010.5461951.
>> ]]]
>>=20
>>=20
>>=20
>> 2. One-time passwords
>>=20
>> NEW:
>>     The password used
>>      to compute this MAC SHOULD NOT be used for any other purpose.
>>=20
>> Please note that while a password should in general be used for only =
a single purpose, due to the weakness of the password based MAC, in the =
use case under consideration it should really be used only *once*. This =
is the only way to thwart offline attacks.
>>=20
>> I would suggest to use the formulation: "The password used to compute =
this MAC SHOULD be used only once."
>>=20
>> 3. Security Considerations:
>>=20
>> I would cite a different paper: Pathirana, Amila & Halgamuge, Malka & =
Syed, Ali: "Energy Efficient Bitcoin Mining to Maximize the Mining =
Profit: Using Data from 119 Bitcoin Mining Hardware Setups", =
International Conference on Advances in Business Management and =
Information Technology Istanbul, Turkey (2019).
>>=20
>>=20
>> Best regards,
>> Hans
>>=20
>>=20
>>=20
>> Mit freundlichen Gr=C3=BC=C3=9Fen
>> Dr. Hans Aschauer
>>=20
>> Siemens AG
>> Corporate Technology
>> Research in Digitalization and Automation
>> Security for Embedded Systems
>> CT RDA CST SES-DE
>> Otto-Hahn-Ring 6
>> 81739 M=C3=BCnchen, Deutschland
>> Tel.: +49 89 636-633706
>> Fax: +49 89 636-48000
>> mailto:hans.aschauer@siemens.com
>>=20
>> www.siemens.com/ingenuityforlife
>>=20
>> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim =
Hagemann Snabe; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Klaus =
Helmrich, Cedrik Neike, Ralf P. Thomas; Sitz der Gesellschaft: Berlin =
und M=C3=BCnchen, Deutschland; Registergericht: Berlin Charlottenburg, =
HRB 12300, M=C3=BCnchen, HRB 6684; WEEE-Reg.-Nr. DE 23691322
>>=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 Mon Dec 14 08:39:04 2020
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 974BC3A156F for ; Mon, 14 Dec 2020 08:39:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level: 
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=C8BZAOwt; dkim=pass (1024-bit key) header.d=primekey.com header.b=C8BZAOwt
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 iDtIbDQLh25J for ; Mon, 14 Dec 2020 08:39:00 -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 19BAB3A1568 for ; Mon, 14 Dec 2020 08:38:59 -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 893B76AA60BF for ; Mon, 14 Dec 2020 17:38:57 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1607963937; bh=4XZ34kXDIiYBP8F6NkXl9c0sGLLHnFwt27RyxF2RQoE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=C8BZAOwt01y63rDaTcF2qOiyUHYoSWtwi/VGoVgviE1RXBh2ureLf6eXE7JKxAorB XDZkK63n99O0Yj/b0u2ezj5gUX1WbSreh1FAx6V86GPt7WYJdOyUVNTJFxzY3g9Cm0 KXza9po1mNZPZFW1MX3WJcJZ3YeffPsWINufzF+8=
Received: from [10.11.0.30] (unknown [10.11.0.30]) (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 458F76AA60BE for ; Mon, 14 Dec 2020 17:38:57 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1607963937; bh=4XZ34kXDIiYBP8F6NkXl9c0sGLLHnFwt27RyxF2RQoE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=C8BZAOwt01y63rDaTcF2qOiyUHYoSWtwi/VGoVgviE1RXBh2ureLf6eXE7JKxAorB XDZkK63n99O0Yj/b0u2ezj5gUX1WbSreh1FAx6V86GPt7WYJdOyUVNTJFxzY3g9Cm0 KXza9po1mNZPZFW1MX3WJcJZ3YeffPsWINufzF+8=
To: spasm@ietf.org
References:  <6f0bee53-2945-025c-3edf-28fca898f7d2@primekey.com> <2A98B48A-741E-4621-B2F1-739AC4B518D0@vigilsec.com>
From: Tomas Gustavsson 
Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= xsBNBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAHNMFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPsLA dwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5zsBNBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAHCwF8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw==
Message-ID: 
Date: Mon, 14 Dec 2020 17:38:56 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <2A98B48A-741E-4621-B2F1-739AC4B518D0@vigilsec.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Dec 2020 16:39:04 -0000

On 2020-12-14 17:25, Russ Housley wrote:
> Tomas:
> 
> Tomas:
> 
> The Security Consideration already talk about entropy in the password.  What more needs to be said?

Right, I can see that in the draft. Are there any recommendations from
good sources as to what level of entropy to use? If we recommend number
of iterations, we should recommend minimum entropy as well, as that is
perhaps even more relevant?

> 
> I think you are advocating:
> 
>       iterationCount identifies the number of times the hash is applied
>       during the key computation process.  The iterationCount MUST be a
>       minimum of X.  The iterationCount SHOULD be at least 10,000
>       [NISTSP800-63B].  There is a trade off between protection of the
>       password from attacks and the time spent by the server processing
>       the iterations.
> 
> I think that X=100 is too low.  What number are you proposing?

The good thing is that the client can choose number of iterations, so
the client can make dynamic trade-offs. So it's actually not super
critical what exact number is specified, but it can be mentioned.
In one performance test we have we use the random number of 567
iterations. This is fast. I don't believe 1000 would be much of an
issue. 10K, probably yes for high performance issuance.

Do we want to say that conformant clients MUST use a minimum of X
(1000?). Is that the same as saying conformant servers MUST reject
iterationCount < 1000, with bad_request?


> 
> Russ
> 
> 
>> On Dec 14, 2020, at 2:26 AM, Tomas Gustavsson  wrote:
>>
>>
>>
>> Good notes on the affect of iterations.
>>
>> Would it not make more sense to instead of focusing on iterations per
>> se, specify a minimum entropy required for the password? Does that not
>> have greater effect on security than the iteration count.
>>
>> We do performance measurements for CMP and the iteration count have huge
>> performance impact. In real world projects we nowadays sometimes have
>> requirements for 100 tps certificate issuance (sometimes even more). And
>> what's more important latency requirements, for example <100ms per
>> transaction for 95% of requests. Mandating too high iteration count will
>> disqualify CMP with HMAC secret protection from such projects.
>>
>> Not allowing too fast hashing absolutely makes sense, with a balance
>> that it must still be usable for real world usage.
>> Having a specified minimum entropy for secrets can also make sense, as
>> we see from other specifications.
>>
>> Regards,
>> Tomas
>>
>> On 2020-12-11 17:13, Aschauer, Hans wrote:
>>>> Hendrik and Jonathan,
>>>>
>>>> Have you had a chance to review the new draft, and do you believe your
>>>> concerns have been adequately addressed?
>>>>
>>>> -Tim
>>>
>>> Hello,
>>>
>>> After discussing the topics internally with Hendrik, there are some concerns left:
>>>
>>> 1. Iteration count:
>>>
>>> NEW:
>>>
>>>      iterationCount identifies the number of times the hash is applied
>>>      during the key computation process.  The iterationCount MUST be a
>>>      least 10,000 [NISTSP800-63B].  There is a trade off between
>>>      protection of the password from attacks and the time spent by the
>>>      server processing the iterations.
>>>
>>> Please note that the cited NIST publication does *not* say that iteration count must be at least 10,000. Actually, it states:
>>>
>>>    Therefore, the iteration count SHOULD be as large as
>>>    Verification server performance will allow, typically at least 10,000 iterations.
>>>
>>> The difference is subtle, but important. 10,000 merely is an estimate on what typical servers will be able to process. However, the important part is "SHOULD be as large as [...] performance will allow". This is due to the fact that even much higher iteration counts will not prevent an attacker from breaking a low-entropy password in an offline attack. NIST also knows this, and for this reason they continue:
>>>
>>>    In addition, verifiers SHOULD perform an additional iteration of a key
>>>    derivation function using a salt value that is secret and known only to
>>>    the verifier.
>>>
>>> However, the secret salt is not an option in the use case discussed here (it can only be used for storing password verifiers, not for password based key generation).
>>>
>>> So IMHO it is not ok to cite the NIST SP in order to recommend 10,000 iterations as an acceptable minimum.
>>>
>>> [[[
>>> Let me just explain why this iteration count of 10,000 should be considered insecure.
>>>
>>> Assume that the password has an entropy of 35 bits (*), and you use an iteration count of 10,000. Further assume that the attacker has an ASIC based hash machine, similar to one used for Bitcoin mining, with a hash rate of 14 Thash/second, i.e. 14e12 hashes per second (commercially available for USD 3000).
>>>
>>> The time it takes to break the password is then
>>>
>>>    t_pwd = 2^35 * 10,000 hashes / 14e12 hashes per second = 25 seconds
>>>
>>> I would assume that this is a realistic threat, even for online attacks.
>>>
>>> On the other hand, a typical server CPU can calculate about 10-100 M hashes per second, i.e. 1e7 to 1e8 hashes per second. Allowing for a password verification time of one second, this allows for an iteration count of 10,000,000 to 100,000,000. This is the number you should choose according to the NIST recommendation. Note that this choice will make online attacks difficult.
>>>
>>> (*) The entropy of a typical password (chosen by a human) is difficult to assess. There is a paper from 2007 by Florencio et al [1] which calculates 40.5 bits as _mean_ entropy, but also newer research [2] which shows that 50% of real-world passwords can be broken with less than 150,000,000 trials, indicating a much lower _median_ entropy (27 bits).
>>>
>>> [1] Florencio, Dinei; Herley, Cormac (May 8, 2007). http://research.microsoft.com/pubs/74164/www2007.pdf, Proceeds of the International World Wide Web Conference Committee
>>>
>>> [2] Dell’Amico, Matteo & Michiardi, Pietro & Roudier, Yves. (2010). Password Strength: An Empirical Analysis. Proceedings of INFOCOM 2010. 1 - 9. 10.1109/INFCOM.2010.5461951.
>>> ]]]
>>>
>>>
>>>
>>> 2. One-time passwords
>>>
>>> NEW:
>>>     The password used
>>>      to compute this MAC SHOULD NOT be used for any other purpose.
>>>
>>> Please note that while a password should in general be used for only a single purpose, due to the weakness of the password based MAC, in the use case under consideration it should really be used only *once*. This is the only way to thwart offline attacks.
>>>
>>> I would suggest to use the formulation: "The password used to compute this MAC SHOULD be used only once."
>>>
>>> 3. Security Considerations:
>>>
>>> I would cite a different paper: Pathirana, Amila & Halgamuge, Malka & Syed, Ali: "Energy Efficient Bitcoin Mining to Maximize the Mining Profit: Using Data from 119 Bitcoin Mining Hardware Setups", International Conference on Advances in Business Management and Information Technology Istanbul, Turkey (2019).
>>>
>>>
>>> Best regards,
>>> Hans
>>>
>>>
>>>
>>> Mit freundlichen Grüßen
>>> Dr. Hans Aschauer
>>>
>>> Siemens AG
>>> Corporate Technology
>>> Research in Digitalization and Automation
>>> Security for Embedded Systems
>>> CT RDA CST SES-DE
>>> Otto-Hahn-Ring 6
>>> 81739 München, Deutschland
>>> Tel.: +49 89 636-633706
>>> Fax: +49 89 636-48000
>>> mailto:hans.aschauer@siemens.com
>>>
>>> www.siemens.com/ingenuityforlife
>>>
>>> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim Hagemann Snabe; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Klaus Helmrich, Cedrik Neike, Ralf P. Thomas; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322
>>>
>>>
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
> 


From nobody Mon Dec 14 09:00:37 2020
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 A204E3A08C5; Mon, 14 Dec 2020 09:00:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.187
X-Spam-Level: 
X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVoMFuXcBfac; Mon, 14 Dec 2020 09:00:23 -0800 (PST)
Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 31EAB3A08D4; Mon, 14 Dec 2020 09:00:23 -0800 (PST)
Received: by mail-ua1-x930.google.com with SMTP id s23so5679555uaq.10; Mon, 14 Dec 2020 09:00:23 -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=rQAnvdj/QI+sFitpvnp/PZr2uJQyILU7lCsbTiCEuik=; b=tkgAkrBzvSgBcchTUc5FnWdyJdp5pYCuh+9ayQRAGCi3M7ABo9WPsSxyUYt4YByZTV +aKzkiFdKGUFYCzKhlaJtfWHtsSeOFANROL+hoYcrF8Djn6o4g94M3ae8YcMypCVzoNU 9e4VnbxuEBq5otyJ8sn/MSYoHmKS7O25U1hRK7a5BSq0STfWLR754E7xTgviKVXUktTq DpTQWN/l5EBrQ4VxhSDjlkVDTY4OhI6Qqxs0NoD0S7tsxUEfRhkbO4HgJG/ue3XRLscx jcAHXwxynXaMP5Zoel1oQD0xzoPeuyrear8TsIxAcrCmwDVEVVs26/XYHKAl+1bxJfO1 bUlQ==
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=rQAnvdj/QI+sFitpvnp/PZr2uJQyILU7lCsbTiCEuik=; b=oa1veA2eX28JQvKE4PgP64lTkfGPZAWJCiTofncllmbLzKS+ZNcPh8iZPAdokfbovW 7Y5BN6OkuGdapsBEd1gmqQDmCCad+k2ANeFp16SNcoAVMQyIxkzqMFXzyaAglV1CrEzy Ls/+wkCe+q2nKfekH6jT1SvH647VT4iUdzWQI953LREF34bYHNA3K+kIeerj6KFEuyqA iN6EW0fIG66dXeSkiMsq+u7C37JIFUTQa6xcRAW0tAZ+YxtjTvW1g7P5uGEqtF0beFc6 vpJICEAWwgjWqV+CR3/Au0TptKOqCZm5/rjuYQJmA3Cv+qnIVf9SM2M75amArfQ5R1Wl gx0A==
X-Gm-Message-State: AOAM531EjkNcDjKkk2sqFGh4x8bY2V7j+LPZ1Wo5fBlj7/mpNieAT/IZ 6NCY87YAzj/j8bayLMSI3xut75875cdtVBFxuefb64kGXrs=
X-Google-Smtp-Source: ABdhPJy6l86p8FhJo2m7g8CO8G3oTyQXjLIBPoHtMwLGg8KRukBUpF6VJBV0GcI8JDRl6D0Ft0rt5dYgGrkiLOA18QI=
X-Received: by 2002:ab0:244f:: with SMTP id g15mr24281731uan.80.1607965222087;  Mon, 14 Dec 2020 09:00:22 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Daniel Migault 
Date: Mon, 14 Dec 2020 12:00:10 -0500
Message-ID: 
To: Benjamin Kaduk 
Cc: Ace Wg , SPASM , anima@ietf.org, iotops@ietf.org
Content-Type: multipart/alternative; boundary="000000000000dfb20a05b66f9357"
Archived-At: 
Subject: Re: [lamps] ACE new charter
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Dec 2020 17:00:26 -0000

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

Hi Ben,

The current proposed charter for ACE is as follows. As soon as the charter
is validated by the IESG, we will start call for adoption - at least for
the CMPv2 and EAP items.


The IESG may find useful that CMPv2 work may also be hosted in LAMPS (which
revisits CMPv2), ANIMA ( which defines CMPv2 as an alternative to EST) or
IOTOPS.

However, the discussion started in LAMPS and it was suggested ACE would be
more appropriated [1] and the current proposed charter has been circulating
on the lamps, anima, iotops mailing list and no concerns have been
raised. We will however make sure , these related WG are informed of our
progress.

EAP work has been coordinated with EMU. In any case, if the work is being
considered in ACE, we will make sure the corresponding WG will follow the
progress.

[1] https://mailarchive.ietf.org/arch/msg/spasm/uyYCf5sMcxg6xoQFcbe1sPxqVLw=
/

Yours,
Daniel

"""

The Authentication and Authorization for Constrained Environments (ace) WG
has defined a standardized solution framework for authentication and
authorization to enable authorized access to resources identified by a URI
and hosted on a resource server in constrained environments.

The access to the resource is mediated by an authorization server, which is
not considered to be constrained.

Profiles of this framework for application to security protocols commonly
used in constrained environments, including CoAP+DTLS and CoAP+OSCORE, have
also been standardized.  The Working Group is charged with maintenance of
the framework and existing profiles thereof, and may undertake work to
specify profiles of the framework for additional secure communications
protocols and for additional support services providing authorized access
to crypto keys (that are not necessarily limited to constrained endpoints,
though the focus remains on deployment in ecosystems with a substantial
portion of constrained devices).

In addition to the ongoing maintenance work, the Working Group will extend
the framework as needed for applicability to group communications, with
initial focus on (D)TLS and (Group) OSCORE as the underlying group
communication security protocols. The Working Group will standardize
procedures for requesting and distributing group keying material using the
ACE framework as well as appropriated management interfaces.

The Working Group will standardize a format for expressing authorization
information for a given authenticated principal as received from an
authorization manager.

The Working Group will examine how to use Constrained Application Protocol
(CoAP) as a transport medium for certificate enrollment protocols, such as
EST and CMPv2, as well as a transport for authentication protocols such as
EAP, and standardize as needed.
"""

Yours,
Daniel



On Sat, Dec 12, 2020 at 12:37 PM Dan Garcia Carrillo 
wrote:

> Hi Mali=C5=A1a,
>
>
> El 11/12/2020 a las 19:45, Mali=C5=A1a Vu=C4=8Dini=C4=87 escribi=C3=B3:
>
> Hi Dan,
>
>
>
> Thanks for the clarification regarding minimal-security. The points that
> you mention below, e.g. flexible authentication or the fresh generation o=
f
> the PSK, were never in the design scope of our work.
>
>
>
> While I fail to understand what exactly do you plan on using EAP-over-CoA=
P
> for, I do not object on this work being done in ACE if you are willing to
> spend cycles on it. I do have reservations on the lightweight aspect of
> this, however, considering that the sequence diagram that you depict in
> Fig. 2 in draft-marin-ace-wg-coap-eap-06 spans 3 pages and consumes 2 rou=
nd
> trips just to get things started! Surely, we can do better?
>
> Yes, we will submit an updated version of the draft.
>
> Best Regards,
>
> Dan
>
>
>
> Mali=C5=A1a
>
>
>
> *From: *Dan Garcia Carrillo  
> *Date: *Friday 11 December 2020 at 18:41
> *To: *Mali=C5=A1a Vu=C4=8Dini=C4=87 , Michael Ri=
chardson
>  , EMU WG 
> , "core@ietf.org WG (core@ietf.org)"
>   ,
> "ace@ietf.org"   
> *Cc: * 
> *Subject: *Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?)
>
>
>
> Hi Mali=C5=A1a,
>
> My intention was not to turn this conversation into a criticism of your
> work. =E2=80=9Cdeficiencies=E2=80=9D was not the most appropriate word.
>
> What we had in mind was a way of providing authentication  to the variety
> of IoT devices with different capabilities, limitations or different type=
s
> of supported credentials. A way of doing that is to provide different
> authentication methods. Since in IoT there are different technologies we
> looked for a link-layer independent solution. Additionally, since some
> technologies are very constrained, we needed a very constrained protocol =
to
> carry out the process.
>
> EAP provides flexible authentication, and it has EAP Key Management
> Framework which is well specified and working for many years, from which
> you can generate generate a fresh pre-shared key (MSK) dynamically. This =
is
> even possible if you do not want to interact with AAA infrastructures
> running EAP in standalone mode.  Having said this, another thing that we
> looked into was to give support to large scale deployments. We can ease
> this process with EAP and its interaction with a AAA infrastructure, whic=
h
> gains relevance in Industrial IoT and 5G.
>
> All these characteristics can be provided by the use of EAP, if we of
> course have a lightweight EAP lower layer to transport EAP from the IoT
> device. Then we considered the usage of CoAP as EAP lower-layer.
>
> In this sense, we saw minimal security did not fit our view (no potential
> interaction with AAA , flexible authentication, fresh generation of PSK).
> In fact,  the provisioning of the PSK was out of scope.
>
> At some level, we could even consider the work complementary. EAP over
> CoAP could be a way of providing the PSK for the work of minimal security=
.
>
>
> Best Regards,
> Dan.
>
> El 10/12/2020 a las 18:43, Mali=C5=A1a Vu=C4=8Dini=C4=87 escribi=C3=B3:
>
> Hi Dan,
>
>
>
> Could you be more specific on the point below, what deficiencies do you
> have in mind?
>
>
>
> Mali=C5=A1a
>
>
>
> *From: *core   on behalf of
> Dan Garcia  
> *Date: *Thursday 10 December 2020 at 10:06
> *To: *Michael Richardson  ,
> EMU WG  , "core@ietf.org WG (core@ietf.org)"
>   ,
> "ace@ietf.org"   
> *Subject: *Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?)
>
>
>
> As you comment , draft-ietf-6tisch-minimal-security - offers minimal
> security and has several deficiencies that can be solved by using EAP and
> AAA infrastructures.
>
> -->
>
> -->_______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>


--=20
Daniel Migault
Ericsson

On Mon, Dec 7, 2020 at 1:22 PM Daniel Migault  wrote:

> Hi,
>
> The ACE WG though you might be interested in knowing that the current ACE
> charter considers, among other things, working on CMPv2 over CoAP. The
> current charter can be found here [1].
> If you think the work should be done in another WG, please let us know
> before Friday December 11, so we can move the charter forward.
>
> Yours,
> Daniel
>
> [1]
> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXh=
oDiptY/edit?usp=3Dsharing
>
> --
> Daniel Migault
> Ericsson
>


--=20
Daniel Migault
Ericsson

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


Hi Ben,=C2=A0

The current pr=
oposed charter for ACE is as follows. As soon as the charter is validated b=
y the=C2=A0IESG, we will=C2=A0start call=C2=A0for adoption - at least for t=
he CMPv2 and EAP items.=C2=A0

The IES=
G may find useful that CMPv2 work may also be hosted in LAMPS (which revisi=
ts CMPv2), ANIMA ( which defines CMPv2 as an alternative to EST) or IOTOPS.=
=C2=A0
Howe=
ver, the discussion started in LAMPS and it was suggested ACE would be more=
 appropriated [1] and the current proposed charter has been circulating on =
the lamps, anima, iotops mailing list and no concerns have been raised.=C2=
=A0We will however make sure , these related WG are informed of our progres=
s. 

EAP work has been coordinated with EMU=
. In any case, if the work is being considered in ACE, we will make sure th=
e corresponding WG will follow the progress.

[1] https://mailarchive.ietf.org/arch/msg/s=
pasm/uyYCf5sMcxg6xoQFcbe1sPxqVLw/

=

Yours,=C2=A0
Daniel

"""
The Authentication and =
Authorization for Constrained Environments (ace) WG has defined a standardi=
zed solution framework for authentication and authorization to enable autho=
rized access to resources identified by a URI and hosted on a resource serv=
er in constrained environments.=C2=A0
The access to the resource is mediated by an authori=
zation server, which is not considered to be constrained.

Profiles of this framework f=
or application to security protocols commonly used in constrained environme=
nts, including CoAP+DTLS and CoAP+OSCORE, have also been standardized.=C2=
=A0 The Working Group is charged with maintenance of the framework and exis=
ting profiles thereof, and may undertake work to specify profiles of the fr=
amework for additional secure communications protocols and for additional support services providing authorized access t=
o crypto keys (tha=
t are not necessarily limited to constrained endpoints, though the focus re=
mains on deployment in ecosystems with a substantial portion of constrained=
 devices).

=
In addition to the ongoing maintenance work, the Working Group will extend =
the framework as needed for applicability to group communications, with ini=
tial focus on (D)TLS and (Group) OSCORE as the underlying group communicati=
on security protocols. The Working Group will standardize procedures for re=
questing and distributing group keying material using the ACE framework as =
well as appropriated management interfaces.=C2=A0

The Working Group will standardize a=
 format for expressing authorization information for a given authenticated =
principal as received from an authorization manager.=C2=A0

The Working Group will exam=
ine how to use Constrained Application Protocol (CoAP) as a transport mediu=
m for certificate enrollment protocols, such as EST and CMPv2, as well as a=
 transport for authentication protocols such as EAP, and standardize as nee=
ded.=C2=A0
"""

Yo=
urs,=C2=A0
Daniel

=C2=A0

On Sat, Dec 12, 2020 at=
 12:37 PM Dan Garcia Carrillo <ga=
rciadan@uniovi.es> wrote:


 =20
  

    
Hi Mali=C5=A1a, 

      

    


      

    
El 11/12/2020 a las 19:45, Mali=C5=A1a
      Vu=C4=8Dini=C4=87 escribi=C3=B3:

    

    

     =20
     =20
     =20
      

        
Hi Dan,

        
=C2=A0

        
Thanks for the
            clarification regarding minimal-security. The points that
            you mention below, e.g. flexible authentication or the fresh
            generation of the PSK, were never in the design scope of our
            work. 

        
=C2=A0

        
While I fail to
            understand what exactly do you plan on using EAP-over-CoAP
            for, I do not object on this work being done in ACE if you
            are willing to spend cycles on it. I do have reservations on
            the lightweight aspect of this, however, considering that
            the sequence diagram that you depict in Fig. 2 in
            draft-marin-ace-wg-coap-eap-06 spans 3 pages and consumes 2
            round trips just to get things started! Surely, we can do
            better?

      

    

    
Yes, we will submit an updated version of the draft. 

    

    
Best Regards,

    
Dan 

    

    

      

        

        
=C2=A0

        
Mali=C5=A1a

        
=C2=A0

        

          
From:
              Dan =
Garcia Carrillo
              <=
garciadan@uniovi.es>

              Date: Friday 11 December 2020 at 18:41

              To: Mali=C5=A1a Vu=C4=8Dini=C4=87 <malisa.vucinic@<=
/span>inria.fr>, Michael
              Richardson <mcr+ietf@sandelman.ca>, EMU WG
              <emu@iet=
f.org>, "core@ietf.org WG (core@ietf.org)"
              <core@i=
etf.org>, "ac=
e@ietf.org" <=
ace@ietf.org>

              Cc: <garciadan@uniovi.es>

              Subject: Re: [core] [Ace] Proposed charter for ACE
              (EAP over CoAP?)

        

        

          
=C2=A0

        

        
Hi Mali=C5=A1a, 

          

          My intention was not to turn this conversation into a
          criticism of your work. =E2=80=9Cdeficiencies=E2=80=9D was not th=
e most
          appropriate word.

          

          What we had in mind was a way of providing authentication=C2=A0 t=
o
          the variety of IoT devices with different capabilities,
          limitations or different types of supported credentials. A way
          of doing that is to provide different authentication methods.
          Since in IoT there are different technologies we looked for a
          link-layer independent solution. Additionally, since some
          technologies are very constrained, we needed a very
          constrained protocol to carry out the process.

          

          EAP provides flexible authentication, and it has EAP Key
          Management Framework which is well specified and working for
          many years, from which you can generate generate a fresh
          pre-shared key (MSK) dynamically. This is even possible if you
          do not want to interact with AAA infrastructures running EAP
          in standalone mode.=C2=A0 Having said this, another thing that we
          looked into was to give support to large scale deployments. We
          can ease this process with EAP and its interaction with a AAA
          infrastructure, which gains relevance in Industrial IoT and
          5G. 

          

          All these characteristics can be provided by the use of EAP,
          if we of course have a lightweight EAP lower layer to
          transport EAP from the IoT device. Then we considered the
          usage of CoAP as EAP lower-layer.

          

          In this sense, we saw minimal security did not fit our view
          (no potential interaction with AAA , flexible authentication,
          fresh generation of PSK).=C2=A0 In fact,=C2=A0 the provisioning o=
f the
          PSK was out of scope. 

          

          At some level, we could even consider the work complementary.
          EAP over CoAP could be a way of providing the PSK for the work
          of minimal security. 

          

          

          Best Regards,

          Dan.

        

          
El 10/12/2020
            a las 18:43, Mali=C5=A1a Vu=C4=8Dini=C4=87 escribi=C3=B3:

        

        

          
Hi Dan,

          
=C2=A0

          
Could you be more specific on the point
              below, what deficiencies do you have in mind?

          
=C2=A0

          
Mali=C5=A1a 
          
=C2=A0

          

            
From:
                co=
re <core-boun=
ces@ietf.org>
                on behalf of Dan Garcia <garciadan@uniovi.es>

                Date: Thursday 10 December 2020 at 10:06

                To: Michael Ri=
chardson
                =
<mcr+ietf@sandelman.ca>,
                EMU WG &l=
t;emu@ietf.org>, "core@ietf.org WG
                  (core@ietf.org)" <core@ietf.org>, "ace@ietf.org"
                <ace@i=
etf.org>

                Subject: Re: [core] [Ace] Proposed charter for
                ACE (EAP over CoAP?)

          

          

            
=C2=A0=


          

          
As
              you comment , draft-ietf-6tisch-minimal-security - offers
              minimal security and has several deficiencies that can be
              solved by using EAP and AAA infrastructures.=C2=A0<=
/u>

        

        
--><=
/u>

      

    

  


-->_______________________________________________

Ace mailing list

Ace@ietf.org

https://www.ietf.org/mailman/listinfo/ace




-- 
Daniel Migault
Ericsson

On Mon, Dec 7, 2020 at 1:22 PM Daniel Migault=
 <mglt.ietf@gmail.com> wro=
te:
Hi,=C2=A0

The ACE WG though you might be interested=
 in knowing that the current ACE charter considers, among other=C2=A0things=
, working on CMPv2 over CoAP. The current charter can be found here [1].=C2=
=A0
If you think the work should=C2=A0be done in another WG, plea=
se let us know before Friday December 11, so we can move the charter forwar=
d.=C2=A0

Yours,=C2=A0
Daniel=C2=A0




-- 
Daniel Migault
Ericsson


--000000000000dfb20a05b66f9357--


From nobody Mon Dec 14 11:29:03 2020
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 F14623A17CE for ; Mon, 14 Dec 2020 11:29:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCsb29jGoRGM for ; Mon, 14 Dec 2020 11:29:01 -0800 (PST)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 5A8513A17CA for ; Mon, 14 Dec 2020 11:29:01 -0800 (PST)
Received: by mail-ot1-x329.google.com with SMTP id i6so16917483otr.2 for ; Mon, 14 Dec 2020 11:29:01 -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=jAaBcWZAnfRRHaoTMKtTjviaetxkuRPy+ySCWLDaJfg=; b=GLIiO+/ovYnbE6IKx/+BPVb2S7BtpPhcWkv9/EVrnXi6YH+7df4w4S0sWG0TYPetIJ Y+pH0S3byJcHsyGXbEVlAO5Mi7FpK4PZhe/yIcbuyNUcIsK/qxqEd+ErAA64cE7FXNBn E/ye9QhyBMoFsyON5PQqOuIx93P08Fky4BGzJfgapChJ8yxdP1psnAbcxRiNG8VQZjY+ ggx1xwRLnG96caz5StAsWQUyOAUnR2919mDW8u5207cewR/c7frTPp8Qc+co+EePvFiJ G5QzrmaxK3IYh0aPhSPAXM+f0ecQGeoMgkCeDDc+TVjqgTx4ys1OWsncU/2oxoV6xACz vH3Q==
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=jAaBcWZAnfRRHaoTMKtTjviaetxkuRPy+ySCWLDaJfg=; b=PTCZsmuHi7kU1Q0vpZ4k2j88NYyHY1DhFOaHDRtIRIEm3pk/AnWm0wNZLdD7bZi1h5 WsIPUDnGl8OleVdi+3wf+tnJ6FQXSYoJnVk8QePprK5l8BKkLv2APkFtsiDEu2jAyz6O tSxJQfE7mBVuGpbKcSItlYq/qu1r4Dzcaq7Mu3u+e3sKDXMdSrt+fEpsE6jabaoBO74Y YTEL06X7d+RWGeGW8ndzk3D1A+Q/9eIKTDL4lH4T99dvleCuFMo3HZhqHtW8Ph1kOYRt UqG5b9/x6RcWT+Prvkd6kpScIJiOZMlFOQygYoPbxU7THKRoByYLfPwk8Bx+Pc1XwzLW bTUw==
X-Gm-Message-State: AOAM531QJMb6qqVsatgT58NngWxg3u+KGxvJP2oIBzF1XbQ04aETckl9 UsVcef9UnMJ1yta7JylNIR50ldN6UZ5KnXs4Jf5M1/bz4Io=
X-Google-Smtp-Source: ABdhPJzT/YIMGUlchRuSYQHXUjQXk4uEOLnY26YTK9a3j8cbWKY2ld8BpvuPZ4Hh2RiNajfQQvZ7Zc5ONb5LXQCz/Zc=
X-Received: by 2002:a05:6830:1f50:: with SMTP id u16mr20299985oth.265.1607974140553;  Mon, 14 Dec 2020 11:29:00 -0800 (PST)
MIME-Version: 1.0
References: <160762574622.28878.12700232679418693746@ietfa.amsl.com>  
In-Reply-To: 
From: Jonathan Hammell 
Date: Mon, 14 Dec 2020 14:28:49 -0500
Message-ID: 
To: Tim Hollebeek 
Cc: Russ Housley , LAMPS 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Dec 2020 19:29:03 -0000

Tim,
I have reviewed the updated draft and I am satisfied with the author's
response to my previous concerns.

Best regards,
Jonathan

On Thu, Dec 10, 2020 at 4:59 PM Tim Hollebeek
 wrote:
>
> Hendrik and Jonathan,
>
> Have you had a chance to review the new draft, and do you believe your
> concerns
> have been adequately addressed?
>
> -Tim
>
> > -----Original Message-----
> > From: Spasm  On Behalf Of Russ Housley
> > Sent: Thursday, December 10, 2020 1:46 PM
> > To: LAMPS 
> > Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
> >
> > This version addresses all og the comments that I received during the call
> for
> > adoption.
> >
> > Please review.  I think it is ready for WG Last Call.
> >
> > Russ
> >
> >
> > > On Dec 10, 2020, at 1:42 PM, internet-drafts@ietf.org wrote:
> > >
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > > This draft is a work item of the Limited Additional Mechanisms for PKIX
> and
> > SMIME WG of the IETF.
> > >
> > >        Title           : Algorithm Requirements Update to the Internet
> X.509 Public
> > Key Infrastructure Certificate Request Message Format (CRMF)
> > >        Author          : Russ Housley
> > >     Filename        : draft-ietf-lamps-crmf-update-algs-00.txt
> > >     Pages           : 7
> > >     Date            : 2020-12-10
> > >
> > > Abstract:
> > >   This document updates the cryptographic algorithm requirements for
> > >   the Password-Based Message Authentication Code in the Internet X.509
> > >   Public Key Infrastructure Certificate Request Message Format (CRMF)
> > >   specified in RFC 4211.
> > >
> > >
> > > The IETF datatracker status page for this draft is:
> > > https://datatracker.ietf.org/doc/draft-ietf-lamps-crmf-update-algs/
> > >
> > > There are also htmlized versions available at:
> > > https://tools.ietf.org/html/draft-ietf-lamps-crmf-update-algs-00
> > > https://datatracker.ietf.org/doc/html/draft-ietf-lamps-crmf-update-alg
> > > s-00
> > >
> > >
> > > Please note that it may take a couple of minutes from the time of
> > > submission until the htmlized version and diff are available at
> tools.ietf.org.
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >
> > >
> > > _______________________________________________
> > > 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
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


From nobody Mon Dec 14 13:20:45 2020
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 D4A153A12FF for ; Mon, 14 Dec 2020 13:20:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level: 
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbTUE0xwWOA2 for ; Mon, 14 Dec 2020 13:20:37 -0800 (PST)
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 E545F3A12E5 for ; Mon, 14 Dec 2020 13:20:36 -0800 (PST)
Received: by mail-pj1-x1033.google.com with SMTP id lb18so7124776pjb.5 for ; Mon, 14 Dec 2020 13:20:36 -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=k3tk1ZSCrszjClxpd2qeh5LSthsyzVb6dpgj65Nc0Ic=; b=qLJV+YLcGAYMk3D7gLW9hjwXNc9vRk9iCcpGKOmmSk7gGMVCkNTAWdOaMhVUzNDjIn H8eki3NUsKk790f8DiIvXOlljy/ZbLvJYlCx7AHbAmzFoGDy6RebaLKhTRJWJ9qGM8gd 5J4WFWG6hVQKJ3DoZxO6yqifD/GYhvdat8RbJ9rO39WNwlZZ3jgyUE40u8Hb19sheBWb 5rmcgVGk/JYXC9hbNAZh3thX7quTouLjwFmyTQHVBjw9+m68KPmbeJmMnp2zCoo85eJn sL3pO3PJScQtt7rgtqjZfpsg+ocuFy1wVd21GZFGdV+xawaW/zatYi3uPPYr7tjEvcBk RKoA==
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=k3tk1ZSCrszjClxpd2qeh5LSthsyzVb6dpgj65Nc0Ic=; b=CNIhtuq/+c1UX01apFwYk/GuTu2MoPs2RA6ueAXR2x0sP2niAsXyO/yKzf+3bNisms FHlPyGcUl8liIu2jb0Wm0Md/XxHJ7bQgkHs3/EASScoMuJWbpIb7l4S574f/5JMTzWlP 9wIrrYRlhqOagKhYNPGwC4C/NScdYFXao9gDz1mTNu0j8EjeY8RlftWRu6VUJ/D8atCi +JDdMXC2uXsfjgm9lQzDW7lipWeeLqFXvyYPDQJRzrh5Dsde2qlmXpH0Ytoo8oqreSx0 oOKVnElTrWyCa6XLIbYcJHZj6pIxOO7DWtusSo3wQjn9VQ+vy5b4nO2QSFhdwBMMdlcd vkRA==
X-Gm-Message-State: AOAM532VGhZEWeM6bnOpWNQeUkdBEbPue+aBaWi/h8bZ6En/YYyBz0wx XeqMoWLICJWLQtU9c/ZwIGWgsDKaCYJsOUEHkrOeNPg89gEL+A==
X-Google-Smtp-Source: ABdhPJxNyV0t/Vd1bD43RvtrTqgGbd+yvjXJpLwN7rnSg84ledJftsamZpLlOg+GM4TjMGr5WUTw3tLbpYIBFaWB8lg=
X-Received: by 2002:a17:90a:bb83:: with SMTP id v3mr26983049pjr.28.1607980836244;  Mon, 14 Dec 2020 13:20:36 -0800 (PST)
MIME-Version: 1.0
References:  <6f0bee53-2945-025c-3edf-28fca898f7d2@primekey.com> <2A98B48A-741E-4621-B2F1-739AC4B518D0@vigilsec.com> 
In-Reply-To: 
From: Lijun Liao 
Date: Mon, 14 Dec 2020 22:20:24 +0100
Message-ID: 
To: Tomas Gustavsson 
Cc: spasm@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008ccf0c05b67336d0"
Archived-At: 
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Dec 2020 21:20:45 -0000

--0000000000008ccf0c05b67336d0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

IterationCount 1000 is definitely too small to prevent from the well-known
password guess attacks. But with 10000 the server has an extreme
computation burden. In this sense, I do not think password based encryption
is the correct mechanism for systems with high throughput. Instead, for
such systems, one should use the symmetric key based encryption mechanism.

- Lijun

On Mon, Dec 14, 2020 at 5:39 PM Tomas Gustavsson <
tomas.gustavsson@primekey.com> wrote:

>
>
> On 2020-12-14 17:25, Russ Housley wrote:
> > Tomas:
> >
> > Tomas:
> >
> > The Security Consideration already talk about entropy in the password.
> What more needs to be said?
>
> Right, I can see that in the draft. Are there any recommendations from
> good sources as to what level of entropy to use? If we recommend number
> of iterations, we should recommend minimum entropy as well, as that is
> perhaps even more relevant?
>
> >
> > I think you are advocating:
> >
> >       iterationCount identifies the number of times the hash is applied
> >       during the key computation process.  The iterationCount MUST be a
> >       minimum of X.  The iterationCount SHOULD be at least 10,000
> >       [NISTSP800-63B].  There is a trade off between protection of the
> >       password from attacks and the time spent by the server processing
> >       the iterations.
> >
> > I think that X=3D100 is too low.  What number are you proposing?
>
> The good thing is that the client can choose number of iterations, so
> the client can make dynamic trade-offs. So it's actually not super
> critical what exact number is specified, but it can be mentioned.
> In one performance test we have we use the random number of 567
> iterations. This is fast. I don't believe 1000 would be much of an
> issue. 10K, probably yes for high performance issuance.
>
> Do we want to say that conformant clients MUST use a minimum of X
> (1000?). Is that the same as saying conformant servers MUST reject
> iterationCount < 1000, with bad_request?
>
>
> >
> > Russ
> >
> >
> >> On Dec 14, 2020, at 2:26 AM, Tomas Gustavsson <
> tomas.gustavsson@primekey.com> wrote:
> >>
> >>
> >>
> >> Good notes on the affect of iterations.
> >>
> >> Would it not make more sense to instead of focusing on iterations per
> >> se, specify a minimum entropy required for the password? Does that not
> >> have greater effect on security than the iteration count.
> >>
> >> We do performance measurements for CMP and the iteration count have hu=
ge
> >> performance impact. In real world projects we nowadays sometimes have
> >> requirements for 100 tps certificate issuance (sometimes even more). A=
nd
> >> what's more important latency requirements, for example <100ms per
> >> transaction for 95% of requests. Mandating too high iteration count wi=
ll
> >> disqualify CMP with HMAC secret protection from such projects.
> >>
> >> Not allowing too fast hashing absolutely makes sense, with a balance
> >> that it must still be usable for real world usage.
> >> Having a specified minimum entropy for secrets can also make sense, as
> >> we see from other specifications.
> >>
> >> Regards,
> >> Tomas
> >>
> >> On 2020-12-11 17:13, Aschauer, Hans wrote:
> >>>> Hendrik and Jonathan,
> >>>>
> >>>> Have you had a chance to review the new draft, and do you believe yo=
ur
> >>>> concerns have been adequately addressed?
> >>>>
> >>>> -Tim
> >>>
> >>> Hello,
> >>>
> >>> After discussing the topics internally with Hendrik, there are some
> concerns left:
> >>>
> >>> 1. Iteration count:
> >>>
> >>> NEW:
> >>>
> >>>      iterationCount identifies the number of times the hash is applie=
d
> >>>      during the key computation process.  The iterationCount MUST be =
a
> >>>      least 10,000 [NISTSP800-63B].  There is a trade off between
> >>>      protection of the password from attacks and the time spent by th=
e
> >>>      server processing the iterations.
> >>>
> >>> Please note that the cited NIST publication does *not* say that
> iteration count must be at least 10,000. Actually, it states:
> >>>
> >>>    Therefore, the iteration count SHOULD be as large as
> >>>    Verification server performance will allow, typically at least
> 10,000 iterations.
> >>>
> >>> The difference is subtle, but important. 10,000 merely is an estimate
> on what typical servers will be able to process. However, the important
> part is "SHOULD be as large as [...] performance will allow". This is due
> to the fact that even much higher iteration counts will not prevent an
> attacker from breaking a low-entropy password in an offline attack. NIST
> also knows this, and for this reason they continue:
> >>>
> >>>    In addition, verifiers SHOULD perform an additional iteration of a
> key
> >>>    derivation function using a salt value that is secret and known
> only to
> >>>    the verifier.
> >>>
> >>> However, the secret salt is not an option in the use case discussed
> here (it can only be used for storing password verifiers, not for passwor=
d
> based key generation).
> >>>
> >>> So IMHO it is not ok to cite the NIST SP in order to recommend 10,000
> iterations as an acceptable minimum.
> >>>
> >>> [[[
> >>> Let me just explain why this iteration count of 10,000 should be
> considered insecure.
> >>>
> >>> Assume that the password has an entropy of 35 bits (*), and you use a=
n
> iteration count of 10,000. Further assume that the attacker has an ASIC
> based hash machine, similar to one used for Bitcoin mining, with a hash
> rate of 14 Thash/second, i.e. 14e12 hashes per second (commercially
> available for USD 3000).
> >>>
> >>> The time it takes to break the password is then
> >>>
> >>>    t_pwd =3D 2^35 * 10,000 hashes / 14e12 hashes per second =3D 25 se=
conds
> >>>
> >>> I would assume that this is a realistic threat, even for online
> attacks.
> >>>
> >>> On the other hand, a typical server CPU can calculate about 10-100 M
> hashes per second, i.e. 1e7 to 1e8 hashes per second. Allowing for a
> password verification time of one second, this allows for an iteration
> count of 10,000,000 to 100,000,000. This is the number you should choose
> according to the NIST recommendation. Note that this choice will make
> online attacks difficult.
> >>>
> >>> (*) The entropy of a typical password (chosen by a human) is difficul=
t
> to assess. There is a paper from 2007 by Florencio et al [1] which
> calculates 40.5 bits as _mean_ entropy, but also newer research [2] which
> shows that 50% of real-world passwords can be broken with less than
> 150,000,000 trials, indicating a much lower _median_ entropy (27 bits).
> >>>
> >>> [1] Florencio, Dinei; Herley, Cormac (May 8, 2007).
> http://research.microsoft.com/pubs/74164/www2007.pdf, Proceeds of the
> International World Wide Web Conference Committee
> >>>
> >>> [2] Dell=E2=80=99Amico, Matteo & Michiardi, Pietro & Roudier, Yves. (=
2010).
> Password Strength: An Empirical Analysis. Proceedings of INFOCOM 2010. 1 =
-
> 9. 10.1109/INFCOM.2010.5461951.
> >>> ]]]
> >>>
> >>>
> >>>
> >>> 2. One-time passwords
> >>>
> >>> NEW:
> >>>     The password used
> >>>      to compute this MAC SHOULD NOT be used for any other purpose.
> >>>
> >>> Please note that while a password should in general be used for only =
a
> single purpose, due to the weakness of the password based MAC, in the use
> case under consideration it should really be used only *once*. This is th=
e
> only way to thwart offline attacks.
> >>>
> >>> I would suggest to use the formulation: "The password used to compute
> this MAC SHOULD be used only once."
> >>>
> >>> 3. Security Considerations:
> >>>
> >>> I would cite a different paper: Pathirana, Amila & Halgamuge, Malka &
> Syed, Ali: "Energy Efficient Bitcoin Mining to Maximize the Mining Profit=
:
> Using Data from 119 Bitcoin Mining Hardware Setups", International
> Conference on Advances in Business Management and Information Technology
> Istanbul, Turkey (2019).
> >>>
> >>>
> >>> Best regards,
> >>> Hans
> >>>
> >>>
> >>>
> >>> Mit freundlichen Gr=C3=BC=C3=9Fen
> >>> Dr. Hans Aschauer
> >>>
> >>> Siemens AG
> >>> Corporate Technology
> >>> Research in Digitalization and Automation
> >>> Security for Embedded Systems
> >>> CT RDA CST SES-DE
> >>> Otto-Hahn-Ring 6
> >>> 81739 M=C3=BCnchen, Deutschland
> >>> Tel.: +49 89 636-633706
> >>> Fax: +49 89 636-48000
> >>> mailto:hans.aschauer@siemens.com
> >>>
> >>> www.siemens.com/ingenuityforlife
> >>>
> >>> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim
> Hagemann Snabe; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Klaus
> Helmrich, Cedrik Neike, Ralf P. Thomas; Sitz der Gesellschaft: Berlin und
> M=C3=BCnchen, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12=
300,
> M=C3=BCnchen, HRB 6684; WEEE-Reg.-Nr. DE 23691322
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >
> > _______________________________________________
> > 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
>


--=20
Lijun Liao

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


IterationCount 1000 is definitely too sma=
ll to prevent from the well-known password guess attacks. But with 10000 th=
e server has an extreme computation burden. In this sense, I do not think p=
assword based encryption is the correct mechanism for systems with high thr=
oughput. Instead, for such systems, one should use the symmetric key based =
encryption mechanism.

- Lijun
<=
/div>
O=
n Mon, Dec 14, 2020 at 5:39 PM Tomas Gustavsson <tomas.gustavsson@primekey.com> wrote:
<=
/div>




On 2020-12-14 17:25, Russ Housley wrote:

> Tomas:

> 

> Tomas:

> 

> The Security Consideration already talk about entropy in the password.=
=C2=A0 What more needs to be said?



Right, I can see that in the draft. Are there any recommendations from

good sources as to what level of entropy to use? If we recommend number

of iterations, we should recommend minimum entropy as well, as that is

perhaps even more relevant?



> 

> I think you are advocating:

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0iterationCount identifies the number of time=
s the hash is applied

>=C2=A0 =C2=A0 =C2=A0 =C2=A0during the key computation process.=C2=A0 Th=
e iterationCount MUST be a

>=C2=A0 =C2=A0 =C2=A0 =C2=A0minimum of X.=C2=A0 The iterationCount SHOUL=
D be at least 10,000

>=C2=A0 =C2=A0 =C2=A0 =C2=A0[NISTSP800-63B].=C2=A0 There is a trade off =
between protection of the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0password from attacks and the time spent by =
the server processing

>=C2=A0 =C2=A0 =C2=A0 =C2=A0the iterations.

> 

> I think that X=3D100 is too low.=C2=A0 What number are you proposing?<=
br>


The good thing is that the client can choose number of iterations, so

the client can make dynamic trade-offs. So it's actually not super

critical what exact number is specified, but it can be mentioned.

In one performance test we have we use the random number of 567

iterations. This is fast. I don't believe 1000 would be much of an

issue. 10K, probably yes for high performance issuance.



Do we want to say that conformant clients MUST use a minimum of X

(1000?). Is that the same as saying conformant servers MUST reject

iterationCount < 1000, with bad_request?





> 

> Russ

> 

> 

>> On Dec 14, 2020, at 2:26 AM, Tomas Gustavsson <tomas.gustavsson@primeke=
y.com> wrote:

>>

>>

>>

>> Good notes on the affect of iterations.

>>

>> Would it not make more sense to instead of focusing on iterations =
per

>> se, specify a minimum entropy required for the password? Does that=
 not

>> have greater effect on security than the iteration count.

>>

>> We do performance measurements for CMP and the iteration count hav=
e huge

>> performance impact. In real world projects we nowadays sometimes h=
ave

>> requirements for 100 tps certificate issuance (sometimes even more=
). And

>> what's more important latency requirements, for example <10=
0ms per

>> transaction for 95% of requests. Mandating too high iteration coun=
t will

>> disqualify CMP with HMAC secret protection from such projects.

>>

>> Not allowing too fast hashing absolutely makes sense, with a balan=
ce

>> that it must still be usable for real world usage.

>> Having a specified minimum entropy for secrets can also make sense=
, as

>> we see from other specifications.

>>

>> Regards,

>> Tomas

>>

>> On 2020-12-11 17:13, Aschauer, Hans wrote:

>>>> Hendrik and Jonathan,

>>>>

>>>> Have you had a chance to review the new draft, and do you =
believe your

>>>> concerns have been adequately addressed?

>>>>

>>>> -Tim

>>>

>>> Hello,

>>>

>>> After discussing the topics internally with Hendrik, there are=
 some concerns left:

>>>

>>> 1. Iteration count:

>>>

>>> NEW:

>>>

>>>=C2=A0 =C2=A0 =C2=A0 iterationCount identifies the number of ti=
mes the hash is applied

>>>=C2=A0 =C2=A0 =C2=A0 during the key computation process.=C2=A0 =
The iterationCount MUST be a

>>>=C2=A0 =C2=A0 =C2=A0 least 10,000 [NISTSP800-63B].=C2=A0 There =
is a trade off between

>>>=C2=A0 =C2=A0 =C2=A0 protection of the password from attacks an=
d the time spent by the

>>>=C2=A0 =C2=A0 =C2=A0 server processing the iterations.

>>>

>>> Please note that the cited NIST publication does *not* say tha=
t iteration count must be at least 10,000. Actually, it states:

>>>

>>>=C2=A0 =C2=A0 Therefore, the iteration count SHOULD be as large=
 as

>>>=C2=A0 =C2=A0 Verification server performance will allow, typic=
ally at least 10,000 iterations.

>>>

>>> The difference is subtle, but important. 10,000 merely is an e=
stimate on what typical servers will be able to process. However, the impor=
tant part is "SHOULD be as large as [...] performance will allow"=
. This is due to the fact that even much higher iteration counts will not p=
revent an attacker from breaking a low-entropy password in an offline attac=
k. NIST also knows this, and for this reason they continue:

>>>

>>>=C2=A0 =C2=A0 In addition, verifiers SHOULD perform an addition=
al iteration of a key

>>>=C2=A0 =C2=A0 derivation function using a salt value that is se=
cret and known only to

>>>=C2=A0 =C2=A0 the verifier.

>>>

>>> However, the secret salt is not an option in the use case disc=
ussed here (it can only be used for storing password verifiers, not for pas=
sword based key generation).

>>>

>>> So IMHO it is not ok to cite the NIST SP in order to recommend=
 10,000 iterations as an acceptable minimum.

>>>

>>> [[[

>>> Let me just explain why this iteration count of 10,000 should =
be considered insecure.

>>>

>>> Assume that the password has an entropy of 35 bits (*), and yo=
u use an iteration count of 10,000. Further assume that the attacker has an=
 ASIC based hash machine, similar to one used for Bitcoin mining, with a ha=
sh rate of 14 Thash/second, i.e. 14e12 hashes per second (commercially avai=
lable for USD 3000).

>>>

>>> The time it takes to break the password is then

>>>

>>>=C2=A0 =C2=A0 t_pwd =3D 2^35 * 10,000 hashes / 14e12 hashes per=
 second =3D 25 seconds

>>>

>>> I would assume that this is a realistic threat, even for onlin=
e attacks.

>>>

>>> On the other hand, a typical server CPU can calculate about 10=
-100 M hashes per second, i.e. 1e7 to 1e8 hashes per second. Allowing for a=
 password verification time of one second, this allows for an iteration cou=
nt of 10,000,000 to 100,000,000. This is the number you should choose accor=
ding to the NIST recommendation. Note that this choice will make online att=
acks difficult.

>>>

>>> (*) The entropy of a typical password (chosen by a human) is d=
ifficult to assess. There is a paper from 2007 by Florencio et al [1] which=
 calculates 40.5 bits as _mean_ entropy, but also newer research [2] which =
shows that 50% of real-world passwords can be broken with less than 150,000=
,000 trials, indicating a much lower _median_ entropy (27 bits).

>>>

>>> [1] Florencio, Dinei; Herley, Cormac (May 8, 2007). http://research.microsoft.com/pubs/74164/www2007.pdf, =
Proceeds of the International World Wide Web Conference Committee

>>>

>>> [2] Dell=E2=80=99Amico, Matteo & Michiardi, Pietro & R=
oudier, Yves. (2010). Password Strength: An Empirical Analysis. Proceedings=
 of INFOCOM 2010. 1 - 9. 10.1109/INFCOM.2010.5461951.

>>> ]]]

>>>

>>>

>>>

>>> 2. One-time passwords

>>>

>>> NEW:

>>>=C2=A0 =C2=A0 =C2=A0The password used

>>>=C2=A0 =C2=A0 =C2=A0 to compute this MAC SHOULD NOT be used for=
 any other purpose.

>>>

>>> Please note that while a password should in general be used fo=
r only a single purpose, due to the weakness of the password based MAC, in =
the use case under consideration it should really be used only *once*. This=
 is the only way to thwart offline attacks.

>>>

>>> I would suggest to use the formulation: "The password use=
d to compute this MAC SHOULD be used only once."

>>>

>>> 3. Security Considerations:

>>>

>>> I would cite a different paper: Pathirana, Amila & Halgamu=
ge, Malka & Syed, Ali: "Energy Efficient Bitcoin Mining to Maximiz=
e the Mining Profit: Using Data from 119 Bitcoin Mining Hardware Setups&quo=
t;, International Conference on Advances in Business Management and Informa=
tion Technology Istanbul, Turkey (2019).

>>>

>>>

>>> Best regards,

>>> Hans

>>>

>>>

>>>

>>> Mit freundlichen Gr=C3=BC=C3=9Fen

>>> Dr. Hans Aschauer

>>>

>>> Siemens AG

>>> Corporate Technology

>>> Research in Digitalization and Automation

>>> Security for Embedded Systems

>>> CT RDA CST SES-DE

>>> Otto-Hahn-Ring 6

>>> 81739 M=C3=BCnchen, Deutschland

>>> Tel.: +49 89 636-633706

>>> Fax: +49 89 636-48000

>>> mailto:hans.aschauer@siemens.com

>>>

>>> www.siemens.com/ingenuityforlife

>>>

>>> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Ji=
m Hagemann Snabe; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Klaus H=
elmrich, Cedrik Neike, Ralf P. Thomas; Sitz der Gesellschaft: Berlin und M=
=C3=BCnchen, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300=
, M=C3=BCnchen, HRB 6684; WEEE-Reg.-Nr. DE 23691322

>>>

>>>

>>> _______________________________________________

>>> Spasm mailing list

>>> Spasm@ietf=
.org

>>> https://www.ietf.org/mailman/listinfo/spasm<=
/a>

>>>

>>

>> _______________________________________________

>> Spasm mailing list

>> Spasm@ietf.org=


>> https://www.ietf.org/mailman/listinfo/spasm<=
br>
> 

> _______________________________________________

> 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




-- 
Lijun Liao


--0000000000008ccf0c05b67336d0--


From nobody Mon Dec 14 13:52:05 2020
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 2067A3A153A for ; Mon, 14 Dec 2020 13:52:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[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 h7FCtpagGunU for ; Mon, 14 Dec 2020 13:52:02 -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 70E663A1536 for ; Mon, 14 Dec 2020 13:52:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CE6BD300BC1 for ; Mon, 14 Dec 2020 16:51:59 -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 U8yhZax4JOVS for ; Mon, 14 Dec 2020 16:51:58 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 6F58C300ADB; Mon, 14 Dec 2020 16:51:58 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Russ Housley 
In-Reply-To: 
Date: Mon, 14 Dec 2020 16:51:59 -0500
Cc: spasm@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0A02F029-D679-406F-B6C5-47F2AE824FBF@vigilsec.com>
References:  <6f0bee53-2945-025c-3edf-28fca898f7d2@primekey.com> <2A98B48A-741E-4621-B2F1-739AC4B518D0@vigilsec.com> 
To: Tomas Gustavsson 
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Dec 2020 21:52:04 -0000

Tomas:

>> The Security Consideration already talk about entropy in the =
password.  What more needs to be said?
>=20
> Right, I can see that in the draft. Are there any recommendations from
> good sources as to what level of entropy to use? If we recommend =
number
> of iterations, we should recommend minimum entropy as well, as that is
> perhaps even more relevant?

We could say that the password SHOULD have at least Z bits of entropy, =
but only the party that generates the password can know whether it does, =
and history has shown that the password generator may have less entropy =
than they think.

>> I think you are advocating:
>>=20
>>      iterationCount identifies the number of times the hash is =
applied
>>      during the key computation process.  The iterationCount MUST be =
a
>>      minimum of X.  The iterationCount SHOULD be at least 10,000
>>      [NISTSP800-63B].  There is a trade off between protection of the
>>      password from attacks and the time spent by the server =
processing
>>      the iterations.
>>=20
>> I think that X=3D100 is too low.  What number are you proposing?
>=20
> The good thing is that the client can choose number of iterations, so
> the client can make dynamic trade-offs. So it's actually not super
> critical what exact number is specified, but it can be mentioned.
> In one performance test we have we use the random number of 567
> iterations. This is fast. I don't believe 1000 would be much of an
> issue. 10K, probably yes for high performance issuance.
>=20
> Do we want to say that conformant clients MUST use a minimum of X
> (1000?). Is that the same as saying conformant servers MUST reject
> iterationCount < 1000, with bad_request?

The mandatory-to-implement discussion is not the place, in my opinion, =
for a statement like servers MUST reject iterationCount < 1000.

Russ


From nobody Mon Dec 14 14:55:45 2020
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 CD7E23A129C for ; Mon, 14 Dec 2020 14:55:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[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 R2yJhY3QwFwp for ; Mon, 14 Dec 2020 14:55:37 -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 50D4E3A12B7 for ; Mon, 14 Dec 2020 14:55:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E59B0300BC3 for ; Mon, 14 Dec 2020 17:55: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 2gLlnJPJZljo for ; Mon, 14 Dec 2020 17:55:31 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id D5792300A48; Mon, 14 Dec 2020 17:55:30 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Russ Housley 
In-Reply-To: 
Date: Mon, 14 Dec 2020 17:55:32 -0500
Cc: "spasm@ietf.org" , "Brockhaus, Hendrik" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: "Aschauer, Hans" 
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Dec 2020 22:55:45 -0000

Hans:

> After discussing the topics internally with Hendrik, there are some =
concerns left:
>=20
> 1. Iteration count:
>=20
> NEW:
>=20
>      iterationCount identifies the number of times the hash is applied
>      during the key computation process.  The iterationCount MUST be a
>      least 10,000 [NISTSP800-63B].  There is a trade off between
>      protection of the password from attacks and the time spent by the
>      server processing the iterations.
>=20
> Please note that the cited NIST publication does *not* say that =
iteration count must be at least 10,000. Actually, it states:
>=20
>    Therefore, the iteration count SHOULD be as large as
>    Verification server performance will allow, typically at least =
10,000 iterations.
>=20
> The difference is subtle, but important. 10,000 merely is an estimate =
on what typical servers will be able to process. However, the important =
part is "SHOULD be as large as [...] performance will allow". This is =
due to the fact that even much higher iteration counts will not prevent =
an attacker from breaking a low-entropy password in an offline attack. =
NIST also knows this, and for this reason they continue:
>=20
>    In addition, verifiers SHOULD perform an additional iteration of a =
key
>    derivation function using a salt value that is secret and known =
only to
>    the verifier.
>=20
> However, the secret salt is not an option in the use case discussed =
here (it can only be used for storing password verifiers, not for =
password based key generation).
>=20
> So IMHO it is not ok to cite the NIST SP in order to recommend 10,000 =
iterations as an acceptable minimum.
>=20
> [[[
> Let me just explain why this iteration count of 10,000 should be =
considered insecure.
>=20
> Assume that the password has an entropy of 35 bits (*), and you use an =
iteration count of 10,000. Further assume that the attacker has an ASIC =
based hash machine, similar to one used for Bitcoin mining, with a hash =
rate of 14 Thash/second, i.e. 14e12 hashes per second (commercially =
available for USD 3000).
>=20
> The time it takes to break the password is then
>=20
>    t_pwd =3D 2^35 * 10,000 hashes / 14e12 hashes per second =3D 25 =
seconds
>=20
> I would assume that this is a realistic threat, even for online =
attacks.
>=20
> On the other hand, a typical server CPU can calculate about 10-100 M =
hashes per second, i.e. 1e7 to 1e8 hashes per second. Allowing for a =
password verification time of one second, this allows for an iteration =
count of 10,000,000 to 100,000,000. This is the number you should choose =
according to the NIST recommendation. Note that this choice will make =
online attacks difficult.
>=20
> (*) The entropy of a typical password (chosen by a human) is difficult =
to assess. There is a paper from 2007 by Florencio et al [1] which =
calculates 40.5 bits as _mean_ entropy, but also newer research [2] =
which shows that 50% of real-world passwords can be broken with less =
than 150,000,000 trials, indicating a much lower _median_ entropy (27 =
bits).
>=20
> [1] Florencio, Dinei; Herley, Cormac (May 8, 2007). =
http://research.microsoft.com/pubs/74164/www2007.pdf, Proceeds of the =
International World Wide Web Conference Committee
>=20
> [2] Dell=C2=92Amico, Matteo & Michiardi, Pietro & Roudier, Yves. =
(2010). Password Strength: An Empirical Analysis. Proceedings of INFOCOM =
2010. 1 - 9. 10.1109/INFCOM.2010.5461951.
> ]]]

As we have seen from other messages on this list, some people think =
10,000 is too high.

Recall that the reason for starting this document at all was to move =
away from HMAC-SHA1, DES-MAC, and Triple-DES-MAC that are specified in =
RFC 4211.  We are replacing them with HMAC-SHA256 and AES-128-GMAC.  The =
argument offered here does not apply to both of these algorithms.  Yet, =
it is desirable that we offer MUST and SHOULD advice that is relevant to =
both.

Does something like this make sense to you?

    iterationCount identifies the number of times the hash is applied
    during the key computation process.  The iterationCount MUST be a
    minimum of X.  The iterationCount SHOULD be at least 10,000
    [NISTSP800-63B].  There is a trade off between protection of the
    password from attacks and the time spent by the server processing
    the iterations.

I think that X=3D100 is too low.  What number is a reasonable minimum =
value?


> 2. One-time passwords
>=20
> NEW:
>     The password used
>      to compute this MAC SHOULD NOT be used for any other purpose.
>=20
> Please note that while a password should in general be used for only a =
single purpose, due to the weakness of the password based MAC, in the =
use case under consideration it should really be used only *once*. This =
is the only way to thwart offline attacks.
>=20
> I would suggest to use the formulation: "The password used to compute =
this MAC SHOULD be used only once."

How would you suggest handling communications interruptions?


> 3. Security Considerations:
>=20
> I would cite a different paper: Pathirana, Amila & Halgamuge, Malka & =
Syed, Ali: "Energy Efficient Bitcoin Mining to Maximize the Mining =
Profit: Using Data from 119 Bitcoin Mining Hardware Setups", =
International Conference on Advances in Business Management and =
Information Technology Istanbul, Turkey (2019).

I will take a look at this paper.

Russ


From nobody Mon Dec 14 23:10:39 2020
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 8F8E53A0B58 for ; Mon, 14 Dec 2020 23:10:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level: 
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=GDy3I8BI; dkim=pass (1024-bit key) header.d=primekey.com header.b=GDy3I8BI
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 UY8wMREU-SUn for ; Mon, 14 Dec 2020 23:10:33 -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 9034E3A0B56 for ; Mon, 14 Dec 2020 23:10:32 -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 3FFE16AA585C; Tue, 15 Dec 2020 08:10:30 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1608016230; bh=+EcDqZxRYO+MOAmEiqcqqdea/RAsf28R0OVLWoPnkWM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=GDy3I8BIs37F7auJRs1hmQ6Whr1/jRVAs26NY8T6ABAX35agffZvb9fwPSU8I6kIq AgO3514yz0MCNSxwDvkcslBr4gcv51qR0bCiA7zVc/g8bJ/To0/04Bw9u8L99W28EJ NRW/dMRXL5fVWP7ESIKwBsrmuXFzp/6DQ7EnHVoo=
Received: from [10.11.0.15] (unknown [10.11.0.15]) (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 1CFAE6AA5668; Tue, 15 Dec 2020 08:10:30 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1608016230; bh=+EcDqZxRYO+MOAmEiqcqqdea/RAsf28R0OVLWoPnkWM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=GDy3I8BIs37F7auJRs1hmQ6Whr1/jRVAs26NY8T6ABAX35agffZvb9fwPSU8I6kIq AgO3514yz0MCNSxwDvkcslBr4gcv51qR0bCiA7zVc/g8bJ/To0/04Bw9u8L99W28EJ NRW/dMRXL5fVWP7ESIKwBsrmuXFzp/6DQ7EnHVoo=
To: Russ Housley 
Cc: spasm@ietf.org
References:  <6f0bee53-2945-025c-3edf-28fca898f7d2@primekey.com> <2A98B48A-741E-4621-B2F1-739AC4B518D0@vigilsec.com>  <0A02F029-D679-406F-B6C5-47F2AE824FBF@vigilsec.com>
From: Tomas Gustavsson 
Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= xsBNBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAHNMFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPsLA dwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5zsBNBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAHCwF8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw==
Message-ID: <9bad3ef4-bb8c-819c-29e7-f51646b221d1@primekey.com>
Date: Tue, 15 Dec 2020 08:10:29 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <0A02F029-D679-406F-B6C5-47F2AE824FBF@vigilsec.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2020 07:10:38 -0000

>> Do we want to say that conformant clients MUST use a minimum of X
>> (1000?). Is that the same as saying conformant servers MUST reject
>> iterationCount < 1000, with bad_request?
> 
> The mandatory-to-implement discussion is not the place, in my opinion, for a statement like servers MUST reject iterationCount < 1000.

I can see the difference between RFC4211 and RFC4210 for this now. I got
confused because the same definition of id-PasswordBasedMac is on both
RFC4210 and RFC4211. Creating a risk of conflict/unclarity between the
two RFCs if not updated in sync.


From nobody Mon Dec 14 23:22:31 2020
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 463133A0B87 for ; Mon, 14 Dec 2020 23:22:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level: 
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 lbiZ49GgSehi for ; Mon, 14 Dec 2020 23:22:26 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150057.outbound.protection.outlook.com [40.107.15.57]) (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 C4C4E3A0B6E for ; Mon, 14 Dec 2020 23:22:25 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KEqwAUacVJeS4N6E2Y3deGetTwbNNvdiDLevdAYGAp4fCYW/msHhKLd7jmr5npZ/hQHm/ogp7w1eRjZDnXi2OQ1mrub6aOOtvxRv4Ql+PGZGl+dWPk0cplB4E8iYTMJz2qsl264hxFw82siQ0vEw349Fbkmd4nIS/3/JDGTu1YgoHBXCxyhtBFw9x+g7VHuaEacSK6JM+tAqhpZ6zex8qZEdOTRG3BoM57fODNWLL+lIcorezC2kCkJymSjz2gez8y0+7hcnlogTpLAuDLLaYV74H0v6JyACd/K7+vNek5YIyqU3Yv9KssXg/AWVtm/nCMp7gR9CqHPn0hwrYRjKAA==
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=ZWuhUttiZXEpaPoNVRLq4b7QT97FkEDMpAOAN5WlHJk=; b=QcFXUfyi4IY8oAAr8kqG5Cw8U7y4iPpe6b/M0iYPFoaRZm+9MwlFRH1TG86+YQux32l5kn8ZFvAC86XIQHrhhh6U4ot71SRzyf5QTtiiWGqlRH/F1fV+MsIszOhE8QEQ0gxfX/LiOpsaaSApBdNhKUZg04uys2DgLYGVvsJ/iY0Yu4xYGx9oriuimLBekINGjdQPoH9gbIvEhvwDHb2izzIsyySZDmfNOYgZuBDzdF5pkFdk/23gG9NQLgsKej5S5ItgJYUS5PmJAILiE1t5dfLAJKd3wx/whuwiNSpUYL4OKmpjUIouJcH2aFCpzXk3tyCC12fcabFiz8jJBNrWsg==
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=ZWuhUttiZXEpaPoNVRLq4b7QT97FkEDMpAOAN5WlHJk=; b=Yat+bBR3Q+8r2ELRTd+LJ+RDvba16CX5cuqZn8/kzx2hes05DbIY7wzTjkMxUSM3POJ/NFGRdC0jJbCjS3gIddrDlayO+roB3WXUbHHuFwhmcGynFq3uZ1kiNmGwSI6S3e92kkm5KKZ78LEUNR7H2zKztC/BTfeJAQhKQG+nmWw=
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM9PR10MB4213.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:1cd::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.24; Tue, 15 Dec 2020 07:22:23 +0000
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69%7]) with mapi id 15.20.3654.024; Tue, 15 Dec 2020 07:22:23 +0000
From: "Brockhaus, Hendrik" 
To: Lijun Liao 
CC: Russ Housley , "spasm@ietf.org" 
Thread-Topic: Mail regarding draft-ietf-lamps-cmp-algorithms
Thread-Index: AQHW0MqJja16stmT1UK1L4/mhTvoY6n2J3ZAgAB6XgCAAApo4IAAUu4AgAAZ3wCAAKKt8A==
Date: Tue, 15 Dec 2020 07:22:23 +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: 
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-12-15T07:22:21Z;  MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=ab502099-008d-4b43-875b-217ae0225e8c; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=siemens.com;
x-originating-ip: [165.225.200.184]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 687ee572-026e-4073-b185-08d8a0ca2aa7
x-ms-traffictypediagnostic: AM9PR10MB4213:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: CBXiRzMtv0taw0IWRFuSWpnzOwWkfDYuKoDsiJekdDR9soTz/k9+dZaHY6fGxUrBvkSRJUvSN4i/0cA42QORx5//2PiwBOlNTGxR+fzBBhlap9dCXvR3YaqEAmnzEH2u95WuLfO+K1pY51qODiTwwukyFQ4dtJ0Xs52fR2p/bcUWN5ainOQWkEokjMiEViiTaGrUDMSjrRc7hLW9oSo4chca3kEOrBzm+PFE0pzAmtWa/yBpgJzEQU1nZnIp861/5vb0EVamnhrP+g1I6vsW7a9t/Iow77LaQHcHl2jpizMaWl4PPz+7m2Ogs42thqdT/RXmJX4KD5nF+GoeFxbCoaP1+JPlHL4yQ/0SuMol0bvWHH8lLCD0GOjnSzneDHLxzwqXk6iQvNHNAJ2If8bhivdN6w2ujEZGjn5LJ4TafY4Aq6LqMLHOx1KQairUUU0O3xj5lm2lTaSfnr574VuwPQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(4636009)(396003)(39860400002)(376002)(346002)(136003)(366004)(66556008)(86362001)(8936002)(8676002)(55236004)(4326008)(186003)(6506007)(9686003)(64756008)(52536014)(66476007)(53546011)(55016002)(76116006)(26005)(66946007)(66446008)(5660300002)(54906003)(71200400001)(316002)(7696005)(83080400002)(83380400001)(166002)(6916009)(478600001)(2906002)(33656002); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?GPFBBmQK7pzBg/AQti1EepVgiccpVbzqJO2w+x8UIrkdJsi7AiFKwMTVUj/6?= =?us-ascii?Q?go8WfvsscsEVDtbqfXw5PeuRL2i30IyAw8giqfyQ9s5C6i79ckw94Xfjk1iB?= =?us-ascii?Q?X+QvVY7zPyx2bV/uMrhT3VWcbrtpGU9lZpUYFaHoeuON+qWPX2SB9R++g2tS?= =?us-ascii?Q?UoMF0JFuWTu0A0qCGON7KOxso5h3D/W9+aid3n0kUUiw7xtlCuluCPBMzsaK?= =?us-ascii?Q?vhWGWrEfGMRT0ZQ/ut3jRVACOBjFEdd3Zt/TV7awRcqwowvnxrwESv3iKJq9?= =?us-ascii?Q?IUE6kjX8aDRTrpqmwxVyT5am5uqzpoFQAaaoa1uFNlZGNjTmPBbvZ97JSAq0?= =?us-ascii?Q?dr8QiOL1gm3VntJYmZ2/WQ8f2bAo8xhDFZdUCpy4QdPuJMvzNRcrBdfyMdtM?= =?us-ascii?Q?dsARptGIAHwyEUMBHrWlJ7p1s+yvcKD2B5OnUzj8TfceCntqXO9ZMOGZ3v4r?= =?us-ascii?Q?yImvkx82QxmZ0EjECriXAAuJRQJXV7NEFFBVDTqPey4RX+RhQwVnUFMIhwt+?= =?us-ascii?Q?0uKux/KRpCxhU8+ANCu6+9d1BhNScF38TTDzP4NyoA6PVVEWLgQS/GKrQ2wr?= =?us-ascii?Q?hB5Rf9Go433d/SCXD7jpg5SullVNsN1cSg6jJeWsDC8MlXb8Zi+bD3Z1AkLK?= =?us-ascii?Q?Lsc95Ec6cP6nSDQpwJxQ0rSPdnNkGkuOHuiGwRgPWOyWhe+4k9evQDFPhEPV?= =?us-ascii?Q?n8pGcOiBe6JMXiyFmie0NwRZlFHuKJMdUz7FfBdoatiJFW5kHN2uB6Dr3Loj?= =?us-ascii?Q?Ea9AuFUKFEwHch86x70iCpZ9NPIdy0SAejbreAeZe+MFqPDCeDyuQe/HreDT?= =?us-ascii?Q?We/vl4+SAwVGeVqToAGG1Lm9fL4I1xa7v9hHKKkyhYpyDpVhInsYe4EKgQ42?= =?us-ascii?Q?h2NCDTCydYMnsjA7240fHLKvwIu2zwtmr+HcSEqFUyw2TXiP93FXVa62iI2a?= =?us-ascii?Q?+XNKXDL8q1x4edj0wNTLn1/VPa9L5o8hD9BeBGWB+1xLEeevbb0RPYdul7yG?= =?us-ascii?Q?Y1tY?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM0PR10MB24188B586A77823772BCD2ECFEC60AM0PR10MB2418EURP_"
MIME-Version: 1.0
X-OriginatorOrg: siemens.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 687ee572-026e-4073-b185-08d8a0ca2aa7
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2020 07:22:23.1446 (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: Q2vBpYxk0k3ZSRPcJLCqluzSDZawEIegq6JDSQIiwthrv3bJ57akg4zBG9O2dLLs13hNUzrcI40r8JL2tty2ADYNOKbLpcdHujLaOVVIgLo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR10MB4213
Archived-At: 
Subject: Re: [lamps] Mail regarding draft-ietf-lamps-cmp-algorithms
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, 15 Dec 2020 07:22:30 -0000

--_000_AM0PR10MB24188B586A77823772BCD2ECFEC60AM0PR10MB2418EURP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Lijun

Thank you for explaining your requests.

I am open to also add SHA3 and I see your points regarding PKCS#11 support.=
 But, currently from the SHA3-family only SHAKE128 and SHAKE256 are specifi=
ed for use in X.509 and CMS. Therefore, you should rise your request to sup=
port SHA3 to the LAMPS mailing list and possibly submit a draft on this.

Thank you for the reference. I will cover RSASSA-PSS as alternative to PKCS=
#1 V1.5. I am also open to keep RSA-OAEP. As this was discussed during the =
WG meeting, you should also bring this request to the attention of the grou=
p, to get a joined decision.

Anyhow, the document dose not aim to specify an exclusive list of algorithm=
s to support. The goal is to have at least one set of algorithms as main li=
ne and one as successor. The document should also cove the most widely used=
 algorithms. As for usage in CMP, the algorithms to support in CMP implemen=
tations strongly depend on the certificates to be used by the CMP endpoints=
 for authentication and on the certificates to manage.

I copied the WG mailing list to this conversation, to bring you valuable po=
int also to their attention.
Any feedback from the group is of course welcome.

Best regards,
Hendrik

Von: Lijun Liao 
Gesendet: Montag, 14. Dezember 2020 22:09
An: Brockhaus, Hendrik (T RDA CST SEA-DE) 
Cc: Russ Housley ; draft-ietf-lamps-cmp-algorithms@ie=
tf.org
Betreff: Re: Mail regarding draft-ietf-lamps-cmp-algorithms

Another issue, in the meeting minutes of IETF 109, datatracker.ietf.org/mee=
ting/109/materials/minutes-109-lamps-00

"Current key transport algorithms is PKCS#1 V1.5 and RSAES-OAEP. Russ has
not seen RSAES-OAEP in the wild. Hendrik will remove RSAES-OAEP."

Be careful while removing RSAES-OAEP, the BSI cryptographic recommendations=
 of 2020 (https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/=
TechGuidelines/TG02102/BSI-TR-02102-1.html) deprecates the usage of PKCS#1 v1.5 for the encrypt=
ion (also for the signature), and suggests RSAES-OAEP instead.

At page 18:

"RSA with PKCS1v1.5 padding: In principle, usage of this padding format is =
encouraged
neither for encryption nor for signature applications, since RSA-OAEP respe=
ctively RSA-
PSS offer more solid theoretical security guarantees. Moreover, RSA impleme=
ntations with
PKCS1v1.5 padding turned out to be more susceptible to attacks exploiting s=
ide-channel
information or implementation errors."

And at page 38:

"Encryption and Decryption:

...
Usage of the older PKCS#1v1.5 paddings is not recommended, as in this conte=
xt variations
of the Bleichenbacher attack [17] have repeatedly turned out to be a proble=
m, see e.g. [20] for a
recent example."

- Lijun

On Mon, Dec 14, 2020 at 8:36 PM Lijun Liao > wrote:
As specified in RFC Section 10.1.6, "Key derivation algorithms convert a pa=
ssword or shared secret value into a key-encryption key", in my opinion, it=
 is the correct location to specify the HKDF to derive from shared secret. =
This is very useful in IoT areas, since it is much quicker than the PBKDF (=
no iteration is required in HKDF).

Regard SHA3, I agree that from aspect of functionality, SHAKE can replace S=
HA3 completely. But if considering the current PKCS#11 specification,  SHA3=
 is defined as the hash algorithm together with the raw signature mechanism=
 RSA, DSA and ECDSA, and is also in HMAC, HKDF,  but SHAKE only in HKDF.

Considering PKCS#11 is widely used, and currently SHA3s are the approved al=
gorithms, but shake still not, if SHA3 is excluded from the specification, =
 for a very  long time, we will keep to use only the sha2.

Please also note that the industrial / commercial CA/RA use FIPS 140 certif=
ied HSMs, and SHAKEs are not in the approved list.

So please reconsider to add the support of SHA3.

Best regards
Lijun

Brockhaus, Hendrik > schrieb am Mo., 14. Dez. 2020, 17:27:
Russ, Lijun

@Russ, is it OK to use a HKDF as keyDerivationAlgorithm in PasswordRecipien=
tInfo to solve Lijuns scenario?

@Lijun, here is the link to the meeting minutes of IETF 109, datatracker.ie=
tf.org/meeting/109/materials/minutes-109-lamps-00.
Unfortunately the discussion SHAKE vs. SHA3 is not documented in the minute=
s.
I remember the discussion, that SHAKE offers mor flexibility than SHA3, but=
 SHA3 does not offer more security than SHAKE. But I do not fully remember =
the discussion.

@Russ, can you give Lijun the background, why SHA3 is not sued for X.509 an=
d CMS, but SHAKE.

- Hendrik


Von: Lijun Liao >
Gesendet: Montag, 14. Dezember 2020 15:02
An: Brockhaus, Hendrik (T RDA CST SEA-DE) >
Cc: draft-ietf-lamps-cmp-algorithms@ietf.org
Betreff: Re: Mail regarding draft-ietf-lamps-cmp-algorithms

Dear Hendrik,

Related to the HKDF, there are Scenarios where bot CA and CMP client share =
secret other than passwords, 1) the secret is not qualified for the encrypt=
ion / decryption, e.g.  the 16 byte secret but they want to use AES 256; 2)=
 or they do not want to use the secret as direct key to protect the secret.

Related to the SHA3, could you please share the meeting notes, if permitted=
.

Best regards
Lijun

Brockhaus, Hendrik > schrieb am Mo., 14. Dez. 2020, 07:53:
Dear Lijun

Thank you very much for your review.
Currently I am preparing the next update to address the guidance from IETF1=
09.
See my comments below.


Von: Lijun Liao >
Gesendet: Samstag, 12. Dezember 2020 22:05
An: draft-ietf-lamps-cmp-algorithms@ietf.org
Betreff: Mail regarding draft-ietf-lamps-cmp-algorithms

Dear authors,

here some comments on this draft:

1. Editorial error in Section 2.1. SHA2

"The message digest algorithms SHA-224, SHA-256, SHA-384, and SHA-512
produce a 224-bit are identified by the following object identifiers
(OIDs)"

Only the SHA-224 produces 224-bit output. It is better to remove the text "=
produce a 224-bit".

[Bro] I have removed this sentence.

2. Editorial error in Section 3. Signature Algorithms

"Signature algorithm identifiers are located in ... signatureAlgorithm fiel=
d of p10cr, ..."
"Signature values are located in ... signature field of p10cr, ..."

p10cr should be corrected to CertificationRequest.

[Bro] Thank you. I will have to check this, but I think you are right. Fina=
lly the p10cr message type contains the CertificationRequest.

3. Signature algorithm
Please also consider the Ed25519 and Ed448 (see RFC 8410)

[Bro] I added them.

4. Hash algorithm in MAC, Signature algorithm and PBKDF2
Please also consider SHA3 (and SHAKE).

[Bro] After discussion at IETF109 it was decided to add SHAKE and not to ad=
d SHA3, similar to other protocols and formats like X.509 and CMS.

5. Key derivation algorithms
Please also consider HKDF.

[Bro] Currently there is only a password-based key derivation required. If =
I add symmetric key management technique, I would also need to add a symmet=
ric key based algorithm.
May be I have overlooked something. Where do you want to use the HKDF?

6. ECDH
Please consider X25519 and X448 (see RFC 8410)

[Bro] I added them.

Hendrik


--
Lijun Liao

--_000_AM0PR10MB24188B586A77823772BCD2ECFEC60AM0PR10MB2418EURP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Lijun


&nbs=
p;


Thank you for explaining your requests.


 


I am open to also add SHA3 and I see your points regarding PKCS#11 su=
pport. But, currently from the SHA3-family only SHAKE128 and SHAKE256 are s=
pecified for use in X.509 and CMS. Therefore,
 you should rise your request to support SHA3 to the LAMPS mailing list and=
 possibly submit a draft on this.


 


Thank you for the reference. I will cover RSASSA-PSS as alternative t=
o PKCS#1 V1.5. I am also open to keep RSA-OAEP. As this was discussed durin=
g the WG meeting, you should also bring
 this request to the attention of the group, to get a joined decision.=



 


Anyhow, the document dose not aim to specify an exclusive list of alg=
orithms to support. The goal is to have at least one set of algorithms as m=
ain line and one as successor. The document
 should also cove the most widely used algorithms. As for usage in CMP, the=
 algorithms to support in CMP implementations strongly depend on the certif=
icates to be used by the CMP endpoints for authentication and on the certif=
icates to manage.


 


I copied the WG mailing list to this conversation, to bring you valua=
ble point also to their attention.



Any feedback from the group is of course welcome.

 


Best regards,


Hendrik


 








Von: Lijun Liao <lijun.liao@gmail.com> =


Gesendet: Montag, 14. Dezember 2020 22:09

An: Brockhaus, Hendrik (T RDA CST SEA-DE) <hendrik.brockhaus@siem=
ens.com>

Cc: Russ Housley <housley@vigilsec.com>; draft-ietf-lamps-cmp-=
algorithms@ietf.org

Betreff: Re: Mail regarding draft-ietf-lamps-cmp-algorithms






 








Another issue, in the meeting m=
inutes of IETF 109,

datatracker.ietf.org/meeting/109/materials/minutes-109-lamps-00<=
o:p>






 






"Current key transport algorithms is PKCS#1 V1.=
5 and RSAES-OAEP. Russ has






not seen RSAES-OAEP in the wild. Hendrik will remove=
 RSAES-OAEP."






 






Be careful while removing RSAES-OAEP, the BSI crypto=
graphic recommendations of 2020 (https://www.bsi.bund.de/SharedDocs/Down=
loads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.html)
 deprecates the usage of PKCS#1 v1.5 for the encryption (also for the signa=
ture), and suggests RSAES-OAEP instead.






 








At page 18:






 






"RSA with PKCS1v1.5 padding: In principle, usag=
e of this padding format is encouraged

neither for encryption nor for signature applications, since RSA-OAEP respe=
ctively RSA-

PSS offer more solid theoretical security guarantees. Moreover, RSA impleme=
ntations with

PKCS1v1.5 padding turned out to be more susceptible to attacks exploiting s=
ide-channel

information or implementation errors."






 






And at page 38:






 






"Encryption and Decryption: 






 






...






Usage of the older PKCS#1v1.5 paddings is not recomm=
ended, as in this context variations

of the Bleichenbacher attack [17] have repeatedly turned out to be a proble=
m, see e.g. [20] for a

recent example."






 






- Lijun




 






On Mon, Dec 14, 2020 at 8:36 PM Lijun Liao <lijun.liao@gmail.com> wrote:=











As specified in RFC Section 10.1.6, "Key deriva=
tion algorithms convert a password or shared secret value into a key-encryp=
tion key", in my opinion, it is the correct location to specify the HK=
DF to derive from shared secret. This is very
 useful in IoT areas, since it is much quicker than the PBKDF (no iteration=
 is required in HKDF).






 






Regard SHA3, I agree that from aspect of functionali=
ty, SHAKE can replace SHA3 completely. But if considering the current PKCS#=
11 specification,  SHA3 is defined as the hash algorithm together=
 with the raw signature mechanism RSA, DSA and
 ECDSA, and is also in HMAC, HKDF,  but SHAKE only in HKDF. =







 






Considering PKCS#11 is widely used, and currently SH=
A3s are the approved algorithms, but shake still not, if SHA3 is excluded f=
rom the specification,  for a very  long time, we will keep to us=
e only the sha2. 






 






Please also note that the industrial / commercial CA=
/RA use FIPS 140 certified HSMs, and SHAKEs are not in the approved list.






 






So please reconsider to add the support of SHA3.






 






Best regards






Lijun






 






Brockhaus, Hendrik <hendrik.brockhaus@siemens.com>=
 schrieb am Mo., 14. Dez. 2020, 17:27:










Russ, Lijun


 


@Russ, is it OK to use a HKDF as keyDerivatio=
nAlgorithm in PasswordRecipientInfo to solve Lijuns scenario?


 


@Lijun, here is the link to the meeting minut=
es of IETF 109,

datatracker.ietf.org/meeting/109/materials/minutes-109-lamps-00.=



Unfortunately the discussion SHAKE vs. SHA3 i=
s not documented in the minutes.


I remember the discussion, that SHAKE offers =
mor flexibility than SHA3, but SHA3 does not offer more security than SHAKE=
. But I do not fully remember the discussion.


 


@Russ, can you give Lijun the background, why=
 SHA3 is not sued for X.509 and CMS, but SHAKE.


 


- Hendrik


 


 








Von: Lijun Liao <lijun.liao@gmail.com>


Gesendet: Montag, 14. Dezember 2020 15:02

An: Brockhaus, Hendrik (T RDA CST SEA-DE) <hendrik.brockhaus@siemens.com<=
/a>>

Cc: 
draft-ietf-lamps-cmp-algorithms@ietf.org

Betreff: Re: Mail regarding draft-ietf-lamps-cmp-algorithms






 






Dear Hend=
rik,




 






Related t=
o the HKDF, there are Scenarios where bot CA and CMP client share secret ot=
her than passwords, 1) the secret is not qualified
 for the encryption / decryption, e.g.  the 16 byte secret but they wa=
nt to use AES 256; 2) or they do not want to use the secret as direct key t=
o protect the secret.






 






Related t=
o the SHA3, could you please share the meeting notes, if permitted.<=
o:p>






 






Best rega=
rds






Lijun




 






Brockhaus, Hendrik <hendrik.brockhaus@siemens.com> schrieb am Mo=
., 14. Dez. 2020, 07:53:










Dear Lijun


 


Thank you very much for your review.


Currently I am preparing the next update to a=
ddress the guidance from IETF109.


See my comments below.


 


 








Von: Lijun Liao <lijun.liao@gmail.com>


Gesendet: Samstag, 12. Dezember 2020 22:05

An: 
draft-ietf-lamps-cmp-algorithms@ietf.org

Betreff: Mail regarding draft-ietf-lamps-cmp-algorithms





 




Dear authors,






 






here some comments on this draft:






 




1. Editorial error in Section 2.1. SHA2




 






"The message digest algorithms SHA-224, SHA-256, SHA-384, and=
 SHA-512






produce a 224-bit are identified by the following object identifie=
rs






(OIDs)"






 






Only the SHA-224 produces 224-bit output. It is better to remove t=
he text "produce a 224-bit".


 


[Bro] I have removed this sentence.






 






2. Editorial error in Section 3. Signature Algorithms





 






"Signature algorithm identifiers are located in ... signature=
Algorithm field of p10cr, ..."








"Signature values are located in ... signature field of p10cr=
, ..."








 






p10cr should be corrected to CertificationRequest.


 


[Bro] Thank you. I will have to check this, b=
ut I think you are right. Finally the p10cr message type contains the Certi=
ficationRequest.






 






3. Signature algorithm






Please also consider the Ed25519 and Ed448 (see RFC 8410)


 


[Bro] I added them.






 






4. Hash algorithm in MAC, Signature algorithm and PBKDF2






Please also consider SHA3 (and SHAKE).


 


[Bro] After discussion at IETF109 it was deci=
ded to add SHAKE and not to add SHA3, similar to other protocols and format=
s like X.509 and CMS.







 






5. Key derivation algorithms






Please also consider HKDF.


 


[Bro] Currently there is only a password-base=
d key derivation required. If I add symmetric key management technique, I w=
ould also need to add a symmetric key
 based algorithm.


May be I have overlooked something. Where do =
you want to use the HKDF?







 






6. ECDH






Please consider X25519 and X448 (see RFC 8410)


 


[Bro] I added them.


 


Hendrik










































-- 




Lijun Liao












--_000_AM0PR10MB24188B586A77823772BCD2ECFEC60AM0PR10MB2418EURP_--


From nobody Tue Dec 15 01:18:49 2020
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 AA3203A0EBA for ; Tue, 15 Dec 2020 01:18:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-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=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 MkcCQzxtGczu for ; Tue, 15 Dec 2020 01:18:47 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140050.outbound.protection.outlook.com [40.107.14.50]) (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 1188E3A0EAE for ; Tue, 15 Dec 2020 01:18:44 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fIr4m7qhbkp0xuTxLual8a4X2SmWf+BgYQpGVvWPYkk0i6cmlM2XnNB9l3JD7m1G1io9QxRCUS36+wUUDEsJTW5JB69Zh8/5nhHTqTx3StQj8pKKQga2O2/gql66b9QLp7AYX+eHP36gEmbkogK862mVqEC3c2LoqkP61p2erKZXQlfnFqZ1ebMKwrV35tyfOSraVmIghFXQFQ9yWzjS+tH/77C8r8VDYjHMpdANKQL2ADa9KRGWhIdi3OXSkASOjuw+mrzIEM+5It4kMRnFB254hEmRV7YcYPm9iQPalhe7m7tZ5qN0VYxHjkAuVl1DFRSom8v4rwwAA9hvXfpxKA==
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=ej9c+HpUavgi7lulURt+7pIlmnPwKgDqhcTWE3bD0yI=; b=lgUBxQ5O6xjLU471qL5U/BZicw9D0IJoSpgjcogPa/0U8BKgqued2bSUuY8HSMVQyOjewAFn5beeTwimgz1SErSmTIGGyljUq84S8pEmsJr09MRVCLtrmJkCj1cq6kdWodtR2CBbtr1vf7JVU/jqXBEIDnysgS6UeQ5f93We8jP7z+xD6SIOPvc1ntmQBnMUpNCXJh9OD/0HheC1kAikk3HIMSy2ZWtLpsM/eEsoNDLFBhfy8Ug8Kwe4KYFgqFi5Yu9WlX7E4qTypLVhVM2mH/2Nk1MONcWyOgNA3Mq1mdegKlVbKj0hzxTCoisuSlGX6ocxjcf9s00Ph4g+F7h9Zg==
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=ej9c+HpUavgi7lulURt+7pIlmnPwKgDqhcTWE3bD0yI=; b=GrCftfKj56BtTa/NQqasIYR3ZoDQdE87A9F/sRurRi3kc2T5UizgTLxmzpI5K5C8TBVv9sVlowFUHO97R+9Bi50Ib7BB2jyYnsUFYp1C/B8LAG868jWji9nZbHwaz8qEmNXMKUjHWc/7V4uw6kyRTQl8tl3y/ET/9fMl2Bk+L1Y=
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM9PR10MB4277.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:1fb::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.20; Tue, 15 Dec 2020 09:18:40 +0000
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69%7]) with mapi id 15.20.3654.024; Tue, 15 Dec 2020 09:18:40 +0000
From: "Brockhaus, Hendrik" 
To: Russ Housley 
CC: Lijun Liao , "spasm@ietf.org" 
Thread-Topic: [lamps] Mail regarding draft-ietf-lamps-cmp-updates
Thread-Index: AQHWz/G52ReRDe2aYUmX7qyUfOqxtanyRpewgAAIvICABZVWgA==
Date: Tue, 15 Dec 2020 09:18:40 +0000
Message-ID: 
References:   <44EBF4BD-7560-492B-A061-CC9CCB848D08@vigilsec.com>
In-Reply-To: <44EBF4BD-7560-492B-A061-CC9CCB848D08@vigilsec.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-12-15T09:18:39Z;  MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=e16bf9e5-ee6d-4b4c-9c5c-12afb5774cd8; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=siemens.com;
x-originating-ip: [165.225.200.184]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: e247bc94-e004-4f6e-2d4b-08d8a0da69b1
x-ms-traffictypediagnostic: AM9PR10MB4277:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: r4NdysaWAYn7wG1UZeHiyUBUX1y1HZC20VzynhQO5ufMemxXnOHrvYN1tlqJQDMFc6kHM9cUMYCW3E/AQb7a6xlowFdMwk1awaeGSlrXpbVtRGcPSWjuFvaci9VrkT1GhUOzGMD98iMe77nZcf089MLn786dkAbr1Smoq3uPFsdQ2oRj8Uz2miegymFX1OmzhzAmEdEQ4X+OAwOmKzFk0A84jjQcghfgZ7DDfbXvNTkZg1AMwj7M2vKPlzqvYlNeoG2TxdvKHYNjeD2hiafG6occMaN90wTo5TMvDBIR2/UWz79BKeb0x6hH4EoN2G8sRQ9emWc9Q00KmLD5Hl696Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(4636009)(136003)(346002)(376002)(39860400002)(366004)(396003)(316002)(66556008)(76116006)(66946007)(66476007)(66446008)(26005)(4326008)(64756008)(86362001)(71200400001)(52536014)(55236004)(7696005)(6916009)(6506007)(54906003)(66574015)(53546011)(186003)(8936002)(9686003)(55016002)(8676002)(83380400001)(33656002)(478600001)(5660300002)(2906002); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?NRFmdRqZA3ej77JEZ0MPY2v0ZmWNw0EK20Zxuxu78ip0mMrQ7/e0UY4MZq?= =?iso-8859-1?Q?gOy6L+g6se+st4YJKFeuHWkB1m5TryDnOBCX/YwXprA6efim0kS487Xa0D?= =?iso-8859-1?Q?ZodnNayBKK0I6NwChMZQBexppEY0z89t5as70IeeS7AnfHpBP4gpksdxAo?= =?iso-8859-1?Q?YF2ttMWkAZOR1TseOhzcozJu70IE+okdYkK2Hwmb8BA5nFQeLothtJT5Mk?= =?iso-8859-1?Q?ObjeDiHyQseeT7i96APqWsT6/2JXDAqaZJwQxz9A5ryrV+FQGSrt92zRO6?= =?iso-8859-1?Q?2l1ER/kWdHG/3OFj0gBh2mJ7/LL3aUl32905eaJGYfLXaeNvHcDrUbM25Q?= =?iso-8859-1?Q?wt+xSexnrLu+dnXLp/j+N2MsZRyL4IoLVjP0HLWbzhIhdH8kDHwlFwd5DN?= =?iso-8859-1?Q?qrLhL8CWMZJtnOcTxmMNvQgXUdY/iJ9RYOq6TPooqOa39Qh2zr5x4xlCPP?= =?iso-8859-1?Q?hpNgL/3sHwmInHiXTIFSqSsRrWQQY5MDSjnMoND+2AHp9gmeGaBLqzxUB8?= =?iso-8859-1?Q?Pz0Jhyw5gcITg1Y3RZBy4sf2IWXH+QsDhC/NBIKYCXstCdnCIqDHhY2kUR?= =?iso-8859-1?Q?wQCjsWf0KRRP3T66Tx6b7jN3AeekIohZrYpRcyL3KGdNz0IJ8cuz5fg98E?= =?iso-8859-1?Q?S5Ng3Z8c/QoAwNSk426HrGxm4FE0fOkw9I2iLBQE3l7jy3wmeNJMH84muQ?= =?iso-8859-1?Q?xJKsCO8svoVpnu+b7LktzNPlWfIPiQOCYhw17vgDZoEdDuj3Rx6UBVZy9N?= =?iso-8859-1?Q?87j085kF7uQahRtxKadGp9OMY4VxwTX3f2UExu/D367QyKuFVZ2YfHcFmE?= =?iso-8859-1?Q?hsGems5zfTvxNrt/vSMFMz3GO5qNcu0Mv+ga8B9yavNNyXqlOKGGqQ5qkR?= =?iso-8859-1?Q?5t2OPaEyaaX2o5vDEE9udBJlHj4g9JmlVpD7bSBV7sItABCiEgAxDv4njk?= =?iso-8859-1?Q?lNPyvWOdU+3T5PHnt10HlonMKwy19gUv5keYB4MO5yktEkgkCbMZ2MSVxo?= =?iso-8859-1?Q?wBZixLpuo2FsX61fzswMhu01Sk27Y3rBagkmWh?=
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-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: e247bc94-e004-4f6e-2d4b-08d8a0da69b1
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2020 09:18:40.8629 (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: U5iikpk4GLbXVifxluZVCtGevASVjQ9cR3aSkbcCnoHfsmP9H4yZHoDfhxLst1+d7T2MRbEpZU2KMMAJpvFHwUUrvYz2g1EXeMYPVBS3CD8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR10MB4277
Archived-At: 
Subject: Re: [lamps] Mail regarding draft-ietf-lamps-cmp-updates
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, 15 Dec 2020 09:18:49 -0000

Russ

> -----Urspr=FCngliche Nachricht-----
> Von: Russ Housley 
>=20
> > On Dec 11, 2020, at 2:48 PM, Brockhaus, Hendrik
>  wrote:
> >
> >> Von: Spasm  Im Auftrag von Lijun Liao
> >> Gesendet: Freitag, 11. Dezember 2020 20:13
> >>
> >> If the CA uses the envelopedData choice, the CMP client that does not
> support this draft, cannot process the response. So the CA needs a
> mechanism to determine whether the CMP client supports > this draft or
> not. You should increase the CMP version or add some other fields in the
> CMP request to provide the CA such information.
> >
> > Our goal was to make only minimal changes to CMP to circumvent
> increasing the CMP version.
>=20
> When we have done things like this in CMS, we say when encryptedValue is
> used, the version MUST be X, and when envelopedData is used, the version
> MUST be x+1.  This allows an unsupported version error instead of a bad
> format.
>=20

Can we stick to the concept of updating RFC4210 when introducing a CMP V3 v=
ersion for usage of EnvelopedData?
Or does the introduction of a new version number requires to obsolete RFC42=
10?

Hendrik


From nobody Tue Dec 15 01:35:06 2020
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 3B7A53A0DBA for ; Tue, 15 Dec 2020 01:35:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-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=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 sHurpcrLWNRv for ; Tue, 15 Dec 2020 01:35:04 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60079.outbound.protection.outlook.com [40.107.6.79]) (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 C38B83A0DF6 for ; Tue, 15 Dec 2020 01:35:03 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DdUjbv8ZaujnmJYthaGc0VwBOf0eOTjkufumPxa+d0hTFm91xLIbENTs+H5f4skGhKoNO5JvUYJR6zp9U1i7NQdm7obnRJavWXsZkpLrWNX5u+mT6IszHJ2lZs3D0X4LwKdSAYeoGobFhdz4a2SIEDN72yIpQ4Vh5j1+OcnDK4SjVJgGj39DQzl7v+ZgkzclIQRJ+25svNiO42Vxmz3n1NWNzSDJQhmkCK8BJEKjqQ1MpYMr1/onyHJ2u95DptuM1YagLD6ihPzrVRWLnABlP8VTVNxOYXzsx4U/YckqM2eXErlBLs54kanOAvRrCsZk+yL+6RT7TqOa9IfIXhmkeg==
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=atEM4AStYUXHw2K0LXDzX4YAJxxya9PrRfWAdZB466o=; b=n3/RLQXG81CNfY8JxoTNQ63hDsHWQ777pfj9evhXoNR+fcggsyxB7p9+YqWBUAeM49gRu01hXBumOFIJ5J3T4ErOx+mRgm19X3AwB3Jz+rjEvGS3WILFIA6dM9cgAbSfR9pEDlaZmFjDdvdFzKQ96OC/seivTrRsnvpoDPTiiWtpkZFaFcKRtrtq+ZZXKnGM/xxy/Y+95MfsOZhRbN1+TzcCw8dXC85mOWLeIUgdEwThUO0JKiADsMvDQcpsVdJCU30iiShw5hPcO4nbixUEDMUw9rNUKgDDx0elLeI7M2SFmYpZa3vyIbBwrv3GCsWLV3gW2XBstHj8vRjKqKGYSA==
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=atEM4AStYUXHw2K0LXDzX4YAJxxya9PrRfWAdZB466o=; b=o/JZQ/nbdm6hmgh0iUrfKPp0a0kf9ccVf2WD4w6ApdXmUr99xTx0VCdCo7DjUwB4OWkrYiVQGQ7rEhOQaFv4L4uAlWHTO2UtCtxV8js5PbKdS3MTpGpT+ec6Vw9SCFLaezXywjIwHoxMrz4QSu/z1+EQ8hXuh5Qmi6XUDBV5TKE=
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM9PR10MB4022.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:1fc::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.13; Tue, 15 Dec 2020 09:35:01 +0000
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69%7]) with mapi id 15.20.3654.024; Tue, 15 Dec 2020 09:35:01 +0000
From: "Brockhaus, Hendrik" 
To: Tomas Gustavsson , Russ Housley 
CC: "spasm@ietf.org" 
Thread-Topic: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
Thread-Index: AdbP1vUv/UMIlgi1CUSbFvZhLrxU4ACE4BwAABLPT4AAAHqjAAAK7uOAABOBYYAABP3W0A==
Date: Tue, 15 Dec 2020 09:35:01 +0000
Message-ID: 
References:  <6f0bee53-2945-025c-3edf-28fca898f7d2@primekey.com> <2A98B48A-741E-4621-B2F1-739AC4B518D0@vigilsec.com>  <0A02F029-D679-406F-B6C5-47F2AE824FBF@vigilsec.com> <9bad3ef4-bb8c-819c-29e7-f51646b221d1@primekey.com>
In-Reply-To: <9bad3ef4-bb8c-819c-29e7-f51646b221d1@primekey.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-12-15T09:35:00Z;  MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=ae3b99db-a265-41bf-8191-f594445e4db2; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
authentication-results: primekey.com; dkim=none (message not signed) header.d=none;primekey.com; dmarc=none action=none header.from=siemens.com;
x-originating-ip: [165.225.200.184]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 1e84628d-a512-4353-5287-08d8a0dcb251
x-ms-traffictypediagnostic: AM9PR10MB4022:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: mkv0cJaImC2rKVZzMbrHGNd/bmEwOe1usbNmlt2E0wFiAZxrHii+T51otJVPja1//2P4P+0mm4r8rHMpgeux0OlHUAdnNW138/u84YJPlM7EkSz34AkwsPR53RVMtNXFeXmfHD7uhESl62Ib4yifW3U0u6Inc5sXyPN4SKn/mnGd14lddAE6Yspy4CeM/2TDTFBXXsbhnRtoaHe2P/qZCvFKkBIAdU9hggv6SzZkaMd1+RL7rQ4hjzPvjrRln9s/A3mtWFF/j8Gu8JGbsBRWEDl1EyjBYPqtGIFCx8YUa8ne52ybNGn0iFQ56UH7tr8iQqw9QA116AtcMWkZWBr3Rg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(4636009)(376002)(396003)(136003)(366004)(39860400002)(346002)(33656002)(478600001)(4326008)(55236004)(76116006)(186003)(64756008)(66946007)(71200400001)(6506007)(55016002)(52536014)(110136005)(8936002)(66556008)(86362001)(15650500001)(4744005)(66476007)(66446008)(83380400001)(7696005)(5660300002)(9686003)(2906002)(66574015)(26005)(316002)(8676002); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?hgcHeCmNX8ePUFL4Boj8mOUEjkaHbWiDviuf8xV96Cq7wMIdlHwcKsQ1G1?= =?iso-8859-1?Q?nIF4gcHRTmEZol8UM33yFAiViUMu/gODEkXEa5qsqsLCXkU2gEgR113dZw?= =?iso-8859-1?Q?iQG+t3lfE097nCkWL0yIr/G97vwu56b05wj/2GOKwGIPhrrFY5dG0mfdqh?= =?iso-8859-1?Q?T9eR3FxZ5KTAi40Yf45dv+rVfJFBVyq54z8G1+ULQ5oAwV2etKtkcoo3H7?= =?iso-8859-1?Q?60xfchOrRwOdm0FB3De9sfg+INCo5QnEJLcWIPXG97WOduFHyvy7xIg09A?= =?iso-8859-1?Q?Sbh4ddek6W6ak0p0yC4IA6xROBotPoweAqIznxlU1uYlZJw5SjUvR1Y+jn?= =?iso-8859-1?Q?kKbDXBeJSdVCybpBlBPZP0YiXH4qM0zJg79m0zkrHr/mH6040on80jFB0H?= =?iso-8859-1?Q?YHxv3TP5dAvFguPF6XE7GF3bPfZhehcm0VIBde1APl7OTdA9kVFnycvO7g?= =?iso-8859-1?Q?TBWCtJYn5DonKvraAGRcAcnnACVFMLPjUH+ZrFS0Wq8ictR85SFWejNvKI?= =?iso-8859-1?Q?y58S4ehhKqJgkc9ZPKTUilEHS3wwILDIgTorgixV0y+VKq8Kf2F7iOBeur?= =?iso-8859-1?Q?SNelNBs5EIPapPmcAwDmEL5nEeev+JrDvcnivdkkKSYrnjLPyvPd9ZLZ+k?= =?iso-8859-1?Q?afRteXKSz1/NakFsv03m3mEpedSgQx3VlRnXkkwp9YvUtnherzMrZHRpit?= =?iso-8859-1?Q?J6LCYp4VseCHM69U1ShFKhOQdENp+tsIqKpwpeFaVHgsnfoLDEC+M1bJSz?= =?iso-8859-1?Q?wNOdwtd8oHzy5A9Z7vRL48NiJxm0OF7hBW3ITI4zT1y8GWvjpybFZbHqOL?= =?iso-8859-1?Q?0gZx9abE5weRSASaiVuRtextm8tuaaZBQ6iUqfAoxWlZd8kWIzLvT2wuEg?= =?iso-8859-1?Q?+gUHRY0meJu7/dzo8Ep88Y0YL0TZIuTt6E/EnlFNhaqzO0O0sv+gRN8BTH?= =?iso-8859-1?Q?06M9JFsySNv6I3CM58xixPtI/B1EKoSUcDEaY+Hv7MAvUytuLqcx9XbjaL?= =?iso-8859-1?Q?KJ8qMF2JPdqWFpeoMZMKZrGk031m9QSxGM1ai9?=
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-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 1e84628d-a512-4353-5287-08d8a0dcb251
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2020 09:35:01.7058 (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: KItp3Ky1I5QS5QdUKRy4PRmCtnJFDzJZBtHYlVZ73D+w91l8k0tud8pQzNMKK4nC9lgWN+Gtiqp7Hmnuu3tHcUsO5+rI8aS/4LNhGmeKGQs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR10MB4022
Archived-At: 
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2020 09:35:05 -0000

Tomas

> -----Urspr=FCngliche Nachricht-----
> Von: Spasm  Im Auftrag von Tomas Gustavsson
>=20
> >> Do we want to say that conformant clients MUST use a minimum of X
> >> (1000?). Is that the same as saying conformant servers MUST reject
> >> iterationCount < 1000, with bad_request?
> >
> > The mandatory-to-implement discussion is not the place, in my opinion, =
for
> a statement like servers MUST reject iterationCount < 1000.
>=20
> I can see the difference between RFC4211 and RFC4210 for this now. I got
> confused because the same definition of id-PasswordBasedMac is on both
> RFC4210 and RFC4211. Creating a risk of conflict/unclarity between the tw=
o
> RFCs if not updated in sync.

Good point.=20
I will add an update of section 5.1.3.1 pf RFC4210 to CMP Updates and refer=
 to the updated section in CRMF.

Hendrik


From nobody Tue Dec 15 08:15:56 2020
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 532583A1211 for ; Tue, 15 Dec 2020 08:15:55 -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, 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 VPKlGIaxnHBd for ; Tue, 15 Dec 2020 08:15: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 9462D3A1210 for ; Tue, 15 Dec 2020 08:15:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0A63F300BC4 for ; Tue, 15 Dec 2020 11:15:51 -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 ci3KJuUj328g for ; Tue, 15 Dec 2020 11:15:49 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 21BFF300A9E; Tue, 15 Dec 2020 11:15:49 -0500 (EST)
From: Russ Housley 
Message-Id: <763CD1C0-4973-41A5-A1DA-615310F7731F@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_715FDF5C-ABA0-4114-B3AA-B9FA81FAAA31"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Tue, 15 Dec 2020 11:15:50 -0500
In-Reply-To: 
Cc: "spasm@ietf.org" 
To: Lijun Liao 
References:       
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] Mail regarding draft-ietf-lamps-cmp-algorithms
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, 15 Dec 2020 16:15:55 -0000

--Apple-Mail=_715FDF5C-ABA0-4114-B3AA-B9FA81FAAA31
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Lijun:

> I am open to also add SHA3 and I see your points regarding PKCS#11 =
support. But, currently from the SHA3-family only SHAKE128 and SHAKE256 =
are specified for use in X.509 and CMS. Therefore, you should rise your =
request to support SHA3 to the LAMPS mailing list and possibly submit a =
draft on this.

See https://tools.ietf.org/html/draft-housley-lamps-cms-sha3-hash-00

It was discussed, and there was very little support for it.

> Thank you for the reference. I will cover RSASSA-PSS as alternative to =
PKCS#1 V1.5. I am also open to keep RSA-OAEP. As this was discussed =
during the WG meeting, you should also bring this request to the =
attention of the group, to get a joined decision.

So far, we have seen very little support for RSA-PSS or RSA-OAEP (see =
RFC 4055 and the update to it in RFC 5756).  I am a bit surprised to =
hear that this is about to change.  Elliptic curve offers smaller public =
keys for the same level of security.  Is there a hardware reason for a =
transition to  RSA-PSS or RSA-OAEP instead of elliptic curve?

Russ


--Apple-Mail=_715FDF5C-ABA0-4114-B3AA-B9FA81FAAA31
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


Lijun:

I am open to also add SHA3 and I see your points regarding =
PKCS#11 support. But, currently from the SHA3-family only SHAKE128 and =
SHAKE256 are specified for use in X.509 and CMS. Therefore, you should =
rise your request to support SHA3 to the LAMPS mailing list and possibly =
submit a draft on this.

See https://tools.ietf.org/html/draft-housley-lamps-cms-sha3-hash-0=
0

It was discussed, and there =
was very little support for it.

Thank you for the reference. I will cover RSASSA-PSS as =
alternative to PKCS#1 V1.5. I am also open to keep RSA-OAEP. As this was =
discussed during the WG meeting, you should also bring this request to =
the attention of the group, to get a joined =
decision.

So =
far, we have seen very little support for RSA-PSS or RSA-OAEP (see RFC =
4055 and the update to it in RFC 5756).  I am a bit surprised to =
hear that this is about to change.  Elliptic curve offers smaller =
public keys for the same level of security.  Is there a hardware =
reason for a transition to  RSA-PSS or RSA-OAEP instead of =
elliptic curve?

Russ

=

--Apple-Mail=_715FDF5C-ABA0-4114-B3AA-B9FA81FAAA31--


From nobody Tue Dec 15 08:21:43 2020
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 606F83A1213 for ; Tue, 15 Dec 2020 08:21:42 -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, 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 hWeauECOvNRo for ; Tue, 15 Dec 2020 08:21:41 -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 17B1D3A1211 for ; Tue, 15 Dec 2020 08:21:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8A657300BC1 for ; Tue, 15 Dec 2020 11:21: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 4M9gvTJwmJEv for ; Tue, 15 Dec 2020 11:21:37 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 0D58E300B53; Tue, 15 Dec 2020 11:21:37 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Russ Housley 
In-Reply-To: 
Date: Tue, 15 Dec 2020 11:21:38 -0500
Cc: "spasm@ietf.org" , Lijun Liao 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <44EBF4BD-7560-492B-A061-CC9CCB848D08@vigilsec.com> 
To: "Brockhaus, Hendrik" 
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] Mail regarding draft-ietf-lamps-cmp-updates
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, 15 Dec 2020 16:21:42 -0000

> On Dec 15, 2020, at 4:18 AM, Brockhaus, Hendrik =
 wrote:
>=20
> Russ
>=20
>> -----Urspr=C3=BCngliche Nachricht-----
>> Von: Russ Housley 
>>=20
>>> On Dec 11, 2020, at 2:48 PM, Brockhaus, Hendrik
>>  wrote:
>>>=20
>>>> Von: Spasm  Im Auftrag von Lijun Liao
>>>> Gesendet: Freitag, 11. Dezember 2020 20:13
>>>>=20
>>>> If the CA uses the envelopedData choice, the CMP client that does =
not
>> support this draft, cannot process the response. So the CA needs a
>> mechanism to determine whether the CMP client supports > this draft =
or
>> not. You should increase the CMP version or add some other fields in =
the
>> CMP request to provide the CA such information.
>>>=20
>>> Our goal was to make only minimal changes to CMP to circumvent
>> increasing the CMP version.
>>=20
>> When we have done things like this in CMS, we say when encryptedValue =
is
>> used, the version MUST be X, and when envelopedData is used, the =
version
>> MUST be x+1.  This allows an unsupported version error instead of a =
bad
>> format.
>>=20
>=20
> Can we stick to the concept of updating RFC4210 when introducing a CMP =
V3 version for usage of EnvelopedData?
> Or does the introduction of a new version number requires to obsolete =
RFC4210?

I do not see a problem.

Russ


From nobody Tue Dec 15 08:38:01 2020
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 01D4C3A1239 for ; Tue, 15 Dec 2020 08:38:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PA_auAAwY0l for ; Tue, 15 Dec 2020 08:37:58 -0800 (PST)
Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 674113A1231 for ; Tue, 15 Dec 2020 08:37:58 -0800 (PST)
Received: by mail-pj1-x1035.google.com with SMTP id l23so9203527pjg.1 for ; Tue, 15 Dec 2020 08:37:58 -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=pnM+I5MCyRx9o3JfxuVFPzqd2T2yWWwIIg38Sb4MBH8=; b=BPDvQhZtaf0FWM04/icfv8o9k9GNIO9c933PVMmvntJ3Xh+RY7Zt/uWe84WIMV5+ts CK2ikIBP5lEkaHMhaaVgfkvJVG37GlMCE11s7kw/W47cmUx7SqYEyHE4zek6dyT7Ed5M oTKeyKl7YbUEeAH9vWGG1JGN9dR+oCErhRExC3mGF2MYL1MeymJntmHBQjdjTVNDUwSu ZkKtqG1TdYRYXyNTi2p5Vs85xz/3uo/FK4eeK7GC3vcYgJtYleUb7OP8Z+uOFAEGTL9b gUkkyH67UZIbJFD+1WFHJ6CmV7S27Aa/EUoqUgdoYfApSZTAyabxfDOJbWy07/RwwZZ0 RxJw==
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=pnM+I5MCyRx9o3JfxuVFPzqd2T2yWWwIIg38Sb4MBH8=; b=X+mmyIxSg9rr+RIBq3HVz66p4V0yxOawLRYEBO8Y4EQ0ch0U6Jy19ks5vFWF/EQp2i SuS/XfwQo+Yfsf1tf0AFndhQmYdJusCtF4V6qLAkkQhy3EfaX5vfWgrwu7Q8WHnXlERw 1FxiT7lRM78Xax0HrkqNbKN5G1+jy5+oG1wClW2pYPC6BKg6Tfcflrg7ILd/gonP56CT 9DfG3Y3JOyd52Z+yICRlswlw5kUkyCn+g8xztb76mlyZZTWkc2cqoL65FD4WSPdUvxPy 6FpHgXHthIDkSowOx4Q5y/6zwM3xN0US3eWQ41paZ7zvhIHL1L5UGyj4/svipbEV1zG7 Mxpg==
X-Gm-Message-State: AOAM532iH5H3xIO5gi+KY59LMk+OkJNay8b+BWNw3bs07Jpy+uI+R/Bz X+hy8maEY6U+csstnf06RhFZSXxnPOvs+o2gPXD7MwepQTuvmg==
X-Google-Smtp-Source: ABdhPJxnMwcaWFwZuFMau0vxC3XFs8sJM6AMDG4+0IS6rZWYnioW3BW7eegMvv/d11RGt35N962J3L0f3OZ9liBapsc=
X-Received: by 2002:a17:90a:450c:: with SMTP id u12mr30790050pjg.93.1608050277808;  Tue, 15 Dec 2020 08:37:57 -0800 (PST)
MIME-Version: 1.0
References:        <763CD1C0-4973-41A5-A1DA-615310F7731F@vigilsec.com>
In-Reply-To: <763CD1C0-4973-41A5-A1DA-615310F7731F@vigilsec.com>
From: Lijun Liao 
Date: Tue, 15 Dec 2020 17:37:46 +0100
Message-ID: 
To: Russ Housley 
Cc: "spasm@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000096fe2d05b683611d"
Archived-At: 
Subject: Re: [lamps] Mail regarding draft-ietf-lamps-cmp-algorithms
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, 15 Dec 2020 16:38:00 -0000

--00000000000096fe2d05b683611d
Content-Type: text/plain; charset="UTF-8"

Russ,

see the inline comments.

On Tue, Dec 15, 2020 at 5:15 PM Russ Housley  wrote:

> Lijun:
>
> I am open to also add SHA3 and I see your points regarding PKCS#11
> support. But, currently from the SHA3-family only SHAKE128 and SHAKE256 are
> specified for use in X.509 and CMS. Therefore, you should rise your request
> to support SHA3 to the LAMPS mailing list and possibly submit a draft on
> this.
>
>
> See https://tools.ietf.org/html/draft-housley-lamps-cms-sha3-hash-00
>
> It was discussed, and there was very little support for it.
>

Signature algorithms with SHA3 (e.g. SHA3-256-ECDSA) are specified in the
current version of PKCS#11 v3.0 and are under the approved algorithms of
FIPS 140-3. But SHAKE is not.
And since most CAs use FIPS 140 certified HSMs (over PKCS#11) to generate
the certificates, it is very impossible that SHAKE based certificates will
be widely used in the next few years.


>
> Thank you for the reference. I will cover RSASSA-PSS as alternative to
> PKCS#1 V1.5. I am also open to keep RSA-OAEP. As this was discussed during
> the WG meeting, you should also bring this request to the attention of the
> group, to get a joined decision.
>
>
> So far, we have seen very little support for RSA-PSS or RSA-OAEP (see RFC
> 4055 and the update to it in RFC 5756).  I am a bit surprised to hear that
> this is about to change.  Elliptic curve offers smaller public keys for the
> same level of security.  Is there a hardware reason for a transition
> to  RSA-PSS or RSA-OAEP instead of elliptic curve?
>

Old systems like embedded devices, may only support RSA. In Germany, the
use of RSA PKCS#1v1.5 encoding in the signature and encryption is
deprecated and in some cases also forbidden. In this case, the only way is
to use RSA-PSS for the signature and RSA-OAEP for the encryptin.



> Russ
>
>
Best regards
Lijun

-- 
Lijun Liao

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


Russ,

see the inline comment=
s.

On Tue, Dec 15, 2020 at 5:15 PM Russ Housley <housley@vigilsec.com> wrote:
Lijun:

I am open to also add=
 SHA3 and I see your points regarding PKCS#11 support. But, currently from =
the SHA3-family only SHAKE128 and SHAKE256 are specified for use in X.509 a=
nd CMS. Therefore, you should rise your request to support SHA3 to the LAMP=
S mailing list and possibly submit a draft on this.

See=C2=A0https://tools.ietf.org/=
html/draft-housley-lamps-cms-sha3-hash-00

It w=
as discussed, and there was very little support for it.

Signature algorit=
hms with SHA3 (e.g. SHA3-256-ECDSA) are specified in the current version of=
 PKCS#11 v3.0 and are under the approved algorithms of FIPS 140-3. But SHAK=
E is not.
And since most CAs use FIPS 140 certified HSMs (over PK=
CS#11) to generate the certificates, it is very impossible that SHAKE based=
 certificates will be widely used in the next few years.
=C2=
=A0

Thank you for the reference. I will cover RSASSA-PSS as alternative to PKC=
S#1 V1.5. I am also open to keep RSA-OAEP. As this was discussed during the=
 WG meeting, you should also bring this request to the attention of the gro=
up, to get a joined decision.

So far, we have seen very little support for RSA-PSS or RSA-OAEP (see RFC =
4055 and the update to it in RFC 5756).=C2=A0 I am a bit surprised to hear =
that this is about to change.=C2=A0 Elliptic curve offers smaller public ke=
ys for the same level of security.=C2=A0 Is there a hardware reason for a t=
ransition to=C2=A0=C2=A0RSA-PSS or RSA-OAEP instead of elliptic curve?

Old systems like embedded devices, =
may only support RSA. In Germany, the use of RSA PKCS#1v1.5 encoding in the=
 signature and encryption is deprecated and in some cases also forbidden. I=
n this case, the only way is to use RSA-PSS for the signature and RSA-OAEP =
for the encryptin.



Russ


=

Best regards
Lijun

-- 
Lijun Liao


--00000000000096fe2d05b683611d--


From nobody Tue Dec 15 13:47:30 2020
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 523F43A005D for ; Tue, 15 Dec 2020 13:47:28 -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, 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 i4mT7BwYB-Yn for ; Tue, 15 Dec 2020 13:47:26 -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 B76CF3A0045 for ; Tue, 15 Dec 2020 13:47:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E168B300BC4 for ; Tue, 15 Dec 2020 16:47:23 -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 yz3PFG1XRdHC for ; Tue, 15 Dec 2020 16:47:22 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 5BB19300A48; Tue, 15 Dec 2020 16:47:22 -0500 (EST)
From: Russ Housley 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_27A954E2-9C31-4FCD-BF17-E53D5793523B"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Tue, 15 Dec 2020 16:47:23 -0500
In-Reply-To: 
Cc: "spasm@ietf.org" 
To: Lijun Liao 
References:        <763CD1C0-4973-41A5-A1DA-615310F7731F@vigilsec.com> 
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] Mail regarding draft-ietf-lamps-cmp-algorithms
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, 15 Dec 2020 21:47:28 -0000

--Apple-Mail=_27A954E2-9C31-4FCD-BF17-E53D5793523B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Lijun:

>=20
>> Thank you for the reference. I will cover RSASSA-PSS as alternative =
to PKCS#1 V1.5. I am also open to keep RSA-OAEP. As this was discussed =
during the WG meeting, you should also bring this request to the =
attention of the group, to get a joined decision.
>=20
> So far, we have seen very little support for RSA-PSS or RSA-OAEP (see =
RFC 4055 and the update to it in RFC 5756).  I am a bit surprised to =
hear that this is about to change.  Elliptic curve offers smaller public =
keys for the same level of security.  Is there a hardware reason for a =
transition to  RSA-PSS or RSA-OAEP instead of elliptic curve?
>=20
> Old systems like embedded devices, may only support RSA. In Germany, =
the use of RSA PKCS#1v1.5 encoding in the signature and encryption is =
deprecated and in some cases also forbidden. In this case, the only way =
is to use RSA-PSS for the signature and RSA-OAEP for the encryptin.

Hendrick has agreed to add them as alternatives for CMP.  The algorithm =
identifiers and the parameters are already specified.  I do not see =
anything else that needs to happen in the LAMPS WG.

Russ


--Apple-Mail=_27A954E2-9C31-4FCD-BF17-E53D5793523B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Lijun:


Thank you for the reference. =
I will cover RSASSA-PSS as alternative to PKCS#1 V1.5. I am also open to =
keep RSA-OAEP. As this was discussed during the WG meeting, you should =
also bring this request to the attention of the group, to get a joined =
decision.

So far, we have seen very little support for RSA-PSS or =
RSA-OAEP (see RFC 4055 and the update to it in RFC 5756).  I am a =
bit surprised to hear that this is about to change.  Elliptic curve =
offers smaller public keys for the same level of security.  Is =
there a hardware reason for a transition to  RSA-PSS or =
RSA-OAEP instead of elliptic curve?

Old systems like =
embedded devices, may only support RSA. In Germany, the use of RSA =
PKCS#1v1.5 encoding in the signature and encryption is deprecated and in =
some cases also forbidden. In this case, the only way is to use RSA-PSS =
for the signature and RSA-OAEP for the =
encryptin.

Hendrick has agreed to add them as alternatives for =
CMP.  The algorithm identifiers and the parameters are already =
specified.  I do not see anything else that needs to happen in the =
LAMPS WG.

Russ

=

--Apple-Mail=_27A954E2-9C31-4FCD-BF17-E53D5793523B--


From nobody Wed Dec 16 14:17:34 2020
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 2CD7F3A1257 for ; Wed, 16 Dec 2020 14:17: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, 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 p6op_U2EiA9m for ; Wed, 16 Dec 2020 14:17:30 -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 0790D3A1258 for ; Wed, 16 Dec 2020 14:17:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5B9C9300ADC for ; Wed, 16 Dec 2020 17:17: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 mt-h_B2T51us for ; Wed, 16 Dec 2020 17:17:26 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 40762300A51 for ; Wed, 16 Dec 2020 17:17:26 -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.17\))
Date: Wed, 16 Dec 2020 17:17:27 -0500
References: <132888CA-AA3D-44B7-A5D7-9361CA0792DD@vigilsec.com>
To: LAMPS 
In-Reply-To: <132888CA-AA3D-44B7-A5D7-9361CA0792DD@vigilsec.com>
Message-Id: 
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] LAMPS Virtual Interim on 28 Jan 2021
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2020 22:17:32 -0000

LAMPS Virtual Interim Meeting
Hosted by LAMPS Working Group

https://ietf.webex.com/ietf/j.php?MTID=3Dmb6639fe2c67ce9a639fcb8701fa85e3c=

Thursday, Jan 28, 2021 10:00 am | 2 hours | (UTC-08:00) Pacific Time (US =
& Canada)
Meeting number: 178 699 4894
Password: PQC-Trans-2021
bf8be386480348c8abe0fd0b64bf8aed

Join by video system
Dial 1786994894@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting number.

Join by phone
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 178 699 4894


> On Dec 10, 2020, at 3:11 PM, Russ Housley  =
wrote:
>=20
> An interim meeting for LAMPS has been approved.  The time was selected =
based on the doodle poll.
>=20
> 	Date: 2021-01-28
>=20
> 	Start Time: 1:00pm Eastern
>=20
> 	Duration: 2 hours
>=20
> 	Remote Participation: WebEx
>=20


From nobody Wed Dec 16 16:18:35 2020
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 56A183A08F8; Wed, 16 Dec 2020 16:18:30 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IESG Secretary 
To: "IETF-Announce" 
Cc: spasm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160816431022.10255.14057915453242628023@ietfa.amsl.com>
Date: Wed, 16 Dec 2020 16:18:30 -0800
Archived-At: 
Subject: [lamps] Limited Additional Mechanisms for PKIX and SMIME (lamps) WG Virtual Meeting: 2021-01-28
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, 17 Dec 2020 00:18:30 -0000

The Limited Additional Mechanisms for PKIX and SMIME (lamps) WG will hold
a virtual interim meeting on 2021-01-28 from 13:00 to 15:00 America/New_York (18:00 to 20:00 UTC).

Agenda:
Since we need to re-charter the LAMPS WG to take on draft-dkg-lamps-e2e-mail-guidance, this seems like a good time to ask what other topics the group might want to tackle.  The WG chairs have hear interest in topics related to the transition to PQ cryptographic algorithms.  We think that a virtual interim on that will help determine what, if anything, should be included in the re-charter.

Information about remote participation:
https://ietf.webex.com/ietf/j.php?MTID=mb6639fe2c67ce9a639fcb8701fa85e3c

Meeting number: 178 699 4894 
Password: PQC-Trans-2021 
bf8be386480348c8abe0fd0b64bf8aed


From nobody Thu Dec 17 15:48:48 2020
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 8C6E63A08FA for ; Thu, 17 Dec 2020 15:48: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 q4l36Xs9qSm2 for ; Thu, 17 Dec 2020 15:48:45 -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 119553A0940 for ; Thu, 17 Dec 2020 15:48:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6F254300ADC for ; Thu, 17 Dec 2020 18:48:42 -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 tbLKpBPhebno for ; Thu, 17 Dec 2020 18:48:40 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 3ED4430066E; Thu, 17 Dec 2020 18:48:40 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Russ Housley 
In-Reply-To: 
Date: Thu, 17 Dec 2020 18:48:41 -0500
Cc: "spasm@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <787D6A06-002B-4008-8379-AC4A87A7B2C7@vigilsec.com>
References: 
To: "Aschauer, Hans" 
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2020 23:48:48 -0000

Hans:

> After discussing the topics internally with Hendrik, there are some =
concerns left:
>=20
> 1. Iteration count:
>=20
> NEW:
>=20
>      iterationCount identifies the number of times the hash is applied
>      during the key computation process.  The iterationCount MUST be a
>      least 10,000 [NISTSP800-63B].  There is a trade off between
>      protection of the password from attacks and the time spent by the
>      server processing the iterations.
>=20
> Please note that the cited NIST publication does *not* say that =
iteration count must be at least 10,000. Actually, it states:
>=20
>    Therefore, the iteration count SHOULD be as large as
>    Verification server performance will allow, typically at least =
10,000 iterations.
>=20
> The difference is subtle, but important. 10,000 merely is an estimate =
on what typical servers will be able to process. However, the important =
part is "SHOULD be as large as [...] performance will allow". This is =
due to the fact that even much higher iteration counts will not prevent =
an attacker from breaking a low-entropy password in an offline attack. =
NIST also knows this, and for this reason they continue:
>=20
>    In addition, verifiers SHOULD perform an additional iteration of a =
key
>    derivation function using a salt value that is secret and known =
only to
>    the verifier.
>=20
> However, the secret salt is not an option in the use case discussed =
here (it can only be used for storing password verifiers, not for =
password based key generation).
>=20
> So IMHO it is not ok to cite the NIST SP in order to recommend 10,000 =
iterations as an acceptable minimum.
>=20
> [[[
> Let me just explain why this iteration count of 10,000 should be =
considered insecure.
>=20
> Assume that the password has an entropy of 35 bits (*), and you use an =
iteration count of 10,000. Further assume that the attacker has an ASIC =
based hash machine, similar to one used for Bitcoin mining, with a hash =
rate of 14 Thash/second, i.e. 14e12 hashes per second (commercially =
available for USD 3000).
>=20
> The time it takes to break the password is then
>=20
>    t_pwd =3D 2^35 * 10,000 hashes / 14e12 hashes per second =3D 25 =
seconds
>=20
> I would assume that this is a realistic threat, even for online =
attacks.
>=20
> On the other hand, a typical server CPU can calculate about 10-100 M =
hashes per second, i.e. 1e7 to 1e8 hashes per second. Allowing for a =
password verification time of one second, this allows for an iteration =
count of 10,000,000 to 100,000,000. This is the number you should choose =
according to the NIST recommendation. Note that this choice will make =
online attacks difficult.
>=20
> (*) The entropy of a typical password (chosen by a human) is difficult =
to assess. There is a paper from 2007 by Florencio et al [1] which =
calculates 40.5 bits as _mean_ entropy, but also newer research [2] =
which shows that 50% of real-world passwords can be broken with less =
than 150,000,000 trials, indicating a much lower _median_ entropy (27 =
bits).
>=20
> [1] Florencio, Dinei; Herley, Cormac (May 8, 2007). =
http://research.microsoft.com/pubs/74164/www2007.pdf, Proceeds of the =
International World Wide Web Conference Committee
>=20
> [2] Dell=C2=92Amico, Matteo & Michiardi, Pietro & Roudier, Yves. =
(2010). Password Strength: An Empirical Analysis. Proceedings of INFOCOM =
2010. 1 - 9. 10.1109/INFCOM.2010.5461951.
> ]]]

I suggest:

      iterationCount identifies the number of times the hash is applied
      during the key computation process.  The iterationCount MUST be a
      minimum of 100; however, the iterationCount SHOULD be as large as
      server performance will allow, typically at least 10,000
      [NISTSP800-63B].  There is a trade off between protection of the
      password from attacks and the time spent by the server processing
      the iterations.


> 2. One-time passwords
>=20
> NEW:
>     The password used
>      to compute this MAC SHOULD NOT be used for any other purpose.
>=20
> Please note that while a password should in general be used for only a =
single purpose, due to the weakness of the password based MAC, in the =
use case under consideration it should really be used only *once*. This =
is the only way to thwart offline attacks.
>=20
> I would suggest to use the formulation: "The password used to compute =
this MAC SHOULD be used only once."

As I said in my previous response, I think that a second use maght be =
needed when connections fail.


> 3. Security Considerations:
>=20
> I would cite a different paper: Pathirana, Amila & Halgamuge, Malka & =
Syed, Ali: "Energy Efficient Bitcoin Mining to Maximize the Mining =
Profit: Using Data from 119 Bitcoin Mining Hardware Setups", =
International Conference on Advances in Business Management and =
Information Technology Istanbul, Turkey (2019).

I have now taken a look at this paper, and it is a good fit.  I will =
cite this paper.

Russ


From nobody Thu Dec 17 22:55:24 2020
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 D8FBB3A1082 for ; Thu, 17 Dec 2020 22:55:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=J0GTz9RH; dkim=pass (1024-bit key) header.d=primekey.com header.b=J0GTz9RH
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 U2GrhWs-2t-c for ; Thu, 17 Dec 2020 22:55:19 -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 BDACF3A1060 for ; Thu, 17 Dec 2020 22:55:17 -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 73C3C6AA5D04 for ; Fri, 18 Dec 2020 07:55:14 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1608274514; bh=4sH/v3i7v3s9xuja7rszzMcGdWAp3ZA0IG3LEH9SkYA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=J0GTz9RH7/7USjAOA5X/ke03CTyfECcbQrloIW7y3M3ZRNhH0I3byTlvu7RS9cDl7 Ss7ogPzASufn32gsWTsUGlpVqXFeOjybf2XG2o1LoZinkzMKOQx941UhiA2PiGnREY GbmakHDfZH3XILElpo6rG3u5h5RreO5EpfMkxOYw=
Received: from [192.168.1.113] (unknown [85.24.187.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id 544756AA5D02 for ; Fri, 18 Dec 2020 07:55:14 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1608274514; bh=4sH/v3i7v3s9xuja7rszzMcGdWAp3ZA0IG3LEH9SkYA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=J0GTz9RH7/7USjAOA5X/ke03CTyfECcbQrloIW7y3M3ZRNhH0I3byTlvu7RS9cDl7 Ss7ogPzASufn32gsWTsUGlpVqXFeOjybf2XG2o1LoZinkzMKOQx941UhiA2PiGnREY GbmakHDfZH3XILElpo6rG3u5h5RreO5EpfMkxOYw=
To: spasm@ietf.org
References:  <787D6A06-002B-4008-8379-AC4A87A7B2C7@vigilsec.com>
From: Tomas Gustavsson 
Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= xsBNBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAHNMFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPsLA dwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5zsBNBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAHCwF8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw==
Message-ID: 
Date: Fri, 18 Dec 2020 07:55:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <787D6A06-002B-4008-8379-AC4A87A7B2C7@vigilsec.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2020 06:55:24 -0000

Perhaps a stupid question. Is Password-Based Proof-of-possession
something used in practice? I at east have not seen it's use within PKI
(for certificate enrollment).

Cheers,
Tomas

On 2020-12-18 00:48, Russ Housley wrote:
> Hans:
> 
>> After discussing the topics internally with Hendrik, there are some concerns left:
>>
>> 1. Iteration count:
>>
>> NEW:
>>
>>      iterationCount identifies the number of times the hash is applied
>>      during the key computation process.  The iterationCount MUST be a
>>      least 10,000 [NISTSP800-63B].  There is a trade off between
>>      protection of the password from attacks and the time spent by the
>>      server processing the iterations.
>>
>> Please note that the cited NIST publication does *not* say that iteration count must be at least 10,000. Actually, it states:
>>
>>    Therefore, the iteration count SHOULD be as large as
>>    Verification server performance will allow, typically at least 10,000 iterations.
>>
>> The difference is subtle, but important. 10,000 merely is an estimate on what typical servers will be able to process. However, the important part is "SHOULD be as large as [...] performance will allow". This is due to the fact that even much higher iteration counts will not prevent an attacker from breaking a low-entropy password in an offline attack. NIST also knows this, and for this reason they continue:
>>
>>    In addition, verifiers SHOULD perform an additional iteration of a key
>>    derivation function using a salt value that is secret and known only to
>>    the verifier.
>>
>> However, the secret salt is not an option in the use case discussed here (it can only be used for storing password verifiers, not for password based key generation).
>>
>> So IMHO it is not ok to cite the NIST SP in order to recommend 10,000 iterations as an acceptable minimum.
>>
>> [[[
>> Let me just explain why this iteration count of 10,000 should be considered insecure.
>>
>> Assume that the password has an entropy of 35 bits (*), and you use an iteration count of 10,000. Further assume that the attacker has an ASIC based hash machine, similar to one used for Bitcoin mining, with a hash rate of 14 Thash/second, i.e. 14e12 hashes per second (commercially available for USD 3000).
>>
>> The time it takes to break the password is then
>>
>>    t_pwd = 2^35 * 10,000 hashes / 14e12 hashes per second = 25 seconds
>>
>> I would assume that this is a realistic threat, even for online attacks.
>>
>> On the other hand, a typical server CPU can calculate about 10-100 M hashes per second, i.e. 1e7 to 1e8 hashes per second. Allowing for a password verification time of one second, this allows for an iteration count of 10,000,000 to 100,000,000. This is the number you should choose according to the NIST recommendation. Note that this choice will make online attacks difficult.
>>
>> (*) The entropy of a typical password (chosen by a human) is difficult to assess. There is a paper from 2007 by Florencio et al [1] which calculates 40.5 bits as _mean_ entropy, but also newer research [2] which shows that 50% of real-world passwords can be broken with less than 150,000,000 trials, indicating a much lower _median_ entropy (27 bits).
>>
>> [1] Florencio, Dinei; Herley, Cormac (May 8, 2007). http://research.microsoft.com/pubs/74164/www2007.pdf, Proceeds of the International World Wide Web Conference Committee
>>
>> [2] DellÂ’Amico, Matteo & Michiardi, Pietro & Roudier, Yves. (2010). Password Strength: An Empirical Analysis. Proceedings of INFOCOM 2010. 1 - 9. 10.1109/INFCOM.2010.5461951.
>> ]]]
> 
> I suggest:
> 
>       iterationCount identifies the number of times the hash is applied
>       during the key computation process.  The iterationCount MUST be a
>       minimum of 100; however, the iterationCount SHOULD be as large as
>       server performance will allow, typically at least 10,000
>       [NISTSP800-63B].  There is a trade off between protection of the
>       password from attacks and the time spent by the server processing
>       the iterations.
> 
> 
>> 2. One-time passwords
>>
>> NEW:
>>     The password used
>>      to compute this MAC SHOULD NOT be used for any other purpose.
>>
>> Please note that while a password should in general be used for only a single purpose, due to the weakness of the password based MAC, in the use case under consideration it should really be used only *once*. This is the only way to thwart offline attacks.
>>
>> I would suggest to use the formulation: "The password used to compute this MAC SHOULD be used only once."
> 
> As I said in my previous response, I think that a second use maght be needed when connections fail.
> 
> 
>> 3. Security Considerations:
>>
>> I would cite a different paper: Pathirana, Amila & Halgamuge, Malka & Syed, Ali: "Energy Efficient Bitcoin Mining to Maximize the Mining Profit: Using Data from 119 Bitcoin Mining Hardware Setups", International Conference on Advances in Business Management and Information Technology Istanbul, Turkey (2019).
> 
> I have now taken a look at this paper, and it is a good fit.  I will cite this paper.
> 
> Russ
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
> 


From nobody Thu Dec 17 23:00:22 2020
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 4508E3A1083 for ; Thu, 17 Dec 2020 23:00:21 -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_MSPIKE_H2=-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=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 uUuhrZUnPvnk for ; Thu, 17 Dec 2020 23:00:19 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130047.outbound.protection.outlook.com [40.107.13.47]) (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 8CB273A07A9 for ; Thu, 17 Dec 2020 23:00:18 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MzE0nBnNFm6hwrRGXUW8aQaRRzkE/UkQ/twSU7/B19qCyEtjSSxsZj81O6Q6HVzdt2iRy5eOBtMsf8fyQyk61WBEKiqxb25gz+OUstPrCIt0lMB40dailHB7cPywX+km/+Al+BVIJ6ndxLOqp8Yd/HBCXhEJUg8ZBKikBNgsG5s49mEreqvXJI8u7vEV2akdK5xi8dcNMGVzfasxlAVUjt2KSAhoFjvKuJ8y37o8oZFXF5OtVF2xSAEwpiaKQTKtMf8dkOe+K7QnFLY4iwnusr4UEbMS+nsOrhVZzb7Qp0uRNxy8uDwccK9iT0jzZGW4c+Nl0aFu5lpZbf29bysKpg==
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=wJh8SoF7DwBjJ8bLDOMk8u4jgtKh9HrWNj54IIqLAPs=; b=EmzscoRTCMweTgBmnv7ae14qFMI19Up+jQ6/BiHRwydNJ1Jk8jBOH7i1zZHbM7wgflqowYnNJOxdIsXOoxGcyfmaa7vUBYFg8QFQyBcdB3HwZLgLiZCp5n5LdLKB+Kw3TnqsT7VI7ChGueQBcZcmFHpf6XT//j9E4OQRZPnT3ui1J1j0ZQCf0AsdOQHRYHB6LUbeZOef3kEKknrKFL1A9G95KpYFHyKrEa8vlf+EiDkicrkGqVcalE2NE/zb+mwyVNTZKHa2rPB5/KYM05iziJNgbUioMNfNbMhCyF7isAisskjjUzae3ns7G+5meyweOtsncnfr65cFGfDdgU9bTw==
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=wJh8SoF7DwBjJ8bLDOMk8u4jgtKh9HrWNj54IIqLAPs=; b=oBqfjg/cMoFUQcDk2ZpuRljKGY9MNAYairDztaGP15o2VurS/oLrCd46KeySujjgKXEvSYDa/sXM0u28jd5xdI7zgBsODhfJwvBzNezPEmCg+1SZ0Icc/pscCNcCp6xChGgSh390AS1JobRpiRE1dOi2KGhVzb0G2diwM6ZGIqo=
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM8PR10MB4049.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:1ef::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.25; Fri, 18 Dec 2020 07:00:15 +0000
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69%7]) with mapi id 15.20.3654.024; Fri, 18 Dec 2020 07:00:15 +0000
From: "Brockhaus, Hendrik" 
To: Tomas Gustavsson , "spasm@ietf.org" 
Thread-Topic: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
Thread-Index: AdbP1vUv/UMIlgi1CUSbFvZhLrxU4AE+DCGAAA7lqAAAABH1IA==
Date: Fri, 18 Dec 2020 07:00:15 +0000
Message-ID: 
References:  <787D6A06-002B-4008-8379-AC4A87A7B2C7@vigilsec.com> 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-12-18T07:00:14Z;  MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=562cfb74-85d1-4632-bb19-94217988479b; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
authentication-results: primekey.com; dkim=none (message not signed) header.d=none;primekey.com; dmarc=none action=none header.from=siemens.com;
x-originating-ip: [165.225.200.157]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 653e0619-89bb-413b-60fd-08d8a32292c1
x-ms-traffictypediagnostic: AM8PR10MB4049:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:6108;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 0ZE2AMyoVgGb8xoFzdOllNxrHBvJ2XQHdI9hO0VP2XaguA9C0gCAXzyI56fv3YIVUAziVR3MDXUM8WmGM+YXpVfs8sjE0tHi2Lggm3f4LE87Tol5Ib+2I4BIoh7ovKxAVDfE37jLsgkvcAn3ljZyCCGBDzum3uZu8gGcS4/gUa4MyzzO2ujJkTkklPHC/VFOEfNZcICiiOwKn/bSNyrd+zBiKXQds8fsS6n9czYouQcjyCGwhgIGObs65I4U3AlaEMwhOovZOqG8M13Jka+SDPHu25WOZY9wSTHQGzQhGXdfkmalrB29V26K54QmYSVnkko3LM/iCa8+baxv9PzDC6+9LDKYCXX4wJl2yApwdqhccDxRZNHJnUCGVB2/ZOQ//dbQbOJpBDQMnE0tMoL7iazBxWhSgdoXb/H+kcQMezbPbHJmwEAf/rSKSCKaMej76QSMSrUxivcEgJutWMNeGA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(4636009)(376002)(346002)(396003)(39860400002)(366004)(136003)(7696005)(55236004)(316002)(66946007)(66556008)(110136005)(66446008)(64756008)(76116006)(8936002)(71200400001)(33656002)(86362001)(53546011)(6506007)(52536014)(4001150100001)(83380400001)(66476007)(966005)(8676002)(15650500001)(5660300002)(55016002)(2906002)(66574015)(9686003)(186003)(45080400002)(26005)(478600001); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?kdBgf6yrNpMxRDiakqC633Gm5QWMizQzg4I1rXsCzZ6zbVVmiaXAqQwUlS?= =?iso-8859-1?Q?/0ASi1XgLtA3q7nnQNBuCrs+c+pvNIY/FDG3kO5zTD8SQ4nl5jRaXPaV7H?= =?iso-8859-1?Q?epFzkpnMiQCeBs9s3vPZJqnyZ2ltYoX6hJHmSJp4LhqmMmivsbiQSMZxRn?= =?iso-8859-1?Q?hMYEAw8dbvzq7UCBbJZlufalxMD6ufGBYV8aAPSDi+YAFm5F8G4q0/qv/E?= =?iso-8859-1?Q?OScSNNpwJpo/3dDGx4T/BHKoteXDyctD1zeMtJthr/gV5oPZgeGTH+qq35?= =?iso-8859-1?Q?Yuzo1RsyRt9Y9+R5yTKEU1/LMLjr2LS4LXj/dhrFt5Nk1eD9zBpAWxkBa9?= =?iso-8859-1?Q?uShviQPlhH8f26lOy05Lj8tePEwJ9llTIzsmtJLF21BotVBlgImd9UlXKO?= =?iso-8859-1?Q?nLwOUCOei4ViM/qOKY+8sdzNQ7EKEHYpBmVdO/aIdAgicYyVsGimEeMMzL?= =?iso-8859-1?Q?DkZdqD97QDm0kwAhXOm5RZJKxBo9gbdBDhzPg91ntjog9vuPPp8Oz4dvdY?= =?iso-8859-1?Q?jzOM8h153i606A01tm9or3F7cI4mg1I05VDPtCcLRtBMd31j7dVoR55pxe?= =?iso-8859-1?Q?1i/Ova+FF10Z9sweshAak982MQSMgWic5wYff6Jn+425hgxrJTqIVCuvJx?= =?iso-8859-1?Q?U2k8kt7XQbecnPgBY9a/tANBTMqTGALAN9/RX1Fw5tssrtcmOM/XG0NibE?= =?iso-8859-1?Q?atk2otTMcBK99138ORPnJHSK8s9U06MysEm+eyrTpzcAwePSKO4yQ9l7Wm?= =?iso-8859-1?Q?65pAD+RqnQTWaf2vyM/pU/iq896ztHuhxBoabpHN9wlrcFk4JKSqBmxDF1?= =?iso-8859-1?Q?hDwZBfV5f9KUz9/pOkro3xYWhB89qf2J91piTVLJupvRAxiGh0bciv9hA0?= =?iso-8859-1?Q?I8pnR48IQskO+C8J/g2G0irlmJ0WlZ0/RLT86GgQebg8QB65QkcOJJP2lA?= =?iso-8859-1?Q?vYHzBExAZfKxcqqMocWVFn8QYircf7lkQX4QDZY22NMHtp4UiRQdgC0g8g?= =?iso-8859-1?Q?X0mRwO+iJBjqk6ieUjNB/l1WGjxKU9c4wStMpj?=
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-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 653e0619-89bb-413b-60fd-08d8a32292c1
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2020 07:00:15.8697 (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: e9mrqaF4SiK7sWzQUw5YyuaB43oCQERJt1ajCU10pUAe0sRMi/zrWazOhtCiId61hwqGlSQEohCp7eJrlFLiIiFDEPR42/LLifG3MW3y2bc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR10MB4049
Archived-At: 
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2020 07:00:21 -0000

Hi Tomas

I haven't seen password based POP.
I am just aware of password based MAC (not POP) for CMP message protection,=
 e.g., as specified in UNISIG Subset-137.

Hendrik

> -----Urspr=FCngliche Nachricht-----
> Von: Spasm  Im Auftrag von Tomas Gustavsson
> Gesendet: Freitag, 18. Dezember 2020 07:55
> An: spasm@ietf.org
> Betreff: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
>=20
>=20
> Perhaps a stupid question. Is Password-Based Proof-of-possession
> something used in practice? I at east have not seen it's use within PKI (=
for
> certificate enrollment).
>=20
> Cheers,
> Tomas
>=20
> On 2020-12-18 00:48, Russ Housley wrote:
> > Hans:
> >
> >> After discussing the topics internally with Hendrik, there are some
> concerns left:
> >>
> >> 1. Iteration count:
> >>
> >> NEW:
> >>
> >>      iterationCount identifies the number of times the hash is applied
> >>      during the key computation process.  The iterationCount MUST be a
> >>      least 10,000 [NISTSP800-63B].  There is a trade off between
> >>      protection of the password from attacks and the time spent by the
> >>      server processing the iterations.
> >>
> >> Please note that the cited NIST publication does *not* say that iterat=
ion
> count must be at least 10,000. Actually, it states:
> >>
> >>    Therefore, the iteration count SHOULD be as large as
> >>    Verification server performance will allow, typically at least 10,0=
00
> iterations.
> >>
> >> The difference is subtle, but important. 10,000 merely is an estimate =
on
> what typical servers will be able to process. However, the important part=
 is
> "SHOULD be as large as [...] performance will allow". This is due to the =
fact
> that even much higher iteration counts will not prevent an attacker from
> breaking a low-entropy password in an offline attack. NIST also knows thi=
s,
> and for this reason they continue:
> >>
> >>    In addition, verifiers SHOULD perform an additional iteration of a =
key
> >>    derivation function using a salt value that is secret and known onl=
y to
> >>    the verifier.
> >>
> >> However, the secret salt is not an option in the use case discussed he=
re (it
> can only be used for storing password verifiers, not for password based k=
ey
> generation).
> >>
> >> So IMHO it is not ok to cite the NIST SP in order to recommend 10,000
> iterations as an acceptable minimum.
> >>
> >> [[[
> >> Let me just explain why this iteration count of 10,000 should be
> considered insecure.
> >>
> >> Assume that the password has an entropy of 35 bits (*), and you use an
> iteration count of 10,000. Further assume that the attacker has an ASIC b=
ased
> hash machine, similar to one used for Bitcoin mining, with a hash rate of=
 14
> Thash/second, i.e. 14e12 hashes per second (commercially available for US=
D
> 3000).
> >>
> >> The time it takes to break the password is then
> >>
> >>    t_pwd =3D 2^35 * 10,000 hashes / 14e12 hashes per second =3D 25
> >> seconds
> >>
> >> I would assume that this is a realistic threat, even for online attack=
s.
> >>
> >> On the other hand, a typical server CPU can calculate about 10-100 M
> hashes per second, i.e. 1e7 to 1e8 hashes per second. Allowing for a
> password verification time of one second, this allows for an iteration co=
unt of
> 10,000,000 to 100,000,000. This is the number you should choose according=
 to
> the NIST recommendation. Note that this choice will make online attacks
> difficult.
> >>
> >> (*) The entropy of a typical password (chosen by a human) is difficult=
 to
> assess. There is a paper from 2007 by Florencio et al [1] which calculate=
s 40.5
> bits as _mean_ entropy, but also newer research [2] which shows that 50%
> of real-world passwords can be broken with less than 150,000,000 trials,
> indicating a much lower _median_ entropy (27 bits).
> >>
> >> [1] Florencio, Dinei; Herley, Cormac (May 8, 2007).
> >>
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Frese
> >>
> arch.microsoft.com%2Fpubs%2F74164%2Fwww2007.pdf&data=3D04%7C0
> 1%7Che
> >>
> ndrik.brockhaus%40siemens.com%7Cae7f9c46e5424d5e615e08d8a321eb64%
> 7C38
> >>
> ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637438713379882182%7CU
> nknown
> >>
> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLC
> >>
> JXVCI6Mn0%3D%7C1000&sdata=3DbairHiBk5lbBrNgav8N89Wz2H3VcnuJvI
> %2BfU0
> >> aI2k1E%3D&reserved=3D0, Proceeds of the International World Wide
> >> Web Conference Committee
> >>
> >> [2] Dell=92Amico, Matteo & Michiardi, Pietro & Roudier, Yves. (2010).
> Password Strength: An Empirical Analysis. Proceedings of INFOCOM 2010. 1 =
-
> 9. 10.1109/INFCOM.2010.5461951.
> >> ]]]
> >
> > I suggest:
> >
> >       iterationCount identifies the number of times the hash is applied
> >       during the key computation process.  The iterationCount MUST be a
> >       minimum of 100; however, the iterationCount SHOULD be as large as
> >       server performance will allow, typically at least 10,000
> >       [NISTSP800-63B].  There is a trade off between protection of the
> >       password from attacks and the time spent by the server processing
> >       the iterations.
> >
> >
> >> 2. One-time passwords
> >>
> >> NEW:
> >>     The password used
> >>      to compute this MAC SHOULD NOT be used for any other purpose.
> >>
> >> Please note that while a password should in general be used for only a
> single purpose, due to the weakness of the password based MAC, in the use
> case under consideration it should really be used only *once*. This is th=
e only
> way to thwart offline attacks.
> >>
> >> I would suggest to use the formulation: "The password used to compute
> this MAC SHOULD be used only once."
> >
> > As I said in my previous response, I think that a second use maght be
> needed when connections fail.
> >
> >
> >> 3. Security Considerations:
> >>
> >> I would cite a different paper: Pathirana, Amila & Halgamuge, Malka &
> Syed, Ali: "Energy Efficient Bitcoin Mining to Maximize the Mining Profit=
:
> Using Data from 119 Bitcoin Mining Hardware Setups", International
> Conference on Advances in Business Management and Information
> Technology Istanbul, Turkey (2019).
> >
> > I have now taken a look at this paper, and it is a good fit.  I will ci=
te this
> paper.
> >
> > Russ
> >
> > _______________________________________________
> > Spasm mailing list
> > Spasm@ietf.org
> >
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
> .
> >
> ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D04%7C01%7Chendrik.b
> rock
> >
> haus%40siemens.com%7Cae7f9c46e5424d5e615e08d8a321eb64%7C38ae3bc
> d95794f
> >
> d4addab42e1495d55a%7C1%7C0%7C637438713379882182%7CUnknown%7CT
> WFpbGZsb3
> >
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7
> >
> C1000&sdata=3D9eADDQ8voM8GgKPwZrUngK4mQrrk04uA5luLsf%2FrDI4
> %3D&r
> > eserved=3D0
> >
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D04%7C01%7Chendrik.
> brockhaus%40siemens.com%7Cae7f9c46e5424d5e615e08d8a321eb64%7C38
> ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637438713379882182%7CU
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> 6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D9eADDQ8voM8GgKPwZr
> UngK4mQrrk04uA5luLsf%2FrDI4%3D&reserved=3D0


From nobody Fri Dec 18 00:30:08 2020
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 D67633A1161 for ; Fri, 18 Dec 2020 00:30:06 -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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 K0NVHTU8OWZb for ; Fri, 18 Dec 2020 00:30:04 -0800 (PST)
Received: from server8.webgo24.de (server8.webgo24.de [185.30.32.8]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADAFE3A115F for ; Fri, 18 Dec 2020 00:30:02 -0800 (PST)
Received: from [192.168.178.44] (dynamic-077-009-085-032.77.9.pool.telefonica.de [77.9.85.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by server8.webgo24.de (Postfix) with ESMTPSA id A8F3E4218B2; Fri, 18 Dec 2020 09:29:57 +0100 (CET)
To: "Brockhaus, Hendrik" , Tomas Gustavsson 
References:  <787D6A06-002B-4008-8379-AC4A87A7B2C7@vigilsec.com>  
Cc: "spasm@ietf.org" 
From: David von Oheimb 
Message-ID: <7d7f76ea-6483-9803-eed3-7296181f4754@von-Oheimb.de>
Date: Fri, 18 Dec 2020 09:29:56 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------F2AE371404CC0571B5B4700B"
Content-Language: en-US
Archived-At: 
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2020 08:30:07 -0000

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

It depends on: proof-of-possession (POP) for what?
For private (asymmetric) keys, a password-based POP makes no sense.
Yet any successful use of a password is a POP for that password.

    David

On 18.12.20 08:00, Brockhaus, Hendrik wrote:
> Hi Tomas
>
> I haven't seen password based POP.
> I am just aware of password based MAC (not POP) for CMP message protection, e.g., as specified in UNISIG Subset-137.
>
> Hendrik
>
>> -----Ursprüngliche Nachricht-----
>> Von: Spasm  Im Auftrag von Tomas Gustavsson
>> Gesendet: Freitag, 18. Dezember 2020 07:55
>> An: spasm@ietf.org
>> Betreff: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
>>
>>
>> Perhaps a stupid question. Is Password-Based Proof-of-possession
>> something used in practice? I at least have not seen it's use within PKI (for
>> certificate enrollment).
>>
>> Cheers,
>> Tomas
>>
>> On 2020-12-18 00:48, Russ Housley wrote:
>>> Hans:
>>>
>>>> After discussing the topics internally with Hendrik, there are some
>> concerns left:
>>>> 1. Iteration count:
>>>>
>>>> NEW:
>>>>
>>>>      iterationCount identifies the number of times the hash is applied
>>>>      during the key computation process.  The iterationCount MUST be a
>>>>      least 10,000 [NISTSP800-63B].  There is a trade off between
>>>>      protection of the password from attacks and the time spent by the
>>>>      server processing the iterations.
>>>>
>>>> Please note that the cited NIST publication does *not* say that iteration
>> count must be at least 10,000. Actually, it states:
>>>>    Therefore, the iteration count SHOULD be as large as
>>>>    Verification server performance will allow, typically at least 10,000
>> iterations.
>>>> The difference is subtle, but important. 10,000 merely is an estimate on
>> what typical servers will be able to process. However, the important part is
>> "SHOULD be as large as [...] performance will allow". This is due to the fact
>> that even much higher iteration counts will not prevent an attacker from
>> breaking a low-entropy password in an offline attack. NIST also knows this,
>> and for this reason they continue:
>>>>    In addition, verifiers SHOULD perform an additional iteration of a key
>>>>    derivation function using a salt value that is secret and known only to
>>>>    the verifier.
>>>>
>>>> However, the secret salt is not an option in the use case discussed here (it
>> can only be used for storing password verifiers, not for password based key
>> generation).
>>>> So IMHO it is not ok to cite the NIST SP in order to recommend 10,000
>> iterations as an acceptable minimum.
>>>> [[[
>>>> Let me just explain why this iteration count of 10,000 should be
>> considered insecure.
>>>> Assume that the password has an entropy of 35 bits (*), and you use an
>> iteration count of 10,000. Further assume that the attacker has an ASIC based
>> hash machine, similar to one used for Bitcoin mining, with a hash rate of 14
>> Thash/second, i.e. 14e12 hashes per second (commercially available for USD
>> 3000).
>>>> The time it takes to break the password is then
>>>>
>>>>    t_pwd = 2^35 * 10,000 hashes / 14e12 hashes per second = 25
>>>> seconds
>>>>
>>>> I would assume that this is a realistic threat, even for online attacks.
>>>>
>>>> On the other hand, a typical server CPU can calculate about 10-100 M
>> hashes per second, i.e. 1e7 to 1e8 hashes per second. Allowing for a
>> password verification time of one second, this allows for an iteration count of
>> 10,000,000 to 100,000,000. This is the number you should choose according to
>> the NIST recommendation. Note that this choice will make online attacks
>> difficult.
>>>> (*) The entropy of a typical password (chosen by a human) is difficult to
>> assess. There is a paper from 2007 by Florencio et al [1] which calculates 40.5
>> bits as _mean_ entropy, but also newer research [2] which shows that 50%
>> of real-world passwords can be broken with less than 150,000,000 trials,
>> indicating a much lower _median_ entropy (27 bits).
>>>> [1] Florencio, Dinei; Herley, Cormac (May 8, 2007).
>>>>
>> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Frese
>> arch.microsoft.com%2Fpubs%2F74164%2Fwww2007.pdf&data=04%7C0
>> 1%7Che
>> ndrik.brockhaus%40siemens.com%7Cae7f9c46e5424d5e615e08d8a321eb64%
>> 7C38
>> ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637438713379882182%7CU
>> nknown
>> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
>> WwiLC
>> JXVCI6Mn0%3D%7C1000&sdata=bairHiBk5lbBrNgav8N89Wz2H3VcnuJvI
>> %2BfU0
>>>> aI2k1E%3D&reserved=0, Proceeds of the International World Wide
>>>> Web Conference Committee
>>>>
>>>> [2] Dell’Amico, Matteo & Michiardi, Pietro & Roudier, Yves. (2010).
>> Password Strength: An Empirical Analysis. Proceedings of INFOCOM 2010. 1 -
>> 9. 10.1109/INFCOM.2010.5461951.
>>>> ]]]
>>> I suggest:
>>>
>>>       iterationCount identifies the number of times the hash is applied
>>>       during the key computation process.  The iterationCount MUST be a
>>>       minimum of 100; however, the iterationCount SHOULD be as large as
>>>       server performance will allow, typically at least 10,000
>>>       [NISTSP800-63B].  There is a trade off between protection of the
>>>       password from attacks and the time spent by the server processing
>>>       the iterations.
>>>
>>>
>>>> 2. One-time passwords
>>>>
>>>> NEW:
>>>>     The password used
>>>>      to compute this MAC SHOULD NOT be used for any other purpose.
>>>>
>>>> Please note that while a password should in general be used for only a
>> single purpose, due to the weakness of the password based MAC, in the use
>> case under consideration it should really be used only *once*. This is the only
>> way to thwart offline attacks.
>>>> I would suggest to use the formulation: "The password used to compute
>> this MAC SHOULD be used only once."
>>> As I said in my previous response, I think that a second use maght be
>> needed when connections fail.
>>>
>>>> 3. Security Considerations:
>>>>
>>>> I would cite a different paper: Pathirana, Amila & Halgamuge, Malka &
>> Syed, Ali: "Energy Efficient Bitcoin Mining to Maximize the Mining Profit:
>> Using Data from 119 Bitcoin Mining Hardware Setups", International
>> Conference on Advances in Business Management and Information
>> Technology Istanbul, Turkey (2019).
>>> I have now taken a look at this paper, and it is a good fit.  I will cite this
>> paper.
>>> Russ
>>>
>>> _______________________________________________
>>> Spasm mailing list
>>> Spasm@ietf.org
>>>
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .
>> ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.b
>> rock
>> haus%40siemens.com%7Cae7f9c46e5424d5e615e08d8a321eb64%7C38ae3bc
>> d95794f
>> d4addab42e1495d55a%7C1%7C0%7C637438713379882182%7CUnknown%7CT
>> WFpbGZsb3
>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
>> %3D%7
>> C1000&sdata=9eADDQ8voM8GgKPwZrUngK4mQrrk04uA5luLsf%2FrDI4
>> %3D&r
>>> eserved=0
>>>
>> _______________________________________________
>> Spasm mailing list
>> Spasm@ietf.org
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.
>> brockhaus%40siemens.com%7Cae7f9c46e5424d5e615e08d8a321eb64%7C38
>> ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637438713379882182%7CU
>> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
>> 6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9eADDQ8voM8GgKPwZr
>> UngK4mQrrk04uA5luLsf%2FrDI4%3D&reserved=0
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>

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


  
    
  
  
    
It depends on: proof-of-possession (POP) for what?

      For private (asymmetric) keys, a password-based POP makes no
      sense.

      Yet any successful use of a password is a POP for that password.

    
    David

    

    
On 18.12.20 08:00, Brockhaus, Hendrik
      wrote:

    

    

      
Hi Tomas

I haven't seen password based POP.
I am just aware of password based MAC (not POP) for CMP message protection, e.g., as specified in UNISIG Subset-137.

Hendrik



      

        
-----Ursprüngliche Nachricht-----
Von: Spasm <spasm-bounces@ietf.org> Im Auftrag von Tomas Gustavsson
Gesendet: Freitag, 18. Dezember 2020 07:55
An: spasm@ietf.org
Betreff: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt


Perhaps a stupid question. Is Password-Based Proof-of-possession
something used in practice? I at least have not seen it's use within PKI (for
certificate enrollment).

Cheers,
Tomas

On 2020-12-18 00:48, Russ Housley wrote:


        

          
Hans:



          

            
After discussing the topics internally with Hendrik, there are some


          

        

        
concerns left:


        

          

            
1. Iteration count:

NEW:

     iterationCount identifies the number of times the hash is applied
     during the key computation process.  The iterationCount MUST be a
     least 10,000 [NISTSP800-63B].  There is a trade off between
     protection of the password from attacks and the time spent by the
     server processing the iterations.

Please note that the cited NIST publication does *not* say that iteration


          

        

        
count must be at least 10,000. Actually, it states:


        

          

            
   Therefore, the iteration count SHOULD be as large as
   Verification server performance will allow, typically at least 10,000


          

        

        
iterations.


        

          

            
The difference is subtle, but important. 10,000 merely is an estimate on


          

        

        
what typical servers will be able to process. However, the important part is
"SHOULD be as large as [...] performance will allow". This is due to the fact
that even much higher iteration counts will not prevent an attacker from
breaking a low-entropy password in an offline attack. NIST also knows this,
and for this reason they continue:


        

          

            
   In addition, verifiers SHOULD perform an additional iteration of a key
   derivation function using a salt value that is secret and known only to
   the verifier.

However, the secret salt is not an option in the use case discussed here (it


          

        

        
can only be used for storing password verifiers, not for password based key
generation).


        

          

            
So IMHO it is not ok to cite the NIST SP in order to recommend 10,000


          

        

        
iterations as an acceptable minimum.


        

          

            
[[[
Let me just explain why this iteration count of 10,000 should be


          

        

        
considered insecure.


        

          

            
Assume that the password has an entropy of 35 bits (*), and you use an


          

        

        
iteration count of 10,000. Further assume that the attacker has an ASIC based
hash machine, similar to one used for Bitcoin mining, with a hash rate of 14
Thash/second, i.e. 14e12 hashes per second (commercially available for USD
3000).


        

          

            
The time it takes to break the password is then

   t_pwd = 2^35 * 10,000 hashes / 14e12 hashes per second = 25
seconds

I would assume that this is a realistic threat, even for online attacks.

On the other hand, a typical server CPU can calculate about 10-100 M


          

        

        
hashes per second, i.e. 1e7 to 1e8 hashes per second. Allowing for a
password verification time of one second, this allows for an iteration count of
10,000,000 to 100,000,000. This is the number you should choose according to
the NIST recommendation. Note that this choice will make online attacks
difficult.


        

          

            
(*) The entropy of a typical password (chosen by a human) is difficult to


          

        

        
assess. There is a paper from 2007 by Florencio et al [1] which calculates 40.5
bits as _mean_ entropy, but also newer research [2] which shows that 50%
of real-world passwords can be broken with less than 150,000,000 trials,
indicating a much lower _median_ entropy (27 bits).


        

          

            
[1] Florencio, Dinei; Herley, Cormac (May 8, 2007).



          

        

        
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Frese


        

          

            

          

        

        
arch.microsoft.com%2Fpubs%2F74164%2Fwww2007.pdf&amp;data=04%7C0
1%7Che


        

          

            

          

        

        
ndrik.brockhaus%40siemens.com%7Cae7f9c46e5424d5e615e08d8a321eb64%
7C38


        

          

            

          

        

        
ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637438713379882182%7CU
nknown


        

          

            

          

        

        
%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
WwiLC


        

          

            

          

        

        
JXVCI6Mn0%3D%7C1000&amp;sdata=bairHiBk5lbBrNgav8N89Wz2H3VcnuJvI
%2BfU0


        

          

            
aI2k1E%3D&amp;reserved=0, Proceeds of the International World Wide
Web Conference Committee

[2] Dell’Amico, Matteo & Michiardi, Pietro & Roudier, Yves. (2010).


          

        

        
Password Strength: An Empirical Analysis. Proceedings of INFOCOM 2010. 1 -
9. 10.1109/INFCOM.2010.5461951.


        

          

            
]]]


          

          
I suggest:

      iterationCount identifies the number of times the hash is applied
      during the key computation process.  The iterationCount MUST be a
      minimum of 100; however, the iterationCount SHOULD be as large as
      server performance will allow, typically at least 10,000
      [NISTSP800-63B].  There is a trade off between protection of the
      password from attacks and the time spent by the server processing
      the iterations.




          

            
2. One-time passwords

NEW:
    The password used
     to compute this MAC SHOULD NOT be used for any other purpose.

Please note that while a password should in general be used for only a


          

        

        
single purpose, due to the weakness of the password based MAC, in the use
case under consideration it should really be used only *once*. This is the only
way to thwart offline attacks.


        

          

            
I would suggest to use the formulation: "The password used to compute


          

        

        
this MAC SHOULD be used only once."


        

          
As I said in my previous response, I think that a second use maght be


        

        
needed when connections fail.


        

          



          

            
3. Security Considerations:

I would cite a different paper: Pathirana, Amila & Halgamuge, Malka &


          

        

        
Syed, Ali: "Energy Efficient Bitcoin Mining to Maximize the Mining Profit:
Using Data from 119 Bitcoin Mining Hardware Setups", International
Conference on Advances in Business Management and Information
Technology Istanbul, Turkey (2019).


        

          
I have now taken a look at this paper, and it is a good fit.  I will cite this


        

        
paper.


        

          
Russ

_______________________________________________
Spasm mailing list
Spasm@ietf.org



        

        
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
.


        

          

        

        
ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Chendrik.b
rock


        

          

        

        
haus%40siemens.com%7Cae7f9c46e5424d5e615e08d8a321eb64%7C38ae3bc
d95794f


        

          

        

        
d4addab42e1495d55a%7C1%7C0%7C637438713379882182%7CUnknown%7CT
WFpbGZsb3


        

          

        

        
d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
%3D%7


        

          

        

        
C1000&amp;sdata=9eADDQ8voM8GgKPwZrUngK4mQrrk04uA5luLsf%2FrDI4
%3D&amp;r


        

          
eserved=0



        

        
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
.ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Chendrik.
brockhaus%40siemens.com%7Cae7f9c46e5424d5e615e08d8a321eb64%7C38
ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637438713379882182%7CU
nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9eADDQ8voM8GgKPwZr
UngK4mQrrk04uA5luLsf%2FrDI4%3D&amp;reserved=0


      

      
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm



    

  


--------------F2AE371404CC0571B5B4700B--


From nobody Fri Dec 18 00:44:55 2020
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 BC9B23A117B for ; Fri, 18 Dec 2020 00:44:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=LFv6mrml; dkim=pass (1024-bit key) header.d=primekey.com header.b=LFv6mrml
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 SMC80iJRki1S for ; Fri, 18 Dec 2020 00:44:51 -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 0F5F43A1175 for ; Fri, 18 Dec 2020 00:44:50 -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 2788A6AA5D25 for ; Fri, 18 Dec 2020 09:44:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1608281089; bh=qqNfKPCu4O0sTRRWi4paFzaLpsumL9lhNQ7DcQ9wSZg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=LFv6mrmldxQn9wCtq+RIcCiuy12hlvqL5V5IG2rmXtDfvHy2y7L0/KT5UD+viZEc0 C2sAMs7p7w1o3H0LsKRW7iE/p0Z1GNSgwtY0t7gxQDOdouOCc/1ISwYCtfxxamCunM 8iEGqa2uK0Icuv29pDTKSFTLHlyhnJgRX28QshCA=
Received: from [10.11.0.13] (unknown [10.11.0.13]) (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 08F6E6AA553F for ; Fri, 18 Dec 2020 09:44:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1608281089; bh=qqNfKPCu4O0sTRRWi4paFzaLpsumL9lhNQ7DcQ9wSZg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=LFv6mrmldxQn9wCtq+RIcCiuy12hlvqL5V5IG2rmXtDfvHy2y7L0/KT5UD+viZEc0 C2sAMs7p7w1o3H0LsKRW7iE/p0Z1GNSgwtY0t7gxQDOdouOCc/1ISwYCtfxxamCunM 8iEGqa2uK0Icuv29pDTKSFTLHlyhnJgRX28QshCA=
To: spasm@ietf.org
References:  <787D6A06-002B-4008-8379-AC4A87A7B2C7@vigilsec.com>   <7d7f76ea-6483-9803-eed3-7296181f4754@von-Oheimb.de>
From: Tomas Gustavsson 
Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= xsBNBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAHNMFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPsLA dwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5zsBNBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAHCwF8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw==
Message-ID: 
Date: Fri, 18 Dec 2020 09:44:48 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <7d7f76ea-6483-9803-eed3-7296181f4754@von-Oheimb.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2020 08:44:54 -0000

I was just thinking as the HMAC is described in RFC4211 section 4.4,
which is POP.

For CMP there can also be other mitigations, such as the "password"
being a one-time code, in which case an attack on the HMAC pwd in the
message is irrelevant.

Regards,
Tomas


On 2020-12-18 09:29, David von Oheimb wrote:
> It depends on: proof-of-possession (POP) for what?
> For private (asymmetric) keys, a password-based POP makes no sense.
> Yet any successful use of a password is a POP for that password.
> 
>     David
> 
> On 18.12.20 08:00, Brockhaus, Hendrik wrote:
>> Hi Tomas
>>
>> I haven't seen password based POP.
>> I am just aware of password based MAC (not POP) for CMP message protection, e.g., as specified in UNISIG Subset-137.
>>
>> Hendrik
>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Spasm  Im Auftrag von Tomas Gustavsson
>>> Gesendet: Freitag, 18. Dezember 2020 07:55
>>> An: spasm@ietf.org
>>> Betreff: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
>>>
>>>
>>> Perhaps a stupid question. Is Password-Based Proof-of-possession
>>> something used in practice? I at least have not seen it's use within PKI (for
>>> certificate enrollment).
>>>
>>> Cheers,
>>> Tomas
>>>
>>> On 2020-12-18 00:48, Russ Housley wrote:
>>>> Hans:
>>>>
>>>>> After discussing the topics internally with Hendrik, there are some
>>> concerns left:
>>>>> 1. Iteration count:
>>>>>
>>>>> NEW:
>>>>>
>>>>>      iterationCount identifies the number of times the hash is applied
>>>>>      during the key computation process.  The iterationCount MUST be a
>>>>>      least 10,000 [NISTSP800-63B].  There is a trade off between
>>>>>      protection of the password from attacks and the time spent by the
>>>>>      server processing the iterations.
>>>>>
>>>>> Please note that the cited NIST publication does *not* say that iteration
>>> count must be at least 10,000. Actually, it states:
>>>>>    Therefore, the iteration count SHOULD be as large as
>>>>>    Verification server performance will allow, typically at least 10,000
>>> iterations.
>>>>> The difference is subtle, but important. 10,000 merely is an estimate on
>>> what typical servers will be able to process. However, the important part is
>>> "SHOULD be as large as [...] performance will allow". This is due to the fact
>>> that even much higher iteration counts will not prevent an attacker from
>>> breaking a low-entropy password in an offline attack. NIST also knows this,
>>> and for this reason they continue:
>>>>>    In addition, verifiers SHOULD perform an additional iteration of a key
>>>>>    derivation function using a salt value that is secret and known only to
>>>>>    the verifier.
>>>>>
>>>>> However, the secret salt is not an option in the use case discussed here (it
>>> can only be used for storing password verifiers, not for password based key
>>> generation).
>>>>> So IMHO it is not ok to cite the NIST SP in order to recommend 10,000
>>> iterations as an acceptable minimum.
>>>>> [[[
>>>>> Let me just explain why this iteration count of 10,000 should be
>>> considered insecure.
>>>>> Assume that the password has an entropy of 35 bits (*), and you use an
>>> iteration count of 10,000. Further assume that the attacker has an ASIC based
>>> hash machine, similar to one used for Bitcoin mining, with a hash rate of 14
>>> Thash/second, i.e. 14e12 hashes per second (commercially available for USD
>>> 3000).
>>>>> The time it takes to break the password is then
>>>>>
>>>>>    t_pwd = 2^35 * 10,000 hashes / 14e12 hashes per second = 25
>>>>> seconds
>>>>>
>>>>> I would assume that this is a realistic threat, even for online attacks.
>>>>>
>>>>> On the other hand, a typical server CPU can calculate about 10-100 M
>>> hashes per second, i.e. 1e7 to 1e8 hashes per second. Allowing for a
>>> password verification time of one second, this allows for an iteration count of
>>> 10,000,000 to 100,000,000. This is the number you should choose according to
>>> the NIST recommendation. Note that this choice will make online attacks
>>> difficult.
>>>>> (*) The entropy of a typical password (chosen by a human) is difficult to
>>> assess. There is a paper from 2007 by Florencio et al [1] which calculates 40.5
>>> bits as _mean_ entropy, but also newer research [2] which shows that 50%
>>> of real-world passwords can be broken with less than 150,000,000 trials,
>>> indicating a much lower _median_ entropy (27 bits).
>>>>> [1] Florencio, Dinei; Herley, Cormac (May 8, 2007).
>>>>>
>>> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Frese
>>> arch.microsoft.com%2Fpubs%2F74164%2Fwww2007.pdf&data=04%7C0
>>> 1%7Che
>>> ndrik.brockhaus%40siemens.com%7Cae7f9c46e5424d5e615e08d8a321eb64%
>>> 7C38
>>> ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637438713379882182%7CU
>>> nknown
>>> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
>>> WwiLC
>>> JXVCI6Mn0%3D%7C1000&sdata=bairHiBk5lbBrNgav8N89Wz2H3VcnuJvI
>>> %2BfU0
>>>>> aI2k1E%3D&reserved=0, Proceeds of the International World Wide
>>>>> Web Conference Committee
>>>>>
>>>>> [2] Dell’Amico, Matteo & Michiardi, Pietro & Roudier, Yves. (2010).
>>> Password Strength: An Empirical Analysis. Proceedings of INFOCOM 2010. 1 -
>>> 9. 10.1109/INFCOM.2010.5461951.
>>>>> ]]]
>>>> I suggest:
>>>>
>>>>       iterationCount identifies the number of times the hash is applied
>>>>       during the key computation process.  The iterationCount MUST be a
>>>>       minimum of 100; however, the iterationCount SHOULD be as large as
>>>>       server performance will allow, typically at least 10,000
>>>>       [NISTSP800-63B].  There is a trade off between protection of the
>>>>       password from attacks and the time spent by the server processing
>>>>       the iterations.
>>>>
>>>>
>>>>> 2. One-time passwords
>>>>>
>>>>> NEW:
>>>>>     The password used
>>>>>      to compute this MAC SHOULD NOT be used for any other purpose.
>>>>>
>>>>> Please note that while a password should in general be used for only a
>>> single purpose, due to the weakness of the password based MAC, in the use
>>> case under consideration it should really be used only *once*. This is the only
>>> way to thwart offline attacks.
>>>>> I would suggest to use the formulation: "The password used to compute
>>> this MAC SHOULD be used only once."
>>>> As I said in my previous response, I think that a second use maght be
>>> needed when connections fail.
>>>>> 3. Security Considerations:
>>>>>
>>>>> I would cite a different paper: Pathirana, Amila & Halgamuge, Malka &
>>> Syed, Ali: "Energy Efficient Bitcoin Mining to Maximize the Mining Profit:
>>> Using Data from 119 Bitcoin Mining Hardware Setups", International
>>> Conference on Advances in Business Management and Information
>>> Technology Istanbul, Turkey (2019).
>>>> I have now taken a look at this paper, and it is a good fit.  I will cite this
>>> paper.
>>>> Russ
>>>>
>>>> _______________________________________________
>>>> Spasm mailing list
>>>> Spasm@ietf.org
>>>>
>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>>> .
>>> ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.b
>>> rock
>>> haus%40siemens.com%7Cae7f9c46e5424d5e615e08d8a321eb64%7C38ae3bc
>>> d95794f
>>> d4addab42e1495d55a%7C1%7C0%7C637438713379882182%7CUnknown%7CT
>>> WFpbGZsb3
>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
>>> %3D%7
>>> C1000&sdata=9eADDQ8voM8GgKPwZrUngK4mQrrk04uA5luLsf%2FrDI4
>>> %3D&r
>>>> eserved=0
>>>>
>>> _______________________________________________
>>> Spasm mailing list
>>> Spasm@ietf.org
>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>>> .ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.
>>> brockhaus%40siemens.com%7Cae7f9c46e5424d5e615e08d8a321eb64%7C38
>>> ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637438713379882182%7CU
>>> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
>>> 6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9eADDQ8voM8GgKPwZr
>>> UngK4mQrrk04uA5luLsf%2FrDI4%3D&reserved=0
>> _______________________________________________
>> 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 Fri Dec 18 01:03:42 2020
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 16A0E3A1189 for ; Fri, 18 Dec 2020 01:03: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, NICE_REPLY_A=-0.001, 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 CYUb8TLWQt64 for ; Fri, 18 Dec 2020 01:03:39 -0800 (PST)
Received: from server8.webgo24.de (server8.webgo24.de [185.30.32.8]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7CA3A10EC for ; Fri, 18 Dec 2020 01:03:38 -0800 (PST)
Received: from [192.168.178.44] (dynamic-077-009-085-032.77.9.pool.telefonica.de [77.9.85.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by server8.webgo24.de (Postfix) with ESMTPSA id CBFDF4217AA; Fri, 18 Dec 2020 10:03:34 +0100 (CET)
To: Tomas Gustavsson , spasm@ietf.org
References:  <787D6A06-002B-4008-8379-AC4A87A7B2C7@vigilsec.com>   <7d7f76ea-6483-9803-eed3-7296181f4754@von-Oheimb.de> 
From: David von Oheimb 
Message-ID: <997f0203-5fb7-61de-99d5-989d5ff98aeb@von-Oheimb.de>
Date: Fri, 18 Dec 2020 10:03:33 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------2209A5437DC2D7457763DB25"
Content-Language: en-US
Archived-At: 
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2020 09:03:41 -0000

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

Yes,  RFC 4211 section 4.4 describes POP for a password by successful
use of an HMAC
(while section 4.1. is about POP for signature keys, which is the most
common use case).

In the context of certificate management the "password-based POP" is not
needed by itself
because having and proving the possession of a password is not a primary
goal in that context,
but it can be used for PBM-based proof of origin (message protection)
when a client does not have a suitable cert yet.

Regards,

    David

On 18.12.20 09:44, Tomas Gustavsson wrote:
> I was just thinking as the HMAC is described in RFC4211 section 4.4,
> which is POP.
>
> For CMP there can also be other mitigations, such as the "password"
> being a one-time code, in which case an attack on the HMAC pwd in the
> message is irrelevant.
>
> Regards,
> Tomas
>
>
> On 2020-12-18 09:29, David von Oheimb wrote:
>> It depends on: proof-of-possession (POP) for what?
>> For private (asymmetric) keys, a password-based POP makes no sense.
>> Yet any successful use of a password is a POP for that password.
>>
>>     David
>>
>> On 18.12.20 08:00, Brockhaus, Hendrik wrote:
>>> Hi Tomas
>>>
>>> I haven't seen password based POP.
>>> I am just aware of password based MAC (not POP) for CMP message protection, e.g., as specified in UNISIG Subset-137.
>>>
>>> Hendrik
>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Spasm  Im Auftrag von Tomas Gustavsson
>>>> Gesendet: Freitag, 18. Dezember 2020 07:55
>>>> An: spasm@ietf.org
>>>> Betreff: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
>>>>
>>>>
>>>> Perhaps a stupid question. Is Password-Based Proof-of-possession
>>>> something used in practice? I at least have not seen it's use within PKI (for
>>>> certificate enrollment).
>>>>
>>>> Cheers,
>>>> Tomas

--------------2209A5437DC2D7457763DB25
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Yes,  RFC 4211 section 4.4 describes POP for a password by
      successful use of an HMAC

      (while section 4.1. is about POP for signature keys, which is the
      most common use case).

      

      In the context of certificate management the "password-based POP"
      is not needed by itself

      because having and proving the possession of a password is not a
      primary goal in that context,

      but it can be used for PBM-based proof of origin (message
      protection) when a client does not have a suitable cert yet.

    
Regards,

    

    
    David

    

    
On 18.12.20 09:44, Tomas Gustavsson
      wrote:

    

    

      
I was just thinking as the HMAC is described in RFC4211 section 4.4,
which is POP.

For CMP there can also be other mitigations, such as the "password"
being a one-time code, in which case an attack on the HMAC pwd in the
message is irrelevant.

Regards,
Tomas


On 2020-12-18 09:29, David von Oheimb wrote:


      

        
It depends on: proof-of-possession (POP) for what?
For private (asymmetric) keys, a password-based POP makes no sense.
Yet any successful use of a password is a POP for that password.

    David

On 18.12.20 08:00, Brockhaus, Hendrik wrote:


        

          
Hi Tomas

I haven't seen password based POP.
I am just aware of password based MAC (not POP) for CMP message protection, e.g., as specified in UNISIG Subset-137.

Hendrik



          

            
-----Ursprüngliche Nachricht-----
Von: Spasm <spasm-bounces@ietf.org> Im Auftrag von Tomas Gustavsson
Gesendet: Freitag, 18. Dezember 2020 07:55
An: spasm@ietf.org
Betreff: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt


Perhaps a stupid question. Is Password-Based Proof-of-possession
something used in practice? I at least have not seen it's use within PKI (for
certificate enrollment).

Cheers,
Tomas


          

        

      

    

  


--------------2209A5437DC2D7457763DB25--


From nobody Fri Dec 18 06:55:56 2020
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 5E5F13A0475 for ; Fri, 18 Dec 2020 06:55:55 -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, 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 Upmu9nyYlgtr for ; Fri, 18 Dec 2020 06:55: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 7C2683A0418 for ; Fri, 18 Dec 2020 06:55:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E3845300B6D for ; Fri, 18 Dec 2020 09:55:50 -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 n_msO7Vf56VS for ; Fri, 18 Dec 2020 09:55:49 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id AFE54300B5C for ; Fri, 18 Dec 2020 09:55:49 -0500 (EST)
From: Russ Housley 
Content-Type: multipart/alternative; boundary="Apple-Mail=_D1B5BAEF-82CB-481A-B6D9-CB7A4233F8F6"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Message-Id: 
References: <20201218103651.M76302@bts.sk>
To: LAMPS 
Date: Fri, 18 Dec 2020 09:55:51 -0500
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: [lamps] Fwd: Conflict between RFC8954 and ISO 14533-4
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, 18 Dec 2020 14:55:55 -0000

--Apple-Mail=_D1B5BAEF-82CB-481A-B6D9-CB7A4233F8F6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

What should we do here?


> From: "Marian =C4=8Eurkovi=C4=8D" 
> Subject: Conflict between RFC8954 and ISO 14533-4
> Date: December 18, 2020 at 5:40:13 AM EST
> To: housley@vigilsec.com
>=20
> Dear Russ,
>=20
> I'd like to notify you about conflict between recently published =
RFC8954 and ISO 14533-4:2019 standard.
>=20
> According to ISO 14533-4:2019, OCSP's Nonce extension is used to =
transmit MessageImprint field according to RFC3161 in order to be able =
to link OCSP response to a specific digital signature. With e.g. SHA512 =
algorithm, that definitely means much more than 32 bytes, as mentioned =
in RFC8954.=20
>=20
> Therefore it's necessary to significantly increase the maxbytes limit =
for OCSP Nonce, to e.g. 128 bytes. Otherwise it won't be possible to =
support usage intended in ISO 14533-4:2019
>=20
>=20
> With kind regards,
> MD
>=20


--Apple-Mail=_D1B5BAEF-82CB-481A-B6D9-CB7A4233F8F6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

What =
should we do here?


From: "Marian =C4=8Eurkovi=C4=8D" <md@bts.sk>
Subject: =
Conflict between =
RFC8954 and ISO 14533-4
Date: =
December 18, 2020 at 5:40:13 AM =
EST
To: =
housley@vigilsec.com

Dear Russ,

I'd like to notify you about conflict between recently =
published RFC8954 and ISO 14533-4:2019 standard.

According to ISO 14533-4:2019, OCSP's Nonce extension is used =
to transmit MessageImprint field according to RFC3161 in order to be =
able to link OCSP response to a specific digital signature. With e.g. =
SHA512 algorithm, that definitely means much more than 32 bytes, as =
mentioned in RFC8954. 

Therefore it's =
necessary to significantly increase the maxbytes limit for OCSP Nonce, =
to e.g. 128 bytes. Otherwise it won't be possible to support usage =
intended in ISO 14533-4:2019


With kind regards,
MD


=

--Apple-Mail=_D1B5BAEF-82CB-481A-B6D9-CB7A4233F8F6--


From nobody Fri Dec 18 10:03:03 2020
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 2982E3A0B5A; Fri, 18 Dec 2020 10:03:01 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: spasm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: spasm@ietf.org
Message-ID: <160831458111.6318.12239584344621407632@ietfa.amsl.com>
Date: Fri, 18 Dec 2020 10:03:01 -0800
Archived-At: 
Subject: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-01.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2020 18:03:01 -0000

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

        Title           : Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)
        Author          : Russ Housley
	Filename        : draft-ietf-lamps-crmf-update-algs-01.txt
	Pages           : 8
	Date            : 2020-12-18

Abstract:
   This document updates the cryptographic algorithm requirements for
   the Password-Based Message Authentication Code in the Internet X.509
   Public Key Infrastructure Certificate Request Message Format (CRMF)
   specified in RFC 4211.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lamps-crmf-update-algs/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lamps-crmf-update-algs-01
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-crmf-update-algs-01

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


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

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



From nobody Fri Dec 18 10:04:31 2020
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 3E8A53A03F4 for ; Fri, 18 Dec 2020 10:04:30 -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, 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 41lYuI5BbE0Q for ; Fri, 18 Dec 2020 10:04:28 -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 1B6B53A0AFB for ; Fri, 18 Dec 2020 10:04:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8F8B6300B9D for ; Fri, 18 Dec 2020 13:04: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 3p-ypYCcUDzE for ; Fri, 18 Dec 2020 13:04:24 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 1EECA300B70 for ; Fri, 18 Dec 2020 13:04:24 -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.17\))
Date: Fri, 18 Dec 2020 13:04:25 -0500
References: <160831458128.6318.14860273607218093486@ietfa.amsl.com>
To: LAMPS 
In-Reply-To: <160831458128.6318.14860273607218093486@ietfa.amsl.com>
Message-Id: <2D45BEE7-538F-4893-B744-B7D491C01AFD@vigilsec.com>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: [lamps] draft-ietf-lamps-crmf-update-algs-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: Fri, 18 Dec 2020 18:04:30 -0000

This revision addresses all of the outstanding comments.  I believe it =
is ready for WG Last Call.

Russ

> On Dec 18, 2020, at 1:03 PM, internet-drafts@ietf.org wrote:
>=20
>=20
> A new version of I-D, draft-ietf-lamps-crmf-update-algs-01.txt
> has been successfully submitted by Russ Housley and posted to the
> IETF repository.
>=20
> Name:		draft-ietf-lamps-crmf-update-algs
> Revision:	01
> Title:		Algorithm Requirements Update to the Internet =
X.509 Public Key Infrastructure Certificate Request Message Format =
(CRMF)
> Document date:	2020-12-18
> Group:		lamps
> Pages:		8
> URL:            =
https://www.ietf.org/archive/id/draft-ietf-lamps-crmf-update-algs-01.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-ietf-lamps-crmf-update-algs/
> Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-crmf-update-algs
> Htmlized:       =
https://tools.ietf.org/html/draft-ietf-lamps-crmf-update-algs-01
> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-crmf-update-algs-01
>=20
> Abstract:
>   This document updates the cryptographic algorithm requirements for
>   the Password-Based Message Authentication Code in the Internet X.509
>   Public Key Infrastructure Certificate Request Message Format (CRMF)
>   specified in RFC 4211.


From nobody Fri Dec 18 10:39:59 2020
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 8EB1F3A0B92 for ; Fri, 18 Dec 2020 10:39:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjmMOPZ5uBmI for ; Fri, 18 Dec 2020 10:39:56 -0800 (PST)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 0F7DC3A00E0 for ; Fri, 18 Dec 2020 10:39:56 -0800 (PST)
Received: by mail-io1-xd35.google.com with SMTP id p187so2965548iod.4 for ; Fri, 18 Dec 2020 10:39:55 -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=8xjmMGSJtocq5ujbEYhoQArUKMZppbZXBlUPhHQqAYQ=; b=MzZLuoxIM5H15yZMcv7kBa4dReLB6OiJScyos0xH1P1yHVynVLvwahu2FV30YeCdCB G0p59y/9P9VtqsGyGupOO+d4Ah0lGfXg1ZEydNmI5GWUNpuN+co4Z0P9KF88NAJa91+r InMhkSYyBfPtLQI9MpK8zwjaEz0N2G1FT31PzVMfddUgZD44ziuzCoOlVli4Wdj8BG+H Oo+qRTeIgcXx815ijIXzFOp5DN/Q5yFEd6lV1oQBkKdVcLi583NX44s0aj+ASmsPzpiQ jyDBdR0bfd6IHDfm9sKkjbx13B8vbu2W2HXqNRB2HNGu1BOcmaValotwEF0scJQRVxKC yIng==
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=8xjmMGSJtocq5ujbEYhoQArUKMZppbZXBlUPhHQqAYQ=; b=PiqvkeyQq70zL9wZUnSUHAsqKKidKmnX7gFp5uFkXBj0TjyWN0W4lHNtIYUmxIfoxa NSraPVIU3vBQ5ky9kAQhyQVVoQZvFCg1Krg+JR1ohLsSAwyaXsxtb8wxG9+giT3/h9cY 9xj/aPLQ3KndrinhuFF4pmjC4P6cogrcey1WJTgHO3RVW7uerDNrgSOBXfGFjlvRUuYG sz/ZxENIhjowdKAN6cxN0JBGA7QMQYkVRYDQlA1vWz2sMKpxUZRH/FWZtKjt99Lz3iJj aODcBWbHAplHkGBbG9ac4CgWp3wAyCmz8zAPU3ZnszYNA+rZ5xEw+g3z4g1HOQYsyJRz ynLQ==
X-Gm-Message-State: AOAM531n4GkKqlmPf8yTj5XCHDn2oU/fTAlluB5dB8WVMeYhVuhSW0Qq U7jCSOl6C6dW/Cwvp7y8gNCQnavJaLt90gePeTo=
X-Google-Smtp-Source: ABdhPJzt1AiZmrjbTl/EzNIN7Uw4m5EXCCwUhplD7lgD3nD35kQHpjjmXy3vS2LOubvbGNvVWB+Ok8X0u9aE8g1U0uM=
X-Received: by 2002:a02:b011:: with SMTP id p17mr5026023jah.114.1608316795167;  Fri, 18 Dec 2020 10:39:55 -0800 (PST)
MIME-Version: 1.0
References: <20201218103651.M76302@bts.sk> 
In-Reply-To: 
From: Mohit Sahni 
Date: Fri, 18 Dec 2020 10:39:44 -0800
Message-ID: 
To: Russ Housley 
Cc: LAMPS , md@bts.sk
Content-Type: multipart/alternative; boundary="000000000000432ab205b6c16f09"
Archived-At: 
Subject: Re: [lamps] Fwd: Conflict between RFC8954 and ISO 14533-4
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, 18 Dec 2020 18:39:58 -0000

--000000000000432ab205b6c16f09
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Russ
RFC 6960 states that the purpose of OCSP nonce extension is to avoid replay
attacks and as per Marian I see that ISO 14533-4:2019 is not using the OCSP
Nonce extension for that purpose. I tried getting a copy of ISO
14533-4:2019 but it is behind a paywall. In my opinion, since the server is
not guaranteed to return the Nonce in the OCSP response, this standard
already has issues unless both OCSP client and responder agree to the
standard. If that is the case, then they should have used a custom
extension for this purpose instead of piggybacking on the OCSP Nonce
extension.

My response is based on the information provided by Marian regarding
the ISO 14533-4:2019. If it is permitted and someone can share the section
of the standard regarding OCSP nonce usage that would be appreciated.

Thanks
Mohit

On Fri, Dec 18, 2020 at 6:56 AM Russ Housley  wrote:

> What should we do here?
>
>
> *From: *"Marian =C4=8Eurkovi=C4=8D" 
> *Subject: **Conflict between RFC8954 and ISO 14533-4*
> *Date: *December 18, 2020 at 5:40:13 AM EST
> *To: *housley@vigilsec.com
>
> Dear Russ,
>
> I'd like to notify you about conflict between recently published RFC8954
> and ISO 14533-4:2019 standard.
>
> According to ISO 14533-4:2019, OCSP's Nonce extension is used to transmit
> MessageImprint field according to RFC3161 in order to be able to link OCS=
P
> response to a specific digital signature. With e.g. SHA512 algorithm, tha=
t
> definitely means much more than 32 bytes, as mentioned in RFC8954.
>
> Therefore it's necessary to significantly increase the maxbytes limit for
> OCSP Nonce, to e.g. 128 bytes. Otherwise it won't be possible to support
> usage intended in ISO 14533-4:2019
>
>
> With kind regards,
> MD
>
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>

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


Hi Russ
RFC 6960 states that the purpose of OCSP nonce=
 extension is to avoid=C2=A0replay attacks and as per Marian I see that ISO=
 14533-4:2019 is not using the OCSP Nonce extension for that purpose. I tri=
ed getting a copy of=C2=A0ISO 14533-4:2019 but it is behind a paywall. In m=
y opinion, since the server is not guaranteed to return the Nonce in the OC=
SP response, this standard already has issues unless both OCSP client and r=
esponder agree to the standard. If that is the case, then they should have =
used a custom extension for this purpose instead of piggybacking=C2=A0on th=
e OCSP Nonce extension.=C2=A0

My response is based=
 on the information provided by Marian regarding the=C2=A0ISO 14533-4:2019.=
 If it is permitted and someone can share the section of the standard=C2=A0=
regarding OCSP nonce usage that would be appreciated.

<=
div>Thanks
Mohit=C2=A0

=

On Fri, Dec 18, 2020 at 6:56 AM Russ =
Housley <housley@vigilsec.com> wrote:
What should we do here?


Subject: Conf=
lict between RFC8954 and ISO 14533-4
Date: December 18, 2020 at 5:40:13 AM EST

Dear Russ,

I=
'd like to notify you about conflict between recently published RFC8954=
 and ISO 14533-4:2019 standard.

According to ISO 14533-4:2019, OCSP&=
#39;s Nonce extension is used to transmit MessageImprint field according to=
 RFC3161 in order to be able to link OCSP response to a specific digital si=
gnature. With e.g. SHA512 algorithm, that definitely means much more than 3=
2 bytes, as mentioned in RFC8954. 

Therefore it's necessary to s=
ignificantly increase the maxbytes limit for OCSP Nonce, to e.g. 128 bytes.=
 Otherwise it won't be possible to support usage intended in ISO 14533-=
4:2019


With kind regards,
MD

=


_______________________________________________

Spasm mailing list

Spasm@ietf.org

https://www.ietf.org/mailman/listinfo/spasm



--000000000000432ab205b6c16f09--


From nobody Fri Dec 18 10:47:11 2020
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 2DFF93A0BB2 for ; Fri, 18 Dec 2020 10:47:09 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 XFCDRIGAMSrE for ; Fri, 18 Dec 2020 10:47:02 -0800 (PST)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2076.outbound.protection.outlook.com [40.107.20.76]) (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 6B2383A0BD4 for ; Fri, 18 Dec 2020 10:46:57 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LiBLmuurYNaLlIFINsPpicnqr+9rHNu2cma7vZ5AWzmMg+BlefUS8i3DA5pAMbLm9OekJO14wHsgwvYNU2IakNZvrHMGpBLiOAU8DStAKYuLs3gR3ve5iYBmgB7gyDv1KDkrQVULCaq0smljBHY8sTJkrTs3SkIAW6pmbQGwvvWu+2Qyk2R89hW7R7QxeZBbY8uZYFFT8/NuEFNAubwaTxMOazhRkfFzOwXY4UN82/gTAv5ZqX4xYwlFuM5LUaOB0od6k/wve0PZ8xjC8mZXwN33qUPm8khzfwlUTxDOg2tRBNABcHBuOEEazpJKStmuaBmQd9RqyzrgoMyCWNhzwg==
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=1DFe2rbczioak/wYdZ2jmKuAsY/Ijmy+MhFSirEAagg=; b=KB8zBt3195JU920v8IeXEEWy71UzOq9L7Nv4kKdHbWWUX9EjxiEK9PhlJTgYta5tdADJu0ZriM1by3DaXf2dKSFktPURCkdurNIm5aqRSPAsiig5ecqSqQxwFdMmoKZH9V3KZieeCe7azssv5zXYViK52AmSxEgtKkhOtNJUbysG0EyAuOpf6qvOoKpmnO0meskJxAgQSdg9YS2QC3A9gtS9imJs0MPuo0ewk2g2J9CJ0fT7LQkEMw5da4rXa1L8wdja+7EA/T2F6kI2cJErMrhQlZUi1gFulGd0rEZTUrEbVbgyPSquZf/a3CqzPKdKnBMEJPKyYoWFVCJDTtw9qA==
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=1DFe2rbczioak/wYdZ2jmKuAsY/Ijmy+MhFSirEAagg=; b=nRXZbmN2qa8i9cHsWdkyo4q4xrguNDs09h+4RlGW/qQeMucy+agO68dmz583SA7Zz/tI0sURbHiBWEyemH+W2QJ7W89zTpv2Wy9uqEmltP6+EI/XZoUZm7Kl6zqq+FhK9lHzj1GNKWqOp718SvFiX/ouE/ghKyhO3XLEVh2KiXo=
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM8PR10MB4209.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:1c8::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.25; Fri, 18 Dec 2020 18:46:55 +0000
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69%7]) with mapi id 15.20.3654.030; Fri, 18 Dec 2020 18:46:55 +0000
From: "Brockhaus, Hendrik" 
To: Russ Housley , LAMPS 
Thread-Topic: [lamps] draft-ietf-lamps-crmf-update-algs-01
Thread-Index: AQHW1WhNtunZE/3TlkGJaO+jSG/XXqn9MOhg
Date: Fri, 18 Dec 2020 18:46:55 +0000
Message-ID: 
References: <160831458128.6318.14860273607218093486@ietfa.amsl.com> <2D45BEE7-538F-4893-B744-B7D491C01AFD@vigilsec.com>
In-Reply-To: <2D45BEE7-538F-4893-B744-B7D491C01AFD@vigilsec.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-12-18T18:46:53Z;  MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=11f43f14-64f3-498c-9ba8-81daea36a4d2; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=siemens.com;
x-originating-ip: [165.225.200.165]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: fb0e3e4a-2a0e-4da5-6770-08d8a3854abb
x-ms-traffictypediagnostic: AM8PR10MB4209:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: cfgjknzJki+pZP/Nyd0g7bI3k0aS6O3dL+M7vceX3szM0311JKcUewSjAn+HKYOZuwdX/n1oCag8cTSvJ5rHKFVsfmYPChxQ3VzEoc5GBzQzhM2hMYizgsG5xWHpV6fWC5t1tU7nfIyqM+iQJj8F3mXTdqgd5cBlrzWg6ZDqsIQORhdAK4y1Yfvj8Bi9IoMch91pOL4O7Rg/qr35jW8rCa9Vs8I5iX6LRwvHazoC/S4pr8ub0imfs+yfrWsIZL0skmp3gpzEvu7T2WhmN0wz4PkjZTi4Rk/MAgVMwM+Hb9jSh9FDCBQaO/jDK3q1dyQtNJQR0AEos14cUx/EBkFw5u/LUqwACi4m4qSm8Z4ML1TPlHj/ePrgT4799W/ptofLB+Lsi4uMJl0sqQHzGvMeJy5b6v4aveiWQ5gmrR62lpZKZNMjsPaUV4ADEvT2VlDDPlWOoB2VCM2iT8RSC2NoWQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(4636009)(376002)(346002)(136003)(39860400002)(396003)(366004)(53546011)(55236004)(6506007)(186003)(52536014)(8936002)(5660300002)(83380400001)(2906002)(86362001)(71200400001)(110136005)(66574015)(26005)(9686003)(478600001)(66446008)(66946007)(66556008)(76116006)(66476007)(33656002)(8676002)(316002)(64756008)(4001150100001)(55016002)(15650500001)(45080400002)(7696005)(966005); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?xb8c+AAWsZOPYih7hb6OGASnIOGoQyWfidtmKAkmOCTG+qJrFQCB+GK9vJ?= =?iso-8859-1?Q?FZKYkifFnCSAcmfbfAn0Khy69u2EYwygB12tbemCueQu+NRy4+p34NP0W1?= =?iso-8859-1?Q?L++ZPZ+Z1dhwlaNcO+rWe2HwWH+i1tNxUDXaBLk84MXBa7xE+Ve5aMptvA?= =?iso-8859-1?Q?z2nh/YEiC+UBJArh4CuZvwpzNzGSMRsoONU013tkrFRs/RiwbNbB3sc+4J?= =?iso-8859-1?Q?negrWNbsX2R9EoB5uEqKTYzKWWrn/1x8WfgEyAvfdT2sXGsshblqiAP1BL?= =?iso-8859-1?Q?3gCEZojy+tdhurPEus0QN4V+jjkCel/YO0tj7pQnERbpxspgc9myqHezXl?= =?iso-8859-1?Q?np8ApjiXvDX2NFYjkw/YH285CJ5qGVZ6u2T4CkL2lxgVKRiLiILm22w0XH?= =?iso-8859-1?Q?n8JU4IrG7OYYsE+bAnfCSpoxl/bFwYwvfT3lIWETo+8ENFcttDO17dFJAd?= =?iso-8859-1?Q?c37xWdf66lKOWrQ7F4530/9B+Z1A5c8XHojwTtRlR/OPjtNunbDkdCGCDT?= =?iso-8859-1?Q?ZcO6EaA5GAuVMpdha3v2UQNcSN+CF3OObfNUfFjx0qjOMU9kOO9D7ZCa7p?= =?iso-8859-1?Q?/GmtFoUw1zae3/sL6Wj5GIW+qUYonFSyOIIQzZ39E9c7BXId27bS7hiSnl?= =?iso-8859-1?Q?VgnxxnIKPngbLBp1RyWX3nb9qkcGoUhnl+yXij402shg4jQy8q6Agj/Byz?= =?iso-8859-1?Q?JWz6fOlYTLRui/YKlRFXgExWRRugfwGpFNjykKwedLGAzznQJ7oUTTz4K2?= =?iso-8859-1?Q?lIvwtyJpZ3N+Tdn1rzhqU9Q3nk4u5dG1A2rfF/MpIkXn1dURJtH1oBw86Q?= =?iso-8859-1?Q?GVZe2lEHoN1URS3V+lapu2YCGT4VGga0rw4qTLUgJ103sqr1tj/IdBuV16?= =?iso-8859-1?Q?Ql8Q2iMLHUpnV4KNEy/BW2a3e5O6k4lybNb90a8led/+XLRyGPcDqvx1cR?= =?iso-8859-1?Q?QPTQGhdevLWscGFo9Bt/aNnA9vFeG86VBBzHvzVVLmXdl26rvv7DJBpIJK?= =?iso-8859-1?Q?dJPETXjflQOY3+Yrfn4jny4pU7SjDFLwWVjOgd?=
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-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: fb0e3e4a-2a0e-4da5-6770-08d8a3854abb
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2020 18:46:55.1999 (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: 0pv802O4n9TmXxOaFgc6g92M/Sxj2IjgzYd7dlrrwMgKr4bN3sn+er62aX7p1WQ57oUjgeG9OsKhanZFkNuPFMGMX85kFSI0zoPMhsArhQE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR10MB4209
Archived-At: 
Subject: Re: [lamps] draft-ietf-lamps-crmf-update-algs-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: Fri, 18 Dec 2020 18:47:09 -0000

Russ

Sorry for our late response on the iterationCount topic.
Hans and I would like to propose a text, but I could not get hold of Hans t=
his week :-)
I will come back to you next week.=20

Hendrik

> -----Urspr=FCngliche Nachricht-----
> Von: Spasm  Im Auftrag von Russ Housley
> Gesendet: Freitag, 18. Dezember 2020 19:04
> An: LAMPS 
> Betreff: [lamps] draft-ietf-lamps-crmf-update-algs-01
>=20
> This revision addresses all of the outstanding comments.  I believe it is=
 ready
> for WG Last Call.
>=20
> Russ
>=20
> > On Dec 18, 2020, at 1:03 PM, internet-drafts@ietf.org wrote:
> >
> >
> > A new version of I-D, draft-ietf-lamps-crmf-update-algs-01.txt
> > has been successfully submitted by Russ Housley and posted to the IETF
> > repository.
> >
> > Name:		draft-ietf-lamps-crmf-update-algs
> > Revision:	01
> > Title:		Algorithm Requirements Update to the Internet X.509 Public
> Key Infrastructure Certificate Request Message Format (CRMF)
> > Document date:	2020-12-18
> > Group:		lamps
> > Pages:		8
> > URL:
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
> .ietf.org%2Farchive%2Fid%2Fdraft-ietf-lamps-crmf-update-algs-
> 01.txt&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd60b
> 8e72a1514c52a39408d8a37f660e%7C38ae3bcd95794fd4addab42e1495d55a%7
> C1%7C0%7C637439115015082517%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100
> 0&sdata=3D46KugpRBPoXItrBKtNc%2BNZeHWhZk3SmEKfIbuf4Twzw%3D&
> amp;reserved=3D0
> > Status:
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat
> racker.ietf.org%2Fdoc%2Fdraft-ietf-lamps-crmf-update-
> algs%2F&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd6
> 0b8e72a1514c52a39408d8a37f660e%7C38ae3bcd95794fd4addab42e1495d55a
> %7C1%7C0%7C637439115015092508%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1
> 000&sdata=3DZfmn0k5pB1H%2BW0EwldtfJPgzhR0eneN7KM8N%2Bq17zU
> U%3D&reserved=3D0
> > Htmlized:
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat
> racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lamps-crmf-update-
> algs&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd60b8e
> 72a1514c52a39408d8a37f660e%7C38ae3bcd95794fd4addab42e1495d55a%7C1
> %7C0%7C637439115015092508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> amp;sdata=3DFStfeGED7f3fl%2BEvYeVnalAtWU6cIWbdNHeOLoYpC2E%3D&am
> p;reserved=3D0
> > Htmlized:
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools=
.
> ietf.org%2Fhtml%2Fdraft-ietf-lamps-crmf-update-algs-
> 01&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd60b8e7
> 2a1514c52a39408d8a37f660e%7C38ae3bcd95794fd4addab42e1495d55a%7C1
> %7C0%7C637439115015092508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> amp;sdata=3D8arjo%2Bfmf5hayTxbD%2BWhJMEOEFR1jkQOlIPn5oIrfP8%3D&a
> mp;reserved=3D0
> > Diff:
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
> .ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-lamps-crmf-update-algs-
> 01&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd60b8e7
> 2a1514c52a39408d8a37f660e%7C38ae3bcd95794fd4addab42e1495d55a%7C1
> %7C0%7C637439115015092508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> amp;sdata=3DAt%2BLQYLUpfKWvTCqCM2uhj%2F2x90M8V%2B3ipHAlP7DShw
> %3D&reserved=3D0
> >
> > Abstract:
> >   This document updates the cryptographic algorithm requirements for
> >   the Password-Based Message Authentication Code in the Internet X.509
> >   Public Key Infrastructure Certificate Request Message Format (CRMF)
> >   specified in RFC 4211.
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D04%7C01%7Chendrik.
> brockhaus%40siemens.com%7Cd60b8e72a1514c52a39408d8a37f660e%7C38a
> e3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637439115015092508%7CU
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> 6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DEUn8W8MCpNFPSlQs79J
> Aq%2FMEvVUV%2BfKyw5WiNjoDa7c%3D&reserved=3D0


From nobody Fri Dec 18 12:01:17 2020
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 BE1DF3A0AA7 for ; Fri, 18 Dec 2020 12:01:10 -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, 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 KPXVFRLPCz1v for ; Fri, 18 Dec 2020 12:01:08 -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 09D943A0E57 for ; Fri, 18 Dec 2020 12:00:56 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D4645300B9E for ; Fri, 18 Dec 2020 15:00:51 -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 yXMn_TPxCqTD for ; Fri, 18 Dec 2020 15:00:46 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 164A4300512; Fri, 18 Dec 2020 15:00:44 -0500 (EST)
From: Russ Housley 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_88A30214-6977-49FA-B07F-B9DE8C46D71E"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Fri, 18 Dec 2020 15:00:45 -0500
In-Reply-To: 
Cc: LAMPS , md@bts.sk
To: Mohit Sahni 
References: <20201218103651.M76302@bts.sk>  
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] Fwd: Conflict between RFC8954 and ISO 14533-4
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, 18 Dec 2020 20:01:17 -0000

--Apple-Mail=_88A30214-6977-49FA-B07F-B9DE8C46D71E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Mohit:

I was only able to see the information sections of ISO 14533-4:2019 on =
the website, and those sections do not tell enough to determine anything =
further.

I was completely unaware of anyone placing anything other than a random =
value in the OCSP nonce field before this message arrived today.  Does =
anyone know of other situations like this?

Russ

> On Dec 18, 2020, at 1:39 PM, Mohit Sahni  wrote:
>=20
> Hi Russ
> RFC 6960 states that the purpose of OCSP nonce extension is to avoid =
replay attacks and as per Marian I see that ISO 14533-4:2019 is not =
using the OCSP Nonce extension for that purpose. I tried getting a copy =
of ISO 14533-4:2019 but it is behind a paywall. In my opinion, since the =
server is not guaranteed to return the Nonce in the OCSP response, this =
standard already has issues unless both OCSP client and responder agree =
to the standard. If that is the case, then they should have used a =
custom extension for this purpose instead of piggybacking on the OCSP =
Nonce extension.=20
>=20
> My response is based on the information provided by Marian regarding =
the ISO 14533-4:2019. If it is permitted and someone can share the =
section of the standard regarding OCSP nonce usage that would be =
appreciated.
>=20
> Thanks
> Mohit=20
>=20
> On Fri, Dec 18, 2020 at 6:56 AM Russ Housley > wrote:
> What should we do here?
>=20
>=20
>> From: "Marian =C4=8Eurkovi=C4=8D" >
>> Subject: Conflict between RFC8954 and ISO 14533-4
>> Date: December 18, 2020 at 5:40:13 AM EST
>> To: housley@vigilsec.com 
>>=20
>> Dear Russ,
>>=20
>> I'd like to notify you about conflict between recently published =
RFC8954 and ISO 14533-4:2019 standard.
>>=20
>> According to ISO 14533-4:2019, OCSP's Nonce extension is used to =
transmit MessageImprint field according to RFC3161 in order to be able =
to link OCSP response to a specific digital signature. With e.g. SHA512 =
algorithm, that definitely means much more than 32 bytes, as mentioned =
in RFC8954.=20
>>=20
>> Therefore it's necessary to significantly increase the maxbytes limit =
for OCSP Nonce, to e.g. 128 bytes. Otherwise it won't be possible to =
support usage intended in ISO 14533-4:2019
>>=20
>>=20
>> With kind regards,
>> MD
>>=20
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org 
> https://www.ietf.org/mailman/listinfo/spasm =



--Apple-Mail=_88A30214-6977-49FA-B07F-B9DE8C46D71E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Mohit:

I =
was only able to see the information sections of ISO 14533-4:2019 =
on the website, and those sections do not tell enough to determine =
anything further.

I was completely unaware of anyone placing anything other =
than a random value in the OCSP nonce field before this message arrived =
today.  Does anyone know of other situations like this?

Russ

On Dec 18, 2020, at 1:39 PM, Mohit Sahni <mohit06jan@gmail.com> wrote:

Hi Russ
RFC 6960 states that the purpose of =
OCSP nonce extension is to avoid replay attacks and as per Marian I =
see that ISO 14533-4:2019 is not using the OCSP Nonce extension for that =
purpose. I tried getting a copy of ISO 14533-4:2019 but it is =
behind a paywall. In my opinion, since the server is not guaranteed to =
return the Nonce in the OCSP response, this standard already has issues =
unless both OCSP client and responder agree to the standard. If that is =
the case, then they should have used a custom extension for this purpose =
instead of piggybacking on the OCSP Nonce =
extension. 

My response is based on the information provided by Marian =
regarding the ISO 14533-4:2019. If it is permitted and someone can =
share the section of the standard regarding OCSP nonce usage that =
would be appreciated.

Thanks
Mohit 

On Fri, Dec 18, 2020 at 6:56 AM Russ Housley <housley@vigilsec.com> wrote:
What should we do here?


From: "Marian =C4=8Eurkovi=C4=8D" =
<md@bts.sk>
Subject: Conflict =
between RFC8954 and ISO 14533-4
Date: December 18, 2020 at 5:40:13 =
AM EST
To: housley@vigilsec.com

Dear Russ,

I'd like to notify you about conflict between recently =
published RFC8954 and ISO 14533-4:2019 standard.

According to ISO 14533-4:2019, OCSP's Nonce extension is used =
to transmit MessageImprint field according to RFC3161 in order to be =
able to link OCSP response to a specific digital signature. With e.g. =
SHA512 algorithm, that definitely means much more than 32 bytes, as =
mentioned in RFC8954. 

Therefore it's =
necessary to significantly increase the maxbytes limit for OCSP Nonce, =
to e.g. 128 bytes. Otherwise it won't be possible to support usage =
intended in ISO 14533-4:2019


With kind regards,
MD


_______________________________________________

Spasm mailing list

Spasm@ietf.org

https://www.ietf.org/mailman/listinfo/spasm





=

--Apple-Mail=_88A30214-6977-49FA-B07F-B9DE8C46D71E--


From nobody Fri Dec 18 12:30:25 2020
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 481203A03F4 for ; Fri, 18 Dec 2020 12:30:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 vLMIivNCs4Ji for ; Fri, 18 Dec 2020 12:30:20 -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 E68243A03FB for ; Fri, 18 Dec 2020 12:30:20 -0800 (PST)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0BIKTcIh009457; Fri, 18 Dec 2020 20:30:15 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=lFxqh/wrNHweHVsG33Y/lm0sLnNy4ynljvfH9ZfBi5s=; b=ZXC6Le8f9srOFiZavYqvZ3ZfTxQhyEO5iP2n76/b2U9J2baVqIV85fhHFWQxDT8KLILG wFZ8y+TylJXLEXsk/PLMXvzjflemL1KOsWcioBGN+4hVQvojH47uJfNNvXZBbBqc4bSo J40CyFPVuLPR7XksynDFDiLuZa+hla8qkb8du+rC/nnGdFcNNn1VUy+QrG9hu9XjpqlS oPexele+JtjgSBE7U5kw0PFhRF+plf+X4sJgmxHzvA8cYxpRpiMfOhVFA+IwyvONTWKI iQo+NV0TLEJmSvNENAlg7wIdtB3sfyqPW+iaTEbjy8K+pJw5JGsTM6Zsqcgg62OPIKNx 1Q== 
Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 35dt6sgtum-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Dec 2020 20:30:15 +0000
Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0BIKSGmG001919; Fri, 18 Dec 2020 15:30:09 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint6.akamai.com with ESMTP id 35ct32x52r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 18 Dec 2020 15:30:09 -0500
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 18 Dec 2020 15:30:08 -0500
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.010; Fri, 18 Dec 2020 15:30:08 -0500
From: "Salz, Rich" 
To: Russ Housley , Mohit Sahni 
CC: LAMPS , "md@bts.sk" 
Thread-Topic: [lamps] Fwd: Conflict between RFC8954 and ISO 14533-4
Thread-Index: AQHW1U3n3kFl6t3LWUWzzUJTc1+wHKn9g4QAgAAWo4D//7RhAA==
Date: Fri, 18 Dec 2020 20:30:08 +0000
Message-ID: <7E92C4FB-4118-470A-8BA4-BEA133FA46AF@akamai.com>
References: <20201218103651.M76302@bts.sk>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.44.20121301
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.164.43]
Content-Type: multipart/alternative; boundary="_000_7E92C4FB4118470A8BA4BEA133FA46AFakamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-18_13:2020-12-18, 2020-12-18 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 bulkscore=0 adultscore=0 malwarescore=0 phishscore=0 mlxscore=0 mlxlogscore=739 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012180136
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-18_13:2020-12-18, 2020-12-18 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 bulkscore=0 impostorscore=0 lowpriorityscore=0 mlxlogscore=641 clxscore=1011 mlxscore=0 spamscore=0 malwarescore=0 suspectscore=0 phishscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012180138
X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.61) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint6
Archived-At: 
Subject: Re: [lamps] Fwd: Conflict between RFC8954 and ISO 14533-4
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, 18 Dec 2020 20:30:24 -0000

--_000_7E92C4FB4118470A8BA4BEA133FA46AFakamaicom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

ICAqICAgSSB3YXMgY29tcGxldGVseSB1bmF3YXJlIG9mIGFueW9uZSBwbGFjaW5nIGFueXRoaW5n
IG90aGVyIHRoYW4gYSByYW5kb20gdmFsdWUgaW4gdGhlIE9DU1Agbm9uY2UgZmllbGQgYmVmb3Jl
IHRoaXMgbWVzc2FnZSBhcnJpdmVkIHRvZGF5LiAgRG9lcyBhbnlvbmUga25vdyBvZiBvdGhlciBz
aXR1YXRpb25zIGxpa2UgdGhpcz8NCg0KSW4gdGhlIGVhcmx5IGRheXMgb2YgZGVzaWduaW5nIE9D
U1AsIENlcnRDbyBhbmQgaXRzIG1lbWJlciBiYW5rcyB3ZXJlIGdvaW5nIHRvIHB1dCB0aGUgZGln
ZXN0IG9mIGFuIG9ubGluZSBtZXNzYWdlIGluIHRoZXJlLCBhcyBhIHdheSBvZiBzaG93aW5nIHRo
YXQgdGhlIG1lc3NhZ2Ugd2FzIHNpZ25lZCBieSBhbiBlbnRpdHkgd2hvc2UgY2VydGlmaWNhdGUg
d2FzIHZhbGlkIGF0IHRoZSB0aW1lIG9mIHNpZ25pbmcuICAoU29tZSBzY2FudCBkZXRhaWxzIGF0
IGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0NlcnRDb18oZmluYW5jaWFsX3NlcnZpY2Vz
KSApICAgV2hlbiBDZXJ0Q28gZm9sZGVkLCBzbyBkaWQgdGhhdCBjb25jZXB0IEkgdGhpbmsuDQoN
ClRoZSBJU08gZm9sa3MgY291bGQgcHV0IGEgZGlnZXN0IG9mIHRoZSBpZGVudGlmaWVyIGFzIHRo
ZSBub25jZSwgb3IgdGhleSBjb3VsZCBoYXZlIGEgcHJvZmlsZSB0aGF0IHNheXMgUkZDODk1NCBk
b2VzIG5vdCBhcHBseS4NCg==

--_000_7E92C4FB4118470A8BA4BEA133FA46AFakamaicom_
Content-Type: text/html; charset="utf-8"
Content-ID: <3762E2E288478B46820A0A27B7FA9855@akamai.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg
MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x
OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp
Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z
ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow
aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFy
YWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28t
c3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsN
CgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCWZvbnQtc2l6ZToxMS4w
cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxl
MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv
cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w
aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM
aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDozNjI4Mjk2NDA7DQoJ
bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMDA1ODAzNTk2
IC0xMTI4NTI2MTI4IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz
IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2
ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl
dmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z
aXplOjEyLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1m
YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTsN
Cgltc28tYW5zaS1mb250LXdlaWdodDpib2xkO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2
ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv
gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K
QGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpT
eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m
YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNv
LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl
bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87
DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N
CkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv
LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6
V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0
b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYg
Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIg
dHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t
bGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkkgd2FzIGNvbXBsZXRlbHkgdW5hd2Fy
ZSBvZiBhbnlvbmUgcGxhY2luZyBhbnl0aGluZyBvdGhlciB0aGFuIGEgcmFuZG9tIHZhbHVlIGlu
IHRoZSBPQ1NQIG5vbmNlIGZpZWxkIGJlZm9yZSB0aGlzIG1lc3NhZ2UgYXJyaXZlZCB0b2RheS4g
Jm5ic3A7RG9lcyBhbnlvbmUga25vdyBvZiBvdGhlciBzaXR1YXRpb25zIGxpa2UNCiB0aGlzPzxv
OnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgZWFybHkg
ZGF5cyBvZiBkZXNpZ25pbmcgT0NTUCwgQ2VydENvIGFuZCBpdHMgbWVtYmVyIGJhbmtzIHdlcmUg
Z29pbmcgdG8gcHV0IHRoZSBkaWdlc3Qgb2YgYW4gb25saW5lIG1lc3NhZ2UgaW4gdGhlcmUsIGFz
IGEgd2F5IG9mIHNob3dpbmcgdGhhdCB0aGUgbWVzc2FnZSB3YXMgc2lnbmVkIGJ5IGFuIGVudGl0
eSB3aG9zZSBjZXJ0aWZpY2F0ZSB3YXMgdmFsaWQgYXQgdGhlIHRpbWUgb2Ygc2lnbmluZy4mbmJz
cDsNCiAoU29tZSBzY2FudCBkZXRhaWxzIGF0IDxhIGhyZWY9Imh0dHBzOi8vZW4ud2lraXBlZGlh
Lm9yZy93aWtpL0NlcnRDb18oZmluYW5jaWFsX3NlcnZpY2VzKSI+DQpodHRwczovL2VuLndpa2lw
ZWRpYS5vcmcvd2lraS9DZXJ0Q29fKGZpbmFuY2lhbF9zZXJ2aWNlcyk8L2E+ICkmbmJzcDsmbmJz
cDsgV2hlbiBDZXJ0Q28gZm9sZGVkLCBzbyBkaWQgdGhhdCBjb25jZXB0IEkgdGhpbmsuPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBJU08gZm9sa3MgY291bGQgcHV0IGEgZGlnZXN0IG9mIHRo
ZSBpZGVudGlmaWVyIGFzIHRoZSBub25jZSwgb3IgdGhleSBjb3VsZCBoYXZlIGEgcHJvZmlsZSB0
aGF0IHNheXMgUkZDODk1NCBkb2VzIG5vdCBhcHBseS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_7E92C4FB4118470A8BA4BEA133FA46AFakamaicom_--


From nobody Fri Dec 18 12:51:44 2020
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 9DCDC3A08A5 for ; Fri, 18 Dec 2020 12:51:42 -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, 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 Zst5Zjlbl8yo for ; Fri, 18 Dec 2020 12:51:40 -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 7EE713A0888 for ; Fri, 18 Dec 2020 12:51:40 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D07EA300BC0 for ; Fri, 18 Dec 2020 15:51: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 BKRwoLq91qnn for ; Fri, 18 Dec 2020 15:51:36 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id C8DEA30066E; Fri, 18 Dec 2020 15:51:35 -0500 (EST)
From: Russ Housley 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_65DA07C8-72FD-4B3E-B7FD-5A6FA841E4B8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Fri, 18 Dec 2020 15:51:37 -0500
In-Reply-To: <7E92C4FB-4118-470A-8BA4-BEA133FA46AF@akamai.com>
Cc: Mohit Sahni , LAMPS , "md@bts.sk" 
To: Rich Salz 
References: <20201218103651.M76302@bts.sk>    <7E92C4FB-4118-470A-8BA4-BEA133FA46AF@akamai.com>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] Fwd: Conflict between RFC8954 and ISO 14533-4
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, 18 Dec 2020 20:51:43 -0000

--Apple-Mail=_65DA07C8-72FD-4B3E-B7FD-5A6FA841E4B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Rich:

>=20
> I was completely unaware of anyone placing anything other than a =
random value in the OCSP nonce field before this message arrived today.  =
Does anyone know of other situations like this?
> =20
> In the early days of designing OCSP, CertCo and its member banks were =
going to put the digest of an online message in there, as a way of =
showing that the message was signed by an entity whose certificate was =
valid at the time of signing.  (Some scant details at =
https://en.wikipedia.org/wiki/CertCo_(financial_services) =
 )   When =
CertCo folded, so did that concept I think.
> =20
> The ISO folks could put a digest of the identifier as the nonce, or =
they could have a profile that says RFC8954 does not apply.

I think that more and more libraries will enforce the size constraint.

For example, in pyasn1, the following defines Nonce from RFC 8984:

	class Nonce(univ.OctetString):
	    subtypeSpec =3D constraint.ValueSizeConstraint(1, 32)

If a nonce longer than 32 octets is provided, a decode error will =
result.

Russ


--Apple-Mail=_65DA07C8-72FD-4B3E-B7FD-5A6FA841E4B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Rich:


  • I was completely =
unaware of anyone placing anything other than a random value in the OCSP =
nonce field before this message arrived today.  Does anyone know of =
other situations like this?
 
In the early days of designing OCSP, CertCo and =
its member banks were going to put the digest of an online message in =
there, as a way of showing that the message was signed by an entity =
whose certificate was valid at the time of signing.  (Some scant =
details at https://en.wikipedia.org/wiki/CertCo_(financial_services) )   When =
CertCo folded, so did that concept I think.
 
The ISO folks could put a =
digest of the identifier as the nonce, or they could have a profile that =
says RFC8954 does not =
apply.

I =
think that more and more libraries will enforce the size =
constraint.

For example, in pyasn1, =
the following defines Nonce from RFC 8984:

	class =
Nonce(univ.OctetString):
	    subtypeSpec =3D =
constraint.ValueSizeConstraint(1, 32)

If a nonce longer than 32 octets is provided, a =
decode error will result.

Russ

=

--Apple-Mail=_65DA07C8-72FD-4B3E-B7FD-5A6FA841E4B8--


From nobody Fri Dec 18 12:53:17 2020
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 068D43A08A9 for ; Fri, 18 Dec 2020 12:53:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 W2xu-32io5Rm for ; Fri, 18 Dec 2020 12:53:13 -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 B41C53A08A5 for ; Fri, 18 Dec 2020 12:53:13 -0800 (PST)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 0BIKhuaM015096; Fri, 18 Dec 2020 20:53:09 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=1j993nbikE6w9NhVLNDvM93wHwzQF27d23mPo23T3GQ=; b=K48A3bGM7OK6NZuo8AoWkfH++1hq2JXEHwadOZ9rpCX77MxEGIO/IxISVBD9a2yiO/JX vzSdXZu6uyd/pT7f9pT4nUrSmWIdmUXm8os7kXLJZQLhzcEt25tbuiIyl4dSdw8/EIo1 RNZ30AeWGhyG7zSzUcMUX2jN5yYFNgnyRrNFejsoPeqMwEU7zjGEVKMXzqKCSpKkCPfc 0M0/e1U6NqoLCT1QYF+qLZ31v61fyy+noM8NcBOr8Ri1ReRIq9f3FHUMg2ext3Wc6Bum bRX5jBy4S3m+QNIHAd6ULRvJBnQbHcKMeI57qK3tnJ7OPXgLPXNL6eZLZxq6UtDyQ6Pk 1g== 
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 35dvu3md52-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Dec 2020 20:53:09 +0000
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0BIKnMse011303; Fri, 18 Dec 2020 15:53:07 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 35ct32x84j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 18 Dec 2020 15:53:07 -0500
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 18 Dec 2020 15:53:06 -0500
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.010; Fri, 18 Dec 2020 15:53:06 -0500
From: "Salz, Rich" 
To: Russ Housley 
CC: Mohit Sahni , LAMPS , "md@bts.sk" 
Thread-Topic: [lamps] Fwd: Conflict between RFC8954 and ISO 14533-4
Thread-Index: AQHW1U3n3kFl6t3LWUWzzUJTc1+wHKn9g4QAgAAWo4D//7RhAIAAWdWA//+sl4A=
Date: Fri, 18 Dec 2020 20:53:06 +0000
Message-ID: 
References: <20201218103651.M76302@bts.sk>    <7E92C4FB-4118-470A-8BA4-BEA133FA46AF@akamai.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.44.20121301
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.164.43]
Content-Type: multipart/alternative; boundary="_000_F90CCA4D6DB84390B60B30DB8627FBB4akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-18_13:2020-12-18, 2020-12-18 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 bulkscore=0 phishscore=0 mlxlogscore=839 malwarescore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012180140
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-18_13:2020-12-18, 2020-12-18 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 suspectscore=0 mlxlogscore=753 spamscore=0 bulkscore=0 impostorscore=0 phishscore=0 adultscore=0 mlxscore=0 malwarescore=0 priorityscore=1501 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012180140
X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.19) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint2
Archived-At: 
Subject: Re: [lamps] Fwd: Conflict between RFC8954 and ISO 14533-4
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, 18 Dec 2020 20:53:15 -0000

--_000_F90CCA4D6DB84390B60B30DB8627FBB4akamaicom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VG8gYmUgdmVyeSBjbGVhcjogSSBhbSBpbiBmYXZvciBvZiB0aGUgY29uc3RyYWludHMsIGFuZCBw
b2ludGVkIG91dCB0d28gd2F5cyBJU08gMTQ1MzMgY291bGQgaGFuZGxlIGl0LiAgSSBkbyBub3Qg
dGhpbmsgd2UgbmVlZCB0byBkbyBhbnl0aGluZy4NCg0KDQogICogICBUaGUgSVNPIGZvbGtzIGNv
dWxkIHB1dCBhIGRpZ2VzdCBvZiB0aGUgaWRlbnRpZmllciBhcyB0aGUgbm9uY2UsIG9yIHRoZXkg
Y291bGQgaGF2ZSBhIHByb2ZpbGUgdGhhdCBzYXlzIFJGQzg5NTQgZG9lcyBub3QgYXBwbHkuDQoN
Cg==

--_000_F90CCA4D6DB84390B60B30DB8627FBB4akamaicom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg
MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x
OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp
Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z
ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow
aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
Zjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0
UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K
CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBl
cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y
OndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u
bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp
biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj
dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp
c3QgbDANCgl7bXNvLWxpc3QtaWQ6MTM3NzI2ODYwODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsN
Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEyMDIzMTIyMjIgLTE0NjExNzM1MzIgNjc2OTg2OTEg
Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2
OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt
aWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu
IjsNCgltc28tYmlkaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1hbnNpLWZvbnQtd2VpZ2h0
OmJvbGQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m
YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNv
LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl
bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87
DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N
CkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv
LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6
V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi
dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ
Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6
bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21z
by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEN
Cgl7bXNvLWxpc3QtaWQ6MTQ3NTYzNTM3NzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTA1NjQ0
NTc3NDt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h
bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxl
dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6
74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w
cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10
YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6
U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z
by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx
OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox
MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl
bC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p
bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi
dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0
IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6
ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s
ZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m
YW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1i
b3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu
az0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxk
aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBiZSB2ZXJ5
IGNsZWFyOiBJIGFtIGluIGZhdm9yIG9mIHRoZSBjb25zdHJhaW50cywgYW5kIHBvaW50ZWQgb3V0
IHR3byB3YXlzIElTTyAxNDUzMyBjb3VsZCBoYW5kbGUgaXQuJm5ic3A7IEkgZG8gbm90IHRoaW5r
IHdlIG5lZWQgdG8gZG8gYW55dGhpbmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
Cjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h
cmdpbi1yaWdodDouNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj5UaGUgSVNPIGZvbGtzIGNv
dWxkIHB1dCBhIGRpZ2VzdCBvZiB0aGUgaWRlbnRpZmllciBhcyB0aGUgbm9uY2UsIG9yIHRoZXkg
Y291bGQgaGF2ZSBhIHByb2ZpbGUgdGhhdCBzYXlzIFJGQzg5NTQgZG9lcyBub3QgYXBwbHkuPG86
cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_F90CCA4D6DB84390B60B30DB8627FBB4akamaicom_--


From nobody Fri Dec 18 15:06:19 2020
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 CAD933A0FD3 for ; Fri, 18 Dec 2020 15:06:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZskNszhwALpn for ; Fri, 18 Dec 2020 15:06:09 -0800 (PST)
Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 8867F3A0FCA for ; Fri, 18 Dec 2020 15:05:53 -0800 (PST)
Received: by mail-il1-x134.google.com with SMTP id q1so3678103ilt.6 for ; Fri, 18 Dec 2020 15:05:53 -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=eBJVcCElWV4Bwdnyc7iGSwY/IbQRCP1Z+uIzG+XR2pc=; b=lEecbWis9hC1JlIqWea0/S2WH3FzhJgo5sxRnEHKsNij1mCUXQKXzTPOxYv1GcLBac M45oaYIGEF2w9o+bKj3nbNLc9WTBGpr3IUzM8We5B9O+7sVBvzrhb40MYT1BTnxEX/dl 27rtoMZfDNUUDgDhmFsUplEjn3Dw/67Oo+5gkAx/rqR71SE1A2mtCR8DnK8dV7u+VE/+ 4r/642m5x4MQS0iZWhQswegFuKP/8GVvszPpJJV2RmPJ5GFv8GMvQoxnjGiCeiJnxvJ4 HVSOH9aNkqRzwaNNF2WX++y7HHEJLSkp6zTTMgJ+Gr/bGp968PkDjfHoX3Tv5HfTppdy 1RNg==
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=eBJVcCElWV4Bwdnyc7iGSwY/IbQRCP1Z+uIzG+XR2pc=; b=g0m2e4mY/CxlAn8o2ZeY4HkqfSafu5AiSBLE0GZA1V6k5gZVBdsBO9aPiYCEftECR7 4/TH+GZUTg4I+TZGlGVbnCLZHI1caSm8H4AB5NJv/0OAssXEXIN2eMLGjyJ0K9OPvLqE JJG6k4obWAC58uNKe1GSinsv+G1AEjuW3brZl+Pk+NkaKfHyvTqyrSmiPPNYWi5iH83M Ml68NMNa6mAP8xoLeOmP2ySveZeZlstHi/UcNcDKlDxdE2QOlLB8oQNKSWPnXzjwRVSl X7mD1+uBZKQrL7yvq6+yqv+9silYkLoqVkyO5jamtDXsV1tDOF4wJCelrzjxONDMNXq2 70aQ==
X-Gm-Message-State: AOAM530d6llLhdpO1qAPXM+9T1NOdbdb3hPY+4BVARx+edDbrZBjyGVm aAlRJJ0PZiL1XD1WaftYLWQLqE/lgjVhkZHyofg=
X-Google-Smtp-Source: ABdhPJxrf91ezpmX5QlIu9uX1AQmRwDpd+xchlvp0VtmxBteknA8jr/t+5ttn0y7QqABDWIxouISe6GGVgZ7yyKvK18=
X-Received: by 2002:a92:d0c8:: with SMTP id y8mr6356367ila.46.1608332752768; Fri, 18 Dec 2020 15:05:52 -0800 (PST)
MIME-Version: 1.0
References: <20201218103651.M76302@bts.sk>    <7E92C4FB-4118-470A-8BA4-BEA133FA46AF@akamai.com> <20201218224153.M14899@bts.sk>
In-Reply-To: <20201218224153.M14899@bts.sk>
From: Mohit Sahni 
Date: Fri, 18 Dec 2020 15:05:41 -0800
Message-ID: 
To: =?UTF-8?B?TWFyaWFuIMSOdXJrb3ZpxI0=?= 
Cc: "Salz, Rich" , Russ Housley , LAMPS 
Content-Type: multipart/alternative; boundary="00000000000068d5a905b6c52683"
Archived-At: 
Subject: Re: [lamps] Fwd: Conflict between RFC8954 and ISO 14533-4
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, 18 Dec 2020 23:06:18 -0000

--00000000000068d5a905b6c52683
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Marian,
So in this case does OCSP responder fill the Nonce extension with its own
data and does not echo back what OCSP client has sent or I am missing
something ? Can you please provide more details on the use case.

-Mohit

On Fri, Dec 18, 2020 at 2:59 PM Marian =C4=8Eurkovi=C4=8D  wrote=
:

> *On Fri, 18 Dec 2020 20:30:08 +0000, Salz, Rich wrote*
>
>    - I was completely unaware of anyone placing anything other than a
>    random value in the OCSP nonce field before this message arrived today=
.
>    Does anyone know of other situations like this?
>
> > In the early days of designing OCSP, CertCo and its member banks were
> going to put the digest of an online message in there, as a way of showin=
g
> that the message was signed by an entity whose certificate was valid at t=
he
> time of signing.  (Some scant details at
> https://en.wikipedia.org/wiki/CertCo_(financial_services) )   When CertCo
> folded, so did that concept I think.
>
> This is very similar - MessageImprint of a digital signature is placed
> into Nonce as a proof, that this digital signature existed at Production
> Time of OSCP response, which also means the certificate was valid at the
> time of signing
>
> > The ISO folks could put a digest of the identifier as the nonce, or the=
y
> could have a profile that says RFC8954 does not apply.
>
> I'm afraid none of the above will work.
>
> According to RFC3161, Message imprint is defined as:
>
> MessageImprint ::=3D SEQUENCE  {
>      hashAlgorithm                AlgorithmIdentifier,
>      hashedMessage                OCTET STRING  }
>
>
> Since you need 19 bytes for the structure and AlgorithmIdentifier, with a
> 32 byte limit imposed on Nonce you'll only have 13 bytes left, which is t=
oo
> few even for legacy & no longer secure algorithms like MD5 or SHA1. And
> when libraries implement 32 byte limit, anything else will require
> customized libraries...
>
> For SHA256, you'll need room for at least 19+32=3D51 bytes in Nonce
> For SHA512, you'll need room for at least 19+64=3D83 bytes in Nonce.
>
> That's why I propose to increase limit from 32 to 128 bytes, which will
> keep some extra bytes for the future or for other purposes. This will kee=
p
> all benefits of having a limit in place and at the same time allow Nonce =
to
> be used for additional purposes.
>
> With kind regards,
> MD
>
>

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


Hi Marian,
So in this case does OCSP responder fill th=
e Nonce extension with its own data and does not echo back what OCSP client=
 has sent or I am missing something ? Can you please provide more details o=
n the use case.=C2=A0

-Mohit=C2=A0

=

On Fri, De=
c 18, 2020 at 2:59 PM Marian =C4=8Eurkovi=C4=8D <md@bts.sk> wrote:








On Fri, 18 Dec 2020 20:30:08 +0000, Salz, Rich wrote



    


  • I=20
was completely unaware of anyone placing anything other than a random value=
 in=20
the OCSP nonce field before this message arrived today.=C2=A0 Does anyone k=
now=20
of other situations=20
like
 this?
    • 






> In the early days of designing OCSP, CertCo and its memb=
er banks were=20
going to put the digest of an online message in there, as a way of showing =
that=20
the message was signed by an entity whose certificate was valid at the time=
 of=20
signing.=C2=A0

 (Some scant details at 
https://en.wikipedia.org/wiki/CertCo_(financial_services) )=C2=A0=C2=A0=
 When=20
CertCo folded, so did that concept I=20
think.








This is very similar - MessageImprint of a digital signature is placed=
 into Nonce as a proof, that this digital signature existed at Production T=
ime of OSCP response, which also means the certificate was valid at the tim=
e of signing









> The ISO folks could put a digest o=
f the identifier as the nonce, or=20
they could have a profile that says RFC8954 does not=20
apply.








I'm afraid none of the above will work.








According to RFC3161, Message imprint is defined as:










MessageImprint ::=3D SEQUENCE  {
     hashAlgorithm                AlgorithmIdentifier,
     hashedMessage                OCTET STRING  }








Since you need 19 bytes for the structure and AlgorithmIdentifier, wit=
h a 32 byte limit imposed on Nonce you'll only have 13 bytes left, whic=
h is too few even for legacy & no longer secure algorithms like MD5 or =
SHA1. And when libraries implement 32 byte limit, anything else will requir=
e customized libraries...









For SHA256, you'll need room for at least 19+32=3D51 bytes in Nonc=
e



For SHA512, you'll need room for at least 19+64=3D83 bytes in Nonc=
e.








That's why I propose to increase limit from 32 to 128 bytes, which=
 will keep some extra bytes for the future or for other purposes. This will=
 keep all benefits of having a limit in place and at the same time allow No=
nce to be used for additional purposes.








With kind regards,



MD
















--00000000000068d5a905b6c52683--


From nobody Fri Dec 18 17:03:00 2020
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 503503A0A49 for ; Fri, 18 Dec 2020 17:02:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPm0n6JMYo5t for ; Fri, 18 Dec 2020 17:02:56 -0800 (PST)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 AF3033A0A3D for ; Fri, 18 Dec 2020 17:02:56 -0800 (PST)
Received: by mail-il1-x132.google.com with SMTP id g1so3848655ilk.7 for ; Fri, 18 Dec 2020 17:02:56 -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=SyCFVbqQDYqvExa47XnZF6p+lH5Xzeh1AV2HgBWBBbs=; b=bpyOfUkrq6X+v68venXNjXJ0dFYfeC2l5PRPAvUMYE7GaOHwcDWBIiKh927F1tC7oy p0Jgac2uOft4zEwClSMr5UxzOHGhBf2JsI7M69yzAd6GpFIhr+/MW6I9/cmNubNoaPEI i+FrbCV9F4Ui1BazEoXfUH0nniaAab6384frGM3OLM8abzMgeICHN/lRh1GOCv7xa7sb brE5Zn1asOBTwhEM21f+FKGHSxYzhfUGBenSCAF2euPIk8gisR3dj8ocGx1CbBVhwOnj hHwYIohB7+XE9BcNKEPM3WJlGC/NfRgDuRD+FcoOYGv1bLLrNf2Q61zNCCdKiIBA4TUs RBUA==
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=SyCFVbqQDYqvExa47XnZF6p+lH5Xzeh1AV2HgBWBBbs=; b=adoGLehWdxtE1sLXCH38Vtmm8fo5NrlVVi85BQQQOJe7k/sOO7QfZqsWU6vIvc80yR 7bx6+Y4ugYZLSh+SWZ378RbP78JUTXjV/CqYY1y0Hx2mw4YUvn+gIY+/U9B2ABzTDIZd FSmoQB1VLA+mn5HJSDMYJS7IwWp5ZQdB3qBfYb4iIDApvkLT6sg1Fq4H6IupTrSMt7Dh 7whjPizwwhez0oEHDol+i8jNfbeKsYnH3JN+Id+66bC1k4CdFi5U2DQUgTDGhi2zsa8Z AER6QuPJD2J8CyjXkckDdpDT9xQdnLWxsiEOT1G8q6dIPw2MTg2De6ZknzVxEZywU5U7 8dmQ==
X-Gm-Message-State: AOAM531E1T3Q1Dz73hEI05hB0RMHtOwwt2TnToYMxZWFU8W9TDYxSUH4 YKuaOMvyTDuxqmWijGTvPby9V40p+TI8++hIcWk=
X-Google-Smtp-Source: ABdhPJw7Pw51UR8bBmunx5LbHONAgkpM70hsdUPYOrXQcKxxTa0N/dNSvvwnPKfvRm0q6nx0JQ0w1i6RuiIpyju2R2g=
X-Received: by 2002:a92:d5c5:: with SMTP id d5mr6938516ilq.24.1608339775836; Fri, 18 Dec 2020 17:02:55 -0800 (PST)
MIME-Version: 1.0
References: <20201218103651.M76302@bts.sk>    <7E92C4FB-4118-470A-8BA4-BEA133FA46AF@akamai.com> <20201218224153.M14899@bts.sk>  <20201218230753.M63543@bts.sk>
In-Reply-To: <20201218230753.M63543@bts.sk>
From: Mohit Sahni 
Date: Fri, 18 Dec 2020 17:02:45 -0800
Message-ID: 
To: =?UTF-8?B?TWFyaWFuIMSOdXJrb3ZpxI0=?= 
Cc: "Salz, Rich" , Russ Housley , LAMPS 
Content-Type: multipart/alternative; boundary="00000000000004561305b6c6c995"
Archived-At: 
Subject: Re: [lamps] Fwd: Conflict between RFC8954 and ISO 14533-4
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, 19 Dec 2020 01:02:58 -0000

--00000000000004561305b6c6c995
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Marian
I did some internet search and I found out a document that explains the ISO
14533, (https://www.bsmi.gov.tw/wSite/public/Data/f1415951364236.pdf). I
think the OCSP Nonce extension is being used by ISO 14533 in a way that it
was not intended to be used for.
If my understanding is correct, then the OCSP response also goes as part of
the digitally signed document along with the signature and the timestamp of
the signature and the application verifying the signature will look at the
OCSP Nonce and match it with the signature's imprint to make sure the OCSP
response is for the particular document that has signature.

Since servers can choose not to echo back the OCSP Nonce extension, in that
case the document validator cannot validate this assertion that the status
of the certificate was not revoked at the time of signing the document.

In my opinion we should have a new OCSP (and may be CRL) extension to
support the long term validation of OCSP status. I.e. linking the OCSP
response with the signed data and leave Nonce extension as it is to prevent
replay attacks. If everyone agree I am happy to write a draft for that.

Thanks,
Mohit

On Fri, Dec 18, 2020 at 3:19 PM Marian =C4=8Eurkovi=C4=8D  wrote=
:

> *On Fri, 18 Dec 2020 15:05:41 -0800, Mohit Sahni wrote*
> > So in this case does OCSP responder fill the Nonce extension with its
> own data and does not echo back what OCSP client has sent or I am missing
> something ? Can you please provide more details on the use case.
>
> No, the proof of existence for the signature relies on the fact, that OCS=
P
> responder echoes back exactly what it received from the OCSP client, so n=
o
> special functionality is needed.
>
> The process looks like this:
>
> - signing application prepares the digital signature and puts its imprint
> into Nonce field of OCSP request
> - OCSP response will contain proof of certificate's validity, trusted
> ProductionTime and echoed Nonce from the request, linking it to exactly
> this digital signature
>
> With kind regards,
> MD
>
>

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


Hi Marian
I did some inter=
net search and I found out a document that explains the ISO 14533, (https://w=
ww.bsmi.gov.tw/wSite/public/Data/f1415951364236.pdf). I think the OCSP =
Nonce extension is being used by ISO 14533 in a way that it was not intende=
d to be used for.=C2=A0
If my understanding is correct, then the =
OCSP response also goes as part of the digitally signed document along with=
 the signature and the timestamp of the signature and the application verif=
ying the signature will look at the OCSP Nonce and match it with the signat=
ure's imprint=C2=A0to make sure the OCSP response is for the particular=
 document that has signature.=C2=A0

Since servers =
can choose not to echo back the OCSP Nonce extension, in that case the docu=
ment validator cannot validate this assertion that the status of the certif=
icate was not revoked at the time of signing the document.=C2=A0
=

In my opinion we should have a new OCSP (and may be CRL) ext=
ension to support the long term validation of OCSP status. I.e. linking the=
 OCSP response with the signed data and leave Nonce extension as it is to p=
revent replay attacks. If everyone agree I am happy to write a draft for th=
at.=C2=A0

Thanks,
Mohit=C2=A0
=

On Fri, Dec 18, 2020 at 3:19 PM Marian =C4=8Eurkovi=C4=8D <md@bts.sk> 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">









On Fri, 18 Dec 2020 15:05:41 -0800, Mohit Sahni wr=
ote

> So in this case does OCSP responder fill the Nonce ex=
tension=20
with its own data and does not echo back what OCSP client has sent or I am=
=20
missing something ? Can you please provide more details on the use=20
case.=C2=A0








No, the proof of existence for the signature relies o=
n the fact, that OCSP responder echoes back exactly what it received from t=
he OCSP client, so no special functionality is needed.








The process looks like this:








- signing application prepares the digital signature =
and puts its imprint into Nonce field of OCSP request



- OCSP response will contain proof of certificate'=
;s validity, trusted ProductionTime and echoed Nonce from the request, link=
ing it to exactly this digital signature









With kind regards,



MD


















--00000000000004561305b6c6c995--


From nobody Sat Dec 19 03:05:49 2020
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 7EE313A1003 for ; Sat, 19 Dec 2020 03:05:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82WxRf-Ntk09 for ; Sat, 19 Dec 2020 03:05:44 -0800 (PST)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 BAC2D3A0FFD for ; Sat, 19 Dec 2020 03:05:44 -0800 (PST)
Received: by mail-io1-xd33.google.com with SMTP id d9so4517168iob.6 for ; Sat, 19 Dec 2020 03:05:44 -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=f0JsUhil0hEvXKKJdlX5CuMVdAeBpVJvOdSu6HOMTdc=; b=HNzV9PYTwlzitzddcxu7wJxHCrF/gF4mbEIBaURWDJDwleQEvG5CpY5z5p3kTKveiL 3jHgahVtVNtT9cMsJ3NtGjR1a+rh8mlb1g8Ks+xG0MXfvoMEBLkYVBzQHeAxj/rjaBmx t0XEryq6JixAmEs8l+PGZ0IGOd/x0nA8Zitel7ziHMcNP9wd9KHnUrwezfJS6AO2xRb+ XTF67u/WgdTFF6Pp5cKo+mkwFzDaclCR4F9v2Z3A2XIMTzdDIQRIuowXYnzzpjRdbcmg 6dkKGRZctP4DF9bb6VP+dWzUvionTTTwcyStLtrkaZVEisQVUh7w5bp+S4fBKV7DOdUi 82aw==
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=f0JsUhil0hEvXKKJdlX5CuMVdAeBpVJvOdSu6HOMTdc=; b=rWxPS+f08020fCwiZITDkvTPu86HnGwfiV3Yx01EFgifMbKRo3uriSuGt3FJR3kQme h0RRHE0SW+WWpdlTwS2ugXb5lVaDlTzybany3FZcrkm4MKdhOtBmJuTYmY9z04wcbOnr tCVL0T62zEoSoZXLLM8d+OWbJfS2M+f68u2UCwjyPk2stB5vgxjbRoLx/dNq70PF1EdH XqVJjQEdYVF5ulhEw0LSRYzusSnaOehqvLQjrVqT+EZV8G6ytCOhIRg6dqXFP1YNS52V dfr39obplwZi4ykjcA1fcqEA1WQRKYJo+79yTep2Q8ZTDBAuWSkDqlYCczfb+BgUA3Kf FmRQ==
X-Gm-Message-State: AOAM532TxX+DXv5Ft0ODwneA/mOxhwSa7B75npVf9mt0BBi8a3y60k2u a18K8PdL/LguVYCFFy0u+Si/LDDXLa3DjmBUqAQavC9P7ocN7Q==
X-Google-Smtp-Source: ABdhPJwe/q/kj7NjzCZqOZ9MVDGZKdWZ+yIa0vPSpuI1DZchzM/dJ0FKkRmGx9c1ZYy4M0GJl4WD6VouVHO6YjMgfv0=
X-Received: by 2002:a05:6602:1492:: with SMTP id a18mr7845644iow.124.1608375943863;  Sat, 19 Dec 2020 03:05:43 -0800 (PST)
MIME-Version: 1.0
References: <20201218103651.M76302@bts.sk>    <7E92C4FB-4118-470A-8BA4-BEA133FA46AF@akamai.com> <20201218224153.M14899@bts.sk>  <20201218230753.M63543@bts.sk>  <20201219085409.M21922@bts.sk>
In-Reply-To: <20201219085409.M21922@bts.sk>
From: Mohit Sahni 
Date: Sat, 19 Dec 2020 03:05:32 -0800
Message-ID: 
To: =?UTF-8?B?TWFyaWFuIMSOdXJrb3ZpxI0=?= 
Cc: "Salz, Rich" , Russ Housley , LAMPS 
Content-Type: multipart/alternative; boundary="000000000000cca3e205b6cf34ab"
Archived-At: 
Subject: Re: [lamps] Fwd: Conflict between RFC8954 and ISO 14533-4
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, 19 Dec 2020 11:05:48 -0000

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

Hi Marian,
I am sorry, I don't concur with you on this matter. The use case mentioned
in ISO 14533 is somewhat analogous to the AEAD in symmetric
encryption/decryption. According to the ISO 14533 we are binding the OCSP
response with the event of the digital signature generated by a particular
private key and then bundling the OCSP response with the digital signature
to prove that the status of the key was not revoked at the time of
generating the signature.

On the contrary the purpose of Nonce extension is to prevent replay attacks
and as discussed in the LAMPS WG the value must be generated using a
cryptographically strong random number. I don't think it is a good idea to
repurpose an extension for some other function when we are talking about
the security. What if someone replays a valid OCSP response after the key
has been revoked by guessing the MessageImprint ?

You are quoting the nonce of RFC3161 out of the context here and it is not
relevant to this discussion for OCSP. However even RFC3161 mentions in
section 2.4.1 that the nonce value should be a large random integer with a
suggested size of 64-bit to avoid the replay of the response to TimeStampRe=
q.


I will agree with what Rich said in an earlier email.

Thanks
Mohit

On Sat, Dec 19, 2020 at 1:42 AM Marian =C4=8Eurkovi=C4=8D  wrote=
:

> *On Fri, 18 Dec 2020 17:02:45 -0800, Mohit Sahni wrote*
>  > If my understanding is correct, then the OCSP response also goes as
> part of the digitally signed document along with the signature and the
> timestamp of the signature and the application verifying the signature wi=
ll
> look at the OCSP Nonce and match it with the signature's imprint to make
> sure the OCSP response is for the particular document that has signature.
>
> Yes, with a note that a document could contain several signatures. Nonce
> matches the OCSP response to one specific signature.
>
> > In my opinion we should have a new OCSP (and may be CRL) extension to
> support the long term validation of OCSP status. I.e. linking the OCSP
> response with the signed data and leave Nonce extension as it is to preve=
nt
> replay attacks. If everyone agree I am happy to write a draft for that.
>
> Introducing a new extension will create serious operational issues, since=
:
>
> - it'll require update of all OCSP responders
> - it'll require update of all signing applications
> - in order not to invalidate existing signatures, dual validation will
> have to be performed (both with Nonce and with the new extension)
>
> Please note, that Nonce extension according to RFC2560 and RFC6960
> supported all required functionality, the problem was introduced only by
> RFC8954, which set the limit of usable bytes too low.
>
> Thus I propose to only make errata to RFC8954, since the current text wil=
l
> cause implementation/deployment problems for digital signatures.
>
> This errata could increase the limit from 32 bytes to some higher value:
>
> - if size of OCSP responses is of highest concern, value of 96 bytes woul=
d
> be fine for 512 bit hashes like SHA512
> - if the limit should be sufficient for eventual future algorithms with
> 1024 bit hashes, value of 160 can be used.
>
> Reason for errata: Nonce extension is used to carry MessageImprint
> according to RFC3161 in order to link digital signature to OCSP response.
>
>
> With kind regards,
> MD
>

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


Hi Marian,
I am sorry, I don't concur with you on =
this matter. The use case=C2=A0mentioned in ISO 14533 is somewhat analogous=
 to the AEAD in symmetric encryption/decryption. According=C2=A0to the ISO =
14533 we are binding the OCSP response with the event of the digital signat=
ure generated by a particular private key and then bundling the OCSP respon=
se with the digital signature to prove that the status of the key was not r=
evoked at the time of generating the signature.

On=
 the contrary the purpose of Nonce extension is to prevent replay=C2=A0atta=
cks and as discussed in the=C2=A0LAMPS WG the value must be generated using=
 a cryptographically strong random number. I don't think it is a good i=
dea to repurpose an extension for some other function when we are=C2=A0talk=
ing about the security. What if someone replays a valid OCSP response=C2=A0=
after the key has been revoked by guessing the MessageImprint ?=C2=A0=C2=A0=


You are quoting the nonce of RFC3161 out of t=
he context here and it is not relevant=C2=A0to this discussion for=C2=A0OCS=
P. However even RFC3161 mentions in section=C2=A02.4.1=C2=A0that the nonce value should b=
e a large random integer with a suggested size of 64-bit to avoid the repla=
y of the response to=C2=A0TimeStampReq. 

I will agree with what =
Rich said in an earlier email.

Thanks=C2=A0
<=
div>Mohit=C2=A0 =C2=A0

On Sat, Dec 19, 2020 at 1:42 AM Marian =C4=8E=
urkovi=C4=8D <md@bts.sk> wrote:
<=
/div>








On Fri, 18 Dec 2020 17:02:45 -0800, Mohit Sahni wrote



=C2=A0> If my understanding is correct, then the=
=20
OCSP response also goes as part of the digitally signed document along with=
 the=20
signature and the timestamp of the signature and the application verifying =
the=20
signature will look at the OCSP Nonce and match it with the signature's=
=20
imprint=C2=A0to make sure the OCSP response is for the particular document =
that has=20
signature.=20









Yes, with a note that a document could contain severa=
l signatures. Nonce matches the OCSP response to one specific signature.









> In my opinion we should have a new OCSP=20
(and may be CRL) extension to support the long term validation of OCSP stat=
us.=20
I.e. linking the OCSP response with the signed data and leave Nonce extensi=
on as=20
it is to prevent replay attacks. If everyone agree I am happy to write a dr=
aft=20
for that.=20









Introducing a new extension will create serious opera=
tional issues, since:









- it'll require update of all OCSP responders




- it'll require update of all signing application=
s



- in order not to invalidate existing signatures, dua=
l validation will have to be performed (both with Nonce and with the new ex=
tension)








Please note, that Nonce extension according to RFC256=
0 and RFC6960 supported all required functionality, the problem was introdu=
ced only by RFC8954, which set the limit of usable bytes too low.







Thus I propose to only make errata to RFC8954, since =
the current text will cause implementation/deployment problems for digital =
signatures.









This errata could increase the limit from 32 bytes to=
 some higher value:









- if size of OCSP responses is of highest concern, va=
lue of 96 bytes would be fine for 512 bit hashes like SHA512




- if the limit should be sufficient for eventual futu=
re algorithms with 1024 bit hashes, value of 160 can be used.








Reason for errata: Nonce
 extension is used to carry MessageImprint according to RFC3161 in=20
order to link digital signature to OCSP response.














With kind regards,



MD


















--000000000000cca3e205b6cf34ab--


From md@bts.sk  Fri Dec 18 15:00:02 2020
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 EE0B33A0D8B for ; Fri, 18 Dec 2020 15:00:02 -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, HTML_MESSAGE=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 ortBunbnbmZX for ; Fri, 18 Dec 2020 15:00:00 -0800 (PST)
Received: from saus.bts.sk (saus.bts.sk [194.160.23.4]) by ietfa.amsl.com (Postfix) with ESMTP id 06E8F3A0B1D for ; Fri, 18 Dec 2020 14:59:57 -0800 (PST)
Received: from saus.bts.sk ([194.160.23.4] helo=bts.sk) by saus.bts.sk with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1kqOj0-000EqW-Dt; Fri, 18 Dec 2020 23:59:50 +0100
From: "=?UTF-8?Q?Marian_=C4=8Eurkovi=C4=8D?=" 
To: "Salz, Rich" , Russ Housley , Mohit Sahni 
Cc: LAMPS 
Date: Fri, 18 Dec 2020 23:59:50 +0100
Message-Id: <20201218224153.M14899@bts.sk>
In-Reply-To: <7E92C4FB-4118-470A-8BA4-BEA133FA46AF@akamai.com>
References: <20201218103651.M76302@bts.sk>    <7E92C4FB-4118-470A-8BA4-BEA133FA46AF@akamai.com>
X-Mailer: OpenWebMail 2.53
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=OPENWEBMAIL_ATT_0.00132931731374697"
X-Spam-Note: SpamAssassin run bypassed due to hostname whitelisted
Archived-At: 
X-Mailman-Approved-At: Sat, 19 Dec 2020 10:01:59 -0800
Subject: Re: [lamps] Fwd: Conflict between RFC8954 and ISO 14533-4
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, 18 Dec 2020 23:20:12 -0000

This is a multi-part message in MIME format.

------=OPENWEBMAIL_ATT_0.00132931731374697
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

On Fri, 18 Dec 2020 20:30:08 +0000, Salz, Rich wrote

I was completely unaware of anyone placing anything other than a random value in the OCSP nonce field before this message arrived today.  Does anyone know of other situations likethis?

> In the early days of designing OCSP, CertCo and its member banks were going to put the digest of an online message in there, as a way of showing that the message was signed by an entity whose certificate was valid at the time of signing. (Some scant details at https://en.wikipedia.org/wiki/CertCo_(financial_services) )   When CertCo folded, so did that concept I think.

This is very similar - MessageImprint of a digital signature is placed into Nonce as a proof, that this digital signature existed at Production Time of OSCP response, which also means the certificate was valid at the time of signing

> The ISO folks could put a digest of the identifier as the nonce, or they could have a profile that says RFC8954 does not apply.

I'm afraid none of the above will work.

According to RFC3161, Message imprint is defined as:

MessageImprint ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashedMessage OCTET STRING }

Since you need 19 bytes for the structure and AlgorithmIdentifier, with a 32 byte limit imposed on Nonce you'll only have 13 bytes left, which is too few even for legacy & no longer secure algorithms like MD5 or SHA1. And when libraries implement 32 byte limit, anything else will require customized libraries...

For SHA256, you'll need room for at least 19+32=51 bytes in Nonce

For SHA512, you'll need room for at least 19+64=83 bytes in Nonce.

That's why I propose to increase limit from 32 to 128 bytes, which will keep some extra bytes for the future or for other purposes. This will keep all benefits of having a limit in place and at the same time allow Nonce to be used for additional purposes.

With kind regards,

MD

 

------=OPENWEBMAIL_ATT_0.00132931731374697
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable








On Fri, 18 Dec 2020 20:30:08 +0000, Salz, Rich wrote



    


  • I=20
was completely unaware of anyone placing anything other than a random value=
 in=20
the OCSP nonce field before this message arrived today. =C2=A0Does anyone k=
now=20
of other situations=20
like
 this?
    • 






> In the early days of designing OCSP, CertCo and its member =
banks were=20
going to put the digest of an online message in there, as a way of showing =
that=20
the message was signed by an entity whose certificate was valid at the time=
 of=20
signing.=C2=A0

 (Some scant details at 
https://en.wikipedia.org/wiki/CertCo_(financial_services) )=C2=A0=C2=A0=
 When=20
CertCo folded, so did that concept I=20
think.








This is very similar - MessageImprint of a digital signature is placed=
 into Nonce as a proof, that this digital signature existed at Production T=
ime of OSCP response, which also means the certificate was valid at the tim=
e of signing









> The ISO folks could put a digest of t=
he identifier as the nonce, or=20
they could have a profile that says RFC8954 does not=20
apply.








I'm afraid none of the above will work.








According to RFC3161, Message imprint is defined as:










MessageImprint ::=3D SEQUENCE  {
     hashAlgorithm                AlgorithmIdentifier,
     hashedMessage                OCTET STRING  }








Since you need 19 bytes for the structure and AlgorithmIdentifier, wit=
h a 32 byte limit imposed on Nonce you'll only have 13 bytes left, which is=
 too few even for legacy & no longer secure algorithms like MD5 or SHA1=
. And when libraries implement 32 byte limit, anything else will require cu=
stomized libraries...









For SHA256, you'll need room for at least 19+32=3D51 bytes in Nonce


For SHA512, you'll need room for at least 19+64=3D83 bytes in Nonce.







That's why I propose to increase limit from 32 to 128 bytes, which wil=
l keep some extra bytes for the future or for other purposes. This will kee=
p all benefits of having a limit in place and at the same time allow Nonce =
to be used for additional purposes.








With kind regards,



MD













------=OPENWEBMAIL_ATT_0.00132931731374697--


From md@bts.sk  Fri Dec 18 15:19:46 2020
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 9DF3E3A00C9 for ; Fri, 18 Dec 2020 15:19:46 -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, HTML_MESSAGE=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 OvkyZEP3jo8i for ; Fri, 18 Dec 2020 15:19:44 -0800 (PST)
Received: from saus.bts.sk (saus.bts.sk [194.160.23.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0763A00C4 for ; Fri, 18 Dec 2020 15:19:44 -0800 (PST)
Received: from saus.bts.sk ([194.160.23.4] helo=bts.sk) by saus.bts.sk with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1kqP2C-000Ets-BD; Sat, 19 Dec 2020 00:19:40 +0100
From: "=?UTF-8?Q?Marian_=C4=8Eurkovi=C4=8D?=" 
To: Mohit Sahni 
Cc: "Salz, Rich" , Russ Housley , LAMPS 
Date: Sat, 19 Dec 2020 00:19:40 +0100
Message-Id: <20201218230753.M63543@bts.sk>
In-Reply-To: 
References: <20201218103651.M76302@bts.sk>    <7E92C4FB-4118-470A-8BA4-BEA133FA46AF@akamai.com> <20201218224153.M14899@bts.sk> 
X-Mailer: OpenWebMail 2.53
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=OPENWEBMAIL_ATT_0.764464536539407"
X-Spam-Note: SpamAssassin run bypassed due to hostname whitelisted
Archived-At: 
X-Mailman-Approved-At: Sat, 19 Dec 2020 10:01:59 -0800
Subject: Re: [lamps] Fwd: Conflict between RFC8954 and ISO 14533-4
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, 18 Dec 2020 23:21:07 -0000

This is a multi-part message in MIME format.

------=OPENWEBMAIL_ATT_0.764464536539407
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

On Fri, 18 Dec 2020 15:05:41 -0800, Mohit Sahni wrote

> So in this case does OCSP responder fill the Nonce extension with its own data and does not echo back what OCSP client has sent or I am missing something ? Can you please provide more details on the use case. 

No, the proof of existence for the signature relies on the fact, that OCSP responder echoes back exactly what it received from the OCSP client, so no special functionality is needed.

The process looks like this:

- signing application prepares the digital signature and puts its imprint into Nonce field of OCSP request

- OCSP response will contain proof of certificate's validity, trusted ProductionTime and echoed Nonce from the request, linking it to exactly this digital signature

With kind regards,

MD

 

------=OPENWEBMAIL_ATT_0.764464536539407
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable










On Fri, 18 Dec 2020 15:05:41 -0800, Mohit Sahni wr=
ote

> So in this case does OCSP responder fill the Nonce ex=
tension=20
with its own data and does not echo back what OCSP client has sent or I am=
=20
missing something ? Can you please provide more details on the use=20
case.=C2=A0








No, the proof of existence for the signature relies o=
n the fact, that OCSP responder echoes back exactly what it received from t=
he OCSP client, so no special functionality is needed.








The process looks like this:








- signing application prepares the digital signature =
and puts its imprint into Nonce field of OCSP request



- OCSP response will contain proof of certificate's v=
alidity, trusted ProductionTime and echoed Nonce from the request, linking =
it to exactly this digital signature









With kind regards,



MD













------=OPENWEBMAIL_ATT_0.764464536539407--


From nobody Sat Dec 19 10:02:08 2020
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 4C1963A0FBA for ; Sat, 19 Dec 2020 01:43:05 -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, HTML_MESSAGE=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 r5YE2Vg2DtJE for ; Sat, 19 Dec 2020 01:43:02 -0800 (PST)
Received: from saus.bts.sk (saus.bts.sk [194.160.23.4]) by ietfa.amsl.com (Postfix) with ESMTP id B52473A0FB8 for ; Sat, 19 Dec 2020 01:43:01 -0800 (PST)
Received: from saus.bts.sk ([194.160.23.4] helo=bts.sk) by saus.bts.sk with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1kqYlM-000Gbz-AN; Sat, 19 Dec 2020 10:42:56 +0100
From: "=?UTF-8?Q?Marian_=C4=8Eurkovi=C4=8D?=" 
To: Mohit Sahni 
Cc: "Salz, Rich" , Russ Housley , LAMPS 
Date: Sat, 19 Dec 2020 10:42:56 +0100
Message-Id: <20201219085409.M21922@bts.sk>
In-Reply-To: 
References: <20201218103651.M76302@bts.sk>    <7E92C4FB-4118-470A-8BA4-BEA133FA46AF@akamai.com> <20201218224153.M14899@bts.sk>  <20201218230753.M63543@bts.sk> 
X-Mailer: OpenWebMail 2.53
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=OPENWEBMAIL_ATT_0.0259525890901102"
X-Spam-Note: SpamAssassin run bypassed due to hostname whitelisted
Archived-At: 
X-Mailman-Approved-At: Sat, 19 Dec 2020 10:01:59 -0800
Subject: Re: [lamps] Fwd: Conflict between RFC8954 and ISO 14533-4
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, 19 Dec 2020 09:43:05 -0000

This is a multi-part message in MIME format.

------=OPENWEBMAIL_ATT_0.0259525890901102
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

On Fri, 18 Dec 2020 17:02:45 -0800, Mohit Sahni wrote

 > If my understanding is correct, then the OCSP response also goes as part of the digitally signed document along with the signature and the timestamp of the signature and the application verifying the signature will look at the OCSP Nonce and match it with the signature's imprint to make sure the OCSP response is for the particular document that has signature.

Yes, with a note that a document could contain several signatures. Nonce matches the OCSP response to one specific signature.

> In my opinion we should have a new OCSP (and may be CRL) extension to support the long term validation of OCSP status. I.e. linking the OCSP response with the signed data and leave Nonce extension as it is to prevent replay attacks. If everyone agree I am happy to write a draft for that.

Introducing a new extension will create serious operational issues, since:

- it'll require update of all OCSP responders

- it'll require update of all signing applications

- in order not to invalidate existing signatures, dual validation will have to be performed (both with Nonce and with the new extension)

Please note, that Nonce extension according to RFC2560 and RFC6960 supported all required functionality, the problem was introduced only by RFC8954, which set the limit of usable bytes too low.

Thus I propose to only make errata to RFC8954, since the current text will cause implementation/deployment problems for digital signatures.

This errata could increase the limit from 32 bytes to some higher value:

- if size of OCSP responses is of highest concern, value of 96 bytes would be fine for 512 bit hashes like SHA512

- if the limit should be sufficient for eventual future algorithms with 1024 bit hashes, value of 160 can be used.

Reason for errata: Nonceextension is used to carry MessageImprint according to RFC3161 in order to link digital signature to OCSP response.

With kind regards,

MD

 

------=OPENWEBMAIL_ATT_0.0259525890901102
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable








On Fri, 18 Dec 2020 17:02:45 -0800, Mohit Sahni wrote



=C2=A0> If my understanding is correct, then the=
=20
OCSP response also goes as part of the digitally signed document along with=
 the=20
signature and the timestamp of the signature and the application verifying =
the=20
signature will look at the OCSP Nonce and match it with the signature's=20
imprint=C2=A0to make sure the OCSP response is for the particular document =
that has=20
signature.=20









Yes, with a note that a document could contain severa=
l signatures. Nonce matches the OCSP response to one specific signature.









> In my opinion we should have a new OCSP=20
(and may be CRL) extension to support the long term validation of OCSP stat=
us.=20
I.e. linking the OCSP response with the signed data and leave Nonce extensi=
on as=20
it is to prevent replay attacks. If everyone agree I am happy to write a dr=
aft=20
for that.=20









Introducing a new extension will create serious opera=
tional issues, since:









- it'll require update of all OCSP responders




- it'll require update of all signing applications



- in order not to invalidate existing signatures, dua=
l validation will have to be performed (both with Nonce and with the new ex=
tension)








Please note, that Nonce extension according to RFC256=
0 and RFC6960 supported all required functionality, the problem was introdu=
ced only by RFC8954, which set the limit of usable bytes too low.







Thus I propose to only make errata to RFC8954, since =
the current text will cause implementation/deployment problems for digital =
signatures.









This errata could increase the limit from 32 bytes to=
 some higher value:









- if size of OCSP responses is of highest concern, va=
lue of 96 bytes would be fine for 512 bit hashes like SHA512




- if the limit should be sufficient for eventual futu=
re algorithms with 1024 bit hashes, value of 160 can be used.








Reason for errata: Nonce
 extension is used to carry MessageImprint according to RFC3161 in=20
order to link digital signature to OCSP response.














With kind regards,



MD















------=OPENWEBMAIL_ATT_0.0259525890901102--


From nobody Sat Dec 19 10:02:11 2020
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 0C2883A105A for ; Sat, 19 Dec 2020 04:50:38 -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, HTML_MESSAGE=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 5X275Z63gj7E for ; Sat, 19 Dec 2020 04:50:36 -0800 (PST)
Received: from saus.bts.sk (saus.bts.sk [194.160.23.4]) by ietfa.amsl.com (Postfix) with ESMTP id F26EC3A1059 for ; Sat, 19 Dec 2020 04:50:35 -0800 (PST)
Received: from saus.bts.sk ([194.160.23.4] helo=bts.sk) by saus.bts.sk with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1kqbgr-000HCx-Su; Sat, 19 Dec 2020 13:50:30 +0100
From: "=?UTF-8?Q?Marian_=C4=8Eurkovi=C4=8D?=" 
To: Mohit Sahni 
Cc: "Salz, Rich" , Russ Housley , LAMPS 
Date: Sat, 19 Dec 2020 13:50:29 +0100
Message-Id: <20201219121104.M37970@bts.sk>
In-Reply-To: 
References: <20201218103651.M76302@bts.sk>    <7E92C4FB-4118-470A-8BA4-BEA133FA46AF@akamai.com> <20201218224153.M14899@bts.sk>  <20201218230753.M63543@bts.sk>  <20201219085409.M21922@bts.sk> 
X-Mailer: OpenWebMail 2.53
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=OPENWEBMAIL_ATT_0.943236440277786"
X-Spam-Note: SpamAssassin run bypassed due to hostname whitelisted
Archived-At: 
X-Mailman-Approved-At: Sat, 19 Dec 2020 10:01:59 -0800
Subject: Re: [lamps] Fwd: Conflict between RFC8954 and ISO 14533-4
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, 19 Dec 2020 12:50:38 -0000

This is a multi-part message in MIME format.

------=OPENWEBMAIL_ATT_0.943236440277786
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

On Sat, 19 Dec 2020 03:05:32 -0800, Mohit Sahni wrote

> On the contrary the purpose of Nonce extension is to prevent replay attacks and as discussed in the LAMPS WG the value must be generated using a cryptographically strong random number. I don't think it is a good idea to repurpose an extension for some other function when we are talking about the security. What if someone replays a valid OCSP response after the key has been revoked by guessing the MessageImprint ? 

This OSCP response is only usable for specific signer of a specific document signed at specific time. All these inputs are hashed by at least SHA256, signed by signer's private key and the resulting signature is again hashed by at least SHA256 to get MessageImprint, which is inserted into Nonce - so its randomnes is ensured. Could you please elaborate, how are you able to guess this kind of Nonce? If that would be possible, we won't be able to trust any digital signature, since the same procedure is being used for Timestamp tokens!

By filling Nonce with MessageImprint, the signing application is generating 32 (for SHA256) or 64 (for SHA512) highly random bytes. This kind of Nonce thus serves both purposes - ensures security against replay attacks and provides trusted binding between the specific signature in specific document and associated OCSP response. The only real problem is, that RFC8954 set the max bytes limit too low and there's hardly any good reason why it couldn't be increased from 32 to e.g. 96 bytes.

With kind regards,

MD

 

------=OPENWEBMAIL_ATT_0.943236440277786
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable








On Sat, 19 Dec 2020 03:05:32 -0800, Mohit Sahni wrote



> On the contrary the purpose of Nonce extension i=
s to=20
prevent replay=C2=A0attacks and as discussed in the=C2=A0LAMPS WG the value=
 must be=20
generated using a cryptographically strong random number. I don't think it=
=20
is a good idea to repurpose an extension for some other function when we=20
are=C2=A0talking about the security. What if someone replays a valid OCSP=
=20
response=C2=A0after the key has been revoked by guessing the MessageImprint=
=20
?=C2=A0=20









This OSCP response is only usable for specific signer=
 of a specific document signed at specific time. All these inputs are hashe=
d by at least SHA256, signed by signer's private key and the resulting sign=
ature is again hashed by at least SHA256 to get MessageImprint, which is in=
serted into Nonce - so its randomnes is ensured. Could you please elaborate=
, how are you able to guess this kind of Nonce? If that would be possible, =
we won't be able to trust any digital signature, since the same procedure i=
s being used for Timestamp tokens!









By filling Nonce with MessageImprint, the signing app=
lication is generating 32 (for SHA256) or 64 (for SHA512) highly random byt=
es. This kind of Nonce thus serves both purposes - ensures security against=
 replay attacks and provides trusted binding between the specific signature=
 in specific document and associated OCSP response. The only real problem i=
s, that RFC8954 set the max bytes limit too low and there's hardly any good=
 reason why it couldn't be increased from 32 to e.g. 96 bytes.








With kind regards,



MD







------=OPENWEBMAIL_ATT_0.943236440277786--


From nobody Sat Dec 19 12:21:53 2020
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 470D23A0EED for ; Sat, 19 Dec 2020 12:21:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1o_MbjosoFzl for ; Sat, 19 Dec 2020 12:21:50 -0800 (PST)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 CAB8E3A0EEC for ; Sat, 19 Dec 2020 12:21:50 -0800 (PST)
Received: by mail-pj1-x102d.google.com with SMTP id m5so3391033pjv.5 for ; Sat, 19 Dec 2020 12:21:50 -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=1t4Pit07g2aicrFdaiQW+hNqC8lmeKaGzfrGy5IE1AQ=; b=ltaGF2fH8S115zjnU4PwxV3ag0ZKKq6qYIc7Yuu0d0upfLOzrptZbHV8cb8Wx/yDON rFIDq5HI9UrcE/DjNekF402DR5PcbrlmDyur11ethUtsClDKvxRDnm7D7KouqOWjr9Ol /dcqoiyg1KV0o8m/Vg7r9NoRKe915pCFW56uXi68fWN6gAYJXo+jm/vAuUA+iWQhaH1Y 0q066kYRqqK72+cTj1H+zCDg4gy5uWAgy3GId0Wy2DBGU3z/U11UQaHNxKZewma7C6Ff 3gsoyjOHPa7QX6MjO4JKlJJW4yKfmKq/YsYeqSH2hwUF/0yZfw9Y6pkfywMOm7XbSJOy KmlA==
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=1t4Pit07g2aicrFdaiQW+hNqC8lmeKaGzfrGy5IE1AQ=; b=L5o2eQgsf20r6x+ZEpUF2c9yG/6jy5bV0uiJrskkBz81+s+bf8e5YdPUC7KHJY8+/A JoVbl36bBBi78f9BgFKUBK/A2IMHnFcB/l96kHItpHPQSF6tL0QE3IFYONVXaOuGppXM Ljj+Rko0iK48AkgkwinAI05TRYIsiiYRnziOCFgtzI60zneqHPxMZi+zCSKsutsWwbNi pydR+jUZk9T44XisPhu6IIp+AZ2eefLPZJ2QZKXwWdq5g6JdK8kKiDmFfJcOO8fI45n2 TunhplxfTSWjAwhFzBoFHj/LfpCfn0XjG2mXhhBkyGXkAmDdZgjIcmDhpskKLA8CVQcr +/pw==
X-Gm-Message-State: AOAM532EtQcUA+kiyklpoa1rkogScGkC/c8chVy6q+6qsoBk6315clII Iu1JbCwsc8Y2dKKKLXBT8iDlK6sQW0LbFdqeTmX/a65BUDE=
X-Google-Smtp-Source: ABdhPJyZY5Z5GfsTtmfNc8GFSw00VWAn4DqGY9Bl6+S/NuUwyEkiFPawiJx6PLyOSloRYFfKNUSdiI9S5aiW4hPGOck=
X-Received: by 2002:a17:90a:b118:: with SMTP id z24mr10192429pjq.14.1608409310372;  Sat, 19 Dec 2020 12:21:50 -0800 (PST)
MIME-Version: 1.0
References:   <44EBF4BD-7560-492B-A061-CC9CCB848D08@vigilsec.com>  
In-Reply-To: 
From: Lijun Liao 
Date: Sat, 19 Dec 2020 21:21:39 +0100
Message-ID: 
To: Russ Housley 
Cc: "Brockhaus, Hendrik" , "spasm@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000099276d05b6d6f9e1"
Archived-At: 
Subject: Re: [lamps] Mail regarding draft-ietf-lamps-cmp-updates
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, 19 Dec 2020 20:21:52 -0000

--00000000000099276d05b6d6f9e1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

What about the following suggestions
1. In the PKIHeader add an InfoTypeAndValue to the generalInfo field. This
new element contains the supported CMP versions of the sending party.
2. The CMP version is set to 3, if the PKIMessage contains fields not
conforming to RFC4210.

- Lijun

On Tue, Dec 15, 2020 at 5:21 PM Russ Housley  wrote:

>
>
> > On Dec 15, 2020, at 4:18 AM, Brockhaus, Hendrik <
> hendrik.brockhaus@siemens.com> wrote:
> >
> > Russ
> >
> >> -----Urspr=C3=BCngliche Nachricht-----
> >> Von: Russ Housley 
> >>
> >>> On Dec 11, 2020, at 2:48 PM, Brockhaus, Hendrik
> >>  wrote:
> >>>
> >>>> Von: Spasm  Im Auftrag von Lijun Liao
> >>>> Gesendet: Freitag, 11. Dezember 2020 20:13
> >>>>
> >>>> If the CA uses the envelopedData choice, the CMP client that does no=
t
> >> support this draft, cannot process the response. So the CA needs a
> >> mechanism to determine whether the CMP client supports > this draft or
> >> not. You should increase the CMP version or add some other fields in t=
he
> >> CMP request to provide the CA such information.
> >>>
> >>> Our goal was to make only minimal changes to CMP to circumvent
> >> increasing the CMP version.
> >>
> >> When we have done things like this in CMS, we say when encryptedValue =
is
> >> used, the version MUST be X, and when envelopedData is used, the versi=
on
> >> MUST be x+1.  This allows an unsupported version error instead of a ba=
d
> >> format.
> >>
> >
> > Can we stick to the concept of updating RFC4210 when introducing a CMP
> V3 version for usage of EnvelopedData?
> > Or does the introduction of a new version number requires to obsolete
> RFC4210?
>
> I do not see a problem.
>
> Russ
>
>

--=20
Lijun Liao

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


What about the following suggestions
1. In =
the PKIHeader add an InfoTypeAndValue to the generalInfo field. This new el=
ement contains the supported CMP versions of the sending party.
2=
. The CMP version is set to 3, if the PKIMessage contains fields not confor=
ming to RFC4210.

- Lijun

On Tue, Dec 15, =
2020 at 5:21 PM Russ Housley <ho=
usley@vigilsec.com> wrote:




> On Dec 15, 2020, at 4:18 AM, Brockhaus, Hendrik <hendrik.brockhaus@siemens.=
com> wrote:

> 

> Russ

> 

>> -----Urspr=C3=BCngliche Nachricht-----

>> Von: Russ Housley <housley@vigilsec.com>

>> 

>>> On Dec 11, 2020, at 2:48 PM, Brockhaus, Hendrik

>> <hendrik.brockhaus@siemens.com> wrote:

>>> 

>>>> Von: Spasm <spasm-bounces@ietf.org> Im Auftrag von Lijun Liao
>>>> Gesendet: Freitag, 11. Dezember 2020 20:13

>>>> 

>>>> If the CA uses the envelopedData choice, the CMP client th=
at does not

>> support this draft, cannot process the response. So the CA needs a=


>> mechanism to determine whether the CMP client supports > this d=
raft or

>> not. You should increase the CMP version or add some other fields =
in the

>> CMP request to provide the CA such information.

>>> 

>>> Our goal was to make only minimal changes to CMP to circumvent=


>> increasing the CMP version.

>> 

>> When we have done things like this in CMS, we say when encryptedVa=
lue is

>> used, the version MUST be X, and when envelopedData is used, the v=
ersion

>> MUST be x+1.=C2=A0 This allows an unsupported version error instea=
d of a bad

>> format.

>> 

> 

> Can we stick to the concept of updating RFC4210 when introducing a CMP=
 V3 version for usage of EnvelopedData?

> Or does the introduction of a new version number requires to obsolete =
RFC4210?



I do not see a problem.



Russ






-- 
Lijun Liao


--00000000000099276d05b6d6f9e1--


From nobody Sat Dec 19 13:12:31 2020
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 7D3CE3A0A22 for ; Sat, 19 Dec 2020 13:12:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwKkIajFkFIp for ; Sat, 19 Dec 2020 13:12:28 -0800 (PST)
Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 CFC843A09D6 for ; Sat, 19 Dec 2020 13:12:28 -0800 (PST)
Received: by mail-il1-x131.google.com with SMTP id k8so5494876ilr.4 for ; Sat, 19 Dec 2020 13:12:28 -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=ZBf8LiDV/yRjcW9dhy6h8omDzQYafudpH5hfabSPTOU=; b=jZYA5raQjmDdhbH0t99Kvcd2kv8rfNj3m52i7LHk5Ou/HgWVK71EVB6G5A3ZKXGdqb X09T//plU8wxeefeW7I4kQZ+D+58M6ZhPOuoCdpHteNesHBVtn8Ssyr0Qs1F6I5RthHI YYfNnQquHviWhz3gLSTPhM75GNeNhhCn6HONL/jID3qnPbqyLdwsHQIItG+lM7AjTGXj Xkv6DdJJcYBlWrrvktLEh08YgjWSA2YKmWhMi9NUccUALMLQHhOpY352OoVUlEdIFlPM InlrInoTVn5e/fGBnmPvHn01TCQmmapQ5sHKGJmLXvT+2O68A/YV7pOrouALO8FIfJgV YeSA==
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=ZBf8LiDV/yRjcW9dhy6h8omDzQYafudpH5hfabSPTOU=; b=j7e0mGrb+6uewQpZTuxOJK/jaCH/8mn+2YdNgZ471zyt33ZH1LPmGEruexw2oH4ViE hW7gvCzQ6V6DSwk7b3ykXSsPxnkrf0UYhPcT6Vklsn3meDnZz7maY0YwbYOySYEyCzHS ZDNxFh3wtgWPlPyWNrsoDCsoDycif20qWrAptQ/0f7XWt7NDybsc9CTdlpNIDyLYPGF/ NXLD8LuYsyaPSYaR4jw6+YNpM/SntVos8sXurs8TR8yEry3LyvJf9D3R72IoUTkqygfh 1V2tiGlhnvu96hjNdrOLHdeZU54Ywed/KpnA9n6N5t/xZJyZd/hu7PNcwIeaOVGZ41bS SFDg==
X-Gm-Message-State: AOAM532xCkzZ8iEjjf2o9kIhp9PAJ3M9i/kjULaawUcbCaibknHe6TLQ UV5ofUEafbxg1x2tTvhipghTufLf3kbuwzgZ/5o=
X-Google-Smtp-Source: ABdhPJyAGQNMho3nnhgWYN5vbeVyDu+DoI6rF6W6aVkGeBsAJJnR7frHdufJYQB6fh9RJoW5+d7VErFkhJzc11gtjFM=
X-Received: by 2002:a92:b008:: with SMTP id x8mr10661407ilh.297.1608412348021;  Sat, 19 Dec 2020 13:12:28 -0800 (PST)
MIME-Version: 1.0
References: <20201218103651.M76302@bts.sk>    <7E92C4FB-4118-470A-8BA4-BEA133FA46AF@akamai.com> <20201218224153.M14899@bts.sk>  <20201218230753.M63543@bts.sk>  <20201219085409.M21922@bts.sk>  <20201219121104.M37970@bts.sk>
In-Reply-To: <20201219121104.M37970@bts.sk>
From: Mohit Sahni 
Date: Sat, 19 Dec 2020 13:12:17 -0800
Message-ID: 
To: =?UTF-8?B?TWFyaWFuIMSOdXJrb3ZpxI0=?= 
Cc: "Salz, Rich" , Russ Housley , LAMPS 
Content-Type: multipart/alternative; boundary="000000000000a8006b05b6d7aeea"
Archived-At: 
Subject: Re: [lamps] Fwd: Conflict between RFC8954 and ISO 14533-4
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, 19 Dec 2020 21:12:31 -0000

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

Hi Marian
>From OCSP point of view the MessageImprint is not a random value but it is
a deterministic value generated for a given input by a collision resistant
one way hash function. One more reason I see for not changing the Nonce
extension length is that the length of MessageImprint is not fixed but
varies based on the underlying hash algorithm.  Since RFC3161 does not
provide a fixed list of Hash functions, let's say we change the size to
Nonce extension to 64 bytes, what if in the future there is a new hash
algorithm or some proprietary hash function that requires size to be 128
bytes or 256 bytes or may be 100 GigaBytes, are we going to increase the
size of the Nonce extension again?  How can we set an upper limit on Nonce
which also serves the regular Nonce use case of just avoiding the replay
attacks ?

In my opinion, ISO 14533 took advantage of the security vulnerability that
existed in RFC6960 and tried using Nonce extension in a way it was not
intended to be used as i.e. using an ASN.1 SEQUENCE where the standard
requires use of OCTET STRING. We should come up with a new extension for
associating the OCSP response with the context where OCSP is being used for
long term validation. That is the right thing to do.

-Mohit

On Sat, Dec 19, 2020 at 4:50 AM Marian =C4=8Eurkovi=C4=8D  wrote=
:

> *On Sat, 19 Dec 2020 03:05:32 -0800, Mohit Sahni wrote*
> > On the contrary the purpose of Nonce extension is to prevent
> replay attacks and as discussed in the LAMPS WG the value must be generat=
ed
> using a cryptographically strong random number. I don't think it is a goo=
d
> idea to repurpose an extension for some other function when we are talkin=
g
> about the security. What if someone replays a valid OCSP response after t=
he
> key has been revoked by guessing the MessageImprint ?
>
> This OSCP response is only usable for specific signer of a specific
> document signed at specific time. All these inputs are hashed by at least
> SHA256, signed by signer's private key and the resulting signature is aga=
in
> hashed by at least SHA256 to get MessageImprint, which is inserted into
> Nonce - so its randomnes is ensured. Could you please elaborate, how are
> you able to guess this kind of Nonce? If that would be possible, we won't
> be able to trust any digital signature, since the same procedure is being
> used for Timestamp tokens!
>
> By filling Nonce with MessageImprint, the signing application is
> generating 32 (for SHA256) or 64 (for SHA512) highly random bytes. This
> kind of Nonce thus serves both purposes - ensures security against replay
> attacks and provides trusted binding between the specific signature in
> specific document and associated OCSP response. The only real problem is,
> that RFC8954 set the max bytes limit too low and there's hardly any good
> reason why it couldn't be increased from 32 to e.g. 96 bytes.
>
> With kind regards,
> MD
>

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


Hi Marian
From OCSP point of view the=C2=A0=
MessageImprint is not a random value but it is a deterministic value genera=
ted for a given input by a collision resistant one way hash function. One m=
ore reason I see for not changing the Nonce extension length is that the le=
ngth of=C2=A0MessageImprint is not fixed but varies based on the underlying=
 hash algorithm.=C2=A0 Since RFC3161 does not provide a fixed list of Hash =
functions, let's say we change the size to Nonce extension to 64 bytes,=
 what if in the future there is a new hash algorithm or some proprietary ha=
sh function that requires size to be 128 bytes or 256 bytes or may be 100 G=
igaBytes, are we going to increase the size of the Nonce extension again?=
=C2=A0 How can we set an upper limit on Nonce which also serves the regular=
 Nonce use case of just avoiding the replay attacks ?=C2=A0

<=
/div>
In my opinion, ISO 14533 took advantage of the security vulnerabi=
lity that existed in RFC6960 and tried using Nonce extension in a way it wa=
s not intended to be used as i.e. using an ASN.1 SEQUENCE where the standar=
d requires=C2=A0use of OCTET=C2=A0STRING. We should come up with a new exte=
nsion for associating the OCSP response with the context where OCSP is bein=
g used for long term validation. That is the right thing to do.=C2=A0
=


-Mohit=C2=A0

On Sat, Dec 19, 2020 at 4:50 AM =
Marian =C4=8Eurkovi=C4=8D <md@bts.sk> wrote:








On Sat, 19 Dec 2020 03:05:32 -0800, Mohit Sahni wrote



> On the contrary the purpose of Nonce extension i=
s to=20
prevent replay=C2=A0attacks and as discussed in the=C2=A0LAMPS WG the value=
 must be=20
generated using a cryptographically strong random number. I don't think=
 it=20
is a good idea to repurpose an extension for some other function when we=20
are=C2=A0talking about the security. What if someone replays a valid OCSP=
=20
response=C2=A0after the key has been revoked by guessing the MessageImprint=
=20
?=C2=A0=20









This OSCP response is only usable for specific signer=
 of a specific document signed at specific time. All these inputs are hashe=
d by at least SHA256, signed by signer's private key and the resulting =
signature is again hashed by at least SHA256 to get MessageImprint, which i=
s inserted into Nonce - so its randomnes is ensured. Could you please elabo=
rate, how are you able to guess this kind of Nonce? If that would be possib=
le, we won't be able to trust any digital signature, since the same pro=
cedure is being used for Timestamp tokens!









By filling Nonce with MessageImprint, the signing app=
lication is generating 32 (for SHA256) or 64 (for SHA512) highly random byt=
es. This kind of Nonce thus serves both purposes - ensures security against=
 replay attacks and provides trusted binding between the specific signature=
 in specific document and associated OCSP response. The only real problem i=
s, that RFC8954 set the max bytes limit too low and there's hardly any =
good reason why it couldn't be increased from 32 to e.g. 96 bytes.








With kind regards,



MD










--000000000000a8006b05b6d7aeea--


From nobody Mon Dec 21 03:04:44 2020
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 A04AE3A10BA for ; Mon, 21 Dec 2020 03:04:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=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 akyGUT8dYd5o for ; Mon, 21 Dec 2020 03:04:40 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60040.outbound.protection.outlook.com [40.107.6.40]) (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 7B5653A10B5 for ; Mon, 21 Dec 2020 03:04:40 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HgjSa22nzKjPjlNR2y+E9MsJjcDRkA5GE4GjgIgCT9gip4CyAvGlmBHgQ7ZKeI+eMZoZ8DXNjS2Q/xcZ9snPJoceEyMxfSsivskHhCSh9+Vs8Zjy7iaqvcDJfGI2mw4A8KCiO3Ay566sxCgzP/viGmVr4et9X1/w2gQZ8i2WvP7DYTS6f1ijfUvjU3xdxiPkf+9x+GNgDyiqBS2xWp8BG0LJkjoFaqQPIjPHR6s0tKpPh81NjFru3v+HzbN+PrgZ8cVEhR/OjDzzQW3aEbkqiEIhPQPnKzVnbscTlBL9u7hDifWr7MnE4oRks9XO982+Fe8KCq9+9cRyEowxa6CWUA==
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=GlS/Kk7JRpZ17VmzTLTK7knbLk4HAcibLD+Q9h+xGO8=; b=TCD2lo7cjcIVz+1RrIoXE8q+RDjVskImSvq3vwMuaPoSZscrkkD+0BEY0DdW9B/bT6Pjpfqv+czCEYCMuPH8Pu5CFKq8ifd6ZV+byrvMVeKKs1IIQX7MgWJJaLwrrLIwoevZ5QrSnEFNCVB0fVwdbc5CDkseDc28xduKD+DquuyewfjOSSeQOu+ap/4vdDOPokmJIriXfxiurvk6bn70IBvI/DpRyhAk+BX90w8RXDZSN51OU56SY4JV5mp2G3armR7y/GcSFgcnlLYjIhReG2dr4PMPhMP34ytaGLQutj+zt9SwXSoTsVH9LOak7Sz9k4h9OD4MBqLDswj1wHkkxg==
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=GlS/Kk7JRpZ17VmzTLTK7knbLk4HAcibLD+Q9h+xGO8=; b=EbGYzFoKLiYVMBriYNQA75k7iDqyUH6vBIc9CBC+bq9/9+T0mpdEsk4PJ/+hia01awE3KDRi85KFiLTD/NR5DmAMADCBEYj3cjuNGoc9MD0OKWXYyfRnINau+ndmF/vcLS/hN4rTS3R8s4eGRycHogxkSZRJReEBjM6gXLCnnn8=
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM0PR10MB3458.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:15c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.29; Mon, 21 Dec 2020 11:04:38 +0000
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69%6]) with mapi id 15.20.3676.033; Mon, 21 Dec 2020 11:04:38 +0000
From: "Brockhaus, Hendrik" 
To: Lijun Liao , Russ Housley 
CC: "spasm@ietf.org" 
Thread-Topic: [lamps] Mail regarding draft-ietf-lamps-cmp-updates
Thread-Index: AQHWz/G52ReRDe2aYUmX7qyUfOqxtanyRpewgAAIvICABZVWgIAAeC0AgAaMY4CAAoYK8A==
Date: Mon, 21 Dec 2020 11:04:38 +0000
Message-ID: 
References:   <44EBF4BD-7560-492B-A061-CC9CCB848D08@vigilsec.com>   
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-12-21T11:04:36Z;  MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=cbc42343-68cd-4f44-b3e0-916013e955ad; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=siemens.com;
x-originating-ip: [165.225.200.160]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: cadfe86e-7a76-45a6-a7d0-08d8a5a0358f
x-ms-traffictypediagnostic: AM0PR10MB3458:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: GpI1BfJjpiM79te5Vyf2YVuJNSl2ReU+LIG/6lEqgcuEUTi12X/JkBU+22msjVU7PHnfOpcg/69LEQJFBZUqGr/dbRZKKlNA0iOA4V2rEn/Zy4gkkXVitzaAshT0lC5GGOomgfKozaKKRaQgme7irgHRjKQJZYPA7u4yYddmsu9ASz/k7YhMHy0WYbdbXw+gexlkaurvpB5HJNAFQnSkLEyOBmy8CKDuywOnrwlVTMtrdfhjW/jaUm3XaJeMULPVO9gGe98M+El0TjBlX4EVRYRdHV9o/SX8DZlY/s5yEL/jMaIO5nxyZxdxpcRoiAEGnuvQCvWTkblLy2HZV6jcuyHnfug2TD9d4Eu4ZaCAm2lWMKeKNN2/On5PCV1g5AmmxmErMt+mUyUv2GG4WT3UGg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(4636009)(396003)(346002)(39860400002)(366004)(136003)(376002)(64756008)(66946007)(66556008)(66476007)(76116006)(7696005)(66446008)(15650500001)(52536014)(6506007)(5660300002)(53546011)(316002)(508600001)(55016002)(110136005)(8676002)(8936002)(83380400001)(33656002)(4326008)(186003)(66574015)(9686003)(86362001)(71200400001)(2906002)(55236004)(26005); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?utf-8?B?VUJrTXNOM1h3SzlWaGVBam1JUTJPYjFGNDlORXFRejU1YURKWnNyTXo0azFM?= =?utf-8?B?aldIWXNUcExNVW1ubW9laElUdXowbEQrb0paZ2h1S3ZiTVZvRnN2cWNLcmRj?= =?utf-8?B?cmthSFpsNTRhYUl3VFV0dU1RSHErZjdYN1UzMUNGMk9VL2N3Um5GOWh4MlB5?= =?utf-8?B?NEM5dXVieXdmM0hGb0NncU52MDliZ21IVWh6OGNhUjFkMElmMkg1YVNwalo1?= =?utf-8?B?N0JKMFhnNm1RVDBPbVRmaWJRVVUzNTlCN01LRTlDZWdJZ3NoNGdmMk9vaWRQ?= =?utf-8?B?UmZ1VG9zWE8yTzRlTWh5d1FIZWJGRnNhbHh5N0xSY1hSS2lvVDd1TjIrUXoz?= =?utf-8?B?ODliZUVSUlIvS3dWU1p1bUZDTWtCaTBETlhWQ0NhS2oxazVUYVJHTmNWNXJj?= =?utf-8?B?alVrU3p1S1AyOHAvOWlOS0RqNXV2eU40cGxRWS8vWTAyQVJNd3ZqdXpsOXR5?= =?utf-8?B?a2ZOd2ZqWlNObVU5N3IwWXp6dDFqaUdmb2J6Wmt4WCtTemdnc3FzaC9sdVYz?= =?utf-8?B?TTBTUkNvaTZLaGVhSHhyUmEwZ29XTS96cHdRNk0vcUoranBmRW1UQVlnREZa?= =?utf-8?B?SHdObEZ3ajc2RHdPak4vcGxuNjJqd2t3eHRJczNiVkF1d28rRXFseWg4ZHVJ?= =?utf-8?B?a3RTdEExcytWdDEzdSs3dE1TaDVtVk9CbzFRY0ozNHNGclJSdWZLQ1ZLZnk4?= =?utf-8?B?YlFBQ0RLcWpNMVRod1lVZjlYTFZoWGdxeUd4VnU2c2ZJVEtkbU1kWXJBa3ZU?= =?utf-8?B?VnRiTFE2NGlEczNjS0xjcWEyTU96ZEx0a1pTMkYxV0N3eXZNVmt4THBwOS9W?= =?utf-8?B?MXN5MjZpcVorYkJUUmJKVnRaMkdmVW4rS1NJV3BZdnAwcjI3L1ZxdXFkdTB1?= =?utf-8?B?cCtZZEJIakxqcWsxTGxZb0tlQkxRTEhONWN2REY4UGZHaXVkRTZOcUl5UUVB?= =?utf-8?B?Q0hPditXRlBTSzR2SWhqUkpjUzJ3UWJNcENNb3J5alEyMVQrblBJR3hMZnFm?= =?utf-8?B?aURscjFBSzg5VG5xemlsMjJDZEc2ZmRwQ1k1Zk5oNWFpRjE1MjBvbjl5cWx5?= =?utf-8?B?bmZCZ2wwSVZTQ0k1L1BTUmx0T1FtRC9OUitKUTlVMGpHM3pHSTJuWFJTcjk3?= =?utf-8?B?aXhicEdDTmRBQTZTQTVvUk5KN1A4U21pZnoxVnMrVUVBOENJcFJBV09xdWVz?= =?utf-8?B?Z2pBdElQY0pOK214VVhzcGQ0M3pJUlJ0NlVjMGF6aXp4RnlsTllFNXkyamNx?= =?utf-8?B?L0hRblV2K0FjaTFnZUd6dGNTOHhYNnVzK0tSODh2Mzl0NGQzaWFqaXlRSmpF?= =?utf-8?Q?IH8njqC1MQclI=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM0PR10MB2418697CCCC55F0B2109217EFEC00AM0PR10MB2418EURP_"
MIME-Version: 1.0
X-OriginatorOrg: siemens.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: cadfe86e-7a76-45a6-a7d0-08d8a5a0358f
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2020 11:04:38.3873 (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: LJWWj4cL4gnSa0WKJ1Gpv0kN+lYwamdZ0A/Tz4Py8WBai1axv1DahazpGEvbpO6XWzlwooFN0ygaUNjyWzurbzsu9uu2MT+7shdBpx3MNnY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB3458
Archived-At: 
Subject: Re: [lamps] Mail regarding draft-ietf-lamps-cmp-updates
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, 21 Dec 2020 11:04:43 -0000

--_000_AM0PR10MB2418697CCCC55F0B2109217EFEC00AM0PR10MB2418EURP_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgTGlqdW4NCg0KSSBjYW4gc2VlIHlvdXIgcG9pbnQgYW5kIHRlbmQgdG8gcHJlZmVyIHRoZSBz
dWdnZXN0aW9uIG9mIFJ1c3MuDQpUaGVyZWZvcmUgSSBpbnZlc3RpZ2F0ZSB3aGF0IG5lZWRzIHRv
IGJlIHVwZGF0ZWQgaW4gQ01QIFVwZGF0ZXMgdG8gaW50cm9kdWNlIGEgQ01QIFYzIG9ubHkgaW4g
Y2FzZSBFbnZlbG9wZWREYXRhIGlzIHJlcXVpcmVkIGluIGEgdHJhbnNhY3Rpb24gYW5kIHN1cHBv
cnRlZCBieSB0aGUgY2xpZW50Lg0KQ3VycmVudGx5IEkgdGhpbmsgaW4gUkZDNDIxMCwgbmV4dCB0
byBzZWN0aW9uIDUuMi4yLCBzZWN0aW9ucyAxLCA1LjEuMSwgNywgRC4xLCBhbmQgRiBuZWVkIHRv
IGJlIHVwZGF0ZXMuIE1heSBiZSBzZWN0aW9ucyA1LjMuNCBhbmQgNS4zLjE5Ljkgd291bGQgYWxz
byBuZWVkIGFuIGV4cGxhbmF0b3J5IG5vdGUuDQpEbyB5b3Ugc2VlIGZ1cnRoZXIgc2VjdGlvbnMg
dGhhdCBuZWVkIHVwZGF0ZXM/DQoNCkhlbmRyaWsNCg0KVm9uOiBMaWp1biBMaWFvIDxsaWp1bi5s
aWFvQGdtYWlsLmNvbT4NCkdlc2VuZGV0OiBTYW1zdGFnLCAxOS4gRGV6ZW1iZXIgMjAyMCAyMToy
Mg0KQW46IFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+DQpDYzogQnJvY2toYXVz
LCBIZW5kcmlrIChUIFJEQSBDU1QgU0VBLURFKSA8aGVuZHJpay5icm9ja2hhdXNAc2llbWVucy5j
b20+OyBzcGFzbUBpZXRmLm9yZw0KQmV0cmVmZjogUmU6IFtsYW1wc10gTWFpbCByZWdhcmRpbmcg
ZHJhZnQtaWV0Zi1sYW1wcy1jbXAtdXBkYXRlcw0KDQpXaGF0IGFib3V0IHRoZSBmb2xsb3dpbmcg
c3VnZ2VzdGlvbnMNCjEuIEluIHRoZSBQS0lIZWFkZXIgYWRkIGFuIEluZm9UeXBlQW5kVmFsdWUg
dG8gdGhlIGdlbmVyYWxJbmZvIGZpZWxkLiBUaGlzIG5ldyBlbGVtZW50IGNvbnRhaW5zIHRoZSBz
dXBwb3J0ZWQgQ01QIHZlcnNpb25zIG9mIHRoZSBzZW5kaW5nIHBhcnR5Lg0KMi4gVGhlIENNUCB2
ZXJzaW9uIGlzIHNldCB0byAzLCBpZiB0aGUgUEtJTWVzc2FnZSBjb250YWlucyBmaWVsZHMgbm90
IGNvbmZvcm1pbmcgdG8gUkZDNDIxMC4NCg0KLSBMaWp1bg0KDQpPbiBUdWUsIERlYyAxNSwgMjAy
MCBhdCA1OjIxIFBNIFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb208bWFpbHRvOmhv
dXNsZXlAdmlnaWxzZWMuY29tPj4gd3JvdGU6DQoNCg0KPiBPbiBEZWMgMTUsIDIwMjAsIGF0IDQ6
MTggQU0sIEJyb2NraGF1cywgSGVuZHJpayA8aGVuZHJpay5icm9ja2hhdXNAc2llbWVucy5jb208
bWFpbHRvOmhlbmRyaWsuYnJvY2toYXVzQHNpZW1lbnMuY29tPj4gd3JvdGU6DQo+DQo+IFJ1c3MN
Cj4NCj4+IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4+IFZvbjogUnVzcyBI
b3VzbGV5IDxob3VzbGV5QHZpZ2lsc2VjLmNvbTxtYWlsdG86aG91c2xleUB2aWdpbHNlYy5jb20+
Pg0KPj4NCj4+PiBPbiBEZWMgMTEsIDIwMjAsIGF0IDI6NDggUE0sIEJyb2NraGF1cywgSGVuZHJp
aw0KPj4gPGhlbmRyaWsuYnJvY2toYXVzQHNpZW1lbnMuY29tPG1haWx0bzpoZW5kcmlrLmJyb2Nr
aGF1c0BzaWVtZW5zLmNvbT4+IHdyb3RlOg0KPj4+DQo+Pj4+IFZvbjogU3Bhc20gPHNwYXNtLWJv
dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNwYXNtLWJvdW5jZXNAaWV0Zi5vcmc+PiBJbSBBdWZ0cmFn
IHZvbiBMaWp1biBMaWFvDQo+Pj4+IEdlc2VuZGV0OiBGcmVpdGFnLCAxMS4gRGV6ZW1iZXIgMjAy
MCAyMDoxMw0KPj4+Pg0KPj4+PiBJZiB0aGUgQ0EgdXNlcyB0aGUgZW52ZWxvcGVkRGF0YSBjaG9p
Y2UsIHRoZSBDTVAgY2xpZW50IHRoYXQgZG9lcyBub3QNCj4+IHN1cHBvcnQgdGhpcyBkcmFmdCwg
Y2Fubm90IHByb2Nlc3MgdGhlIHJlc3BvbnNlLiBTbyB0aGUgQ0EgbmVlZHMgYQ0KPj4gbWVjaGFu
aXNtIHRvIGRldGVybWluZSB3aGV0aGVyIHRoZSBDTVAgY2xpZW50IHN1cHBvcnRzID4gdGhpcyBk
cmFmdCBvcg0KPj4gbm90LiBZb3Ugc2hvdWxkIGluY3JlYXNlIHRoZSBDTVAgdmVyc2lvbiBvciBh
ZGQgc29tZSBvdGhlciBmaWVsZHMgaW4gdGhlDQo+PiBDTVAgcmVxdWVzdCB0byBwcm92aWRlIHRo
ZSBDQSBzdWNoIGluZm9ybWF0aW9uLg0KPj4+DQo+Pj4gT3VyIGdvYWwgd2FzIHRvIG1ha2Ugb25s
eSBtaW5pbWFsIGNoYW5nZXMgdG8gQ01QIHRvIGNpcmN1bXZlbnQNCj4+IGluY3JlYXNpbmcgdGhl
IENNUCB2ZXJzaW9uLg0KPj4NCj4+IFdoZW4gd2UgaGF2ZSBkb25lIHRoaW5ncyBsaWtlIHRoaXMg
aW4gQ01TLCB3ZSBzYXkgd2hlbiBlbmNyeXB0ZWRWYWx1ZSBpcw0KPj4gdXNlZCwgdGhlIHZlcnNp
b24gTVVTVCBiZSBYLCBhbmQgd2hlbiBlbnZlbG9wZWREYXRhIGlzIHVzZWQsIHRoZSB2ZXJzaW9u
DQo+PiBNVVNUIGJlIHgrMS4gIFRoaXMgYWxsb3dzIGFuIHVuc3VwcG9ydGVkIHZlcnNpb24gZXJy
b3IgaW5zdGVhZCBvZiBhIGJhZA0KPj4gZm9ybWF0Lg0KPj4NCj4NCj4gQ2FuIHdlIHN0aWNrIHRv
IHRoZSBjb25jZXB0IG9mIHVwZGF0aW5nIFJGQzQyMTAgd2hlbiBpbnRyb2R1Y2luZyBhIENNUCBW
MyB2ZXJzaW9uIGZvciB1c2FnZSBvZiBFbnZlbG9wZWREYXRhPw0KPiBPciBkb2VzIHRoZSBpbnRy
b2R1Y3Rpb24gb2YgYSBuZXcgdmVyc2lvbiBudW1iZXIgcmVxdWlyZXMgdG8gb2Jzb2xldGUgUkZD
NDIxMD8NCg0KSSBkbyBub3Qgc2VlIGEgcHJvYmxlbS4NCg0KUnVzcw0KDQoNCi0tDQpMaWp1biBM
aWFvDQo=

--_000_AM0PR10MB2418697CCCC55F0B2109217EFEC00AM0PR10MB2418EURP_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s
eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5n
dWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7
DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCAyLjBjbSA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlv
bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+
PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8
L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0
IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo
YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iREUiIGxp
bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V
UyI+SGkgTGlqdW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgY2FuIHNlZSB5b3VyIHBvaW50IGFuZCB0
ZW5kIHRvIHByZWZlciB0aGUgc3VnZ2VzdGlvbiBvZiBSdXNzLg0KPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28t
ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlcmVmb3JlIEkgaW52ZXN0aWdhdGUgd2hhdCBuZWVk
cyB0byBiZSB1cGRhdGVkIGluIENNUCBVcGRhdGVzIHRvIGludHJvZHVjZSBhIENNUCBWMyBvbmx5
IGluIGNhc2UgRW52ZWxvcGVkRGF0YSBpcyByZXF1aXJlZCBpbiBhIHRyYW5zYWN0aW9uIGFuZCBz
dXBwb3J0ZWQgYnkgdGhlIGNsaWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl
OkVOLVVTIj5DdXJyZW50bHkgSSB0aGluayBpbiBSRkM0MjEwLCBuZXh0IHRvIHNlY3Rpb24gNS4y
LjIsIHNlY3Rpb25zDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjEsIDUuMS4xLCA3LCBELjEs
IGFuZCBGIG5lZWQgdG8gYmUgdXBkYXRlcy4gTWF5IGJlIHNlY3Rpb25zIDUuMy40IGFuZCA1LjMu
MTkuOSB3b3VsZCBhbHNvIG5lZWQgYW4gZXhwbGFuYXRvcnkgbm90ZS48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RG8geW91IHNl
ZSBmdXJ0aGVyIHNlY3Rpb25zIHRoYXQgbmVlZCB1cGRhdGVzPzxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+
SGVuZHJpazwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1
YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw
YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPlZvbjo8
L2I+IExpanVuIExpYW8gJmx0O2xpanVuLmxpYW9AZ21haWwuY29tJmd0OyA8YnI+DQo8Yj5HZXNl
bmRldDo8L2I+IFNhbXN0YWcsIDE5LiBEZXplbWJlciAyMDIwIDIxOjIyPGJyPg0KPGI+QW46PC9i
PiBSdXNzIEhvdXNsZXkgJmx0O2hvdXNsZXlAdmlnaWxzZWMuY29tJmd0Ozxicj4NCjxiPkNjOjwv
Yj4gQnJvY2toYXVzLCBIZW5kcmlrIChUIFJEQSBDU1QgU0VBLURFKSAmbHQ7aGVuZHJpay5icm9j
a2hhdXNAc2llbWVucy5jb20mZ3Q7OyBzcGFzbUBpZXRmLm9yZzxicj4NCjxiPkJldHJlZmY6PC9i
PiBSZTogW2xhbXBzXSBNYWlsIHJlZ2FyZGluZyBkcmFmdC1pZXRmLWxhbXBzLWNtcC11cGRhdGVz
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldo
YXQgYWJvdXQgdGhlIGZvbGxvd2luZyBzdWdnZXN0aW9uczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gSW4gdGhlIFBLSUhlYWRlciBhZGQgYW4g
SW5mb1R5cGVBbmRWYWx1ZSB0byB0aGUgZ2VuZXJhbEluZm8gZmllbGQuIFRoaXMgbmV3IGVsZW1l
bnQgY29udGFpbnMgdGhlIHN1cHBvcnRlZCBDTVAgdmVyc2lvbnMgb2YgdGhlIHNlbmRpbmcgcGFy
dHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4y
LiBUaGUgQ01QIHZlcnNpb24gaXMgc2V0IHRvIDMsIGlmIHRoZSBQS0lNZXNzYWdlIGNvbnRhaW5z
IGZpZWxkcyBub3QgY29uZm9ybWluZyB0byBSRkM0MjEwLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIExpanVuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRGVjIDE1LCAyMDIw
IGF0IDU6MjEgUE0gUnVzcyBIb3VzbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86aG91c2xleUB2aWdp
bHNlYy5jb20iPmhvdXNsZXlAdmlnaWxzZWMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz
b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6
NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCiZndDsgT24gRGVjIDE1LCAyMDIwLCBhdCA0
OjE4IEFNLCBCcm9ja2hhdXMsIEhlbmRyaWsgJmx0OzxhIGhyZWY9Im1haWx0bzpoZW5kcmlrLmJy
b2NraGF1c0BzaWVtZW5zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmhlbmRyaWsuYnJvY2toYXVzQHNp
ZW1lbnMuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJ1c3M8YnI+DQom
Z3Q7IDxicj4NCiZndDsmZ3Q7IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS08YnI+
DQomZ3Q7Jmd0OyBWb246IFJ1c3MgSG91c2xleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhvdXNsZXlA
dmlnaWxzZWMuY29tIiB0YXJnZXQ9Il9ibGFuayI+aG91c2xleUB2aWdpbHNlYy5jb208L2E+Jmd0
Ozxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBPbiBEZWMgMTEsIDIwMjAsIGF0IDI6
NDggUE0sIEJyb2NraGF1cywgSGVuZHJpazxicj4NCiZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWls
dG86aGVuZHJpay5icm9ja2hhdXNAc2llbWVucy5jb20iIHRhcmdldD0iX2JsYW5rIj5oZW5kcmlr
LmJyb2NraGF1c0BzaWVtZW5zLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyA8
YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFZvbjogU3Bhc20gJmx0OzxhIGhyZWY9Im1haWx0bzpzcGFz
bS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3Bhc20tYm91bmNlc0BpZXRmLm9y
ZzwvYT4mZ3Q7IEltIEF1ZnRyYWcgdm9uIExpanVuIExpYW88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7
IEdlc2VuZGV0OiBGcmVpdGFnLCAxMS4gRGV6ZW1iZXIgMjAyMCAyMDoxMzxicj4NCiZndDsmZ3Q7
Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJZiB0aGUgQ0EgdXNlcyB0aGUgZW52ZWxv
cGVkRGF0YSBjaG9pY2UsIHRoZSBDTVAgY2xpZW50IHRoYXQgZG9lcyBub3Q8YnI+DQomZ3Q7Jmd0
OyBzdXBwb3J0IHRoaXMgZHJhZnQsIGNhbm5vdCBwcm9jZXNzIHRoZSByZXNwb25zZS4gU28gdGhl
IENBIG5lZWRzIGE8YnI+DQomZ3Q7Jmd0OyBtZWNoYW5pc20gdG8gZGV0ZXJtaW5lIHdoZXRoZXIg
dGhlIENNUCBjbGllbnQgc3VwcG9ydHMgJmd0OyB0aGlzIGRyYWZ0IG9yPGJyPg0KJmd0OyZndDsg
bm90LiBZb3Ugc2hvdWxkIGluY3JlYXNlIHRoZSBDTVAgdmVyc2lvbiBvciBhZGQgc29tZSBvdGhl
ciBmaWVsZHMgaW4gdGhlPGJyPg0KJmd0OyZndDsgQ01QIHJlcXVlc3QgdG8gcHJvdmlkZSB0aGUg
Q0Egc3VjaCBpbmZvcm1hdGlvbi48YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7
IE91ciBnb2FsIHdhcyB0byBtYWtlIG9ubHkgbWluaW1hbCBjaGFuZ2VzIHRvIENNUCB0byBjaXJj
dW12ZW50PGJyPg0KJmd0OyZndDsgaW5jcmVhc2luZyB0aGUgQ01QIHZlcnNpb24uPGJyPg0KJmd0
OyZndDsgPGJyPg0KJmd0OyZndDsgV2hlbiB3ZSBoYXZlIGRvbmUgdGhpbmdzIGxpa2UgdGhpcyBp
biBDTVMsIHdlIHNheSB3aGVuIGVuY3J5cHRlZFZhbHVlIGlzPGJyPg0KJmd0OyZndDsgdXNlZCwg
dGhlIHZlcnNpb24gTVVTVCBiZSBYLCBhbmQgd2hlbiBlbnZlbG9wZWREYXRhIGlzIHVzZWQsIHRo
ZSB2ZXJzaW9uPGJyPg0KJmd0OyZndDsgTVVTVCBiZSB4KzEuJm5ic3A7IFRoaXMgYWxsb3dzIGFu
IHVuc3VwcG9ydGVkIHZlcnNpb24gZXJyb3IgaW5zdGVhZCBvZiBhIGJhZDxicj4NCiZndDsmZ3Q7
IGZvcm1hdC48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQ2FuIHdlIHN0aWNr
IHRvIHRoZSBjb25jZXB0IG9mIHVwZGF0aW5nIFJGQzQyMTAgd2hlbiBpbnRyb2R1Y2luZyBhIENN
UCBWMyB2ZXJzaW9uIGZvciB1c2FnZSBvZiBFbnZlbG9wZWREYXRhPzxicj4NCiZndDsgT3IgZG9l
cyB0aGUgaW50cm9kdWN0aW9uIG9mIGEgbmV3IHZlcnNpb24gbnVtYmVyIHJlcXVpcmVzIHRvIG9i
c29sZXRlIFJGQzQyMTA/PGJyPg0KPGJyPg0KSSBkbyBub3Qgc2VlIGEgcHJvYmxlbS48YnI+DQo8
YnI+DQpSdXNzPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxicj4NCi0tIDxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxpanVuIExpYW88bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_AM0PR10MB2418697CCCC55F0B2109217EFEC00AM0PR10MB2418EURP_--


From nobody Mon Dec 21 06:59:57 2020
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 CA8F53A11B4 for ; Mon, 21 Dec 2020 06:59:55 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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=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 irJblOXPifCb for ; Mon, 21 Dec 2020 06:59:54 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150084.outbound.protection.outlook.com [40.107.15.84]) (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 CC27D3A11B0 for ; Mon, 21 Dec 2020 06:59:53 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TMrmlJeGZAzBoQxBtSkoKl+TtCoYVChXBl3m9/BT/qvRZBy4aO+MevOmx5xo57K3yH3GNKKOuDn/yVTGgzd0saSt4Z/MsRm7GpFwoWMN0MJyUaK5UEZlnnhuJdCn2ON7FRJP9AjjR/SxCbnBbKeIxm0+dVCoPX++zSgS4Cu2/TXgbn+QInsmp1K0JPdrQJOi1cH5Zk03A7tD4caAt/t5xA/FMdTnUK3iSDtw4Yjny9eYgug3c05cAKqo3sIcQdIZAWnmOUS4s506TKZMgifqrL8ZC46Yx8KrGprz51AZT1vgFvWGkPc9lAE/Sh20pWjafACDMDEU03jfbBcd/rGTkA==
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=oap0htNgji6i1nswlCCYxIiv/xuDrI5O8Y2GsobG3XY=; b=XyiwN7o2B8vnqYFN+2B7DHKX6fJivtCp46kxUHjd+okFIhcr+oUYT/8tsyuIci7ef7bxs23oNZnu+/+smP9OKZcbaCtXssRLZ+RcECHCTILqOBsgJinktR8oy+6gjJ4I8Sf1xJfoSCzg63xHI2LRo1MXhGUgtY6AJuKvbqaajfbB5/9ME7cYnm/Pk0yyqBe00rrwTd7T882x15D0btwd+x+4FRu0GUTSEedxf62cJkNnn1yLyW1c5wgmHPxMbO2pdheEPJHMmFNYpLx+zOcsGXRxn3i46h20f8eAYAOIN0AuJ1LNO+FbSIikwpBuvuxDtoX2G5107QcPThA+TDuvZA==
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=oap0htNgji6i1nswlCCYxIiv/xuDrI5O8Y2GsobG3XY=; b=X2xbHxz1TmeY3UxWVcYu1WUmvsl2KOOM8isEEYqqEcrYlTgWfZEcPStTGAxI8fGjjIs+tHtJ/0OEhw1HQvsMvjU0ibNJupeF0uCKPWal5qikefZ7J+Fhui/jc0fq9KZP94Gl9C+Nf+AJ8QAvlrh/ZW68b/EURt2HXr9IXz4oUEQ=
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM8PR10MB4178.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:1e8::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.25; Mon, 21 Dec 2020 14:59:48 +0000
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69%6]) with mapi id 15.20.3676.033; Mon, 21 Dec 2020 14:59:48 +0000
From: "Brockhaus, Hendrik" 
To: Russ Housley 
CC: LAMPS , "hans.aschauer@siemens.com" , Tomas Gustavsson 
Thread-Topic: [lamps] draft-ietf-lamps-crmf-update-algs-01
Thread-Index: AQHW1WhNtunZE/3TlkGJaO+jSG/XXqoBoPlg
Date: Mon, 21 Dec 2020 14:59:48 +0000
Message-ID: 
References: <160831458128.6318.14860273607218093486@ietfa.amsl.com> <2D45BEE7-538F-4893-B744-B7D491C01AFD@vigilsec.com>
In-Reply-To: <2D45BEE7-538F-4893-B744-B7D491C01AFD@vigilsec.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-12-21T14:59:47Z;  MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=ac9adb96-532e-406d-a94a-63fa13149a2f; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=siemens.com;
x-originating-ip: [165.225.200.160]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: c335d48e-c272-4b89-8209-08d8a5c10ff5
x-ms-traffictypediagnostic: AM8PR10MB4178:
x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: vwfqa5t3V1+9ihZ9tMabiTMUVG0mPrl+jzhpBypGrJNAPSS/8HoopqnjIN9Fy66sU67NdBKBrVfjIH+F6Ka0rXFChbtSQMn9UrqOFAMgc7o1z6HSc35Ddg2/cv2K0KqoP71ddo4B0xVFbeDg0zccF0/W7prI2RH3GGMSklIibg+UXnw/0DuhxVJCEip+746xqbrZNKi56mRrmG+73xbNbyJCXBuYSfEuCbG7w3H6MDl6E33JdCyyDuTsFfDgsVfr/aMc6aGza3/9IbuT/86w4iJhr2uU9LqG5d6SGb4TNbPZHXDfbHwCHLbXuotIapg9elH8wA4+5AxiyzpMWVH+Rnw5zIxdUYaVW8l2J9sSudsF4dAiN7X+OqOdPSEq57nUnQ5CHI5MsVsPoHQJQ3L9eo8jGTFv7eudWca1uBr+z6xBy4BHAeNUP/Nh2CAa6IRUxEMNtSnZVZq2bFvXA03GaA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(4636009)(346002)(396003)(136003)(39860400002)(366004)(376002)(26005)(6916009)(316002)(54906003)(4001150100001)(478600001)(966005)(83380400001)(52536014)(33656002)(15650500001)(45080400002)(55016002)(5660300002)(6506007)(64756008)(186003)(86362001)(66946007)(4326008)(7696005)(76116006)(66476007)(66446008)(55236004)(66574015)(9686003)(66556008)(8936002)(2906002)(53546011)(8676002)(71200400001); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?QSgOjdjNP0us6auL7TkYkNaqElpZGcFK8Xh5af9iOygLm2dbb9mVaMZyFJCE?= =?us-ascii?Q?YZSu3bDN4rEhzGE6H++3EhufXe/wOHXemqq4sfOkuTXRJ439IgQx1738SotM?= =?us-ascii?Q?8xiboN21Rs1Myi15NO04kpmX4nPRlvAr1meJknglL1VWgXmNi9ih5ADvx47y?= =?us-ascii?Q?yZIYXpbkEqyNNtZdRhyfZQsBlVTrlAnit5SgzrjEAhJ5SwWw/Sxc5bwkmRPb?= =?us-ascii?Q?DhsbpLwJ1pWZCFG3aG12jiR/9TQeQhlQboGNsHqq49lqGIIJRHHaI2w5giqU?= =?us-ascii?Q?2laoe46Xv1nIyPsxGiiSScaqWJsU7uOkMupMZbmEYABqgImKHY//iddjCw3F?= =?us-ascii?Q?tveDuTtc2Jl4v379+dFzN4bkygfDEryzJoQHlfjl3pvu9sE50jYihteyzPbL?= =?us-ascii?Q?hhTTbhAuaZcZXS8/l/m8qyj8zXN6N3n9oV7titiuzJsOC0Q9mxrXsJSEeL5R?= =?us-ascii?Q?g/++h5lVQzKUkIVSjcJpCKBlZnNdNjirJ7q1yV8m/bsNgfjee4HbPgBbev8/?= =?us-ascii?Q?zNoYmbDT1BDXL2gHrOqosJI+b/Nw/asztgVjpaFwlyyJKolL9fIu5Ss3JKDj?= =?us-ascii?Q?m61x2xc3zyBAcqqLeh/08sgOBE1BbvlG1P2w5I/oua+OipASypTi54dv1fgn?= =?us-ascii?Q?JwAVnBKrqts6Q/+kPrTflziDtsf0UDBtczq+YvRLPqdaPcgBoovSL1B53phQ?= =?us-ascii?Q?Qa/8OYXmkhj65Az0nFl210anhiWFv0dHb51i7TwwgWNj4VJbYkcMZg+GkFV0?= =?us-ascii?Q?bahjpQLaX071TYP1EkcTdWb6ehe3sebQAP5rMfdkLAWKKNxrJDL/wRedA2pk?= =?us-ascii?Q?zhDifsfJKr2QQcz8FEbz/Iqdf3aFGJ3YcUoz7x+wCFP5mgbonA+3DJFqFGKp?= =?us-ascii?Q?whsJXmhcuuuXQSE9HB8s0IL5Ov0DwZ7WN5bX8l5XruUzBQX+GsrebJymeVNO?= =?us-ascii?Q?HpXUSLPVv3aqQaQyXJfyAE2N/2vRQRirc0k08lJOmuA=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: siemens.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: c335d48e-c272-4b89-8209-08d8a5c10ff5
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2020 14:59:48.7324 (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: xtR482NbfIKdBpdpjVFYF0cv1sCmgnfjTvZIeJ1B54qp4k5FP4ZSBO6UYZt4o3xBUvWL0GfEmpQhjB+ruobcIIDHUUbawQ+tAcj9t83qznQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR10MB4178
Archived-At: 
Subject: Re: [lamps] draft-ietf-lamps-crmf-update-algs-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: Mon, 21 Dec 2020 14:59:56 -0000

Russ

Many thanks for the update. It addresses our concerns and suggestions.

To also address Tomas issues, you could add the following sentence to the s=
ection on iterationCount:
"A lower iterationCount can be used, if computer generated shared secrets w=
ith a high entropy are used."

We think, using a shared secret with high entropy, the iterationCount of 10=
0 can be absolutely sufficient.

- Hendrik and Hans

> Von: Spasm  Im Auftrag von Russ Housley
> Gesendet: Freitag, 18. Dezember 2020 19:04
>=20
> This revision addresses all of the outstanding comments.  I believe it is=
 ready
> for WG Last Call.
>=20
> Russ
>=20
> > On Dec 18, 2020, at 1:03 PM, internet-drafts@ietf.org wrote:
> >
> >
> > A new version of I-D, draft-ietf-lamps-crmf-update-algs-01.txt
> > has been successfully submitted by Russ Housley and posted to the IETF
> > repository.
> >
> > Name:		draft-ietf-lamps-crmf-update-algs
> > Revision:	01
> > Title:		Algorithm Requirements Update to the Internet X.509 Public
> Key Infrastructure Certificate Request Message Format (CRMF)
> > Document date:	2020-12-18
> > Group:		lamps
> > Pages:		8
> > URL:
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
> .ietf.org%2Farchive%2Fid%2Fdraft-ietf-lamps-crmf-update-algs-
> 01.txt&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd60b
> 8e72a1514c52a39408d8a37f660e%7C38ae3bcd95794fd4addab42e1495d55a%7
> C1%7C0%7C637439115015082517%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100
> 0&sdata=3D46KugpRBPoXItrBKtNc%2BNZeHWhZk3SmEKfIbuf4Twzw%3D&
> amp;reserved=3D0
> > Status:
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat
> racker.ietf.org%2Fdoc%2Fdraft-ietf-lamps-crmf-update-
> algs%2F&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd6
> 0b8e72a1514c52a39408d8a37f660e%7C38ae3bcd95794fd4addab42e1495d55a
> %7C1%7C0%7C637439115015092508%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1
> 000&sdata=3DZfmn0k5pB1H%2BW0EwldtfJPgzhR0eneN7KM8N%2Bq17zU
> U%3D&reserved=3D0
> > Htmlized:
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat
> racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lamps-crmf-update-
> algs&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd60b8e
> 72a1514c52a39408d8a37f660e%7C38ae3bcd95794fd4addab42e1495d55a%7C1
> %7C0%7C637439115015092508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> amp;sdata=3DFStfeGED7f3fl%2BEvYeVnalAtWU6cIWbdNHeOLoYpC2E%3D&am
> p;reserved=3D0
> > Htmlized:
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools=
.
> ietf.org%2Fhtml%2Fdraft-ietf-lamps-crmf-update-algs-
> 01&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd60b8e7
> 2a1514c52a39408d8a37f660e%7C38ae3bcd95794fd4addab42e1495d55a%7C1
> %7C0%7C637439115015092508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> amp;sdata=3D8arjo%2Bfmf5hayTxbD%2BWhJMEOEFR1jkQOlIPn5oIrfP8%3D&a
> mp;reserved=3D0
> > Diff:
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
> .ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-lamps-crmf-update-algs-
> 01&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd60b8e7
> 2a1514c52a39408d8a37f660e%7C38ae3bcd95794fd4addab42e1495d55a%7C1
> %7C0%7C637439115015092508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> amp;sdata=3DAt%2BLQYLUpfKWvTCqCM2uhj%2F2x90M8V%2B3ipHAlP7DShw
> %3D&reserved=3D0
> >
> > Abstract:
> >   This document updates the cryptographic algorithm requirements for
> >   the Password-Based Message Authentication Code in the Internet X.509
> >   Public Key Infrastructure Certificate Request Message Format (CRMF)
> >   specified in RFC 4211.
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D04%7C01%7Chendrik.
> brockhaus%40siemens.com%7Cd60b8e72a1514c52a39408d8a37f660e%7C38a
> e3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637439115015092508%7CU
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> 6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DEUn8W8MCpNFPSlQs79J
> Aq%2FMEvVUV%2BfKyw5WiNjoDa7c%3D&reserved=3D0


From nobody Mon Dec 21 07:46:54 2020
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 39A853A11D6 for ; Mon, 21 Dec 2020 07:46: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, 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 ib7bGWwzFl0k for ; Mon, 21 Dec 2020 07:46:50 -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 626A03A11D4 for ; Mon, 21 Dec 2020 07:46:50 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C0E8F300BBC for ; Mon, 21 Dec 2020 10:46:47 -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 h8iMtvMVzEgN for ; Mon, 21 Dec 2020 10:46:45 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id D0459300B0F; Mon, 21 Dec 2020 10:46:44 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Russ Housley 
In-Reply-To: 
Date: Mon, 21 Dec 2020 10:46:45 -0500
Cc: LAMPS , "hans.aschauer@siemens.com" , Tomas Gustavsson 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <160831458128.6318.14860273607218093486@ietfa.amsl.com> <2D45BEE7-538F-4893-B744-B7D491C01AFD@vigilsec.com> 
To: "Brockhaus, Hendrik" 
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] draft-ietf-lamps-crmf-update-algs-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: Mon, 21 Dec 2020 15:46:52 -0000

How about:

    A lower iteration count can be used, if automated
    generation produces shared secrets with high entropy.

Russ

> On Dec 21, 2020, at 9:59 AM, Brockhaus, Hendrik =
 wrote:
>=20
> Russ
>=20
> Many thanks for the update. It addresses our concerns and suggestions.
>=20
> To also address Tomas issues, you could add the following sentence to =
the section on iterationCount:
> "A lower iterationCount can be used, if computer generated shared =
secrets with a high entropy are used."
>=20
> We think, using a shared secret with high entropy, the iterationCount =
of 100 can be absolutely sufficient.
>=20
> - Hendrik and Hans
>=20
>> Von: Spasm  Im Auftrag von Russ Housley
>> Gesendet: Freitag, 18. Dezember 2020 19:04
>>=20
>> This revision addresses all of the outstanding comments.  I believe =
it is ready
>> for WG Last Call.
>>=20
>> Russ
>>=20
>>> On Dec 18, 2020, at 1:03 PM, internet-drafts@ietf.org wrote:
>>>=20
>>>=20
>>> A new version of I-D, draft-ietf-lamps-crmf-update-algs-01.txt
>>> has been successfully submitted by Russ Housley and posted to the =
IETF
>>> repository.
>>>=20
>>> Name:		draft-ietf-lamps-crmf-update-algs
>>> Revision:	01
>>> Title:		Algorithm Requirements Update to the Internet =
X.509 Public
>> Key Infrastructure Certificate Request Message Format (CRMF)
>>> Document date:	2020-12-18
>>> Group:		lamps
>>> Pages:		8
>>> URL:
>> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww=

>> .ietf.org%2Farchive%2Fid%2Fdraft-ietf-lamps-crmf-update-algs-
>> 01.txt&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd60b
>> 8e72a1514c52a39408d8a37f660e%7C38ae3bcd95794fd4addab42e1495d55a%7
>> C1%7C0%7C637439115015082517%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
>> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100
>> 0&sdata=3D46KugpRBPoXItrBKtNc%2BNZeHWhZk3SmEKfIbuf4Twzw%3D&
>> amp;reserved=3D0
>>> Status:
>> =
https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat
>> racker.ietf.org%2Fdoc%2Fdraft-ietf-lamps-crmf-update-
>> algs%2F&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd6
>> 0b8e72a1514c52a39408d8a37f660e%7C38ae3bcd95794fd4addab42e1495d55a
>> %7C1%7C0%7C637439115015092508%7CUnknown%7CTWFpbGZsb3d8eyJWIj
>> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1
>> 000&sdata=3DZfmn0k5pB1H%2BW0EwldtfJPgzhR0eneN7KM8N%2Bq17zU
>> U%3D&reserved=3D0
>>> Htmlized:
>> =
https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat
>> racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lamps-crmf-update-
>> algs&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd60b8e
>> 72a1514c52a39408d8a37f660e%7C38ae3bcd95794fd4addab42e1495d55a%7C1
>> %7C0%7C637439115015092508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
>> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
>> amp;sdata=3DFStfeGED7f3fl%2BEvYeVnalAtWU6cIWbdNHeOLoYpC2E%3D&am
>> p;reserved=3D0
>>> Htmlized:
>> =
https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.=

>> ietf.org%2Fhtml%2Fdraft-ietf-lamps-crmf-update-algs-
>> 01&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd60b8e7
>> 2a1514c52a39408d8a37f660e%7C38ae3bcd95794fd4addab42e1495d55a%7C1
>> %7C0%7C637439115015092508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
>> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
>> amp;sdata=3D8arjo%2Bfmf5hayTxbD%2BWhJMEOEFR1jkQOlIPn5oIrfP8%3D&a
>> mp;reserved=3D0
>>> Diff:
>> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww=

>> .ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-lamps-crmf-update-algs-
>> 01&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd60b8e7
>> 2a1514c52a39408d8a37f660e%7C38ae3bcd95794fd4addab42e1495d55a%7C1
>> %7C0%7C637439115015092508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
>> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
>> amp;sdata=3DAt%2BLQYLUpfKWvTCqCM2uhj%2F2x90M8V%2B3ipHAlP7DShw
>> %3D&reserved=3D0
>>>=20
>>> Abstract:
>>>  This document updates the cryptographic algorithm requirements for
>>>  the Password-Based Message Authentication Code in the Internet =
X.509
>>>  Public Key Infrastructure Certificate Request Message Format (CRMF)
>>>  specified in RFC 4211.
>>=20
>> _______________________________________________
>> Spasm mailing list
>> Spasm@ietf.org
>> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww=

>> .ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D04%7C01%7Chendrik.
>> brockhaus%40siemens.com%7Cd60b8e72a1514c52a39408d8a37f660e%7C38a
>> e3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637439115015092508%7CU
>> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
>> 6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DEUn8W8MCpNFPSlQs79J
>> Aq%2FMEvVUV%2BfKyw5WiNjoDa7c%3D&reserved=3D0
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


From nobody Mon Dec 21 07:53:51 2020
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 9FFD83A11CF; Mon, 21 Dec 2020 07:53:48 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: spasm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: spasm@ietf.org
Message-ID: <160856602856.10027.8841274051228614037@ietfa.amsl.com>
Date: Mon, 21 Dec 2020 07:53:48 -0800
Archived-At: 
Subject: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-02.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2020 15:53:49 -0000

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

        Title           : Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)
        Author          : Russ Housley
	Filename        : draft-ietf-lamps-crmf-update-algs-02.txt
	Pages           : 8
	Date            : 2020-12-21

Abstract:
   This document updates the cryptographic algorithm requirements for
   the Password-Based Message Authentication Code in the Internet X.509
   Public Key Infrastructure Certificate Request Message Format (CRMF)
   specified in RFC 4211.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lamps-crmf-update-algs/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lamps-crmf-update-algs-02
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-crmf-update-algs-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-crmf-update-algs-02


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

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



From nobody Mon Dec 21 07:55:17 2020
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 0D3FC3A11DA for ; Mon, 21 Dec 2020 07:55:16 -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, 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 JhdCaYeKXAQ3 for ; Mon, 21 Dec 2020 07:55:14 -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 592A23A104E for ; Mon, 21 Dec 2020 07:55:14 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CFE20300BBC for ; Mon, 21 Dec 2020 10:55:11 -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 aXsFwomZLV0Z for ; Mon, 21 Dec 2020 10:55:10 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 85D29300B0F for ; Mon, 21 Dec 2020 10:55:10 -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.17\))
Date: Mon, 21 Dec 2020 10:55:11 -0500
References: <160856602856.10027.8841274051228614037@ietfa.amsl.com>
To: LAMPS 
In-Reply-To: <160856602856.10027.8841274051228614037@ietfa.amsl.com>
Message-Id: <8B2D49FE-C082-4F62-BDEE-AA1028BEE0E0@vigilsec.com>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-02.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2020 15:55:16 -0000

This addresses the request for a sentence about high-entropy shared =
secrets.  I believe all of the open isses have been resolved.

Russ


> On Dec 21, 2020, at 10:53 AM, internet-drafts@ietf.org wrote:
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Limited Additional Mechanisms for =
PKIX and SMIME WG of the IETF.
>=20
>        Title           : Algorithm Requirements Update to the Internet =
X.509 Public Key Infrastructure Certificate Request Message Format =
(CRMF)
>        Author          : Russ Housley
> 	Filename        : draft-ietf-lamps-crmf-update-algs-02.txt
> 	Pages           : 8
> 	Date            : 2020-12-21
>=20
> Abstract:
>   This document updates the cryptographic algorithm requirements for
>   the Password-Based Message Authentication Code in the Internet X.509
>   Public Key Infrastructure Certificate Request Message Format (CRMF)
>   specified in RFC 4211.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lamps-crmf-update-algs/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lamps-crmf-update-algs-02
> =
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-crmf-update-algs-02=

>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-crmf-update-algs-02=

>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


From nobody Mon Dec 21 09:43:47 2020
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 3DEC13A1314 for ; Mon, 21 Dec 2020 09:43:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYq7VCFF1PEq for ; Mon, 21 Dec 2020 09:43:44 -0800 (PST)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 6E7D53A130E for ; Mon, 21 Dec 2020 09:43:44 -0800 (PST)
Received: by mail-io1-xd30.google.com with SMTP id o6so9541453iob.10 for ; Mon, 21 Dec 2020 09:43:44 -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=FVKvZPIRfTGAPrTQjRl9lWH2BQEj4ERQhsPY/qwu0bo=; b=SvjOfzV8oynzAz1U7vNtwF0L2By6Dbq2EI4E0qz903OYowaJsWTsIzNdygywAMwwCz nfxhQHRHdAYawMfBbjsi/pfPJF8UElBdwCYF7UpnuO5F0iPdQlu5f4RNMajvqNMJq/Cz dAxkWtGBYBKGsg/mSNuV1k35VssbWkD5DOJFSkCZpHIY1wfItwlplge2Rr1EZ5FflFJn VM5jY3w49Vqx+uM3XHZUdr1zNNJ6oIEDb6771Z5jjGyUN3ZkmqPi9kZnRyFgwNJ8t7ew YVD4keSFl0q9ikavVQARB6VQCNEYIJghRlIOMR6BlMvgv1zu74MeBs+9Yyy/CBlsDI5w NN0g==
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=FVKvZPIRfTGAPrTQjRl9lWH2BQEj4ERQhsPY/qwu0bo=; b=VOuXC+uI9JEDMOvKBLjdC+B26ef/h/svBmVf1aG9lgPsgbq3TZIovtjGjQMpD288AG IgW5bMklpOTjCY5+TatSdD9dB0jln/bep2ghyLVhI9Y/Ytb5O7YqB6G3zeFWTmRNy6MX x7gIr/Y5tVVrfhP7C2LkSy4/G6npqWIbTtx0ahVjNAwOg9kK9gxi/PNMZX/6ZgZ8jPvJ j4jPl3NJpjhonIUbsoq+VGDw4sjpUWSmoJs3gZ7w9z73jo2+Q/ehO3EbVsKLBAJoCjd7 4jpBRbWpAl34F5aK7umMPv1DomHpt44A/tTg1tcldtnBaJXaK+FwA/Kv/1hg0parXr3U v5kg==
X-Gm-Message-State: AOAM530ME3g09CmnbncuPr//H+aXXM6vWYh5U0SmbA1EVEBpLbxW+spm P2qeEyIDKe7WPcj/WX7+2oZeL+ALBMFsSg6wNolZmU64uE2XSg==
X-Google-Smtp-Source: ABdhPJx5uKW/FlVPs1m+da0gTly9k67WP1wR0vshFCEiqd3zFl+O7gPKqWut3p4vgTCopRAS844k+HMAVOIvhiuxNl8=
X-Received: by 2002:a6b:441a:: with SMTP id r26mr14654508ioa.105.1608572623533;  Mon, 21 Dec 2020 09:43:43 -0800 (PST)
MIME-Version: 1.0
References: <20201218103651.M76302@bts.sk>    <7E92C4FB-4118-470A-8BA4-BEA133FA46AF@akamai.com> <20201218224153.M14899@bts.sk>  <20201218230753.M63543@bts.sk>  <20201219085409.M21922@bts.sk>  <20201219121104.M37970@bts.sk>  <20201221155837.M1893@bts.sk>
In-Reply-To: <20201221155837.M1893@bts.sk>
From: Mohit Sahni 
Date: Mon, 21 Dec 2020 09:43:33 -0800
Message-ID: 
To: =?UTF-8?B?TWFyaWFuIMSOdXJrb3ZpxI0=?= 
Cc: "Salz, Rich" , Russ Housley , LAMPS 
Content-Type: multipart/alternative; boundary="000000000000d23d1905b6fcffec"
Archived-At: 
Subject: Re: [lamps] Fwd: Conflict between RFC8954 and ISO 14533-4
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, 21 Dec 2020 17:43:46 -0000

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

HI Marian
I have shared my point of view on this and I will let others weigh in.

One correction to your last comment
>And what will be the advantage of having yet another extension doing the
same thing? Both use cases require nothing else from OCSP responder than to
echo back exactly the same bytes it received in request. Do you propose to
have 2 extensions, one of them being able to only echo 32 bytes and another
being able to echo 96? or 160? or unlimited bytes? Isn't it much more
straightforward to have only one "echoing" extension being able to echo as
many bytes as needed for both use cases?

OCSP Responder is not required to echo the Nonce extension value even if it
supports the extension and it can send a Nonce back to client even if it
did not receive one in the OCSP request (Section 4 RFC5019). So if ISO
14533-4 requires the MessageImprint in the OCSP response for the long term
validation, then it is already broken there. The new extension can make
sure if Responder supports it then MUST echo back.

-Mohit

On Mon, Dec 21, 2020 at 8:36 AM Marian =C4=8Eurkovi=C4=8D  wrote=
:

> *On Sat, 19 Dec 2020 13:12:17 -0800, Mohit Sahni wrote*
> > From OCSP point of view the MessageImprint is not a random value but it
> is a deterministic value generated for a given input by a collision
> resistant one way hash function.
>
> This input, however, consists of multiple parts: some of them being
> random, some of them being unknown even to document signer (private key).
> In any case, an attacker is not able to guess this value so it serves
> against reply attack very well.
>
> > One more reason I see for not changing the Nonce extension length is
> that the length of MessageImprint is not fixed but varies based on the
> underlying hash algorithm.  Since RFC3161 does not provide a fixed list o=
f
> Hash functions, let's say we change the size to Nonce extension to 64
> bytes, what if in the future there is a new hash algorithm or some
> proprietary hash function that requires size to be 128 bytes or 256 bytes
> or may be 100 GigaBytes, are we going to increase the size of the Nonce
> extension again?  How can we set an upper limit on Nonce which also serve=
s
> the regular Nonce use case of just avoiding the replay attacks ?
>
> I proposed 2 values: 96 bytes if we want to accomodate 512-bit hashes, or
> 160 bytes, if we want to accomodate (future) 1024-bit hashes. Any hashing
> algorithm is designed to yield a relatively small result, so we're
> certainly not talking about GigaBytes here...
>
> > In my opinion, ISO 14533 took advantage of the security vulnerability
> that existed in RFC6960 and tried using Nonce extension in a way it was n=
ot
> intended to be used as i.e. using an ASN.1 SEQUENCE where the standard
> requires use of OCTET STRING.
>
> OCTET STRING means arbitrary sequence of bytes, which OCSP responder
> shouldn't interpret in any way - just echo them back in its response. It'=
s
> completely irrelevant, what's encoded inside - after all, a random number
> could also start with 0x30 which corresponds to SEQUENCE.
>
> > We should come up with a new extension for associating the OCSP respons=
e
> with the context where OCSP is being used for long term validation. That =
is
> the right thing to do.
>
> And what will be the advantage of having yet another extension doing the
> same thing? Both use cases require nothing else from OCSP responder than =
to
> echo back exactly the same bytes it received in request. Do you propose t=
o
> have 2 extensions, one of them being able to only echo 32 bytes and anoth=
er
> being able to echo 96? or 160? or unlimited bytes? Isn't it much more
> straightforward to have only one "echoing" extension being able to echo a=
s
> many bytes as needed for both use cases?
>
> On the other hand, the disadvantages are significant - I mentioned some o=
f
> them in my previous email. Also please keep in mind, that RFC 8954 (if
> applied by OCSP responder or by some firewall doing deep packet inspectio=
n)
> will immediately break digital signing - since it says:
>
>    A server *MUST* reject any OCSP request that has a nonce in the Nonce
>    extension with a length of either 0 octets or more than 32 octets
>    with the malformedRequest OCSPResponseStatus
>
> Last but not least, introducing another extension is more complex than yo=
u
> assume - it will require modification of (at least) RFC6960, RFC5019, ISO
> 14533-4. When will that solution be available and what to do until then?
>
> With kind regards,
> MD
>
>
>
>

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


HI Marian
I have=C2=A0shared my point of view on this =
and I will let others weigh in.=C2=A0

One correcti=
on to your last comment=C2=A0
>And what will be the advantage =
of having yet another extension doing the same thing? Both use cases requir=
e nothing else from OCSP responder than to echo back exactly the same bytes=
 it received in request. Do you propose to have 2 extensions, one of them b=
eing able to only echo 32 bytes and another being able to echo 96? or 160? =
or unlimited bytes? Isn't it much more straightforward to have only one=
 "echoing" extension being able to echo as many bytes as needed f=
or both use cases?

OCSP Responder is not required to ec=
ho the Nonce extension value even if it supports the=C2=A0extension and it =
can send a Nonce back to client=C2=A0even if it did not receive one in the =
OCSP request (Section 4 RFC5019). So if ISO 14533-4 requires the MessageImp=
rint=C2=A0in the OCSP response for the long term validation, then it is alr=
eady broken there. The new extension can make sure if Responder supports it=
 then MUST echo back.

-Mohit=C2=A0

On Mon, Dec 21, =
2020 at 8:36 AM Marian =C4=8Eurkovi=C4=8D <=
md@bts.sk> wrote:








On Sat, 19 Dec 2020 13:12:17 -0800, Mohit Sahni wrote



> From OCSP point of view the=C2=A0MessageImprint =
is not a random value=20
but it is a deterministic value generated for a given input by a collision=
=20
resistant one way hash function.=20









This input, however, consists of multiple parts: some=
 of them being random, some of them being unknown even to document signer (=
private key). In any case, an attacker is not able to guess this value so i=
t serves against reply attack very well.









> One more reason I see for not changing the=20
Nonce extension length is that the length of=C2=A0MessageImprint is not fix=
ed but=20
varies based on the underlying hash algorithm.=C2=A0 Since RFC3161 does not=
 provide=20
a fixed list of Hash functions, let's say we change the size to Nonce=
=20
extension to 64 bytes, what if in the future there is a new hash algorithm =
or=20
some proprietary hash function that requires size to be 128 bytes or 256 by=
tes=20
or may be 100 GigaBytes, are we going to increase the size of the Nonce=20
extension again?=C2=A0 How can we set an upper limit on Nonce which also se=
rves the=20
regular Nonce use case of just avoiding the replay attacks ?








I proposed 2 values: 96 bytes if we want to accomodat=
e 512-bit hashes, or 160 bytes, if we want to accomodate (future) 1024-bit =
hashes. Any hashing algorithm is designed to yield a relatively small resul=
t, so we're certainly not talking about GigaBytes here...









>=20
In my opinion, ISO 14533 took advantage of the security vulnerability that=
=20
existed in RFC6960 and tried using Nonce extension in a way it was not inte=
nded=20
to be used as i.e. using an ASN.1 SEQUENCE where the standard requires=C2=
=A0use of=20
OCTET=C2=A0STRING.=20









OCTET STRING means arbitrary sequence of bytes, which=
 OCSP responder shouldn't interpret in any way - just echo them back in=
 its response. It's completely irrelevant, what's encoded inside - =
after all, a random number could also start with 0x30 which corresponds to =
SEQUENCE.=20









> We should come up with a new extension for assoc=
iating the OCSP=20
response with the context where OCSP is being used for long term validation=
.=20
That is the right thing to do.=20









And what will be the advantage of having yet another =
extension doing the same thing? Both use cases require nothing else from OC=
SP responder than to echo back exactly the same bytes it received in reques=
t. Do you propose to have 2 extensions, one of them being able to only echo=
 32 bytes and another being able to echo 96? or 160? or unlimited bytes? Is=
n't it much more straightforward to have only one "echoing" e=
xtension being able to echo as many bytes as needed for both use cases?








On the other hand, the disadvantages are significant =
- I mentioned some of them in my previous email. Also please keep in mind, =
that RFC 8954 (if applied by OCSP responder or by some firewall doing deep =
packet inspection) will immediately break digital signing - since it says:<=
/font>



   A server *MUST* reject any OCSP request that has a nonce in the Non=
ce
   extension with a length of either 0 octets or more than 32 octets
   with the malformedRequest OCSPResponseStatus



Last but not least, introducing another extension is =
more complex than you assume - it will require modification of (at least) R=
FC6960, RFC5019, ISO 14533-4. When will that solution be available and what=
 to do until then?








With kind regards,



MD


























--000000000000d23d1905b6fcffec--


From nobody Tue Dec 22 00:09:33 2020
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 399063A0E61 for ; Tue, 22 Dec 2020 00:09: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-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=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 HtcKQt6HlrBY for ; Tue, 22 Dec 2020 00:09:29 -0800 (PST)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2059.outbound.protection.outlook.com [40.107.21.59]) (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 D248B3A0C04 for ; Tue, 22 Dec 2020 00:09:28 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MgJ4R3tp0V+L4W1CDxHE8/0bsU0648ZrLjK7zNdmZWIsxj9DSIyQ2td4eGu3KI21ly6j7nhfCh9tz5tKKuZ+TmkQpbzOPjeREoE5yp7PUt5/nVm1hUPo9nteBogHU0r+8FgZDlg1o/QJmB+TAKWJvcmpK7D12U/MkMZET4Yt3/l/pZ4Ft8x09ivQpIXmiIIb3NIMDnOEgaGu1DutiMgyYEoGz3APsQ0BnTPIVKZkpJhIjUwHTH74p5PJQgW7z+aB1Ou4wdij9+PwBNiYsK4LlJVgbUfOlhSOzrUoQLcJifbWAWqTSMuQp3UelZPsX8l0KAVbfHvieGgk2JDpwZM/cw==
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=HXNEWg+ZA7VM+4CWVN7UFMMeVHRa0W1fpUZdoexC8e4=; b=cfa/GyoxzUzkzO12wsQ+ZyMBlwOjVwCY4yilsGk0Jo1Ce/PKoNhTEBFRhtN2bj2Phb6Aj6OLARGIYNru6Qy5d4W8MIwPPp/3b45s1bb8ch4QgOoreILIh7aSns0TAskWitOYXBa8Ys2i/4QQfuO4tkYJ6fY3bQNA3/+oGIJ1ABElsIb/sSiypsa/N3JR2D5jeS9jmUBtyvVVG3SY9BqUGok44jK9a0XBlrGxLyw6mEA/slZIw0eZOssJ7VHkDk+oyEedlI1iM7OjdoY9q+gYB+c2Fec+UN3N8wLKuSTt2xGGV7AQNoEFIR7f7nDJTsnmg/4bwdszBGd+6LLmVANi3g==
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=HXNEWg+ZA7VM+4CWVN7UFMMeVHRa0W1fpUZdoexC8e4=; b=MLwy/fCYpiylT57VYmSrPRAdX2Kv7QhPaa3qVQG5xsp1mIBwnSDjZlZwi+JIaoch7h52Mw5SD3VlvvXrtkjn1iTHCqbkTQs5uEZJ84yIyowHqIldMAmyBIVzC+/Uh1PUKbEAC5PNXOt3DzfXKu/Bza0984pZLUhD1dnDPr6PwYk=
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM0PR10MB2882.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:157::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.25; Tue, 22 Dec 2020 08:09:26 +0000
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::a5a7:8af9:1e22:1d69%6]) with mapi id 15.20.3676.033; Tue, 22 Dec 2020 08:09:25 +0000
From: "Brockhaus, Hendrik" 
To: Russ Housley 
CC: LAMPS , "hans.aschauer@siemens.com" , Tomas Gustavsson 
Thread-Topic: [lamps] draft-ietf-lamps-crmf-update-algs-01
Thread-Index: AQHW1WhNtunZE/3TlkGJaO+jSG/XXqoBoPlggAAVLoCAARJZkA==
Date: Tue, 22 Dec 2020 08:09:25 +0000
Message-ID: 
References: <160831458128.6318.14860273607218093486@ietfa.amsl.com> <2D45BEE7-538F-4893-B744-B7D491C01AFD@vigilsec.com>  
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-12-22T08:09:24Z;  MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=11b91864-9fbf-4318-9b63-c06e762b2cb7; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=siemens.com;
x-originating-ip: [165.225.200.160]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 65cf4581-4c57-42e4-8e51-08d8a650e607
x-ms-traffictypediagnostic: AM0PR10MB2882:
x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: EHsfwTABfvzyCuFllDptj15VYqg2blxwqHeO7JyleGzoUJ72h+G4i/1MhkL7QGAeZnEFQlqYwlQWLN613WvxHreO1SydtVnQo18Syuivo59Pif8HPI/JvG4tRFENyzZEC30hR1g8+vsday4t2qzoaYGbriuI3T8BWCJ8PLXus/9ky/3bM0ghlR4eZ6J55wyS/Uwr/PI+3E36FTpQGNYFakIrDcd+flDBIMC5Ip/gdFKYtyIdn0F8mqRa3CGDarzw524oqukkm5bOu5GW9pG6jl5YkxsxB5N/hTbV8zTrUoQetTusYCi+OlECpmGTczgditKM8uit3auK6ujQfF9NQwu42MDE1nNhdVWTe9mRzQc014v4d9SKnVjKPqrd0LHDg1OEydWXWDXnVrdb3G0EohO2EtEPAfpaFDbQv/8YAwKBKJL2F9WIudBlVlk/eOU2UFEBrU6y0WibArnIECBQBA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(4636009)(136003)(366004)(39860400002)(346002)(376002)(396003)(316002)(9686003)(8676002)(54906003)(966005)(55016002)(53546011)(86362001)(45080400002)(6506007)(33656002)(7696005)(2906002)(4001150100001)(478600001)(83380400001)(55236004)(66476007)(186003)(76116006)(66946007)(5660300002)(26005)(66446008)(64756008)(66556008)(8936002)(15650500001)(66574015)(4326008)(52536014)(6916009)(71200400001); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?NsxnzHurZIf8141vDDRw9QDFRW+5iqCZUf5q22cA7K3k1vGv/og68irHYG5f?= =?us-ascii?Q?oUXhPELmqsvn7XYa6YRxIW/ZC1RCZF9Y8n4EyZihgqy+OufB1b5L1d18C6Jg?= =?us-ascii?Q?SelCiDYAU7RUipa7triBbKyR+I85sHT0BzbXIZ0p1253Xp4uyNsPkTbQtWPU?= =?us-ascii?Q?xXiPEig3LpfOKbrIrgXT0v30qlFHh5cxt0U1aSbKLjxE002YQDrit3ckLkEH?= =?us-ascii?Q?EibWe/+La6/U/1Kj7B9ZMlLodx0kv6qsOPOO8AFWAKhThoy6/IB48HbV93eh?= =?us-ascii?Q?i/efoJku0gWR0vTlq7JYvlyRw1r4O0tbn36vGRtArpENKPKo6PFG7dyGTGyT?= =?us-ascii?Q?tvYdqPrrBzdQATGsrvE8F7vETeS5u3qkR9TXsuJ0VflELUSVA6a7wpw3lbL0?= =?us-ascii?Q?xtvUeo+d4ZET5UQ0QmCs+X1KGq/zOeFRfCOEgMGVnSURbR9At5XosQMjLi5Z?= =?us-ascii?Q?493WZLRQuIEo5b+W2HfYwegxvkSSDCvYY3AscuA/AaGBQRJNmPWGiWAVPPvC?= =?us-ascii?Q?6GHRisGxiyV2appUldEDOGMv+SiokUksQrmCNL5uo6bprOPB0Eetc2WnmLIW?= =?us-ascii?Q?YgBJpuppgosc/It7sekuird7mtzsRthPKkb6iWSTtCiUgGjgJzOs6v3tvUx1?= =?us-ascii?Q?WbUZUMKu7rMQD3ySOcw+MJi+7agNYn2A7sM6HglKEbZ/diTSbbabS0dbYab4?= =?us-ascii?Q?7QYbWGFDWGpSiuf6Cw4KuYicU4YeoV2sypzyP5XYO4ZA/6fNTbiIQdBkpW/U?= =?us-ascii?Q?/mSreU4clFrjt288qk22iTiyABFhFWu7S7/JkuJ+avJorY+FZPFvp2c8DVHN?= =?us-ascii?Q?YL8LGY//qL2C+kOrhP7XBh4yapBPt/fKrOhDcQmiCaLy3L/5GF5lbqKWQGbZ?= =?us-ascii?Q?t1CniPW5BRBqqr5KZ+PWLOxrBmTDGgbR06Z1XxhNIaYZaxRjWnTNpV0Iog6N?= =?us-ascii?Q?rvNniqW4H/eTkkI8RDy/O8aPkzGLTD5qpLYF/KzM7lM=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: siemens.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 65cf4581-4c57-42e4-8e51-08d8a650e607
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2020 08:09:25.8475 (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: Xjl3TRiUVYD5yhP/5s+tliKm83c7NsWTj2wR6BYRyxIMIaF10fUMoYF+fPjDAF6YkGPjoQet3XohI74U8bMH+6kqEo5sqlZAzXTCge8tdF0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2882
Archived-At: 
Subject: Re: [lamps] draft-ietf-lamps-crmf-update-algs-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, 22 Dec 2020 08:09:31 -0000

Thanks Russ, I like the wording.

Hendrik

> Von: Russ Housley 
> Gesendet: Montag, 21. Dezember 2020 16:47
>=20
> How about:
>=20
>     A lower iteration count can be used, if automated
>     generation produces shared secrets with high entropy.
>=20
> Russ
>=20
> > On Dec 21, 2020, at 9:59 AM, Brockhaus, Hendrik
>  wrote:
> >
> > Russ
> >
> > Many thanks for the update. It addresses our concerns and suggestions.
> >
> > To also address Tomas issues, you could add the following sentence to t=
he
> section on iterationCount:
> > "A lower iterationCount can be used, if computer generated shared secre=
ts
> with a high entropy are used."
> >
> > We think, using a shared secret with high entropy, the iterationCount o=
f
> 100 can be absolutely sufficient.
> >
> > - Hendrik and Hans
> >
> >> Von: Spasm  Im Auftrag von Russ Housley
> >> Gesendet: Freitag, 18. Dezember 2020 19:04
> >>
> >> This revision addresses all of the outstanding comments.  I believe
> >> it is ready for WG Last Call.
> >>
> >> Russ
> >>
> >>> On Dec 18, 2020, at 1:03 PM, internet-drafts@ietf.org wrote:
> >>>
> >>>
> >>> A new version of I-D, draft-ietf-lamps-crmf-update-algs-01.txt
> >>> has been successfully submitted by Russ Housley and posted to the
> >>> IETF repository.
> >>>
> >>> Name:		draft-ietf-lamps-crmf-update-algs
> >>> Revision:	01
> >>> Title:		Algorithm Requirements Update to the Internet X.509
> Public
> >> Key Infrastructure Certificate Request Message Format (CRMF)
> >>> Document date:	2020-12-18
> >>> Group:		lamps
> >>> Pages:		8
> >>> URL:
> >>
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
> >> .ietf.org%2Farchive%2Fid%2Fdraft-ietf-lamps-crmf-update-algs-
> >>
> 01.txt&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd60b
> >>
> 8e72a1514c52a39408d8a37f660e%7C38ae3bcd95794fd4addab42e1495d55a%7
> >>
> C1%7C0%7C637439115015082517%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> >>
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100
> >>
> 0&sdata=3D46KugpRBPoXItrBKtNc%2BNZeHWhZk3SmEKfIbuf4Twzw%3D&
> >> amp;reserved=3D0
> >>> Status:
> >>
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdat
> >> at
> >> racker.ietf.org%2Fdoc%2Fdraft-ietf-lamps-crmf-update-
> >>
> algs%2F&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd6
> >>
> 0b8e72a1514c52a39408d8a37f660e%7C38ae3bcd95794fd4addab42e1495d55a
> >>
> %7C1%7C0%7C637439115015092508%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> >>
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1
> >>
> 000&sdata=3DZfmn0k5pB1H%2BW0EwldtfJPgzhR0eneN7KM8N%2Bq17zU
> >> U%3D&reserved=3D0
> >>> Htmlized:
> >>
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdat
> >> at
> >> racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lamps-crmf-update-
> >>
> algs&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd60b8e
> >>
> 72a1514c52a39408d8a37f660e%7C38ae3bcd95794fd4addab42e1495d55a%7C1
> >>
> %7C0%7C637439115015092508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> >>
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> >>
> amp;sdata=3DFStfeGED7f3fl%2BEvYeVnalAtWU6cIWbdNHeOLoYpC2E%3D&am
> >> p;reserved=3D0
> >>> Htmlized:
> >>
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools=
.
> >> ietf.org%2Fhtml%2Fdraft-ietf-lamps-crmf-update-algs-
> >>
> 01&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd60b8e7
> >>
> 2a1514c52a39408d8a37f660e%7C38ae3bcd95794fd4addab42e1495d55a%7C1
> >>
> %7C0%7C637439115015092508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> >>
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> >>
> amp;sdata=3D8arjo%2Bfmf5hayTxbD%2BWhJMEOEFR1jkQOlIPn5oIrfP8%3D&a
> >> mp;reserved=3D0
> >>> Diff:
> >>
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
> >> .ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-lamps-crmf-update-algs-
> >>
> 01&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd60b8e7
> >>
> 2a1514c52a39408d8a37f660e%7C38ae3bcd95794fd4addab42e1495d55a%7C1
> >>
> %7C0%7C637439115015092508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> >>
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> >>
> amp;sdata=3DAt%2BLQYLUpfKWvTCqCM2uhj%2F2x90M8V%2B3ipHAlP7DShw
> >> %3D&reserved=3D0
> >>>
> >>> Abstract:
> >>>  This document updates the cryptographic algorithm requirements for
> >>> the Password-Based Message Authentication Code in the Internet X.509
> >>> Public Key Infrastructure Certificate Request Message Format (CRMF)
> >>> specified in RFC 4211.
> >>
> >> _______________________________________________
> >> Spasm mailing list
> >> Spasm@ietf.org
> >>
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
> >>
> .ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D04%7C01%7Chendrik.
> >>
> brockhaus%40siemens.com%7Cd60b8e72a1514c52a39408d8a37f660e%7C38a
> >>
> e3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637439115015092508%7CU
> >>
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> >>
> 6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DEUn8W8MCpNFPSlQs79J
> >> Aq%2FMEvVUV%2BfKyw5WiNjoDa7c%3D&reserved=3D0
> >
> > _______________________________________________
> > Spasm mailing list
> > Spasm@ietf.org
> >
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
> .
> >
> ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D04%7C01%7Chendrik.b
> rock
> >
> haus%40siemens.com%7Cd5b41e6e86b9426dc44308d8a5c7a364%7C38ae3bc
> d95794f
> >
> d4addab42e1495d55a%7C1%7C0%7C637441624152431517%7CUnknown%7CT
> WFpbGZsb3
> >
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7
> >
> C1000&sdata=3D%2FnRwbNXjvkUR%2BCAvWkombUkbqHL2QUP5Z8m9e
> Mo71ak%3D&
> > ;reserved=3D0


From nobody Tue Dec 22 09:01:49 2020
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 06F833A1236 for ; Mon, 21 Dec 2020 08:36:56 -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, HTML_MESSAGE=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 g1KXdmlnjUY9 for ; Mon, 21 Dec 2020 08:36:53 -0800 (PST)
Received: from saus.bts.sk (saus.bts.sk [194.160.23.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD453A1235 for ; Mon, 21 Dec 2020 08:36:52 -0800 (PST)
Received: from saus.bts.sk ([194.160.23.4] helo=bts.sk) by saus.bts.sk with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1krOAw-0005Mt-TR; Mon, 21 Dec 2020 17:36:47 +0100
From: "=?UTF-8?Q?Marian_=C4=8Eurkovi=C4=8D?=" 
To: Mohit Sahni 
Cc: "Salz, Rich" , Russ Housley , LAMPS 
Date: Mon, 21 Dec 2020 17:36:46 +0100
Message-Id: <20201221155837.M1893@bts.sk>
In-Reply-To: 
References: <20201218103651.M76302@bts.sk>    <7E92C4FB-4118-470A-8BA4-BEA133FA46AF@akamai.com> <20201218224153.M14899@bts.sk>  <20201218230753.M63543@bts.sk>  <20201219085409.M21922@bts.sk>  <20201219121104.M37970@bts.sk> 
X-Mailer: OpenWebMail 2.53
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=OPENWEBMAIL_ATT_0.385066720049025"
X-Spam-Note: SpamAssassin run bypassed due to hostname whitelisted
Archived-At: 
X-Mailman-Approved-At: Tue, 22 Dec 2020 09:01:48 -0800
Subject: Re: [lamps] Fwd: Conflict between RFC8954 and ISO 14533-4
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, 21 Dec 2020 16:36:56 -0000

This is a multi-part message in MIME format.

------=OPENWEBMAIL_ATT_0.385066720049025
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

On Sat, 19 Dec 2020 13:12:17 -0800, Mohit Sahni wrote

> From OCSP point of view the MessageImprint is not a random value but it is a deterministic value generated for a given input by a collision resistant one way hash function.

This input, however, consists of multiple parts: some of them being random, some of them being unknown even to document signer (private key). In any case, an attacker is not able to guess this value so it serves against reply attack very well.

> One more reason I see for not changing the Nonce extension length is that the length of MessageImprint is not fixed but varies based on the underlying hash algorithm.  Since RFC3161 does not provide a fixed list of Hash functions, let's say we change the size to Nonce extension to 64 bytes, what if in the future there is a new hash algorithm or some proprietary hash function that requires size to be 128 bytes or 256 bytes or may be 100 GigaBytes, are we going to increase the size of the Nonce extension again?  How can we set an upper limit on Nonce which also serves the regular Nonce use case of just avoiding the replay attacks ?

I proposed 2 values: 96 bytes if we want to accomodate 512-bit hashes, or 160 bytes, if we want to accomodate (future) 1024-bit hashes. Any hashing algorithm is designed to yield a relatively small result, so we're certainly not talking about GigaBytes here...

> In my opinion, ISO 14533 took advantage of the security vulnerability that existed in RFC6960 and tried using Nonce extension in a way it was not intended to be used as i.e. using an ASN.1 SEQUENCE where the standard requires use of OCTET STRING.

OCTET STRING means arbitrary sequence of bytes, which OCSP responder shouldn't interpret in any way - just echo them back in its response. It's completely irrelevant, what's encoded inside - after all, a random number could also start with 0x30 which corresponds to SEQUENCE.

> We should come up with a new extension for associating the OCSP response with the context where OCSP is being used for long term validation. That is the right thing to do.

And what will be the advantage of having yet another extension doing the same thing? Both use cases require nothing else from OCSP responder than to echo back exactly the same bytes it received in request. Do you propose to have 2 extensions, one of them being able to only echo 32 bytes and another being able to echo 96? or 160? or unlimited bytes? Isn't it much more straightforward to have only one "echoing" extension being able to echo as many bytes as needed for both use cases?

On the other hand, the disadvantages are significant - I mentioned some of them in my previous email. Also please keep in mind, that RFC 8954 (if applied by OCSP responder or by some firewall doing deep packet inspection) will immediately break digital signing - since it says:
 A server *MUST* reject any OCSP request that has a nonce in the Nonce
extension with a length of either 0 octets or more than 32 octets
with the malformedRequest OCSPResponseStatus

Last but not least, introducing another extension is more complex than you assume - it will require modification of (at least) RFC6960, RFC5019, ISO 14533-4. When will that solution be available and what to do until then?

With kind regards,

MD

 

------=OPENWEBMAIL_ATT_0.385066720049025
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable








On Sat, 19 Dec 2020 13:12:17 -0800, Mohit Sahni wrote



> From OCSP point of view the=C2=A0MessageImprint =
is not a random value=20
but it is a deterministic value generated for a given input by a collision=
=20
resistant one way hash function.=20









This input, however, consists of multiple parts: some=
 of them being random, some of them being unknown even to document signer (=
private key). In any case, an attacker is not able to guess this value so i=
t serves against reply attack very well.









> One more reason I see for not changing the=20
Nonce extension length is that the length of=C2=A0MessageImprint is not fix=
ed but=20
varies based on the underlying hash algorithm.=C2=A0 Since RFC3161 does not=
 provide=20
a fixed list of Hash functions, let's say we change the size to Nonce=20
extension to 64 bytes, what if in the future there is a new hash algorithm =
or=20
some proprietary hash function that requires size to be 128 bytes or 256 by=
tes=20
or may be 100 GigaBytes, are we going to increase the size of the Nonce=20
extension again?=C2=A0 How can we set an upper limit on Nonce which also se=
rves the=20
regular Nonce use case of just avoiding the replay attacks ?








I proposed 2 values: 96 bytes if we want to accomodat=
e 512-bit hashes, or 160 bytes, if we want to accomodate (future) 1024-bit =
hashes. Any hashing algorithm is designed to yield a relatively small resul=
t, so we're certainly not talking about GigaBytes here...









>=20
In my opinion, ISO 14533 took advantage of the security vulnerability that=
=20
existed in RFC6960 and tried using Nonce extension in a way it was not inte=
nded=20
to be used as i.e. using an ASN.1 SEQUENCE where the standard requires=C2=
=A0use of=20
OCTET=C2=A0STRING.=20









OCTET STRING means arbitrary sequence of bytes, which=
 OCSP responder shouldn't interpret in any way - just echo them back in its=
 response. It's completely irrelevant, what's encoded inside - after all, a=
 random number could also start with 0x30 which corresponds to SEQUENCE.=20









> We should come up with a new extension for assoc=
iating the OCSP=20
response with the context where OCSP is being used for long term validation=
.=20
That is the right thing to do.=20









And what will be the advantage of having yet another =
extension doing the same thing? Both use cases require nothing else from OC=
SP responder than to echo back exactly the same bytes it received in reques=
t. Do you propose to have 2 extensions, one of them being able to only echo=
 32 bytes and another being able to echo 96? or 160? or unlimited bytes? Is=
n't it much more straightforward to have only one "echoing" exten=
sion being able to echo as many bytes as needed for both use cases?<=
/div>







On the other hand, the disadvantages are significant =
- I mentioned some of them in my previous email. Also please keep in mind, =
that RFC 8954 (if applied by OCSP responder or by some firewall doing deep =
packet inspection) will immediately break digital signing - since it says:<=
/font>



   A server *MUST* reject any OCSP request that has a nonce in the Non=
ce
   extension with a length of either 0 octets or more than 32 octets
   with the malformedRequest OCSPResponseStatus



Last but not least, introducing another extension is =
more complex than you assume - it will require modification of (at least) R=
FC6960, RFC5019, ISO 14533-4. When will that solution be available and what=
 to do until then?








With kind regards,



MD























------=OPENWEBMAIL_ATT_0.385066720049025--


From nobody Tue Dec 22 13:47:48 2020
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 7CEA53A12D2 for ; Tue, 22 Dec 2020 13:47:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=digicert.com header.b=lGECpNoW; dkim=pass (1024-bit key) header.d=digicert.com header.b=EWZaz0Mx
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 PL3pXRlubfZ9 for ; Tue, 22 Dec 2020 13:47:44 -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 A41DE3A12CE for ; Tue, 22 Dec 2020 13:47:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1608673663; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=D5sLZJPaSbd7Z18HDOtlFBFeft/ntvusHth+qZR63G0=; b=lGECpNoWkrdbsY/E9ThYkT+rbp1qQ+fQptymvV/TA5QvRIHzFbLbdKlZZOXOhG0/11vBpe cDqCFv8SWCBP68D6sNQTe/wrc9ZWP5GmLhejFtpxe58a+QcD69wNTha83NAFChbGo00vFE y8TVieEDbLsao6ypDMZAgMN+UM24q+A=
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2106.outbound.protection.outlook.com [104.47.58.106]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-202-NrcGWbOSMM6cXHhf9x0k8w-1; Tue, 22 Dec 2020 16:47:40 -0500
X-MC-Unique: NrcGWbOSMM6cXHhf9x0k8w-1
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U8qvlr2yQ4pt+iqh4uhwgiAsp49Pq0/YDqTDAH/7k6IQLYv4TwIOTHX2kJbnY//xoi83PGedS3eK5KSuQLLzpLU9prSqW9mhPC+/0rWis6YUs163b4JROu7m23VjdQPcy85zcLS2s4u+ghE24dK3561IgPCmYDmFLEE9D7j+Qxq6t3JDt4GRzePFsZhSOJnIRpE1yMHTMxB7yDMQ6rc+1RdbcCG1xY0RwX678zDShGgYNmSzqWscrfBY8+gmZNBnMnI8n4KABmCXLPZXW+12EdcAB0rryAkMZC43Oqy3iWADYi/kyRVsLPPjz5kRvD2hWpNtw/L4apMRFwItIUOiZw==
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=D5sLZJPaSbd7Z18HDOtlFBFeft/ntvusHth+qZR63G0=; b=ls4Qe6HVBnoI8YKm1B9qyvw+A6Jz3ZK4VJGs2XGYHAVZ5gtE0Hv7RhuL2+lR66E6/cZmfWcEJPjrp96gfDRAaUbQelaJjVcfwcog1dsyQqURQ6GdbLE2wRMtFBse6WWqIhPCQXskdKe+q83WXjZ/Cj6UnuRK8uQS/euWRKz4W7ERP7v51ikK2GWXHsmeHJWFImCWa5D0b7qD97BvFko6GhY3j0ncDs2OJ7UdPCqV0zd0uauBkKnrVUP3w+QlobNzK0ctofcLifnfp4JiYC6fnvlR/pG3q4D4syOIFrSABoeWuorKpw7n0nilnpNE0yv8UGlpl+GhdmuB4VsudUJkHw==
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=D5sLZJPaSbd7Z18HDOtlFBFeft/ntvusHth+qZR63G0=; b=EWZaz0Mx76tcCcxV2BmP7lBVXNNTB+ZOk8UWSDpmGvzK7uAFw0Hpw3z9ocsc0DnJCg3QV0MCyEXDgjoocrdY4B1ovIVykATfrmc2BCjA7aIgYvWzwDqXkhFQoocFQFvtGU/4e6lxtC9SSqTGVk3vRT+eyoWVOCBI9wHQvJ1ppAA=
Received: from MN2PR14MB3167.namprd14.prod.outlook.com (2603:10b6:208:12e::28) by MN2PR14MB4190.namprd14.prod.outlook.com (2603:10b6:208:1dc::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.25; Tue, 22 Dec 2020 21:47:38 +0000
Received: from MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::7929:62d4:d59d:be5e]) by MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::7929:62d4:d59d:be5e%3]) with mapi id 15.20.3676.033; Tue, 22 Dec 2020 21:47:38 +0000
From: Tim Hollebeek 
To: Tim Hollebeek , LAMPS 
Thread-Topic: WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
Thread-Index: AdbKgl0GZVRVKEllR6iGycD6D5x5ZAOKY8Zw
Date: Tue, 22 Dec 2020 21:47:38 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=digicert.com;
x-originating-ip: [74.111.113.115]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d852b2a5-c8e3-4440-103e-08d8a6c33388
x-ms-traffictypediagnostic: MN2PR14MB4190:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: uAQV7HENxwATUklVPHHQ08POxDZgwmf/k02WLwBenOGpQ5Lpd/rIg3+UwbHRIykyeboHl77kC55X2WYKmI2Ec0IX//qmLm8faq3j7Ry6twkrWSqVGr/FU4jUG0zNLqp0YsmabYlo0AlO2mFuVbOklmsZYHQeqVAp/AcwdU0NQtVQCRQ37KYLxhzK4LsX0Yo9sv10zl7r67eUfcIKohHjpu7tNXflcWlTvucIz3ScF/HBffbTUPN6DCWXKv24QJz2qiwIrsJsWRntAkiSl2P1SEKsPynoKXjuO7vM8zcSA7ZaL7S5FK3ll0TFxHSA4MyUnL1RNlgreUS0uW6VmccoroixUxjGFgGmm1d292lVCs9zy/OXrWAswoYiDRv3y6M792d28lMaoUKKm95XCyMcYs1z7/cfd2iaSkPUi576vS1GdpMS8adLAtkkzEQzodHtSdDYqzGnh3x1Lgoqr84bbw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MN2PR14MB3167.namprd14.prod.outlook.com; PTR:; CAT:NONE;  SFS:(376002)(346002)(366004)(396003)(136003)(39850400004)(99936003)(76116006)(66476007)(64756008)(52536014)(966005)(66556008)(66946007)(66446008)(186003)(33656002)(478600001)(316002)(66616009)(8936002)(55016002)(2906002)(8676002)(166002)(5660300002)(83380400001)(110136005)(71200400001)(44832011)(53546011)(9686003)(26005)(6506007)(4744005)(86362001)(7696005); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?o63G0hF6WdCE5NrqXgnSwMG5WBsAgEuhiFHfPn0NoyPVIEB8vuAVwikX34x4?= =?us-ascii?Q?vXN6s951aU+YBdlrrxuJ4Fr9HZJfbRi+xKJG0FtbEqd37hs85oRsEaI5Tu/b?= =?us-ascii?Q?48tB332BRTnMrlv2EPfdsV4PC6n7Rd1uGg1jjiLsn8u6lek+r9t5NWAl4yiX?= =?us-ascii?Q?ZLwOzxs/Zs+XXyJhe83UgLDDDYoTfkl81NyjrFeqCfrSVJiz84zubSNxvAFW?= =?us-ascii?Q?GMKKp1Zu8RSN3tsQIOFEfWshvdT0dVDiOSMQRyMF3OWsRttloxrC3S99yEgI?= =?us-ascii?Q?pssaxb3btKK6g6/Y1knCUhtlnGvpRypqKY3g60DvfdV3RtjpeRiruGFUcwIv?= =?us-ascii?Q?S4DDzAUr+N+KS8S/de+Ln4IjboaQVa1GNa9lLRYk12HTX2Se9vcjXe5Z54Ma?= =?us-ascii?Q?O3Maw18k5XxAsiqSEJ5ikrNgjwAxBK3HmHw5s2nCgLZMzczJCDSCWHXCh6pd?= =?us-ascii?Q?l9qPu0Bw+f5MvPNXzpq/8bXjkZsdBEmHm3XdXQVILU041EbmLthuuQdx4ckO?= =?us-ascii?Q?IdHtcfNDoIcuIzF9mFLTE+Ht/DY8M8x0wQ4Oj80plfu1xa+VE6OL8OlI351/?= =?us-ascii?Q?8CPNexIgQVOK/90ooG5ZQs5AI9HlETG+gT70qShfmcNdKXfEj16HkQqqU1Xd?= =?us-ascii?Q?pO/nAD6xN6JuSeDAfjWkZ+IBAOhXHs9pkxdt+0/gYHG/IWUuk6/yna4Ib/ZC?= =?us-ascii?Q?bh8yeWATWNyQTYa57O5FIZxjEaj/XNLdfDh0ygaAM+JwmfV6qZRBJUdBJkhv?= =?us-ascii?Q?exHPrTLKLxzaLPzE13JNtgGDO21o95vMThro5eiy9iNjROfqY9Eo7o7UDRAk?= =?us-ascii?Q?zuJC+KFBW97f6jgkjsCRkMdH4XCo9EhTAW0mLIfWhFGBCCNXeS27dTme0YfJ?= =?us-ascii?Q?F3av/+bDmByOVXlJCy6pD1SR3VZry8mW6HXuM+M5XcFO1ZRn2idjlaCOg4L7?= =?us-ascii?Q?B/PNnZ0t1hRDZkiT24cGP6YZesfw0lg/yE1HdC/XyG0=3D?=
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_03B6_01D6D882.27090920"
MIME-Version: 1.0
X-OriginatorOrg: digicert.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR14MB3167.namprd14.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d852b2a5-c8e3-4440-103e-08d8a6c33388
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2020 21:47:38.4734 (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: ak208a2bmDEB+PHpTylJx0zmMwfT5DyqjcLg0SAazIbIFCI5cz6JvT4B2+nRHDp3RlPDylOpYjZK7SCWQwa1zHp9wdQrczhvFAx6mwpbFuA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB4190
Archived-At: 
Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
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, 22 Dec 2020 21:47:47 -0000

------=_NextPart_000_03B6_01D6D882.27090920
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_03B7_01D6D882.27090920"


------=_NextPart_001_03B7_01D6D882.27090920
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The comment period has ended, and no new feedback was received.  I'll start
pushing this forward.

 

-Tim

 

From: Spasm  On Behalf Of Tim Hollebeek
Sent: Friday, December 4, 2020 4:17 PM
To: LAMPS 
Subject: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg

 

This is the LAMPS WG Last Call for "Using the AES-GMAC Algorithm with the
Cryptographic Message Syntax (CMS)" .
Please review the document and send your comments to the list by 18 December
2020.

 

The datatracker page for the document is
https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-aes-gmac-alg/

 

-Tim


------=_NextPart_001_03B7_01D6D882.27090920
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


The comment period has ended, =
and no new feedback was received.  I’ll start pushing this =
forward.
 
-Tim
 
From: Spasm =
<spasm-bounces@ietf.org> On Behalf Of Tim =
Hollebeek
Sent: Friday, December 4, 2020 4:17 PM
To: =
LAMPS <spasm@ietf.org>
Subject: [lamps] WG Last Call for =
draft-ietf-lamps-cms-aes-gmac-alg
 
This is the =
LAMPS WG Last Call for "Using the AES-GMAC Algorithm with the =
Cryptographic Message Syntax (CMS)” =
<draft-ietf-lamps-cms-aes-gmac-alg-00>.  Please review the =
document and send your comments to the list by 18 December =
2020.
 
The datatracker page for the document is https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-aes-gmac-alg/
 
-Tim

------=_NextPart_001_03B7_01D6D882.27090920--

------=_NextPart_000_03B6_01D6D882.27090920
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
CQUxDxcNMjAxMjIyMjE0NzM2WjAvBgkqhkiG9w0BCQQxIgQg91hTu44SSRqD6Kyrt5dyNKxNwewp
0G0lOpj/2pwvAFAwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp
Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw
ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth
tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq
hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG
SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA
BIIBAJ5e9pZleUVYaq/TkPUXth+DyfTKFerGanoQ0n278G4/dGVwK4Pr0DzeioboR6EcDbd1aNoA
6QjcKXEZGkQMHHy5jDVjYBoykIgEhFjptN+SdQYE+9ObGKnVOAgKpVc9xcdBEf5Vo8Ac5S55G6UZ
PW05J10ELPiFFVqs8vKWByG9i8UlLBXwzOuxuvd7KlfhdK2vKbEcPrtkWEUusf2X/iem1HSK5uUc
YxdVXDe00LDnYWLFTS4ZnvrIOarsNhLeCbb5a19FLlF5cFgcQXr4/Qi/jcq7p1QbMMnO+HnDEFjL
z/k8sHG5YvTmPSvAjtNaPWs3f5cB7vvlb43YmidfmFwAAAAAAAA=

------=_NextPart_000_03B6_01D6D882.27090920--


From nobody Tue Dec 22 23:40:28 2020
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 0FEA93A0B37 for ; Tue, 22 Dec 2020 23:40:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=kdhRNKK0; dkim=pass (1024-bit key) header.d=primekey.com header.b=kdhRNKK0
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 en7jPDswrAyo for ; Tue, 22 Dec 2020 23:40: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 3AD713A0B36 for ; Tue, 22 Dec 2020 23:40: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 4DA8D6AA61A8 for ; Wed, 23 Dec 2020 08:40:19 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1608709219; bh=D7uTckNcZN7UPvOG27MV1POPbS45mNODzf3rrEPcasY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=kdhRNKK02sJvRsHu8lOFKjl5GKAe+soBW9MJHw9QJBeHgOI1CxUlVHtkfYj3Fj//m HJUKmenvwQzSlF29sFsUlE0y12tg2ueQwLq1zm9jmVCSeFsVP+m0xeKjblfSN7lXf2 IBK6edpsaYYp8idDILHd5UZ8xQUKnKamkmxK64Dw=
Received: from [10.11.0.11] (unknown [10.11.0.11]) (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 2B7ED6AA5D23 for ; Wed, 23 Dec 2020 08:40:19 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1608709219; bh=D7uTckNcZN7UPvOG27MV1POPbS45mNODzf3rrEPcasY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=kdhRNKK02sJvRsHu8lOFKjl5GKAe+soBW9MJHw9QJBeHgOI1CxUlVHtkfYj3Fj//m HJUKmenvwQzSlF29sFsUlE0y12tg2ueQwLq1zm9jmVCSeFsVP+m0xeKjblfSN7lXf2 IBK6edpsaYYp8idDILHd5UZ8xQUKnKamkmxK64Dw=
To: spasm@ietf.org
References: <20201218103651.M76302@bts.sk>    <7E92C4FB-4118-470A-8BA4-BEA133FA46AF@akamai.com> <20201218224153.M14899@bts.sk>  <20201218230753.M63543@bts.sk>  <20201219085409.M21922@bts.sk>  <20201219121104.M37970@bts.sk>  <20201221155837.M1893@bts.sk>
From: Tomas Gustavsson 
Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= xsBNBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAHNMFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPsLA dwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5zsBNBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAHCwF8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw==
Message-ID: 
Date: Wed, 23 Dec 2020 08:40:19 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <20201221155837.M1893@bts.sk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [lamps] Fwd: Conflict between RFC8954 and ISO 14533-4
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2020 07:40:27 -0000

Hi,

I'd like to give my view on this.

I support not changing anything in RFC8954.

I recently started using the term "tweaking standards" for when you take
an existing field in a standard and use it for other purposes than the
one stated in the standard, just because it is technically possible and
not explicitly forbidden in the standard. This has been done many times
before, and many times it leads to interoperability issues, severe
spending of time, money and resources, and in severe cases even downtime.
Tweaking standards is a short term short-cut, ignoring long term costs.

ISO 14533 clearly tweaked RFC6960 section 4.4.1.

Many internet scale OCSP responders today do not include Nonce in the
response. Regardless if the client sends it. This is for caching
reasons, and is for both GET and POST requests.

Using nonce as MessageImprint is non-interoperable with RFC6960 and with
the real world.

I'd like to say it again: ISO 14533 is non-interoperable with how OCSP
is deployed on the internet today.

It is a disaster waiting to happen. The reason it hasn't happened yet is
likely due to ISO 14533 not being widely used. Let's fix it before it
falls apart.
The solution is not to force RFC6960 compliant OCSP responders into
submission to ISO 14533, but to fix ISO 14533.
ISO 14533 should recognize that the suggested solution is non-compliant,
causing interoperability issues, and go back and create an extension.
Yes, it's a little more work, and may result in a new RFC, or a
replacement of RFC6960 (but the extension can be private to ISO 14533 to
start with), but it's the right thing to do imho.

There is already an extension, a bit similar to this, specified in the
German Common PKI. https://de.wikipedia.org/wiki/Common_PKI
It's called CertHash and can be copied. The specification isn't
available any longer, but I have an off-line copy that I share here:
https://app.box.com/s/lk1g4a3h75icirnu6xqrqhee8h5kmv54

It's a SingleResponse extension, section 3.1.2:

id-commonpki-at-certHash OBJECT IDENTIFIER ::== {1 3 36 8 3 13}

CertHash ::= SEQUENCE {
  hashAlgorithm AlgorithmIdentifier, // The identifier of the algorithm
                                     // that has been used the for hash
                                     //value below.

  certificateHash OCTET STRING // A hash over the DER-encoding of the
                               // entire PKC or AC (i.e. NOT a hash
                               // over tbsCertificate).
}

There are OCSP responders out there supporting the old CertHash extension.

Not saying to use it "as is", it has another purpose, but very very
similar. Just put a new OID and rename it to MessageImprint...

Best regards,
Tomas


On 2020-12-21 17:36, Marian ÄŽurkoviÄ wrote:
> *On Sat, 19 Dec 2020 13:12:17 -0800, Mohit Sahni wrote*
>> From OCSP point of view the MessageImprint is not a random value but
> it is a deterministic value generated for a given input by a collision
> resistant one way hash function.
> 
> This input, however, consists of multiple parts: some of them being
> random, some of them being unknown even to document signer (private
> key). In any case, an attacker is not able to guess this value so it
> serves against reply attack very well.
> 
>> One more reason I see for not changing the Nonce extension length is
> that the length of MessageImprint is not fixed but varies based on the
> underlying hash algorithm.  Since RFC3161 does not provide a fixed list
> of Hash functions, let's say we change the size to Nonce extension to 64
> bytes, what if in the future there is a new hash algorithm or some
> proprietary hash function that requires size to be 128 bytes or 256
> bytes or may be 100 GigaBytes, are we going to increase the size of the
> Nonce extension again?  How can we set an upper limit on Nonce which
> also serves the regular Nonce use case of just avoiding the replay attacks ?
> 
> I proposed 2 values: 96 bytes if we want to accomodate 512-bit hashes,
> or 160 bytes, if we want to accomodate (future) 1024-bit hashes. Any
> hashing algorithm is designed to yield a relatively small result, so
> we're certainly not talking about GigaBytes here...
> 
>> In my opinion, ISO 14533 took advantage of the security vulnerability
> that existed in RFC6960 and tried using Nonce extension in a way it was
> not intended to be used as i.e. using an ASN.1 SEQUENCE where the
> standard requires use of OCTET STRING.
> 
> OCTET STRING means arbitrary sequence of bytes, which OCSP responder
> shouldn't interpret in any way - just echo them back in its response.
> It's completely irrelevant, what's encoded inside - after all, a random
> number could also start with 0x30 which corresponds to SEQUENCE.
> 
>> We should come up with a new extension for associating the OCSP
> response with the context where OCSP is being used for long term
> validation. That is the right thing to do.
> 
> And what will be the advantage of having yet another extension doing the
> same thing? Both use cases require nothing else from OCSP responder than
> to echo back exactly the same bytes it received in request. Do you
> propose to have 2 extensions, one of them being able to only echo 32
> bytes and another being able to echo 96? or 160? or unlimited bytes?
> Isn't it much more straightforward to have only one "echoing" extension
> being able to echo as many bytes as needed for both use cases?
> 
> On the other hand, the disadvantages are significant - I mentioned some
> of them in my previous email. Also please keep in mind, that RFC 8954
> (if applied by OCSP responder or by some firewall doing deep packet
> inspection) will immediately break digital signing - since it says:
> 
>    A server *MUST* reject any OCSP request that has a nonce in the Nonce
>    extension with a length of either 0 octets or more than 32 octets
>    with the malformedRequest OCSPResponseStatus
> 
> Last but not least, introducing another extension is more complex than
> you assume - it will require modification of (at least) RFC6960,
> RFC5019, ISO 14533-4. When will that solution be available and what to
> do until then?
> 
> With kind regards,
> MD
> 
> 
> 
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
> 


From nobody Tue Dec 22 23:56:12 2020
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 E03973A0B62 for ; Tue, 22 Dec 2020 23:56:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=kfT42oMc; dkim=pass (1024-bit key) header.d=primekey.com header.b=kfT42oMc
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 L1tOS9l4IAEJ for ; Tue, 22 Dec 2020 23:56:07 -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 287993A0B5A for ; Tue, 22 Dec 2020 23:56:06 -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 A78BC6AA61B3 for ; Wed, 23 Dec 2020 08:56:04 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1608710164; bh=NCzZC+FtHKY0HHOCD1vzIRXP+lwWlasCXiOsQjW+P9o=; h=Subject:To:References:From:Date:In-Reply-To:From; b=kfT42oMc7EiL1NpvDEg+HAFw17GsVBEFv7QYFKrn3uHhXGduXSiEw8Xx8jhJJ80z5 TRPNOSTWR6aRFai/WVAjy2OKDfCPmgpNNc4unXPtNdmqFtIpBCq9ONlU8h4isgMbv1 x1EQWz5hpH5vpOGR2oUuaFR5ioJfpnsrZcd90i2Q=
Received: from [10.11.0.11] (unknown [10.11.0.11]) (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 86E6F6AA61B2 for ; Wed, 23 Dec 2020 08:56:04 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1608710164; bh=NCzZC+FtHKY0HHOCD1vzIRXP+lwWlasCXiOsQjW+P9o=; h=Subject:To:References:From:Date:In-Reply-To:From; b=kfT42oMc7EiL1NpvDEg+HAFw17GsVBEFv7QYFKrn3uHhXGduXSiEw8Xx8jhJJ80z5 TRPNOSTWR6aRFai/WVAjy2OKDfCPmgpNNc4unXPtNdmqFtIpBCq9ONlU8h4isgMbv1 x1EQWz5hpH5vpOGR2oUuaFR5ioJfpnsrZcd90i2Q=
To: spasm@ietf.org
References: <20201218103651.M76302@bts.sk>    <7E92C4FB-4118-470A-8BA4-BEA133FA46AF@akamai.com> <20201218224153.M14899@bts.sk>  <20201218230753.M63543@bts.sk>  <20201219085409.M21922@bts.sk>  <20201219121104.M37970@bts.sk>  <20201221155837.M1893@bts.sk> 
From: Tomas Gustavsson 
Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= xsBNBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAHNMFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPsLA dwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5zsBNBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAHCwF8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw==
Message-ID: <011be1c1-3d42-926e-823e-c2beac5a94ed@primekey.com>
Date: Wed, 23 Dec 2020 08:56:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] Fwd: Conflict between RFC8954 and ISO 14533-4
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2020 07:56:11 -0000

CertHash is also mentioned in the eIDAS rgulation acording to this.
https://ec.europa.eu/cefdigital/tracker/secure/attachment/17296/17296_OCSP+and+Article+24-4+of+eIDAS+EU+regulation+910-2014.pdf

And the below should be specific to ISO 14533-4 (PoEAttributes), it's
not generic for CAdES.

> I'd like to say it again: ISO 14533-4 is non-interoperable with how
> OCSP is deployed on the internet today.

Of course, the MessageImprint ASN.1 is identical to CertHash, just
another OID. It's nothing special to add an extension for this.

Regards,
Tomas

On 2020-12-23 08:40, Tomas Gustavsson wrote:
> 
> Hi,
> 
> I'd like to give my view on this.
> 
> I support not changing anything in RFC8954.
> 
> I recently started using the term "tweaking standards" for when you take
> an existing field in a standard and use it for other purposes than the
> one stated in the standard, just because it is technically possible and
> not explicitly forbidden in the standard. This has been done many times
> before, and many times it leads to interoperability issues, severe
> spending of time, money and resources, and in severe cases even downtime.
> Tweaking standards is a short term short-cut, ignoring long term costs.
> 
> ISO 14533 clearly tweaked RFC6960 section 4.4.1.
> 
> Many internet scale OCSP responders today do not include Nonce in the
> response. Regardless if the client sends it. This is for caching
> reasons, and is for both GET and POST requests.
> 
> Using nonce as MessageImprint is non-interoperable with RFC6960 and with
> the real world.
> 
> I'd like to say it again: ISO 14533 is non-interoperable with how OCSP
> is deployed on the internet today.
> 
> It is a disaster waiting to happen. The reason it hasn't happened yet is
> likely due to ISO 14533 not being widely used. Let's fix it before it
> falls apart.
> The solution is not to force RFC6960 compliant OCSP responders into
> submission to ISO 14533, but to fix ISO 14533.
> ISO 14533 should recognize that the suggested solution is non-compliant,
> causing interoperability issues, and go back and create an extension.
> Yes, it's a little more work, and may result in a new RFC, or a
> replacement of RFC6960 (but the extension can be private to ISO 14533 to
> start with), but it's the right thing to do imho.
> 
> There is already an extension, a bit similar to this, specified in the
> German Common PKI. https://de.wikipedia.org/wiki/Common_PKI
> It's called CertHash and can be copied. The specification isn't
> available any longer, but I have an off-line copy that I share here:
> https://app.box.com/s/lk1g4a3h75icirnu6xqrqhee8h5kmv54
> 
> It's a SingleResponse extension, section 3.1.2:
> 
> id-commonpki-at-certHash OBJECT IDENTIFIER ::== {1 3 36 8 3 13}
> 
> CertHash ::= SEQUENCE {
>   hashAlgorithm AlgorithmIdentifier, // The identifier of the algorithm
>                                      // that has been used the for hash
>                                      //value below.
> 
>   certificateHash OCTET STRING // A hash over the DER-encoding of the
>                                // entire PKC or AC (i.e. NOT a hash
>                                // over tbsCertificate).
> }
> 
> There are OCSP responders out there supporting the old CertHash extension.
> 
> Not saying to use it "as is", it has another purpose, but very very
> similar. Just put a new OID and rename it to MessageImprint...
> 
> Best regards,
> Tomas
> 
> 
> On 2020-12-21 17:36, Marian ÄŽurkoviÄ wrote:
>> *On Sat, 19 Dec 2020 13:12:17 -0800, Mohit Sahni wrote*
>>> From OCSP point of view the MessageImprint is not a random value but
>> it is a deterministic value generated for a given input by a collision
>> resistant one way hash function.
>>
>> This input, however, consists of multiple parts: some of them being
>> random, some of them being unknown even to document signer (private
>> key). In any case, an attacker is not able to guess this value so it
>> serves against reply attack very well.
>>
>>> One more reason I see for not changing the Nonce extension length is
>> that the length of MessageImprint is not fixed but varies based on the
>> underlying hash algorithm.  Since RFC3161 does not provide a fixed list
>> of Hash functions, let's say we change the size to Nonce extension to 64
>> bytes, what if in the future there is a new hash algorithm or some
>> proprietary hash function that requires size to be 128 bytes or 256
>> bytes or may be 100 GigaBytes, are we going to increase the size of the
>> Nonce extension again?  How can we set an upper limit on Nonce which
>> also serves the regular Nonce use case of just avoiding the replay attacks ?
>>
>> I proposed 2 values: 96 bytes if we want to accomodate 512-bit hashes,
>> or 160 bytes, if we want to accomodate (future) 1024-bit hashes. Any
>> hashing algorithm is designed to yield a relatively small result, so
>> we're certainly not talking about GigaBytes here...
>>
>>> In my opinion, ISO 14533 took advantage of the security vulnerability
>> that existed in RFC6960 and tried using Nonce extension in a way it was
>> not intended to be used as i.e. using an ASN.1 SEQUENCE where the
>> standard requires use of OCTET STRING.
>>
>> OCTET STRING means arbitrary sequence of bytes, which OCSP responder
>> shouldn't interpret in any way - just echo them back in its response.
>> It's completely irrelevant, what's encoded inside - after all, a random
>> number could also start with 0x30 which corresponds to SEQUENCE.
>>
>>> We should come up with a new extension for associating the OCSP
>> response with the context where OCSP is being used for long term
>> validation. That is the right thing to do.
>>
>> And what will be the advantage of having yet another extension doing the
>> same thing? Both use cases require nothing else from OCSP responder than
>> to echo back exactly the same bytes it received in request. Do you
>> propose to have 2 extensions, one of them being able to only echo 32
>> bytes and another being able to echo 96? or 160? or unlimited bytes?
>> Isn't it much more straightforward to have only one "echoing" extension
>> being able to echo as many bytes as needed for both use cases?
>>
>> On the other hand, the disadvantages are significant - I mentioned some
>> of them in my previous email. Also please keep in mind, that RFC 8954
>> (if applied by OCSP responder or by some firewall doing deep packet
>> inspection) will immediately break digital signing - since it says:
>>
>>    A server *MUST* reject any OCSP request that has a nonce in the Nonce
>>    extension with a length of either 0 octets or more than 32 octets
>>    with the malformedRequest OCSPResponseStatus
>>
>> Last but not least, introducing another extension is more complex than
>> you assume - it will require modification of (at least) RFC6960,
>> RFC5019, ISO 14533-4. When will that solution be available and what to
>> do until then?
>>
>> With kind regards,
>> MD
>>
>>
>>
>>
>> _______________________________________________
>> Spasm mailing list
>> Spasm@ietf.org
>> https://www.ietf.org/mailman/listinfo/spasm
>>
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
> 


From nobody Wed Dec 23 07:41:34 2020
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 DF88A3A0B05 for ; Wed, 23 Dec 2020 07:41: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, 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 Ipc5qaIaL3Ri for ; Wed, 23 Dec 2020 07:41:30 -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 B69253A0B02 for ; Wed, 23 Dec 2020 07:41:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D75C3300A4B for ; Wed, 23 Dec 2020 10:41: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 r8vOLKGMF9bJ for ; Wed, 23 Dec 2020 10:41:24 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 9E902300BB7; Wed, 23 Dec 2020 10:41:24 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Russ Housley 
In-Reply-To: 
Date: Wed, 23 Dec 2020 10:41:25 -0500
Cc: LAMPS 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20201218103651.M76302@bts.sk>    <7E92C4FB-4118-470A-8BA4-BEA133FA46AF@akamai.com> <20201218224153.M14899@bts.sk>  <20201218230753.M63543@bts.sk>  <20201219085409.M21922@bts.sk>  <20201219121104.M37970@bts.sk>  <20201221155837.M1893@bts.sk> 
To: IAB 
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: [lamps] Conflict between RFC8954 and ISO 14533-4
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2020 15:41:33 -0000

Dear  IAB:

The IETF does not have a liaison relationship with the ISO TC that =
produced ISO 14533-4:2019.  It would be a good think to tell that group =
that we disagree with the approach that was taken.  What does the IAB =
suggest?

Russ

> On Dec 23, 2020, at 2:40 AM, Tomas Gustavsson =
 wrote:
>=20
>=20
> Hi,
>=20
> I'd like to give my view on this.
>=20
> I support not changing anything in RFC8954.
>=20
> I recently started using the term "tweaking standards" for when you =
take
> an existing field in a standard and use it for other purposes than the
> one stated in the standard, just because it is technically possible =
and
> not explicitly forbidden in the standard. This has been done many =
times
> before, and many times it leads to interoperability issues, severe
> spending of time, money and resources, and in severe cases even =
downtime.
> Tweaking standards is a short term short-cut, ignoring long term =
costs.
>=20
> ISO 14533 clearly tweaked RFC6960 section 4.4.1.
>=20
> Many internet scale OCSP responders today do not include Nonce in the
> response. Regardless if the client sends it. This is for caching
> reasons, and is for both GET and POST requests.
>=20
> Using nonce as MessageImprint is non-interoperable with RFC6960 and =
with
> the real world.
>=20
> I'd like to say it again: ISO 14533 is non-interoperable with how OCSP
> is deployed on the internet today.
>=20
> It is a disaster waiting to happen. The reason it hasn't happened yet =
is
> likely due to ISO 14533 not being widely used. Let's fix it before it
> falls apart.
> The solution is not to force RFC6960 compliant OCSP responders into
> submission to ISO 14533, but to fix ISO 14533.
> ISO 14533 should recognize that the suggested solution is =
non-compliant,
> causing interoperability issues, and go back and create an extension.
> Yes, it's a little more work, and may result in a new RFC, or a
> replacement of RFC6960 (but the extension can be private to ISO 14533 =
to
> start with), but it's the right thing to do imho.
>=20
> There is already an extension, a bit similar to this, specified in the
> German Common PKI. https://de.wikipedia.org/wiki/Common_PKI
> It's called CertHash and can be copied. The specification isn't
> available any longer, but I have an off-line copy that I share here:
> https://app.box.com/s/lk1g4a3h75icirnu6xqrqhee8h5kmv54
>=20
> It's a SingleResponse extension, section 3.1.2:
>=20
> id-commonpki-at-certHash OBJECT IDENTIFIER ::=3D=3D {1 3 36 8 3 13}
>=20
> CertHash ::=3D SEQUENCE {
>  hashAlgorithm AlgorithmIdentifier, // The identifier of the algorithm
>                                     // that has been used the for hash
>                                     //value below.
>=20
>  certificateHash OCTET STRING // A hash over the DER-encoding of the
>                               // entire PKC or AC (i.e. NOT a hash
>                               // over tbsCertificate).
> }
>=20
> There are OCSP responders out there supporting the old CertHash =
extension.
>=20
> Not saying to use it "as is", it has another purpose, but very very
> similar. Just put a new OID and rename it to MessageImprint...
>=20
> Best regards,
> Tomas
>=20
>=20
> On 2020-12-21 17:36, Marian =C4=8Eurkovi=C4=8D wrote:
>> *On Sat, 19 Dec 2020 13:12:17 -0800, Mohit Sahni wrote*
>>> =46rom OCSP point of view the MessageImprint is not a random value =
but
>> it is a deterministic value generated for a given input by a =
collision
>> resistant one way hash function.
>>=20
>> This input, however, consists of multiple parts: some of them being
>> random, some of them being unknown even to document signer (private
>> key). In any case, an attacker is not able to guess this value so it
>> serves against reply attack very well.
>>=20
>>> One more reason I see for not changing the Nonce extension length is
>> that the length of MessageImprint is not fixed but varies based on =
the
>> underlying hash algorithm.  Since RFC3161 does not provide a fixed =
list
>> of Hash functions, let's say we change the size to Nonce extension to =
64
>> bytes, what if in the future there is a new hash algorithm or some
>> proprietary hash function that requires size to be 128 bytes or 256
>> bytes or may be 100 GigaBytes, are we going to increase the size of =
the
>> Nonce extension again?  How can we set an upper limit on Nonce which
>> also serves the regular Nonce use case of just avoiding the replay =
attacks ?
>>=20
>> I proposed 2 values: 96 bytes if we want to accomodate 512-bit =
hashes,
>> or 160 bytes, if we want to accomodate (future) 1024-bit hashes. Any
>> hashing algorithm is designed to yield a relatively small result, so
>> we're certainly not talking about GigaBytes here...
>>=20
>>> In my opinion, ISO 14533 took advantage of the security =
vulnerability
>> that existed in RFC6960 and tried using Nonce extension in a way it =
was
>> not intended to be used as i.e. using an ASN.1 SEQUENCE where the
>> standard requires use of OCTET STRING.
>>=20
>> OCTET STRING means arbitrary sequence of bytes, which OCSP responder
>> shouldn't interpret in any way - just echo them back in its response.
>> It's completely irrelevant, what's encoded inside - after all, a =
random
>> number could also start with 0x30 which corresponds to SEQUENCE.
>>=20
>>> We should come up with a new extension for associating the OCSP
>> response with the context where OCSP is being used for long term
>> validation. That is the right thing to do.
>>=20
>> And what will be the advantage of having yet another extension doing =
the
>> same thing? Both use cases require nothing else from OCSP responder =
than
>> to echo back exactly the same bytes it received in request. Do you
>> propose to have 2 extensions, one of them being able to only echo 32
>> bytes and another being able to echo 96? or 160? or unlimited bytes?
>> Isn't it much more straightforward to have only one "echoing" =
extension
>> being able to echo as many bytes as needed for both use cases?
>>=20
>> On the other hand, the disadvantages are significant - I mentioned =
some
>> of them in my previous email. Also please keep in mind, that RFC 8954
>> (if applied by OCSP responder or by some firewall doing deep packet
>> inspection) will immediately break digital signing - since it says:
>>=20
>>   A server *MUST* reject any OCSP request that has a nonce in the =
Nonce
>>   extension with a length of either 0 octets or more than 32 octets
>>   with the malformedRequest OCSPResponseStatus
>>=20
>> Last but not least, introducing another extension is more complex =
than
>> you assume - it will require modification of (at least) RFC6960,
>> RFC5019, ISO 14533-4. When will that solution be available and what =
to
>> do until then?
>>=20
>> With kind regards,
>> MD
>>=20
>>=20
>>=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 23 08:09:31 2020
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 05A033A0BDB for ; Wed, 23 Dec 2020 08:09:29 -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, NICE_REPLY_A=-0.001, 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=cs.tcd.ie
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 CzrUU5xJKAXZ for ; Wed, 23 Dec 2020 08:09:26 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F00F3A0BDE for ; Wed, 23 Dec 2020 08:09:25 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0785DBE2E; Wed, 23 Dec 2020 16:09:24 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmw6GzeBopKq; Wed, 23 Dec 2020 16:09:21 +0000 (GMT)
Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 066E7BE2C; Wed, 23 Dec 2020 16:09:21 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1608739761; bh=eq/un/Z5+IBx0PcHY8brE4NsWc76xH7thkRcpZ9szoo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=CibTs/2h2ESqbNWfcoxxKKVBhaaHcHriMUJCVt/A1depUKvOMkIOTG0ZCKsC6QQ8o Af+kkZSBJ4mGd6nCzu8s2C+Bsai1qeSQNEph6X4I93OijvcWQOVMBkPWwQnzRY7iL+ mb81I5aoXdi5o8DsVLhPALyCFkILF/cCj2AYoL/0=
To: Russ Housley , IAB 
Cc: LAMPS 
References: <20201218103651.M76302@bts.sk>    <7E92C4FB-4118-470A-8BA4-BEA133FA46AF@akamai.com> <20201218224153.M14899@bts.sk>  <20201218230753.M63543@bts.sk>  <20201219085409.M21922@bts.sk>  <20201219121104.M37970@bts.sk>  <20201221155837.M1893@bts.sk>  
From: Stephen Farrell 
Message-ID: 
Date: Wed, 23 Dec 2020 16:09:19 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dgipD5EB7HGOr4WVSIvED14FBvYFngYAl"
Archived-At: 
Subject: Re: [lamps] Conflict between RFC8954 and ISO 14533-4
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2020 16:09:29 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--dgipD5EB7HGOr4WVSIvED14FBvYFngYAl
Content-Type: multipart/mixed; boundary="NOV9m9iWVQQHRRtCwsK5YxeaaSPa8PQYf";
 protected-headers="v1"
From: Stephen Farrell 
To: Russ Housley , IAB 
Cc: LAMPS 
Message-ID: 
Subject: Re: [lamps] Conflict between RFC8954 and ISO 14533-4
References: <20201218103651.M76302@bts.sk>
 
 
 
 <7E92C4FB-4118-470A-8BA4-BEA133FA46AF@akamai.com>
 <20201218224153.M14899@bts.sk>
 
 <20201218230753.M63543@bts.sk>
 
 <20201219085409.M21922@bts.sk>
 
 <20201219121104.M37970@bts.sk>
 
 <20201221155837.M1893@bts.sk>
 
 
In-Reply-To: 

--NOV9m9iWVQQHRRtCwsK5YxeaaSPa8PQYf
Content-Type: multipart/mixed;
 boundary="------------E690125FB92BB539C71F5336"
Content-Language: en-US

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


Hi Russ,

On 23/12/2020 15:41, Russ Housley wrote:
> Dear  IAB:
>=20
> The IETF does not have a liaison relationship with the ISO TC that
> produced ISO 14533-4:2019.  It would be a good think to tell that
> group that we disagree with the approach that was taken.  What does
> the IAB suggest?

I've not followed this discussion, nor am I at all familiar
with that ISO spec, so I'd have to get up to speed before I'd
have an informed opinion.

Does anyone know someone involved with that ISO group/spec?
If so, I'd say trying to see if it can be sorted out at that
level would be good (if it's not happened already).

If there's no good contact available then yeah I guess the
IAB might try find a way to send a message to ISO. First up
though might be for lamps to craft the message to be sent
(including enough background that IAB and ISO folks will get
the point). I'd be happy to bring such a message to the IAB
and ask that we figure out how to get it sent to the right
place/people.

Cheers,
S.

PS: The above is clearly just me speaking, and isn't the
consensus of the IAB:-)

>=20
> Russ
>=20
>> On Dec 23, 2020, at 2:40 AM, Tomas Gustavsson
>>  wrote:
>>=20
>>=20
>> Hi,
>>=20
>> I'd like to give my view on this.
>>=20
>> I support not changing anything in RFC8954.
>>=20
>> I recently started using the term "tweaking standards" for when you
>> take an existing field in a standard and use it for other purposes
>> than the one stated in the standard, just because it is technically
>> possible and not explicitly forbidden in the standard. This has
>> been done many times before, and many times it leads to
>> interoperability issues, severe spending of time, money and
>> resources, and in severe cases even downtime. Tweaking standards is
>> a short term short-cut, ignoring long term costs.
>>=20
>> ISO 14533 clearly tweaked RFC6960 section 4.4.1.
>>=20
>> Many internet scale OCSP responders today do not include Nonce in
>> the response. Regardless if the client sends it. This is for
>> caching reasons, and is for both GET and POST requests.
>>=20
>> Using nonce as MessageImprint is non-interoperable with RFC6960 and
>> with the real world.
>>=20
>> I'd like to say it again: ISO 14533 is non-interoperable with how
>> OCSP is deployed on the internet today.
>>=20
>> It is a disaster waiting to happen. The reason it hasn't happened
>> yet is likely due to ISO 14533 not being widely used. Let's fix it
>> before it falls apart. The solution is not to force RFC6960
>> compliant OCSP responders into submission to ISO 14533, but to fix
>> ISO 14533. ISO 14533 should recognize that the suggested solution
>> is non-compliant, causing interoperability issues, and go back and
>> create an extension. Yes, it's a little more work, and may result
>> in a new RFC, or a replacement of RFC6960 (but the extension can be
>> private to ISO 14533 to start with), but it's the right thing to do
>> imho.
>>=20
>> There is already an extension, a bit similar to this, specified in
>> the German Common PKI. https://de.wikipedia.org/wiki/Common_PKI=20
>> It's called CertHash and can be copied. The specification isn't=20
>> available any longer, but I have an off-line copy that I share
>> here: https://app.box.com/s/lk1g4a3h75icirnu6xqrqhee8h5kmv54
>>=20
>> It's a SingleResponse extension, section 3.1.2:
>>=20
>> id-commonpki-at-certHash OBJECT IDENTIFIER ::=3D=3D {1 3 36 8 3 13}
>>=20
>> CertHash ::=3D SEQUENCE { hashAlgorithm AlgorithmIdentifier, // The
>> identifier of the algorithm // that has been used the for hash=20
>> //value below.
>>=20
>> certificateHash OCTET STRING // A hash over the DER-encoding of
>> the // entire PKC or AC (i.e. NOT a hash // over tbsCertificate).=20
>> }
>>=20
>> There are OCSP responders out there supporting the old CertHash
>> extension.
>>=20
>> Not saying to use it "as is", it has another purpose, but very
>> very similar. Just put a new OID and rename it to
>> MessageImprint...
>>=20
>> Best regards, Tomas
>>=20
>>=20
>> On 2020-12-21 17:36, Marian =C4=8Eurkovi=C4=8D wrote:
>>> *On Sat, 19 Dec 2020 13:12:17 -0800, Mohit Sahni wrote*
>>>> From OCSP point of view the MessageImprint is not a random
>>>> value but
>>> it is a deterministic value generated for a given input by a
>>> collision resistant one way hash function.
>>>=20
>>> This input, however, consists of multiple parts: some of them
>>> being random, some of them being unknown even to document signer
>>> (private key). In any case, an attacker is not able to guess this
>>> value so it serves against reply attack very well.
>>>=20
>>>> One more reason I see for not changing the Nonce extension
>>>> length is
>>> that the length of MessageImprint is not fixed but varies based
>>> on the underlying hash algorithm.  Since RFC3161 does not provide
>>> a fixed list of Hash functions, let's say we change the size to
>>> Nonce extension to 64 bytes, what if in the future there is a new
>>> hash algorithm or some proprietary hash function that requires
>>> size to be 128 bytes or 256 bytes or may be 100 GigaBytes, are we
>>> going to increase the size of the Nonce extension again?  How can
>>> we set an upper limit on Nonce which also serves the regular
>>> Nonce use case of just avoiding the replay attacks ?
>>>=20
>>> I proposed 2 values: 96 bytes if we want to accomodate 512-bit
>>> hashes, or 160 bytes, if we want to accomodate (future) 1024-bit
>>> hashes. Any hashing algorithm is designed to yield a relatively
>>> small result, so we're certainly not talking about GigaBytes
>>> here...
>>>=20
>>>> In my opinion, ISO 14533 took advantage of the security
>>>> vulnerability
>>> that existed in RFC6960 and tried using Nonce extension in a way
>>> it was not intended to be used as i.e. using an ASN.1 SEQUENCE
>>> where the standard requires use of OCTET STRING.
>>>=20
>>> OCTET STRING means arbitrary sequence of bytes, which OCSP
>>> responder shouldn't interpret in any way - just echo them back in
>>> its response. It's completely irrelevant, what's encoded inside -
>>> after all, a random number could also start with 0x30 which
>>> corresponds to SEQUENCE.
>>>=20
>>>> We should come up with a new extension for associating the
>>>> OCSP
>>> response with the context where OCSP is being used for long term=20
>>> validation. That is the right thing to do.
>>>=20
>>> And what will be the advantage of having yet another extension
>>> doing the same thing? Both use cases require nothing else from
>>> OCSP responder than to echo back exactly the same bytes it
>>> received in request. Do you propose to have 2 extensions, one of
>>> them being able to only echo 32 bytes and another being able to
>>> echo 96? or 160? or unlimited bytes? Isn't it much more
>>> straightforward to have only one "echoing" extension being able
>>> to echo as many bytes as needed for both use cases?
>>>=20
>>> On the other hand, the disadvantages are significant - I
>>> mentioned some of them in my previous email. Also please keep in
>>> mind, that RFC 8954 (if applied by OCSP responder or by some
>>> firewall doing deep packet inspection) will immediately break
>>> digital signing - since it says:
>>>=20
>>> A server *MUST* reject any OCSP request that has a nonce in the
>>> Nonce extension with a length of either 0 octets or more than 32
>>> octets with the malformedRequest OCSPResponseStatus
>>>=20
>>> Last but not least, introducing another extension is more complex
>>> than you assume - it will require modification of (at least)
>>> RFC6960, RFC5019, ISO 14533-4. When will that solution be
>>> available and what to do until then?
>>>=20
>>> With kind regards, MD
>>>=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________ Spasm mailing
>>> list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm
>>>=20
>>=20
>> _______________________________________________ Spasm mailing list=20
>> Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm
>=20
> _______________________________________________ Spasm mailing list=20
> Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm
>=20

--------------E690125FB92BB539C71F5336
Content-Type: application/pgp-keys;
 name="OpenPGP_0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="OpenPGP_0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5=
Cg8
gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq=
978
CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu=
D/Q
9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4=
tNn
cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB=
wV+
4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir=
1GC
YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav=
ACY
Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D=
VQu
8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER=
8la
5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE=
wEI
ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC=
xAA
pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX=
Az9
+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL=
F+X
+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4=
g1U
QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre=
k3U
P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2=
niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL=
4Nw
tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m=
6vt
ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7=
+8A
CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ=
LvC
wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8=
rpK
o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr=
qJs
CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa=
W/r
KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG=
gMW
rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u=
rqR
1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/=
0A9
J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc=
JBD
EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4=
vrp
2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA=
xvK
dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK=
xlf
tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg=
Uky
o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO=
aHv
X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp=
yyz
JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ=
uLE
FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w=
sDc
BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer=
3UM
TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP=
jt5
uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK=
171
RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR=
Lpg
RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov=
wza
tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0=
zG3
6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ=
eah
r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ=
GNz
LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o=
3cC
GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo=
w5o
DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h=
Rcs
RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC=
Y98
iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd=
h2k
4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4=
EIk
CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ=
DIJ
pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4=
tvy
a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4=
ul3
qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc=
G9g
ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt=
w/r
1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ=
Jaf
3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1=
4Q0
7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf=
qtu
Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C=
gHw
26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC=
wIE
FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL=
rfb
e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF=
etu
O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8=
v39
+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr=
1oD
3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr=
m2D
Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby=
y/A
UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO=
jao
P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz=
leL
Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC=
2X4
pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g=
1MS
BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34=
YT0
auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb=
edD
Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3=
1qG
/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV=
YW6
R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg=
4Im
VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm=
qyH
eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx=
qnk
SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ=
Esc
YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n=
2Hw
xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F=
eIY
jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E=
AuF
CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4=
2AY
R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH=
X5v
aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q=
Csw
Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq=
yA4
3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m=
Eer
0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI=
Dxz
dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC=
QgH
AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ=
i0B
igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn=
i9g
OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy=
sIg
pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n=
66v
xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/=
3r2
BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM=
YtU
N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr=
5iW
XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/=
zek
ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b=
a0H
Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP=
Ic2
gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6=
XE6
i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1=
16u
/HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J=
G9a
SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW=
OMq
N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz=
0YO
K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4=
vYl
zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx=
nNb
KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+=
5HN
HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq=
4hn
l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn=
Zbg
JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d=
nJj
j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8=
WLI
aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc=
dPC
Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX=
o4+
Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO=
Tyk
rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9=
hZM
0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5=
P3f
WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp=
cL2
lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk=
etP
GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3=
zRq
k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0=
20q
pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U=
DIB
EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x=
/nL
PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE=
hOV
fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D=
VI9
DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT=
uW/
eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD=
aWT
3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6=
1df
mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8=
MAv
2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA=
HZR
5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo=
qj1
gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6=
Mas
qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi=
RkM
dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB=
++/
KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX=
xMD
rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf=
ZtA
ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN=
2OE
0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT=
zcS
oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7=
IKP
3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW=
Iys
s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST
=3D40Nd
-----END PGP PUBLIC KEY BLOCK-----

--------------E690125FB92BB539C71F5336--

--NOV9m9iWVQQHRRtCwsK5YxeaaSPa8PQYf--

--dgipD5EB7HGOr4WVSIvED14FBvYFngYAl
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl/ja68FAwAAAAAACgkQWrL68XsXK+oO
KA/8Dz/Ee/twrb4eWWNYxoLBFjUiQ3evB51VbJ8Q9c35j/gW/e1B6mnnPwC9X0U/yG6vnEnr5tw3
PrgXyziom0aYfETGiPq9zSnAdghkgXztUV8D31XfMkxN9sKz4Pn5qs0HTFfd7xmGQG71MG5Okb9j
wH7Ht41XOArfTVLLNcsse8GWr0Ttaq27dT1WySMyvS0sbgpZa2Ae+tYNoTkqx7fASi2sU9jtUlZ6
tYyzKFkCqGaNKAACKHExKsYBSdJ0eYVuNs07eYtlAcf7TczVYH5hxKfh1clHD6sC2kSL3Htrz3Io
Ce5/b3Usb3hsK8klij3A3wdyPspu7qnq2PmL90in/dfS3NvySZ7wJabSnJeSoLMCZZqgFtWjwQ9L
6ou7gX9sJLYtsmdrvRbKaXgODUiYukRuIVE5UvL7w0pAjRs7NggkHs7XnAnB0V8yUR66zUAN/1Ca
hlqCJLAY5zkG9qFarzgQAl49CALN5+1bUbNuTQOsz370GwwpJW8dDCszKmTmxcayVXVMnmrUG22K
h35Cy/eRZaj622McFdn5sYMNVnTNVcqO4Tgpza1vklNNg9Bk/WIPXhpdF1mXePUTkSddYDatFD54
chHBuK6EG6DTPRqWma9CWJ3gjJFfatHSZVbDPuZzMUw0H5Pq7FACo6x8LR127LSyJDKf7eedmvgT
jNM=
=0kW7
-----END PGP SIGNATURE-----

--dgipD5EB7HGOr4WVSIvED14FBvYFngYAl--


From nobody Wed Dec 23 08:21:12 2020
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 2E2513A0BF2 for ; Wed, 23 Dec 2020 08:21:11 -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, 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 DFCHCCKiVVC0 for ; Wed, 23 Dec 2020 08:21:07 -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 46FAA3A0BF8 for ; Wed, 23 Dec 2020 08:20:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CB197300BBC for ; Wed, 23 Dec 2020 11:20:50 -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 CMM5Cf7XUUsd for ; Wed, 23 Dec 2020 11:20:46 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 93F22300ADB; Wed, 23 Dec 2020 11:20:46 -0500 (EST)
From: Russ Housley 
Message-Id: <52B573D6-5DB4-41DA-95F1-20C3EB5EEAC0@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AB39240E-0F81-4E61-A2A6-A947FE5A3F09"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Wed, 23 Dec 2020 11:20:47 -0500
In-Reply-To: 
Cc: IAB , LAMPS 
To: Stephen Farrell 
References: <20201218103651.M76302@bts.sk>    <7E92C4FB-4118-470A-8BA4-BEA133FA46AF@akamai.com> <20201218224153.M14899@bts.sk>  <20201218230753.M63543@bts.sk>  <20201219085409.M21922@bts.sk>  <20201219121104.M37970@bts.sk>  <20201221155837.M1893@bts.sk>   
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] Conflict between RFC8954 and ISO 14533-4
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2020 16:21:11 -0000

--Apple-Mail=_AB39240E-0F81-4E61-A2A6-A947FE5A3F09
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Marian =C4=8Eurkovi=C4=8D  brought it to the attention of the =
LAMPS WG.  That was a message out of the blue from my perspective.

Russ



> On Dec 23, 2020, at 11:09 AM, Stephen Farrell =
 wrote:
>=20
> Signed PGP part
>=20
> Hi Russ,
>=20
> On 23/12/2020 15:41, Russ Housley wrote:
>> Dear  IAB:
>> The IETF does not have a liaison relationship with the ISO TC that
>> produced ISO 14533-4:2019.  It would be a good think to tell that
>> group that we disagree with the approach that was taken.  What does
>> the IAB suggest?
>=20
> I've not followed this discussion, nor am I at all familiar
> with that ISO spec, so I'd have to get up to speed before I'd
> have an informed opinion.
>=20
> Does anyone know someone involved with that ISO group/spec?
> If so, I'd say trying to see if it can be sorted out at that
> level would be good (if it's not happened already).
>=20
> If there's no good contact available then yeah I guess the
> IAB might try find a way to send a message to ISO. First up
> though might be for lamps to craft the message to be sent
> (including enough background that IAB and ISO folks will get
> the point). I'd be happy to bring such a message to the IAB
> and ask that we figure out how to get it sent to the right
> place/people.
>=20
> Cheers,
> S.
>=20
> PS: The above is clearly just me speaking, and isn't the
> consensus of the IAB:-)
>=20
>> Russ
>>> On Dec 23, 2020, at 2:40 AM, Tomas Gustavsson
>>>  wrote:
>>> Hi,
>>> I'd like to give my view on this.
>>> I support not changing anything in RFC8954.
>>> I recently started using the term "tweaking standards" for when you
>>> take an existing field in a standard and use it for other purposes
>>> than the one stated in the standard, just because it is technically
>>> possible and not explicitly forbidden in the standard. This has
>>> been done many times before, and many times it leads to
>>> interoperability issues, severe spending of time, money and
>>> resources, and in severe cases even downtime. Tweaking standards is
>>> a short term short-cut, ignoring long term costs.
>>> ISO 14533 clearly tweaked RFC6960 section 4.4.1.
>>> Many internet scale OCSP responders today do not include Nonce in
>>> the response. Regardless if the client sends it. This is for
>>> caching reasons, and is for both GET and POST requests.
>>> Using nonce as MessageImprint is non-interoperable with RFC6960 and
>>> with the real world.
>>> I'd like to say it again: ISO 14533 is non-interoperable with how
>>> OCSP is deployed on the internet today.
>>> It is a disaster waiting to happen. The reason it hasn't happened
>>> yet is likely due to ISO 14533 not being widely used. Let's fix it
>>> before it falls apart. The solution is not to force RFC6960
>>> compliant OCSP responders into submission to ISO 14533, but to fix
>>> ISO 14533. ISO 14533 should recognize that the suggested solution
>>> is non-compliant, causing interoperability issues, and go back and
>>> create an extension. Yes, it's a little more work, and may result
>>> in a new RFC, or a replacement of RFC6960 (but the extension can be
>>> private to ISO 14533 to start with), but it's the right thing to do
>>> imho.
>>> There is already an extension, a bit similar to this, specified in
>>> the German Common PKI. https://de.wikipedia.org/wiki/Common_PKI It's =
called CertHash and can be copied. The specification isn't available any =
longer, but I have an off-line copy that I share
>>> here: https://app.box.com/s/lk1g4a3h75icirnu6xqrqhee8h5kmv54
>>> It's a SingleResponse extension, section 3.1.2:
>>> id-commonpki-at-certHash OBJECT IDENTIFIER ::=3D=3D {1 3 36 8 3 13}
>>> CertHash ::=3D SEQUENCE { hashAlgorithm AlgorithmIdentifier, // The
>>> identifier of the algorithm // that has been used the for hash =
//value below.
>>> certificateHash OCTET STRING // A hash over the DER-encoding of
>>> the // entire PKC or AC (i.e. NOT a hash // over tbsCertificate). }
>>> There are OCSP responders out there supporting the old CertHash
>>> extension.
>>> Not saying to use it "as is", it has another purpose, but very
>>> very similar. Just put a new OID and rename it to
>>> MessageImprint...
>>> Best regards, Tomas
>>> On 2020-12-21 17:36, Marian =C4=8Eurkovi=C4=8D wrote:
>>>> *On Sat, 19 Dec 2020 13:12:17 -0800, Mohit Sahni wrote*
>>>>> =46rom OCSP point of view the MessageImprint is not a random
>>>>> value but
>>>> it is a deterministic value generated for a given input by a
>>>> collision resistant one way hash function.
>>>> This input, however, consists of multiple parts: some of them
>>>> being random, some of them being unknown even to document signer
>>>> (private key). In any case, an attacker is not able to guess this
>>>> value so it serves against reply attack very well.
>>>>> One more reason I see for not changing the Nonce extension
>>>>> length is
>>>> that the length of MessageImprint is not fixed but varies based
>>>> on the underlying hash algorithm.  Since RFC3161 does not provide
>>>> a fixed list of Hash functions, let's say we change the size to
>>>> Nonce extension to 64 bytes, what if in the future there is a new
>>>> hash algorithm or some proprietary hash function that requires
>>>> size to be 128 bytes or 256 bytes or may be 100 GigaBytes, are we
>>>> going to increase the size of the Nonce extension again?  How can
>>>> we set an upper limit on Nonce which also serves the regular
>>>> Nonce use case of just avoiding the replay attacks ?
>>>> I proposed 2 values: 96 bytes if we want to accomodate 512-bit
>>>> hashes, or 160 bytes, if we want to accomodate (future) 1024-bit
>>>> hashes. Any hashing algorithm is designed to yield a relatively
>>>> small result, so we're certainly not talking about GigaBytes
>>>> here...
>>>>> In my opinion, ISO 14533 took advantage of the security
>>>>> vulnerability
>>>> that existed in RFC6960 and tried using Nonce extension in a way
>>>> it was not intended to be used as i.e. using an ASN.1 SEQUENCE
>>>> where the standard requires use of OCTET STRING.
>>>> OCTET STRING means arbitrary sequence of bytes, which OCSP
>>>> responder shouldn't interpret in any way - just echo them back in
>>>> its response. It's completely irrelevant, what's encoded inside -
>>>> after all, a random number could also start with 0x30 which
>>>> corresponds to SEQUENCE.
>>>>> We should come up with a new extension for associating the
>>>>> OCSP
>>>> response with the context where OCSP is being used for long term =
validation. That is the right thing to do.
>>>> And what will be the advantage of having yet another extension
>>>> doing the same thing? Both use cases require nothing else from
>>>> OCSP responder than to echo back exactly the same bytes it
>>>> received in request. Do you propose to have 2 extensions, one of
>>>> them being able to only echo 32 bytes and another being able to
>>>> echo 96? or 160? or unlimited bytes? Isn't it much more
>>>> straightforward to have only one "echoing" extension being able
>>>> to echo as many bytes as needed for both use cases?
>>>> On the other hand, the disadvantages are significant - I
>>>> mentioned some of them in my previous email. Also please keep in
>>>> mind, that RFC 8954 (if applied by OCSP responder or by some
>>>> firewall doing deep packet inspection) will immediately break
>>>> digital signing - since it says:
>>>> A server *MUST* reject any OCSP request that has a nonce in the
>>>> Nonce extension with a length of either 0 octets or more than 32
>>>> octets with the malformedRequest OCSPResponseStatus
>>>> Last but not least, introducing another extension is more complex
>>>> than you assume - it will require modification of (at least)
>>>> RFC6960, RFC5019, ISO 14533-4. When will that solution be
>>>> available and what to do until then?
>>>> With kind regards, MD
>>>> _______________________________________________ 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
>> _______________________________________________ Spasm mailing list =
Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm
> 
>=20
>=20


--Apple-Mail=_AB39240E-0F81-4E61-A2A6-A947FE5A3F09
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Marian =C4=8Eurkovi=C4=8D <md@bts.sk> brought it to the =
attention of the LAMPS WG.  That was a message out of the blue from =
my perspective.
Russ



On Dec 23, 2020, at 11:09 AM, Stephen Farrell =
<stephen.farrell@cs.tcd.ie> wrote:

Signed PGP =
part

Hi Russ,

On 23/12/2020 15:41, Russ Housley wrote:
Dear  IAB:
The IETF does not have a liaison relationship with the ISO TC =
that
produced ISO 14533-4:2019.  It would be a good =
think to tell that
group that we disagree with the =
approach that was taken.  What does
the IAB =
suggest?

I've not followed =
this discussion, nor am I at all familiar
with that ISO =
spec, so I'd have to get up to speed before I'd
have an =
informed opinion.

Does anyone know someone =
involved with that ISO group/spec?
If so, I'd say trying =
to see if it can be sorted out at that
level would be good =
(if it's not happened already).

If there's =
no good contact available then yeah I guess the
IAB might =
try find a way to send a message to ISO. First up
though =
might be for lamps to craft the message to be sent
(including enough background that IAB and ISO folks will =
get
the point). I'd be happy to bring such a message to =
the IAB
and ask that we figure out how to get it sent to =
the right
place/people.

Cheers,
S.

PS: The =
above is clearly just me speaking, and isn't the
consensus =
of the IAB:-)

Russ
On =
Dec 23, 2020, at 2:40 AM, Tomas Gustavsson
<tomas.gustavsson@primekey.com> wrote:
Hi,
I'd like to give my view on this.
I support not changing anything in RFC8954.
I =
recently started using the term "tweaking standards" for when you
take an existing field in a standard and use it for other =
purposes
than the one stated in the standard, just because =
it is technically
possible and not explicitly forbidden in =
the standard. This has
been done many times before, and =
many times it leads to
interoperability issues, severe =
spending of time, money and
resources, and in severe cases =
even downtime. Tweaking standards is
a short term =
short-cut, ignoring long term costs.
ISO 14533 clearly =
tweaked RFC6960 section 4.4.1.
Many internet scale OCSP =
responders today do not include Nonce in
the response. =
Regardless if the client sends it. This is for
caching =
reasons, and is for both GET and POST requests.
Using =
nonce as MessageImprint is non-interoperable with RFC6960 and
with the real world.
I'd like to say it again: =
ISO 14533 is non-interoperable with how
OCSP is deployed =
on the internet today.
It is a disaster waiting to happen. =
The reason it hasn't happened
yet is likely due to ISO =
14533 not being widely used. Let's fix it
before it falls =
apart. The solution is not to force RFC6960
compliant OCSP =
responders into submission to ISO 14533, but to fix
ISO =
14533. ISO 14533 should recognize that the suggested solution
is non-compliant, causing interoperability issues, and go =
back and
create an extension. Yes, it's a little more =
work, and may result
in a new RFC, or a replacement of =
RFC6960 (but the extension can be
private to ISO 14533 to =
start with), but it's the right thing to do
imho.
There is already an extension, a bit similar to this, =
specified in
the German Common PKI. https://de.wikipedia.org/wiki/Common_PKI It's called =
CertHash and can be copied. The specification isn't available any =
longer, but I have an off-line copy that I share
here: https://app.box.com/s/lk1g4a3h75icirnu6xqrqhee8h5kmv54
It's a SingleResponse extension, section 3.1.2:
id-commonpki-at-certHash OBJECT IDENTIFIER ::=3D=3D {1 3 36 8 =
3 13}
CertHash ::=3D SEQUENCE { hashAlgorithm =
AlgorithmIdentifier, // The
identifier of the algorithm // =
that has been used the for hash //value below.
certificateHash OCTET STRING // A hash over the DER-encoding =
of
the // entire PKC or AC (i.e. NOT a hash // over =
tbsCertificate). }
There are OCSP responders out there =
supporting the old CertHash
extension.
Not =
saying to use it "as is", it has another purpose, but very
very similar. Just put a new OID and rename it to
MessageImprint...
Best regards, Tomas
On 2020-12-21 17:36, Marian =C4=8Eurkovi=C4=8D wrote:
*On Sat, 19 Dec 2020 =
13:12:17 -0800, Mohit Sahni wrote*
=46rom OCSP point of view the MessageImprint is not a =
random
value but
it is a =
deterministic value generated for a given input by a
collision resistant one way hash function.
This =
input, however, consists of multiple parts: some of them
being random, some of them being unknown even to document =
signer
(private key). In any case, an attacker is not able =
to guess this
value so it serves against reply attack very =
well.
One more reason =
I see for not changing the Nonce extension
length is
that the length of MessageImprint is not fixed =
but varies based
on the underlying hash algorithm. =
 Since RFC3161 does not provide
a fixed list of Hash =
functions, let's say we change the size to
Nonce extension =
to 64 bytes, what if in the future there is a new
hash =
algorithm or some proprietary hash function that requires
size to be 128 bytes or 256 bytes or may be 100 GigaBytes, =
are we
going to increase the size of the Nonce extension =
again?  How can
we set an upper limit on Nonce which =
also serves the regular
Nonce use case of just avoiding =
the replay attacks ?
I proposed 2 values: 96 bytes if we =
want to accomodate 512-bit
hashes, or 160 bytes, if we =
want to accomodate (future) 1024-bit
hashes. Any hashing =
algorithm is designed to yield a relatively
small result, =
so we're certainly not talking about GigaBytes
here...
In my opinion, ISO 14533 =
took advantage of the security
vulnerability
that existed in RFC6960 and tried using Nonce =
extension in a way
it was not intended to be used as i.e. =
using an ASN.1 SEQUENCE
where the standard requires use of =
OCTET STRING.
OCTET STRING means arbitrary sequence of =
bytes, which OCSP
responder shouldn't interpret in any way =
- just echo them back in
its response. It's completely =
irrelevant, what's encoded inside -
after all, a random =
number could also start with 0x30 which
corresponds to =
SEQUENCE.
We should =
come up with a new extension for associating the
OCSP
response with the context where OCSP is being =
used for long term validation. That is the right thing to do.
And what will be the advantage of having yet another =
extension
doing the same thing? Both use cases require =
nothing else from
OCSP responder than to echo back exactly =
the same bytes it
received in request. Do you propose to =
have 2 extensions, one of
them being able to only echo 32 =
bytes and another being able to
echo 96? or 160? or =
unlimited bytes? Isn't it much more
straightforward to =
have only one "echoing" extension being able
to echo as =
many bytes as needed for both use cases?
On the other =
hand, the disadvantages are significant - I
mentioned some =
of them in my previous email. Also please keep in
mind, =
that RFC 8954 (if applied by OCSP responder or by some
firewall doing deep packet inspection) will immediately =
break
digital signing - since it says:
A =
server *MUST* reject any OCSP request that has a nonce in the
Nonce extension with a length of either 0 octets or more than =
32
octets with the malformedRequest OCSPResponseStatus
Last but not least, introducing another extension is more =
complex
than you assume - it will require modification of =
(at least)
RFC6960, RFC5019, ISO 14533-4. When will that =
solution be
available and what to do until then?
With kind regards, MD
_______________________________________________ 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
_______________________________________________ =
Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm
<OpenP=
GP_0x5AB2FAF17B172BEA.asc>


=

--Apple-Mail=_AB39240E-0F81-4E61-A2A6-A947FE5A3F09--


From nobody Wed Dec 23 08:35:22 2020
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 D93963A0C16 for ; Wed, 23 Dec 2020 08:35:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 pVTYrUDMSaGX for ; Wed, 23 Dec 2020 08:35:18 -0800 (PST)
Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 659EF3A0C13 for ; Wed, 23 Dec 2020 08:35:18 -0800 (PST)
Received: by mail-qv1-xf33.google.com with SMTP id l7so19165qvt.4 for ; Wed, 23 Dec 2020 08:35:18 -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=VPPJRh6bG1UKNSmWIieXq+oSa8Z9VY0t5v4poXbHYEY=; b=Dk1pKL39DjpOqXkn6PFb99pKYSHfPXrFhTmyDa6gI4v02x461SKll41z3OZpPeiWiE PkBELnSyBcOo+nOpjvOYwgD+m3D4yN7W2d4Jujxz1QJHqfpxYM2jU6nWCnrasZT61m/j kRYmMhIMqzQPGhNBSRrImdnVsQk+bOgMOb9I0=
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=VPPJRh6bG1UKNSmWIieXq+oSa8Z9VY0t5v4poXbHYEY=; b=KP9r9rKzbV7UnFO9hgaPgG4CQk+LO0T9MH/hDenMsDEPTKB0gkawkf7WtP3vUmwCJI OfSgpBAof4P3g51c+AXEswllRzwZytFPpbMXOGJQfp0Lf7TqOAEINi3HOBvgrs6Jsu15 BrdEB9fNCC2JysUI3pkoDFK8nQrtp/wc7+pGOoDkoPl9KxC4Wb9SH/c6501Bkytt3sTE HAVIctsx96E10V7so0NiTeShYklwX+X3wXyX8p7LYOLQ2mxuQjC3ScBe4fZ+sDkQVK/C tXYkFLrB3lTcAsN4aOdTB0Ax9iVof8VuELIMCtnlq9CHhmhgz+r66Ao6t4oSz/1lRnbt ciCw==
X-Gm-Message-State: AOAM533YpbaFti0FCp5T7KgcQe/Yq5jzEwbRkoGqj5rLNnVbwbFT4gxy vmSM6Po6VyygGJJVKI5uA1TFK+eAeAakqw==
X-Google-Smtp-Source: ABdhPJxVFxNk2f4iykDJyrfkIIHbmzyMtOo12KRkEWRR6C3d5Il8QA/lKiZzLG7Yw5/Vr92vLdsWkQ==
X-Received: by 2002:a05:6214:b82:: with SMTP id fe2mr27834985qvb.3.1608741317200;  Wed, 23 Dec 2020 08:35:17 -0800 (PST)
Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id m8sm7951037qkh.21.2020.12.23.08.35.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Dec 2020 08:35:16 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Sean Turner 
In-Reply-To: 
Date: Wed, 23 Dec 2020 11:35:15 -0500
Cc: LAMPS 
Content-Transfer-Encoding: quoted-printable
Message-Id: <17C5AA81-30C1-48BD-A919-1D0F78C936C5@sn3rd.com>
References:  
To: Tim Hollebeek 
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: 
Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2020 16:35:20 -0000

IANAC, but I did have a read of this draft and thought it looked like a =
fine candidate for progressing to the next stage.

Minor nit that could be addressed later:

To be all matchy-matchy with the last paragraph in s3.1 you could
s/nonce parameter/nonce parameter field
in the penultimate paragraph of s3.1.

spt

> On Dec 22, 2020, at 16:47, Tim Hollebeek =
 wrote:
>=20
> The comment period has ended, and no new feedback was received.  =
I=E2=80=99ll start pushing this forward.
> =20
> -Tim
> =20
> From: Spasm  On Behalf Of Tim Hollebeek
> Sent: Friday, December 4, 2020 4:17 PM
> To: LAMPS 
> Subject: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
> =20
> This is the LAMPS WG Last Call for "Using the AES-GMAC Algorithm with =
the Cryptographic Message Syntax (CMS)=E2=80=9D =
.  Please review the document and =
send your comments to the list by 18 December 2020.
> =20
> The datatracker page for the document is =
https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-aes-gmac-alg/
> =20
> -Tim
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


From nobody Wed Dec 23 09:12:27 2020
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 A44B13A0E6B for ; Wed, 23 Dec 2020 09:12:26 -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, 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 E9fqudMvjzDB for ; Wed, 23 Dec 2020 09:12:24 -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 215583A0E67 for ; Wed, 23 Dec 2020 09:12:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 894D9300BBC for ; Wed, 23 Dec 2020 12:12:21 -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 9S8NKjZN1pyg for ; Wed, 23 Dec 2020 12:12:19 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id CD62C300ADC; Wed, 23 Dec 2020 12:12:19 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Russ Housley 
In-Reply-To: <17C5AA81-30C1-48BD-A919-1D0F78C936C5@sn3rd.com>
Date: Wed, 23 Dec 2020 12:12:20 -0500
Cc: LAMPS 
Content-Transfer-Encoding: quoted-printable
Message-Id: <50CE7489-C6DD-45A9-8B5A-2B97E74ACC0C@vigilsec.com>
References:   <17C5AA81-30C1-48BD-A919-1D0F78C936C5@sn3rd.com>
To: Sean Turner 
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2020 17:12:27 -0000

Sean, you are talking about Section 3.4 (not 3.1), I think.  If that is =
correct, then I suggest:

   The GMACParameters nonce field is the GMAC initialization vector.
   The nonce may have any number of bits between 8 and 2^64, but it MUST
   be a multiple of 8 bits.  Within the scope of any GMAC key, the nonce
   value MUST be unique.  A nonce value of 12 octets can be processed
   more efficiently, so that length for the nonce value is RECOMMENDED.

   The GMACParameters length field field tells the size of the
   message authentication code in octets.  The length may have a value
   between 12 and 16, inclusive.  A length of 12 octets is RECOMMENDED.

Russ

> On Dec 23, 2020, at 11:35 AM, Sean Turner  wrote:
>=20
> IANAC, but I did have a read of this draft and thought it looked like =
a fine candidate for progressing to the next stage.
>=20
> Minor nit that could be addressed later:
>=20
> To be all matchy-matchy with the last paragraph in s3.1 you could
> s/nonce parameter/nonce parameter field
> in the penultimate paragraph of s3.1.
>=20
> spt
>=20
>> On Dec 22, 2020, at 16:47, Tim Hollebeek =
 wrote:
>>=20
>> The comment period has ended, and no new feedback was received.  =
I=E2=80=99ll start pushing this forward.
>>=20
>> -Tim
>>=20
>> From: Spasm  On Behalf Of Tim Hollebeek
>> Sent: Friday, December 4, 2020 4:17 PM
>> To: LAMPS 
>> Subject: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
>>=20
>> This is the LAMPS WG Last Call for "Using the AES-GMAC Algorithm with =
the Cryptographic Message Syntax (CMS)=E2=80=9D =
.  Please review the document and =
send your comments to the list by 18 December 2020.
>>=20
>> The datatracker page for the document is =
https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-aes-gmac-alg/
>>=20
>> -Tim
>> _______________________________________________
>> 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


From nobody Wed Dec 23 10:12:04 2020
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 212D43A00F7 for ; Wed, 23 Dec 2020 10:12:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 AQGdSmeIxCUO for ; Wed, 23 Dec 2020 10:12:00 -0800 (PST)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 038C53A00D9 for ; Wed, 23 Dec 2020 10:11:59 -0800 (PST)
Received: by mail-qk1-x72f.google.com with SMTP id z11so104880qkj.7 for ; Wed, 23 Dec 2020 10:11:59 -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=vAyyU4XPKaaeemt4HgS0+2BtTCliXF99gPFWAUEwZR0=; b=K3qTnY88qOjvR+IzwI3gphUW9FqrHEYdeSCCWoZhSpNxG8DyZM30RUvsVLiCHeVOlS Po3EfKNShYA+BnRL2SlN7hXsa+nhQN7EufWecs8tj8l7QArESpUYsX+VJR4ShPcMg85d 1NcZahKffAvJZyjdk+pQ+swTniOk/v/5WIqzM=
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=vAyyU4XPKaaeemt4HgS0+2BtTCliXF99gPFWAUEwZR0=; b=r8MiqWK46lGFO8mstV7FlLpru33BPK8dvuo8auZ2bUi7JHjFtipg8eyKx07rZtoOu8 jGpaB3frnGSGy64bFaUDNy6En3UHyL3/L2GpgR1bO/Nbnht1Vz5L2wVX3yR7OOV+ef1c j7UdiCXJtm4sHIaWen64oc5/tv9uL8REgfsIHotyQfPrrcR46aD5qG5nR8mfeEii3YKS R4bCRt8ODYzbGSC47NlMO+LyD+z0y6/hLektCbufO0n35e4196G0tJYgNcF0vyA8iVzJ Av59NGfGteLp2pnHV9mQ8eZwY8NjtP13CcLqrCNu+i+HjFRtWOzW4p8l4effcSy9vIYF 46jw==
X-Gm-Message-State: AOAM532boVlewc/NtsTBem5OApYYIiyIpkqUBNBTrsc65ohpoPD50042 qHfIm9kIwDM7l40MCYr5DkNmXg==
X-Google-Smtp-Source: ABdhPJz3ZYI+YZY6ho9SDIU+uRGQDsPapuXhYGz0wvgfxlSSVrxmlPPTLtINCbxgmQzcuiD/7M5pkQ==
X-Received: by 2002:a05:620a:2104:: with SMTP id l4mr26965891qkl.35.1608747118802;  Wed, 23 Dec 2020 10:11:58 -0800 (PST)
Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id 195sm15431244qke.108.2020.12.23.10.11.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Dec 2020 10:11:56 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Sean Turner 
In-Reply-To: <017ca985-ac25-b318-c259-24b08344bd0e@isode.com>
Date: Wed, 23 Dec 2020 13:11:55 -0500
Cc: LAMPS 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5F4E87EE-4CD1-4A9F-BDE2-82AD8FD6EFB1@savignano.net>  <017ca985-ac25-b318-c259-24b08344bd0e@isode.com>
To: Alexey Melnikov , Metin Savignano 
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: 
Subject: Re: [lamps] Possible inconsistencies or ambiguities in RFC 8551
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2020 18:12:02 -0000

Hi! Sorry it=E2=80=99s taken me forever to get to this.

I just want to be clear that the proposal here is not trying to change, =
what I believe and somebody else should correct me if they think =
otherwise, the consensus decision that GCM is the MUST.

The meta point here is that as S/MIME has moved from RC4 to tripleDES =
(RFC 3851 v3.1), from tripleDES to AES-CBC (RFC 5751), and now from =
AES-CBC to AES-GCM (RFC 8751) the logic has been the same:

   If you do not know what the receiving side
   supports send the best you got.

There is no negotiation so better to err on the side of caution (for =
human controlled agents) even (s2.7.2) "if there is a possibility that =
the recipient will not be able to process that algorithm."

I would not read the paragraphs in question as a cookbook to get the =
most interoperability. If we want that, then we either switch to =
plaintext or we would need to decide on which version to most =
interoperable with. I would hazard a guess that that CBC based on v3.2 =
wouldn=E2=80=99t be the choice but instead tripleDES based on v3.1/v3.0.

You should also note that there is a big out in s2.7.1 in the last =
paragraph. All of 2.7.1.* is a SHOULD.

WRT the ambiguity between s1.4 and s2.7.1.2, I am not so sure there is =
one as I consider s1.4 to be feel good deployment consideration text =
lacking any requirements. It provides some history for readers unaware =
of it. But, that =E2=80=9Cought=E2=80=9D in s1.4 only applies some of =
the times, e.g., if this is a high security environment maybe do not use =
RC4 as specified in v2.

I could go either way on removing the =E2=80=9Cis=E2=80=9D. I think it =
is wordy, but not necessarily wrong. Then again I am no grammar scholar. =
I would certainly not object to an editorial errata if the WG felt it =
necessary. Some options:

ORIGINAL (wordy):
given the presumption is that a client implementing=20
MAYBE (less wordy):
given the presumption that a client implementing
OR (even more wordy):
given that the presumption is that a client implementing
OR (even less wordy):
assuming a client implementing

Alexey is right in that what it is trying to say is that if a client =
supports AES it=E2=80=99s like to also support CBC. That is there so =
that implementations do not choose tripleDES, which was the old SHOULD-.

spt

> On Dec 8, 2020, at 12:48, Alexey Melnikov  =
wrote:
>=20
> Hi Metin,
>=20
> I am not an author/editor of RFC 8551, but I will reply with my =
opinions in order to stimulate some discussion of issues that you've =
raised.
>=20
> On 07/12/2020 09:06, Metin Savignano wrote:
>=20
>> Hi,
>>=20
>> referring to my email quoted below of 7th August, may I ask if and =
how I would get a reply? I haven=E2=80=99t seen one,         and I am =
wondering if I would have to look at some other place?
>>=20
>> Thanks
>> Metin
>>=20
>>=20
>>> Anfang der weitergeleiteten Nachricht:
>>>=20
>>> Von: Metin Savignano 
>>> Betreff: Possible inconsistencies or ambiguities in RFC 8551
>>> Datum: 7. August 2020 um 13:01:53 MESZ
>>> An: spasm@ietf.org
>>>=20
>>> Dear authors,
>>>=20
>>> First of all, thank you very much for your work to create a new and =
better version of S/MIME!=20
>>>=20
>>> As an author of an S/MIME app, we are working through RFC 8551 to =
determine the changes we have to implement in order to fully comply to =
the S/MIME 4.0 specs.
>>>=20
>>> However, I=E2=80=99ve come to a point where I seem unable to =
understand what the RFC actually recommends with regard to the backward =
compatibility. I=E2=80=99ve also discussed this with another software =
developer, but we both weren=E2=80=99t sure how to read it. It would be =
awesome if you could help me with a clarification.
>>>=20
>>> In the relevant scenario, the sending agent wants to send encrypted =
email to a recipient with unknown capabilities.
>>>=20
>>> With regard to backward compatibility, RFC 8551 states in section =
1.4:
>>>=20
>>>    S/MIME version 4.0 agents ought to attempt to have the greatest
>>>    interoperability possible with agents for prior versions of =
S/MIME.
>>>=20
>>>=20
>>> Although this is a very general statement, I believe it is =
contradictory to the description about how to decide which content =
encryption cipher to use in section 2.7.1.2:
>>>=20
>>>    If the following two conditions are met, the sending agent SHOULD =
use
>>>    AES-256 GCM, as AES-256 GCM is a stronger algorithm and is =
required
>>>    by S/MIME v4.0:
>>>=20
>>>    -  The sending agent has no knowledge of the encryption =
capabilities
>>>       of the recipient.
>>>=20
>>>    -  The sending agent has no knowledge of the version of S/MIME =
used
>>>       or supported by the recipient.
>>>=20
>>> I don=E2=80=99t understand why we should choose AES-256-GCM if we =
don=E2=80=99t know about the recipients capabilities and S/MIME version.
> I agree with you that text from Sections 1.4 and 2.7.1.2 is =
contradictory.
>=20
>>> For example, if the recipient uses an S/MIME 3.2 compliant software, =
as I understand RFC 5751, that software need not know about AES-256-GCM. =
The GCM block mode is not even mentioned in earlier S/MIME versions.  As =
a consequence, doesn=E2=80=99t the selection of AES-256-GCM contradict =
the "attempt to have the greatest interoperability possible with agents =
for prior versions of S/MIME=E2=80=9C?
> Yes, there is contradiction in the RFC as written.
>=20
> I think some implementations would value interoperability with earlier =
versions of S/MIME higher than security and others would choose the =
opposite. Text in 2.7.1.2 seems to be written with the latter case in =
mind.
>=20
> For new implementations or implementations more concerned with =
security, using more modern crypto algorithms can be a good default.
>=20
>>> The common capability in both S/MIME versions would be AES-128-CBC, =
wouldn=E2=80=99t it?
>>>=20
>>> Also, I do not really understand the following sentence:
>>> =20
>>>    If the sending agent chooses not to use AES-256 GCM in this step,
>>>    given the presumption is that a client implementing AES-GCM would =
do
>>>    both AES-256 and AES-128, it SHOULD use AES-128 CBC.
>>>=20
>>> It appears to me as if this sentence was grammatically either wrong =
or uses a construct that I don=E2=80=99t understand (I=E2=80=99m not a =
native speaker).
> You are right, the above seems wrong. I think "is" needs to be dropped =
after "presumption".
>>> I don=E2=80=99t understand what "given the presumption is that a =
client implementing AES-GCM would do both AES-256 and AES-128=E2=80=9C  =
is meant to tell me in that context. Also, I=E2=80=99m not sure if the =
word =E2=80=9Eclient=E2=80=9C is meant to refer to the sending or =
receiving client. At first, I thought it=E2=80=99s the receiving client, =
but after re-reading a few times, I=E2=80=99m unsure if it=E2=80=99s the =
sending agent, because I don=E2=80=99t understand why I should make =
presumptions about the receiving client implementing AES-GCM when I =
don=E2=80=99t know anything about it.
> I think the text is trying to say that as the client supports AES, it =
is likely to support AES-128 CBC.
>>>=20
>>> I would recommend that this sentence maybe rephrase to make it more =
understandable for non-native speakers.
>>>=20
>>> What I would have expected in section 2.7.1.2:
>>>=20
>>> To maintain "greatest interoperability possible with agents for =
prior versions of S/MIME=E2=80=9C, the RFC would select AES-128-CBC if =
the recipient=E2=80=99s capabilities and S/MIME version aren=E2=80=99t =
known.
>>>=20
>>> Where am I off the track?
>>>=20
>>>=20
>>> Thanks a lot!
>>>=20
>>> Metin Savignano
> Best Regards,
>=20
> Alexey
>=20
>=20
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


From nobody Wed Dec 23 10:24:37 2020
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 E02F63A03FC for ; Wed, 23 Dec 2020 10:24:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Tio1635xHe4h for ; Wed, 23 Dec 2020 10:24:34 -0800 (PST)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 078953A03FA for ; Wed, 23 Dec 2020 10:24:34 -0800 (PST)
Received: by mail-qk1-x72d.google.com with SMTP id 143so120052qke.10 for ; Wed, 23 Dec 2020 10:24:33 -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=Urgf2JuN4EAhJKpDFnuUGAmzuW7sloJZLgyejoVU9uk=; b=c5RnGU7UuM+cXJ+qHt2XD0lNdSnnFE4cUKKaU0iA8TjO+hVIH0Si7DUHNYzxiLz9Y/ Q+sZBGWBCWZ4QtP0orEbvSmPTdsR4kdV5UeRQ+bLzrDnEYiwMi5xK9M7UR/vOn5i7s8O 9q5CTm3h1Hz9LJ9Y+hSsnd+ezzI0jJN8lmGrI=
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=Urgf2JuN4EAhJKpDFnuUGAmzuW7sloJZLgyejoVU9uk=; b=UsfBT9oxFF3DXEq3dgsnNpsML6PhJmx4Xeus+Mt/Epu7shuoUfYf1z3w7khIqylrf5 iuleOqCUAKY1UWvv11VS66Lc/dDZj7Dbmy+kZz3sIh/LpogYDuxmluB7lEZkD/cONs1L lXnumBaskJm4+i2jZl9ID5CNw4wIUAD4P3ozi1WDiCT34K1peHrMQw5O+rCfT2zt7QMA 7Ivhcx8wIaAa1OFU3xlVWZwWOQSVR5nvjDdKI+NZyfrgM2Dhjhp8AGS6ZfkI89TMPhVC aI2E/YgAygxoaQBHgsSueX5CO3WuH4x3vgOo8Czp1YMLnB4D5W8iYbG6U9c8eIRFTXv9 Zxqw==
X-Gm-Message-State: AOAM531jv8D9JJf7MyUZRoQj0Z2u09kP5URNUxxU7Hd/TCnaM5WuZ23P +kS3eaEgtj+ABdrvVV1Y06jkSw==
X-Google-Smtp-Source: ABdhPJxjKWVTmoeeUXM1s/6t42NcbNhHYw3VBomscPFRU86j2EQyg68vmDT7iYqsRKabdTNxZ6cehg==
X-Received: by 2002:a37:aace:: with SMTP id t197mr27700082qke.175.1608747873149;  Wed, 23 Dec 2020 10:24:33 -0800 (PST)
Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id g18sm14503349qtv.79.2020.12.23.10.24.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Dec 2020 10:24:31 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Sean Turner 
In-Reply-To: <50CE7489-C6DD-45A9-8B5A-2B97E74ACC0C@vigilsec.com>
Date: Wed, 23 Dec 2020 13:24:30 -0500
Cc: LAMPS 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <17C5AA81-30C1-48BD-A919-1D0F78C936C5@sn3rd.com> <50CE7489-C6DD-45A9-8B5A-2B97E74ACC0C@vigilsec.com>
To: Russ Housley 
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: 
Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2020 18:24:36 -0000

There=E2=80=99s no 3.4 in my version ;)
=
https://tools.ietf.org/html/draft-ietf-lamps-cms-aes-gmac-alg-00#section-3=
.1

But, yeah it=E2=80=99s adding =E2=80=9Cfield" in the first sentence.

> On Dec 23, 2020, at 12:12, Russ Housley  wrote:
>=20
> Sean, you are talking about Section 3.4 (not 3.1), I think.  If that =
is correct, then I suggest:
>=20
>   The GMACParameters nonce field is the GMAC initialization vector.
>   The nonce may have any number of bits between 8 and 2^64, but it =
MUST
>   be a multiple of 8 bits.  Within the scope of any GMAC key, the =
nonce
>   value MUST be unique.  A nonce value of 12 octets can be processed
>   more efficiently, so that length for the nonce value is RECOMMENDED.
>=20
>   The GMACParameters length field field tells the size of the
>   message authentication code in octets.  The length may have a value
>   between 12 and 16, inclusive.  A length of 12 octets is RECOMMENDED.
>=20
> Russ
>=20
>> On Dec 23, 2020, at 11:35 AM, Sean Turner  wrote:
>>=20
>> IANAC, but I did have a read of this draft and thought it looked like =
a fine candidate for progressing to the next stage.
>>=20
>> Minor nit that could be addressed later:
>>=20
>> To be all matchy-matchy with the last paragraph in s3.1 you could
>> s/nonce parameter/nonce parameter field
>> in the penultimate paragraph of s3.1.
>>=20
>> spt
>>=20
>>> On Dec 22, 2020, at 16:47, Tim Hollebeek =
 wrote:
>>>=20
>>> The comment period has ended, and no new feedback was received.  =
I=E2=80=99ll start pushing this forward.
>>>=20
>>> -Tim
>>>=20
>>> From: Spasm  On Behalf Of Tim Hollebeek
>>> Sent: Friday, December 4, 2020 4:17 PM
>>> To: LAMPS 
>>> Subject: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
>>>=20
>>> This is the LAMPS WG Last Call for "Using the AES-GMAC Algorithm =
with the Cryptographic Message Syntax (CMS)=E2=80=9D =
.  Please review the document and =
send your comments to the list by 18 December 2020.
>>>=20
>>> The datatracker page for the document is =
https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-aes-gmac-alg/
>>>=20
>>> -Tim
>>> _______________________________________________
>>> Spasm mailing list
>>> Spasm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/spasm
>>=20
>> _______________________________________________
>> Spasm mailing list
>> Spasm@ietf.org
>> https://www.ietf.org/mailman/listinfo/spasm
>=20


From nobody Wed Dec 23 10:31:18 2020
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 00E433A046B for ; Wed, 23 Dec 2020 10:31:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.5
X-Spam-Level: 
X-Spam-Status: No, score=-2.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, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.399, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=nist.gov
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 IeAiLGihj9t2 for ; Wed, 23 Dec 2020 10:31:14 -0800 (PST)
Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2099.outbound.protection.outlook.com [40.107.91.99]) (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 A52F43A044E for ; Wed, 23 Dec 2020 10:31:14 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OyK/urt0wUy8T5aLpvlQWE6hu5wwaG9SNYM5dYfQJKKRck/dqcRIuESuLVVfJsTka7lwhzzGW1jKSLAVAG1sHPZ3iBOQ+CHnjfgoe6ZW65Du99LQ0HLscKTibOAkdXOshvs90w84I87gBU4PpH9vtLSzl0qcr6IVmpnIYNGjoh1vbVlGJ8Bjy5rKBZdEOaM52h4Awdv+Co2p9zXdEjOVA1EdTqPmAHEeyeqQ4YPCMhUplrKTbN3WUCVr5tpP1ub+UQbeaj4lNzSkp+zMNoOBAEVL6mtFdPSODfKLTL0zU490aUKmki1jtGDFt+WQu781voUiAxDuPa0DKJlZTFJ5sw==
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=vdX/kBiu7OWWOkXV5t3L0EY5taNPRtNvLIJtNCpvTq0=; b=PpWxEuC34+4mLq7H7nlqKK2HnT5cLIvM98+tJJ51zVKfdTJTLhf8afKP0KDbBqUG9YpacuriL93xE5/9fdfr504fWYTpfJ4t5SA3EhFJjjol7WWZ79bAQ6106dek9u4oio72gyTXn7M95eI6HTWzwbN0pHGATxa9sbO1VZV91x2Jpdmh6cSJx8Tzn0jFyjQZfYXNon8I86u4lEMU/HHJi85FokfUDf1h5FfP/vpT+CPX/Z0O/maZtbUwTQev5OgQIe8AAWdUDwO8JmcCfglnFO474BKxJ/X18Y8bf7JpX4DUu1SBjuzQxQfbdHZ0H8Uh7WRaHlqvK4mk1F8hU0WIQQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2;  h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vdX/kBiu7OWWOkXV5t3L0EY5taNPRtNvLIJtNCpvTq0=; b=fO8ZiD0ifnbssXDIXYb9cZtfyImClRhSr7bfW3IPMtsB9Xe4ChgolvgVuGfHu7mePdyS6I2H6qlq1LFLErh4a4Y7Gc0IQJ3dsEmb67VvfZMoVYnpMsGIb5dvESTPUkA4rLrxDHvwpoDZiF4d3DWPPASfROBqDlqx9PSq4tC/anI=
Received: from SA0PR09MB6841.namprd09.prod.outlook.com (2603:10b6:806:7e::23) by SA1PR09MB7759.namprd09.prod.outlook.com (2603:10b6:806:182::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.25; Wed, 23 Dec 2020 18:31:12 +0000
Received: from SA0PR09MB6841.namprd09.prod.outlook.com ([fe80::78c3:29d8:9d06:733d]) by SA0PR09MB6841.namprd09.prod.outlook.com ([fe80::78c3:29d8:9d06:733d%6]) with mapi id 15.20.3676.033; Wed, 23 Dec 2020 18:31:12 +0000
From: "Dang, Quynh H. (Fed)" 
To: Russ Housley , Sean Turner 
CC: LAMPS 
Thread-Topic: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
Thread-Index: AdbKgl0GZVRVKEllR6iGycD6D5x5ZAOKY8ZwACdq0oAAAUuNAAACpdgh
Date: Wed, 23 Dec 2020 18:31:12 +0000
Message-ID: 
References:   <17C5AA81-30C1-48BD-A919-1D0F78C936C5@sn3rd.com>, <50CE7489-C6DD-45A9-8B5A-2B97E74ACC0C@vigilsec.com>
In-Reply-To: <50CE7489-C6DD-45A9-8B5A-2B97E74ACC0C@vigilsec.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=nist.gov;
x-originating-ip: [2610:20:6005:223::a3]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: d7acd7ed-8562-4ac2-d892-08d8a770ecd8
x-ms-traffictypediagnostic: SA1PR09MB7759:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: EMLk3iJtHw9FNZK35Bzkn8hypaFX2ly96bPyiBjHL5gY5h9hI+r1JWOBCFtWhjbI5f7QF+MW39CSlzvoJNUmUgkExhAmDxbD8Pe0pdewln6TbYVTyzlKeHxu6qPsNEdiXx48VNRV4od4YvZ4cMaWadNCHyeS+NHxQVP+UnIV7a01YWo8qgemKTj425JW0twCKN2M193FpIj+rUvrLNRhxfhxGwZaBtlmsUScbOKwcNnghqrD7ieeMb2r3OnJzGAE4guZzHMvj+fG+D6yp2k42ChyN+KH5lOGacEPCb4T3qVCHeTrDb3rAp1eGF+GtVjCmHlI5YVdf8DLdzH9TYffVx3M0f9jNSPSsYdq3E1T0TcU8vKxnxPRKN125WbB+OrZYX20IhZpKKeX6h2FTJ82Qbc3GmHFRaWHiRZcchOeuR/XZQuYObKmMJn9MjAbvdXayt6QsZVl8KZlwsYEJ3Ameg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:SA0PR09MB6841.namprd09.prod.outlook.com; PTR:; CAT:NONE;  SFS:(4636009)(39860400002)(346002)(136003)(376002)(366004)(396003)(76116006)(19627405001)(52536014)(55016002)(66446008)(9686003)(166002)(478600001)(45080400002)(64756008)(6506007)(316002)(33656002)(83380400001)(8676002)(5660300002)(91956017)(2906002)(53546011)(7696005)(186003)(8936002)(4326008)(71200400001)(110136005)(66556008)(66946007)(966005)(66476007)(86362001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?CLTZ67oukffD84Pi64hKN1VI6Zldg7JsdhT5aN0rYyFCDbz+OJXIbI/P?= =?Windows-1252?Q?WkHyRMmnqis4V78OvqidUO7gOFP6BSO1iAZpR1O+LweubZRE0KJ5xa/0?= =?Windows-1252?Q?/KIV01qKixk/OW4mQHOgZEPW7/4GkLQ6tsAZz+6cBfLzujB76+2lmVMq?= =?Windows-1252?Q?xnYq7lwkzhguj1iM4r88AoDYR48noxWtQ8AD3BZ8YGAbLEGwvbPRGDqM?= =?Windows-1252?Q?i4dJlmBjAnSMMlyxI5Lu6lroO02M5HE2Zsn/qIZv8E+DPBTrSam+pfkj?= =?Windows-1252?Q?Hnibbi2FnyrvVt62derU8Djpp6kv5IZysP3TvwymPc6m8UJJcHFRT4Ij?= =?Windows-1252?Q?ErOLeWuFPWafAHv+WkyJJrkKtBs5DCEIUMCoby+80U3wz6DaJxjTOvWD?= =?Windows-1252?Q?G1183Hxbt7hlbj5gPkPDyEVQDk58R0DhrxQrHQOLR19jtYErMLc/Va7X?= =?Windows-1252?Q?vdsRc7fxOZt/SN9qNJkg8vQxtNKceJhLE+3co5w65kL0KFQ2a12Frywo?= =?Windows-1252?Q?HGAAQRJ6Lxrbkj0i7TeixcMVBUJgVrPNxvKFSUg6di58ijyqw0biMIQx?= =?Windows-1252?Q?K3dbOyeAZzq0gza41AE3FlhFl4xKFd4wcTndmvwh3Yq62Qld+LZRQPJy?= =?Windows-1252?Q?7Q8pJg5D1Jl/FBeDeMZsJldA6ktq993DN+Sp0oPFb0cW8Fr7mnI9E7hm?= =?Windows-1252?Q?fKjUWDRb5tqhQk/bjGZoZAzwIwiUt+TR1BimymC06fnJA8SeQKG/G+Ja?= =?Windows-1252?Q?1ca7TwwXK83yvvwCcfUqV++j55ajJILCy8g+e1Zn6xb+8ssMxhAADEnQ?= =?Windows-1252?Q?VldVwY8DKJF0aSQT2zbQmv7NIDAQRMQ0k4aUdFGiNJkn9UXLT+RVkiuj?= =?Windows-1252?Q?NnT0Dz07kil6te7mKxng92a4pCo1iqtA8oKzYcxx/ynHR2obzO/jhwAz?= =?Windows-1252?Q?VqiGQfxGYR+dXw+lkHmhaq3XJYOI5ttuBwHspklMV6bzs/oaEIbv2K8N?= =?Windows-1252?Q?MXJpIIx6yM2/AROUx8/VzmwiOIlIKrvDyxlCzelYyywqA+MP/obmS/dZ?= =?Windows-1252?Q?jECm/+6hzKJTSBW3?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_SA0PR09MB684150E8DD04EABA4E99F131F3DE0SA0PR09MB6841namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA0PR09MB6841.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d7acd7ed-8562-4ac2-d892-08d8a770ecd8
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2020 18:31:12.3898 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: JRG6H9drQRoMudxQXkizInspiPQW/5NQ+yXjTjiGMhiQiNBlvB74rsFMwhX1ozxE
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR09MB7759
Archived-At: 
Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2020 18:31:17 -0000

--_000_SA0PR09MB684150E8DD04EABA4E99F131F3DE0SA0PR09MB6841namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Russ,

12 octets are fine for many use cases.

I am wondering why that size is Recommended (to save 4 bytes ?).

Regards,
Quynh.
________________________________
From: Spasm  on behalf of Russ Housley 
Sent: Wednesday, December 23, 2020 12:12 PM
To: Sean Turner 
Cc: LAMPS 
Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg

Sean, you are talking about Section 3.4 (not 3.1), I think.  If that is cor=
rect, then I suggest:

   The GMACParameters nonce field is the GMAC initialization vector.
   The nonce may have any number of bits between 8 and 2^64, but it MUST
   be a multiple of 8 bits.  Within the scope of any GMAC key, the nonce
   value MUST be unique.  A nonce value of 12 octets can be processed
   more efficiently, so that length for the nonce value is RECOMMENDED.

   The GMACParameters length field field tells the size of the
   message authentication code in octets.  The length may have a value
   between 12 and 16, inclusive.  A length of 12 octets is RECOMMENDED.

Russ

> On Dec 23, 2020, at 11:35 AM, Sean Turner  wrote:
>
> IANAC, but I did have a read of this draft and thought it looked like a f=
ine candidate for progressing to the next stage.
>
> Minor nit that could be addressed later:
>
> To be all matchy-matchy with the last paragraph in s3.1 you could
> s/nonce parameter/nonce parameter field
> in the penultimate paragraph of s3.1.
>
> spt
>
>> On Dec 22, 2020, at 16:47, Tim Hollebeek  wrote:
>>
>> The comment period has ended, and no new feedback was received.  I=92ll =
start pushing this forward.
>>
>> -Tim
>>
>> From: Spasm  On Behalf Of Tim Hollebeek
>> Sent: Friday, December 4, 2020 4:17 PM
>> To: LAMPS 
>> Subject: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
>>
>> This is the LAMPS WG Last Call for "Using the AES-GMAC Algorithm with th=
e Cryptographic Message Syntax (CMS)=94 .  Please review the document and send your comments to the list by 18 D=
ecember 2020.
>>
>> The datatracker page for the document is https://gcc02.safelinks.protect=
ion.outlook.com/?url=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-iet=
f-lamps-cms-aes-gmac-alg%2F&data=3D04%7C01%7Cquynh.dang%40nist.gov%7Cf6=
db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7=
C637443403620987942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l=
uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DIo8posg3cBdQoVepGGnS=
ai5E9VgYk3BCODMqablsdHI%3D&reserved=3D0
>>
>> -Tim
>> _______________________________________________
>> Spasm mailing list
>> Spasm@ietf.org
>> https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.=
ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D04%7C01%7Cquynh.dang%40nis=
t.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa4797a93e054655c61dec=
%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL=
CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3D8LKfeqo971=
8V2PBoM4xTaE4%2FfQhaaBUgVNo9T1X9tIs%3D&reserved=3D0
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i=
etf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D04%7C01%7Cquynh.dang%40nist=
.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa4797a93e054655c61dec%=
7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC=
JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3D8LKfeqo9718=
V2PBoM4xTaE4%2FfQhaaBUgVNo9T1X9tIs%3D&reserved=3D0

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet=
f.org%2Fmailman%2Flistinfo%2Fspasm&data=3D04%7C01%7Cquynh.dang%40nist.g=
ov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa4797a93e054655c61dec%7C=
1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ=
IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3D8LKfeqo9718V2=
PBoM4xTaE4%2FfQhaaBUgVNo9T1X9tIs%3D&reserved=3D0

--_000_SA0PR09MB684150E8DD04EABA4E99F131F3DE0SA0PR09MB6841namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable









Hi Russ,









12 octets are fine for many use cases. 









I am wondering why that size is Recommended (to save 4 bytes ?).









Regards,



Quynh. 






From: Spasm <spasm-bounc=
es@ietf.org> on behalf of Russ Housley <housley@vigilsec.com>

Sent: Wednesday, December 23, 2020 12:12 PM

To: Sean Turner <sean@sn3rd.com>

Cc: LAMPS <spasm@ietf.org>

Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-=
alg

 






Sean, you are talking about Section 3.4 (not 3.1),=
 I think.  If that is correct, then I suggest:



   The GMACParameters nonce field is the GMAC initialization vect=
or.

   The nonce may have any number of bits between 8 and 2^64, but =
it MUST

   be a multiple of 8 bits.  Within the scope of any GMAC ke=
y, the nonce

   value MUST be unique.  A nonce value of 12 octets can be =
processed

   more efficiently, so that length for the nonce value is RECOMM=
ENDED.



   The GMACParameters length field field tells the size of the
   message authentication code in octets.  The length may ha=
ve a value

   between 12 and 16, inclusive.  A length of 12 octets is R=
ECOMMENDED.



Russ



> On Dec 23, 2020, at 11:35 AM, Sean Turner <sean@sn3rd.com> wrote=
:

> 

> IANAC, but I did have a read of this draft and thought it looked like =
a fine candidate for progressing to the next stage.

> 

> Minor nit that could be addressed later:

> 

> To be all matchy-matchy with the last paragraph in s3.1 you could

> s/nonce parameter/nonce parameter field

> in the penultimate paragraph of s3.1.

> 

> spt

> 

>> On Dec 22, 2020, at 16:47, Tim Hollebeek <tim.hollebeek=3D40dig=
icert.com@dmarc.ietf.org> wrote:

>> 

>> The comment period has ended, and no new feedback was received.&nb=
sp; I=92ll start pushing this forward.

>> 

>> -Tim

>> 

>> From: Spasm <spasm-bounces@ietf.org> On Behalf Of Tim Holleb=
eek

>> Sent: Friday, December 4, 2020 4:17 PM

>> To: LAMPS <spasm@ietf.org>

>> Subject: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-al=
g

>> 

>> This is the LAMPS WG Last Call for "Using the AES-GMAC Algori=
thm with the Cryptographic Message Syntax (CMS)=94 <draft-ietf-lamps-cms=
-aes-gmac-alg-00>.  Please review the document and send your commen=
ts to the list by 18 December 2020.

>> 

>> The datatracker page for the document is 
https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra=
cker.ietf.org%2Fdoc%2Fdraft-ietf-lamps-cms-aes-gmac-alg%2F&amp;data=3D0=
4%7C01%7Cquynh.dang%40nist.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82=
fd8fa4797a93e054655c61dec%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZs=
b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C20=
00&amp;sdata=3DIo8posg3cBdQoVepGGnSai5E9VgYk3BCODMqablsdHI%3D&amp;r=
eserved=3D0

>> 

>> -Tim

>> _______________________________________________

>> Spasm mailing list

>> Spasm@ietf.org

>> 
https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet=
f.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=3D04%7C01%7Cquynh.dang%40ni=
st.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa4797a93e054655c61de=
c%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi=
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=3D8LKfe=
qo9718V2PBoM4xTaE4%2FfQhaaBUgVNo9T1X9tIs%3D&amp;reserved=3D0

> 

> _______________________________________________

> Spasm mailing list

> Spasm@ietf.org

> 
https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet=
f.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=3D04%7C01%7Cquynh.dang%40ni=
st.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa4797a93e054655c61de=
c%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi=
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=3D8LKfe=
qo9718V2PBoM4xTaE4%2FfQhaaBUgVNo9T1X9tIs%3D&amp;reserved=3D0



_______________________________________________

Spasm mailing list

Spasm@ietf.org

https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i=
etf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=3D04%7C01%7Cquynh.dang%40=
nist.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa4797a93e054655c61=
dec%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD=
AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=3D8LK=
feqo9718V2PBoM4xTaE4%2FfQhaaBUgVNo9T1X9tIs%3D&amp;reserved=3D0








--_000_SA0PR09MB684150E8DD04EABA4E99F131F3DE0SA0PR09MB6841namp_--


From nobody Wed Dec 23 10:54:23 2020
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 17BD43A0811 for ; Wed, 23 Dec 2020 10:54:21 -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, 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 mAReGmWIsPoB for ; Wed, 23 Dec 2020 10:54:19 -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 EDEE03A0803 for ; Wed, 23 Dec 2020 10:54:18 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8E32E300BA3 for ; Wed, 23 Dec 2020 13:54:16 -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 Fi-lDvdwryFT for ; Wed, 23 Dec 2020 13:54:14 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id ACF44300ADB; Wed, 23 Dec 2020 13:54:14 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Russ Housley 
In-Reply-To: 
Date: Wed, 23 Dec 2020 13:54:16 -0500
Cc: LAMPS 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <17C5AA81-30C1-48BD-A919-1D0F78C936C5@sn3rd.com> <50CE7489-C6DD-45A9-8B5A-2B97E74ACC0C@vigilsec.com> 
To: Sean Turner 
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2020 18:54:21 -0000

I stand corrected about the Section number.  It is Section 3.1.

I'll post the updated version with "field" in the first sentence of the =
two paragraphs at the end of Section 3.1.

Russ

> On Dec 23, 2020, at 1:24 PM, Sean Turner  wrote:
>=20
> There=E2=80=99s no 3.4 in my version ;)
> =
https://tools.ietf.org/html/draft-ietf-lamps-cms-aes-gmac-alg-00#section-3=
.1
>=20
> But, yeah it=E2=80=99s adding =E2=80=9Cfield" in the first sentence.
>=20
>> On Dec 23, 2020, at 12:12, Russ Housley  wrote:
>>=20
>> Sean, you are talking about Section 3.4 (not 3.1), I think.  If that =
is correct, then I suggest:
>>=20
>>  The GMACParameters nonce field is the GMAC initialization vector.
>>  The nonce may have any number of bits between 8 and 2^64, but it =
MUST
>>  be a multiple of 8 bits.  Within the scope of any GMAC key, the =
nonce
>>  value MUST be unique.  A nonce value of 12 octets can be processed
>>  more efficiently, so that length for the nonce value is RECOMMENDED.
>>=20
>>  The GMACParameters length field field tells the size of the
>>  message authentication code in octets.  The length may have a value
>>  between 12 and 16, inclusive.  A length of 12 octets is RECOMMENDED.
>>=20
>> Russ
>>=20
>>> On Dec 23, 2020, at 11:35 AM, Sean Turner  wrote:
>>>=20
>>> IANAC, but I did have a read of this draft and thought it looked =
like a fine candidate for progressing to the next stage.
>>>=20
>>> Minor nit that could be addressed later:
>>>=20
>>> To be all matchy-matchy with the last paragraph in s3.1 you could
>>> s/nonce parameter/nonce parameter field
>>> in the penultimate paragraph of s3.1.
>>>=20
>>> spt
>>>=20
>>>> On Dec 22, 2020, at 16:47, Tim Hollebeek =
 wrote:
>>>>=20
>>>> The comment period has ended, and no new feedback was received.  =
I=E2=80=99ll start pushing this forward.
>>>>=20
>>>> -Tim
>>>>=20
>>>> From: Spasm  On Behalf Of Tim Hollebeek
>>>> Sent: Friday, December 4, 2020 4:17 PM
>>>> To: LAMPS 
>>>> Subject: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
>>>>=20
>>>> This is the LAMPS WG Last Call for "Using the AES-GMAC Algorithm =
with the Cryptographic Message Syntax (CMS)=E2=80=9D =
.  Please review the document and =
send your comments to the list by 18 December 2020.
>>>>=20
>>>> The datatracker page for the document is =
https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-aes-gmac-alg/
>>>>=20
>>>> -Tim
>>>> _______________________________________________
>>>> Spasm mailing list
>>>> Spasm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/spasm
>>>=20
>>> _______________________________________________
>>> Spasm mailing list
>>> Spasm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/spasm
>>=20
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


From nobody Wed Dec 23 10:57:16 2020
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 F21A23A0827 for ; Wed, 23 Dec 2020 10:57:14 -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, 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 negIQkeJyBf4 for ; Wed, 23 Dec 2020 10:57:11 -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 556453A0811 for ; Wed, 23 Dec 2020 10:57:11 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BC846300BC0 for ; Wed, 23 Dec 2020 13:57:08 -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 ELUJtLys2zEv for ; Wed, 23 Dec 2020 13:57:06 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id E5BB8300ADB; Wed, 23 Dec 2020 13:57:05 -0500 (EST)
From: Russ Housley 
Message-Id: <5CAC89C9-59E9-4137-A33C-A65D9D73AA0B@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DC1D4ADE-8329-4934-BB0C-BBCD62D5ACB7"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Wed, 23 Dec 2020 13:57:06 -0500
In-Reply-To: 
Cc: LAMPS 
To: "Dang, Quynh H. (Fed)" 
References:   <17C5AA81-30C1-48BD-A919-1D0F78C936C5@sn3rd.com> <50CE7489-C6DD-45A9-8B5A-2B97E74ACC0C@vigilsec.com> 
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2020 18:57:15 -0000

--Apple-Mail=_DC1D4ADE-8329-4934-BB0C-BBCD62D5ACB7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Quynh:

It is making the same recommendation at RFC 5084.  See the last sentence =
in Section 3.2 of RFC 5084.

Russ

> On Dec 23, 2020, at 1:31 PM, Dang, Quynh H. (Fed) =
 wrote:
>=20
> Hi Russ,
>=20
> 12 octets are fine for many use cases.=20
>=20
> I am wondering why that size is Recommended (to save 4 bytes ?).
>=20
> Regards,
> Quynh.=20
> From: Spasm > =
on behalf of Russ Housley >
> Sent: Wednesday, December 23, 2020 12:12 PM
> To: Sean Turner >
> Cc: LAMPS >
> Subject: Re: [lamps] WG Last Call for =
draft-ietf-lamps-cms-aes-gmac-alg
> =20
> Sean, you are talking about Section 3.4 (not 3.1), I think.  If that =
is correct, then I suggest:
>=20
>    The GMACParameters nonce field is the GMAC initialization vector.
>    The nonce may have any number of bits between 8 and 2^64, but it =
MUST
>    be a multiple of 8 bits.  Within the scope of any GMAC key, the =
nonce
>    value MUST be unique.  A nonce value of 12 octets can be processed
>    more efficiently, so that length for the nonce value is =
RECOMMENDED.
>=20
>    The GMACParameters length field field tells the size of the
>    message authentication code in octets.  The length may have a value
>    between 12 and 16, inclusive.  A length of 12 octets is =
RECOMMENDED.
>=20
> Russ
>=20
> > On Dec 23, 2020, at 11:35 AM, Sean Turner > wrote:
> >=20
> > IANAC, but I did have a read of this draft and thought it looked =
like a fine candidate for progressing to the next stage.
> >=20
> > Minor nit that could be addressed later:
> >=20
> > To be all matchy-matchy with the last paragraph in s3.1 you could
> > s/nonce parameter/nonce parameter field
> > in the penultimate paragraph of s3.1.
> >=20
> > spt
> >=20
> >> On Dec 22, 2020, at 16:47, Tim Hollebeek =
> wrote:
> >>=20
> >> The comment period has ended, and no new feedback was received.  =
I=E2=80=99ll start pushing this forward.
> >>=20
> >> -Tim
> >>=20
> >> From: Spasm > On Behalf Of Tim Hollebeek
> >> Sent: Friday, December 4, 2020 4:17 PM
> >> To: LAMPS >
> >> Subject: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
> >>=20
> >> This is the LAMPS WG Last Call for "Using the AES-GMAC Algorithm =
with the Cryptographic Message Syntax (CMS)=E2=80=9D =
.  Please review the document and =
send your comments to the list by 18 December 2020.
> >>=20
> >> The datatracker page for the document is =
https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatr=
acker.ietf.org%2Fdoc%2Fdraft-ietf-lamps-cms-aes-gmac-alg%2F&data=3D04%=
7C01%7Cquynh.dang%40nist.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82f=
d8fa4797a93e054655c61dec%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZs=
b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2=
000&sdata=3DIo8posg3cBdQoVepGGnSai5E9VgYk3BCODMqablsdHI%3D&reserve=
d=3D0 =

> >>=20
> >> -Tim
> >> _______________________________________________
> >> Spasm mailing list
> >> Spasm@ietf.org 
> >> =
https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ie=
tf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D04%7C01%7Cquynh.dang%40nist=
.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa4797a93e054655c61dec=
%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi=
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3D8LKfeqo9=
718V2PBoM4xTaE4%2FfQhaaBUgVNo9T1X9tIs%3D&reserved=3D0 =

> >=20
> > _______________________________________________
> > Spasm mailing list
> > Spasm@ietf.org 
> > =
https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ie=
tf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D04%7C01%7Cquynh.dang%40nist=
.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa4797a93e054655c61dec=
%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi=
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3D8LKfeqo9=
718V2PBoM4xTaE4%2FfQhaaBUgVNo9T1X9tIs%3D&reserved=3D0 =

>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org 
> =
https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ie=
tf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D04%7C01%7Cquynh.dang%40nist=
.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa4797a93e054655c61dec=
%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi=
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3D8LKfeqo9=
718V2PBoM4xTaE4%2FfQhaaBUgVNo9T1X9tIs%3D&reserved=3D0 =

> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org 
> https://www.ietf.org/mailman/listinfo/spasm =


--Apple-Mail=_DC1D4ADE-8329-4934-BB0C-BBCD62D5ACB7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Quynh:

It =
is making the same recommendation at RFC 5084.  See the last =
sentence in Section 3.2 of RFC 5084.

Russ

On Dec =
23, 2020, at 1:31 PM, Dang, Quynh H. (Fed) <quynh.dang=3D40nist.gov@dmarc.ietf.org> =
wrote:

Hi =
Russ,

12 octets are fine for many use =
cases. 

I am wondering why that size is =
Recommended (to save 4 bytes ?).

Regards,
Quynh. 
From: Spasm <spasm-bounces@ietf.org> on behalf of Russ Housley =
<housley@vigilsec.com>
Sent: Wednesday, December 23, =
2020 12:12 PM
To: Sean Turner <sean@sn3rd.com>
Cc: LAMPS <spasm@ietf.org>
Subject: Re: [lamps] WG Last Call =
for draft-ietf-lamps-cms-aes-gmac-alg
 
Sean, you are talking about Section 3.4 (not 3.1), I =
think.  If that is correct, then I suggest:

   The GMACParameters nonce field is the GMAC =
initialization vector.
   The nonce may have any =
number of bits between 8 and 2^64, but it MUST
   =
be a multiple of 8 bits.  Within the scope of any GMAC key, the =
nonce
   value MUST be unique.  A nonce =
value of 12 octets can be processed
   more =
efficiently, so that length for the nonce value is RECOMMENDED.

   The GMACParameters length field =
field tells the size of the
   message =
authentication code in octets.  The length may have a value
   between 12 and 16, inclusive.  A length of =
12 octets is RECOMMENDED.

Russ

> On Dec 23, 2020, at 11:35 AM, Sean Turner =
<sean@sn3rd.com> =
wrote:
> 
> IANAC, =
but I did have a read of this draft and thought it looked like a fine =
candidate for progressing to the next stage.
> 
> Minor =
nit that could be addressed later:
> 
> To be =
all matchy-matchy with the last paragraph in s3.1 you could
> s/nonce parameter/nonce parameter field
>=
 in the penultimate paragraph of s3.1.
> 
> spt
> 
>> On Dec 22, 2020, at 16:47, Tim Hollebeek <tim.hollebeek=3D40digicert.com@dmarc.ietf.org> =
wrote:
>> 
>> The =
comment period has ended, and no new feedback was received.  I=E2=80=99=
ll start pushing this forward.
>> 
>> =
-Tim
>> 
>> =
From: Spasm <spasm-bounces@ietf.org> On Behalf Of Tim Hollebeek
>> Sent: Friday, December 4, 2020 4:17 PM
>> To: LAMPS <spasm@ietf.org>
>> Subject: =
[lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
>> 
>> This is the LAMPS WG Last Call for "Using the =
AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS)=E2=80=9D =
<draft-ietf-lamps-cms-aes-gmac-alg-00>.  Please review the =
document and send your comments to the list by 18 December 2020.
>> 
>> The datatracker page for the document is https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%=
2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lamps-cms-aes-gmac-alg%2F&=
;amp;data=3D04%7C01%7Cquynh.dang%40nist.gov%7Cf6db9786858545b5790b08d8a765=
f3e0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637443403620987942%7CUnk=
nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ=
XVCI6Mn0%3D%7C2000&amp;sdata=3DIo8posg3cBdQoVepGGnSai5E9VgYk3BCODMqabl=
sdHI%3D&amp;reserved=3D0
>> 
>> =
-Tim
>> =
_______________________________________________
>> =
Spasm mailing list
>> Spasm@ietf.org
>> https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%=
2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=3D04%7C01%7Cqu=
ynh.dang%40nist.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa4797a=
93e054655c61dec%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8eyJWI=
joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&a=
mp;sdata=3D8LKfeqo9718V2PBoM4xTaE4%2FfQhaaBUgVNo9T1X9tIs%3D&amp;reserv=
ed=3D0
> 
> =
_______________________________________________
> Spasm =
mailing list
> Spasm@ietf.org
> https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%=
2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=3D04%7C01%7Cqu=
ynh.dang%40nist.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa4797a=
93e054655c61dec%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8eyJWI=
joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&a=
mp;sdata=3D8LKfeqo9718V2PBoM4xTaE4%2FfQhaaBUgVNo9T1X9tIs%3D&amp;reserv=
ed=3D0

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%=
2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=3D04%7C01%7Cqu=
ynh.dang%40nist.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa4797a=
93e054655c61dec%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8eyJWI=
joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&a=
mp;sdata=3D8LKfeqo9718V2PBoM4xTaE4%2FfQhaaBUgVNo9T1X9tIs%3D&amp;reserv=
ed=3D0
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

=

--Apple-Mail=_DC1D4ADE-8329-4934-BB0C-BBCD62D5ACB7--


From nobody Wed Dec 23 10:57:27 2020
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 F36853A0827; Wed, 23 Dec 2020 10:57:25 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: spasm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: spasm@ietf.org
Message-ID: <160874984595.16042.7198986969132155460@ietfa.amsl.com>
Date: Wed, 23 Dec 2020 10:57:25 -0800
Archived-At: 
Subject: [lamps] I-D Action: draft-ietf-lamps-cms-aes-gmac-alg-01.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2020 18:57:26 -0000

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

        Title           : Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS)
        Author          : Russ Housley
	Filename        : draft-ietf-lamps-cms-aes-gmac-alg-01.txt
	Pages           : 7
	Date            : 2020-12-23

Abstract:
   This document specifies the conventions for using the AES-GMAC
   Message Authentication Code algorithms with the Cryptographic Message
   Syntax (CMS) as specified in RFC 5652.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-aes-gmac-alg/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lamps-cms-aes-gmac-alg-01
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-aes-gmac-alg-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-aes-gmac-alg-01


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

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



From nobody Wed Dec 23 10:58:36 2020
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 9F8103A0811 for ; Wed, 23 Dec 2020 10:58:34 -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, 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 eWSN9LqFj5CW for ; Wed, 23 Dec 2020 10:58: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 19FDF3A0876 for ; Wed, 23 Dec 2020 10:58:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A8236300BBC for ; Wed, 23 Dec 2020 13:58: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 4-r4kivlk5WY for ; Wed, 23 Dec 2020 13:58:26 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 86B9D300ADB for ; Wed, 23 Dec 2020 13:58:26 -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.17\))
Date: Wed, 23 Dec 2020 13:58:28 -0500
References: <160874984612.16042.16771299600697699996@ietfa.amsl.com>
To: LAMPS 
In-Reply-To: <160874984612.16042.16771299600697699996@ietfa.amsl.com>
Message-Id: <7C427FA1-BF14-4E35-B17D-E37D1442838C@vigilsec.com>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] New Version Notification for draft-ietf-lamps-cms-aes-gmac-alg-01.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2020 18:58:35 -0000

This revision is making the change discussed a few minutes ago in =
Section 3.1.

Russ


> A new version of I-D, draft-ietf-lamps-cms-aes-gmac-alg-01.txt
> has been successfully submitted by Russ Housley and posted to the
> IETF repository.
>=20
> Name:		draft-ietf-lamps-cms-aes-gmac-alg
> Revision:	01
> Title:		Using the AES-GMAC Algorithm with the =
Cryptographic Message Syntax (CMS)
> Document date:	2020-12-23
> Group:		lamps
> Pages:		7
> URL:            =
https://www.ietf.org/archive/id/draft-ietf-lamps-cms-aes-gmac-alg-01.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-aes-gmac-alg/
> Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-aes-gmac-alg
> Htmlized:       =
https://tools.ietf.org/html/draft-ietf-lamps-cms-aes-gmac-alg-01
> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-aes-gmac-alg-01
>=20
> Abstract:
>   This document specifies the conventions for using the AES-GMAC
>   Message Authentication Code algorithms with the Cryptographic =
Message
>   Syntax (CMS) as specified in RFC 5652.


From nobody Wed Dec 30 10:00:11 2020
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 EBF933A0B05 for ; Wed, 30 Dec 2020 10:00:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=digicert.com header.b=ac5/6XMf; dkim=pass (1024-bit key) header.d=digicert.com header.b=Mn7raRYe
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 8thtyaccWkjv for ; Wed, 30 Dec 2020 10:00:07 -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 2B0743A0B08 for ; Wed, 30 Dec 2020 10:00:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1609351206; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=b+DcuJKHQlplTChXSp4MXS+fttoIu3Q0VPV4eOShqwM=; b=ac5/6XMfylurj9aR3xjUAxf4RTUk1sIC1vToHRT8NdzLbrcfa8wOQ5LLpRc47rBvk63rHR PfHAflVAb4m+zl8A215gGPga/2Xxt4jhfqij0fa2Bhs8XR8gf+zq9+Fb1OCPtDzWODjkfv 5r1dS79Suo0hiFBBR0BcCTvlcTBug2U=
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2169.outbound.protection.outlook.com [104.47.59.169]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-458-YOBdnVjQOESMudAEk5zKPQ-1; Wed, 30 Dec 2020 13:00:02 -0500
X-MC-Unique: YOBdnVjQOESMudAEk5zKPQ-1
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mH9rDKmdVsumb5ns7mlfnBRd+8e19jIhiDh4vR5rYaE8g06IZ21KbuItua5gMgGcWaAnSy17FQbvPVeXBJBcC8jr2iRYtXKuU0NqXyV9FyOoZCZ/MX6WbEO26v/842Oy5LIAYUObiMcXpqP7xXqQLiRQQ8Wgj24rUJa7FPSTC0wSDReLMFU5Dt2K4h5ULW+HgqL5j7tenkQK9QnDto3BpfIBF2+sjMLR469ymhS2qo0IOFNGaEgqhsg9FX5hOqxIia14dJR8KKgxwv1nKa2Py0bQhk+LN7kLPrFQOBeFFtRxxK8l9HDnad+oQJ3O+u7TpCSMJMHXBgZzS+trUlu9hg==
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=b+DcuJKHQlplTChXSp4MXS+fttoIu3Q0VPV4eOShqwM=; b=iMq56CeAUQG9b3CMATx44s6TP8zHeAUkDoQPOgm9ttXLWVw8cUXltOOSRFB065q860XI4ikOaSRXJUFo6ux1hDY/uiHOeQ9SYBbePB+IwbZS5UwQWwgbJ7ewl5HBJRvX6ollTKyWFZ1Z7va7xeitMBoq0qEpJun9IAe4ecBfznuCh/1xpI2H+MRi/6719NY7EU3gCEJHcm45HpcxdLLgdUgDoh4ctLfNZwPCOW8hJSF8yCh0NDZOYgj0o2cIvum3Pt6wURzIkrOuCyoYlb5NruKGEubEfJbno6FyLk9iaDCveNeccaakVcCLpF9nfVqbuu7CcuDPv8wXFEgbyadM+w==
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=b+DcuJKHQlplTChXSp4MXS+fttoIu3Q0VPV4eOShqwM=; b=Mn7raRYe7Dkp7Mws4sZxGKc4p7AA4A+yzoqEiJNwDfzrWbLAS6N3lmt8CHV2YS2H/qx1SyFz/BZPZf0V48KC6htxgliQ74qh1RzYN1jl9bCe/SQ+xuOJ3wnOcUKhSwxvkPILBCPDXdT3R0dWv6ADJhIExY9fs5KjFjrOX4bGfxk=
Received: from MN2PR14MB3167.namprd14.prod.outlook.com (2603:10b6:208:12e::28) by MN2PR14MB3359.namprd14.prod.outlook.com (2603:10b6:208:1ab::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.20; Wed, 30 Dec 2020 17:59:59 +0000
Received: from MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::7929:62d4:d59d:be5e]) by MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::7929:62d4:d59d:be5e%3]) with mapi id 15.20.3700.031; Wed, 30 Dec 2020 17:59:59 +0000
From: Tim Hollebeek 
To: Russ Housley , "Dang, Quynh H. (Fed)" 
CC: LAMPS 
Thread-Topic: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
Thread-Index: AdbKgl0GZVRVKEllR6iGycD6D5x5ZAOKY8ZwACdq0oAAAUuNAAACpdghAAEC2AABXgP8IA==
Date: Wed, 30 Dec 2020 17:59:58 +0000
Message-ID: 
References:   <17C5AA81-30C1-48BD-A919-1D0F78C936C5@sn3rd.com> <50CE7489-C6DD-45A9-8B5A-2B97E74ACC0C@vigilsec.com>  <5CAC89C9-59E9-4137-A33C-A65D9D73AA0B@vigilsec.com>
In-Reply-To: <5CAC89C9-59E9-4137-A33C-A65D9D73AA0B@vigilsec.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=digicert.com;
x-originating-ip: [74.111.113.115]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 60f125e4-ed91-41c1-4d6c-08d8acecb91a
x-ms-traffictypediagnostic: MN2PR14MB3359:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:2150;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: TsPnZe/doAgey2hDd8RfEFUK9+GFPeJbD/T7s1ckaUJbrwXMKUbfeegOPVt30bBJf9rKlqpd5i7m/7gOr/Bj7MqdO9OY9pu0PpYvxnbCNIc9voWLhjtmsit1/40Yev2UJqznLsptYzBZmiRVMCw2cB/gIAKwbhVLtbBsa0z/NzU9KlbabMOocMH0acfBtOnDI/xnAVjOR4dUZZqUWWwosXWhlxbuIZ05nbB/Jr2qbTPUHwjCx+s+YgMwhImN/6qa4H6rx1l6VJQqrd3QUxDcH11U5uRQlCeQ7bN/DlgtNbfg6OJNkyF101XVeMXPtaAvZB0Z66XIJdz/NZpz0yvdR9/fiA9IdyhI3x+GiB11mBSfaUMff2BsMH93m16QdjWlwcYa/Pk90S+g7aUXhs0WFuQXRerh9ut+RCMCoLhqb0fHMXeLRZjXIahcfnWgKBnvixKyxuMI2Z8mpaTBB9j7Pw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MN2PR14MB3167.namprd14.prod.outlook.com; PTR:; CAT:NONE;  SFS:(366004)(376002)(396003)(136003)(346002)(39850400004)(8676002)(52536014)(478600001)(44832011)(966005)(64756008)(45080400002)(9686003)(66556008)(76116006)(66946007)(66476007)(66616009)(66446008)(4326008)(2906002)(55016002)(71200400001)(7696005)(166002)(83380400001)(186003)(53546011)(6506007)(26005)(5660300002)(99936003)(8936002)(110136005)(316002)(33656002)(86362001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: =?utf-8?B?SG0wM1BLR0ZWdkl6dWJQWGkxZ0NLTzduU1RJbmxtT2hOMHVuR3hzT2NoeXhZ?= =?utf-8?B?blU3UFAxVllGTVg0ajV1NGYxU2xmdTVhckc0ZmdYelJhSlF4cm8xZG1RVFI1?= =?utf-8?B?d0JCazZFeitvTEU2Wm9kY2J0OXRRODBWOEFXalFrMGxvaVE5RTFidkE0bzNu?= =?utf-8?B?NjBBd1pSVm5uYTNIWlc0Y0toNVZWNndyYWVuVW8xai8vYUxqSStseUEwVXNm?= =?utf-8?B?Mm1nekhpMEZwNnY0RnlrU0JVZ2c3UXRVRGNQTVNWdWZKQW5HRzFrTTBuOUZr?= =?utf-8?B?RkNaR3o3VWFleTlWc2JpMnkrS0pLVXYyYXJ1QTFrNFE2S21hQjBjNWZyemNk?= =?utf-8?B?K2s4Wmlnb2ZXdDRNRnBRRVRxVitsMkdIcjh5WWdhMDlCOGs5SFFrcjVTbm1n?= =?utf-8?B?YjAvUTNPRVF4S2xZUjZXUG9vcS95SGQyeWFHMmcvU0twN2NhbllYaUZkM3ZK?= =?utf-8?B?QnY1RUJzalBvelplOEh4S1hnYk9VcDJ6Q3FCb0xzSXZmNnNwZzFMZWkwY3Mr?= =?utf-8?B?b1pSQnltOTlpT2V3bU9tYWV3ZUFQS2I3ZW1nVzJhK1FOdURYMHYzcmZ4K0d5?= =?utf-8?B?MEZEL1AyaDQrOEVsQkRaZUFUWjE5QmpKWnlCK1JEWnQ3cWd0Ynd5OXNUemN0?= =?utf-8?B?YnJSalIwUG9VcWFSWlg3VGlIUGxXZzhORVpSZVpYR0FacGo3WXRXaW5tT3dP?= =?utf-8?B?UkYwZk1hTXR5MGpoVzZVSTVmM1BReG8yL0F2eTArZ0trQjVMamVxSEQ3emUr?= =?utf-8?B?N29iRHh6dXl1ZzZzZmN0WWVUZEx3SVRkeU41UStTNXB4Q1hXK2o3OGpiNXRh?= =?utf-8?B?VUtkeVpLNVFvekJhdHRMOVNFQnNON3RGaVk3VTdzblIvdFU0UUx0Zk9oSVgv?= =?utf-8?B?cnVuVWpWb2d1MU1KRjBhWU8xNnFNM1JOS2VDMVBzODNWOGdFaGY2Y3pHenov?= =?utf-8?B?emt6QisyUFlmQXFTN0pwbmR0V3FpNWpnQmJPMnM0TE55V256aXlvelU0WnhF?= =?utf-8?B?RzB2aFpEeENXdUNaR2VoUGt3UlNVZnMzRXRDOXJoeDF6MHRGWXplK3hxUEpl?= =?utf-8?B?aHEybm0xZFNyYXVLd21lSUVYTDZ6d1BtaUYvblM2VnowREJWdHpzNUo2M0ps?= =?utf-8?B?QjVaNWd1SkFiWTcwa0NVNGhGOWRESTgrYzFxdFRJN0tORGFrN25UQ3dGbldt?= =?utf-8?B?YWwzOWpIaDVxK2c1SXF4UXl6NjVIQ2pqQnFYc290YTlEa0UvR2hWY2s1ZEg5?= =?utf-8?B?MHlaWVJEWXVWWXNMa0NPMGhiTERvMnpZUjYxbUsxNXJkSE81RnV1alg1U2xa?= =?utf-8?Q?cGcJkLaT79JQc=3D?=
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_04B1_01D6DEAB.ACEE7190"
MIME-Version: 1.0
X-OriginatorOrg: digicert.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR14MB3167.namprd14.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 60f125e4-ed91-41c1-4d6c-08d8acecb91a
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Dec 2020 17:59:58.9234 (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: 4SE3ZcsAcbunnGjsyXEmlK8RcXx1xLtnZOxvm8rLoMjB9mDhQHhx5B2DWjwK/M2pYSInChUx8yeCpnjeYdP3pUK4Deinv1HhnOh5avYlLoU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB3359
Archived-At: 
Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Dec 2020 18:00:10 -0000

------=_NextPart_000_04B1_01D6DEAB.ACEE7190
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_04B2_01D6DEAB.ACEE7190"


------=_NextPart_001_04B2_01D6DEAB.ACEE7190
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I think it=E2=80=99s worth calling that out in the comment, so the =
reader knows where the recommendation comes from and can use RFC 5084 to =
help evaluate the recommendation.

=20

Am I wrong?

=20

-Tim

=20

From: Spasm  On Behalf Of Russ Housley
Sent: Wednesday, December 23, 2020 1:57 PM
To: Dang, Quynh H. (Fed) 
Cc: LAMPS 
Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg

=20

Quynh:

=20

It is making the same recommendation at RFC 5084.  See the last sentence =
in Section 3.2 of RFC 5084.

=20

Russ





On Dec 23, 2020, at 1:31 PM, Dang, Quynh H. (Fed) =
 > wrote:

=20

Hi Russ,

=20

12 octets are fine for many use cases.=20

=20

I am wondering why that size is Recommended (to save 4 bytes ?).

=20

Regards,

Quynh.=20

  _____ =20

From: Spasm  > on =
behalf of Russ Housley  >
Sent: Wednesday, December 23, 2020 12:12 PM
To: Sean Turner  >
Cc: LAMPS  >
Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg

=20

Sean, you are talking about Section 3.4 (not 3.1), I think.  If that is =
correct, then I suggest:

   The GMACParameters nonce field is the GMAC initialization vector.
   The nonce may have any number of bits between 8 and 2^64, but it MUST
   be a multiple of 8 bits.  Within the scope of any GMAC key, the nonce
   value MUST be unique.  A nonce value of 12 octets can be processed
   more efficiently, so that length for the nonce value is RECOMMENDED.

   The GMACParameters length field field tells the size of the
   message authentication code in octets.  The length may have a value
   between 12 and 16, inclusive.  A length of 12 octets is RECOMMENDED.

Russ

> On Dec 23, 2020, at 11:35 AM, Sean Turner  > wrote:
>=20
> IANAC, but I did have a read of this draft and thought it looked like =
a fine candidate for progressing to the next stage.
>=20
> Minor nit that could be addressed later:
>=20
> To be all matchy-matchy with the last paragraph in s3.1 you could
> s/nonce parameter/nonce parameter field
> in the penultimate paragraph of s3.1.
>=20
> spt
>=20
>> On Dec 22, 2020, at 16:47, Tim Hollebeek =
 > wrote:
>>=20
>> The comment period has ended, and no new feedback was received.  =
I=E2=80=99ll start pushing this forward.
>>=20
>> -Tim
>>=20
>> From: Spasm  > =
On Behalf Of Tim Hollebeek
>> Sent: Friday, December 4, 2020 4:17 PM
>> To: LAMPS  >
>> Subject: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
>>=20
>> This is the LAMPS WG Last Call for "Using the AES-GMAC Algorithm with =
the Cryptographic Message Syntax (CMS)=E2=80=9D =
.  Please review the document and =
send your comments to the list by 18 December 2020.
>>=20
>> The datatracker page for the document is =
https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat=
racker.ietf.org%2Fdoc%2Fdraft-ietf-lamps-cms-aes-gmac-alg%2F =
 =
&data=3D04%7C01%7Cquynh.dang%40nist.gov%7Cf6db9786858545b5790b08d8a76=
5f3e0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637443403620987942%7CU=
nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi=
LCJXVCI6Mn0%3D%7C2000&sdata=3DIo8posg3cBdQoVepGGnSai5E9VgYk3BCODMqabl=
sdHI%3D&reserved=3D0
>>=20
>> -Tim
>> _______________________________________________
>> Spasm mailing list
>> Spasm@ietf.org =20
>> =
https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i=
etf.org%2Fmailman%2Flistinfo%2Fspasm =
 =
&data=3D04%7C01%7Cquynh.dang%40nist.gov%7Cf6db9786858545b5790b08d8a76=
5f3e0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637443403620987942%7CU=
nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi=
LCJXVCI6Mn0%3D%7C2000&sdata=3D8LKfeqo9718V2PBoM4xTaE4%2FfQhaaBUgVNo9T=
1X9tIs%3D&reserved=3D0
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org =20
> =
https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i=
etf.org%2Fmailman%2Flistinfo%2Fspasm =
 =
&data=3D04%7C01%7Cquynh.dang%40nist.gov%7Cf6db9786858545b5790b08d8a76=
5f3e0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637443403620987942%7CU=
nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi=
LCJXVCI6Mn0%3D%7C2000&sdata=3D8LKfeqo9718V2PBoM4xTaE4%2FfQhaaBUgVNo9T=
1X9tIs%3D&reserved=3D0

_______________________________________________
Spasm mailing list
Spasm@ietf.org =20
https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i=
etf.org%2Fmailman%2Flistinfo%2Fspasm =
 =
&data=3D04%7C01%7Cquynh.dang%40nist.gov%7Cf6db9786858545b5790b08d8a76=
5f3e0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637443403620987942%7CU=
nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi=
LCJXVCI6Mn0%3D%7C2000&sdata=3D8LKfeqo9718V2PBoM4xTaE4%2FfQhaaBUgVNo9T=
1X9tIs%3D&reserved=3D0

_______________________________________________
Spasm mailing list
  Spasm@ietf.org
  =
https://www.ietf.org/mailman/listinfo/spasm

=20


------=_NextPart_001_04B2_01D6DEAB.ACEE7190
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I think it=E2=80=99s worth =
calling that out in the comment, so the reader knows where the =
recommendation comes from and can use RFC 5084 to help evaluate the =
recommendation.
 
Am I =
wrong?
 
-Tim
 
From: Spasm =
<spasm-bounces@ietf.org> On Behalf Of Russ =
Housley
Sent: Wednesday, December 23, 2020 1:57 =
PM
To: Dang, Quynh H. (Fed) =
<quynh.dang=3D40nist.gov@dmarc.ietf.org>
Cc: LAMPS =
<spasm@ietf.org>
Subject: Re: [lamps] WG Last Call for =
draft-ietf-lamps-cms-aes-gmac-alg
 
Quynh:
 
It is making the same recommendation at RFC 5084. =
 See the last sentence in Section 3.2 of RFC =
5084.
 
Russ


On Dec 23, 2020, at 1:31 PM, Dang, Quynh H. (Fed) =
<quynh.dang=3D40nis=
t.gov@dmarc.ietf.org> wrote:
 
Hi =
Russ,
 
12 octets are fine =
for many use cases. 
 
I am wondering why =
that size is Recommended (to save 4 bytes =
?).
 
Regards,
Quynh. 
From: Spasm <spasm-bounces@ietf.org> on =
behalf of Russ Housley <housley@vigilsec.com>
S=
ent: Wednesday, =
December 23, 2020 12:12 PM
To: Sean Turner <sean@sn3rd.com>
Cc: LAMPS <spasm@ietf.org>
Subject:<=
span class=3Dapple-converted-space> Re: [lamps] WG Last Call =
for draft-ietf-lamps-cms-aes-gmac-alg<=
/span>
 <=
/o:p>
Sean, you are talking about =
Section 3.4 (not 3.1), I think.  If that is correct, then I =
suggest:

   The GMACParameters nonce field is the GMAC =
initialization vector.
   The nonce may have any number of =
bits between 8 and 2^64, but it MUST
   be a multiple of 8 =
bits.  Within the scope of any GMAC key, the nonce
   =
value MUST be unique.  A nonce value of 12 octets can be =
processed
   more efficiently, so that length for the nonce =
value is RECOMMENDED.

   The GMACParameters length =
field field tells the size of the
   message authentication =
code in octets.  The length may have a value
   =
between 12 and 16, inclusive.  A length of 12 octets is =
RECOMMENDED.

Russ

> On Dec 23, 2020, at 11:35 AM, Sean =
Turner <sean@sn3rd.com> =
wrote:
> 
> =
IANAC, but I did have a read of this draft and thought it looked like a =
fine candidate for progressing to the next stage.
> 
> Minor nit that could =
be addressed later:
> 
> To be all =
matchy-matchy with the last paragraph in s3.1 you could
> s/nonce =
parameter/nonce parameter field
> in the penultimate paragraph of =
s3.1.
> 
> =
spt
> 
>> =
On Dec 22, 2020, at 16:47, Tim Hollebeek <tim.hollebe=
ek=3D40digicert.com@dmarc.ietf.org> wrote:
>> 
>> The comment =
period has ended, and no new feedback was received.  I=E2=80=99ll =
start pushing this forward.
>> 
>> =
-Tim
>> 
>> From: Spasm =
<spasm-bounces@ietf.org> On =
Behalf Of Tim Hollebeek
>> Sent: Friday, December 4, 2020 4:17 =
PM
>> To: LAMPS <spasm@ietf.org>
>> =
Subject: [lamps] WG Last Call for =
draft-ietf-lamps-cms-aes-gmac-alg
>> 
>> This is the =
LAMPS WG Last Call for "Using the AES-GMAC Algorithm with the =
Cryptographic Message Syntax (CMS)=E2=80=9D =
<draft-ietf-lamps-cms-aes-gmac-alg-00>.  Please review the =
document and send your comments to the list by 18 December =
2020.
>> 
>> The datatracker =
page for the document is https://gcc02.safelinks.protection.outlo=
ok.com/?url=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lamps=
-cms-aes-gmac-alg%2F&amp;data=3D04%7C01%7Cquynh.dang%40nist.gov%7Cf6d=
b9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%=
7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi=
V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=3DIo8posg3cBd=
QoVepGGnSai5E9VgYk3BCODMqablsdHI%3D&amp;reserved=3D0
>><=
span class=3Dapple-converted-space> 
>> =
-Tim
>> =
_______________________________________________
>> Spasm =
mailing list
>> Spasm@ietf.org
>> https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A=
%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=3D04%7C01%7C=
quynh.dang%40nist.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa47=
97a93e054655c61dec%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8e=
yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&=
amp;amp;sdata=3D8LKfeqo9718V2PBoM4xTaE4%2FfQhaaBUgVNo9T1X9tIs%3D&amp;=
reserved=3D0
> 
> =
_______________________________________________
> Spasm mailing =
list
> Spasm@ietf.org
> https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A=
%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=3D04%7C01%7C=
quynh.dang%40nist.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa47=
97a93e054655c61dec%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8e=
yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&=
amp;amp;sdata=3D8LKfeqo9718V2PBoM4xTaE4%2FfQhaaBUgVNo9T1X9tIs%3D&amp;=
reserved=3D0

_______________________________________________Spasm mailing list
Spasm@ietf.org
https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A=
%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=3D04%7C01%7C=
quynh.dang%40nist.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa47=
97a93e054655c61dec%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8e=
yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&=
amp;amp;sdata=3D8LKfeqo9718V2PBoM4xTaE4%2FfQhaaBUgVNo9T1X9tIs%3D&amp;=
reserved=3D0
____________=
___________________________________
Spasm mailing list
Spasm@ietf.o=
rg
<=
a href=3D"https://www.ietf.org/mailman/listinfo/spasm">https://www.=
ietf.org/mailman/listinfo/spasm
 

------=_NextPart_001_04B2_01D6DEAB.ACEE7190--

------=_NextPart_000_04B1_01D6DEAB.ACEE7190
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
CQUxDxcNMjAxMjMwMTc1OTU3WjAvBgkqhkiG9w0BCQQxIgQgxLG19/W2T4cB7ExxURIn5UAD9JxD
OqRj9JWjwwDazFcwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp
Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw
ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth
tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq
hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG
SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA
BIIBAExlijMoT/rMcT3v9VaFe6PpTlxziaqYBE6J6mix73PxKUYSMZ3dcWvtVlHUwlC+2AfBF2JG
ZJafpL5QOOFcEV8ZkPtJKjFyD40SBewtA7KrruC9pdx9veLeFOi9KXEXNqsECmk6RJGJE9VkjJCV
MYmw7B2jmzDeRMyuI5BjCzKNkZRfWLFJlO8NrqBcd7M+6wQhrfGRfZZqMdrYIivRYlvQvXJajUuH
7KijGdFYjxXh1Ex//ecJeyU3RHsXdPb/XBwKzRn4vU2DtqcGCWAyEYZB8Jx/4V9aPkrF40ZG80Ho
uPu0XpmNGIlr5kb6oeeIueCHvcx2RwHzPYCcr81GxYkAAAAAAAA=

------=_NextPart_000_04B1_01D6DEAB.ACEE7190--


From nobody Wed Dec 30 10:06:21 2020
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 55E353A0B21 for ; Wed, 30 Dec 2020 10:06:19 -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, 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 AQW0y7iUpkht for ; Wed, 30 Dec 2020 10:06:16 -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 767103A09B5 for ; Wed, 30 Dec 2020 10:06:16 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DB12F300BB1 for ; Wed, 30 Dec 2020 13:06:13 -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 bocRYApLy0Pf for ; Wed, 30 Dec 2020 13:06:10 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 6913E300AB0; Wed, 30 Dec 2020 13:06:10 -0500 (EST)
From: Russ Housley 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_78322AA4-91E2-467A-A5AD-C89DD6701438"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Wed, 30 Dec 2020 13:06:11 -0500
In-Reply-To: 
Cc: LAMPS 
To: Tim Hollebeek 
References:   <17C5AA81-30C1-48BD-A919-1D0F78C936C5@sn3rd.com> <50CE7489-C6DD-45A9-8B5A-2B97E74ACC0C@vigilsec.com>  <5CAC89C9-59E9-4137-A33C-A65D9D73AA0B@vigilsec.com> 
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Dec 2020 18:06:19 -0000

--Apple-Mail=_78322AA4-91E2-467A-A5AD-C89DD6701438
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Sure.  I'll add a paragraph to the Implementation Considerations that =
says so.

Russ

> On Dec 30, 2020, at 12:59 PM, Tim Hollebeek =
 wrote:
>=20
> I think it=E2=80=99s worth calling that out in the comment, so the =
reader knows where the recommendation comes from and can use RFC 5084 to =
help evaluate the recommendation.
> =20
> Am I wrong?
> =20
> -Tim
> =20
> From: Spasm > =
On Behalf Of Russ Housley
> Sent: Wednesday, December 23, 2020 1:57 PM
> To: Dang, Quynh H. (Fed) >
> Cc: LAMPS >
> Subject: Re: [lamps] WG Last Call for =
draft-ietf-lamps-cms-aes-gmac-alg
> =20
> Quynh:
> =20
> It is making the same recommendation at RFC 5084.  See the last =
sentence in Section 3.2 of RFC 5084.
> =20
> Russ
>=20
>=20
> On Dec 23, 2020, at 1:31 PM, Dang, Quynh H. (Fed) =
> wrote:
> =20
> Hi Russ,
> =20
> 12 octets are fine for many use cases.=20
> =20
> I am wondering why that size is Recommended (to save 4 bytes ?).
> =20
> Regards,
> Quynh.=20
> From: Spasm > =
on behalf of Russ Housley >
> Sent: Wednesday, December 23, 2020 12:12 PM
> To: Sean Turner >
> Cc: LAMPS >
> Subject: Re: [lamps] WG Last Call for =
draft-ietf-lamps-cms-aes-gmac-alg
> =20
> Sean, you are talking about Section 3.4 (not 3.1), I think.  If that =
is correct, then I suggest:
>=20
>    The GMACParameters nonce field is the GMAC initialization vector.
>    The nonce may have any number of bits between 8 and 2^64, but it =
MUST
>    be a multiple of 8 bits.  Within the scope of any GMAC key, the =
nonce
>    value MUST be unique.  A nonce value of 12 octets can be processed
>    more efficiently, so that length for the nonce value is =
RECOMMENDED.
>=20
>    The GMACParameters length field field tells the size of the
>    message authentication code in octets.  The length may have a value
>    between 12 and 16, inclusive.  A length of 12 octets is =
RECOMMENDED.
>=20
> Russ
>=20
> > On Dec 23, 2020, at 11:35 AM, Sean Turner > wrote:
> >=20
> > IANAC, but I did have a read of this draft and thought it looked =
like a fine candidate for progressing to the next stage.
> >=20
> > Minor nit that could be addressed later:
> >=20
> > To be all matchy-matchy with the last paragraph in s3.1 you could
> > s/nonce parameter/nonce parameter field
> > in the penultimate paragraph of s3.1.
> >=20
> > spt
> >=20
> >> On Dec 22, 2020, at 16:47, Tim Hollebeek =
> wrote:
> >>=20
> >> The comment period has ended, and no new feedback was received.  =
I=E2=80=99ll start pushing this forward.
> >>=20
> >> -Tim
> >>=20
> >> From: Spasm > On Behalf Of Tim Hollebeek
> >> Sent: Friday, December 4, 2020 4:17 PM
> >> To: LAMPS >
> >> Subject: [lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
> >>=20
> >> This is the LAMPS WG Last Call for "Using the AES-GMAC Algorithm =
with the Cryptographic Message Syntax (CMS)=E2=80=9D =
.  Please review the document and =
send your comments to the list by 18 December 2020.
> >>=20
> >> The datatracker page for the document is =
https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatr=
acker.ietf.org%2Fdoc%2Fdraft-ietf-lamps-cms-aes-gmac-alg%2F&data=3D04%=
7C01%7Cquynh.dang%40nist.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82f=
d8fa4797a93e054655c61dec%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZs=
b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2=
000&sdata=3DIo8posg3cBdQoVepGGnSai5E9VgYk3BCODMqablsdHI%3D&reserve=
d=3D0 =

> >>=20
> >> -Tim
> >> _______________________________________________
> >> Spasm mailing list
> >> Spasm@ietf.org 
> >> =
https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ie=
tf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D04%7C01%7Cquynh.dang%40nist=
.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa4797a93e054655c61dec=
%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi=
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3D8LKfeqo9=
718V2PBoM4xTaE4%2FfQhaaBUgVNo9T1X9tIs%3D&reserved=3D0 =

> >=20
> > _______________________________________________
> > Spasm mailing list
> > Spasm@ietf.org 
> > =
https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ie=
tf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D04%7C01%7Cquynh.dang%40nist=
.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa4797a93e054655c61dec=
%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi=
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3D8LKfeqo9=
718V2PBoM4xTaE4%2FfQhaaBUgVNo9T1X9tIs%3D&reserved=3D0 =

>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org 
> =
https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ie=
tf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D04%7C01%7Cquynh.dang%40nist=
.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa4797a93e054655c61dec=
%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi=
LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3D8LKfeqo9=
718V2PBoM4xTaE4%2FfQhaaBUgVNo9T1X9tIs%3D&reserved=3D0 =

> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org 
> https://www.ietf.org/mailman/listinfo/spasm =


--Apple-Mail=_78322AA4-91E2-467A-A5AD-C89DD6701438
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Sure.=
  I'll add a paragraph to the Implementation Considerations =
that says so.


Russ

On Dec 30, 2020, at 12:59 PM, Tim Hollebeek <tim.hollebeek@digicert.com> wrote:

I think it=E2=80=99s worth =
calling that out in the comment, so the reader knows where the =
recommendation comes from and can use RFC 5084 to help evaluate the =
recommendation.
 
Am I wrong?
 
-Tim
 
From: Spasm <spasm-bounces@ietf.org> On Behalf =
Of Russ Housley
Sent: Wednesday, December 23, =
2020 1:57 PM
To: Dang, Quynh H. (Fed) <quynh.dang=3D40nist.gov@dmarc.ietf.org>
Cc: LAMPS <spasm@ietf.org>
Subject: Re: [lamps] WG Last Call =
for draft-ietf-lamps-cms-aes-gmac-alg
 
Quynh:
 
It =
is making the same recommendation at RFC 5084.  See the last =
sentence in Section 3.2 of RFC 5084.
 
Russ


On =
Dec 23, 2020, at 1:31 PM, Dang, Quynh H. (Fed) <quynh.dang=3D40nist.gov@dmarc.ietf.org> wrote:
 
Hi =
Russ,
 
12 =
octets are fine for many use cases. 
 
I am =
wondering why that size is Recommended (to save 4 bytes ?).
 
Regards,
Quynh. 
From: Spasm <spasm-bounces@ietf.org> =
on behalf of Russ Housley <housley@vigilsec.com>
Sent: Wednesday, December 23, =
2020 12:12 PM
To: Sean Turner <sean@sn3rd.com>
Cc: LAMPS=
 <spasm@ietf.org>
Subject: Re: [lamps] WG Last Call =
for draft-ietf-lamps-cms-aes-gmac-alg
 
Sean, you are talking about Section =
3.4 (not 3.1), I think.  If that is correct, then I suggest:

   The GMACParameters nonce field is =
the GMAC initialization vector.
   The nonce may =
have any number of bits between 8 and 2^64, but it MUST
   be a multiple of 8 bits.  Within the scope =
of any GMAC key, the nonce
   value MUST be =
unique.  A nonce value of 12 octets can be processed
   more efficiently, so that length for the nonce =
value is RECOMMENDED.

   The =
GMACParameters length field field tells the size of the
   message authentication code in octets.  The =
length may have a value
   between 12 and 16, =
inclusive.  A length of 12 octets is RECOMMENDED.

Russ

> On Dec 23, 2020, at =
11:35 AM, Sean Turner <sean@sn3rd.com> wrote:
> 
> IANAC, =
but I did have a read of this draft and thought it looked like a fine =
candidate for progressing to the next stage.
> 
> Minor =
nit that could be addressed later:
> 
> To be =
all matchy-matchy with the last paragraph in s3.1 you could
> s/nonce parameter/nonce parameter field
>=
 in the penultimate paragraph of s3.1.
> 
> spt
> 
>> On Dec 22, 2020, at 16:47, Tim Hollebeek <tim.hollebeek=3D40digicert.com@dmarc.ietf.org> =
wrote:
>> 
>> The =
comment period has ended, and no new feedback was received.  I=E2=80=99=
ll start pushing this forward.
>> 
>> =
-Tim
>> 
>> =
From: Spasm <spasm-bounces@ietf.org> On Behalf Of Tim Hollebeek
>> Sent: Friday, December 4, 2020 4:17 PM
>> To: LAMPS <spasm@ietf.org>
>> Subject: =
[lamps] WG Last Call for draft-ietf-lamps-cms-aes-gmac-alg
>> 
>> This is the LAMPS WG Last Call for "Using the =
AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS)=E2=80=9D =
<draft-ietf-lamps-cms-aes-gmac-alg-00>.  Please review the =
document and send your comments to the list by 18 December 2020.
>> 
>> The datatracker page for the document is https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%=
2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lamps-cms-aes-gmac-alg%2F&=
;amp;data=3D04%7C01%7Cquynh.dang%40nist.gov%7Cf6db9786858545b5790b08d8a765=
f3e0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637443403620987942%7CUnk=
nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ=
XVCI6Mn0%3D%7C2000&amp;sdata=3DIo8posg3cBdQoVepGGnSai5E9VgYk3BCODMqabl=
sdHI%3D&amp;reserved=3D0
>> 
>> =
-Tim
>> =
_______________________________________________
>> =
Spasm mailing list
>> Spasm@ietf.org
>> https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%=
2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=3D04%7C01%7Cqu=
ynh.dang%40nist.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa4797a=
93e054655c61dec%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8eyJWI=
joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&a=
mp;sdata=3D8LKfeqo9718V2PBoM4xTaE4%2FfQhaaBUgVNo9T1X9tIs%3D&amp;reserv=
ed=3D0
> 
> =
_______________________________________________
> Spasm =
mailing list
> Spasm@ietf.org
> https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%=
2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=3D04%7C01%7Cqu=
ynh.dang%40nist.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa4797a=
93e054655c61dec%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8eyJWI=
joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&a=
mp;sdata=3D8LKfeqo9718V2PBoM4xTaE4%2FfQhaaBUgVNo9T1X9tIs%3D&amp;reserv=
ed=3D0

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%=
2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=3D04%7C01%7Cqu=
ynh.dang%40nist.gov%7Cf6db9786858545b5790b08d8a765f3e0%7C2ab5d82fd8fa4797a=
93e054655c61dec%7C1%7C0%7C637443403620987942%7CUnknown%7CTWFpbGZsb3d8eyJWI=
joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&a=
mp;sdata=3D8LKfeqo9718V2PBoM4xTaE4%2FfQhaaBUgVNo9T1X9tIs%3D&amp;reserv=
ed=3D0
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
=

--Apple-Mail=_78322AA4-91E2-467A-A5AD-C89DD6701438--


From nobody Wed Dec 30 10:11:36 2020
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 4C8173A0B2F; Wed, 30 Dec 2020 10:11:31 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: spasm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: spasm@ietf.org
Message-ID: <160935189125.28893.5519410869969425189@ietfa.amsl.com>
Date: Wed, 30 Dec 2020 10:11:31 -0800
Archived-At: 
Subject: [lamps] I-D Action: draft-ietf-lamps-cms-aes-gmac-alg-02.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Dec 2020 18:11:31 -0000

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

        Title           : Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS)
        Author          : Russ Housley
	Filename        : draft-ietf-lamps-cms-aes-gmac-alg-02.txt
	Pages           : 7
	Date            : 2020-12-30

Abstract:
   This document specifies the conventions for using the AES-GMAC
   Message Authentication Code algorithms with the Cryptographic Message
   Syntax (CMS) as specified in RFC 5652.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-aes-gmac-alg/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lamps-cms-aes-gmac-alg-02
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-aes-gmac-alg-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-aes-gmac-alg-02


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

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



From nobody Wed Dec 30 10:12:46 2020
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 51C043A0B32 for ; Wed, 30 Dec 2020 10:12: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, 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 tDLt-BqRWjdF for ; Wed, 30 Dec 2020 10:12:42 -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 B10253A0B2F for ; Wed, 30 Dec 2020 10:12:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 349DC300BA9 for ; Wed, 30 Dec 2020 13:12:40 -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 2BpKivnbjkgb for ; Wed, 30 Dec 2020 13:12:39 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 02497300AB0 for ; Wed, 30 Dec 2020 13:12:38 -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.17\))
Date: Wed, 30 Dec 2020 13:12:40 -0500
References: <160935189149.28893.4420482476543985220@ietfa.amsl.com>
To: LAMPS 
In-Reply-To: <160935189149.28893.4420482476543985220@ietfa.amsl.com>
Message-Id: <18536DE7-8005-4638-97CE-28C2C38DE379@vigilsec.com>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] New Version Notification for draft-ietf-lamps-cms-aes-gmac-alg-02.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Dec 2020 18:12:44 -0000

This revision adds the paragraph to the Implementation Considerations =
about the parameter structure alignment with RFC 5084.

Russ


> On Dec 30, 2020, at 1:11 PM, internet-drafts@ietf.org wrote:
>=20
>=20
> A new version of I-D, draft-ietf-lamps-cms-aes-gmac-alg-02.txt
> has been successfully submitted by Russ Housley and posted to the
> IETF repository.
>=20
> Name:		draft-ietf-lamps-cms-aes-gmac-alg
> Revision:	02
> Title:		Using the AES-GMAC Algorithm with the =
Cryptographic Message Syntax (CMS)
> Document date:	2020-12-30
> Group:		lamps
> Pages:		7
> URL:            =
https://www.ietf.org/archive/id/draft-ietf-lamps-cms-aes-gmac-alg-02.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-aes-gmac-alg/
> Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-aes-gmac-alg
> Htmlized:       =
https://tools.ietf.org/html/draft-ietf-lamps-cms-aes-gmac-alg-02
> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-aes-gmac-alg-02
>=20
> Abstract:
>   This document specifies the conventions for using the AES-GMAC
>   Message Authentication Code algorithms with the Cryptographic =
Message
>   Syntax (CMS) as specified in RFC 5652.
>=20
>=20
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> The IETF Secretariat
>=20
>=20


From nobody Wed Dec 30 11:23:43 2020
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 547273A0C2A; Wed, 30 Dec 2020 11:23:41 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Tim Hollebeek via Datatracker 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Cc: iesg-secretary@ietf.org, lamps-chairs@ietf.org, spasm@ietf.org, tim.hollebeek@digicert.com
Message-ID: <160935622132.23213.997195670917876879@ietfa.amsl.com>
Date: Wed, 30 Dec 2020 11:23:41 -0800
Archived-At: 
Subject: [lamps] Publication has been requested for draft-ietf-lamps-cms-aes-gmac-alg-02
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Dec 2020 19:23:42 -0000

Tim Hollebeek has requested publication of draft-ietf-lamps-cms-aes-gmac-alg-02 as Proposed Standard on behalf of the LAMPS working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-aes-gmac-alg/



From nobody Wed Dec 30 11:37:27 2020
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 E35053A0C43 for ; Wed, 30 Dec 2020 11:37:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=digicert.com header.b=M79fYZth; dkim=pass (1024-bit key) header.d=digicert.com header.b=iOpyxtf8
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 PfRZTY1uT73K for ; Wed, 30 Dec 2020 11:37:24 -0800 (PST)
Received: from us-smtp-delivery-173.mimecast.com (us-smtp-delivery-173.mimecast.com [216.205.24.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 16F133A0C40 for ; Wed, 30 Dec 2020 11:37:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1609357043; 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=zptsFVLMrCwZPj4AJ+JF+LP2PvH9xZLfG5tLm6KCQh8=; b=M79fYZthbswaOQiHn+ShFfqklE1l6CTzD4Yi0r2o6lgqcDconF7IqA/MJIuxFSSHLHUN1F Iv6tQiUC6NFUaqG/s/VIb2Om/XME4rM49kwXU25uJFdXSewueB81KamSnv5yFi+2mZRCUn V7NeKr5oR7VF0qdNLIDdxhgnIF29qN0=
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2104.outbound.protection.outlook.com [104.47.55.104]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-513--gJnk48ANKKS00GL48gDsg-1; Wed, 30 Dec 2020 14:37:20 -0500
X-MC-Unique: -gJnk48ANKKS00GL48gDsg-1
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WSk7fR+s3zd0j9F769XsdKCUZcC/aYGJVTGNFOSG9oCQXwOOdu0jF8hO/tdCN+TD+ayEN4QhHF+hQ4FNBkEXwXzuxHLh7D6C6vY3RHPh9QHHewhlsTHcwjPO77IO7az4b11+DfQmMuGWDxQ42M90RRlrVcOG+HC0KsMtyD7BNE5bgmp6vzA1v2yDpUfu9KFOr3nGuuA2eDqkxwpCNZ1gwnuQQ2g4DHGikFGgwtFoMTsnzb0Wpxw8M22l3Stt8S2e24SLxAlW/Lg78E1n7AWbRzIGkrsQwodiNRsKgyGtv09lgFe7zguzWZf2Gj+Q6TUd5gq3fQeJEDEpR5EjeNqhfA==
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=zptsFVLMrCwZPj4AJ+JF+LP2PvH9xZLfG5tLm6KCQh8=; b=ONJrO5xxLEKH9oW+B9EL7HWDgnH8oatYe0/7Oj8r1Qm2bCHA+fnRoFLj/6vwzW6oZzAabIpIKwmq8UvEdnLGMBxkGjNbMQ2m3/mcIzQusM1GVB+6p28H2slY7LyhVanE0hA0/JyiI5xWInepWqGnxW9yg6uANKS42HGag/vGKlC3bswAWcpB0fZOKDG08bB9pszjJEn9fM+V6gzriD52rOtuzPaqoSoyqLd0ZfX4YzdDFdbF4mDI5unhOvyDi63OlOfpPec2n0eoguyjiLfRULENTeQhwkNO0lLGRJ8l0Zc+Q54TKR9UAdxgKt7HgYuhIlmSnooThhwCW5Czrbyqyw==
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=zptsFVLMrCwZPj4AJ+JF+LP2PvH9xZLfG5tLm6KCQh8=; b=iOpyxtf8PAdrUD23tFCOQ7FcV3lCaPk8cDgylmNiq5Sv7tqt2PJ2KLfRM2c02oU1XjZUFZB/hACCZz/w+DSYcHd3bSF6JPDxRONFT4dGDTedZ0c8qeOjBeV5TwZTaIOn0GCxWBXEMppcsuTPzH0OsdltPqIQzpiJjx0vOHLSgMI=
Received: from MN2PR14MB3167.namprd14.prod.outlook.com (2603:10b6:208:12e::28) by MN2PR14MB2528.namprd14.prod.outlook.com (2603:10b6:208:ca::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.19; Wed, 30 Dec 2020 19:37:18 +0000
Received: from MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::7929:62d4:d59d:be5e]) by MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::7929:62d4:d59d:be5e%3]) with mapi id 15.20.3700.031; Wed, 30 Dec 2020 19:37:18 +0000
From: Tim Hollebeek 
To: LAMPS 
Thread-Topic: WG Last Call for draft-ietf-lamps-crmf-update-algs
Thread-Index: Adbe4kRpHs7+KJu/RXiZaDByfdDqcA==
Date: Wed, 30 Dec 2020 19:37:18 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=digicert.com;
x-originating-ip: [74.111.113.115]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 93fa990b-9d5f-4c31-2d4c-08d8acfa5194
x-ms-traffictypediagnostic: MN2PR14MB2528:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Yb/MW0Tyfjt4h2Ls7/j64UL5zA3+PCwwgZ1i2oT1QftgR1P3RNiV8Db3AAEL++tJpaMGVVCfuAaYkDYHqtRjmjuTbep1TUNzti9qrytYUEp5UhYAk3tRtrWDSej3nSX2/iKnUlNXUbdnkZlAzx2REtfnJdOQR/lKASU8CY+RbxhH+VgER1hgx98nu9VNi3yXi36OyEBwAcbCacjVzCKLSDgXdjs6ci71OqEfh/kth6x2zCQ7dr2lSopTPTvIrwZD9ku2xKSAPhZ852qnND2C//MaEW8FxxQe6yuTW5XYvx3CUczqjcZwHKcYVqBqptHgdSuv9fXTRJ3vVnjeFrkBLwwf9huUqWEai6Q+x/HOkyomr66GqovHsewL8YIpkMJm6qCTWg7lw0m4tw3UAKMShHTAA3hIpEp7/SbnNWpMIKB4QFlxYRtU/y/L6F3T5xR9bci27Pa5AuwR2bjChxGpWQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:MN2PR14MB3167.namprd14.prod.outlook.com; PTR:; CAT:NONE;  SFS:(396003)(346002)(136003)(366004)(376002)(39850400004)(83380400001)(166002)(5660300002)(186003)(26005)(316002)(66574015)(66446008)(86362001)(4744005)(55016002)(2906002)(15650500001)(71200400001)(33656002)(9686003)(52536014)(64756008)(44832011)(8936002)(66616009)(66476007)(6506007)(66556008)(478600001)(966005)(7696005)(99936003)(6916009)(8676002)(76116006)(66946007); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?DKlV4T/4n8cfrbtyfvWNwJvtyzD+KEsm5iD8jrk7cbk6UEiwo/a+XbYWCKq6?= =?us-ascii?Q?VFfU8qrnvkJyciN2QnAyal+5ZO3j8CDyH+FR5mg+sKajUCvqgOPuYzNUXwaD?= =?us-ascii?Q?NcFBATH9auvxW/ylTtA5Khgu1w0jrcySEhm03x0FofvEj6KgXyPMvTtolqyt?= =?us-ascii?Q?PHj28+Dw4f4fo09tNdeZaZRDuHyFnF4yp2D3z8TsoGIahnTphGB2RsK7DiqY?= =?us-ascii?Q?eGsnu2OAlyZpDUpFqJcfn3oVTJmojXsTUfG6oGyPDMPcLDS4sgyWrUUAuSYZ?= =?us-ascii?Q?1htVSmYR6Kw/vxPbbBHiC3uJJLLvvxYdorf+qBEndghUkm2RY9OdxGKdVws0?= =?us-ascii?Q?Rss24h7cUSddFPk/P0p0xKdaLv5P/VNKZuBilWziHHtORDvHAJrSuuANeitH?= =?us-ascii?Q?gV5vZC7xMA9CQv3IZZv1qQuhCHBw7CHSfvHQgCwQQAdYpD4lpu0P8JhYs7fZ?= =?us-ascii?Q?zBPOQsxjsTVvXxvVXw7INXHpjdzALfijJt1cUR+4LKsitLS3KAM2Fd9QlfXD?= =?us-ascii?Q?dLxYoqs20My4vpVP6miGNMBPgGLcO7Fu6M6f8GRhimbCDlT4piqwfR619Wpv?= =?us-ascii?Q?WmxOURF5uaLk/SmHKK9abi5tPjtFtNKgF4dfn0JkNmiY+FbG2g0vQ6cEYlQf?= =?us-ascii?Q?5q073v1hV4dCddx0Tm0YlFJmcdIBMFxPVkflFdIX5Taw1rCUROz8A0cjdFAG?= =?us-ascii?Q?WjdIaXk5Uq9epJHLQKCWq9/3R0nGsCBRrWsaMlnLieqmFz53fV7Hl7DdGdS2?= =?us-ascii?Q?TaXpVwe7HoTKPqt6/UF4hdyBX9mmLYQsI5S9P5MuFEJHRNknVNRK3RY4MdMM?= =?us-ascii?Q?HPtUj1JrNnZ3YvetE7kZidmK1EsndaBtd8S2VDJFITdsNKRGcapQFO4gRCmN?= =?us-ascii?Q?gHMJPlVMGWQdlBhogFervoj91zPqtdA76QPTM4tw6RnJWWUG8ZLpgnKpg76P?= =?us-ascii?Q?kdxq1LeblhsulE8u8yQM2NNSB1RPxPN90bDoCYqbH2A=3D?=
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_0528_01D6DEB9.45813520"
MIME-Version: 1.0
X-OriginatorOrg: digicert.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR14MB3167.namprd14.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 93fa990b-9d5f-4c31-2d4c-08d8acfa5194
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Dec 2020 19:37:18.2902 (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: 4BNylNkfZLdU5FG+qovlAPTwbC31rwAGIUG23cBLeBKE6wRaq0yyhDWYuIc0nu0DLQe/3GPVwNvCaSj3Va84l44+ZI66Z0F0HbBz6hP8hsA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB2528
Archived-At: 
Subject: [lamps] WG Last Call for draft-ietf-lamps-crmf-update-algs
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Dec 2020 19:37:26 -0000

------=_NextPart_000_0528_01D6DEB9.45813520
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0529_01D6DEB9.45813520"


------=_NextPart_001_0529_01D6DEB9.45813520
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Ok, with that last fix, I am not aware of any outstanding issues with the
current document.  Russ thinks it is ready to proceed to WG Last Call.

 

Therefore, this is the LAMPS WG Last Call for "Algorithm Requirements Update
to the Internet X.509 Public Key Infrastructure Certificate Request Message
Format (CRMF)" < draft-ietf-lamps-crmf-update-algs-02>.  Please review the
document and send your comments to the list by 18 January 2020.

 

The datatracker page for the document is
https://datatracker.ietf.org/doc/draft-ietf-lamps-crmf-update-algs/

 

-Tim

 


------=_NextPart_001_0529_01D6DEB9.45813520
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Ok, with that last fix, I am =
not aware of any outstanding issues with the current document.  =
Russ thinks it is ready to proceed to WG Last Call.
 
Therefore, =
this is the LAMPS WG Last Call for "Algorithm Requirements Update =
to the Internet X.509 Public Key Infrastructure Certificate Request =
Message Format (CRMF)” < =
draft-ietf-lamps-crmf-update-algs-02>.  Please review the =
document and send your comments to the list by 18 January =
2020.
 
The datatracker page for the document is https://datatracker.ietf.org/doc/draft-ietf-lamps-crmf-update-algs/
 
-Tim
 

------=_NextPart_001_0529_01D6DEB9.45813520--

------=_NextPart_000_0528_01D6DEB9.45813520
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
CQUxDxcNMjAxMjMwMTkzNzE3WjAvBgkqhkiG9w0BCQQxIgQgTJK/aAHLsQ2yC/QQhCWRxI7uc30Q
Tq+G3fOgiIe6IxYwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp
Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw
ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth
tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq
hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG
SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA
BIIBABdwK/Q+QcImBwafMCPg+IbuxzjeQ6B0XJsgk7nh4cQNEQpzCwInNbGTkzfKFZoNc+rxOvE2
IijjA2MiirE7O+CbHLxXhmZ/OleNsJIokcPjeSTEbSIJy4lI9CIm/2QOlHfgTcOzJGqRNuFpGeNV
eaumYfXkKE6/HsQPhYR/qfnD6Ougg7uKseQ6v7WJIoEq1el0c3KE8FSirhsKhRkoa7kx8b/1nJ+P
Ov/rim44RBLBv4IrpY0vG33ycewc0V54en07olTP/5tEXpiwDH1FBQ3BkxUgpjvIYQwcVxIWqbNd
uB+o8hK1BuSR1Vz4dz8fC4OozSg8xjB1Vl7zAm2YPWsAAAAAAAA=

------=_NextPart_000_0528_01D6DEB9.45813520--


From nobody Wed Dec 30 13:19:29 2020
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 CCEF83A033F for ; Wed, 30 Dec 2020 13:19:27 -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_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 tHvSV5ycSaLY for ; Wed, 30 Dec 2020 13:19:25 -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 54B8A3A0140 for ; Wed, 30 Dec 2020 13:19:25 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 823E9F4073F; Wed, 30 Dec 2020 13:18:54 -0800 (PST)
To: housley@vigilsec.com, rdd@cert.org, kaduk@mit.edu, housley@vigilsec.com, tim.hollebeek@digicert.com
X-PHP-Originating-Script: 1005:errata_mail_lib.php
From: RFC Errata System 
Cc: amtzandre43@gmail.com, spasm@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20201230211854.823E9F4073F@rfc-editor.org>
Date: Wed, 30 Dec 2020 13:18:54 -0800 (PST)
Archived-At: 
Subject: [lamps] [Technical Errata Reported] RFC8649 (6376)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Dec 2020 21:19:28 -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/eid6376

--------------------------------------
Type: Technical
Reported by: Mahmud andreansyah 

1297992261

Original Text
-------------
Privasi account

Corrected Text
--------------
Privasi account saya

Notes
-----
Privasi account

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 Wed Dec 30 13:25:52 2020
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 DBA023A08AF for ; Wed, 30 Dec 2020 13:25:50 -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, 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 YQn_m35-E6UB for ; Wed, 30 Dec 2020 13:25:49 -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 560C13A086D for ; Wed, 30 Dec 2020 13:25:49 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 98359300BC8 for ; Wed, 30 Dec 2020 16:25: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 GnVEIrPqg9nw for ; Wed, 30 Dec 2020 16:25:43 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 8511E300B0D; Wed, 30 Dec 2020 16:25:43 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Russ Housley 
In-Reply-To: <20201230211854.823E9F4073F@rfc-editor.org>
Date: Wed, 30 Dec 2020 16:25:44 -0500
Cc: "Roman D. Danyliw" , Ben Kaduk , tim.hollebeek@digicert.com, amtzandre43@gmail.com, spasm@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <39AD1828-8C2E-482A-A3AA-5B0A080F1F30@vigilsec.com>
References: <20201230211854.823E9F4073F@rfc-editor.org>
To: RFC Editor 
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: 
Subject: Re: [lamps] [Technical Errata Reported] RFC8649 (6376)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Dec 2020 21:25:51 -0000

This looks like noise. Please delete it.

Russ


> On Dec 30, 2020, at 4:18 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/eid6376
>=20
> --------------------------------------
> Type: Technical
> Reported by: Mahmud andreansyah 
>=20
> 1297992261
>=20
> Original Text
> -------------
> Privasi account
>=20
> Corrected Text
> --------------
> Privasi account saya
>=20
> Notes
> -----
> Privasi account
>=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