From nobody Mon Jun 1 10:36: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 B70123A134B for ; Mon, 1 Jun 2020 10:36:09 -0700 (PDT) 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_H3=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=MaGKkWbg; dkim=pass (1024-bit key) header.d=digicert.com header.b=fesmnb3I 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 8H_ErrtoYceZ for ; Mon, 1 Jun 2020 10:36:08 -0700 (PDT) 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 D8F383A1356 for ; Mon, 1 Jun 2020 10:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1591032966; 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=qMrjz2P8UrLdsUklx4VDqNOZNKFbYB/azfZbMbDK1sU=; b=MaGKkWbgRbQkJG+QOIWs0/JIT5NPOZ7UwX+M+fl2KiKbzFbLqJGwGEiHdqi1YLq3Vg5CiY 2pS3FGpEfLjzH7P9CIWnaXHsxOktxJBwHUcvO3WD+wyfwTYLnJyDbPK2ZQOiCkIVlY9Btr 6O+y/Ix/MfEZ7X07sbk7GPBjo/Jy6Ac= Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-co1nam04lp2052.outbound.protection.outlook.com [104.47.45.52]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-357-Egi5nGfFMpOVoLS2sCoQUQ-1; Mon, 01 Jun 2020 13:36:04 -0400 X-MC-Unique: Egi5nGfFMpOVoLS2sCoQUQ-1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QYLImgqWvTp27uq1IThN3HkxxvWYKzrkN7agldOjXJ62HhN+kXFk3DoV/H2mQthJ0gWWdvhEQ99LV4VeTkcjdJ9GX66crGSexRSTxqeRFsSTXo3tZXCdMooljQoYjNAXDV09HiiSJ5jrOd6gXw/pm4HCWoun0J7uBBesmivaqFDjpHSxEfjvEOYOgU2euDl4mpwYwyg+4zJtlHNutIH0J5iun3NI/yEW+Ik93IWLdsM57lPRLWplQaIKxztLZN2bUz87+iphshkA3jq3QOn1mXNpUQQjoBBH30JU4R5S1qNgQYZ4Kfz86J0vTsNIVwVwziNc7PsN7iFY6AlqRd0fVw== 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=qMrjz2P8UrLdsUklx4VDqNOZNKFbYB/azfZbMbDK1sU=; b=jT3A+Mpiabo2AMbqsVpXUxUR9FxD90BEWrGG4rYwv/EugU4UPy/MpabRKD1foNf64e6N3JuirVTpYb28M/1CTj7mj/nX0AarXwRS99VD49hpZGGa1DJ54MytSU35kXvq/W/um3rD4iEJdvv6Kz2M3cYeUm/KgeZf1I3zcw6hgmndi9KG59wEr9P8YIKI2ullXGVJwa808n4/T5ZFczZ+VhcB0nR4pDcXm1zJ9F+7wHXVrvg1v0UIEDXopoja5Ws5TRM7WDrYEvOfsDo6Ri3JQiXeHbbFGzLvJXD9QPhBLPEOCqGT31KTpYJHIWlKWQcCkzNtXNbRVRhGYPX2o+IHFA== 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=qMrjz2P8UrLdsUklx4VDqNOZNKFbYB/azfZbMbDK1sU=; b=fesmnb3IZYjZm2yvGiUo/j2P72h0ZSgtKHZ2XDYzxzvGc8QePTTXdH4vYshcMWMx09pBgLuvH9ICs0x3+/CYKzYf2n1PHqI2mvx/BENaA4Kzen+K9mjjKEtELXiuH6eVJuQTvG6wfXVM+EjkgCN1zPUl+oCgF0ibikqKHv9fIi4= Received: from BY5PR14MB3270.namprd14.prod.outlook.com (2603:10b6:a03:1e4::24) by BY5PR14MB3414.namprd14.prod.outlook.com (2603:10b6:a03:1e1::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.19; Mon, 1 Jun 2020 17:36:02 +0000 Received: from BY5PR14MB3270.namprd14.prod.outlook.com ([fe80::5d9a:c434:cd5b:8f44]) by BY5PR14MB3270.namprd14.prod.outlook.com ([fe80::5d9a:c434:cd5b:8f44%9]) with mapi id 15.20.3045.022; Mon, 1 Jun 2020 17:36:02 +0000 From: Tim Hollebeek To: Tim Hollebeek , SPASM Thread-Topic: WG Last Call for draft-ietf-lamps-cms-update-alg-id-protect Thread-Index: AdYf8KSSykcnQsXFRZy6I1/5Rblf8gYSivDg Date: Mon, 1 Jun 2020 17:36:02 +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: digicert.com; dkim=none (message not signed) header.d=none;digicert.com; dmarc=none action=none header.from=digicert.com; x-originating-ip: [74.98.249.186] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a351f7bd-b50a-4503-bbc3-08d806524133 x-ms-traffictypediagnostic: BY5PR14MB3414: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 0421BF7135 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1t051NFn6mLcEbz6HQikVX/3j0yWhVPfAOp9kGeMqDzElYTWvLnDix+cGAWcG6lL25E+BKw2XtmIIWrrYqzHqAgf7rSCQuuL28vXUWfQKUa8FsO8xIXCJKQLoboIrnKxBJpijJunhdkDCTw4mO6rsBKPFmuGsxNpEErdLhf/M7AHtW8vfPEVafuw5sHjecgK/Z7IOJSPpo54hgpFjwRxCT/Xks5sU91anHM0IaONWFqtQHbEkFs3SOTztp1wdxDdvmLic1vMGeMqm4Sx96xRnJ4XoGYHgWEyK7879xJiiGjnN29OgNRXN5L2GC8zCBwpnrCPpoklpQgbR0GSNYMwnlGTTTJucQEjGJOUpJu1gYdH1RNZlJwdnxjcZ3rsygYrKayWKYdnx2bwGZ+j3I6gqw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR14MB3270.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(376002)(396003)(346002)(366004)(136003)(39850400004)(86362001)(2906002)(44832011)(99936003)(15650500001)(83380400001)(5660300002)(9686003)(33656002)(71200400001)(166002)(66946007)(52536014)(76116006)(66446008)(66556008)(66616009)(6506007)(53546011)(8676002)(316002)(110136005)(7696005)(55016002)(8936002)(4744005)(478600001)(186003)(64756008)(66476007)(966005)(26005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 8YH/mPLPcWHLquoIi/ZJu9riVp5BfLH+yb5RU52zdPs2D/FSL5dOW+2V3obNh7aUrFbuyctk28VpYCUNSybG4W9Y7bOQoNFFLZVF6o31kOXInYRI+EufRfbSUqwGKzNI1bidBH1v2uKnWn5ICOG7YNy07DT0lcfbZ5Zy0dGgBpX8YHCVBQkZzQoxDscQvfo3LWGzOak3DqLNgFmv0Uf1UdHaQEeKDJhdmP1HvmiOcM8o/9c3lwHxhh+dRBiB0EXU4br26Rl3HHM1vKaVry3iPCu6jX7syy/PkbJ4EP1ynOymW2GqpbgvfiJDVEiRk8zpSXwvyloixNrpCWsIgm+FZUGmEyDmviUOzhKnRejFAD47n6lONE09sqm+AvPQG5sQ9gue0FKxf2hjkCXLzlkjZwLzWgd3b0gKOaoUUDfZSxtre17fZ0wt81t30TRouNieLEuKHqm6iN92hm+Iw17UR24RRcVyfixVfOdneqlxRSE= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0803_01D63819.6C00D4E0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: a351f7bd-b50a-4503-bbc3-08d806524133 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2020 17:36:02.1978 (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: YjBX9EKjGMYn1B8EEy9iCzxUQSfeK8enFSHld+m2DTM3xnEq/tQlaSe6n+Jnu5k/A6NcmVvWuvkXG0P8c8nyr5i8hAys0lhH4NniSlFx/R0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR14MB3414 Archived-At: Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-update-alg-id-protect X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 17:36:10 -0000 ------=_NextPart_000_0803_01D63819.6C00D4E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0804_01D63819.6C00D4E0" ------=_NextPart_001_0804_01D63819.6C00D4E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It looks like Russ has already addressed the one minor concern that was noted during the WG Last Call. Seeing no other concerns, I'll start the shepherd write-up. -Tim From: Spasm On Behalf Of Tim Hollebeek Sent: Friday, May 1, 2020 3:45 PM To: SPASM Subject: [lamps] WG Last Call for draft-ietf-lamps-cms-update-alg-id-protect This is the LAMPS WG Last Call for "Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection" . Please review the document and send your comments to the list by 22 May 2020. The datatracker page for the document is https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protect/ -Tim ------=_NextPart_001_0804_01D63819.6C00D4E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It looks like Russ has already addressed the one minor = concern that was noted during the WG Last Call.  Seeing no other = concerns, I’ll start the shepherd write-up.

 

-Tim

 

From: Spasm = <spasm-bounces@ietf.org> On Behalf Of Tim = Hollebeek
Sent: Friday, May 1, 2020 3:45 PM
To: = SPASM <spasm@ietf.org>
Subject: [lamps] WG Last Call for = draft-ietf-lamps-cms-update-alg-id-protect

 

This is = the LAMPS WG Last Call for "Update to the Cryptographic Message = Syntax (CMS) for Algorithm Identifier Protection” = <draft-ietf-lamps-cms-update-alg-id-protect-01>.  Please = review the document and send your comments to the list by 22 May = 2020.

 

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

 

-Tim

 

 

 

------=_NextPart_001_0804_01D63819.6C00D4E0-- ------=_NextPart_000_0803_01D63819.6C00D4E0 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 CQUxDxcNMjAwNjAxMTczNDQ5WjAvBgkqhkiG9w0BCQQxIgQgfstDbYQh9GrNJ3rKzWhwrAPKPe1g gWe8QmVUgrVjS3QwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAE0Qpoakq7++jK2L4xI42qp75zJ+aXyrKC4kZby1Jba2WJnKvUAzAL5DmuFmiColxkN8eKKj Vf1VkwYuiBa9KUCkxmjqptcaHGULMzaSoYlszoS9sc1MiXrWVOD1jbhtlqIyOgwqrd0BetjghDM/ wrW2lygQJ7bWHAZzMKXmyun5GMi4PqSNhvrbLvF/CG8VKe059EeTg0ZeLQn/2dHkQtq7mZbUS1ep ythE3DwSX9RqBvf53QOswaEve0p/2dO+tRk8HgQYcRVV2p3XjyB/Hh/5Fbb8zDg1i0iKMn8716EJ i1BcNJK7+h16XzBaHx+4AhKdzS6kJhf/DtYjftq8kNQAAAAAAAA= ------=_NextPart_000_0803_01D63819.6C00D4E0-- From nobody Tue Jun 2 19:09: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 698C83A11DF for ; Tue, 2 Jun 2020 19:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, 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 xFY1IYKVIffJ for ; Tue, 2 Jun 2020 19:09:38 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F863A11DE for ; Tue, 2 Jun 2020 19:09:38 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id t8so906357ilm.7 for ; Tue, 02 Jun 2020 19:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FKs5jxUfuUlJi+fw1PzfrM594j4QdAhX/D7WZBeDDhI=; b=JzUPHmxlg8Wp+pQ7dgDvzLOiuTtTRiL9hsSMAlweeVCQjQ+CqP2M12Gikq1gfOpSnJ Lqq/k1xArg8RzwaWtFHydoE/RFVKS9LPeQkacPAvCYKHYkps6MHVz7sKkVJbUFL++1sG 4V3bfAtDXwHz+3lxTpwEUpKS0OqlkYKTPUN0G1PauS7szlf9xR02MlKfT91cRp+sJ0H/ wc9wSBpNNRu3l5/qsX433HlRXrVDCQ1bKbpylddJaIns04PD7FHWvbXKWM872Z4Il4AJ PYspOl7mhRRDUdYVQ9XNa/AutnVnJf69urhbi1Pm/iHuSqAEqT8yTzs4L4jsWNkxkKIJ 0rJg== 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=FKs5jxUfuUlJi+fw1PzfrM594j4QdAhX/D7WZBeDDhI=; b=WmVmkYM2TiUel47zwIfRtVmmzRLiDNAjmC+dD5LWYvgzgUiMFeNq9wm24TcuPwi8tt wK1jRRQYsosyENy0XdXIGtHEznOysMOigTMm/bBmItmHPHySIUVYnrYPBn+dGRJo/mL/ uZJAh+0aUslbSCIvFHUK+U/i27Z2F6ZGLLT910L5E8ajlYCPe58rG+RLPV9Wv4CdFfdN EJ2FZi3NL99yjTPTjcJgL1teiQZO9FzYpUr8neNZcximU1emVzbvx6zoGoh0DMZrj0hw Lo7LWDUjl3Vgt829l5/U97sAKLs34CX9hFxc6U1uwtTUeqSdj5VdI74c/+USUx8Ag9S/ bybQ== X-Gm-Message-State: AOAM5323RCJB38Q1JwmKJHgiWHTRWqSveXxv9Y226BKQgbkwO/ScFknz R3k+wAaUwWL3XvxKWiEQU2Wxix3LCaVksCU8ZQA= X-Google-Smtp-Source: ABdhPJzk1gQDsTghkSl2PQCJ9KBso+XDRFVP8AuPfRxFakxtg+s99b+W9gJf9C3rHY8EWAUEkCHOjB/XFMGCWe+49CM= X-Received: by 2002:a92:7787:: with SMTP id s129mr1882348ilc.297.1591150178113; Tue, 02 Jun 2020 19:09:38 -0700 (PDT) MIME-Version: 1.0 References: <79037008-09ED-4E31-BA8C-1DC4F24E1687@vigilsec.com> <16418846-B43A-45E5-BB28-B89169AE6523@akamai.com> In-Reply-To: From: Mohit Sahni Date: Tue, 2 Jun 2020 19:09:27 -0700 Message-ID: To: Russ Housley Cc: Rich Salz , LAMPS Content-Type: multipart/alternative; boundary="000000000000269e8805a7248505" Archived-At: Subject: Re: [lamps] shepherd writeup: draft-ietf-lamps-ocsp-nonce/ 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, 03 Jun 2020 02:09:40 -0000 --000000000000269e8805a7248505 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable {OFF LIST} Hi Russ, I am sorry I am not aware of the whole process, just wanted to check what are the next steps now? Is there anything pending on my end? Thanks Mohit On Mon, May 18, 2020 at 10:02 AM Russ Housley wrote: > Thanks for catching my failure to answer the proper question. Now fixed: > > (11) Identify any ID nits the Document Shepherd has found in this > document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts > Checklist). Boilerplate checks are not enough; this check needs to be > thorough. > > IDnits reports: > -- The draft header indicates that this document updates RFC6960, but t= he > abstract doesn't seem to directly say this. It does mention RFC6960 > though, so this could be OK. > The Abstract includes "This document updates the RFC 6960". > This warning seems to be the result of "the" or a missing period. > > Russ > > > On May 18, 2020, at 10:56 AM, Salz, Rich 40akamai.com@dmarc.ietf.org> wrote: > > > > Is the answer to #11 a non-sequiture? (However you spell it.) > > > > It also specifies a recommendation for minimum, is that worth mentionin= g? > > > > > > =EF=BB=BFOn 5/16/20, 2:21 PM, "Russ Housley" wro= te: > > > > > https://datatracker.ietf.org/doc/draft-ietf-lamps-ocsp-nonce/shepherdwrit= eup/ > > > > Please review and comment. > > > > Russ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --000000000000269e8805a7248505 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
{OFF LIST}

Hi=C2=A0Russ,
= I am sorry I am not aware of the whole process, just wanted to check what a= re the next=C2=A0steps now? Is there anything pending on my=C2=A0end?
=

Thanks
Mohit

On Mon, May 18, 2020 at 10:= 02 AM Russ Housley <housley@vigi= lsec.com> wrote:
Thanks for catching my failure to answer the proper question.=C2=A0= Now fixed:

(11) Identify any ID nits the Document Shepherd has found in this
document.=C2=A0 (See http://www.ietf.org/tools/idnits/ and the = Internet-Drafts
Checklist).=C2=A0 Boilerplate checks are not enough; this check needs to be=
thorough.

=C2=A0 IDnits reports:
=C2=A0 -- The draft header indicates that this document updates RFC6960, bu= t the
=C2=A0 =C2=A0 =C2=A0abstract doesn't seem to directly say this.=C2=A0 I= t does mention RFC6960
=C2=A0 =C2=A0 =C2=A0though, so this could be OK.
=C2=A0 The Abstract includes "This document updates the RFC 6960"= .
=C2=A0 This warning seems to be the result of "the" or a missing = period.

Russ

> On May 18, 2020, at 10:56 AM, Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org= > wrote:
>
> Is the answer to #11 a non-sequiture?=C2=A0 (However you spell it.) >
> It also specifies a recommendation for minimum, is that worth mentioni= ng?
>
>
> =EF=BB=BFOn 5/16/20, 2:21 PM, "Russ Housley" <housley@vigilsec.com>= wrote:
>
>=C2=A0 =C2=A0 https= ://datatracker.ietf.org/doc/draft-ietf-lamps-ocsp-nonce/shepherdwriteup/
>
>=C2=A0 =C2=A0 Please review and comment.
>
>=C2=A0 =C2=A0 Russ

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--000000000000269e8805a7248505-- From nobody Wed Jun 3 09:13:28 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 A04683A07FB; Wed, 3 Jun 2020 09:13:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Cc: spasm@ietf.org, housley@vigilsec.com, Russ Housley , lamps-chairs@ietf.org, iesg-secretary@ietf.org Message-ID: <159120079962.24141.15959820770743462038@ietfa.amsl.com> Date: Wed, 03 Jun 2020 09:13:19 -0700 Archived-At: Subject: [lamps] Publication has been requested for draft-ietf-lamps-ocsp-nonce-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, 03 Jun 2020 16:13:26 -0000 Russ Housley has requested publication of draft-ietf-lamps-ocsp-nonce-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-ocsp-nonce/ From nobody Wed Jun 3 09:15: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 2FEE83A07FC for ; Wed, 3 Jun 2020 09:15:52 -0700 (PDT) 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 SJaY1mn4owVi for ; Wed, 3 Jun 2020 09:15:50 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA323A0E22 for ; Wed, 3 Jun 2020 09:15:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BF51F300AEF for ; Wed, 3 Jun 2020 12:15:01 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gYWT9QGn2tMz for ; Wed, 3 Jun 2020 12:14:59 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id AC73B300A93; Wed, 3 Jun 2020 12:14:59 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2175CAE6-F5DE-4BBA-9B2E-54A703D28A25" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Wed, 3 Jun 2020 12:15:00 -0400 In-Reply-To: Cc: LAMPS To: Mohit Sahni References: <79037008-09ED-4E31-BA8C-1DC4F24E1687@vigilsec.com> <16418846-B43A-45E5-BB28-B89169AE6523@akamai.com> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [lamps] shepherd writeup: draft-ietf-lamps-ocsp-nonce/ 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, 03 Jun 2020 16:15:52 -0000 --Apple-Mail=_2175CAE6-F5DE-4BBA-9B2E-54A703D28A25 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I was waiting to see is anyone raised concerns with the write-up. No = one did. The document is now with the IESG. You can see the states in the IESG = process here: https://datatracker.ietf.org/help/state/draft/iesg = Russ > On Jun 2, 2020, at 10:09 PM, Mohit Sahni wrote: >=20 > {OFF LIST} >=20 > Hi Russ, > I am sorry I am not aware of the whole process, just wanted to check = what are the next steps now? Is there anything pending on my end? >=20 > Thanks > Mohit >=20 > On Mon, May 18, 2020 at 10:02 AM Russ Housley > wrote: > Thanks for catching my failure to answer the proper question. Now = fixed: >=20 > (11) Identify any ID nits the Document Shepherd has found in this > document. (See http://www.ietf.org/tools/idnits/ = and the Internet-Drafts > Checklist). Boilerplate checks are not enough; this check needs to be > thorough. >=20 > IDnits reports: > -- The draft header indicates that this document updates RFC6960, = but the > abstract doesn't seem to directly say this. It does mention = RFC6960 > though, so this could be OK. > The Abstract includes "This document updates the RFC 6960".. > This warning seems to be the result of "the" or a missing period. >=20 > Russ >=20 > > On May 18, 2020, at 10:56 AM, Salz, Rich = > wrote: > >=20 > > Is the answer to #11 a non-sequiture? (However you spell it.) > >=20 > > It also specifies a recommendation for minimum, is that worth = mentioning? > >=20 > >=20 > > =EF=BB=BFOn 5/16/20, 2:21 PM, "Russ Housley" > wrote: > >=20 > > = https://datatracker.ietf.org/doc/draft-ietf-lamps-ocsp-nonce/shepherdwrite= up/ = > >=20 > > Please review and comment. > >=20 > > Russ >=20 > _______________________________________________ > 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 --Apple-Mail=_2175CAE6-F5DE-4BBA-9B2E-54A703D28A25 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = was waiting to see is anyone raised concerns with the write-up.  No = one did.

The = document is now with the IESG.  You can see the states in the IESG = process here: https://datatracker.ietf.org/help/state/draft/iesg

Russ


On Jun 2, 2020, at 10:09 PM, Mohit Sahni = <mohit06jan@gmail.com> wrote:

{OFF LIST}

Hi Russ,
I am sorry = I am not aware of the whole process, just wanted to check what are the = next steps now? Is there anything pending on my end?

Thanks
Mohit

On Mon, May 18, 2020 at 10:02 AM Russ = Housley <housley@vigilsec.com> wrote:
Thanks for catching my failure to = answer the proper question.  Now fixed:

(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the = Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to = be
thorough.

  IDnits reports:
  -- The draft header indicates that this document updates RFC6960, = but the
     abstract doesn't seem to directly say this.  It = does mention RFC6960
     though, so this could be OK.
  The Abstract includes "This document updates the RFC 6960"..
  This warning seems to be the result of "the" or a missing = period.

Russ

> On May 18, 2020, at 10:56 AM, Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org> wrote:
>
> Is the answer to #11 a non-sequiture?  (However you spell = it.)
>
> It also specifies a recommendation for minimum, is that worth = mentioning?
>
>
> =EF=BB=BFOn 5/16/20, 2:21 PM, "Russ Housley" <housley@vigilsec.com> wrote:
>
>    https://datatracker.ietf.org/doc/draft-ietf-lamps-ocsp-nonce/sh= epherdwriteup/
>
>    Please review and comment.
>
>    Russ

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

= --Apple-Mail=_2175CAE6-F5DE-4BBA-9B2E-54A703D28A25-- From nobody Thu Jun 4 11:04: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 8AC203A0A69 for ; Thu, 4 Jun 2020 11:04:10 -0700 (PDT) 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 DwDcfuP_k9VV for ; Thu, 4 Jun 2020 11:04:09 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 3D0A73A0A68 for ; Thu, 4 Jun 2020 11:04:09 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id y5so7335057iob.12 for ; Thu, 04 Jun 2020 11:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=U+lf9KKRlNxd8uRHzCoON4kfYkFl1tO4NeOl6p2uCO8=; b=uaHloswJt80psL6Kh1w5WqI5JgCVsJAgl0lkOMvqGgivADbVy+mL8Y+P2AeFqbdlcp DhSTwwBV7a4qzb9FyqXAKx/7FQpoLi8aYAxysg69cYyGXy45OK82Mgq0zMg0Gni8pxrK Y/PL6e4PKGZfZ0IDgdGFCz1UJWN8LiEsztHboPu4xKqwiQXxfz+frz2IP/h9Yb7gy7+q 0vIeoORUkcIl2NYzNjZ8cHwpv34EOZoOHPDMfynt+P69rR3sq0RBmiBoHISxA7sKzE+Z GXn37qV2Wur2+03QEAY9nKmes6KMTLh1/bE0q51HcYxvZF62rrGoFmdGwnUm2mYDWZUT GNSw== 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=U+lf9KKRlNxd8uRHzCoON4kfYkFl1tO4NeOl6p2uCO8=; b=lnUj41WX+LBLYvUPxCogyNTxvMTrdh9mPnjT82QjK2joylCJnSoFszx6mVcMnjuslG 44mqUi3vkIavYR/GUDHYueIU48HcZiHH1Ab3kq4iHQ2CfkDzhaN+NQEy4J/IR30KyUA4 YhZCt497d3stCZ2slyzNDfEHpbaGWiQXRXJna3zJJoXhAVBUMo7Xs/qIzzsmtOxIT4rZ OvsZ03Touz2eVv7AUxOAhVC+hyg5y4Hea8eNoSO2+gBdvKGZKI0CsPgIui64RlRW+Ihv 4FLudAKTmeo1JUl0zmkC06c/druDFzerystLiaWGATO6Rdf4Dts2Tc6kGSiqrdk+o2dK msLg== X-Gm-Message-State: AOAM533qOxbM61vddf7tVVGjF6GJ0yyf48QLMeRimsya1lCJmizNAeYT NspqUBKp0Zl5EJoc6sxN5AUjvLB9DgwGLbplg8A= X-Google-Smtp-Source: ABdhPJzP+klB1jLlm6T67qRlsmy3e+Kax7VY0qI7h12kVYMIqKOKZetqqTyxy+mGkZwSY91t5BPFjySwSPsB0fcSJ4w= X-Received: by 2002:a05:6602:2ac9:: with SMTP id m9mr5177945iov.68.1591293847122; Thu, 04 Jun 2020 11:04:07 -0700 (PDT) MIME-Version: 1.0 From: Mohit Sahni Date: Thu, 4 Jun 2020 11:03:56 -0700 Message-ID: To: Jim Schaad , "Brockhaus, Hendrik" , LAMPS WG Content-Type: multipart/alternative; boundary="0000000000007dbb7805a745f891" Archived-At: Subject: [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport 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, 04 Jun 2020 18:04:11 -0000 --0000000000007dbb7805a745f891 Content-Type: text/plain; charset="UTF-8" Hi Jim, There were some discussions about using CoAP as transport for the Lightweight CMP profile in the last LAMPS WG meeting. After having some discussions with Hendrik, David, and Andreas I have written an internet-draft for using CoAP as transport for CMPv2 / Light Weight CMP Profile. If I am not mistaken, the recommendation was to present this draft to ACE WG for the review instead of Lamps group, can you please advice on that? Here is the link to the internet-draft that I wrote https://www.ietf.org/id/draft-msahni-tbd-cmpv2-coap-transport-00.txt Thanks Mohit --0000000000007dbb7805a745f891 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jim,
There were some discussions ab= out using CoAP as transport for the Lightweight CMP profile in the last LAM= PS WG meeting. After having some discussions with Hendrik, David, and=C2=A0= Andreas I have written an internet-draft for using CoAP as transport for CM= Pv2 / Light Weight CMP Profile. If I am not=C2=A0mistaken, the=C2=A0recomme= ndation was to present this draft to ACE WG for the review instead of Lamps= group, can you please advice on that?

Here is the= link to the internet-draft that I wrote https://www.ietf.org/id/draf= t-msahni-tbd-cmpv2-coap-transport-00.txt=C2=A0

Thanks=
Mohit=C2=A0=C2=A0
--0000000000007dbb7805a745f891-- From nobody Thu Jun 4 12:32: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 A03003A0ED7 for ; Thu, 4 Jun 2020 12:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=fSmH0TSD; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=r3/miCFR 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 2UNdEyj3TUKF for ; Thu, 4 Jun 2020 12:32:31 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041FB3A0E86 for ; Thu, 4 Jun 2020 12:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11598; q=dns/txt; s=iport; t=1591299151; x=1592508751; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=rfYA0VzO2P4dAIU7vJY6wEAHarjGXLK3YQslqr8oxcE=; b=fSmH0TSDgVw+HnskG5rP4i9qsHG7OXWOIUnIDgM1ZanZxO31Y9O/w7Sm ZDpS3hNc51EYw0OKE0sDx8X7GbquRe11JycLROlRZK+8aFlSv5MIc8wPW I/Quc5j2J4Xu5uK7boWEeg8UVczyGwhRxvY7ykyAwpUVVwO5uOpxTeFk+ Q=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3A3iC3ARTEpgF5PLtoCKrbZOvSIdpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBNmJ5PdNiu6QuKflCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFLXq3y2qzUVH0?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcCAA0S9le/4ENJK1mHQEBAQEJARI?= =?us-ascii?q?BBQUBggqBIy9SB28rLS8sCoQbg0YDjT6HVIwUhGiCUgNVBAcBAQEJAwEBIwo?= =?us-ascii?q?CBAEBhEQCgisCJDgTAgMBAQsBAQUBAQECAQYEbYVbDIVyAQEBAQMSEQoTAQE?= =?us-ascii?q?4DwIBCBEEAQErAgICMB0IAgQBEggGFIMFgX5NAx8PAQ6nFAKBOYhhdoEygwE?= =?us-ascii?q?BAQWFSxiCBwcDBoE4gRJBgRGJaBqBQT+BVIJNPoJnAoFnK4JnM4ILIpICh1+?= =?us-ascii?q?aEwqCWYQiglOSJYJniQySR4xVhB+eCAIEAgQFAg4BAQWBaiKBVnAVgyRQFwI?= =?us-ascii?q?NkECDcoUUhUJ0AjUCBggBAQMJfI17AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.73,472,1583193600"; d="p7s'?scan'208,217";a="777347345" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Jun 2020 19:32:29 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 054JWTSQ028113 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Jun 2020 19:32:29 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 4 Jun 2020 14:32:29 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 4 Jun 2020 15:32:28 -0400 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 4 Jun 2020 14:32:28 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HwJpsJ7vPM0YFZoKdbiUjmQPvRYmwA+kvzM4JToRvF5CZ+Rqynd4RXLXv8h5a84fHWBVsD1Mzp66h0pbiuRhaju7z/FMxNOoFySMK8LYEi+fP9LZoukVVBQF5yKsA3q9EcKwJ2Xm3YWaWoyFZn6+uuO8c+t5vL2JGHLKBC8Z0Xe71BqlESMn+lEz/F2YQjY6PQktAIuJBWC14SKUv04IXseqqIhtWeHbCuzJq7/oKwrsLnAQ1uSQ4ZBlx9eZBBDv5nlXoZ07MDX6pRdzOP/06wsV4w99mkmffM1R9jxi6kTj1QLJPz5x3Wxkj0KJqNmtyh0dd9KIQFYNoYlYTaUBXQ== 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=oM+3ZUGxPRnms0qJ2NeqsBKjVqOSU4954/r+qp2D1cI=; b=Mmb3xA98IywkDu6G7GRTnlKYAg0LDgex3UkF8uROQl+s1mrY/5pVFH9i8VKBYXXL3twhUN4JnUPnQyUN85ZNSco5iaO4r/IWYFa/f20NxyQxD/fO/CdbWmxW5Bi8XgtZ/Uz3vSR38LettM/v+nYQ7Q9qErEr8QHvouwr67+QcJtEzyiAMryHYw3MCG6yV8LxNVQAOzmwkNm+K8gRxt5O8NlwGLjGwYNsGBpq/cGZK6VwQ/BbBiUGG+i+0Z65BSb3cJsYB7Pi3qyRFtAjGT3U+ASJEFeunqJVrQ5OXKFlAOxnJlp2w38Lq8Bgq4A5cuuk3OHdcfQimYaQn+IXlAT5gQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oM+3ZUGxPRnms0qJ2NeqsBKjVqOSU4954/r+qp2D1cI=; b=r3/miCFRdUUORcQPBTzyFTbNAT3EFKgyKsrZA55FxSIx/trFy66A6rMJc2JGzSElphGtwpMTPh4PJDD1kUdDyntFu3STfOYKGUcID612vNkNfnIEhrbIo4yO3Xi53TqsG0PNBoFGwvH9xZPV3OxNjMev1wdtASKdZhhfQLt6Xi0= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2546.namprd11.prod.outlook.com (2603:10b6:406:ad::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Thu, 4 Jun 2020 19:32:27 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::7d1c:98b:2131:d35]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::7d1c:98b:2131:d35%3]) with mapi id 15.20.3066.018; Thu, 4 Jun 2020 19:32:27 +0000 From: "Panos Kampanakis (pkampana)" To: Mohit Sahni , Jim Schaad , "Brockhaus, Hendrik" , LAMPS WG Thread-Topic: [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport Thread-Index: AQHWOpqUcx8a4JCXDUyrICt9M8FufajI1gcA Date: Thu, 4 Jun 2020 19:32: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: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [68.93.142.48] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e00de2f4-fd90-4d7a-f7fb-08d808be03d7 x-ms-traffictypediagnostic: BN7PR11MB2546: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04244E0DC5 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cUgltMIGbQYL5mpXNrEs+AYYN/ZlynMxW7ATT+swrzA/Gk/JkA87aQUVEl0GstOgxKuas9Tszsev/cXs5n/7qSMjFeqwznje42A03JvKrj+gWnNtedaqdeJ7hqOvR/w4eQqugeYtrm7U2zb53sHpgwZdrk7jPdJnn31vzNzFMDXqMY/oFtl9Ex1VTuqKoz/emD21XJYrKZSOfMHZv6Wf5pEM8gaAWeijLNxex0A5hdbMdGhzqF4g9Rg8+PKt1VFKPMdHGXXmuB8Nq6KfEnBDpd6LVYxoE1sTcg7wAQNYGZDSpojlGqfY1As5uWiJldmv3iouo/j2V5lM8waiJlJoaSw0L4yPNz1Ei58S/erqA4sFxoyXhWFBO9w05N37S1dcWKqulCQbQGA4mb1MaQT5Iw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(376002)(366004)(346002)(396003)(7696005)(478600001)(316002)(966005)(26005)(33656002)(66556008)(5660300002)(2906002)(52536014)(86362001)(71200400001)(66946007)(19627235002)(66616009)(64756008)(66446008)(66476007)(110136005)(6506007)(8936002)(55016002)(186003)(8676002)(99936003)(76116006)(53546011)(166002)(9686003)(66574014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: HqC4dGq8It/df4BTX9t2tSbFLDJBCxNIGSPgbixZLNyoWNm0BKrb6GYDgHAD5F1Mhwj1yTHVp9Htn2gb+nKPXlI52LoPZmauP/UqFyNe+ht4vyga84ej45Y7NHSSS6t58sB063WMbZkfi1ZHDZ8JaB4ln3ZM5N8ybJ7z7Ph+ghPjX/22rjqRfQ0wCGWX84pXbL9tJezqgBqHX/fJ2UPjNE88PAw0xge2hgPKDHR7SCn94AvjASWCJ2r5Dn8o8HlJQFaj24aYY443HDWgQTMpjEh6wY3giQYsGK/z0nDs8BlC/N62u3/vtXB5NwWw2OhjSFXRb0G3ZbUWBUKNiuVVT+ucydkMWczLw6+q24GXSvieNoJ9ur19fhkEY8aBHiUvKIScolNEkHbIfpOnO0rtreAFWDN9U69+ii6LP+FX897iCERrx6v5z1OZu5TmB5Dhh5g0nA6bZK5cowE27t2UtViK97BRfVEG/ugv0W9ANc0= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0007_01D63A85.59815D80" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e00de2f4-fd90-4d7a-f7fb-08d808be03d7 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2020 19:32:27.2879 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: g0M2/wj1PbilSIZ8upG2+o/UYZ8QXuymPQXvjCekNGQv/d8IOXia5urt5y0+NDJ8sq9Y1F9cZdOyfdXL4BokNw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2546 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport 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, 04 Jun 2020 19:32:34 -0000 ------=_NextPart_000_0007_01D63A85.59815D80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01D63A85.59815D80" ------=_NextPart_001_0008_01D63A85.59815D80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Great. We can now once again have more than one protocols that do the same thing over the same transport protocol. This should go in the ACE WG. ACE worked on EST-coaps (draft-ietf-ace-coap-est) as well. Panos From: Spasm On Behalf Of Mohit Sahni Sent: Thursday, June 04, 2020 2:04 PM To: Jim Schaad ; Brockhaus, Hendrik ; LAMPS WG Subject: [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport Hi Jim, There were some discussions about using CoAP as transport for the Lightweight CMP profile in the last LAMPS WG meeting. After having some discussions with Hendrik, David, and Andreas I have written an internet-draft for using CoAP as transport for CMPv2 / Light Weight CMP Profile. If I am not mistaken, the recommendation was to present this draft to ACE WG for the review instead of Lamps group, can you please advice on that? Here is the link to the internet-draft that I wrote https://www.ietf.org/id/draft-msahni-tbd-cmpv2-coap-transport-00.txt Thanks Mohit ------=_NextPart_001_0008_01D63A85.59815D80 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Great. We can now once again have more than one = protocols that do the same thing over the same transport protocol. =

 

This should go in the = ACE WG. ACE worked on EST-coaps (draft-ietf-ace-coap-est) as well. =

 

Panos

 

 

From: Spasm <spasm-bounces@ietf.org> = On Behalf Of Mohit Sahni
Sent: Thursday, June 04, 2020 = 2:04 PM
To: Jim Schaad <ietf@augustcellars.com>; = Brockhaus, Hendrik <hendrik.brockhaus@siemens.com>; LAMPS WG = <spasm@ietf.org>
Subject: [lamps] CMPv2/LightWeiight-CMP = profile over CoAP transport

 

Hi Jim,

There were some discussions about using CoAP as = transport for the Lightweight CMP profile in the last LAMPS WG meeting. = After having some discussions with Hendrik, David, and Andreas I = have written an internet-draft for using CoAP as transport for CMPv2 / = Light Weight CMP Profile. If I am not mistaken, = the recommendation was to present this draft to ACE WG for the = review instead of Lamps group, can you please advice on = that?

 

Here is the link to the internet-draft = that I wrote https://www.ietf.org/id/draft-msahni-tbd-cmpv2-coap-transport-00.txt=  

Thanks

Mohit  

------=_NextPart_001_0008_01D63A85.59815D80-- ------=_NextPart_000_0007_01D63A85.59815D80 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMjAwNjA0MTkzMjI2WjAvBgkqhkiG9w0BCQQxIgQg/jBe3hYNAcinXeCkfQCy0Ksnj/D5sRIh qB7or7mO4CIwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA HAq8TTxNUhBcSPg4zXDM+ZI7Sb1OMEowLAF2m12tAtITnd4nE4X7yrjYuqSZ2NeiIHhfC2H7TFme a46LdHv4huMBxqpGOTFn+s9xcVAnAlH0LBIkYby4IMelw6VeXq3jjYewHBjaIx7jNx2fWDWLE9iM HW6y5JLnSgueTUXgRnxNTkHUoG0WGL2DtVmZy017387fReRa+EOM2AhGqnd7jSrkk8zCvqkfjprl ghinOENomQR2vCYApHLGBLckwoREKSOdrxRXhv4Gp/UZ1CJD9WmOtQw6M4FkA8McDK/fLz6tWDAv QjdrasKWw/QUe0P6eRncHN2Sntz6ngTOLkGcCgAAAAAAAA== ------=_NextPart_000_0007_01D63A85.59815D80-- From nobody Thu Jun 4 17:06: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 A04E33A1097 for ; Thu, 4 Jun 2020 17:06:43 -0700 (PDT) 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 noGvtpMhCiNy for ; Thu, 4 Jun 2020 17:06:42 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 0EC003A1096 for ; Thu, 4 Jun 2020 17:06:42 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id r2so8397882ioo.4 for ; Thu, 04 Jun 2020 17:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fre2DPsnThD4bhMz5APX9cH1NB7pcU3HrtAeSVrxrng=; b=iZGYFDPnFJdEmh6IyRjqST1QgBj4scnYj4R/DS4mIt+ZN6g+iTHh5M5eQF2+OFL1Tk JrHA1VdNF6OYGiuERh2b/86U6gfZYTJfLegysJ04qt7oNtQW+efjymjU1cBJHaThsps5 0bA/hFu0yFcB2b8r7uK+4xcrZPi7y+E3Q3ZltnC/YXtscSp4rJHMTnhcr4+ErXOB58wk 96VGztdLUBQel3LwoUucWuKvjJq/Ymbe50hEkpW1UVE2WRss01g1Ih9OPStLltfn5CsJ h/ONvHwDIJJdmO+JOX0bIDECnbeyqvXA0F2QiB6ExP0yRT+fYLx/Dr+PG0kW5q0kL3uv XuDg== 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=Fre2DPsnThD4bhMz5APX9cH1NB7pcU3HrtAeSVrxrng=; b=ofEbni2N2p1Xe3gwVuLOVbgtAe4bjDEbpvqgGAdFp+rm696gQPr/aZ38Sb1QCprkk3 Vf7SAk1LuY8YdCrVXPkhxbPV2CrOYVwxlPaWF9Y0vOUsEB/qSrWaCDL3bXZ2uUnJhLar XIUAJBDxA105U2/TW1OuowyqI15fKHIInz6qN6zvOfwhBwAU5nu1vrqkVkF/9gaNiO1g vdAJjnDa0+cxM3RTbInotRrwDH7KkrzTMPEJSwN6mxcG7gR4CK4ihnNLbw75xQHFOSvN lAXTBNOTWmqJH+38a62D3gk7EVM1XRccVqjbJ4B7Gk33lOWzwZ+yD9Dthbljf5GCQ0aD R9ww== X-Gm-Message-State: AOAM530H5U6wySbtPHfGCBjxAgIdGQiST2RaADJqlLJjNiO86f91c/El X4eMBeUU8YWsqczUsWDHgX5EfcMep+Lkjg3Td7s= X-Google-Smtp-Source: ABdhPJwZIjveQii+RxhDcKrbZ0JnZ9pCvWTOzguvx62PUHqlM7lSfHiZFJBszkNzflEA9GicqwFcedDK95KC68Ouy4U= X-Received: by 2002:a05:6602:2ac9:: with SMTP id m9mr6357147iov.68.1591315601233; Thu, 04 Jun 2020 17:06:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mohit Sahni Date: Thu, 4 Jun 2020 17:06:30 -0700 Message-ID: To: "Panos Kampanakis (pkampana)" Cc: Jim Schaad , "Brockhaus, Hendrik" , LAMPS WG Content-Type: multipart/alternative; boundary="000000000000231f6805a74b094a" Archived-At: Subject: Re: [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport 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, 05 Jun 2020 00:06:44 -0000 --000000000000231f6805a74b094a Content-Type: text/plain; charset="UTF-8" Panos, I am sorry, I did not understand the first part of your comment. Can you please elaborate on which two same protocols you are referring to here that will work on CoAP? -Mohit On Thu, Jun 4, 2020 at 12:32 PM Panos Kampanakis (pkampana) < pkampana@cisco.com> wrote: > Great. We can now once again have more than one protocols that do the same > thing over the same transport protocol. > > > > This should go in the ACE WG. ACE worked on EST-coaps > (draft-ietf-ace-coap-est) as well. > > > > Panos > > > > > > *From:* Spasm *On Behalf Of *Mohit Sahni > *Sent:* Thursday, June 04, 2020 2:04 PM > *To:* Jim Schaad ; Brockhaus, Hendrik < > hendrik.brockhaus@siemens.com>; LAMPS WG > *Subject:* [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport > > > > Hi Jim, > > There were some discussions about using CoAP as transport for the > Lightweight CMP profile in the last LAMPS WG meeting. After having some > discussions with Hendrik, David, and Andreas I have written an > internet-draft for using CoAP as transport for CMPv2 / Light Weight CMP > Profile. If I am not mistaken, the recommendation was to present this draft > to ACE WG for the review instead of Lamps group, can you please advice on > that? > > > > Here is the link to the internet-draft that I wrote > https://www.ietf.org/id/draft-msahni-tbd-cmpv2-coap-transport-00.txt > > Thanks > > Mohit > --000000000000231f6805a74b094a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Panos,
I am sorry, I did not understand the first part= of your comment. Can you please elaborate on which two same protocols you = are referring to here that=C2=A0will work on CoAP?=C2=A0

-Mohit

On Thu, Jun 4, 2020 at 12:32 PM Panos Kampanakis (pkampa= na) <pkampana@cisco.com> wr= ote:

Great. We can now once = again have more than one protocols that do the same thing over the same tra= nsport protocol.

=C2=A0

This should go in the ACE WG. AC= E worked on EST-coaps (draft-ietf-ace-coap-est) as well.

= =C2=A0

Panos

=C2=A0

=C2=A0

From: Spasm <spasm-bounces@ietf.org> On Behalf Of= Mohit Sahni
Sent: Thursday, June 04, 2020 2:04 PM
To:<= /b> Jim Schaad <ietf@augustcellars.com>; Brockhaus, Hendrik <hendrik.brockhaus@siemen= s.com>; LAMPS WG <spasm@ietf.org>
Subject: [lamps] CMPv2/LightWeiight-C= MP profile over CoAP transport

<= /u>=C2=A0

Hi Jim,=

There were some discussions about= using CoAP as transport for the Lightweight CMP profile in the last LAMPS = WG meeting. After having some discussions with Hendrik, David, and=C2=A0And= reas I have written an internet-draft for using CoAP as transport for CMPv2= / Light Weight CMP Profile. If I am not=C2=A0mistaken, the=C2=A0recommenda= tion was to present this draft to ACE WG for the review instead of Lamps gr= oup, can you please advice on that?

=C2=A0

Here is the link to the internet-draft that I wrote= https://www.ietf.org/id/draft-msahni-tbd-cmpv2-coa= p-transport-00.txt=C2=A0

Thanks

Mohit=C2=A0= =C2=A0

--000000000000231f6805a74b094a-- From nobody Thu Jun 4 22:40: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 6817D3A12B6 for ; Thu, 4 Jun 2020 22:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=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=primekey.se header.b=nhrFQD9O; dkim=pass (1024-bit key) header.d=primekey.se header.b=nhrFQD9O 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 cStrHcHNP_uR for ; Thu, 4 Jun 2020 22:40:38 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB4B3A12B5 for ; Thu, 4 Jun 2020 22:40:37 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id E8C5F6AA0084 for ; Fri, 5 Jun 2020 07:40:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.se; s=mail; t=1591335608; bh=gr02zpYZ2s5oiVCbxkgS3pXeXwuys5TGv7M4WuIU8nI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=nhrFQD9OE9dZw1huMRkUJJPgcBI5GSMc/XqUgBUXZi7ksRFUnF8aXhMllNRLB7opc Dc4M9546UCT9TdRmeN4ceVsHP4QnWAea8F+fSomeGnzXhjJSOKZxteUQFZpzAUxa3S k6+jZ/BiJPjG+sqtmanM9UUNKC7PUzgfA1IFSIe8= Received: from [10.11.0.2] (gatekeeper.primekey.se [84.55.121.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id CA5246AA006D for ; Fri, 5 Jun 2020 07:40:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.se; s=mail; t=1591335608; bh=gr02zpYZ2s5oiVCbxkgS3pXeXwuys5TGv7M4WuIU8nI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=nhrFQD9OE9dZw1huMRkUJJPgcBI5GSMc/XqUgBUXZi7ksRFUnF8aXhMllNRLB7opc Dc4M9546UCT9TdRmeN4ceVsHP4QnWAea8F+fSomeGnzXhjJSOKZxteUQFZpzAUxa3S k6+jZ/BiJPjG+sqtmanM9UUNKC7PUzgfA1IFSIe8= To: spasm@ietf.org References: From: Tomas Gustavsson Autocrypt: addr=tomas@primekey.se; 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: <1978e1d6-ae62-1b85-1e70-062aee0fcc89@primekey.se> Date: Fri, 5 Jun 2020 07:40:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.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] CMPv2/LightWeiight-CMP profile over CoAP transport 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, 05 Jun 2020 05:40:42 -0000 Hi, I noticed that section 4, Proxy Support (good section btw), mentions Announcement messages. These are excluded from the Lightweight specification. Since the LIghtweight specification is mentioned in the beginning, I'm not sure if that's worth mentioning here? Cheers, Tomas On 2020-06-04 20:03, Mohit Sahni wrote: > Hi Jim, > There were some discussions about using CoAP as transport for the > Lightweight CMP profile in the last LAMPS WG meeting. After having some > discussions with Hendrik, David, and Andreas I have written an > internet-draft for using CoAP as transport for CMPv2 / Light Weight CMP > Profile. If I am not mistaken, the recommendation was to present this > draft to ACE WG for the review instead of Lamps group, can you please > advice on that? > > Here is the link to the internet-draft that I wrote > https://www.ietf.org/id/draft-msahni-tbd-cmpv2-coap-transport-00.txt  > > Thanks > Mohit   > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Thu Jun 4 22:48:51 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 28CFE3A12BD for ; Thu, 4 Jun 2020 22:48:49 -0700 (PDT) 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 1ACtgj3BghHw for ; Thu, 4 Jun 2020 22:48:47 -0700 (PDT) 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 2843F3A12BA for ; Thu, 4 Jun 2020 22:48:47 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id s18so9022709ioe.2 for ; Thu, 04 Jun 2020 22:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jScaQykC9yx5G5WuBQE+a+Oa42mMZnuu5iomEKsi0+I=; b=IGysqPVD51wTz3jqOSzSSdc27NcciwG0cvfpYPimpiV8zZEPm1NDVLGSDHIehW9YHg 5DJ0w3OjfkLOAHPX9CrOWRwN7KuCX8/SjYxvPlGV4fbv8NlHrTLCqSOkgZQVGYUBPmrq HSzodBg/GoByVVJUEl4xX72g2bSr9IE0p+hp3p5ggPXUHKq4/MlNdIKuQR8BV3N+muYQ BQszndPNPK92YXAer54NbllNpD2PnO6yqWQEs3AA/8t3wnXQvC1apezqGlLOohpXoplK UhIjjRdgP/7+ISsVR0egusrDWNYhhc1akxPAfPsLURyBoDrN7iQNeUFBp5EE6Sohzj8E WioA== 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=jScaQykC9yx5G5WuBQE+a+Oa42mMZnuu5iomEKsi0+I=; b=rtTIE5njUWZeR1yAYqVGnw1XZr0fpdgd0X42//aHtshHc4DOvL/CYyEVgrr/JAYx5l ADvwEwt/YA1ObMChyN1fp6P+me1pFpKO54tPaBljPH/cgg12prh3Iwe8j6CKpnPM5/+z tUPlqyZNCofe06+ECcBzAKe+QSCd/PU5zkP71oWny2kKJn0E0Yq1fi0+yYi7OMkENENW QBeZzOxlJX3rrWtO2czarRBSE3OmtsQRU1WYrirOi32fUvPlTyegRLEwYSIhLNzVgopz fDCvmmb773opaj4k5N8Ze/aPdLVMb1NDofd36V5BLYB9xjkMCfyV2zWBy55UcztrOthn BMqg== X-Gm-Message-State: AOAM5335kjjXE3XnW8jBvCrBq7/vPjwOjJwGOEbMHFZB5qR/qP07QtEN 6qVyG9UlfBd+xjSDMz0mzUWMbhqu93GnzeUMOFOCxQ== X-Google-Smtp-Source: ABdhPJwc6oF3HzKaUvmYcFiOpJdmMZx6D8L2H1P7VRIBcuYxaGwwb35i7t9w/xdIHcHye4bwQxIz6LEXZXSA2dBBPzE= X-Received: by 2002:a05:6638:b:: with SMTP id z11mr7029254jao.114.1591336124726; Thu, 04 Jun 2020 22:48:44 -0700 (PDT) MIME-Version: 1.0 References: <1978e1d6-ae62-1b85-1e70-062aee0fcc89@primekey.se> In-Reply-To: <1978e1d6-ae62-1b85-1e70-062aee0fcc89@primekey.se> From: Mohit Sahni Date: Thu, 4 Jun 2020 22:48:34 -0700 Message-ID: To: Tomas Gustavsson Cc: LAMPS WG Content-Type: multipart/alternative; boundary="0000000000006ec4af05a74fd0c3" Archived-At: Subject: Re: [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport 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, 05 Jun 2020 05:48:49 -0000 --0000000000006ec4af05a74fd0c3 Content-Type: text/plain; charset="UTF-8" Hi Tomas Thanks for the feedback, I was trying to write it in a way so that it can work for both CMPv2 and LightWeight CMP, I have noted it your feedback and I will try to make it more clear. -Mohit On Thu, Jun 4, 2020 at 10:40 PM Tomas Gustavsson wrote: > Hi, > > I noticed that section 4, Proxy Support (good section btw), mentions > Announcement messages. These are excluded from the Lightweight > specification. Since the LIghtweight specification is mentioned in the > beginning, I'm not sure if that's worth mentioning here? > > Cheers, > Tomas > > On 2020-06-04 20:03, Mohit Sahni wrote: > > Hi Jim, > > There were some discussions about using CoAP as transport for the > > Lightweight CMP profile in the last LAMPS WG meeting. After having some > > discussions with Hendrik, David, and Andreas I have written an > > internet-draft for using CoAP as transport for CMPv2 / Light Weight CMP > > Profile. If I am not mistaken, the recommendation was to present this > > draft to ACE WG for the review instead of Lamps group, can you please > > advice on that? > > > > Here is the link to the internet-draft that I wrote > > https://www.ietf.org/id/draft-msahni-tbd-cmpv2-coap-transport-00.txt > > > > Thanks > > Mohit > > > > _______________________________________________ > > Spasm mailing list > > Spasm@ietf.org > > https://www.ietf.org/mailman/listinfo/spasm > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --0000000000006ec4af05a74fd0c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Tomas
Thanks for the feedback, I was trying=C2= =A0to write it in a way so that it can work for both CMPv2 and LightWeight = CMP, I have noted it your=C2=A0feedback and I will try to make it more clea= r.

-Mohit=C2=A0

On Thu, Jun 4, 2020 at 10:40 = PM Tomas Gustavsson <tomas@primekey= .se> wrote:
Hi,

I noticed that section 4, Proxy Support (good section btw), mentions
Announcement messages. These are excluded from the Lightweight
specification. Since the LIghtweight specification is mentioned in the
beginning, I'm not sure if that's worth mentioning here?

Cheers,
Tomas

On 2020-06-04 20:03, Mohit Sahni wrote:
> Hi Jim,
> There were some discussions about using CoAP as transport for the
> Lightweight CMP profile in the last LAMPS WG meeting. After having som= e
> discussions with Hendrik, David, and=C2=A0Andreas I have written an > internet-draft for using CoAP as transport for CMPv2 / Light Weight CM= P
> Profile. If I am not=C2=A0mistaken, the=C2=A0recommendation was to pre= sent this
> draft to ACE WG for the review instead of Lamps group, can you please<= br> > advice on that?
>
> Here is the link to the internet-draft that I wrote
> https://www.ietf.org/id/dra= ft-msahni-tbd-cmpv2-coap-transport-00.txt=C2=A0
>
> Thanks
> Mohit=C2=A0=C2=A0
>
> _______________________________________________
> 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
--0000000000006ec4af05a74fd0c3-- From nobody Thu Jun 4 23:50: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 235963A131D for ; Thu, 4 Jun 2020 23:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_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 EFU4uaiDpeCM for ; Thu, 4 Jun 2020 23:50:43 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20058.outbound.protection.outlook.com [40.107.2.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 EC7BA3A0900 for ; Thu, 4 Jun 2020 23:50:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h9yVOrFMVcdf41ov21Q4bDBpid5vXDlXjBex2z8k/mIGd9Sl4KXmkuV59FPBNgyFgHCo5nUlSP0lA0p5rg+O9UWm2+2bIjSDF/kWcwPOMEeeC7eJmlHh3BAuW9wfMYh2hIr6rlMu3LB5zZHyJTRFFc88X5JPFQSlGFWBMF32XCrkshaUEzHTU/2xSq2nQFNfS7+Q13XtihA5xU5WkomZxUS+nkD2ej9XyljYneKzGNre1sYzzfXfktEPhHBHy3uINI2yRo+UFGKYtvyqqHiTB1ggkN7pyhn14ptqDeRK+wGoisB5xTky1xLzy6/QZzL5WPJS1XwhltrS6EjO97mUMg== 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=FzJFjDSOneHKpSbQPTK68XiJXoRZ1sC3l7TtSZhZ7cs=; b=H8NofdbZLfFyge2l3pOppxAHoecl+AnBVXYx+05wF1Z++OzLuh2yp0CQOrfec3CaUmkVBR2rWQEnsz0xyaCB/pvGn0QsEi80UHWg/SjpzVJd981hIipm7KZ0NpQxaBf2aqvkhClWXlBaCHt54LstTRczsFW13IN0XZ1TiuCCgp4iW2Mqb9ocNUb+MsuCp0clEx2A6g/+EkNkYKidjb2P83QhyMm6B9wfzfP2qPsLkvpYrfwqmtMcDKG7/XWohjh/6dmFAAPhC9CkgORZslwEg0T2CUDK7sJx/2eJTghTNWZ6UH4Swe6F3SG8ECq0Yj/9SgtfmrGUOlQPBxhUQCa5QA== 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=FzJFjDSOneHKpSbQPTK68XiJXoRZ1sC3l7TtSZhZ7cs=; b=j96nRGrIGofIG2Fnpb3RZzTypAnqOlXfhTj54j3uwkQepWLAVuGofUWKXjFKMwlT/8hXEjwvjErlrJeQ3mNSkm81M/HjGKWvhX8ryi3S50P9P4gd5vrl+lowbN+Q95hseywnfIM+bftZPbeffAoqzFvPjBnH+1Q81zjLPCl3nis= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:e2::32) by AM0PR10MB3651.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:156::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Fri, 5 Jun 2020 06:50:40 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::ccfa:a7d4:79ed:c39a]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::ccfa:a7d4:79ed:c39a%4]) with mapi id 15.20.3066.019; Fri, 5 Jun 2020 06:50:40 +0000 From: "Brockhaus, Hendrik" To: Mohit Sahni CC: Jim Schaad , LAMPS WG Thread-Topic: CMPv2/LightWeiight-CMP profile over CoAP transport Thread-Index: AQHWOpqMTaopCwilUkGOk9vnrw2MI6jJlOoQ Date: Fri, 5 Jun 2020 06:50:40 +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: x-document-confidentiality: NotClassified 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.161] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ee47eacb-f290-4bd4-3b62-08d8091cc2f7 x-ms-traffictypediagnostic: AM0PR10MB3651: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0425A67DEF x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aT9Ag645qXZYsbxClMfrGI364JrBsyhvpE6RpsawrFyHZ8a8dYpX1GhHbP796BoULvPMP2NyLyjNIelGeqBDE5vGfh5XZyG3SltAqWPV1fozfFra/3gX5noPIqRNEbb2z3NKRUrWzXsGvqMGaxdWcE8Z4/xUQA8riOKMI7rRKiDRzbJ9GhSvjPg2gtxuijgQPRK8jfgeFqomjcEzUzyC+KhnnrHwx8A2GLQoqgjzkMu8p0z/+YShgTZvuWfQPkQKVN2QTMi1v58osMYHh2jNaVUbMmp+akMRzgzHaADRRX/KJ4qRl0dVYsEcse3EzR9BhxSTsglZZ7xzYh97PyOsH+M1YvAJqPs9KQoqSg2cW+P8ool+JumtGpoGPLI5YLoBPkyU7tM2NQM/AtbG2obc4Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(376002)(346002)(396003)(136003)(52536014)(5660300002)(966005)(66946007)(316002)(66556008)(66574014)(478600001)(6506007)(64756008)(7696005)(66446008)(66476007)(76116006)(54906003)(33656002)(55236004)(86362001)(6916009)(71200400001)(55016002)(8936002)(4326008)(186003)(2906002)(558084003)(26005)(9686003)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 7WTu3l4vnl9qR/AR5KygyeZ+5mYoL7Cge7yBKgCqpQuBrS/l1s/WX7zotgBSBpv4Zjj0NwqodcRsRFUd8fHmC5jUBUg6Q5I4Oi2I32SkiL1EVRJT3nosr5dtJxmMsbvfyKtpkUPLY94gnCtcOe8LT8ZSAK+a5/1VF7X2zGZU1aflZkIS2zyBK9jvOpjS2C3F/1PLIxUXI9tcH51eQNy0JudUqdbDHU0pOgbtDzdv4mTJ54te3tVNVGOkH+C8U9tqpka00T5rLcUk/GWvfdJ2PnZCvOLxmFfqffEwPKSLjVlzQbxOYDO8cbM0r2Aj/9KgwR7UIR23UBORkzFuHZiPt4zLQcPQ1LNCJ/gGmBRTEr8wKqwUZ0crZR7vlwcjs0hdi7rnwEMlpQeiOvD9DTMBV85dUr1xwvXrnPWeTrIFYmrN3ZY+GvEy3UePcDBU9gHyWmAJmPdmpzBhrf/qFHLahpqUKkcxsHDT0QKP28ob0MhYVJZrxpQcHLdhlVwyC7AW x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: ee47eacb-f290-4bd4-3b62-08d8091cc2f7 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2020 06:50:40.6322 (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: xdA7h4tZzOL8B7kiaVnkWiadgII4ZrgI9Mnxu/620XMC5EVmHvklnYaf5+jI3IZclMImqf2r3HYXhB3FQCmB524GyQaH0ifXBdQhjli4hVY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB3651 Archived-At: Subject: Re: [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport 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, 05 Jun 2020 06:50:45 -0000 SGkgTW9oaXQNCg0KPiBWb246IE1vaGl0IFNhaG5pIDxtb2hpdDA2amFuQGdtYWlsLmNvbT4gDQo+ IEdlc2VuZGV0OiBEb25uZXJzdGFnLCA0LiBKdW5pIDIwMjAgMjA6MDQNCj4NCj4gSGVyZSBpcyB0 aGUgbGluayB0byB0aGUgaW50ZXJuZXQtZHJhZnQgdGhhdCBJIHdyb3RlIGh0dHBzOi8vd3d3Lmll dGYub3JnL2lkL2RyYWZ0LW1zYWhuaS10YmQtY21wdjItY29hcC10cmFuc3BvcnQtMDAudHh0DQo+ DQpUaGFua3MgZm9yIHN1Ym1pdHRpbmcgdGhpcyBkcmFmdC4gDQpJIHdpbGwgcmVmZXJlbmNlIGl0 IGluIHRoZSBMaWdodHdlaWdodCBDTVAgUHJvZmlsZSBkcmFmdC4NCg0KLSBIZW5kcmlrDQo= From nobody Fri Jun 5 19:19:15 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 89AF73A083F for ; Fri, 5 Jun 2020 19:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKlFQuAECvDs for ; Fri, 5 Jun 2020 19:19:11 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7BD23A0841 for ; Fri, 5 Jun 2020 19:19:10 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 5 Jun 2020 19:19:05 -0700 From: Jim Schaad To: 'Mohit Sahni' CC: 'LAMPS WG' References: <1978e1d6-ae62-1b85-1e70-062aee0fcc89@primekey.se> In-Reply-To: Date: Fri, 5 Jun 2020 19:19:02 -0700 Message-ID: <000101d63ba8$d9cd4020$8d67c060$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01D63B6E.2D6F2B70" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIFJAWnONllgwTy/fIIRAQ8KldUkgEREqChAUsuCcCoWiaT4A== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport 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, 06 Jun 2020 02:19:14 -0000 ------=_NextPart_000_0002_01D63B6E.2D6F2B70 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I suppose that this could go into the ACE working group, but it will = require a charter change to do so. =20 =20 I would suggest that you review the EST document with special attention = to the sections on DTLS and proxying. It would also help to have some = idea of guidance for when coap or coaps is going to be used. I am not = sure that this strongly exists in CMP as my very vague memory was that = it was assumed that all transactions where going to be done over TLS = with server validation as a minimum. =20 Jim =20 =20 From: Spasm On Behalf Of Mohit Sahni Sent: Thursday, June 4, 2020 10:49 PM To: Tomas Gustavsson Cc: LAMPS WG Subject: Re: [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport =20 Hi Tomas Thanks for the feedback, I was trying to write it in a way so that it = can work for both CMPv2 and LightWeight CMP, I have noted it your = feedback and I will try to make it more clear. =20 -Mohit=20 =20 On Thu, Jun 4, 2020 at 10:40 PM Tomas Gustavsson > wrote: Hi, I noticed that section 4, Proxy Support (good section btw), mentions Announcement messages. These are excluded from the Lightweight specification. Since the LIghtweight specification is mentioned in the beginning, I'm not sure if that's worth mentioning here? Cheers, Tomas On 2020-06-04 20:03, Mohit Sahni wrote: > Hi Jim, > There were some discussions about using CoAP as transport for the > Lightweight CMP profile in the last LAMPS WG meeting. After having = some > discussions with Hendrik, David, and Andreas I have written an > internet-draft for using CoAP as transport for CMPv2 / Light Weight = CMP > Profile. If I am not mistaken, the recommendation was to present this > draft to ACE WG for the review instead of Lamps group, can you please > advice on that? >=20 > Here is the link to the internet-draft that I wrote > https://www.ietf.org/id/draft-msahni-tbd-cmpv2-coap-transport-00.txt=20 >=20 > Thanks > Mohit =20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org =20 > https://www.ietf.org/mailman/listinfo/spasm >=20 _______________________________________________ Spasm mailing list Spasm@ietf.org =20 https://www.ietf.org/mailman/listinfo/spasm ------=_NextPart_000_0002_01D63B6E.2D6F2B70 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I suppose = that this could go into the ACE working group, but it will require a = charter change to do so.=C2=A0

 

I would = suggest that you review the EST document with special attention to the = sections on DTLS and proxying.=C2=A0 It would also help to have some = idea of guidance for when coap or coaps is going to be used.=C2=A0 I am = not sure that this strongly exists in CMP as my very vague memory was = that it was assumed that all transactions where going to be done over = TLS with server validation as a minimum.

 

Jim

 

 

From: Spasm = <spasm-bounces@ietf.org> On Behalf Of Mohit = Sahni
Sent: Thursday, June 4, 2020 10:49 PM
To: = Tomas Gustavsson <tomas@primekey.se>
Cc: LAMPS WG = <spasm@ietf.org>
Subject: Re: [lamps] = CMPv2/LightWeiight-CMP profile over CoAP = transport

 

Hi Tomas

Thanks for the feedback, I was trying to write it = in a way so that it can work for both CMPv2 and LightWeight CMP, I have = noted it your feedback and I will try to make it more = clear.

 

-Mohit 

 

On = Thu, Jun 4, 2020 at 10:40 PM Tomas Gustavsson <tomas@primekey..se> = wrote:

Hi,

I noticed that section 4, Proxy Support = (good section btw), mentions
Announcement messages. These are = excluded from the Lightweight
specification. Since the LIghtweight = specification is mentioned in the
beginning, I'm not sure if that's = worth mentioning here?

Cheers,
Tomas

On 2020-06-04 = 20:03, Mohit Sahni wrote:
> Hi Jim,
> There were some = discussions about using CoAP as transport for the
> Lightweight = CMP profile in the last LAMPS WG meeting. After having some
> = discussions with Hendrik, David, and Andreas I have written = an
> internet-draft for using CoAP as transport for CMPv2 / Light = Weight CMP
> Profile. If I am not mistaken, = the recommendation was to present this
> draft to ACE WG for = the review instead of Lamps group, can you please
> advice on = that?
>
> Here is the link to the internet-draft that I = wrote
> https://www.ietf.org/id/draft-msahni-tbd-cmpv2-coap-tra= nsport-00.txt 
>
> Thanks
> = Mohit  
>
> = _______________________________________________
> Spasm mailing = list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>=

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

------=_NextPart_000_0002_01D63B6E.2D6F2B70-- From nobody Sat Jun 6 10:01: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 A9D103A0ECB for ; Sat, 6 Jun 2020 10:01:17 -0700 (PDT) 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 sJzbPRoCOze0 for ; Sat, 6 Jun 2020 10:01:16 -0700 (PDT) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 17C513A0ECA for ; Sat, 6 Jun 2020 10:01:16 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id h3so12788184ilh.13 for ; Sat, 06 Jun 2020 10:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y9hntt1QqmPHqOqVUe09HAkgVBlwdXXJJaOSmgU5sXo=; b=tI1/Bhqcq9V82BXuJGZO5dpARjVhcvh6Qu8XCWT3nZTtTIwaLCIuhQ0hjr4rN/EOJ8 d1RXQ3EXl8g5zUnVDSm1nRgBjW25VcEPhSLNtwji27Z4QNVPJCjkD/n6zApSM72EFoXt 7KcsEZRtTC8bUe3tQG8kR1+rJKhncluLeW4B9pfTLLEECeuj0DXggyGCtErKcIjpcIaw pYVHjugnV+poQdMzG3mFd1v2hiOHk+8HJdEdNcaHQ9y1mbgcMvV27ZvbHSTWddlyaPGy T5UibsWht+ilUWp5Bl+AVhmoxXy6sZjltHQb3YsLQv09MM44I4FgD/6t4jmXl7l1Z4ah tkaw== 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=Y9hntt1QqmPHqOqVUe09HAkgVBlwdXXJJaOSmgU5sXo=; b=pCyZt/PqAeFRulqf88M48tR81Ygw7iiWXn6aMpHhf8LQqKpS3iFq0YN0EMq6O4j2A8 NRD4SA/0nM0pdHTAoNk5ivY9fciWJ6HgQKpMyhpE0cPWvE0hb1fwEBuunrDwAZQtZygw aT25DvB8oy0huO+Ulh056uZVx5TvY2aTo+jIGSJspLJxbVvVb6zCuIoGENpGKXFKiBbX uuE0iTbZ3SlEuctBvqAKYHBay8CSpjlFcup0OeGdMfEwZh9UUa6Tp4BxgvG3G5SUYrbW alZihtFdXS/ri810Sv68eBMH7ouSFGxmTgjZwoGa1+kcKZ9v5MUNiNA2gdy+qzZjlfsf 0qXA== X-Gm-Message-State: AOAM53109827L95WxZxIPli28oQN6w/cxgdH1SBs1GFGE6Z1L/M8Eh09 HBFBDb17GbkOISgVGuPKGfF+K6jrhirHxLaNeHY= X-Google-Smtp-Source: ABdhPJw/xQNtMLstRRHcLkvUGgl+aniosiORJzbXhjVpBZOgVyIHsN4mEcrGCGYbSwsnpNDwAEPHp991vYly5EOmdgY= X-Received: by 2002:a92:4885:: with SMTP id j5mr12852424ilg.35.1591462873865; Sat, 06 Jun 2020 10:01:13 -0700 (PDT) MIME-Version: 1.0 References: <1978e1d6-ae62-1b85-1e70-062aee0fcc89@primekey.se> <000101d63ba8$d9cd4020$8d67c060$@augustcellars.com> In-Reply-To: <000101d63ba8$d9cd4020$8d67c060$@augustcellars.com> From: Mohit Sahni Date: Sat, 6 Jun 2020 10:01:02 -0700 Message-ID: To: Jim Schaad Cc: LAMPS WG Content-Type: multipart/alternative; boundary="0000000000004520ee05a76d5356" Archived-At: Subject: Re: [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport 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, 06 Jun 2020 17:01:18 -0000 --0000000000004520ee05a76d5356 Content-Type: text/plain; charset="UTF-8" Hi Jim, Thanks for the feedback. I will go over the EST document and update sections around DTLS and proxying and address your other comments. Once ready, I will post the draft in ACE WG. Regards, Mohit On Fri, Jun 5, 2020 at 7:19 PM Jim Schaad wrote: > I suppose that this could go into the ACE working group, but it will > require a charter change to do so. > > > > I would suggest that you review the EST document with special attention to > the sections on DTLS and proxying. It would also help to have some idea of > guidance for when coap or coaps is going to be used. I am not sure that > this strongly exists in CMP as my very vague memory was that it was assumed > that all transactions where going to be done over TLS with server > validation as a minimum. > > > > Jim > > > > > > *From:* Spasm *On Behalf Of *Mohit Sahni > *Sent:* Thursday, June 4, 2020 10:49 PM > *To:* Tomas Gustavsson > *Cc:* LAMPS WG > *Subject:* Re: [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport > > > > Hi Tomas > > Thanks for the feedback, I was trying to write it in a way so that it can > work for both CMPv2 and LightWeight CMP, I have noted it your feedback and > I will try to make it more clear. > > > > -Mohit > > > > On Thu, Jun 4, 2020 at 10:40 PM Tomas Gustavsson > wrote: > > Hi, > > I noticed that section 4, Proxy Support (good section btw), mentions > Announcement messages. These are excluded from the Lightweight > specification. Since the LIghtweight specification is mentioned in the > beginning, I'm not sure if that's worth mentioning here? > > Cheers, > Tomas > > On 2020-06-04 20:03, Mohit Sahni wrote: > > Hi Jim, > > There were some discussions about using CoAP as transport for the > > Lightweight CMP profile in the last LAMPS WG meeting. After having some > > discussions with Hendrik, David, and Andreas I have written an > > internet-draft for using CoAP as transport for CMPv2 / Light Weight CMP > > Profile. If I am not mistaken, the recommendation was to present this > > draft to ACE WG for the review instead of Lamps group, can you please > > advice on that? > > > > Here is the link to the internet-draft that I wrote > > https://www.ietf.org/id/draft-msahni-tbd-cmpv2-coap-transport-00.txt > > > > Thanks > > Mohit > > > > _______________________________________________ > > Spasm mailing list > > Spasm@ietf.org > > https://www.ietf.org/mailman/listinfo/spasm > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > --0000000000004520ee05a76d5356 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jim,
Thanks for the feedback. I will go over = the EST document and update sections around DTLS and proxying and address y= our other comments. Once ready, I will post the draft in ACE WG.
<= br>
Regards,
Mohit=C2=A0

=

= On Fri, Jun 5, 2020 at 7:19 PM Jim Schaad <ietf@augustcellars.com> wrote:

I suppose that t= his could go into the ACE working group, but it will require a charter chan= ge to do so.=C2=A0

=C2=A0

I would suggest that you review the EST doc= ument with special attention to the sections on DTLS and proxying.=C2=A0 It= would also help to have some idea of guidance for when coap or coaps is go= ing to be used.=C2=A0 I am not sure that this strongly exists in CMP as my = very vague memory was that it was assumed that all transactions where going= to be done over TLS with server validation as a minimum.

=

=C2=A0

Jim

=C2=A0

=C2=A0

From: Spasm <spasm-bounces@ietf.org> <= b>On Behalf Of Mohit Sahni
Sent: Thursday, June 4, 2020 10:49= PM
To: Tomas Gustavsson <tomas@primekey.se>
Cc: LAMPS WG <spasm@ietf.org>
= Subject: Re: [lamps] CMPv2/LightWeiight-CMP profile over CoAP transp= ort

=C2=A0

<= div>

Hi=C2=A0Tomas

Thanks for the feedback, I was trying=C2=A0to write it in a way = so that it can work for both CMPv2 and LightWeight CMP, I have noted it you= r=C2=A0feedback and I will try to make it more clear.

=C2=A0

-Mohit=C2=A0

=C2=A0

On Thu, Jun 4= , 2020 at 10:40 PM Tomas Gustavsson <tomas@primekey..se> wrote:

Hi,

I noticed that s= ection 4, Proxy Support (good section btw), mentions
Announcement messag= es. These are excluded from the Lightweight
specification. Since the LIg= htweight specification is mentioned in the
beginning, I'm not sure i= f that's worth mentioning here?

Cheers,
Tomas

On 2020-= 06-04 20:03, Mohit Sahni wrote:
> Hi Jim,
> There were some dis= cussions about using CoAP as transport for the
> Lightweight CMP prof= ile in the last LAMPS WG meeting. After having some
> discussions wit= h Hendrik, David, and=C2=A0Andreas I have written an
> internet-draft= for using CoAP as transport for CMPv2 / Light Weight CMP
> Profile. = If I am not=C2=A0mistaken, the=C2=A0recommendation was to present this
&= gt; draft to ACE WG for the review instead of Lamps group, can you please> advice on that?
>
> Here is the link to the internet-dr= aft that I wrote
> https://www.ietf.org/id/dr= aft-msahni-tbd-cmpv2-coap-transport-00.txt=C2=A0
>
> Thank= s
> Mohit=C2=A0=C2=A0
>
> ______________________________= _________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.or= g/mailman/listinfo/spasm
>

______________________________= _________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listi= nfo/spasm

=
--0000000000004520ee05a76d5356-- From nobody Wed Jun 10 08:52: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 935703A094E; Wed, 10 Jun 2020 08:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CrMIVIkr-y00; Wed, 10 Jun 2020 08:51:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E01E73A093A; Wed, 10 Jun 2020 08:51:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 30CB138A39; Wed, 10 Jun 2020 11:49:19 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id a6Dmv5aAHGJi; Wed, 10 Jun 2020 11:49:17 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5069A38A37; Wed, 10 Jun 2020 11:49:17 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5CF51534; Wed, 10 Jun 2020 11:51:46 -0400 (EDT) From: Michael Richardson to: secdispatch@ietf.org Reply-to: secdispatch@ietf.org CC: anima@ietf.org, spasm@ietf.org, lwip@ietf.org, acme@ietf.org In-Reply-To: <10463.1591763623@localhost> References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [lamps] IDevID considerations document to secdispatch 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, 10 Jun 2020 15:52:00 -0000 --=-=-= Content-Type: text/plain Dear Secdispatch chairs and WG, (and various people in the BCC who are encouraged to forward) EXEC SUM: https://datatracker.ietf.org/doc/draft-richardson-secdispatch-idevid-considerations/ While working on ANIMA's BRSKI enrollment system, and the associated mechanisms that create the ACP, it became clear that there was possibly a wealth of useful advice on operating the Manufacturer and Owner components (the MASA and Registrar). As these thoughts grew, it became clear that there were many non-normative, non-wire-protocol level design considerations. Two documents were originally created: a) draft-richardson-anima-masa-considerations b) draft-richardson-anima-registrar-considerations Both situations involve operation of a certificate authority. On the manufacturer side, this involves the Manufacturer Installed Certificate, the IDevID. There are multiple users of the IDevID and there are many entities building a variety of trust models based upon having that trust model. For instance, the Kumari/Doyle Secure Device Install/draft-ietf-opsawg-sdi-12 leverages built-in certificates as much as BRSKI does. Much of the RATS work requires some kind of known signing key to be built-in, secured deep into a hardware or firmware TPM/enclave. If you want to (asymmetrically) encrypt firmware for SUIT, you may need keys built in too. Many other protocols also depend upon keys to be deployed, but can deal with having them deployed as part of configuration, but as we all experienced, actually getting them deployed can be difficult. As discussed at the RATS/SUIT/TEEP Hackathon, and later in a few WGs, there seems to be three ways to deploy matching private-key/certificates. a) generate key onboard, sign with EST/SCEP/CMP/magic<%>, b) generate keypair in CA, deploy with EST/SCEP/JTAG/magic, c) simultaneously/deterministically generate keypair from shared secret, deploy certificate via magic. I don't have good names for these three methods, nor sufficient proof that there isn't a reasonable fourth method. One reason (among many) to have names for these three methods is so that it is possible in Supply Chain Security discussions to be able to easily state the inherent security vested in the device, and to thus #include the risk/threat landscape of devices (particularly MCUs) that are included in designs. I believe that EST (RFC7030), SCEP (draft-gutmann-scep) and some lightweight profile of CMP (such as is in LAMPS) are reasonable protocols for factory time onboarding, but require very strict profiling to get right. This makes it IETF business. I would want to have a champion for (a)/(b)/(c) X {EST,SCEP,CMP}., ideally said champion would be describing active experience from a real factory. As publically anchored enterprise (intermediate) CAs seem to be a thing of the past, many have discussed how appropriate it might be for manufacturers to use ACME to provision IDevIDs directly. {In fact, I have running code} There are however many aspects of this effort which might reasonably be considered outside of the IETF perview. Fundamentally, these are PKIX objects that are being provisioned, and it is at the IETF that potential successors to PKIX (CoID, JWTs, etc.) are being developed. One of the major difficulties I have experienced in trying to assemble this document is that current methods are often buried in a Silicon vendor/OEM-board vendor interaction fearing many NDAs. This is particularly acute for method (c). This makes it difficult to ascertain what level of care has been taken with the sensitive symmetric keys, which results in a difficulty to compare audit results across the industry. In order to get better and wider review, as well as detailing the required magic, I've split the MASA considerations document into two pieces. One is BRSKI MASA RFC8366 voucher generation specific, which I intend to leave in the ANIMA WG (should the chairs agree), and the other part which is IDevID generation specific, which I am looking for advice from secdispatch to determine what to do with it. The second document is: https://datatracker.ietf.org/doc/draft-richardson-secdispatch-idevid-considerations/ and it is still rather drafty. I will note that draft-richardson-anima-registrar-considerations also discusses an Operator/Enterprise/Home-router having/operating a CA, (among many other things), and I am undecided whether or not to extract that advice and merge it into idevid-considerations. At this point, I think that it is not of general interest and it is better kept isolated. <%> leveraging Clarke's third law, but possibly also 1st and 2nd law as well. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7hAZIACgkQgItw+93Q 3WUUzAgAkr2uWhXQXc69iIGeKa5xyIYJhwB6k62QcYcoPnWImogUfphZDopQa3n7 DUeU5C64E93u4dP3BfW12tOrjv/cGrWV3nVF81BqKAsT3qHm7sf7kC86yeI2IEMB D2OSq/pe0mfBIFNCT6jgWSNVFvns4GJLxKiWiPuqCJYKIbN2xX0txcOY+EMMrgu0 Wa/sq9DApfP53ZgHm0UK9gXSjuvoWIH6nq40A3T5AZf/JHhAO+gYfQqGQra0M4nH M6ex82L5ucsipq0RgTVFeEBcjcMQ1E7L1QPl7KRAKkW6ogAEt5BgwvWtDjjMSKKd mL0CuAkXOfqSzh3WgNAq14rjr/OQVA== =fgBt -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 11 00: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 C80A13A0F73 for ; Thu, 11 Jun 2020 00:39:30 -0700 (PDT) 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=primekey.com header.b=MuAwDSUz; dkim=pass (1024-bit key) header.d=primekey.com header.b=MuAwDSUz 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 hXQNVdmXA8jV for ; Thu, 11 Jun 2020 00:39:28 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C761A3A0F6B for ; Thu, 11 Jun 2020 00:39:26 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id E4DA46AA009D for ; Thu, 11 Jun 2020 09:39:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1591861147; bh=BWYITa7G2W1hk3JFvV9vBfr8Nt/Z0WMHuMS/x/K49GI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=MuAwDSUzyywYMQxDMcSZrPfl+J0+hzBdu9Q4SmKCldq6MCJswPoOoJlj82Vib9zW8 z/DEUiDMwvo6Omvh1w6Tgx46A5vbtVf/ue3gG6oWL14xqdDMVMpzy6YHZbf/MWugqN 8s93Vos39G0wcC6bdA4F+FNXfg2SRMs9YvH+6v+8= Received: from [10.11.0.10] (gatekeeper.primekey.se [84.55.121.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id C5C736AA0091 for ; Thu, 11 Jun 2020 09:39:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1591861147; bh=BWYITa7G2W1hk3JFvV9vBfr8Nt/Z0WMHuMS/x/K49GI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=MuAwDSUzyywYMQxDMcSZrPfl+J0+hzBdu9Q4SmKCldq6MCJswPoOoJlj82Vib9zW8 z/DEUiDMwvo6Omvh1w6Tgx46A5vbtVf/ue3gG6oWL14xqdDMVMpzy6YHZbf/MWugqN 8s93Vos39G0wcC6bdA4F+FNXfg2SRMs9YvH+6v+8= To: spasm@ietf.org References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> 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: Thu, 11 Jun 2020 09:39:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <13107.1591804306@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] IDevID considerations document to secdispatch 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, 11 Jun 2020 07:39:31 -0000 Hi Michael, It's a good read. One thing confuses me a bit. Please allow for ignorance on my part as my knowledge about manufacturing processes is limited The notion of serialNumber in the document, for me, reads as it's not clear what is the certificate serial number (9-19 bytes in your document) and the device serial number. There don't have to be the same. What I have seen commonly used is that the subjectDN field is used to carry the device serial number, while the certificate serial number is random, and only used to uniquely identify the certificate in the PKI (issuer/serial). In such a case I would assume that the manufacturing execution system (MES) and it's database controls the device serial number, while the PKI controls the certificate serial number, and there does not have to be any synchronization between these two. Regards, Tomas On 2020-06-10 17:51, Michael Richardson wrote: > > Dear Secdispatch chairs and WG, (and various people in the BCC who > are encouraged to forward) > > EXEC SUM: > https://datatracker.ietf.org/doc/draft-richardson-secdispatch-idevid-considerations/ > > While working on ANIMA's BRSKI enrollment system, and the > associated mechanisms that create the ACP, it became clear that > there was possibly a wealth of useful advice on operating the > Manufacturer and Owner components (the MASA and Registrar). As > these thoughts grew, it became clear that there were many > non-normative, non-wire-protocol level design considerations. Two > documents were originally created: a) > draft-richardson-anima-masa-considerations b) > draft-richardson-anima-registrar-considerations > > Both situations involve operation of a certificate authority. On > the manufacturer side, this involves the Manufacturer Installed > Certificate, the IDevID. There are multiple users of the IDevID > and there are many entities building a variety of trust models > based upon having that trust model. For instance, the Kumari/Doyle > Secure Device Install/draft-ietf-opsawg-sdi-12 leverages built-in > certificates as much as BRSKI does. > > Much of the RATS work requires some kind of known signing key to be > built-in, secured deep into a hardware or firmware TPM/enclave. If > you want to (asymmetrically) encrypt firmware for SUIT, you may > need keys built in too. Many other protocols also depend upon keys > to be deployed, but can deal with having them deployed as part of > configuration, but as we all experienced, actually getting them > deployed can be difficult. > > As discussed at the RATS/SUIT/TEEP Hackathon, and later in a few > WGs, there seems to be three ways to deploy matching > private-key/certificates. a) generate key onboard, sign with > EST/SCEP/CMP/magic<%>, b) generate keypair in CA, deploy with > EST/SCEP/JTAG/magic, c) simultaneously/deterministically generate > keypair from shared secret, deploy certificate via magic. I don't > have good names for these three methods, nor sufficient proof that > there isn't a reasonable fourth method. One reason (among many) > to have names for these three methods is so that it is possible in > Supply Chain Security discussions to be able to easily state the > inherent security vested in the device, and to thus #include the > risk/threat landscape of devices (particularly MCUs) that are > included in designs. > > I believe that EST (RFC7030), SCEP (draft-gutmann-scep) and some > lightweight profile of CMP (such as is in LAMPS) are reasonable > protocols for factory time onboarding, but require very strict > profiling to get right. This makes it IETF business. I would want > to have a champion for (a)/(b)/(c) X {EST,SCEP,CMP}., ideally said > champion would be describing active experience from a real > factory. > > As publically anchored enterprise (intermediate) CAs seem to be a > thing of the past, many have discussed how appropriate it might be > for manufacturers to use ACME to provision IDevIDs directly. {In > fact, I have running code} > > There are however many aspects of this effort which might > reasonably be considered outside of the IETF perview. > Fundamentally, these are PKIX objects that are being provisioned, > and it is at the IETF that potential successors to PKIX (CoID, > JWTs, etc.) are being developed. > > One of the major difficulties I have experienced in trying to > assemble this document is that current methods are often buried in > a Silicon vendor/OEM-board vendor interaction fearing many NDAs. > This is particularly acute for method (c). This makes it difficult > to ascertain what level of care has been taken with the sensitive > symmetric keys, which results in a difficulty to compare audit > results across the industry. > > In order to get better and wider review, as well as detailing the > required magic, I've split the MASA considerations document into > two pieces. One is BRSKI MASA RFC8366 voucher generation specific, > which I intend to leave in the ANIMA WG (should the chairs agree), > and the other part which is IDevID generation specific, which I am > looking for advice from secdispatch to determine what to do with > it. > > The second document is: > https://datatracker.ietf.org/doc/draft-richardson-secdispatch-idevid-considerations/ > > and it is still rather drafty. > > I will note that draft-richardson-anima-registrar-considerations > also discusses an Operator/Enterprise/Home-router having/operating > a CA, (among many other things), and I am undecided whether or not > to extract that advice and merge it into idevid-considerations. At > this point, I think that it is not of general interest and it is > better kept isolated. > > > > <%> leveraging Clarke's third law, but possibly also 1st and 2nd > law as well. > > -- Michael Richardson , Sandelman Software > Works -= IPv6 IoT consulting =- > > > > > _______________________________________________ Spasm mailing list > Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm > From nobody Thu Jun 11 08:00: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 AB2E13A091E for ; Thu, 11 Jun 2020 08:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kUq9tI64Snhm for ; Thu, 11 Jun 2020 08:00:00 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F8C73A091B for ; Thu, 11 Jun 2020 08:00:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9A6C9300B6A for ; Thu, 11 Jun 2020 10:59:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ELu3Vo1xDexU for ; Thu, 11 Jun 2020 10:59:56 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 3D04D300A01; Thu, 11 Jun 2020 10:59:56 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Message-Id: Date: Thu, 11 Jun 2020 10:59:57 -0400 Cc: LAMPS To: Michael Richardson X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: [lamps] CSR attrs in rfc7030-clarify X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 15:00:02 -0000 Michael: I have had an email exchange with someone that implemented EST, and they = have pointed out that the aa-asymmDecryptKeyID attribute is not for = inclusion in the CSR. However, when the server does the public/private = key pair generation, it is used to name the key to be used top protect = the server-generated key. This leads to two changes in rfc7030-clarify: In Section 4.1: OLD: AttrSet ATTRIBUTE ::=3D { aa-asymmDecryptKeyID, ... } NEW: AttrSet ATTRIBUTE ::=3D { ... } In Appendix A: OLD: AttrSet ATTRIBUTE ::=3D { aa-asymmDecrytKeyID, ... } NEW: AttrSet ATTRIBUTE ::=3D { ... } Thanks, Russ From nobody Thu Jun 11 10:53: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 66D573A0CF3; Thu, 11 Jun 2020 10:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zQD86cfZfzOf; Thu, 11 Jun 2020 10:52:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC553A0CF8; Thu, 11 Jun 2020 10:52:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2CDAB3897F; Thu, 11 Jun 2020 13:50:26 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id awk_cRgipQb0; Thu, 11 Jun 2020 13:50:25 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9B6E73897E; Thu, 11 Jun 2020 13:50:25 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A4BA8486; Thu, 11 Jun 2020 13:52:55 -0400 (EDT) From: Michael Richardson To: Tomas Gustavsson cc: spasm@ietf.org, secdispatch@ietf.org In-Reply-To: References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] IDevID considerations document to secdispatch 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, 11 Jun 2020 17:53:00 -0000 --=-=-= Content-Type: text/plain Tomas Gustavsson wrote: > The notion of serialNumber in the document, for me, reads as it's not > clear what is the certificate serial number (9-19 bytes in your > document) and the device serial number. There don't have to be the > same. What I have seen commonly used is that the subjectDN field is > used to carry the device serial number, while the certificate serial > number is random, and only used to uniquely identify the certificate > in the PKI (issuer/serial). Your assumption is entirely correct. I wish that certificates hadn't used "serial Number" in it's terminology, as it's really "certificate Identifier", and we have learnt the hard way that it should not be sequential. > In such a case I would assume that the manufacturing execution system > (MES) and it's database controls the device serial number, while the > PKI controls the certificate serial number, and there does not have to > be any synchronization between these two. Agreed. Do I say something different here? I would love to clarify things. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7ib3cACgkQgItw+93Q 3WVhYwgAoxUZnvZ5zjFPTVnsGl/Id+hGHpuV35mBQ7p3ppbdQtgLRijmN7uD6MkO cVDMG9ZxRLTWWWvsj1XY73i9XmtTXwYNDH5nGBkBXrAOihDrtdkuK9TWc+UTlNao Vzm/747oSc2+ST7hcq50dolvaLdzyeXEjBbhsSKJKE6ayYXbncRxsX3fjzK/vm7d URm8uCLPb8isgaQbg9qkXJK4A24u11BFO7EoOSNVXfRQdkIcgMsAjFjzx0wRSZQC pnBcThD7+01DUZcuEckQG6WpTPmFxsvLXzKz73ft/NUeYh9WwXwUpOqFHXTKVQbb grumBJt28U9Ca2svVVNhplcFQZB81Q== =HLE3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 11 12:44: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 7C4983A0859 for ; Thu, 11 Jun 2020 12:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PXvMsJu8SjSe for ; Thu, 11 Jun 2020 12:44:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DF083A07C7 for ; Thu, 11 Jun 2020 12:44:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D5EDA38983; Thu, 11 Jun 2020 15:42:23 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wfkro-xwfS24; Thu, 11 Jun 2020 15:42:23 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5F46738982; Thu, 11 Jun 2020 15:42:23 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7A2F1486; Thu, 11 Jun 2020 15:44:53 -0400 (EDT) From: Michael Richardson To: Russ Housley cc: LAMPS In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Thu, 11 Jun 2020 15:44:53 -0400 Message-ID: <2136.1591904693@localhost> Archived-At: Subject: Re: [lamps] CSR attrs in rfc7030-clarify X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 19:44:58 -0000 Russ Housley wrote: > I have had an email exchange with someone that implemented EST, and > they have pointed out that the aa-asymmDecryptKeyID attribute is not > for inclusion in the CSR. However, when the server does the > public/private key pair generation, it is used to name the key to be > used top protect the server-generated key. Okay, fixed. > This leads to two changes in rfc7030-clarify: > In Section 4.1: > OLD: > AttrSet ATTRIBUTE ::= { aa-asymmDecryptKeyID, ... } > NEW: > AttrSet ATTRIBUTE ::= { ... } > In Appendix A: > OLD: > AttrSet ATTRIBUTE ::= { aa-asymmDecrytKeyID, ... } > NEW: > AttrSet ATTRIBUTE ::= { ... } > Thanks, > Russ From nobody Thu Jun 11 13:23: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 650EB3A0DCD for ; Thu, 11 Jun 2020 13:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 q_htFrhdc8Xn for ; Thu, 11 Jun 2020 13:23:27 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A98283A0DCA for ; Thu, 11 Jun 2020 13:23:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 78318300B23 for ; Thu, 11 Jun 2020 16:23:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3MFClZcuiXRv for ; Thu, 11 Jun 2020 16:23:23 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 4C665300A3B; Thu, 11 Jun 2020 16:23:23 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: <2136.1591904693@localhost> Date: Thu, 11 Jun 2020 16:23:24 -0400 Cc: LAMPS Content-Transfer-Encoding: 7bit Message-Id: References: <2136.1591904693@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [lamps] CSR attrs in rfc7030-clarify X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 20:23:29 -0000 Thank you very much > On Jun 11, 2020, at 3:44 PM, Michael Richardson wrote: > > Russ Housley wrote: >> I have had an email exchange with someone that implemented EST, and >> they have pointed out that the aa-asymmDecryptKeyID attribute is not >> for inclusion in the CSR. However, when the server does the >> public/private key pair generation, it is used to name the key to be >> used top protect the server-generated key. > > Okay, fixed. > >> This leads to two changes in rfc7030-clarify: > > >> In Section 4.1: > >> OLD: > >> AttrSet ATTRIBUTE ::= { aa-asymmDecryptKeyID, ... } > >> NEW: > >> AttrSet ATTRIBUTE ::= { ... } > > >> In Appendix A: > >> OLD: > >> AttrSet ATTRIBUTE ::= { aa-asymmDecrytKeyID, ... } > >> NEW: > >> AttrSet ATTRIBUTE ::= { ... } > > >> Thanks, >> Russ > From nobody Sun Jun 14 07:10: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 0DBB33A0828 for ; Sun, 14 Jun 2020 07:10:36 -0700 (PDT) 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=[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 wxCh0Ks5yRIE for ; Sun, 14 Jun 2020 07:10:34 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [78.46.205.88]) (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 231583A081F for ; Sun, 14 Jun 2020 07:10:33 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jkTLD-000FIJ-Dg; Sun, 14 Jun 2020 16:10:31 +0200 Date: Sun, 14 Jun 2020 16:10:30 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Daniel Kahn Gillmor cc: IETF LAMPS WG In-Reply-To: <87ftj3pczs.fsf@fifthhorseman.net> Message-ID: References: <87ftj3pczs.fsf@fifthhorseman.net> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-1676082590-1592137052=:57529" Content-ID: X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Archived-At: Subject: Re: [lamps] Common Protected Header practice documented (was "Memory Hole") 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, 14 Jun 2020 14:10:36 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1676082590-1592137052=:57529 Content-Type: text/plain; CHARSET=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: Hi Daniel Thanks for this great document! I was finally able to read and assess it. I believe it is quite useful to assist in finding a solution for our chartered work item on Header Protection. I have some questions related to the S/MIME examples: 1) The examples you provide for S/MIME have a simple structure, i.e. the body consist of a single MIME entity. How would an example look with the solution your are proposing, if it was a tree of MIME entities (e.g. text and html as multipart/alternative)? 2) In the examples (e.g. 9.2.) you are using "Content-Type: text/plain", however the content appears to be a full "message/rfc822" email. To me this looks like a mismatch between Media-Type and Content. To my understanding, whatever is in "Content-Type: text/plain" is unformated and is not guaranteed to be parsable. However your proposal suggests to parse this to replace the outer header fields. Have I misunderstood anything? Looking forward to your answer! cheers, Bernie -- http://ucom.ch/ Modern Telephony Solutions and Tech Consulting for Internet Technology On Mon, 4 Nov 2019, Daniel Kahn Gillmor wrote: > Hey LAMPS folks-- > > At (and shortly after) the OpenPGP e-mail summit [0], a group of MUA > developers went ahead and documented the way that several of us have > been handling header protection in a backward-compatible way. > > This bundle of techniques used to be known as "Memory Hole" a while back > but for a couple years now we've been calling it just "Protected > Headers", since "Memory Hole" was confusing and weird for some people. > > Hopefully this document can serve as input for appendix A.1.1 of > draft-ietf-lamps-header-protection-requirements-01 [1]. > > The new draft is at: > > https://datatracker.ietf.org/doc/draft-autocrypt-lamps-protected-headers/ > > (it's "draft-autocrypt-…" because it's not a single-person draft, and > because most of the experience we have in this comes from > implementations actively engaged in the Autocrypt project [2]. But it is > not a formal part of the Autocrypt specifications at this time, and it > is not intended to ever be limited to Autocrypt implementations.) > > To whet your appetite, the summary: > > ------- > The Protected Headers scheme relies on three backward-compatible > changes to a cryptographically-protected e-mail message: > > * Headers known to the composing MUA at message composition time are > (in addition to their typical placement as Exposed Headers on the > outside of the message) also present in the MIME header of the > root of the Cryptographic Payload. These Protected Headers share > cryptographic properties with the rest of the Cryptographic > Payload. > > * When the Cryptographic Envelope includes encryption, any Exposed > Header MAY be _obscured_ by a transformation (including deletion). > > * If the composing MUA intends to obscure any user-facing headers, > it MAY add a decorative "Legacy Display" MIME part to the > Cryptographic Payload which additionally duplicates the original > values of the obscured user-facing headers. > > When a composing MUA encrypts a message, it SHOULD obscure the > "Subject:" header, by using the literal string "..." (three U+002E > FULL STOP characters) as the value of the exposed "Subject:" header. > > When a receiving MUA encounters a message with a Cryptographic > Envelope, it treats the headers of the Cryptographic Payload as > belonging to the message itself, not just the subpart. In > particular, when rendering a header for any such message, the > renderer SHOULD prefer the header's Protected value over its Exposed > value. > > A receiving MUA that understands Protected Headers and discovers a > Legacy Display part SHOULD hide the Legacy Display part when > rendering the message. > ------- > > Please don't be put off by the draft length -- nearly half of the > document consists of test vectors that implementers can use to verify > their ability to consume well-formed, protected-header messages. > > I'd be happy to present this work in Singapore if there's space on the > agenda. > > Feedback, critiques, comments, etc, are all welcome. > > Regards, > > --dkg > > [0] https://wiki.gnupg.org/OpenPGPEmailSummit201910 > [1] https://tools.ietf.org/html/draft-ietf-lamps-header-protection-requirements-01#appendix-A.1.1 > [2] https://autocrypt.org/ > --8323329-1676082590-1592137052=:57529-- From nobody Sun Jun 14 11:07: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 0C3B43A0365 for ; Sun, 14 Jun 2020 11:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MZwnqM6pwmWU for ; Sun, 14 Jun 2020 11:07:41 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029DD3A02BE for ; Sun, 14 Jun 2020 11:07:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 704B5389FD; Sun, 14 Jun 2020 14:05:05 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rzRyjS-sZM0e; Sun, 14 Jun 2020 14:05:04 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 34CBB389FB; Sun, 14 Jun 2020 14:05:04 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C9B55608; Sun, 14 Jun 2020 14:07:36 -0400 (EDT) From: Michael Richardson To: Roman Danyliw , LAMPS WG CC: max pritikin In-Reply-To: <7cba97541fbd435b94192d23f966b363@cert.org> References: <7cba97541fbd435b94192d23f966b363@cert.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] AD review of draft-ietf-lamps-rfc7030est-clarify-05 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, 14 Jun 2020 18:07:45 -0000 --=-=-= Content-Type: text/plain WG and Max, I have changed the section 3 (in this document) edits for the RFC7030 section 4 edits to Replace/New. I could change the 4.5.2 change to be more explicit about what has changed. I found that section very difficult to read in rfc7030, so I prefer to have the changes applied in the update. Roman Danyliw wrote: > I conducted an AD review of draft-ietf-lamps-rfc7030est-clarify-05. > Thanks for the work on this document to address issues that had arisen > in RFC7030. Below is my feedback: Thank you. > (1) From idnits: > == The 'Updates: ' line in the draft header should list only the _numbers_ > of the RFCs which will be updated by this document (if approved); it > should not include the word 'RFC' in the list. Fixed. kramdown puts whatever I put in the header into the output. I had "RFC7030" > This is likely an artifact of the document build chain you are using, > but can you please recompile it to spit out the following s/Updates: > RFC7030/Updates: 7030/ > (2) From idnits: > == Unused Reference: 'RFC8179' is defined on line 377, but no explicit > reference was found in the text That's BCP14. I see it in the BCP14 paragraph. > == Unused Reference: 'X681' is defined on line 385, but no explicit > reference was found in the text > == Unused Reference: 'X682' is defined on line 389, but no explicit > reference was found in the text I believe that I got a request to please include them all. The reference is: This annex provides the normative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in [X680] through [X683]. I will write them all out. > (3) Section 1. Editorial. > "[RFC7030] defines the Enrollment over Secure Transport, or EST protocol. > This specification defines a number ..." > Because of the paragraph break, I initially read "This specification > defines a ..." to mean this document when you really mean RFC7030. Changed to: -{{RFC7030}} defines the Enrollment over Secure Transport, or EST protocol. - -This specification defines a number of HTTP end points for certificate enrollment and management. +Enrollment over Secure Transport (EST) is defined in {{RFC7030}}. +The EST specification defines a number of HTTP end points for certificate enrollment and management. > (4) Section 1. Per "Changes to [RFC7030] to bring it inline with > typical HTTP processing risk changes the on-wire protocol in a way > that is not backwards compatible. However, reports ..." > -- I had difficulty parsing this first sentence due to the use of > "changes" twice. > -- Calling something "typical HTTP processing" begs for a reference > describing that baseline behavior. > Maybe saying something like: > Any updates to [RFC7030] to bring it inline with HTTP processing per [RFC7231] risks changing the on-wire protocol in a way that is not backwards compatible. Done. > (5) Section 1. Editorial. There is no canonical set of implementers > (so the definite article shouldn't suggest that). s/However, reports > from the implementers .../However, reports from implementers/ done. > (6) Section 1. Typo. s/extranous/extraneous/ fixed. > (7) Section 1. Editorial. Per "This document deals with errata numbers > [errata4384], [errata5107], [errata5108], and [errata5904]", this is > helpful to point out that these errata are getting addressed. They are > even cited as normative references. However, by my read, the text only > every explains how [errata5108] is being addressed. The other three > are not mentioned in the text at all. Please make the text more > explicit on which changes are addressing which errata. I have listed in the introduction how each of the four errata are closed. > (8) Section 3, 4, and 5. I found it confusing that each section used a > different patch style. Is there a reason to do that? I see your point, but I think that we used the right style each time. > ** Section 3 summarizes the behavior of 4.1.3, 4.3.1, 4.3.2, 4.4.2 and > 4.5.2 without providing specific references to exact text, and then > provides a general updated behavior (again without providing exact text > updates) Yes. I don't think that patching the text of each of those would make it easier to read. We could cross-off the text of 4.1.3 if that would be easier. > ** Section 4. Provides an outright new blob of text to drop into a > section with high redundancy to the original The CSR Attribute text would have the base64 edit applied to it as well. I personally thought that we might have edited that text a bit more to clarify how CSRs are made. > ** Section 5. Uses an OLD vs. NEW convention. > Minimally, since the style of Section 4 and 5 are similar and are > precise, I'd recommend making Section 3 look like one of these style > (i.e., being clear on exactly what text is being updated/deprecated). okay, I'll change section 3. Please see next email/diff. > (a) Section 1. "However, reports from the implementers suggest that > many implementations do not send the Content-Transfer-Encoding, and > many of them ignore it. The consequence is that simply deprecating the > header would remain compatible with current implementations." - this > commentary suggests that dropping the header would cause no issues if > that approach is taken. That's what we have done. > (b) Section 3. "This document updates [RFC7030] to require the POST > request and payload response of all endpoints use Base64 encoding as > specified in Section 4 of [RFC4648]." - this updated guidance doesn't > explicitly rule out the use of the header Correct, current implementations do not set the header, and ignore it upon receipt. If there are lurking implementations that did not response that do include the header, then they will continue to operate. If someone ran into such an implementation that required the header, then it could work around by continuing to include it. > (c) Section 3. "This format is to be used regardless of any > Content-Transfer-Encoding header, and any value in such a header MUST > be ignored." - this doesn't say anything about sending the header, only > that it should be ignored on processing; this seems important for > backwards compatibility. Yes. Liberal in what you accept. Not, no need to send it. > Why drop the header from one section per (d) but not from the others > per (e)? Under what circumstances should a header be sent - > specifically, if (c) says the header should be dropped, why do we still > send it per (e)? I don't think we do, and maybe your request for explicit patches is waranteed. > (10) Section 3.1. Per "This specification clarifies that despite > [RFC2616], that white space including CR, LF, spaces (ASCII 32) and, > tabs (ASCII 9) should be tolerated by receivers", is there a reason > that there isn't a normative SHOULD here? Agreed. SHOULD now. > (11) Section 4. > "Section 4.5.2 of [RFC7030] is to be replaced with the following text: > 4.1. CSR Attributes Response" > ** Editorial. I suspect there is a tool chain rendering issue. The > section header to drop into RFC7030 needs to read "4.5.2 CSR Attributes > Response" (not 4.1 which is the next section of this document). > Editorial alternative would be to drop the header entirely or following > convention used in Sections 5.1 and 5.2. Yeah, I'll render it without the markup. > ** Editorial. It might also be valuable to explain what is getting > changed instead of just providing an updated blob. I'll defer to the WG here. > (12) Section 4. Editorial. For consistency with RFC7090, consider s/[X609]/[X.609]/. Okay. > (13) Section 5. The updates here drop the normative MUST to a "must" > regarding the "response data must ...". The Errata text explains that > "Note that the MUST was reduced to a must because no content-type is > specified" but I'm still not following why we lost the normative MUST. > What am I missing? Editorial mistake -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7mZ2gACgkQgItw+93Q 3WXvoggAjjLpR7gzBjJ/650RnRIJTGz7D9c7ZNDFEuktVMjAKLmcmfk4XKvg1BQI gST8tTiIxxG+RIJIol1sV9xJe24BgR5pEaQFIchl5Y89vQfTE81uBJlrSpfWJyxn n18MZOSbKEKCI1fb7Uv80RTPstEknTBNm/4rQtYJJwOYgm/lDTXPGHRiYRwzhzYS iTbyEGL9aud7BWHOfl/3QUhPAEj79TnX81DR5/ceOczg/oVFSMlRECkjaualXgCq Xejo86znLSvBtvN4LaHMM5xrjYhQM4guLH07JYKYsDVv5arthA8Dp4gqbfAUZTU7 R/MASNu7ocm2SCibE+heyh18BsHgVQ== =UhLR -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 14 11:10:08 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 CCB903A03EA; Sun, 14 Jun 2020 11:10:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <159215820677.10150.10298345187666430066@ietfa.amsl.com> Date: Sun, 14 Jun 2020 11:10:06 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc7030est-clarify-06.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: Sun, 14 Jun 2020 18:10:07 -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 : Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1 Authors : Michael Richardson Thomas Werner Wei Pan Filename : draft-ietf-lamps-rfc7030est-clarify-06.txt Pages : 14 Date : 2020-06-14 Abstract: This document updates RFC7030: Enrollment over Secure Transport (EST) to resolve some errata that was reported, and which has proven to cause interoperability issues when RFC7030 was extended. This document deprecates the specification of "Content-Transfer- Encoding" headers for EST endpoints. This document fixes some syntactical errors in ASN.1 that was presented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7030est-clarify/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc7030est-clarify-06 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc7030est-clarify-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc7030est-clarify-06 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 Sun Jun 14 11:12:40 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 AA8D13A03EA for ; Sun, 14 Jun 2020 11:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 y7eNtn4cEdq4 for ; Sun, 14 Jun 2020 11:12:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 260E63A03ED for ; Sun, 14 Jun 2020 11:12:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 12CBE389FF; Sun, 14 Jun 2020 14:10:03 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id I5yEWmDbXzQt; Sun, 14 Jun 2020 14:09:59 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 538F0389FE; Sun, 14 Jun 2020 14:09:59 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E9638608; Sun, 14 Jun 2020 14:12:31 -0400 (EDT) From: Michael Richardson to: Roman Danyliw , LAMPS WG CC: max pritikin In-Reply-To: <30816.1592158056@localhost> References: <7cba97541fbd435b94192d23f966b363@cert.org> <30816.1592158056@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] AD review of draft-ietf-lamps-rfc7030est-clarify-05 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, 14 Jun 2020 18:12:39 -0000 --=-=-= Content-Type: text/plain Michael Richardson wrote: > okay, I'll change section 3. Please see next email/diff. A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc7030est-clarify-06 I won't paste the diffs in here, since I think they look better there. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7maI8ACgkQgItw+93Q 3WUQqQgAvHo9OxoN3SDHY+71z40dydjnahoAmy2DWiIlFobK2ff9n5ZBcUdbhmAE 4UZO2+AUyVsnSq2is2nPjBqdv/cWbGiKAKmt5VzMk0yubEGr62+sHD4+CIzTeI2R DVCUCsiNhSzhRtASmjr6200MiRSHXc9S513OWk0CvPRZm812S/rV94qzPS3a9fO5 twv2xIt+jiBpPqwUi3ucq3yYrFmf4g7tKwgGRNTPFczsZFRiZMXp4GbrFhOJruZm A2LLZCqif51azSdawM6cuTsydkPc3sDrG1ATbnK6RQmdeneJ9UkrVPceHOuO1Ti2 TMnRfAlULGP9AiLjlbVAb+Wyzj2bNA== =CUzP -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 14 22:49: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 B89713A09D5 for ; Sun, 14 Jun 2020 22:49:05 -0700 (PDT) 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=primekey.com header.b=f1kVWx6K; dkim=pass (1024-bit key) header.d=primekey.com header.b=f1kVWx6K 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 O-SFxlkAch8J for ; Sun, 14 Jun 2020 22:49:03 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FCA33A09D4 for ; Sun, 14 Jun 2020 22:49:02 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id D44F86AA0084 for ; Mon, 15 Jun 2020 07:48:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1592200123; bh=G9QSfgDZoTKPzB4JurjIzq8mg56loNFR25Xszma796A=; h=Subject:To:References:From:Date:In-Reply-To:From; b=f1kVWx6KHJntvhaKEwn3mlyEZPmDeYX0yyRU4YTSXitcSGjCgY2nhJTL4N949hKTP SVKekKzOTQlZr4lG2gCZMrxewxmArq2+gUS5r1zXI2JKMYT6hJP9BjypnM3gGWCL9N CNisbtWGyVcEdr8y1Zhzyy/Cnvkag3aBJDyT4LBg= Received: from [10.11.0.4] (gatekeeper.primekey.se [84.55.121.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id B3CA26AA006F for ; Mon, 15 Jun 2020 07:48:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1592200123; bh=G9QSfgDZoTKPzB4JurjIzq8mg56loNFR25Xszma796A=; h=Subject:To:References:From:Date:In-Reply-To:From; b=f1kVWx6KHJntvhaKEwn3mlyEZPmDeYX0yyRU4YTSXitcSGjCgY2nhJTL4N949hKTP SVKekKzOTQlZr4lG2gCZMrxewxmArq2+gUS5r1zXI2JKMYT6hJP9BjypnM3gGWCL9N CNisbtWGyVcEdr8y1Zhzyy/Cnvkag3aBJDyT4LBg= To: spasm@ietf.org References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> 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: <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> Date: Mon, 15 Jun 2020 07:48:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <5843.1591897975@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] IDevID considerations document to secdispatch 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, 15 Jun 2020 05:49:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2020-06-11 19:52, Michael Richardson wrote: > > Tomas Gustavsson wrote: >> The notion of serialNumber in the document, for me, reads as it's >> not clear what is the certificate serial number (9-19 bytes in >> your document) and the device serial number. There don't have to >> be the same. What I have seen commonly used is that the subjectDN >> field is used to carry the device serial number, while the >> certificate serial number is random, and only used to uniquely >> identify the certificate in the PKI (issuer/serial). > > Your assumption is entirely correct. I wish that certificates > hadn't used "serial Number" in it's terminology, as it's really > "certificate Identifier", and we have learnt the hard way that it > should not be sequential. > >> In such a case I would assume that the manufacturing execution >> system (MES) and it's database controls the device serial number, >> while the PKI controls the certificate serial number, and there >> does not have to be any synchronization between these two. > > Agreed. Do I say something different here? I would love to clarify > things. This section confused me at first read: - ----- In all cases the serialNumber embedded in the certificate must be unique across all products produced by the manufacturer. This suggests some amount of structure to the serialNumber, such that different intermediate CAs do not need to coordinate when issuing certificates - ----- At first read I thought about certificate serial number, but now realize it's the device serial number that is meant. I think that section can be clarified somewhat. Some additional nitpicking... I think this section is missing an 's'? - ----- The intermediate CA will have a private key, likely kept online, which is used to sign each generated IDevID. Once the IDevID are created, the private key is no longer needed and can either be destroyed, or taken offline. - ----- In the line preceding this section it talks about "some number of IDevIDs". Then that the CAs private key can be destroyed after generating that number if IDevIDs. Hence, just ad an s: "Once the IDevID are created, the private key is no longer needed and can either be destroyed, or taken offline." - -> "Once the IDevIDs are created, the private key is no longer needed and can either be destroyed, or taken offline." Regards, Tomas -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEWhJUWO1gQBfiUtymYm3EmwBD/kAFAl7nC8gACgkQYm3EmwBD /kCVAQgAw1vi8QdbAapwi60XQsStaRK1Ap8sNtkfMpyq7J4E45VREVLoazhKnqlX w5JxuM5ViHPgekNBnIk1qj3hN5XjPEFxZGtoy8Dx1iJh6w0pu8jbK5p/LKBWX71U H0f1FXQ6e2NGmfSviWR4G76ikapI4bfq05SlIrWP29+b/GPaqUZPyX5g0Uf/UANu 4cWAhnOH6DlSEcHolMJzc7Zi61bjIkY1XXd25AZFiu1/uer0zhxZV/kwuj69ELTd OTKOrprmOHVtcOC3PapIK0or4c6EusJSBdY3mpo4OibjKKiJsEhQUFqAnj+osg3Q P7rH5eYNul83MAb0jlAZk88oc3Z2HA== =NCZB -----END PGP SIGNATURE----- From nobody Tue Jun 16 10:21:50 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 DF5113A0788; Tue, 16 Jun 2020 10:21:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <159232810486.23178.15730724559866018531@ietfa.amsl.com> Date: Tue, 16 Jun 2020 10:21:44 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc7030est-clarify-07.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 17:21:45 -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 : Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1 Authors : Michael Richardson Thomas Werner Wei Pan Filename : draft-ietf-lamps-rfc7030est-clarify-07.txt Pages : 14 Date : 2020-06-16 Abstract: This document updates RFC7030: Enrollment over Secure Transport (EST) to resolve some errata that was reported, and which has proven to cause interoperability issues when RFC7030 was extended. This document deprecates the specification of "Content-Transfer- Encoding" headers for EST endpoints. This document fixes some syntactical errors in ASN.1 that was presented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7030est-clarify/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc7030est-clarify-07 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc7030est-clarify-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc7030est-clarify-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 16 10:25: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 58D2D3A079D for ; Tue, 16 Jun 2020 10:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YPQHWYMdxCE5 for ; Tue, 16 Jun 2020 10:25:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 214403A0793 for ; Tue, 16 Jun 2020 10:25:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8597B38A42; Tue, 16 Jun 2020 13:23:15 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RFUbA9ViTRFO; Tue, 16 Jun 2020 13:23:13 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8DCC438A3F; Tue, 16 Jun 2020 13:23:13 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D5F03616; Tue, 16 Jun 2020 13:25:47 -0400 (EDT) From: Michael Richardson To: spasm@ietf.org, Roman Danyliw In-Reply-To: <159232810486.23178.15730724559866018531@ietfa.amsl.com> References: <159232810486.23178.15730724559866018531@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-rfc7030est-clarify-07.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, 16 Jun 2020 17:25:54 -0000 --=-=-= Content-Type: text/plain internet-drafts@ietf.org wrote: > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc7030est-clarify-07 The 05->06 diff was still on my screen a day later, and I realized that I could make the changed text more obvious, while still retaining the context that I thought was useful. I hope others agree that this is an improvement. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7pAJsACgkQgItw+93Q 3WWcGwf/Yr6D+dmV6AvQEoAIfxTtZjlwbtKTAlCeKK6cMoiJ+G/EdG669qbKvyUo Av9TEUxLu6Z9B8zDPuD4gPTcTOm25QdqDnaeOOCRaNZH2QzqNUPMosyqytFf+U4B gGzMjg3fZiT2D3PYPoY+qcjHxn86bnm46gvWODlCdl/a2UaNxU45t70BNUQgXoNk 80WW4Iuh1f4YDeqOKExRH7RdsNp2mojkV5vfszKGtTjvq4yQJobqpIPbKDptzWLT MnQZg31X3949S+SFbuh+iRraDBF9jFVWYAR3ey8VIJ8ZDqLrp1JQ9iuPUqRQVKFf WYZuzrtAUJtLvHI1qRR5Y5KpLQisaQ== =C+qZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 25 10:47: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 246153A0E06 for ; Thu, 25 Jun 2020 10:47:00 -0700 (PDT) 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=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRUN0S7uL13q for ; Thu, 25 Jun 2020 10:46:57 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE26D3A0E0A for ; Thu, 25 Jun 2020 10:46:54 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 05PHkq8u020464; Thu, 25 Jun 2020 13:46:52 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 05PHkq8u020464 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1593107212; bh=UT/GGLt6bZlMcVu+PLVqtSe6vJLop1wFnBT6RaCt93o=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=L3alf7m4PmQD5pjzNai8fw/frJPf+KEobNXRHu7ESpYGVDAxxTTYT65/xPILH4BB9 WyKm7ULZrFG3Hk/CBXVK6hJ8XQfaFxmC4pI5j0e7DWAZ4M9bbSjmge6bEBGxpClMls 9J9WVrusPzAiNWTnQoE/zfMeIxNCAU1JH0eCB1IA= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 05PHkmRd031323; Thu, 25 Jun 2020 13:46:48 -0400 Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASSINA.ad.sei.cmu.edu (10.64.28.249) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 25 Jun 2020 13:46:48 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Thu, 25 Jun 2020 13:46:47 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Thu, 25 Jun 2020 13:46:47 -0400 From: Roman Danyliw To: Michael Richardson , LAMPS WG CC: max pritikin Thread-Topic: [lamps] AD review of draft-ietf-lamps-rfc7030est-clarify-05 Thread-Index: AdYzkAx0m2ssZAMLTjWn2jugw7dc+APCClkAAh493hA= Date: Thu, 25 Jun 2020 17:46:46 +0000 Message-ID: References: <7cba97541fbd435b94192d23f966b363@cert.org> <30816.1592158056@localhost> In-Reply-To: <30816.1592158056@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.201.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] AD review of draft-ietf-lamps-rfc7030est-clarify-05 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, 25 Jun 2020 17:47:00 -0000 Hi Michael! Thanks for making all of these edits. More commentary is inline, but the b= ottom line is it looks ready for IETF LC. > -----Original Message----- > From: Spasm On Behalf Of Michael Richardson > Sent: Sunday, June 14, 2020 2:08 PM > To: Roman Danyliw ; LAMPS WG > Cc: max pritikin > Subject: Re: [lamps] AD review of draft-ietf-lamps-rfc7030est-clarify-05 >=20 >=20 > WG and Max, I have changed the section 3 (in this document) edits for the > RFC7030 section 4 edits to Replace/New. >=20 > I could change the 4.5.2 change to be more explicit about what has change= d. > I found that section very difficult to read in rfc7030, so I prefer to ha= ve the > changes applied in the update. >=20 > Roman Danyliw wrote: > > I conducted an AD review of draft-ietf-lamps-rfc7030est-clarify-05. > > Thanks for the work on this document to address issues that had ari= sen > > in RFC7030. Below is my feedback: >=20 > Thank you. >=20 > > (1) From idnits: > > =3D=3D The 'Updates: ' line in the draft header should list only th= e _numbers_ > > of the RFCs which will be updated by this document (if approved); i= t > > should not include the word 'RFC' in the list. >=20 > Fixed. kramdown puts whatever I put in the header into the output. > I had "RFC7030" >=20 > > This is likely an artifact of the document build chain you are usin= g, > > but can you please recompile it to spit out the following s/Updates= : > > RFC7030/Updates: 7030/ >=20 >=20 > > (2) From idnits: > > =3D=3D Unused Reference: 'RFC8179' is defined on line 377, but no e= xplicit > > reference was found in the text >=20 > That's BCP14. I see it in the BCP14 paragraph. >=20 > > =3D=3D Unused Reference: 'X681' is defined on line 385, but no expl= icit > > reference was found in the text >=20 > > =3D=3D Unused Reference: 'X682' is defined on line 389, but no expl= icit > > reference was found in the text >=20 > I believe that I got a request to please include them all. > The reference is: > This annex provides the normative ASN.1 definitions for the > structures described in this specification using ASN.1 as defined in > [X680] through [X683]. >=20 > I will write them all out. > > > (3) Section 1. Editorial. > > "[RFC7030] defines the Enrollment over Secure Transport, or EST pro= tocol. > > This specification defines a number ..." >=20 > > Because of the paragraph break, I initially read "This specificatio= n > > defines a ..." to mean this document when you really mean RFC7030. >=20 > Changed to: >=20 > -{{RFC7030}} defines the Enrollment over Secure Transport, or EST protoco= l. > - > -This specification defines a number of HTTP end points for certificate > enrollment and management. > +Enrollment over Secure Transport (EST) is defined in {{RFC7030}}. > +The EST specification defines a number of HTTP end points for certificat= e > enrollment and management. > > > (4) Section 1. Per "Changes to [RFC7030] to bring it inline with > > typical HTTP processing risk changes the on-wire protocol in a way > > that is not backwards compatible. However, reports ..." >=20 > > -- I had difficulty parsing this first sentence due to the use of > > "changes" twice. >=20 > > -- Calling something "typical HTTP processing" begs for a reference > > describing that baseline behavior. >=20 > > Maybe saying something like: >=20 > > Any updates to [RFC7030] to bring it inline with HTTP processing pe= r > [RFC7231] risks changing the on-wire protocol in a way that is not backwa= rds > compatible. >=20 > Done. > > > (5) Section 1. Editorial. There is no canonical set of implemente= rs > > (so the definite article shouldn't suggest that). s/However, repor= ts > > from the implementers .../However, reports from implementers/ >=20 > done. >=20 > > (6) Section 1. Typo. s/extranous/extraneous/ >=20 > fixed. Thanks for all of the edits noted above. > > (7) Section 1. Editorial. Per "This document deals with errata num= bers > > [errata4384], [errata5107], [errata5108], and [errata5904]", this i= s > > helpful to point out that these errata are getting addressed. They= are > > even cited as normative references. However, by my read, the text = only > > every explains how [errata5108] is being addressed. The other thre= e > > are not mentioned in the text at all. Please make the text more > > explicit on which changes are addressing which errata. >=20 > I have listed in the introduction how each of the four errata are closed. >=20 > > (8) Section 3, 4, and 5. I found it confusing that each section us= ed a > > different patch style. Is there a reason to do that? >=20 > I see your point, but I think that we used the right style each time. > > > ** Section 3 summarizes the behavior of 4.1.3, 4.3.1, 4.3.2, 4.4.2 = and > > 4.5.2 without providing specific references to exact text, and then > > provides a general updated behavior (again without providing exact = text > > updates) >=20 > Yes. I don't think that patching the text of each of those would make > it easier to read. We could cross-off the text of 4.1.3 if that would b= e > easier. >=20 > > ** Section 4. Provides an outright new blob of text to drop into a > > section with high redundancy to the original >=20 > The CSR Attribute text would have the base64 edit applied to it as well. > I personally thought that we might have edited that text a bit more to cl= arify > how CSRs are made. >=20 > > ** Section 5. Uses an OLD vs. NEW convention. >=20 > > Minimally, since the style of Section 4 and 5 are similar and are > > precise, I'd recommend making Section 3 look like one of these styl= e > > (i.e., being clear on exactly what text is being updated/deprecated= ). >=20 > okay, I'll change section 3. Please see next email/diff. The new Section 3.2 is much clearer. Thanks for putting it in. Consider all of my other comments about patch style as resolved. The nesti= ng of the changes per the addressed issue works for me. > > (a) Section 1. "However, reports from the implementers suggest tha= t > > many implementations do not send the Content-Transfer-Encoding, and > > many of them ignore it. The consequence is that simply deprecating= the > > header would remain compatible with current implementations." - thi= s > > commentary suggests that dropping the header would cause no issues = if > > that approach is taken. >=20 > That's what we have done. >=20 > > (b) Section 3. "This document updates [RFC7030] to require the POS= T > > request and payload response of all endpoints use Base64 encoding a= s > > specified in Section 4 of [RFC4648]." - this updated guidance doesn= 't > > explicitly rule out the use of the header >=20 > Correct, current implementations do not set the header, and ignore it upo= n > receipt. If there are lurking implementations that did not response that= do > include the header, then they will continue to operate. If someone ran i= nto > such an implementation that required the header, then it could work aroun= d by > continuing to include it. >=20 > > (c) Section 3. "This format is to be used regardless of any > > Content-Transfer-Encoding header, and any value in such a header MU= ST > > be ignored." - this doesn't say anything about sending the header, = only > > that it should be ignored on processing; this seems important for > > backwards compatibility. >=20 > Yes. Liberal in what you accept. > Not, no need to send it. >=20 > > Why drop the header from one section per (d) but not from the other= s > > per (e)? Under what circumstances should a header be sent - > > specifically, if (c) says the header should be dropped, why do we s= till > > send it per (e)? >=20 > I don't think we do, and maybe your request for explicit patches is waran= teed. Fixed as noted above. > > (10) Section 3.1. Per "This specification clarifies that despite > > [RFC2616], that white space including CR, LF, spaces (ASCII 32) and= , > > tabs (ASCII 9) should be tolerated by receivers", is there a reason > > that there isn't a normative SHOULD here? >=20 > Agreed. SHOULD now. Thanks. > > (11) Section 4. > > "Section 4.5.2 of [RFC7030] is to be replaced with the following te= xt: > > 4.1. CSR Attributes Response" >=20 > > ** Editorial. I suspect there is a tool chain rendering issue. The > > section header to drop into RFC7030 needs to read "4.5.2 CSR Attrib= utes > > Response" (not 4.1 which is the next section of this document). > > Editorial alternative would be to drop the header entirely or follo= wing > > convention used in Sections 5.1 and 5.2. >=20 > Yeah, I'll render it without the markup. Thanks. > > ** Editorial. It might also be valuable to explain what is getting > > changed instead of just providing an updated blob. >=20 > I'll defer to the WG here. >=20 > > (12) Section 4. Editorial. For consistency with RFC7090, consider > s/[X609]/[X.609]/. >=20 > Okay. Thanks. > > (13) Section 5. The updates here drop the normative MUST to a "mus= t" > > regarding the "response data must ...". The Errata text explains t= hat > > "Note that the MUST was reduced to a must because no content-type i= s > > specified" but I'm still not following why we lost the normative MU= ST. > > What am I missing? >=20 > Editorial mistake Thanks. Regards, Roman > -- > Michael Richardson , Sandelman Software Works -= =3D > IPv6 IoT consulting =3D- From nobody Thu Jun 25 10:50:45 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 B0D2D3A0E36; Thu, 25 Jun 2020 10:50:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk CC: Russ Housley , housley@vigilsec.com, draft-ietf-lamps-rfc7030est-clarify@ietf.org, rdd@cert.org, lamps-chairs@ietf.org, spasm@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <159310743069.25320.1522043820400981987@ietfa.amsl.com> Date: Thu, 25 Jun 2020 10:50:30 -0700 Archived-At: Subject: [lamps] Last Call: (Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1) to Proposed Standard 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, 25 Jun 2020 17:50:43 -0000 The IESG has received a request from the Limited Additional Mechanisms for PKIX and SMIME WG (lamps) to consider the following document: - 'Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-07-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates RFC7030: Enrollment over Secure Transport (EST) to resolve some errata that was reported, and which has proven to cause interoperability issues when RFC7030 was extended. This document deprecates the specification of "Content-Transfer- Encoding" headers for EST endpoints. This document fixes some syntactical errors in ASN.1 that was presented. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7030est-clarify/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5212: Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) (Informational - IETF stream) From nobody Fri Jun 26 14:56: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 00B303A0CDB; Fri, 26 Jun 2020 14:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vDesNArbJ1Mb; Fri, 26 Jun 2020 14:56:45 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 248D33A0CBE; Fri, 26 Jun 2020 14:56:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 21B5C389A1; Fri, 26 Jun 2020 17:54:00 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mJYdoEzqxphY; Fri, 26 Jun 2020 17:53:58 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id BDC0C389A0; Fri, 26 Jun 2020 17:53:58 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2A838F5; Fri, 26 Jun 2020 17:56:42 -0400 (EDT) From: Michael Richardson To: spasm@ietf.org, Russ Housley , anima@ietf.org, Ben Kaduk CC: Nico Williams , Ryan Sleevi In-Reply-To: References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [lamps] on certification authorities. 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, 26 Jun 2020 21:56:47 -0000 --=-=-= Content-Type: text/plain Russ Housley wrote: > Thank you. Many people get it wrong, but X.509 and RFC 5280 (as well > as the earlier versions in RFC 2459 and RFC 3280) all use > {CA=} "certification authority". I guess it might be worth spreading this point more widely :-) I'll all for stamping out the wrong expansions, even if it sometimes seems pendantic. I'm told that Google is about to start their Cloud *Certificate* Authority. If that happens, I believe that any chance to assert the term will be completely lost :-) On the other hand, if they go with "certification authority", then perhaps the tide of the terminology will be reversed. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl72bxkACgkQgItw+93Q 3WWVnQf+PbQH5kxqc+k5oGlEk0ziTLghz1BAboDztzOfyjEwsOZTbpORX1P7oZLU UWufR9LUfFVBTgOyP5ZYwJdhFEifdRwZJny/yFQvQEVDRSoRgFq41PNi3yzxp9ea wDuR2p1aCHdb888HrM9HZsR0sTRhwflbGxWCn0+hSoks6mpmkw+/+EvR1v3UENKt x942eJ9kidSzmmm9CXFTFROniYSgpVzGY99MCsKpmBuP5kgX7p7sVzWUprEyive9 WBJujsSFiZBG+rtgEyXu9aMglMJUa8sLD2gEbD0bzgOydRxJ8KYl1G1v07B9Wumm gGs1YNSJEVSp+UxMNMt0MbdfAVbQ1Q== =sEPI -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 26 15:04: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 587F23A0CE5; Fri, 26 Jun 2020 15:04:52 -0700 (PDT) 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, 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=cryptonector.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 GraGu44BaHuv; Fri, 26 Jun 2020 15:04:51 -0700 (PDT) Received: from bird.elm.relay.mailchannels.net (bird.elm.relay.mailchannels.net [23.83.212.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FCB73A0CE4; Fri, 26 Jun 2020 15:04:49 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 2C0391E0EA3; Fri, 26 Jun 2020 22:04:49 +0000 (UTC) Received: from pdx1-sub0-mail-a15.g.dreamhost.com (100-96-23-8.trex.outbound.svc.cluster.local [100.96.23.8]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 67A3A1E1255; Fri, 26 Jun 2020 22:04:48 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a15.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Fri, 26 Jun 2020 22:04:49 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Absorbed-Bubble: 2d677f5e17533c28_1593209088910_198106182 X-MC-Loop-Signature: 1593209088910:1891334799 X-MC-Ingress-Time: 1593209088910 Received: from pdx1-sub0-mail-a15.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a15.g.dreamhost.com (Postfix) with ESMTP id 2A1C27F081; Fri, 26 Jun 2020 15:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Yq23/ANPjKPXZC 12YmFWhdLtWJo=; b=g97my4gRGyzFmCc8NonREQb12uq6BfrLlbd6CiUk1lCQhC CvykyiXKDAyNBaKbs/JC4YV+thz4y08qI0fd2v30gRdH4oU0PY6d58VylWvt/hWZ pUd2EOZYDbKaq74wQbRaEtrUiYSrMTBnNAzx8/D96nI3IVHwK+sdwV/q6XB0I= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 064797F07F; Fri, 26 Jun 2020 15:04:45 -0700 (PDT) Date: Fri, 26 Jun 2020 17:04:42 -0500 X-DH-BACKEND: pdx1-sub0-mail-a15 From: Nico Williams To: Michael Richardson Cc: spasm@ietf.org, Russ Housley , anima@ietf.org, Ben Kaduk , Ryan Sleevi Message-ID: <20200626220441.GW3100@localhost> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13005.1593208602@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudelvddgtdeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [lamps] on certification authorities. 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, 26 Jun 2020 22:04:52 -0000 On Fri, Jun 26, 2020 at 05:56:42PM -0400, Michael Richardson wrote: > Russ Housley wrote: > > Thank you. Many people get it wrong, but X.509 and RFC 5280 (as well > > as the earlier versions in RFC 2459 and RFC 3280) all use > > {CA=} "certification authority". > > I guess it might be worth spreading this point more widely :-) > I'll all for stamping out the wrong expansions, even if it sometimes > seems pendantic. > > I'm told that Google is about to start their Cloud *Certificate* > Authority. If that happens, I believe that any chance to assert the > term will be completely lost :-) Then clearly they have not read the specs and have no idea what they're doing!!1! :^) Just like with IpSec. Nico -- From nobody Sat Jun 27 00:57: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 4E4B03A0542; Sat, 27 Jun 2020 00:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.695 X-Spam-Level: X-Spam-Status: No, score=-1.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=x500.eu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ls1SC2zxKAbO; Sat, 27 Jun 2020 00:57:29 -0700 (PDT) Received: from outscan1.mf.dandomain.dk (outscan1.mf.dandomain.dk [212.237.249.58]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1C63A043D; Sat, 27 Jun 2020 00:57:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by outscan1.mf.dandomain.dk (Postfix) with ESMTP id 026754069108; Sat, 27 Jun 2020 09:57:27 +0200 (CEST) Received: from outscan1.mf.dandomain.dk ([127.0.0.1]) by localhost (outscan1.mf.dandomain.dk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biJ1pJk1QMuv; Sat, 27 Jun 2020 09:57:26 +0200 (CEST) Received: from mail-proxy.dandomain.dk (dilvs03.dandomain.net [194.150.112.64]) by outscan1.mf.dandomain.dk (Postfix) with ESMTPA id 204594069100; Sat, 27 Jun 2020 09:57:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=x500.eu; s=dandomain; t=1593244646; bh=St7PSINpTDoO7XbXbeu19G7mALHtr+KVerIBvmZTLbA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:From; b=LI4bDBk2VvF7ALm74PQliD9+6gwwjwZqlhHTxNfw78HitSuJU18mwglOuzOG2EFyZ Sf3Bhherfy3a4kkW1VksUhpsg0Pe7CwoHcUde/zk6s0FA0wY4J0YlPIVUfc4ePfguf XQkjTfanwDwHPCscQqrv4O/wK/BJ4lJ+v3hPs7NdvyjYRuWzwqr6tw0gCyx6j6dwb4 KFx6aiuKXVhZNteOQaT6DCwm0sg4XsgZHyun4cKo1glSjPlZNNyLmAde7Vr01g1jlE z5saF8s4bEXYAqeSFvvCYLOFIShPypFQqI1zc6MwHWUb8aqI5XYkJuBkvkXwaMqx2J XuYpT8GYvr0fw== From: "Erik Andersen" To: "'Michael Richardson'" , , "'Russ Housley'" , , "'Ben Kaduk'" Cc: "'Ryan Sleevi'" , "'Nico Williams'" References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> In-Reply-To: <13005.1593208602@localhost> Date: Sat, 27 Jun 2020 09:57:16 +0200 Message-ID: <001001d64c58$98890d40$c99b27c0$@x500.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEwj93EDQf+67rRWWSqilgJXpnKwAJ6Ny4/AP3sFROqG81lYA== Content-Language: en-gb Archived-At: Subject: Re: [lamps] on certification authorities. 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, 27 Jun 2020 07:57:32 -0000 There certainly is a big difference between the term certification (an act) and the term certificate (a data value). Certification implies that the CA does some validation before issuing a certificate. When a read an article and hit the term certificate authority, I stop reading thinking the guy cannot even get the term right. He/She does not know what a CA is. Erik -----Original Message----- From: Spasm On Behalf Of Michael Richardson Sent: 26 June 2020 23:57 To: spasm@ietf.org; Russ Housley ; anima@ietf.org; Ben Kaduk Cc: Ryan Sleevi ; Nico Williams Subject: [lamps] on certification authorities. Russ Housley wrote: > Thank you. Many people get it wrong, but X.509 and RFC 5280 (as well > as the earlier versions in RFC 2459 and RFC 3280) all use > {CA=} "certification authority". I guess it might be worth spreading this point more widely :-) I'll all for stamping out the wrong expansions, even if it sometimes seems pendantic. I'm told that Google is about to start their Cloud *Certificate* Authority. If that happens, I believe that any chance to assert the term will be completely lost :-) On the other hand, if they go with "certification authority", then perhaps the tide of the terminology will be reversed. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- From nobody Sun Jun 28 00:41:15 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 CF52C3A082D for ; Sun, 28 Jun 2020 00:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.695 X-Spam-Level: X-Spam-Status: No, score=-1.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=x500.eu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OL2f4X-DpzFO for ; Sun, 28 Jun 2020 00:41:10 -0700 (PDT) Received: from outscan1.mf.dandomain.dk (outscan1.mf.dandomain.dk [212.237.249.58]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC0B3A07A8 for ; Sun, 28 Jun 2020 00:41:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by outscan1.mf.dandomain.dk (Postfix) with ESMTP id 1C47A406913E; Sun, 28 Jun 2020 09:41:08 +0200 (CEST) Received: from outscan1.mf.dandomain.dk ([127.0.0.1]) by localhost (outscan1.mf.dandomain.dk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kh9uzismibAk; Sun, 28 Jun 2020 09:41:06 +0200 (CEST) Received: from mail-proxy.dandomain.dk (dilvs03.dandomain.net [194.150.112.64]) by outscan1.mf.dandomain.dk (Postfix) with ESMTPA id 8A34C4069103; Sun, 28 Jun 2020 09:41:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=x500.eu; s=dandomain; t=1593330066; bh=r8pYh8RWzxJf3UA8iQ1P9wWKJ740p9+pfoIo21y1AAc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:From; b=mTreouaMPe7tCtGqjN2tv45Tkv7v4sFKwvVTeP+UiqviF1oF0sWe763sMwGzjzY9T uV+JaRZxtQpo5QQ4ZYCwyCbTWjWK/Jd+fgdfh/+PggFFwdVTH7qSgexHZxM9IORG7E odDBpqpxG3NknNVp+fQ2FrYtgutzVEjF8BNExTQ9lB4/6GMIN2elRpUN4O9Hmz+t3i aeJeeSQZxJQRzw0ClOShu1XKXWwY0cVxoL+soOj9L01DdynTzcsEkyIlS0kecGXs+u QzID/jBa+PDhmJBiDkPI1wyDmWxh8vW4xzooVjhqGl5xIQgfmdQlC/t52fpTh1E/wq g1iyWsmfIeM3A== From: "Erik Andersen" To: "'Carsten Bormann'" Cc: "LAMPS" References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> In-Reply-To: <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> Date: Sun, 28 Jun 2020 09:41:01 +0200 Message-ID: <000701d64d1f$7a7cea20$6f76be60$@x500.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEwj93EDQf+67rRWWSqilgJXpnKwAJ6Ny4/AP3sFRMB+BZSggHDnm7Qqf9+zQA= Content-Language: en-gb Archived-At: Subject: Re: [lamps] [Anima] on certification authorities. 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, 28 Jun 2020 07:41:13 -0000 32 years ago X.509 (1988) defined certification authority. There has = been plenty of time to get acquainted with the term. Erik -----Original Message----- From: Carsten Bormann =20 Sent: 27 June 2020 22:19 To: Erik Andersen Cc: anima@ietf.org Subject: Re: [Anima] [lamps] on certification authorities. On 2020-06-27, at 09:57, Erik Andersen wrote: >=20 > certificate authority 4 matches in 1id-abstracts.txt. 7292 files on my laptop happen to match. Enjoy how RFC 4523 dances right into the fire here: ( 2.5.6.16 NAME 'certificationAuthority' DESC 'X.509 certificate authority' SUP top AUXILIARY MUST ( authorityRevocationList $ certificateRevocationList $ cACertificate ) MAY crossCertificatePair ) RFCs with =E2=80=9Ccertificate authority=E2=80=9D released before RFC = 5280: rfc1305.txt rfc2246.txt rfc2408.txt rfc2633.txt rfc2634.txt rfc2752.txt = rfc2828.txt rfc2847.txt rfc2904.txt rfc3108.txt rfc3182.txt rfc3193.txt = rfc3520.txt rfc3552.txt rfc3588.txt rfc3720.txt rfc3723.txt rfc3760.txt = rfc3851.txt rfc3854.txt rfc3911.txt rfc3920.txt rfc3923.txt rfc4171.txt = rfc4230.txt rfc4255.txt rfc4261.txt rfc4346.txt rfc4474.txt rfc4523.txt = rfc4534.txt rfc4582.txt rfc4795.txt rfc4870.txt rfc4949.txt rfc4953.txt = rfc5040.txt rfc5197.txt rfc5246.txt RFCs with =E2=80=9Ccertificate authority=E2=80=9D released after RFC = 5280: rfc5479.txt rfc5763.txt rfc5765.txt rfc5981.txt rfc6101.txt rfc6187.txt = rfc6189.txt rfc6376.txt rfc6406.txt rfc6810.txt rfc6818.txt rfc6837.txt = rfc6940.txt rfc6950.txt rfc6962.txt rfc7143.txt rfc7146.txt rfc7211.txt = rfc7340.txt rfc7378.txt rfc7427.txt rfc7533.txt rfc7576.txt rfc7671.txt = rfc7826.txt rfc7858.txt rfc7859.txt rfc7958.txt rfc8023.txt rfc8071.txt = rfc8446.txt rfc8572.txt rfc8705.txt (Not all of these are about X.509 certificates, of course. And I=E2=80=99m probably missing a few because line breaking obscures = the combination.) Yes, you saw TLS 1.0, 1.1, 1.2, and 1.3 there. Now starting to write the errata reports :-) Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Jun 28 11:08: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 DBF823A0E65 for ; Sun, 28 Jun 2020 11:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YfztsgvPTswi for ; Sun, 28 Jun 2020 11:08:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BCDA3A0E64 for ; Sun, 28 Jun 2020 11:08:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0148638988 for ; Sun, 28 Jun 2020 14:05:24 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id g4zLVAynASGt for ; Sun, 28 Jun 2020 14:05:22 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CCC5738984 for ; Sun, 28 Jun 2020 14:05:22 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DD8D3137 for ; Sun, 28 Jun 2020 14:08:07 -0400 (EDT) From: Michael Richardson To: spasm@ietf.org X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] [Anima] on certification authorities. (fwd) Carsten Bormann: Re: [Anima] on certification authorities. 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, 28 Jun 2020 18:08:12 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: message/rfc822 Content-Disposition: inline; filename=85 Content-Description: forwarded message Return-Path: Received: from tuna.sandelman.ca [2607:f0b0:f:3::184] by localhost with IMAP (fetchmail-6.4.0.beta4) for (single-drop); Sun, 28 Jun 2020 13:59:19 -0400 (EDT) Received: from tuna.sandelman.ca ([unix socket]) by tuna (Cyrus git2.4.17+0-Debian-2.4.17+nocaldav-0+deb8u2) with LMTPA; Sat, 27 Jun 2020 16:16:05 -0400 X-Sieve: CMU Sieve 2.4 Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id BA43838997 for ; Sat, 27 Jun 2020 16:16:05 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id j-8mabHiHZ02 for ; Sat, 27 Jun 2020 16:16:02 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tuna.sandelman.ca (Postfix) with ESMTPS id 6FBE538996 for ; Sat, 27 Jun 2020 16:16:02 -0400 (EDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD883A0407 for ; Sat, 27 Jun 2020 13:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1593289125; bh=qcCM3QZfKdK1ckRPZ7rUdDDuuJBMhfs1YVeQ8hGdjdY=; h=From:In-Reply-To:Date:References:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=vY5J565qaa5Z520h4tyIMweQnkGLqOQdDgPe+11zj93m1GoGi9VLcIyTU/sF23Web s+3HIro1Jn0bFYUYAxQkGpCBA2b40YjHtOBcBcZfH24wHHqOSW/1a4n11uG/PePcDh moSCCXdQeZypXRvUlI2sKYJV7HX57FUKT9TdBHSM= X-Mailbox-Line: From anima-bounces@ietf.org Sat Jun 27 13:18:44 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F8D3A00C4; Sat, 27 Jun 2020 13:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1593289123; bh=qcCM3QZfKdK1ckRPZ7rUdDDuuJBMhfs1YVeQ8hGdjdY=; h=From:In-Reply-To:Date:References:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=GaLKTyrv/WSJn7ZRH8NUFN0xsQvVA4AKGtn9iBm7AWqa/20POgoD2/5RgwBFnOpvx /gUzzB3EBgV0hfK7aYsE+EYcpBbglgGF8u8f2caqI8UfdFnGHFLTwT431ivsLWWPFF kJsYIh759wzS2FBnP1+mhbHO71M0wbG8jWRfOmLY= X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6C53A00C9 for ; Sat, 27 Jun 2020 13:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.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 f3xcibQmeBe3 for ; Sat, 27 Jun 2020 13:18:38 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C3E3A00C4 for ; Sat, 27 Jun 2020 13:18:37 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49vQ7H3yMYzybM; Sat, 27 Jun 2020 22:18:35 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <001001d64c58$98890d40$c99b27c0$@x500.eu> Date: Sat, 27 Jun 2020 22:18:34 +0200 X-Mao-Original-Outgoing-Id: 614981914.4838409-966d771d340f23f91727b8be2d355c53 Message-Id: <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> To: Erik Andersen X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Anima] [lamps] on certification authorities. X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: anima@ietf.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: anima-bounces@ietf.org Sender: "Anima" T24gMjAyMC0wNi0yNywgYXQgMDk6NTcsIEVyaWsgQW5kZXJzZW4gPGVyYUB4NTAwLmV1PiB3cm90 ZToKPiAKPiBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkKCjQgbWF0Y2hlcyBpbiAxaWQtYWJzdHJhY3Rz LnR4dC4KNzI5MiBmaWxlcyBvbiBteSBsYXB0b3AgaGFwcGVuIHRvIG1hdGNoLgoKRW5qb3kgaG93 IFJGQyA0NTIzIGRhbmNlcyByaWdodCBpbnRvIHRoZSBmaXJlIGhlcmU6CgogICAgICAoIDIuNS42 LjE2IE5BTUUgJ2NlcnRpZmljYXRpb25BdXRob3JpdHknCiAgICAgICAgICAgREVTQyAnWC41MDkg Y2VydGlmaWNhdGUgYXV0aG9yaXR5JwogICAgICAgICAgIFNVUCB0b3AgQVVYSUxJQVJZCiAgICAg ICAgICAgTVVTVCAoIGF1dGhvcml0eVJldm9jYXRpb25MaXN0ICQKICAgICAgICAgICAgICAgIGNl cnRpZmljYXRlUmV2b2NhdGlvbkxpc3QgJCBjQUNlcnRpZmljYXRlICkKICAgICAgICAgICBNQVkg Y3Jvc3NDZXJ0aWZpY2F0ZVBhaXIgKQoKUkZDcyB3aXRoIOKAnGNlcnRpZmljYXRlIGF1dGhvcml0 eeKAnSByZWxlYXNlZCBiZWZvcmUgUkZDIDUyODA6CgpyZmMxMzA1LnR4dCByZmMyMjQ2LnR4dCBy ZmMyNDA4LnR4dCByZmMyNjMzLnR4dCByZmMyNjM0LnR4dApyZmMyNzUyLnR4dCByZmMyODI4LnR4 dCByZmMyODQ3LnR4dCByZmMyOTA0LnR4dCByZmMzMTA4LnR4dApyZmMzMTgyLnR4dCByZmMzMTkz LnR4dCByZmMzNTIwLnR4dCByZmMzNTUyLnR4dCByZmMzNTg4LnR4dApyZmMzNzIwLnR4dCByZmMz NzIzLnR4dCByZmMzNzYwLnR4dCByZmMzODUxLnR4dCByZmMzODU0LnR4dApyZmMzOTExLnR4dCBy ZmMzOTIwLnR4dCByZmMzOTIzLnR4dCByZmM0MTcxLnR4dCByZmM0MjMwLnR4dApyZmM0MjU1LnR4 dCByZmM0MjYxLnR4dCByZmM0MzQ2LnR4dCByZmM0NDc0LnR4dCByZmM0NTIzLnR4dApyZmM0NTM0 LnR4dCByZmM0NTgyLnR4dCByZmM0Nzk1LnR4dCByZmM0ODcwLnR4dCByZmM0OTQ5LnR4dApyZmM0 OTUzLnR4dCByZmM1MDQwLnR4dCByZmM1MTk3LnR4dCByZmM1MjQ2LnR4dAoKUkZDcyB3aXRoIOKA nGNlcnRpZmljYXRlIGF1dGhvcml0eeKAnSByZWxlYXNlZCBhZnRlciBSRkMgNTI4MDoKCnJmYzU0 NzkudHh0IHJmYzU3NjMudHh0IHJmYzU3NjUudHh0IHJmYzU5ODEudHh0IHJmYzYxMDEudHh0CnJm YzYxODcudHh0IHJmYzYxODkudHh0IHJmYzYzNzYudHh0IHJmYzY0MDYudHh0IHJmYzY4MTAudHh0 CnJmYzY4MTgudHh0IHJmYzY4MzcudHh0IHJmYzY5NDAudHh0IHJmYzY5NTAudHh0IHJmYzY5NjIu dHh0CnJmYzcxNDMudHh0IHJmYzcxNDYudHh0IHJmYzcyMTEudHh0IHJmYzczNDAudHh0IHJmYzcz NzgudHh0CnJmYzc0MjcudHh0IHJmYzc1MzMudHh0IHJmYzc1NzYudHh0IHJmYzc2NzEudHh0IHJm Yzc4MjYudHh0CnJmYzc4NTgudHh0IHJmYzc4NTkudHh0IHJmYzc5NTgudHh0IHJmYzgwMjMudHh0 IHJmYzgwNzEudHh0CnJmYzg0NDYudHh0IHJmYzg1NzIudHh0IHJmYzg3MDUudHh0CgooTm90IGFs bCBvZiB0aGVzZSBhcmUgYWJvdXQgWC41MDkgY2VydGlmaWNhdGVzLCBvZiBjb3Vyc2UuCkFuZCBJ 4oCZbSBwcm9iYWJseSBtaXNzaW5nIGEgZmV3IGJlY2F1c2UgbGluZSBicmVha2luZyBvYnNjdXJl cyB0aGUgY29tYmluYXRpb24uKQoKWWVzLCB5b3Ugc2F3IFRMUyAxLjAsIDEuMSwgMS4yLCBhbmQg MS4zIHRoZXJlLgoKTm93IHN0YXJ0aW5nIHRvIHdyaXRlIHRoZSBlcnJhdGEgcmVwb3J0cyA6LSkK Ckdyw7zDn2UsIENhcnN0ZW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCkFuaW1hIG1haWxpbmcgbGlzdApBbmltYUBpZXRmLm9yZwpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hCg== --=-=-= Content-Type: text/plain -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl743IcACgkQgItw+93Q 3WW7ZAgAnjcz3ZAyVrMXrZVNXYpNjw3qrZaCMVRY4N/rkTgipokwdJHCw0WfPbB3 EJtpb6wwvc/QtpSh2fmGNlCrAnt9TsR1fntJ/ehHR6VsHWa0qkthPC6iMDd/K+RB 72zmP8aHOuf5I0TKhldWmEgVT46lwIIG4+nH3BvoOZjC+pT3w5NdFUW5Ot1B2kos eR0GxABDXESfwg9vpz4oEYDJiZuyfwhIuAIbmN/Uu+tUypGUh8BqBGs6NHNhfjEF cIn+gmRunWeqQsRcpwHQ7a0Dk7KgQ+VNurpIStezFaRYgwjEGxyJz9Rs+lcD5pHp uIl/RVWAk3TooyRVap9zPcXu1/PUgA== =of5V -----END PGP SIGNATURE----- --==-=-=-- From nobody Sun Jun 28 13:51: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 5B7653A0F3B; Sun, 28 Jun 2020 13:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 r2WNrxdtWPaM; Sun, 28 Jun 2020 13:51:31 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 192873A0F39; Sun, 28 Jun 2020 13:51:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9C04A3898C; Sun, 28 Jun 2020 16:48:43 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id A1X3nlNBCMPW; Sun, 28 Jun 2020 16:48:42 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 68F3338988; Sun, 28 Jun 2020 16:48:42 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9116F137; Sun, 28 Jun 2020 16:51:27 -0400 (EDT) From: Michael Richardson To: Tomas Gustavsson , secdispatch@ietf.org cc: spasm@ietf.org In-Reply-To: <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] IDevID considerations document to secdispatch 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, 28 Jun 2020 20:51:35 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Thank you again for reviewing the document! I know that primekey is involved in creating Birth Certificates for many product lines. (Your website's term, not mine, but a good one) I wonder if you can comment on which of the three methods you support? Do you have any suggestions on names for the three methods? To me, just getting three good names is 90% of the value of this document. Thinking about "birth" concept, I am trying to think if this helps with terms. Invivo <- self-generated private key, with enrollment. Invitro <- private key generated in test-tub, deployed to device. I also feel that I want to leverage the "digital twin" terminology a bit for the third case. I suspect that there might also be some hybrid/fourth case that uses Threshold Modes in Elliptic Curves, draft-hallambaker-threshold-02 and while I think this would be an improvement on the security side of things, I also am concerned that it may make the manufacturing process worse. In particular, the self-generated (_invivo_) key suffers because the device needs to do a write/read operation from the infrastructure. That involves the highest possible latency for interaction with the CA and therefore would slow the assembly line the most. The invitro and shared-secret methods allows the infrastructure to generate a few keys in advance (and get them signed, assigning DN-serialNumber at the same time), and then injecting that key via JTAG at the same time as the firmware. This overlaps the CA interaction with other steps. Tomas Gustavsson wrote: > On 2020-06-11 19:52, Michael Richardson wrote: >> >> Tomas Gustavsson wrote: >>> The notion of serialNumber in the document, for me, reads as it's >>> not clear what is the certificate serial number (9-19 bytes in >>> your document) and the device serial number. There don't have to >>> be the same. What I have seen commonly used is that the subjectDN >>> field is used to carry the device serial number, while the >>> certificate serial number is random, and only used to uniquely >>> identify the certificate in the PKI (issuer/serial). >> >> Your assumption is entirely correct. I wish that certificates >> hadn't used "serial Number" in it's terminology, as it's really >> "certificate Identifier", and we have learnt the hard way that it >> should not be sequential. >> >>> In such a case I would assume that the manufacturing execution >>> system (MES) and it's database controls the device serial number, >>> while the PKI controls the certificate serial number, and there >>> does not have to be any synchronization between these two. >> >> Agreed. Do I say something different here? I would love to clarify >> things. > This section confused me at first read: > ----- > In all cases the serialNumber embedded in the certificate must be > unique across all products produced by the manufacturer. This suggests > some amount of structure to the serialNumber, such that different > intermediate CAs do not need to coordinate when issuing certificates > ----- > At first read I thought about certificate serial number, but now > realize it's the device serial number that is meant. I think that > section can be clarified somewhat. okay, I will do that. I wish I had a good way to distinguish things. "serialNumber" (in that case), is a used in RFC5280 as the field name of the "CertificateSerialNumber", I sure wish we could go back and change the name of the field to be "certificateIdentity" The same document mentions "id-at-serialNumber" and X520SerialNumber! And in section 4.1.2.4 (Issuer) and 4.1.2.6 (Subject), it uses the term "serial number"... and the usual rendering in a DN is that it is "serialNumber" (OID 2.5.4.5, I think it is)! I will call it the "product DN-serialNumber". How does this strike you? > Some additional nitpicking... > I think this section is missing an 's'? Do you mean the title? that it should be: ## Public Key infrastructure for IDevID -> ## Public Key infrastructure for IDevIDs > ----- > The intermediate CA will have a private key, likely kept online, which > is used to sign each generated IDevID. Once the IDevID are created, > the private key is no longer needed and can either be destroyed, or > taken offline. > ----- > In the line preceding this section it talks about "some number of > IDevIDs". Then that the CAs private key can be destroyed after > generating that number if IDevIDs. Hence, just ad an s: > "Once the IDevID are created, the private key is no longer needed and > can either be destroyed, or taken offline." -> > "Once the IDevIDs are created, the private key is no longer needed and > can either be destroyed, or taken offline." I think I found all the missing s, and one case where it should be CAs' rather than CA's. see commit/diff: https://github.com/mcr/idevid-security-considerations/commit/84fa9fad74d9b2d950b061a4fa5bf3fe99443472?short_path=77f5cdf#diff-77f5cdfefb38aca78416645deaa3310e --=-=-= Content-Type: text/plain Content-Disposition: inline Content-Description: Signature -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl75As8ACgkQgItw+93Q 3WUKKwgAkkb57DzjtQWi+sKUEPTjFm8ak2nX4OM26JBC2eo1xwDVZ8Drny1tIUQZ wk6B06iZcX0wZflYmy11VT/krWsI3P+f7H8tcbMJUsrr/KwQgiBlzNADpIKZYum6 hbtOVjwQCRTpK5aR5qa3DdjQ10vvedA8xrWfw6nRoDoiq2AoPMlx2wM3C+ohuTgh LDFnqgQndK7oMaJOby1isas9nEacqLjRPRCTHLWYttkIe1rtnd6aOmiThmPqSgC2 6VUa5yJhPR9dg2cZZH8sDfBdciD5CNhwnoOfZEzJrqtGj4XK5OhEDF+dYICw1EoS 5wtRZ6qVSxV30NOIXwH3b9FtkfwSkg== =p5Dx -----END PGP SIGNATURE----- --==-=-=-- From nobody Mon Jun 29 00:10: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 18C773A090B; Mon, 29 Jun 2020 00:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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] 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 rYlzGpBxBwCD; Mon, 29 Jun 2020 00:10:30 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20041.outbound.protection.outlook.com [40.107.2.41]) (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 A2F583A0901; Mon, 29 Jun 2020 00:10:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RY4OZy3nVh6P/zGRu4jlT+qbCmu6EjjnOAilbHDYt8Fia8wjo2yb9jjhxNuJ0YJyrL8YiYmH37cGZ5GC/ISNraOFK7GVtzhdDUQBoje53oZh+4+VLKzcF2JktxBb5CBSNwAdRJZlJykKsQVKz1R1KyXmhzZcVDchcNaNETb/YnGjED/LelSaUAqgvCIsF1k3J2kLb5OzFAmiZeskWOA/cfONmpRgwoEqzVTC+rG2q2S2FzMkV/btM49QjalZ+GNkyBy+bqCEmRZuM5jb75JVh4PA4yN9e1pz/m2ogcN77eH7cCEMSePl4etGKNp5FtMKAZne41NHrMr2kQSw7gJQKA== 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=NUlRfvsB1SVaR2prfoPgY+Lp4bj7Oa1+QL8+1/vft+o=; b=GBlY2p/itzBWmgYGMm33b82yxmvNHF0gs78ChsTHqmivOAhNvtZEO3PlT25+fbm35sTWtZrsRcEkvOtpk9W8FfBm3v54kyNckinfiIZvR7hBBfnrjXi/oWilbv6ApRJkkM42IuVjNHKir0II4EUPFXAFIDapnec4zG0ZmRmkGA2b8pYmjdoi72J3GYh/4r4flr4eh1+ARz+FY8Fzut70d12V+GwrI2+HI0wXwwSJ8I24hviuFpSKfJdPFep0GNo8kOrE405ydp4uzseAxjBZ8y4pTyXrt276XH/Xs5dr8c4WO0v+npeb6W/WrA+Gi6n/E1bPXynGgc9kZchDvFzI7Q== 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=NUlRfvsB1SVaR2prfoPgY+Lp4bj7Oa1+QL8+1/vft+o=; b=aginh0f0nBBP2VjgPEGUT6P64O03R4GL92HBc0oWHw69ZjJzFc+4VKlcNaNuWdOjsfy6KmaFbXHIwr46PgNZuxpcc1KSJSAhxoO2F5ojsUbUOiUOZEMUyCb5dL+5fqxRjN9C6aldnHO0AclZ3T7xxK5Z8xKSBdhCh336o5SAXQE= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:e2::32) by AM0PR10MB2868.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:15d::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.23; Mon, 29 Jun 2020 06:54:36 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::ccfa:a7d4:79ed:c39a]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::ccfa:a7d4:79ed:c39a%4]) with mapi id 15.20.3131.026; Mon, 29 Jun 2020 06:54:36 +0000 From: "Brockhaus, Hendrik" To: Michael Richardson , "secdispatch@ietf.org" CC: "spasm@ietf.org" , Tomas Gustavsson Thread-Topic: [lamps] IDevID considerations document to secdispatch Thread-Index: AQHWP8N6k88ddaiq9U6Bs/QsBzthBajTsr2AgAV/EICAFWp0gIAApgFA Date: Mon, 29 Jun 2020 06:54:36 +0000 Message-ID: References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> In-Reply-To: <20595.1593377487@localhost> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.26.241] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6ebdf368-d81c-44cf-825b-08d81bf94936 x-ms-traffictypediagnostic: AM0PR10MB2868: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 044968D9E1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NLeahZ2/whU/GoG8u9mMqLZg5Tg8cVHwmu4Xhfn6CZhYFTCh6otAweVe8epZyaftk+bBrP27yO1WkyMVjgRonS7X1QI3HEMjUA4izFUF6ASiFgW/oNqax3ZjWEuxauiirJp4cBv/AyEF4C4v4qhEHgk3OeXfkhRPHRnRxCeKfK+O9UXEOjB9NdmbBYMccGDrZsC3RDMiIa0IgWsbEvwZa0CAmu4/MlmyPDLpF3Kdul9M87aVHiR5poy64HRSQLrrNDuJLrKmqgCW0abT1HQ40NvihzF/wCAZjvP3QaC/pM4/69teRS0w5+so0g62lqBKF+rxATLzDwFq8mPKSrq54A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(346002)(396003)(136003)(366004)(54906003)(26005)(55236004)(478600001)(71200400001)(83380400001)(33656002)(86362001)(316002)(55016002)(9686003)(64756008)(66446008)(6506007)(2906002)(110136005)(66946007)(76116006)(7696005)(66476007)(4326008)(66556008)(186003)(8936002)(52536014)(8676002)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: qTbLbRLWV/kWib1nMpL+TxiMMMTwBLKy9Jw4gj57BXXdq06cVSd932vCTx+F868SumMMSD5EUBXI85ko5Xu3XvAHY7uVkVO+NMvcOwksfqYBR937d+bkGilKovQ8NK2QmjYSo4v/CAqhGsW0utp/4rPp1UJ270zXuCyXbmFzZFt2rYN+dn3tdDpt0AdX1iTTOidTBt/LcmSX8DbGAmA0TkINDLXOkBKC+eykWkmY1wUECvN7XB6azHbwaoAW+SiswNPl6MU72s7uPkIit4zx/OwXA21jrdzMUFNGdEC5bElxkugh/+qGZTSY9o4iMP3CkzzK9RfaXupm3OHSSwX3FWYHzSvy0CcsOKrCggITBEwY2bLrA7dW5w/4NWD/BdlyAt7Kjg0zOEVJmF1+Rb0YezLn9CKN3B+ci+zXgqql5UN2dPYSdw2vG3cjo0ovWWiNnFqqNao5WGB3Fz9JgQNA1duP7ZVgi8Eaw3CMNVXiRidibTXI5LaNzfBPi9WvXGJB 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: AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 6ebdf368-d81c-44cf-825b-08d81bf94936 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2020 06:54:36.1051 (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: /SlIaUEOPx2SGR4HjppWc6VqOQqVTABlhV/toYGHFqeuuSIT2mKrSqVNZEZBxFkEZdPpdJjIaCDgimIBQFoToBa8jgoBrEmlHbkl4Ir+NDQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2868 Archived-At: Subject: Re: [lamps] IDevID considerations document to secdispatch 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, 29 Jun 2020 07:10:31 -0000 Richard >=20 > In particular, the self-generated (_invivo_) key suffers because the devi= ce > needs to do a write/read operation from the infrastructure. That involve= s the > highest possible latency for interaction with the CA and therefore would = slow > the assembly line the most. We make use of the key-pair generated on the fly on the device and do not s= ee major delay on the manufacturing line due to CA communication. Finally it is a question of how you arrange your manufacturing procedures. = If you experience delay due to waiting for the certificate delivery, you ca= n do other meaningful things in the meantime. >=20 > The invitro and shared-secret methods allows the infrastructure to genera= te a > few keys in advance (and get them signed, assigning DN-serialNumber at th= e > same time), and then injecting that key via JTAG at the same time as the > firmware. This overlaps the CA interaction with other steps. >=20 Finally this method puts higher security burden on the manufacturing infras= tructure to securely handle the pre-generated key pairs. This is why I do n= ot like it, but sometimes it is needed. -- Hendrik=20 From nobody Mon Jun 29 01:05: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 09ADF3A0BD5; Mon, 29 Jun 2020 01:05:26 -0700 (PDT) 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=primekey.com header.b=JPnIoCWY; dkim=pass (1024-bit key) header.d=primekey.com header.b=JPnIoCWY 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 uTxYNRvDkGT6; Mon, 29 Jun 2020 01:05:23 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D4E3A0BAE; Mon, 29 Jun 2020 01:05:22 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id C99606AA01AD; Mon, 29 Jun 2020 10:05:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1593417901; bh=U9yK/HrtiQOG2UeMDHjoahKkRMUis3hFHUzPEhgjgLk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=JPnIoCWYriSlI1NnrJo4fFTnHVVYKPk0sAXRIhXqjBwCOxeh6g0xoK64PUddvn1Gb By3mM0LVgry3XMFWeJgYy7hjdRzk1GH2bh91mU1izOkDied+7dx68PGqEa9/V5SZkW +RKOkMDsZRcZk5BQM/8nM9+bukTh5Nf2h3DsfI4Y= Received: from [192.168.1.100] (m37-2-193-37.cust.tele2.se [37.2.193.37]) (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 88DAE6AA01AB; Mon, 29 Jun 2020 10:05:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1593417901; bh=U9yK/HrtiQOG2UeMDHjoahKkRMUis3hFHUzPEhgjgLk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=JPnIoCWYriSlI1NnrJo4fFTnHVVYKPk0sAXRIhXqjBwCOxeh6g0xoK64PUddvn1Gb By3mM0LVgry3XMFWeJgYy7hjdRzk1GH2bh91mU1izOkDied+7dx68PGqEa9/V5SZkW +RKOkMDsZRcZk5BQM/8nM9+bukTh5Nf2h3DsfI4Y= To: Michael Richardson , secdispatch@ietf.org Cc: spasm@ietf.org References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> 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: <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> Date: Mon, 29 Jun 2020 10:05:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20595.1593377487@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] IDevID considerations document to secdispatch 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, 29 Jun 2020 08:05:26 -0000 Hi, On 2020-06-28 22:51, Michael Richardson wrote: > > Thank you again for reviewing the document! > > I know that primekey is involved in creating Birth Certificates for > many product lines. (Your website's term, not mine, but a good > one) It wasn't my (ours) terminology unfortunately :-). We found it elsewhere. I don't remember where "birth" came from. 3GPP 33.310 have the same concept, but calling Vendor certificate. I think birth certificate is a little better, as it's more generic than specifying a vendor relationship. > I wonder if you can comment on which of the three methods you > support? Do you have any suggestions on names for the three > methods? To me, just getting three good names is 90% of the value > of this document. We support: 2.1.1. On-device private key generation Standard CSR-submitted-to-CA process 2.1.2. Off-device private key generation Typically CA-generates-keystore process. Some protocols, i.e. CMP/RFC4210 have standard support for encrypting the private key sent back to the client 2.1.3. Key setup based on 256-bit secret seed We haven't seen this. Albeit, it's not so much related to the PKI part, so it can still be supported/used if the certificate issuance is done using a CSR process to the CA. > Thinking about "birth" concept, I am trying to think if this helps > with terms. Invivo <- self-generated private key, with > enrollment. Invitro <- private key generated in test-tub, deployed > to device. Good idea to have naming for these. I like the idea. I don't have any immediate ideas. Are there any naming from TMP/SE vendors/standards that can be re-used? (I'm not very familiar with those specs myself). > I also feel that I want to leverage the "digital twin" terminology > a bit for the third case. > > I suspect that there might also be some hybrid/fourth case that > uses Threshold Modes in Elliptic Curves, > draft-hallambaker-threshold-02 and while I think this would be an > improvement on the security side of things, I also am concerned > that it may make the manufacturing process worse. > > In particular, the self-generated (_invivo_) key suffers because > the device needs to do a write/read operation from the > infrastructure. That involves the highest possible latency for > interaction with the CA and therefore would slow the assembly line > the most. > > The invitro and shared-secret methods allows the infrastructure to > generate a few keys in advance (and get them signed, assigning > DN-serialNumber at the same time), and then injecting that key via > JTAG at the same time as the firmware. This overlaps the CA > interaction with other steps. > > > Tomas Gustavsson wrote: >> On 2020-06-11 19:52, Michael Richardson wrote: >>> >>> Tomas Gustavsson wrote: >>>> The notion of serialNumber in the document, for me, reads as >>>> it's not clear what is the certificate serial number (9-19 >>>> bytes in your document) and the device serial number. There >>>> don't have to be the same. What I have seen commonly used is >>>> that the subjectDN field is used to carry the device serial >>>> number, while the certificate serial number is random, and >>>> only used to uniquely identify the certificate in the PKI >>>> (issuer/serial). >>> >>> Your assumption is entirely correct. I wish that certificates >>> hadn't used "serial Number" in it's terminology, as it's >>> really "certificate Identifier", and we have learnt the hard >>> way that it should not be sequential. >>> >>>> In such a case I would assume that the manufacturing >>>> execution system (MES) and it's database controls the device >>>> serial number, while the PKI controls the certificate serial >>>> number, and there does not have to be any synchronization >>>> between these two. >>> >>> Agreed. Do I say something different here? I would love to >>> clarify things. > >> This section confused me at first read: ----- In all cases the >> serialNumber embedded in the certificate must be unique across >> all products produced by the manufacturer. This suggests some >> amount of structure to the serialNumber, such that different >> intermediate CAs do not need to coordinate when issuing >> certificates ----- > >> At first read I thought about certificate serial number, but now >> realize it's the device serial number that is meant. I think >> that section can be clarified somewhat. > > okay, I will do that. I wish I had a good way to distinguish > things. > > "serialNumber" (in that case), is a used in RFC5280 as the field > name of the "CertificateSerialNumber", I sure wish we could go back > and change the name of the field to be "certificateIdentity" > > The same document mentions "id-at-serialNumber" and > X520SerialNumber! And in section 4.1.2.4 (Issuer) and 4.1.2.6 > (Subject), it uses the term "serial number"... and the usual > rendering in a DN is that it is "serialNumber" (OID 2.5.4.5, I > think it is)! > > I will call it the "product DN-serialNumber". How does this strike > you? For me that is crystal clear. Nice. > >> Some additional nitpicking... I think this section is missing an >> 's'? > > Do you mean the title? that it should be: ## Public Key > infrastructure for IDevID -> ## Public Key infrastructure for > IDevIDs > >> ----- The intermediate CA will have a private key, likely kept >> online, which is used to sign each generated IDevID. Once the >> IDevID are created, the private key is no longer needed and can >> either be destroyed, or taken offline. ----- > >> In the line preceding this section it talks about "some number >> of IDevIDs". Then that the CAs private key can be destroyed >> after generating that number if IDevIDs. Hence, just ad an s: > > > >> "Once the IDevID are created, the private key is no longer needed >> and can either be destroyed, or taken offline." > -> >> "Once the IDevIDs are created, the private key is no longer >> needed and can either be destroyed, or taken offline." > > I think I found all the missing s, and one case where it should be > CAs' rather than CA's. > > see commit/diff: > https://github.com/mcr/idevid-security-considerations/commit/84fa9fad74d9b2d950b061a4fa5bf3fe99443472?short_path=77f5cdf#diff-77f5cdfefb38aca78416645deaa3310e > > > > -- ] Never tell me the odds! | ipv6 > mesh networks [ ] Michael Richardson, Sandelman Software Works > | IoT architect [ ] mcr@sandelman.ca > http://www.sandelman.ca/ | ruby on rails [ > > > > From nobody Tue Jun 30 13:30: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 559DA3A081D for ; Tue, 30 Jun 2020 13:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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, T_SPF_TEMPERROR=0.01, 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=TJZobxO0; dkim=pass (1024-bit key) header.d=digicert.com header.b=giKZL3t7 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 KtNFJvMm0beJ for ; Tue, 30 Jun 2020 13:30:47 -0700 (PDT) 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 6B9613A0990 for ; Tue, 30 Jun 2020 13:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1593548968; 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=NPVsXRdHq2f8sh6XfXdCNLxZ0AM08buk/hswFAVUkI4=; b=TJZobxO0izcfeXUOvVJcHKdFp8dTos2HiWU5Jzh0qiL3LZJadFfOh6orPM7tG03+O5pI4j PGKCdihAZAtzt2DU/w5uFFZFFh3VjDSt5r3PyD092D38RaD9i2TsPmJRBeCIJaVszlza4e I70G9igCP/lHeqP/e3CjOK3rCHLdENs= 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-368-37ZhgKfxMSGfWH2KWRdlqg-1; Tue, 30 Jun 2020 16:29:24 -0400 X-MC-Unique: 37ZhgKfxMSGfWH2KWRdlqg-1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BI1EdiB4/HE/acJW7uI73miEZMdqiPwhiyzspZQ2+NIt8cH8IFHqYMwbkh+2I1Ug1p2hr2WovbtOaYRhw4LO/xiwcKOCUzoc8bmEbLdsEWCMT96uftLBZoa28/ASmN/MHHPrh0cdac9y9j6fYl2HFISqsxVKU0NiF+InhliYD5E6yGd5BPJwuAxzZ4SZmnstZw6RHnZdvMunGKwScbZxGOBEdOp3SoyKzSFHcduF8OcSl7S47e/qdRqgxk69FL/y2xWxxcbpAhbTNna7roCRSs7M5mr7NxP65EgnWhT7+UIOaRGZSdeixqVEwGvir3CoAAEnHEpe0qY61kJHl7sAfg== 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=NPVsXRdHq2f8sh6XfXdCNLxZ0AM08buk/hswFAVUkI4=; b=od3f63iMdqucBA+hnZzg/tCuNvcJXf1haFR9BMmh38iroiw7IoFC0AiLjuARYZ/9sKhO/3wVa53aU9QB5nOaPc2xfqAnYcEW3idAZAg78H+8N0D8cyxdQiOmjJEphxaFKp/4Ucu4mt3I8y8TXZSdg2JtrEC+ahHoTlUQl29Km5MyBkbnJtwOS7eZQeYYBgZX2YPXJRSAWxLouP2J+pnIHv5H1Vo8Ws37dS3ViwZvdAiVSmBkxzjvtPF8cfIMWKD4fhAH7pKzKZr0MldcYNFwdVdLTGLvdWcVcr1RnHSkXbkAYwXQeFvBgTZOHET8RXojaWDKj5HxAeYJ/UsOQtwX2A== 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=NPVsXRdHq2f8sh6XfXdCNLxZ0AM08buk/hswFAVUkI4=; b=giKZL3t7NhggMQQ6GouP7GJYC9PhnPYrQJnh5gmSK67NmZ2eVBG3VdmsvvYWQokAdfEp767JSdxS/+WrccFt0fOBnGeg6vOqsNmxtN01O8E3JGfodfW0fu7btSai4Ii5yyr2yc32m5/Ts5lyc51Lo5LSz7nvWPvp5UQPwud4cxs= Received: from MN2PR14MB3167.namprd14.prod.outlook.com (2603:10b6:208:12e::28) by MN2PR14MB2621.namprd14.prod.outlook.com (2603:10b6:208:c3::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21; Tue, 30 Jun 2020 20:29:22 +0000 Received: from MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::419f:18ba:1450:6cb]) by MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::419f:18ba:1450:6cb%7]) with mapi id 15.20.3153.020; Tue, 30 Jun 2020 20:29:22 +0000 From: Tim Hollebeek To: SPASM Thread-Topic: shepherd writeup for draft-ietf-lamps-cms-update-alg-id-protect Thread-Index: AdZPHMejBDL09tWbSUyTLYwNN0bjfA== Date: Tue, 30 Jun 2020 20:29:22 +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.98.249.186] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7941679b-1326-44a5-f763-08d81d344659 x-ms-traffictypediagnostic: MN2PR14MB2621: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2657; x-forefront-prvs: 0450A714CB x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +dTi+ORh01cet+EhSVcf6gUSYt7lnPjSQHl1adLMsRd9iyv3mqEaqiQ96G6IWHhLMkBYNAFEqv8vl+LO0/sUozzFEYixX4mgkciGzcr3SUpaCUWmAt26nUtWnu9aT5GXIdckdMc8E7uu3s24OAplPiP8k8DJ3RDOW7YVdyt+zljWdPg2Pb5ViWW1lV5nXU5Vk07Fe+DtGT4N1IljRt5YmrBw6dD5AmGjVs5vnI5rEXXWmEFTsjNZrnP68Pnl0UQsCPTHqOTjZg3zw41ievOu3BvkdBl8BYubO8dwdQGYKrYl/6f639S9H8qFVIxXAkQaccv27xjzXdqPrAqOslOnzS57nZF6TCQHbR2QzVq0Q1YzWKHOt6462JwpW2pWAu185WZBPUev+nrruaCF4ZOJvw== 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; SFTY:; SFS:(376002)(396003)(39850400004)(136003)(346002)(366004)(7696005)(15650500001)(71200400001)(2906002)(558084003)(186003)(8936002)(8676002)(99936003)(6916009)(83380400001)(44832011)(316002)(478600001)(33656002)(76116006)(966005)(9686003)(55016002)(66476007)(166002)(66616009)(64756008)(66446008)(66556008)(6506007)(5660300002)(66946007)(52536014)(26005)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 2ivV8vsaaYcBmZYB+WshX1ROjlL/+rjv1tIckPzRYDnNwf7VlnXh85XUODeQWbwc6pS7C3YGoIXWErJJI5kQ1QESCRCk2BfIP3uiTiY5xnH0iEyZAwwEyd6M5pNSKMvjUJWL0wmJav4eYOz34TXEQuInviIf8TH16hugAGaBlkw5ZdGO2HoLH7qs9iebQ5VA99nz/YtfOj6ULs6nIE6aONcsIjLjJ2ACdO1yrz3S+f/heJvFGM7N7FilIoQcUuq4lzoRO+V9Un8qHDRvI7TEAvkGkZHhuCXdd8eSy4Yh1WUqOuzDaIpnwv2Lr94AKKt1QtrBtlW/jGU4oS03lrRQlj7EtjBEqC9yiycsd0HnQqtVYkSeHn+1zj1y9x2IIRca6yc1FH3brHb+Xs+IPXppUYg2pUwmU4PpQ6auOExW4PlSrmpyyv0MLbhXbGdRo0/fkkGO8ige5PKr+SGaI5f0Kpd+b1BApbWDPcaPDNp0dU063Jq7fCFpYrWtswa7ZVwL 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_024D_01D64EFB.688C47B0" 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: 7941679b-1326-44a5-f763-08d81d344659 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2020 20:29:22.7052 (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: U6XAgl5hYmZOTX1iV0S7Aifg4EUg8bH2TeMH+XT9cHuYGO9CMw3p9/DoGLQArIaO/oRCWI7mgu54js3CaOFaBAg7VRPb+QRg6nn2BUgjrLw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB2621 Archived-At: Subject: [lamps] shepherd writeup for draft-ietf-lamps-cms-update-alg-id-protect X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 20:30:53 -0000 ------=_NextPart_000_024D_01D64EFB.688C47B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_024E_01D64EFB.688C47B0" ------=_NextPart_001_024E_01D64EFB.688C47B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protect/ shepherdwriteup/ Please review and comment. -Tim ------=_NextPart_001_024E_01D64EFB.688C47B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

https://datatracker.ietf.org/doc/draft-ietf-= lamps-cms-update-alg-id-protect/shepherdwriteup/

 

Please = review and comment.

 

-Tim

------=_NextPart_001_024E_01D64EFB.688C47B0-- ------=_NextPart_000_024D_01D64EFB.688C47B0 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 CQUxDxcNMjAwNjMwMjAyNzU1WjAvBgkqhkiG9w0BCQQxIgQgwInNSdLbD6fR5Dm6sm4OyaD1gTK/ 87uFDkpAY8IERHswgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBADWjj2hOaKNLgPGSUKO+4pwhvEZELnrthy1IiExH22qKuAHZmoc45gz8JfeL7fCMVb+Nh3Ng dh6LLI+pbD0k8KldPy5dKuS84MhXOUbh82rvXNQ3npTizjWlNQnUYX2oiqvbCo8LGSSVIEooKwzb TQNK0sqODoSx6Gvb5VuNuQM3GOc61E6BOgzjzJqOMAUcoGUYMNeaUswmjz074Wn5BuCw9NvBY3uW hi4XI2ZUiCOE9U7jyuVaS9jgiCQc3dMQZTuPE1TFLKV4W4qWojT6bhnkEUDBak74OfjHbU9aDtAO FzYTv/y5wDEe63XmQ2jSVUl1p5JazfIjFZB0Xkqk4k0AAAAAAAA= ------=_NextPart_000_024D_01D64EFB.688C47B0-- From nobody Tue Jun 30 13:36: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 208EE3A0823 for ; Tue, 30 Jun 2020 13:36:17 -0700 (PDT) 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 Nd7KuSb14m6e for ; Tue, 30 Jun 2020 13:36:15 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A1413A0810 for ; Tue, 30 Jun 2020 13:36:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BD868300B71 for ; Tue, 30 Jun 2020 16:36:12 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 84NIr6N4ucIw for ; Tue, 30 Jun 2020 16:36:11 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 7C93430009A; Tue, 30 Jun 2020 16:36:11 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_5FB742F4-3915-49B9-AAB4-C03F24C124A5" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Tue, 30 Jun 2020 16:36:12 -0400 In-Reply-To: Cc: SPASM To: Tim Hollebeek References: X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [lamps] shepherd writeup for draft-ietf-lamps-cms-update-alg-id-protect X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 20:36:17 -0000 --Apple-Mail=_5FB742F4-3915-49B9-AAB4-C03F24C124A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This seem fine to me. Thanks. > On Jun 30, 2020, at 4:29 PM, Tim Hollebeek = wrote: >=20 > = https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protec= t/shepherdwriteup/ = > =20 > Please review and comment. > =20 > -Tim > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm = --Apple-Mail=_5FB742F4-3915-49B9-AAB4-C03F24C124A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = seem fine to me.  Thanks.


On Jun = 30, 2020, at 4:29 PM, Tim Hollebeek <tim.hollebeek=3D40digicert.com@dmarc.ietf.org> = wrote:

https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-al= g-id-protect/shepherdwriteup/
 
Please review and comment.
 
-Tim
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

= --Apple-Mail=_5FB742F4-3915-49B9-AAB4-C03F24C124A5--