From nobody Tue Aug 1 10:15:17 2017 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 4320C1200F3 for ; Tue, 1 Aug 2017 10:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] 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 vxFNkojfk-1P for ; Tue, 1 Aug 2017 10:15:14 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 743EA1321B1 for ; Tue, 1 Aug 2017 10:15:14 -0700 (PDT) Received: from maxs-mbp.cablelabs.com (host64-111.cablelabs.com [192.160.73.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 2D3EF3740843; Tue, 1 Aug 2017 11:12:10 -0400 (EDT) To: "Salz, Rich" , "Dang, Quynh (Fed)" , Russ Housley Cc: LAMPS References: <04e73e42-7c5b-912d-cc79-7959a710927e@openca.org> <0a12992260ec44ebab8cff0426670cc8@usma1ex-dag1mb1.msg.corp.akamai.com> From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <7e290f82-2b2b-44ac-d976-d94064f3d90b@openca.org> Date: Tue, 1 Aug 2017 09:12:09 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <0a12992260ec44ebab8cff0426670cc8@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060707010801010204020704" Archived-At: Subject: Re: [lamps] Considerations about the need to resume PKIX work X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 17:15:16 -0000 This is a cryptographically signed message in MIME format. --------------ms060707010801010204020704 Content-Type: multipart/alternative; boundary="------------08FE81EC9991263692BFDA53" Content-Language: en-US This is a multi-part message in MIME format. --------------08FE81EC9991263692BFDA53 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Rich, all, I do really hope we will be able to provide some alternatives that might = work in different environments - I will try to make more formal=20 proposals soon for the charter items and milestones. Depending on which=20 direction the WG wants to go, I'd be happy to help with the=20 implementation in OpenSSL. We do have some sample code for OCSP over DNS = for our OCSP responder - it is just demo code (not even close to be=20 production ready :D) but it might be used as an example :D I think few optimizations might be low-hanging fruits (e.g.,=20 distribution of rev info via DNS, reducing the response size for=20 non-revoked entries) and some others might require more creative=20 thinking (e.g., cumulative responses for full-chain validation). These are just examples, and I am curious to know if there are other=20 possible proposals on the table... Cheers, Max On 7/31/17 10:27 AM, Salz, Rich wrote: > > I am also curious to see what concrete things could be done to improve = > revocation. If the answer is =93nothing=94 that=92s okay, but if it=92= s not,=20 > I expect OpenSSL will have to write some code J > > [...]=20 --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------08FE81EC9991263692BFDA53 Content-Type: multipart/related; boundary="------------470250C179369D2436CF7AC2" --------------470250C179369D2436CF7AC2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi Rich, all,

I do really hope we will be able to provide some alternatives that might work in different environments - I will try to make more formal proposals soon for the charter items and milestones. Depending on which direction the WG wants to go, I'd be happy to help with the implementation in OpenSSL. We do have some sample code for OCSP over DNS for our OCSP responder - it is just demo code (not even close to be production ready :D) but it might be used as an example :D

I think few optimizations might be low-hanging fruits (e.g., distribution of rev info via DNS, reducing the response size for non-revoked entries) and some others might require more creative thinking (e.g., cumulative responses for full-chain validation).

These are just examples, and I am curious to know if there are other possible proposals on the table...

Cheers,
Max


On 7/31/17 10:27 AM, Salz, Rich wrote:=

I am also curious to see what concrete things could be done to improve revocation.=A0 If the answer is =93nothing=94 that=92= s okay, but if it=92s not, I expect OpenSSL will have to write some code J

[...]

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--------------470250C179369D2436CF7AC2 Content-Type: image/png; name="ihalcodonpekknan.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ihalcodonpekknan.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------470250C179369D2436CF7AC2-- --------------08FE81EC9991263692BFDA53-- --------------ms060707010801010204020704 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfUwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU+MIIEJqADAgECAhEA/bu0LJsAKXVhEpPllE0lYzANBgkq hkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE2MTEzMDAwMDAwMFoXDTE3MTEzMDIzNTk1OVowJDEiMCAGCSqGSIb3DQEJ ARYTZGlyZWN0b3JAb3BlbmNhLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKnGg/GUuTjn0dKCEpRhVd+uiYbCjLQht+dbkvyRLm4aqlL7yHCe+21HQLIcU68ZCHT2ImpF CFFrxQMQh4KijAwkbLc8+xZZSwXeZt58qnPn5c4vcpYU5LFq1q9oDT8MXH33DhVUT/7/IDSi wRWM6FcgM6VrIjBmmvl9dW3gQaEd1bOAhO2X489fChRQYTaB6AEhqb8RSvWW7ZYzfNw8sPxV afMCzWBPpO5RmLqOciZBhAinAM9dXmP5ckg/HjJQYSjvTc7HDcg75mpr5wH8Tk/ChyIYk4CT zqONQV8HKCzZPTVmd2ZuMrliJwMFs3uEg0aBSzHjJTyAmZ89q5Mz3XsCAwEAAaOCAfEwggHt MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTGgh9JWBvcrak1 PhAWBLGrECNAjzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3Bl bmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAdIqtPcvA+g6VTYUpEo0I9Vtnrf9PiZ3OpkRL O7U78EaeUfvOotThqj74XyrIl6eYlg+EdGIIUVB1CI05wPMRlZN3/R/Tj28vWkwckLRIbpL4 A5ZQyKgA9vK15/EEBVFIpCtAI6xJX0zx6TySlIgjcca05L0JgO7nzLGD2MY/dVWEE+QBuNI+ NBci+c+9q6YDPoXOpo0Wwbe0Bq95jNNWmZwhGzc+N5rhOGZmQT4P7TnpzvMik8ugbkqWyyHa DQbLKYzM1RKS/mwcvFqjJCQgORnaCilSbfClwdWGI7vwcTR8eAzduvwG61u46Cgb57K5sMck RicpWRvEYxCCVTwnozGCBEQwggRAAgEBMIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCWCGSAFlAwQC AQUAoIICYzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4 MDExNTEyMDlaMC8GCSqGSIb3DQEJBDEiBCCWCvI3hwasfWbIi5h2phTOzpZBVnk1Msj8W0II Q38UUTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHCBgkrBgEEAYI3EAQxgbQwgbEwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAP27tCybACl1YRKT5ZRNJWMwgcQGCyqGSIb3DQEJ EAILMYG0oIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCSqGSIb3DQEBAQUABIIBAE55WSJMq8o/eD49 0IFcJBVKaqgZGZ7MSvYntltM1ojGjgWuzEVXnTndBbObsJZtsmIDxEbm2sMgaVlzwoVq8Rug 4JSNrBHpwJI//xP9/cHHpzxj0fJC1KTep78zfe9k2KPRw5gZCC5lVGBntmYG/SElgk9wLpxn 02LqJT3TFBwn2GbRm1QrFmv9N+TK000ZyYBcE5//Ju3ryhaWYZDIbsLg+yspoJNIRvT1Bq6k rhNR/GyEmROyOMANkfMAhkjDmj1nv+28m4pdFypFv89ibmAKEbNick+xNJFFHWTagmb+cK/O p+FGXQKxeLBgV4KgqcQ4sreZlQtHB45DPezES94AAAAAAAA= --------------ms060707010801010204020704-- From nobody Sun Aug 6 09:51:33 2017 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 72F82126B7E for ; Sun, 6 Aug 2017 09:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnR1zje-dOuO for ; Sun, 6 Aug 2017 09:51:28 -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 A80C0127B73 for ; Sun, 6 Aug 2017 09:51:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id AEDEA300526 for ; Sun, 6 Aug 2017 12:51:27 -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 KBRrfg1B8y7g for ; Sun, 6 Aug 2017 12:51:26 -0400 (EDT) Received: from [192.168.1.13] (75-139-107-240.dhcp.mant.nc.charter.com [75.139.107.240]) by mail.smeinc.net (Postfix) with ESMTPSA id 85D4D300455 for ; Sun, 6 Aug 2017 12:51:26 -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 10.3 \(3273\)) Message-Id: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> Date: Sun, 6 Aug 2017 12:51:24 -0400 To: spasm@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lamps] DRAFT LAMPS Recharter Text X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2017 16:51:30 -0000 At IETF 99, the LAMPS WG considered several potential recharter work = items. The attached draft is a result of that discussion. Please = review and comment. Russ =3D =3D =3D =3D =3D =3D =3D =3D The PKIX and S/MIME Working Groups have been closed for some time. Some updates have been proposed to the X.509 certificate documents produced=20= by the PKIX Working Group and the electronic mail security documents=20 produced by the S/MIME Working Group. The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working=20 Group is chartered to make updates where there is a known constituency=20= interested in real deployment and there is at least one sufficiently=20 well specified approach to the update so that the working group can=20 sensibly evaluate whether to adopt a proposal. Having completed the S/MIME 4.0 specifications and updates to support i18n email addresses in PKIX certificates, the LAMPS WG is now: 1. Specify a discovery mechanism for CAA records to replace the one described in RFC 6844. 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. RFC 6844 describes the mechanism by which CAA records relating to a domain are discovered. Implementation experience has demonstrated an ambiguity in the current processing of CNAME and DNAME records during discovery. Subsequent discussion has suggested that a different discovery approach would resolve limitations inherent in the current approach. Unlike the previous hashing standards, the SHA-3 functions are the outcome of an open competition. They have a clear design rationale and have received a lot of public analysis, resulting in great confidence that the SHA-3 family of functions are very secure. Also, since the design of the SHA-3 functions use a very different construction from the SHA-2 functions, they offer an excellent alternative to the SHA-2 family of functions. In particular, SHAKE128/256 and SHAKE256/512 offer security and performance benefits. In addition, the LAMPS Working Group may investigate other updates to=20 the documents produced by the PKIX and S/MIME Working Groups, but the=20 LAMPS Working Group shall not adopt any of these potential work items=20 without rechartering. MILESTONES Nov 2017: Adopt a draft for rfc6844bis Dec 2017: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512 Dec 2017: Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512 Apr 2018: rfc6844bis sent to IESG for standards track publication Sep 2018: SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for standards track publication Sep 2018: SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for standards track publication= From nobody Mon Aug 7 07:01:27 2017 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 A91E3132031 for ; Mon, 7 Aug 2017 07:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-6oinPqYq8g for ; Mon, 7 Aug 2017 07:01:24 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78470132225 for ; Mon, 7 Aug 2017 07:01:24 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v77Due1F003711; Mon, 7 Aug 2017 15:01:22 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=rQADs8P+2h2QTbw8SZlLdC5EkBxFX/rvL0DkbzO/naQ=; b=hBpCoN0S8/zdLrG6DcaV13Z0os+pE37n102rrMtt6OUKoNebr2ZMtUvMPJX89NcHlbhE 80ZrVpjvaC1ZLVpxmQKjc5CODD8sY3DF46Ya9qL7sgA0Z9neAsGzNRuh9MFm05aVepzf a9VYBHzqkyTEcqIhuw6/piDaVJifI+HWeOXC2VuPZ4sXBvatr+UQEdPECKZ3NorAWxIf TWsYXxKp52VmETO+oxw8fSC4bT0PHc+eChgUUC5y+am+MsavJbbAWBfL60Nm7VeJaOUs StRO5f8HYJKOSkYsCc56JwZd5K7GtPsi3VVajxL/+rlzrjNvpEHZJH3Csg0MaPEhGldR SA== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 2c533bubch-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Aug 2017 15:01:21 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v77E0nNn027946; Mon, 7 Aug 2017 10:01:21 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2c59bvmcs4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 07 Aug 2017 10:01:21 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 7 Aug 2017 10:00:51 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 7 Aug 2017 10:00:50 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 7 Aug 2017 10:00:50 -0400 From: "Salz, Rich" To: Russ Housley , "spasm@ietf.org" Thread-Topic: [lamps] DRAFT LAMPS Recharter Text Thread-Index: AQHTDtREV2uTgAmGC0Ci5Fyipv6dEKJ47V2Q Date: Mon, 7 Aug 2017 14:00:49 +0000 Message-ID: References: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> In-Reply-To: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.64] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-07_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708070235 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-07_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708070234 Archived-At: Subject: Re: [lamps] DRAFT LAMPS Recharter Text X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 14:01:26 -0000 LGTM although the dates seem the usual IETF optimistic :) Can add a recharter item to get the mailing list moved/renamed? From nobody Mon Aug 7 08:08:48 2017 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 B901513252B for ; Mon, 7 Aug 2017 08:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 mi7TyaDO9a1P for ; Mon, 7 Aug 2017 08:08:44 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 E658413251D for ; Mon, 7 Aug 2017 08:08:42 -0700 (PDT) Received: from [192.168.123.7] (unknown [76.90.60.238]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 05F62509B6 for ; Mon, 7 Aug 2017 11:08:41 -0400 (EDT) To: spasm@ietf.org References: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> From: Sean Leonard Message-ID: <35427a83-1956-b560-2f9a-50177f88d5fe@seantek.com> Date: Mon, 7 Aug 2017 08:09:28 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [lamps] DRAFT LAMPS Recharter Text X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 15:08:48 -0000 Reviewed. Comment: looks good. Sean On 8/6/2017 9:51 AM, Russ Housley wrote: > At IETF 99, the LAMPS WG considered several potential recharter work items. The attached draft is a result of that discussion. Please review and comment. > > Russ > > = = = = = = = = > > The PKIX and S/MIME Working Groups have been closed for some time. Some > updates have been proposed to the X.509 certificate documents produced > by the PKIX Working Group and the electronic mail security documents > produced by the S/MIME Working Group. > > The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working > Group is chartered to make updates where there is a known constituency > interested in real deployment and there is at least one sufficiently > well specified approach to the update so that the working group can > sensibly evaluate whether to adopt a proposal. > > Having completed the S/MIME 4.0 specifications and updates to support > i18n email addresses in PKIX certificates, the LAMPS WG is now: > > 1. Specify a discovery mechanism for CAA records to replace the one > described in RFC 6844. > > 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. > > RFC 6844 describes the mechanism by which CAA records relating to a > domain are discovered. Implementation experience has demonstrated an > ambiguity in the current processing of CNAME and DNAME records during > discovery. Subsequent discussion has suggested that a different > discovery approach would resolve limitations inherent in the current > approach. > > Unlike the previous hashing standards, the SHA-3 functions are the > outcome of an open competition. They have a clear design rationale and > have received a lot of public analysis, resulting in great confidence > that the SHA-3 family of functions are very secure. Also, since the > design of the SHA-3 functions use a very different construction from the > SHA-2 functions, they offer an excellent alternative to the SHA-2 family > of functions. In particular, SHAKE128/256 and SHAKE256/512 offer > security and performance benefits. > > In addition, the LAMPS Working Group may investigate other updates to > the documents produced by the PKIX and S/MIME Working Groups, but the > LAMPS Working Group shall not adopt any of these potential work items > without rechartering. > > MILESTONES > > Nov 2017: Adopt a draft for rfc6844bis > Dec 2017: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512 > Dec 2017: Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512 > Apr 2018: rfc6844bis sent to IESG for standards track publication > Sep 2018: SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for > standards track publication > Sep 2018: SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for > standards track publication > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Aug 7 08:09:50 2017 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 0D207131D34 for ; Mon, 7 Aug 2017 08:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 cDObMS6JW9CA for ; Mon, 7 Aug 2017 08:09:45 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 1AF6B131CEA for ; Mon, 7 Aug 2017 08:09:27 -0700 (PDT) Received: from [192.168.123.7] (unknown [76.90.60.238]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 50F0F509BE for ; Mon, 7 Aug 2017 11:09:26 -0400 (EDT) To: spasm@ietf.org References: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> From: Sean Leonard Message-ID: <86bd7642-6c7b-8127-44dc-f268789dc039@seantek.com> Date: Mon, 7 Aug 2017 08:10:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [lamps] DRAFT LAMPS Recharter Text X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 15:09:48 -0000 On 8/7/2017 7:00 AM, Salz, Rich wrote: > Can add a recharter item to get the mailing list moved/renamed? I also agree about getting the mailing list moved/renamed. Sean From nobody Mon Aug 7 14:00:36 2017 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 3AE96131CC2 for ; Mon, 7 Aug 2017 14:00:35 -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, HTML_MESSAGE=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 CIQ_YHwtGyEb for ; Mon, 7 Aug 2017 14:00:33 -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 6547F126B7E for ; Mon, 7 Aug 2017 14:00:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C46E2300557 for ; Mon, 7 Aug 2017 17:00:32 -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 FCvuK7D-2zq5 for ; Mon, 7 Aug 2017 17:00:27 -0400 (EDT) Received: from [192.168.1.9] (75-139-107-240.dhcp.mant.nc.charter.com [75.139.107.240]) by mail.smeinc.net (Postfix) with ESMTPSA id A0713300498; Mon, 7 Aug 2017 17:00:27 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0C762E01-376E-44B1-A35B-F3FECEA50BC2" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 7 Aug 2017 17:00:26 -0400 In-Reply-To: <86bd7642-6c7b-8127-44dc-f268789dc039@seantek.com> Cc: spasm@ietf.org To: Sean Leonard References: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> <86bd7642-6c7b-8127-44dc-f268789dc039@seantek.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] DRAFT LAMPS Recharter Text X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 21:00:35 -0000 --Apple-Mail=_0C762E01-376E-44B1-A35B-F3FECEA50BC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> Can add a recharter item to get the mailing list moved/renamed? >=20 > I also agree about getting the mailing list moved/renamed. This does not have anything to do with the charter. The previous AD felt that changing the name of the mail list was not = important. I do not know what the new AD thinks. Russ --Apple-Mail=_0C762E01-376E-44B1-A35B-F3FECEA50BC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Can add a recharter item to get the mailing list = moved/renamed?

I also agree about getting the = mailing list moved/renamed.

This does not have anything to do with the charter.

The previous AD felt = that changing the name of the mail list was not important.  I do = not know what the new AD thinks.

Russ

= --Apple-Mail=_0C762E01-376E-44B1-A35B-F3FECEA50BC2-- From nobody Mon Aug 7 14:05:08 2017 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 AAE90131D31 for ; Mon, 7 Aug 2017 14:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pG80MgdRrbZE for ; Mon, 7 Aug 2017 14:05:04 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 480A513202B for ; Mon, 7 Aug 2017 14:05:04 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v77L1isg031398; Mon, 7 Aug 2017 22:05:02 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=+PlcrapGT5EyWHkDhtVbg84uArd+ujYTABAkTUGUnfQ=; b=Cd+PvALUrBLVcYKPO679jky6LcxBYu3iSOyasmhTNLwmQhWqMOSROmBIwGKPYi539yUT deAHKhOF96iT1PfZu5F3VPv/TmIEeNXBB7/ZcjR1dPADo/o5n6mfk0w8Uz1Nzpr3rIA5 UZ0HVItL20a4dev/GNk/5S+9XRPBQ58QgkntQj6d76KoMM2NT3bailKd3DG0mROoDwAN yb+U7bGRMU9WhheBd+8IgJIHJldmlhHo1YPUxi03Rgfc+7fsdUyosqRkc+wo99qb+T9y voXRX4B/KjGTtH7s5UfKej+NfnmZwcwrGdX2EeWTbgi+hB7ce7W5axSVfE2VP7e47pfp uw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2c533bwrqt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Aug 2017 22:05:02 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v77L0ORQ008742; Mon, 7 Aug 2017 17:05:01 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2c59burc8w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 07 Aug 2017 17:05:01 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 7 Aug 2017 17:05:00 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 7 Aug 2017 17:05:00 -0400 From: "Salz, Rich" To: Russ Housley , Sean Leonard CC: "spasm@ietf.org" Thread-Topic: [lamps] DRAFT LAMPS Recharter Text Thread-Index: AQHTDtREV2uTgAmGC0Ci5Fyipv6dEKJ47V2QgABWkYCAAGHaAP//vc/w Date: Mon, 7 Aug 2017 21:04:59 +0000 Message-ID: <4e0425e3edcb48b084a8d902c9f1f15a@usma1ex-dag1mb1.msg.corp.akamai.com> References: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> <86bd7642-6c7b-8127-44dc-f268789dc039@seantek.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.51] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-07_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708070347 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-07_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708070348 Archived-At: Subject: Re: [lamps] DRAFT LAMPS Recharter Text X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 21:05:06 -0000 > This does not have anything to do with the charter. Hence the initial smiley. > The previous AD felt that changing the name of the mail list was not impo= rtant. =A0I do not know what the new AD thinks. If we changed the name because of sensitivity issues then we should change = the mailing list name because, in the IETF, WG's die but mailing lists neve= r do. And if there were other reasons, having the WG name and email name d= ifferent is jarring. Of course you know this :) From nobody Mon Aug 7 14:59:00 2017 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 E3A0B129ABE for ; Mon, 7 Aug 2017 14:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 Fqqon3bj-tke for ; Mon, 7 Aug 2017 14:58:57 -0700 (PDT) Received: from mail-vk0-x242.google.com (mail-vk0-x242.google.com [IPv6:2607:f8b0:400c:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF35F12741D for ; Mon, 7 Aug 2017 14:58:56 -0700 (PDT) Received: by mail-vk0-x242.google.com with SMTP id j189so819923vka.2 for ; Mon, 07 Aug 2017 14:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=qQWcx5yCipyi1Ky7AhlmnvYWuS3x0hO5MbVRrrX7tX0=; b=GeC3V5Ggr+IZykpjGUvQmfnHfWV7uW/XJ7oRxKWM5TGjo6rvLzTYnGd8+RH97m0atm LLYGg/IKh0PQ3WRDV4nQkT/lMW6KJrVvGIyAtG5ny2rJVBxBnoUT8m1LVFTpxzvbnHI4 j87vbY7G0BYbkNu8O6heMn8HfoTrafNwOz8KxLLR9iBGqIUyn66vWtOqF6I69cDgqwty g40c53uf0OhJV8Ipb49gLgrNmOMqrIaFp3xt5bnrm/ku05Y6Ys6bvd+auozsiOKV1gWm Tf7BmgO+vqJtQka+bsQMoLTvA7ckRuGc/XV9bDM0CB5Ac/ASVlhaG9roTsHNyQjBKMUC YzXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=qQWcx5yCipyi1Ky7AhlmnvYWuS3x0hO5MbVRrrX7tX0=; b=U2gJoruDXx+wpGfO64jL2XIpO1KZ7HV7EIdjLQIFI3J7nu5QBvzHkLarl5C34xnLG5 HEsx4WToipSKtzKLMU2CkVDLxqtFugR1BdE0GS1kpnYPthHR2bdM0CGtXpdsGaNz6Bta T1kgboQUT9mAs7cOGjpnm3PEdpjO1TjxGNWcEO5PqaSkIe0Q8YK0yP2he6w2PZkCHVXA DWx9iO7tT8w+CSoYFFyn5AQ4zKlKSWHOBnbP9bW7plnbOFghHlw2jMs+d/gOePUpzOhA p3TZjzFkzDkYhu2IEmu0M7oTFaa6fk1E1kYxJ2nrek05HoSJjPoO+D5S+M0C1aoH2xHF B2wg== X-Gm-Message-State: AHYfb5jHvI5/OVeBU/uomy9CsWagyhn06/Kv0zCDHh09IFiehOLBxVJh XmREGkj778FtG3Wq/WI= X-Received: by 10.80.226.205 with SMTP id q13mr2145763edl.49.1502143136095; Mon, 07 Aug 2017 14:58:56 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id n12sm65335edd.4.2017.08.07.14.58.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 14:58:55 -0700 (PDT) From: Yoav Nir Message-Id: <724C8D38-6016-4941-A0F6-9055DEDD6F68@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_01493640-0D80-4543-A21A-749C1AC23FC7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 8 Aug 2017 00:58:53 +0300 In-Reply-To: <4e0425e3edcb48b084a8d902c9f1f15a@usma1ex-dag1mb1.msg.corp.akamai.com> Cc: Russ Housley , Sean Leonard , "spasm@ietf.org" To: Rich Salz References: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> <86bd7642-6c7b-8127-44dc-f268789dc039@seantek.com> <4e0425e3edcb48b084a8d902c9f1f15a@usma1ex-dag1mb1.msg.corp.akamai.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] DRAFT LAMPS Recharter Text X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 21:58:59 -0000 --Apple-Mail=_01493640-0D80-4543-A21A-749C1AC23FC7 Content-Type: multipart/alternative; boundary="Apple-Mail=_D10BC092-E5D5-4DE6-9477-2208DCE6C8BA" --Apple-Mail=_D10BC092-E5D5-4DE6-9477-2208DCE6C8BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 8 Aug 2017, at 0:04, Salz, Rich wrote: >=20 >> This does not have anything to do with the charter. >=20 > Hence the initial smiley. >=20 >> The previous AD felt that changing the name of the mail list was not = important. I do not know what the new AD thinks. >=20 > If we changed the name because of sensitivity issues then we should = change the mailing list name because, in the IETF, WG's die but mailing = lists never do. And if there were other reasons, having the WG name and = email name different is jarring. Perhaps, but changing the group name is just a little administrative = work. Changing the mailing list is disruptive. What happens if a message = is sent tot spasm@? If it gets delivered, we haven=E2=80=99t really = changed the name, just created an alias. If it causes a reject, it = causes a disruption (and not the good kind) to all participants. On the bright side only a few mailing lists are really forever. Years = from now, when lamps and curdle have closed, nobody is going to use = these lists. They will still use pkix@ietf.org , = but not these two. It=E2=80=99s the same way that if anyone wants to = talk about web security at the IETF, they=E2=80=99re going to SAAG, not = websec@ and not httpauth@. I should know. These lists have been dead = since the respective working groups have closed. Yoav --Apple-Mail=_D10BC092-E5D5-4DE6-9477-2208DCE6C8BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 8 Aug 2017, at 0:04, Salz, Rich <rsalz@akamai.com> = wrote:

This does not have = anything to do with the charter.

Hence the initial smiley.

The previous AD felt = that changing the name of the mail list was not important.  I do = not know what the new AD thinks.

If we changed the name because of sensitivity issues then we = should change the mailing list name because, in the IETF, WG's die but = mailing lists never do.  And if there were other reasons, having = the WG name and email name different is jarring.

Perhaps, but changing the group name is just a = little administrative work. Changing the mailing list is disruptive. = What happens if a message is sent tot spasm@?  If it gets = delivered, we haven=E2=80=99t really changed the name, just created an = alias. If it causes a reject, it causes a disruption (and not the good = kind) to all participants. 

On the bright side only a few mailing lists are really = forever. Years from now, when lamps and curdle have closed, nobody is = going to use these lists. They will still use pkix@ietf.org, but not = these two.  It=E2=80=99s the same way that if anyone wants to talk = about web security at the IETF, they=E2=80=99re going to SAAG, not = websec@ and not httpauth@.  I should know. These lists have been = dead since the respective working groups have closed.

Yoav
= --Apple-Mail=_D10BC092-E5D5-4DE6-9477-2208DCE6C8BA-- --Apple-Mail=_01493640-0D80-4543-A21A-749C1AC23FC7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZiOKdAAoJELhJCxUKWMyZbnMIAJcp5bRL3NZunK29picd86rt RdSfQLLzKLke2t6cC3hwxD8oG2Myccv6k04nltaE6yw6paOEU7VxL9hzAfdFuRhb 6P5kkgATTEUyMJ8n62m2wfzOCRu9PwWGr2cyT6XbBw0LY7s+9f2vz4VXI1dI6fpV PHaJR8uTHsRjWXvN4IOSZHc2I4PWxXra7gvWnQdWK/WQvs0ShsN+kYg9C47AAWdn 3RILebJt3iXug0GCeduXtJuemRzXFg6iU6CMdWIEGwF+LuZz8E7ckOCEpBzIrG7B MBzn3Hps8DqXtL4U8t8XyRAUMLFvHvUSZ+t6DSEm8FTt1LpqwuobNAXt+cQ7fGY= =6R+H -----END PGP SIGNATURE----- --Apple-Mail=_01493640-0D80-4543-A21A-749C1AC23FC7-- From nobody Tue Aug 8 11:14:52 2017 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 607E8132A65; Tue, 8 Aug 2017 11:14:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Mahesh Jethanandani To: Cc: draft-ietf-lamps-rfc5280-i18n-update.all@ietf.org, spasm@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150221609128.12407.7360399856163460147@ietfa.amsl.com> Date: Tue, 08 Aug 2017 11:14:51 -0700 Archived-At: Subject: [lamps] Opsdir last call review of draft-ietf-lamps-rfc5280-i18n-update-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 18:14:51 -0000 Reviewer: Mahesh Jethanandani Review result: Ready I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments. Summary: The document provides updates to RFC 5280 providing clarity on the handling of Internationalized Domain Names (IDNs) and Internationalized Email Addresses in X.509 Certificates. Comments: The document provides clarifications on the handling of Internationalized Domain Names (IDNs) and Internationalized Email Addresses in X.509 Certificates. As such it has no operational or management impact. From nobody Sat Aug 12 13:18:46 2017 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 5FFFB124217 for ; Sat, 12 Aug 2017 13:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcKfpv_-vdL0 for ; Sat, 12 Aug 2017 13:18:43 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4606E12778D for ; Sat, 12 Aug 2017 13:18:43 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id i66so15844176wmg.0 for ; Sat, 12 Aug 2017 13:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MrZoOaSAVMkvRzO6Nsd6z+Qupu5CoYhXrpjBFnecBv0=; b=KHEA5+Hlmv4y2QisPrORuisyvysB5bpdmRK7rfjcDysP5YzKZ9sFA2AuFZLJV8SB6L Sr8otd8sfDVDPoTRlGgl2u3aZU3glXL3qcs6hGMeM+2hUS2CzHvaj/gix/BQwVFN6yGW Ej4PP5Ji1liCgFEiqzyEoHgo8tB/UCSOEAfYeIF7xkQGcBMwAb96TjkkWB9hKD1klzAL ZoAK4bgMuK1o29S74z+MeI8didDhc8PDZEBuBnDR+YcMR51RuQzCz0+oClEnGwBaMhA3 jya2/OEt3176O15m/gdSiqjGO3JCjZPMey0/tP+WEf/ZdbhC8J0eLoxTCQ37TaXoBUBC COeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MrZoOaSAVMkvRzO6Nsd6z+Qupu5CoYhXrpjBFnecBv0=; b=LzHl+zWnX5qrtDOnDHKH9QsrxHIMiyHNr0y7BYBn/hf6s3RrZLEcUcPtw+lTpvsTxL BpG1ZPS8ubl8fmNgpTmEwjzxpTr98yPv6WSGAoYQDnwjvBSCyf/MTTBKzY22bacYcQ8r UCj5aT7ud0hX9VoLsXi0tB+Y++QdxzXxnF5uMcNLqpDvmwA7OG60XzcO9nE4QJaJw7rH +4cmbMJqxjWRSeB682QiZAB0SbYVnU4bKz2Dw6yCfqMY011CHWiutMo6K74FMVYdTmbF PFT145kZy381kW3OVw87iiL4AGqbetiKXGBcItiNLPOQob5lRXmpBYSG21koLJXqAazv FE6Q== X-Gm-Message-State: AHYfb5hKaKbVLcrbKYBpQI2VT7nw6pH+hNJP5TSo6o1IdjneUh2uHDMd 9j6dsuUiEWLKORxLxDTnWFUxQjWzcw== X-Received: by 10.80.176.68 with SMTP id i62mr19753560edd.147.1502569121649; Sat, 12 Aug 2017 13:18:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.143.3 with HTTP; Sat, 12 Aug 2017 13:18:41 -0700 (PDT) In-Reply-To: <7e290f82-2b2b-44ac-d976-d94064f3d90b@openca.org> References: <04e73e42-7c5b-912d-cc79-7959a710927e@openca.org> <0a12992260ec44ebab8cff0426670cc8@usma1ex-dag1mb1.msg.corp.akamai.com> <7e290f82-2b2b-44ac-d976-d94064f3d90b@openca.org> From: Dmitry Belyavsky Date: Sat, 12 Aug 2017 23:18:41 +0300 Message-ID: To: "Dr. Pala" Cc: "Salz, Rich" , "Dang, Quynh (Fed)" , Russ Housley , LAMPS Content-Type: multipart/alternative; boundary="f403045c853ebf17a00556942294" Archived-At: Subject: Re: [lamps] Considerations about the need to resume PKIX work X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 12 Aug 2017 20:18:45 -0000 --f403045c853ebf17a00556942294 Content-Type: text/plain; charset="UTF-8" Hello, On Tue, Aug 1, 2017 at 6:12 PM, Dr. Pala wrote: > Hi Rich, all, > > I do really hope we will be able to provide some alternatives that might > work in different environments - I will try to make more formal proposals > soon for the charter items and milestones. Depending on which direction the > WG wants to go, I'd be happy to help with the implementation in OpenSSL. We > do have some sample code for OCSP over DNS for our OCSP responder - it is > just demo code (not even close to be production ready :D) but it might be > used as an example :D > > I think few optimizations might be low-hanging fruits (e.g., distribution > of rev info via DNS, reducing the response size for non-revoked entries) > and some others might require more creative thinking (e.g., cumulative > responses for full-chain validation). > > These are just examples, and I am curious to know if there are other > possible proposals on the table... > I would like to remind about my draft describing application-level revocation. Thank you! -- SY, Dmitry Belyavsky --f403045c853ebf17a00556942294 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,=C2=A0

On Tue, Aug 1, 2017 at 6:12 PM, Dr. Pala <= director@openca.or= g> wrote:
=20 =20 =20

Hi Rich, all,

I do really hope we will be able to provide some alternatives that might work in different environments - I will try to make more formal proposals soon for the charter items and milestones. Depending on which direction the WG wants to go, I'd be happy to help with the implementation in OpenSSL. We do have some sample code for OCSP over DNS for our OCSP responder - it is just demo code (not even close to be production ready :D) but it might be used as an example :D

I think few optimizations might be low-hanging fruits (e.g., distribution of rev info via DNS, reducing the response size for non-revoked entries) and some others might require more creative thinking (e.g., cumulative responses for full-chain validation).

These are just examples, and I am curious to know if there are other possible proposals on the table...


I would like to remind about my draft describing applicat= ion-level revocation.
=C2=A0
Thank you!

--
SY, Dmitry Belyavsky
--f403045c853ebf17a00556942294-- From nobody Sun Aug 13 00:38:31 2017 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 DB4B0132723 for ; Sun, 13 Aug 2017 00:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1cV4DGEGsys for ; Sun, 13 Aug 2017 00:38:28 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 DAD72132380 for ; Sun, 13 Aug 2017 00:38:27 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id i66so21359986wmg.0 for ; Sun, 13 Aug 2017 00:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+Nvm/iUwVko+T5d6DeZfH7fK4585nxgmpb57Xll5OsA=; b=hvj9BuSO05MtJZCC7ejC4iQuVg1ODIP9A6UQZ47lQ/l1hCqqlZbQxVw/MfWRuqWxGY HSovx/fpRm6LJtikknIPGRBnYJJOJNwMCyZ8PL1Z/Gy31fnepPsTwcdaQ2BHvtd10SwB 0SsDWCHFUeYgifQubQoJmG9CKZEiK9LmbZliyErmAbZSojjyTDHCKtuerr4a9Yfrh3ZA pq8U6rgYXGiNy+sxulFX+8yEvLnao6j6bUWSnKPfjjkl0PG4+lhY+gehTc6H+0g8kiyQ Ro/BILi61UIm5+NosCSWkbc4na1LFE0T1sO7Gib5wX/O1jRCOjYAfqIrISaRTQGdc5ap esLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+Nvm/iUwVko+T5d6DeZfH7fK4585nxgmpb57Xll5OsA=; b=NVsQ25C/nrL0V+OLt4NkIDiYllovqLokdsP/w5dI9Rjo5r9EH87hDonzIDWH8kjQgw Rw0sz5qiCs7sdlF5o1ddqfKjiC9C6SBdbY8ov4Q2+MNPo1j1qDDMp1tQNzEA7ge1Vgjr uB5o5mt0fVsOL0AGJQZfLIIggZ0H6Vi6yPocMcYNyvf+EDHZEftXHV7P3l5c8KrjzOcq izMyr1n5U8/6KoyfBKU6IZPFPsjJ/KRvtskFCogvULgqC63XFh8Hx1hI/hF7H5a4U/ov ejP4wyqzWdMBwWKXEvdiEe4maJbgLlsr+Tpn9Fu2CXg76Pzyb0bgoaZ8NBK6s4EsjVaR sBaQ== X-Gm-Message-State: AHYfb5jEA23aevNokkkf7DHX7h89mfhTsnHG0xKBEhxMI6eLhosboVko ItI+fUGuAEHUw+GVQwXLZ1kWR61wzw== X-Received: by 10.80.147.134 with SMTP id o6mr21836601eda.102.1502609906403; Sun, 13 Aug 2017 00:38:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.143.3 with HTTP; Sun, 13 Aug 2017 00:38:25 -0700 (PDT) In-Reply-To: References: <04e73e42-7c5b-912d-cc79-7959a710927e@openca.org> <0a12992260ec44ebab8cff0426670cc8@usma1ex-dag1mb1.msg.corp.akamai.com> <7e290f82-2b2b-44ac-d976-d94064f3d90b@openca.org> From: Dmitry Belyavsky Date: Sun, 13 Aug 2017 10:38:25 +0300 Message-ID: To: "Dr. Pala" Cc: "Salz, Rich" , "Dang, Quynh (Fed)" , Russ Housley , LAMPS Content-Type: multipart/alternative; boundary="f403045c81ecb50f2405569da18a" Archived-At: Subject: Re: [lamps] Considerations about the need to resume PKIX work X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 13 Aug 2017 07:38:30 -0000 --f403045c81ecb50f2405569da18a Content-Type: text/plain; charset="UTF-8" Hello, On Sat, Aug 12, 2017 at 11:18 PM, Dmitry Belyavsky wrote: > Hello, > > On Tue, Aug 1, 2017 at 6:12 PM, Dr. Pala wrote: > >> Hi Rich, all, >> >> I do really hope we will be able to provide some alternatives that might >> work in different environments - I will try to make more formal proposals >> soon for the charter items and milestones. Depending on which direction the >> WG wants to go, I'd be happy to help with the implementation in OpenSSL. We >> do have some sample code for OCSP over DNS for our OCSP responder - it is >> just demo code (not even close to be production ready :D) but it might be >> used as an example :D >> >> I think few optimizations might be low-hanging fruits (e.g., distribution >> of rev info via DNS, reducing the response size for non-revoked entries) >> and some others might require more creative thinking (e.g., cumulative >> responses for full-chain validation). >> >> These are just examples, and I am curious to know if there are other >> possible proposals on the table... >> > > I would like to remind about my draft describing application-level > revocation. > Just to clarify. My draft describes practice that already is in use in browsers. Now the limitations and partial revocations are hard coded, I suggest a way to make them alienable. -- SY, Dmitry Belyavsky --f403045c81ecb50f2405569da18a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

On Sat, Aug 12, 2017 at 11:18 PM, Dmitry Belyavsky = <beldmit@gmail.co= m> wrote:
Hello,=C2=A0

On Tue, Aug 1, 2017 at 6:12 PM, Dr. Pa= la <director@openca.org> wrote:
=20 =20 =20

Hi Rich, all,

I do really hope we will be able to provide some alternatives that might work in different environments - I will try to make more formal proposals soon for the charter items and milestones. Depending on which direction the WG wants to go, I'd be happy to help with the implementation in OpenSSL. We do have some sample code for OCSP over DNS for our OCSP responder - it is just demo code (not even close to be production ready :D) but it might be used as an example :D

I think few optimizations might be low-hanging fruits (e.g., distribution of rev info via DNS, reducing the response size for non-revoked entries) and some others might require more creative thinking (e.g., cumulative responses for full-chain validation).

These are just examples, and I am curious to know if there are other possible proposals on the table...


I would like to remind about my draft describing a= pplication-level revocation.

<= /div>
Just to clarify. My draft describes practice that already is in u= se in browsers. Now the limitations and partial revocations are hard coded,= I suggest a way to make them alienable.=C2=A0


--
SY, Dmitry Belyavsky<= /div>
--f403045c81ecb50f2405569da18a-- From nobody Mon Aug 14 07:12:54 2017 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 D4BCE132055 for ; Mon, 14 Aug 2017 07:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8lzQ4oBbk9e for ; Mon, 14 Aug 2017 07:12:49 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503231321ED for ; Mon, 14 Aug 2017 07:12:49 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id t201so38431802wmt.1 for ; Mon, 14 Aug 2017 07:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z/cEHwWFtsS7VBP8d9+co8eTo4HxxGPN0UAliMI8CwM=; b=tRTlidHLKMR8geix1qvh25s1DkY8YYOqozFwOn0c1GYMJoNRCYr2XPKZUrmMlyKkTf LZnkctHQHi+MiZw11uX6Z3ahHIna4CIPq9yslNDqzw8x/pevQuSlqJ922Yguto5+XuQJ 14nHKs7VcgAUvTYSvCNjTstrksOHwTaSoKeesNClAZqx19ErVBK/bK0wCeha/Q/UFHzY XE12yR/lW5KeM9q3Dkv+T84xYqyGd2R+fLygyaz5UbYis+GBLtWVbx/4emYJKvZ90VgQ YJHas8GwhqyPCoSHV+Naa4uOnL+DVmvBDTU1ae4ssaGTUyvUohQb497bJx5blrzA7PAI PH8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Z/cEHwWFtsS7VBP8d9+co8eTo4HxxGPN0UAliMI8CwM=; b=DxloauESvAAAdIqnvm6lE80ySPHkMdQovDeuy4fNngHhvtbZcDaPVv6AFj9E4dQ4Qu 1o7B9KRyEsZGx5pSUXfOtHYB8hG2GVHLFoaSUoeyumzvFKoCRsNUOxUE5k3TfY6omF5p pYlaJ2qscyGFsCzioDsROL3fZJuJds3Sqp3krIkM318p4bw7ATUwsKSfWrHxRETmSYaM HvXsrU3hqDuEjGvypFKE2HPMw2PZgCZ/LoIJDi1dqu8M2ZQBt6U4xtm3PSlZCbpA1hoa lwJEmpON5gFpL+LYfv3wS41NLKIrHl+lsyIyGU5mbeWgpH5vNp3hKdjKkqkLXHWd5aGn gk4A== X-Gm-Message-State: AHYfb5i0siGTMxNPDb8r1rj9Bj/UPYboko/4an3XTbVFNRkGESsEFfaD ieOECc/ZybkxWAWOrJwoQH5z69zuH0vi X-Received: by 10.80.176.68 with SMTP id i62mr24479695edd.147.1502719967837; Mon, 14 Aug 2017 07:12:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.143.3 with HTTP; Mon, 14 Aug 2017 07:12:47 -0700 (PDT) In-Reply-To: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> References: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> From: Dmitry Belyavsky Date: Mon, 14 Aug 2017 17:12:47 +0300 Message-ID: To: Russ Housley Cc: LAMPS Content-Type: multipart/alternative; boundary="f403045c853ee1409e0556b74162" Archived-At: Subject: Re: [lamps] DRAFT LAMPS Recharter Text X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 14:12:53 -0000 --f403045c853ee1409e0556b74162 Content-Type: text/plain; charset="UTF-8" Hello, On Sun, Aug 6, 2017 at 7:51 PM, Russ Housley wrote: > At IETF 99, the LAMPS WG considered several potential recharter work > items. The attached draft is a result of that discussion. Please review > and comment. > > Russ > > = = = = = = = = > > The PKIX and S/MIME Working Groups have been closed for some time. Some > updates have been proposed to the X.509 certificate documents produced > by the PKIX Working Group and the electronic mail security documents > produced by the S/MIME Working Group. > > The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working > Group is chartered to make updates where there is a known constituency > interested in real deployment and there is at least one sufficiently > well specified approach to the update so that the working group can > sensibly evaluate whether to adopt a proposal. > > Having completed the S/MIME 4.0 specifications and updates to support > i18n email addresses in PKIX certificates, the LAMPS WG is now: > > 1. Specify a discovery mechanism for CAA records to replace the one > described in RFC 6844. > > 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. > > RFC 6844 describes the mechanism by which CAA records relating to a > domain are discovered. Implementation experience has demonstrated an > ambiguity in the current processing of CNAME and DNAME records during > discovery. Subsequent discussion has suggested that a different > discovery approach would resolve limitations inherent in the current > approach. > > Unlike the previous hashing standards, the SHA-3 functions are the > outcome of an open competition. They have a clear design rationale and > have received a lot of public analysis, resulting in great confidence > that the SHA-3 family of functions are very secure. Also, since the > design of the SHA-3 functions use a very different construction from the > SHA-2 functions, they offer an excellent alternative to the SHA-2 family > of functions. In particular, SHAKE128/256 and SHAKE256/512 offer > security and performance benefits. > > In addition, the LAMPS Working Group may investigate other updates to > the documents produced by the PKIX and S/MIME Working Groups, but the > LAMPS Working Group shall not adopt any of these potential work items > without rechartering. > > MILESTONES > > Nov 2017: Adopt a draft for rfc6844bis > Dec 2017: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512 > Dec 2017: Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512 > Apr 2018: rfc6844bis sent to IESG for standards track publication > Sep 2018: SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for > standards track publication > Sep 2018: SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for > standards track publication > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > I suggest to add one more item to the charter: =============== 3. Specify a mechanism/language describing the application-level limitations to certificate trust. There are a lot of limitations applied to the trust model specified by the RFC 5280 by browsers, see for example https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/--aa6dYHhrc/xbozEdS2BgAJ This limitations distributed in well-documented alienable format can be used by various applications, such as MTAs and browsers, and improve the overall security of PKI infrastracture. ================ Thank you! -- SY, Dmitry Belyavsky --f403045c853ee1409e0556b74162 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,=C2=A0

On Sun, Aug 6, 2017 at 7:51 PM, Russ Housley = <housley@vigil= sec.com> wrote:
At IETF 99, the LAMPS WG considered several potential recharter wor= k items.=C2=A0 The attached draft is a result of that discussion.=C2=A0 Ple= ase review and comment.

Russ

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

The PKIX and S/MIME Working Groups have been closed for some time. Some
updates have been proposed to the X.509 certificate documents produced
by the PKIX Working Group and the electronic mail security documents
produced by the S/MIME Working Group.

The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working
Group is chartered to make updates where there is a known constituency
interested in real deployment and there is at least one sufficiently
well specified approach to the update so that the working group can
sensibly evaluate whether to adopt a proposal.

Having completed the S/MIME 4.0 specifications and updates to support
i18n email addresses in PKIX certificates, the LAMPS WG is now:

1. Specify a discovery mechanism for CAA records to replace the one
=C2=A0 =C2=A0described in RFC 6844.

2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME.
RFC 6844 describes the mechanism by which CAA records relating to a
domain are discovered.=C2=A0 Implementation experience has demonstrated an<= br> ambiguity in the current processing of CNAME and DNAME records during
discovery.=C2=A0 Subsequent discussion has suggested that a different
discovery approach would resolve limitations inherent in the current
approach.

Unlike the previous hashing standards, the SHA-3 functions are the
outcome of an open competition.=C2=A0 They have a clear design rationale an= d
have received a lot of public analysis, resulting in great confidence
that the SHA-3 family of functions are very secure.=C2=A0 Also, since the design of the SHA-3 functions use a very different construction from the SHA-2 functions, they offer an excellent alternative to the SHA-2 family of functions.=C2=A0 In particular, SHAKE128/256 and SHAKE256/512 offer
security and performance benefits.

In addition, the LAMPS Working Group may investigate other updates to
the documents produced by the PKIX and S/MIME Working Groups, but the
LAMPS Working Group shall not adopt any of these potential work items
without rechartering.

MILESTONES

Nov 2017: Adopt a draft for rfc6844bis
Dec 2017: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512
Dec 2017: Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512
Apr 2018: rfc6844bis sent to IESG for standards track publication
Sep 2018: SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0standards track publication=
Sep 2018: SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0standards track publication=
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

I suggest to add one more item to the charter:
=

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
3. Spe= cify a mechanism/language describing the application-level limitations to c= ertificate trust.

There are a lot of limitations applied to the trust model speci= fied by the RFC 5280 by browsers,=C2=A0
see= for example=C2=A0https://groups.google.com/for= um/#!msg/mozilla.dev.security.policy/--aa6dYHhrc/xbozEdS2BgAJ
This limitations distributed in well-documented alie= nable format can be used by various applications,=C2=A0
such as MTAs and browsers, and improve the overall security of= PKI infrastracture.
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

Thank you!

--
SY, Dmitry Belyavsky=
--f403045c853ee1409e0556b74162-- From nobody Mon Aug 14 11:26:43 2017 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 4EBF51323CA; Mon, 14 Aug 2017 11:26:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: spasm@ietf.org, lamps-chairs@ietf.org, ekr@rtfm.com, housley@vigilsec.com X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150273520131.470.9659992748974621510.idtracker@ietfa.amsl.com> Date: Mon, 14 Aug 2017 11:26:41 -0700 Archived-At: Subject: [lamps] lamps - New Meeting Session Request for IETF 100 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 18:26:41 -0000 A new meeting session request has just been submitted by Russ Housley, a Chair of the lamps working group. --------------------------------------------------------- Working Group Name: Limited Additional Mechanisms for PKIX and SMIME Area Name: Security Area Session Requester: Russ Housley Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: rtcweb ace acme openpgp stir fud ipwave tls sipbrandy sidrops saag perc quic curdle Second Priority: cfrg dprive ecrit oauth sacm mile modern radext Third Priority: mtgvenue iasa20 People who must be present: Russ Housley Eric Rescorla Sean Turner Jim Schaad Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Aug 17 05:40:33 2017 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 554E31323C6 for ; Thu, 17 Aug 2017 05:40:32 -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, 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 6varhhAs9kN4 for ; Thu, 17 Aug 2017 05:40:30 -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 00B94132391 for ; Thu, 17 Aug 2017 05:40:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 50CEC300526 for ; Thu, 17 Aug 2017 08:40:29 -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 OtENL3JUfvCk for ; Thu, 17 Aug 2017 08:40:27 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id E1A54300295 for ; Thu, 17 Aug 2017 08:40:27 -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 10.3 \(3273\)) Date: Thu, 17 Aug 2017 08:40:27 -0400 References: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> To: spasm@ietf.org In-Reply-To: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> Message-Id: <02CCCC92-7487-444A-A14A-0CC0D4118104@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] DRAFT LAMPS Recharter Text X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 12:40:32 -0000 I have seen people voice support for the two work items listed in the = draft charter text. I have seen Max and Dmitry offer additional work = items, but there has been almost no discussion of their suggestions. = Without active support, the suggested items will not be added. Russ > On Aug 6, 2017, at 12:51 PM, Russ Housley = wrote: >=20 > At IETF 99, the LAMPS WG considered several potential recharter work = items. The attached draft is a result of that discussion. Please = review and comment. >=20 > Russ >=20 > =3D =3D =3D =3D =3D =3D =3D =3D >=20 > The PKIX and S/MIME Working Groups have been closed for some time. = Some > updates have been proposed to the X.509 certificate documents produced=20= > by the PKIX Working Group and the electronic mail security documents=20= > produced by the S/MIME Working Group. >=20 > The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working=20= > Group is chartered to make updates where there is a known constituency=20= > interested in real deployment and there is at least one sufficiently=20= > well specified approach to the update so that the working group can=20 > sensibly evaluate whether to adopt a proposal. >=20 > Having completed the S/MIME 4.0 specifications and updates to support > i18n email addresses in PKIX certificates, the LAMPS WG is now: >=20 > 1. Specify a discovery mechanism for CAA records to replace the one > described in RFC 6844. >=20 > 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and = S/MIME. >=20 > RFC 6844 describes the mechanism by which CAA records relating to a > domain are discovered. Implementation experience has demonstrated an > ambiguity in the current processing of CNAME and DNAME records during > discovery. Subsequent discussion has suggested that a different > discovery approach would resolve limitations inherent in the current > approach. >=20 > Unlike the previous hashing standards, the SHA-3 functions are the > outcome of an open competition. They have a clear design rationale = and > have received a lot of public analysis, resulting in great confidence > that the SHA-3 family of functions are very secure. Also, since the > design of the SHA-3 functions use a very different construction from = the > SHA-2 functions, they offer an excellent alternative to the SHA-2 = family > of functions. In particular, SHAKE128/256 and SHAKE256/512 offer > security and performance benefits. >=20 > In addition, the LAMPS Working Group may investigate other updates to=20= > the documents produced by the PKIX and S/MIME Working Groups, but the=20= > LAMPS Working Group shall not adopt any of these potential work items=20= > without rechartering. >=20 > MILESTONES >=20 > Nov 2017: Adopt a draft for rfc6844bis > Dec 2017: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512 > Dec 2017: Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512 > Apr 2018: rfc6844bis sent to IESG for standards track publication > Sep 2018: SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for > standards track publication > Sep 2018: SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for > standards track publication > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Fri Aug 18 07:02:50 2017 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 D3ABE1323C9 for ; Fri, 18 Aug 2017 07:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bFzOtu4Q7Nb for ; Fri, 18 Aug 2017 07:02:42 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82BF8132402 for ; Fri, 18 Aug 2017 07:02:39 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id e124so97482358oig.2 for ; Fri, 18 Aug 2017 07:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lwqpSC3w4xEE7y9wSeCyLcCikrmmzj81RW2FAPFPn7Y=; b=VfK0CSBhZ4DxPfArYF1/ukbNTIPOGMn8IX9BFXZiBN8RlLhOJXA3W7MxWgX+EHYRk9 scWaWlGUIa2Xa1Sitbx2W7VtK0q9uKUc/oS/IyyiuDyX0ctakMF/g59fUD+yRguZqJnn c6XftiNcqljRFj6L8vS5WrYA+m2/rJ6aKS1X8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lwqpSC3w4xEE7y9wSeCyLcCikrmmzj81RW2FAPFPn7Y=; b=GRyhO1BuPSaXPT/emXELITy94NjMSX1jUrWL9v4B9AGnWU+ScpojwJRRznerY9GeSp 29Sb+vT3MGxC+sCHIpff/UiiP97ZVfhNH0h80rLxoNg2ge+jzdYKKdgdtcvvcn7Bm08k w2H4IESAHFMM0MCvNwP4IwIWzwMKIquNPjW5hgtdh4pFuCD5HA/PVo56QtyASE1d99fD xaUfJ8l4OVsMC7vbFa5oa8HR03AT9AoAl2OEt1VFRZkO5tMhraq/6eZ6n2A4ZtjwQpOb NJQncMrxonWUO0noBq9haz5s0Pn+rit706KPbvCfHclTe0GII3iUvy+6XMavZSrr+upW 8yIw== X-Gm-Message-State: AHYfb5hDyZ9MfvavGQL1sWDV5dHSEMTSV1nkZqbKIchS3QgmEj8ipSFr YAJAe1l5VHpZijOoJzQb8A== X-Received: by 10.202.80.143 with SMTP id e137mr763073oib.293.1503064958091; Fri, 18 Aug 2017 07:02:38 -0700 (PDT) Received: from [10.175.17.100] (mobile-166-177-121-152.mycingular.net. [166.177.121.152]) by smtp.gmail.com with ESMTPSA id t76sm7734283oit.5.2017.08.18.07.02.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Aug 2017 07:02:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Sean Turner X-Mailer: iPhone Mail (14G60) In-Reply-To: <02CCCC92-7487-444A-A14A-0CC0D4118104@vigilsec.com> Date: Fri, 18 Aug 2017 09:02:35 -0500 Cc: spasm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> <02CCCC92-7487-444A-A14A-0CC0D4118104@vigilsec.com> To: Russ Housley Archived-At: Subject: Re: [lamps] DRAFT LAMPS Recharter Text X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 14:02:48 -0000 I think it makes sense to do byte sized pieces of work to make sure we get '= em done. Let's focus on the two listed(I.e., remember the limited part of o= ur charter and then circle back. spt Sent from my iPhone > On Aug 17, 2017, at 07:40, Russ Housley wrote: >=20 > I have seen people voice support for the two work items listed in the draf= t charter text. I have seen Max and Dmitry offer additional work items, but= there has been almost no discussion of their suggestions. Without active s= upport, the suggested items will not be added. >=20 > Russ >=20 >=20 >> On Aug 6, 2017, at 12:51 PM, Russ Housley wrote: >>=20 >> At IETF 99, the LAMPS WG considered several potential recharter work item= s. The attached draft is a result of that discussion. Please review and co= mment. >>=20 >> Russ >>=20 >> =3D =3D =3D =3D =3D =3D =3D =3D >>=20 >> The PKIX and S/MIME Working Groups have been closed for some time. Some >> updates have been proposed to the X.509 certificate documents produced=20= >> by the PKIX Working Group and the electronic mail security documents=20 >> produced by the S/MIME Working Group. >>=20 >> The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working=20 >> Group is chartered to make updates where there is a known constituency=20= >> interested in real deployment and there is at least one sufficiently=20 >> well specified approach to the update so that the working group can=20 >> sensibly evaluate whether to adopt a proposal. >>=20 >> Having completed the S/MIME 4.0 specifications and updates to support >> i18n email addresses in PKIX certificates, the LAMPS WG is now: >>=20 >> 1. Specify a discovery mechanism for CAA records to replace the one >> described in RFC 6844. >>=20 >> 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. >>=20 >> RFC 6844 describes the mechanism by which CAA records relating to a >> domain are discovered. Implementation experience has demonstrated an >> ambiguity in the current processing of CNAME and DNAME records during >> discovery. Subsequent discussion has suggested that a different >> discovery approach would resolve limitations inherent in the current >> approach. >>=20 >> Unlike the previous hashing standards, the SHA-3 functions are the >> outcome of an open competition. They have a clear design rationale and >> have received a lot of public analysis, resulting in great confidence >> that the SHA-3 family of functions are very secure. Also, since the >> design of the SHA-3 functions use a very different construction from the >> SHA-2 functions, they offer an excellent alternative to the SHA-2 family >> of functions. In particular, SHAKE128/256 and SHAKE256/512 offer >> security and performance benefits. >>=20 >> In addition, the LAMPS Working Group may investigate other updates to=20 >> the documents produced by the PKIX and S/MIME Working Groups, but the=20 >> LAMPS Working Group shall not adopt any of these potential work items=20 >> without rechartering. >>=20 >> MILESTONES >>=20 >> Nov 2017: Adopt a draft for rfc6844bis >> Dec 2017: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512 >> Dec 2017: Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512 >> Apr 2018: rfc6844bis sent to IESG for standards track publication >> Sep 2018: SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for >> standards track publication >> Sep 2018: SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for >> standards track publication >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Aug 24 11:31:27 2017 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 7304413235A for ; Thu, 24 Aug 2017 11:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] 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 CYYI6dP81UU3 for ; Thu, 24 Aug 2017 11:31:23 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id DF444126E64 for ; Thu, 24 Aug 2017 11:31:22 -0700 (PDT) Received: from maxs-mbp.cablelabs.com (host64-111.cablelabs.com [192.160.73.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 8A0013740EE4 for ; Thu, 24 Aug 2017 14:31:22 -0400 (EDT) To: spasm@ietf.org References: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> <02CCCC92-7487-444A-A14A-0CC0D4118104@vigilsec.com> From: "Dr. Pala" Message-ID: <691aeea4-8b96-b0c9-6171-b9d06f414b46@openca.org> Date: Thu, 24 Aug 2017 12:31:21 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <02CCCC92-7487-444A-A14A-0CC0D4118104@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [lamps] DRAFT LAMPS Recharter Text X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 18:31:25 -0000 Hi Russ, all, I am sorry I was not able to send in the items right away - I think there has been some e-mails about supporting the work we are proposing, in particular adding a work item related to revocation. When you say "active support" what does that actually mean ? I think we demonstrated interest around the specific topic (there have been several messages across the different mailing lists - i.e., pkix, lamps, and saag). However, we still need the charter and milestones for the proposed work to see if we can adopt it in this WG. I will send in the charter text and milestones soon.. sorry again for the delay, but I hope the items will be considered for the charter :) Cheers, Max On 8/17/17 6:40 AM, Russ Housley wrote: > I have seen people voice support for the two work items listed in the draft charter text. I have seen Max and Dmitry offer additional work items, but there has been almost no discussion of their suggestions. Without active support, the suggested items will not be added. > > Russ > > >> On Aug 6, 2017, at 12:51 PM, Russ Housley wrote: >> >> At IETF 99, the LAMPS WG considered several potential recharter work items. The attached draft is a result of that discussion. Please review and comment. >> >> Russ >> >> = = = = = = = = >> >> The PKIX and S/MIME Working Groups have been closed for some time. Some >> updates have been proposed to the X.509 certificate documents produced >> by the PKIX Working Group and the electronic mail security documents >> produced by the S/MIME Working Group. >> >> The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working >> Group is chartered to make updates where there is a known constituency >> interested in real deployment and there is at least one sufficiently >> well specified approach to the update so that the working group can >> sensibly evaluate whether to adopt a proposal. >> >> Having completed the S/MIME 4.0 specifications and updates to support >> i18n email addresses in PKIX certificates, the LAMPS WG is now: >> >> 1. Specify a discovery mechanism for CAA records to replace the one >> described in RFC 6844. >> >> 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. >> >> RFC 6844 describes the mechanism by which CAA records relating to a >> domain are discovered. Implementation experience has demonstrated an >> ambiguity in the current processing of CNAME and DNAME records during >> discovery. Subsequent discussion has suggested that a different >> discovery approach would resolve limitations inherent in the current >> approach. >> >> Unlike the previous hashing standards, the SHA-3 functions are the >> outcome of an open competition. They have a clear design rationale and >> have received a lot of public analysis, resulting in great confidence >> that the SHA-3 family of functions are very secure. Also, since the >> design of the SHA-3 functions use a very different construction from the >> SHA-2 functions, they offer an excellent alternative to the SHA-2 family >> of functions. In particular, SHAKE128/256 and SHAKE256/512 offer >> security and performance benefits. >> >> In addition, the LAMPS Working Group may investigate other updates to >> the documents produced by the PKIX and S/MIME Working Groups, but the >> LAMPS Working Group shall not adopt any of these potential work items >> without rechartering. >> >> MILESTONES >> >> Nov 2017: Adopt a draft for rfc6844bis >> Dec 2017: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512 >> Dec 2017: Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512 >> Apr 2018: rfc6844bis sent to IESG for standards track publication >> Sep 2018: SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for >> standards track publication >> Sep 2018: SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for >> standards track publication >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Aug 24 12:06:39 2017 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 CC5AA132113 for ; Thu, 24 Aug 2017 12:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] 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 LR98mgKi40k8 for ; Thu, 24 Aug 2017 12:06:35 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 1446C1320CF for ; Thu, 24 Aug 2017 12:06:35 -0700 (PDT) Received: from maxs-mbp.cablelabs.com (host64-111.cablelabs.com [192.160.73.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id DA56A3740EE4 for ; Thu, 24 Aug 2017 15:06:34 -0400 (EDT) To: spasm@ietf.org References: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> From: "Dr. Pala" Message-ID: <01452470-3179-f675-208b-fdd338a1d0d0@openca.org> Date: Thu, 24 Aug 2017 13:06:34 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [lamps] DRAFT LAMPS Recharter Text X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 19:06:37 -0000 Hi Russ, all, I just added my additions to the charter and the related milestones.Please let me know what you think :D Cheers, Max On 8/6/17 10:51 AM, Russ Housley wrote: > At IETF 99, the LAMPS WG considered several potential recharter work items. The attached draft is a result of that discussion. Please review and comment. > > Russ > > = = = = = = = = > > The PKIX and S/MIME Working Groups have been closed for some time. Some > updates have been proposed to the X.509 certificate documents produced > by the PKIX Working Group and the electronic mail security documents > produced by the S/MIME Working Group. > > The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working > Group is chartered to make updates where there is a known constituency > interested in real deployment and there is at least one sufficiently > well specified approach to the update so that the working group can > sensibly evaluate whether to adopt a proposal. > > Having completed the S/MIME 4.0 specifications and updates to support > i18n email addresses in PKIX certificates, the LAMPS WG is now: > > 1. Specify a discovery mechanism for CAA records to replace the one > described in RFC 6844. > > 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. 3. Specify how to effectively reduce the size and increase the availability of    revocation informationby leveraging DNS as a transport protocol. > RFC 6844 describes the mechanism by which CAA records relating to a > domain are discovered. Implementation experience has demonstrated an > ambiguity in the current processing of CNAME and DNAME records during > discovery. Subsequent discussion has suggested that a different > discovery approach would resolve limitations inherent in the current > approach. > > Unlike the previous hashing standards, the SHA-3 functions are the > outcome of an open competition. They have a clear design rationale and > have received a lot of public analysis, resulting in great confidence > that the SHA-3 family of functions are very secure. Also, since the > design of the SHA-3 functions use a very different construction from the > SHA-2 functions, they offer an excellent alternative to the SHA-2 family > of functions. In particular, SHAKE128/256 and SHAKE256/512 offer > security and performance benefits. One of the major issues still open in PKIX is the efficient distribution of revocation information. Because of this, the use of short-lived certificates is seenas the only practical deployment solution in many environments. The use of DNS as an alternative transport protocol and the reducing of the size of revocation information via lightweight revocation tokens will improve the overall adoption of best-practices for revocation checking, lower the costs of revocation information distribution, and allow for distributed lookup and caching capabilities. > In addition, the LAMPS Working Group may investigate other updates to > the documents produced by the PKIX and S/MIME Working Groups, but the > LAMPS Working Group shall not adopt any of these potential work items > without rechartering. > > MILESTONES > > Nov 2017: Adopt a draft for rfc6844bis Nov 2017: Adopt OCSP over DNS draft > Dec 2017: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512 > Dec 2017: Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512 Mar 2018: Adopt a draft for Lightweight Revocation Tokens > Apr 2018: rfc6844bis sent to IESG for standards track publication Apr 2018: OCSP-over-DNS sent to IESG for standards track publication > Sep 2018: SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for > standards track publication > Sep 2018: SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for > standards track publication Sep 2018: Lightweight Revocation Tokens sent to IESG for standards           track publication From nobody Thu Aug 24 15:15:08 2017 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 80C5313235C for ; Thu, 24 Aug 2017 15:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name 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 4sUXTjGVTryj for ; Thu, 24 Aug 2017 15:15:05 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [IPv6:2600:3c00:e000:6c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2990C13219C for ; Thu, 24 Aug 2017 15:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1503612904; bh=N6YH5VT2S8teO9ziZMVTRH4cJ72/DHc3Yy97dE1btPc=; h=Date:From:To:Subject; b=OJV6cyg1hf2kbNqvAw2JZ/s3sqrmFeMKIRvhPloOMVx7Gtat/zcDUIiDekSF1FV1B 7DAkcFgQUQF5miZDDViQBW7slq/csafdTNKF7867W1Fvebf9Nxec47BN34KGZ9Swk4 36sBSaOp+j1iI0to9KU+hDr6N/Bm2vT2Di/XKpzpEWipM+NjtxST0wHTTwNerKW3XC 5p/4YTGtyo6SaR/hcPX1DzrjwuVRagg9ulWk7ZbKNUCboW7u2hZeMxAZvacy5xJs65 f9dKyLx7NPceckl/XqrOonnwPLYKqAs05njO1ApjADnH1B5cdjpVdolosisoDObL5E xnUf6PdecH/Gg== Date: Thu, 24 Aug 2017 15:15:03 -0700 From: Andrew Ayer To: spasm@ietf.org Message-Id: <20170824151503.172306cafdc978621d14d526@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: [lamps] CAA DNAME behavior is surprising X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 22:15:06 -0000 Roughly speaking, the CAA lookup algorithm in RFC 6844 section 4 says that if X does not have a CAA record, but is an alias, then the CA should look for a CAA record at the target of X. Specifically, it defines "alias" to be either a CNAME or a DNAME: "Let ... A(X) be the target of a CNAME or DNAME alias record specified at the label X." A straightforward interpretation of this language is that if you have the following records: sub1.example.com. IN DNAME sub2.example.com. sub2.example.com. IN CAA 0 issue "example.net" example.com. IN CAA 0 issue "example.org" then the only CA that is allowed to issue for sub1.example.com is example.net. This is the case even with erratum 5065. However, this does not match the typical behavior of DNAME. Per section 2.3 of RFC 6672: "Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its owner name; the owner name of a DNAME is not redirected itself." It's therefore rather surprising that CAA says you should follow the DNAME target of X and use the CAA record there. Given the above records, I would expect example.org, not example.net, to be the only CA that can issue for sub1.example.com. Is this behavior intentional? If so, what was its motivation? Regards, Andrew From nobody Thu Aug 24 19:13:14 2017 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 44D8F1329FD for ; Thu, 24 Aug 2017 19:13:13 -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, HEADER_FROM_DIFFERENT_DOMAINS=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 KVVHol0j_53D for ; Thu, 24 Aug 2017 19:13:12 -0700 (PDT) Received: from gal.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (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 D4AD91329FB for ; Thu, 24 Aug 2017 19:13:11 -0700 (PDT) Received: (qmail 57965 invoked by uid 100); 25 Aug 2017 02:13:11 -0000 Date: 25 Aug 2017 02:13:11 -0000 Message-ID: From: "John Levine" To: spasm@ietf.org Organization: Taughannock Networks, Trumansburg NY References: <20170824151503.172306cafdc978621d14d526@andrewayer.name> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@aryv.qy (John L) Archived-At: Subject: Re: [lamps] CAA DNAME behavior is surprising X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 02:13:13 -0000 In article <20170824151503.172306cafdc978621d14d526@andrewayer.name>, Andrew Ayer wrote: >Roughly speaking, the CAA lookup algorithm in RFC 6844 section 4 says >that if X does not have a CAA record, but is an alias, then the CA >should look for a CAA record at the target of X. > >Specifically, it defines "alias" to be either a CNAME or a DNAME: > >"Let ... A(X) be the target of a CNAME or DNAME alias record specified >at the label X." > >A straightforward interpretation of this language is that if you have >the following records: I think the obvious intention is to refer to a name at a CNAME or below a DNAME. We all understand that the DNAME's own name is not redirected. R's, John From nobody Fri Aug 25 11:22:40 2017 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 EF2BE132A19 for ; Fri, 25 Aug 2017 11:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=andrewayer.name 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 d_klQDyO3s8z for ; Fri, 25 Aug 2017 11:22:38 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [70.85.129.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7CA132256 for ; Fri, 25 Aug 2017 11:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1503685357; bh=n1MrNvospwAeCVIT91UWptTFVolUSFnpchx+aXNhybQ=; h=Date:From:To:Subject:In-Reply-To:References; b=l6imXjqZCor//IDuMyjlWFRnNZ4XUcgQQF8reIQQQUuCVq9shKojVE7ABUqCz5XV2 cAlszg2v2NQC3qJNF3NhYtgwBTcEGsHu3Z9p5QMnhsezhwD2GFg24Wcr3kC7IVOHYD rETZyH3RveVSDErfLG8XSX7lSlYN2oK19hb6JKsUuV2lUFbhHd7ljJOEvSnZfLFzwr QYKizi89CQXT5XIyNRKIlrMImZdI768myjWElChsvoAKP2+VxwHNoj8a14Wl1tKra4 ngHAXGIO4ri+3rOq/+ZGtk9tpXSsjfOwtRAvpamBBWlGdWXTwBkLYHgGpOifmTjVmu 6kQkB2+2F8Lmw== Date: Fri, 25 Aug 2017 11:22:37 -0700 From: Andrew Ayer To: spasm@ietf.org Message-Id: <20170825112237.78f046a3bdd502a35f35bb8a@andrewayer.name> In-Reply-To: References: <20170824151503.172306cafdc978621d14d526@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] CAA DNAME behavior is surprising X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 18:22:40 -0000 On 25 Aug 2017 02:13:11 -0000 "John Levine" wrote: > In article <20170824151503.172306cafdc978621d14d526@andrewayer.name>, > Andrew Ayer wrote: > >Roughly speaking, the CAA lookup algorithm in RFC 6844 section 4 says > >that if X does not have a CAA record, but is an alias, then the CA > >should look for a CAA record at the target of X. > > > >Specifically, it defines "alias" to be either a CNAME or a DNAME: > > > >"Let ... A(X) be the target of a CNAME or DNAME alias record > >specified at the label X." > > > >A straightforward interpretation of this language is that if you have > >the following records: > > I think the obvious intention is to refer to a name at a CNAME or > below a DNAME. We all understand that the DNAME's own name is not > redirected. I agree this is how CAA should work. Unfortunately, the language in RFC 6844 is quite explicit that a CAA lookup be attempted at A(X), and A(X) is defined to be the target of a DNAME alias record specified *at* the label X. Thus, if you implement CAA as it's specified in RFC 6844, you end up with the weird DNAME behavior. I've submitted erratum 5097 which proposes to simply remove mention of DNAME. Since DNAMEs cause CNAMEs to be synthesized for subordinate names, it's unnecessary for the CAA algorithm to consider them explicitly. https://www.rfc-editor.org/errata/eid5097 Regards, Andrew From nobody Fri Aug 25 13:15:23 2017 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 31A411320CF for ; Fri, 25 Aug 2017 13:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIJM7vs0IHaL for ; Fri, 25 Aug 2017 13:15:20 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 B865E124207 for ; Fri, 25 Aug 2017 13:15:19 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id o188so3263940lff.4 for ; Fri, 25 Aug 2017 13:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=1VWODVvMOxJ3RSCqpHxHAaXRHzmEFhCk7vd2cDYI/9w=; b=d9iTRtJH7eYcN7DjjVc7tOsN2ZQG/x049bwf50/Q+/ft+BNTysdUnNGYMt3raG1Hsd YLwdlhisOsXkmRn+KFBPA8MZGQ5vU7ByozbarFsB4QBws+MpfjtirZhZnvntr2F1vF0u Rsiu6NPWY4KAH9cP9+Zyemnr/VSrqNm4lX6zsQ5Y9Ex+y2iYZG+/WG8WPb/yxBURL0Yb xF/9JWMfZi+5h6AtQTSnh0CofW9a9Scv4s5V8xefk8FT6WGQN94GxUppNyWWhyqFDWCv xC5vver8AXaiZjt3t0Mzlk1gJNlEpPWCKVc4Znr9Vc6P37pxT0OOopMj+0uTB/LADtud bv6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=1VWODVvMOxJ3RSCqpHxHAaXRHzmEFhCk7vd2cDYI/9w=; b=h9qPVTSwXnNYAFlMkoAJ0vy91IXZTxk3j9zDQlAO7onP4j2owhlPgi7t94uQYqnhBS BHsuQ6uFu0BdK4g5aCeIXTXLAT/OWom4xjxYuCqGddRqhdc0jIcpeQAkklbTZ6fFFM6j 326PXC43VIer/VybwgIv8SXxoxqxrOpj+qCMV+nmylbpQNJ+O6B/YDPj3IA8CzdW9KoE 1ywU/frethxiliqw6Vnu9Wm86zbngZF4A5pPZmwmX82z14XVEt2K1zcqWT+sH2TgCdo2 T8WS/NX+f83/QKP/RxkUXK9QBSWFAh5gK+Qb82+ODgjLeczueVWXP/K+ajr4Hwp6pNEF vlSQ== X-Gm-Message-State: AHYfb5jsymUUrgIEXeKLTA4nRcReMvEgMU6K5PDaa3qbV5inorJgOxyH rAPRPAqjEZ0Qovl7jkos30Q+cJcUNw== X-Received: by 10.46.21.20 with SMTP id s20mr4354877ljd.172.1503692117944; Fri, 25 Aug 2017 13:15:17 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.142.199 with HTTP; Fri, 25 Aug 2017 13:15:17 -0700 (PDT) In-Reply-To: <20170825112237.78f046a3bdd502a35f35bb8a@andrewayer.name> References: <20170824151503.172306cafdc978621d14d526@andrewayer.name> <20170825112237.78f046a3bdd502a35f35bb8a@andrewayer.name> From: Phillip Hallam-Baker Date: Fri, 25 Aug 2017 16:15:17 -0400 X-Google-Sender-Auth: fiEtvjqORsNqADGYdPslEqdAMP8 Message-ID: To: Andrew Ayer Cc: SPASM Content-Type: multipart/alternative; boundary="94eb2c1cc9468aaf870557999aa8" Archived-At: Subject: Re: [lamps] CAA DNAME behavior is surprising X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 20:15:22 -0000 --94eb2c1cc9468aaf870557999aa8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please. No more errata to RFC 6844. The point of the work in this WG is to specify a new discovery mechanism. RFC 6844 already has an errata changing the semantics of the discovery mechanism that was extensively reviewed.. We do not do errata of errata. =E2=80=8BThe reason DNAME comes into it is DNSSEC. If you are processing DN= SSEC records then you will encounter DNAME on the wire. It is the only way that they can be signed. So any description has to cope with that.=E2=80=8B On Fri, Aug 25, 2017 at 2:22 PM, Andrew Ayer wrote: > On 25 Aug 2017 02:13:11 -0000 > "John Levine" wrote: > > > In article <20170824151503.172306cafdc978621d14d526@andrewayer.name>, > > Andrew Ayer wrote: > > >Roughly speaking, the CAA lookup algorithm in RFC 6844 section 4 says > > >that if X does not have a CAA record, but is an alias, then the CA > > >should look for a CAA record at the target of X. > > > > > >Specifically, it defines "alias" to be either a CNAME or a DNAME: > > > > > >"Let ... A(X) be the target of a CNAME or DNAME alias record > > >specified at the label X." > > > > > >A straightforward interpretation of this language is that if you have > > >the following records: > > > > I think the obvious intention is to refer to a name at a CNAME or > > below a DNAME. We all understand that the DNAME's own name is not > > redirected. > > I agree this is how CAA should work. > > Unfortunately, the language in RFC 6844 is quite explicit that a CAA > lookup be attempted at A(X), and A(X) is defined to be the target of a > DNAME alias record specified *at* the label X. > > Thus, if you implement CAA as it's specified in RFC 6844, you end up > with the weird DNAME behavior. > > I've submitted erratum 5097 which proposes to simply remove mention of > DNAME. Since DNAMEs cause CNAMEs to be synthesized for subordinate > names, it's unnecessary for the CAA algorithm to consider them > explicitly. > > https://www.rfc-editor.org/errata/eid5097 > > Regards, > Andrew > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --94eb2c1cc9468aaf870557999aa8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ple= ase. No more errata to RFC 6844.

The point of the work in this WG is to specify a new discovery mech= anism. RFC 6844 already has an errata changing the semantics of the discove= ry mechanism that was extensively reviewed.. We do not do errata of errata.= =C2=A0

=E2=80=8BThe reason DNAME comes into it is DNSSEC. If you are proc= essing DNSSEC records then you will encounter DNAME on the wire. It is the = only way that they can be signed. So any description has to cope with that.= =E2=80=8B




On Fri, Aug 25, 2017 at 2:22 PM, Andrew Ayer <<= a href=3D"mailto:agwa@andrewayer.name" target=3D"_blank">agwa@andrewayer.na= me> wrote:
On 25 Aug 2017 0= 2:13:11 -0000
"John Levine" <johnl@taugh.com> wrote:

> In article <20170824151503.172306cafdc978621d14d526@andre= wayer.name>,
> Andrew Ayer=C2=A0 <agwa@and= rewayer.name> wrote:
> >Roughly speaking, the CAA lookup algorithm in RFC 6844 section 4 s= ays
> >that if X does not have a CAA record, but is an alias, then the CA=
> >should look for a CAA record at the target of X.
> >
> >Specifically, it defines "alias" to be either a CNAME or= a DNAME:
> >
> >"Let ... A(X) be the target of a CNAME or DNAME alias record<= br> > >specified at the label X."
> >
> >A straightforward interpretation of this language is that if you h= ave
> >the following records:
>
> I think the obvious intention is to refer to a name at a CNAME or
> below a DNAME.=C2=A0 We all understand that the DNAME's own name i= s not
> redirected.

I agree this is how CAA should work.

Unfortunately, the language in RFC 6844 is quite explicit that a CAA
lookup be attempted at A(X), and A(X) is defined to be the target of a
DNAME alias record specified *at* the label X.

Thus, if you implement CAA as it's specified in RFC 6844, you end up with the weird DNAME behavior.

I've submitted erratum 5097 which proposes to simply remove mention of<= br> DNAME. Since DNAMEs cause CNAMEs to be synthesized for subordinate
names, it's unnecessary for the CAA algorithm to consider them
explicitly.

https://www.rfc-editor.org/errata/eid5097

Regards,
Andrew

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

--94eb2c1cc9468aaf870557999aa8-- From nobody Mon Aug 28 07:08:02 2017 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 04A4F132D0E for ; Mon, 28 Aug 2017 07:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I12TCWnjj1oJ for ; Mon, 28 Aug 2017 07:07:59 -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 D4EF3132D0D for ; Mon, 28 Aug 2017 07:07:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4AC073004D1 for ; Mon, 28 Aug 2017 10:07:58 -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 p_av9UEbqyVN for ; Mon, 28 Aug 2017 10:07:56 -0400 (EDT) Received: from [10.5.245.234] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id 70A083002A3; Mon, 28 Aug 2017 10:07:56 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <691aeea4-8b96-b0c9-6171-b9d06f414b46@openca.org> Date: Mon, 28 Aug 2017 10:07:57 -0400 Cc: spasm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2E78D706-3ED3-4596-8E86-2B5D3D6C365A@vigilsec.com> References: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> <02CCCC92-7487-444A-A14A-0CC0D4118104@vigilsec.com> <691aeea4-8b96-b0c9-6171-b9d06f414b46@openca.org> To: "Dr. Pala" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] DRAFT LAMPS Recharter Text X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 28 Aug 2017 14:08:01 -0000 For the current items, "active support" meant that more than one party = was willing to implement the RFC produced by the group. Russ > On Aug 24, 2017, at 2:31 PM, Dr. Pala wrote: >=20 > Hi Russ, all, >=20 > I am sorry I was not able to send in the items right away - I think = there has been some e-mails about supporting the work we are proposing, = in particular adding a work item related to revocation. When you say = "active support" what does that actually mean ? I think we demonstrated = interest around the specific topic (there have been several messages = across the different mailing lists - i.e., pkix, lamps, and saag). >=20 > However, we still need the charter and milestones for the proposed = work to see if we can adopt it in this WG. I will send in the charter = text and milestones soon.. sorry again for the delay, but I hope the = items will be considered for the charter :) >=20 > Cheers, > Max >=20 >=20 > On 8/17/17 6:40 AM, Russ Housley wrote: >> I have seen people voice support for the two work items listed in the = draft charter text. I have seen Max and Dmitry offer additional work = items, but there has been almost no discussion of their suggestions. = Without active support, the suggested items will not be added. >>=20 >> Russ >>=20 >>=20 >>> On Aug 6, 2017, at 12:51 PM, Russ Housley = wrote: >>>=20 >>> At IETF 99, the LAMPS WG considered several potential recharter work = items. The attached draft is a result of that discussion. Please = review and comment. >>>=20 >>> Russ >>>=20 >>> =3D =3D =3D =3D =3D =3D =3D =3D >>>=20 >>> The PKIX and S/MIME Working Groups have been closed for some time. = Some >>> updates have been proposed to the X.509 certificate documents = produced >>> by the PKIX Working Group and the electronic mail security documents >>> produced by the S/MIME Working Group. >>>=20 >>> The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working >>> Group is chartered to make updates where there is a known = constituency >>> interested in real deployment and there is at least one sufficiently >>> well specified approach to the update so that the working group can >>> sensibly evaluate whether to adopt a proposal. >>>=20 >>> Having completed the S/MIME 4.0 specifications and updates to = support >>> i18n email addresses in PKIX certificates, the LAMPS WG is now: >>>=20 >>> 1. Specify a discovery mechanism for CAA records to replace the one >>> described in RFC 6844. >>>=20 >>> 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and = S/MIME. >>>=20 >>> RFC 6844 describes the mechanism by which CAA records relating to a >>> domain are discovered. Implementation experience has demonstrated = an >>> ambiguity in the current processing of CNAME and DNAME records = during >>> discovery. Subsequent discussion has suggested that a different >>> discovery approach would resolve limitations inherent in the current >>> approach. >>>=20 >>> Unlike the previous hashing standards, the SHA-3 functions are the >>> outcome of an open competition. They have a clear design rationale = and >>> have received a lot of public analysis, resulting in great = confidence >>> that the SHA-3 family of functions are very secure. Also, since the >>> design of the SHA-3 functions use a very different construction from = the >>> SHA-2 functions, they offer an excellent alternative to the SHA-2 = family >>> of functions. In particular, SHAKE128/256 and SHAKE256/512 offer >>> security and performance benefits. >>>=20 >>> In addition, the LAMPS Working Group may investigate other updates = to >>> the documents produced by the PKIX and S/MIME Working Groups, but = the >>> LAMPS Working Group shall not adopt any of these potential work = items >>> without rechartering. >>>=20 >>> MILESTONES >>>=20 >>> Nov 2017: Adopt a draft for rfc6844bis >>> Dec 2017: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512 >>> Dec 2017: Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512 >>> Apr 2018: rfc6844bis sent to IESG for standards track publication >>> Sep 2018: SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for >>> standards track publication >>> Sep 2018: SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for >>> standards track publication >>> _______________________________________________ >>> Spasm mailing list >>> Spasm@ietf.org >>> https://www.ietf.org/mailman/listinfo/spasm >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Aug 28 07:54:39 2017 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 84138132C41 for ; Mon, 28 Aug 2017 07:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jgM8NZ5MkmY for ; Mon, 28 Aug 2017 07:54:36 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C5EB132C3F for ; Mon, 28 Aug 2017 07:54:36 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7SEpGGr015817; Mon, 28 Aug 2017 15:54:34 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=QU4hoVmv7jcbIF++AoW1AuvM38sOxZMrzWez5xUvU8I=; b=ApawwG/jbjIMktlawKYPyniS+/krmhuzTEJx9To3RuQ/z8fUu/nNYgsIQoZEYx+D6RKq vI1QVC64wu9ukE1XabyCeosHsve574VmXjFreBrCVB78htvfmFARDKUNVemjOsTB4T/l Efcahqu5hBF3YktJUa5yn8R7Wo8n2j0QZwSYEZHNwmqvTraCyNVajIF1t/ASVbq/2L+v AHokn+L/vBmMJhgJX74GJL3wCGm4N5o+LbEFitYSpv3FrY4TRtnlRmAXwavg6/y6dJxh HCHNptryDnoyork9sqx9mie5mUuOeyFDtERJ4haqLXUZKkrNY2yQTkbHv/o9L+aXhfC9 og== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2ck08kcdph-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Aug 2017 15:54:34 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7SErdsB019933; Mon, 28 Aug 2017 10:54:33 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2ck4au8yun-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 28 Aug 2017 10:54:33 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 28 Aug 2017 10:54:32 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 28 Aug 2017 10:54:32 -0400 From: "Salz, Rich" To: Russ Housley , "Dr. Pala" CC: "spasm@ietf.org" Thread-Topic: [lamps] DRAFT LAMPS Recharter Text Thread-Index: AQHTDtREV2uTgAmGC0Ci5Fyipv6dEKKI0WaAgAtiXYCABf+7gP//yfMA Date: Mon, 28 Aug 2017 14:54:31 +0000 Message-ID: <942CF4F1-7495-4C23-A2C4-5F4E4124CFA2@akamai.com> References: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> <02CCCC92-7487-444A-A14A-0CC0D4118104@vigilsec.com> <691aeea4-8b96-b0c9-6171-b9d06f414b46@openca.org> <2E78D706-3ED3-4596-8E86-2B5D3D6C365A@vigilsec.com> In-Reply-To: <2E78D706-3ED3-4596-8E86-2B5D3D6C365A@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.38.215] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-28_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708280239 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-28_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708280239 Archived-At: Subject: Re: [lamps] DRAFT LAMPS Recharter Text X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 28 Aug 2017 14:54:37 -0000 T3BlblNTTCBpcyBpbnRlcmVzdGVkLg0KDQpPbiA4LzI4LzE3LCAxMDowNyBBTSwgIlJ1c3MgSG91 c2xleSIgPGhvdXNsZXlAdmlnaWxzZWMuY29tPiB3cm90ZToNCg0KICAgIEZvciB0aGUgY3VycmVu dCBpdGVtcywgImFjdGl2ZSBzdXBwb3J0IiBtZWFudCB0aGF0IG1vcmUgdGhhbiBvbmUgcGFydHkg d2FzIHdpbGxpbmcgdG8gaW1wbGVtZW50IHRoZSBSRkMgcHJvZHVjZWQgYnkgdGhlIGdyb3VwLg0K IA0KDQo= From nobody Mon Aug 28 08:02:28 2017 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 04306132C4B for ; Mon, 28 Aug 2017 08:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5v9OXCH8KcVc for ; Mon, 28 Aug 2017 08:02:24 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 89B4E132C41 for ; Mon, 28 Aug 2017 08:02:24 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id b14so13686556wme.0 for ; Mon, 28 Aug 2017 08:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EUsUdkwTOyhNQRfWLin9yiufnqwWZaS9797jt4FOMn8=; b=NARD9Gt1mP1RbQugE9ndFIe4qrM4U6ljPJwj3la8sVTdvwjAitSVk30n5HJpsNEoNH laPO6bYMiDqURZOIazFH3uX0LTJCBjxBC7+IEe23NzMYj36YWgr5GVd7161xUosOLB4k r8XVJ2/2mE6WCWo2UCOwPM05sCJa1DEiBzlTr1H6WoIoAScYWIEEM/flYa5L8Pgca/tf REmg7B6DR9n/PheiI8Dt8YQJSHnyu8+mDCb2xHXsnTbhUkv7c9PtyAqb1ga/UEPAfLTZ p7LKLfz6DF2ibe1+lCw2w1WqEN2V1ok+BlOW2nq02unWxIhvOhL5b5ND3TAzyNQZ03kt iAkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EUsUdkwTOyhNQRfWLin9yiufnqwWZaS9797jt4FOMn8=; b=cJWhiTbn/fp3ndPCH597/O5M5YzPeeLHlNpkTukdKfbz04+a79xxtf6xGhtZVVuJjf vXr2TMJ+BbSP3lTG7HdmAMNKUKT1ho4ZvlGUOlECUJtWcwSTSAkwLu8DU+13zPkh5yyv hgSw7ERrKD/Hv92pQi02y2SO8iRU6TTS2vQZYhmcotNqoRw8GgEqLV/pg7ZB+RPr01O6 zhQs5NXxsWUH/yZ3tHo7lWeJuKcwyusxL6TO20uYmwdSxVQLu/mJwM36GMGLlWLjLwkz PH0HkrNdoTUEqvBLSdU+ZQyA9zncymR/4E66p5rp2FKUFcJf/D+qbA7tK/XmyJmNdko3 ejgg== X-Gm-Message-State: AHYfb5gsgGTj82+t4JRslaIjXJZ4aBCDzuqPEs+nJXiA0L9WyC1SIFFQ JHEXNfYJk+lVl+qQ0gk9BxFdqfgkmg== X-Received: by 10.80.178.97 with SMTP id o88mr710506edd.209.1503932543034; Mon, 28 Aug 2017 08:02:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.143.3 with HTTP; Mon, 28 Aug 2017 08:02:22 -0700 (PDT) In-Reply-To: <942CF4F1-7495-4C23-A2C4-5F4E4124CFA2@akamai.com> References: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> <02CCCC92-7487-444A-A14A-0CC0D4118104@vigilsec.com> <691aeea4-8b96-b0c9-6171-b9d06f414b46@openca.org> <2E78D706-3ED3-4596-8E86-2B5D3D6C365A@vigilsec.com> <942CF4F1-7495-4C23-A2C4-5F4E4124CFA2@akamai.com> From: Dmitry Belyavsky Date: Mon, 28 Aug 2017 18:02:22 +0300 Message-ID: To: "Salz, Rich" Cc: Russ Housley , "Dr. Pala" , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c195c10fe69ee0557d1945d" Archived-At: Subject: Re: [lamps] DRAFT LAMPS Recharter Text X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 28 Aug 2017 15:02:27 -0000 --94eb2c195c10fe69ee0557d1945d Content-Type: text/plain; charset="UTF-8" Do you mean Dr.Pala's suggestion or mine one? They are related in some way, but not equivalent. Thank you! On Mon, Aug 28, 2017 at 5:54 PM, Salz, Rich wrote: > OpenSSL is interested. > > On 8/28/17, 10:07 AM, "Russ Housley" wrote: > > For the current items, "active support" meant that more than one party > was willing to implement the RFC produced by the group. > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > -- SY, Dmitry Belyavsky --94eb2c195c10fe69ee0557d1945d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Do you mean Dr.Pala's suggestion or mine one? They are= related in some way, but not equivalent.

Thank you!

On Mon, A= ug 28, 2017 at 5:54 PM, Salz, Rich <rsalz@akamai.com> wrote:<= br>
OpenSSL is interested.

On 8/28/17, 10:07 AM, "Russ Housley" <housley@vigilsec.com> wrote:

=C2=A0 =C2=A0 For the current items, "active support" meant that = more than one party was willing to implement the RFC produced by the group.=


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



--
=
SY, Dmitr= y Belyavsky
--94eb2c195c10fe69ee0557d1945d-- From nobody Mon Aug 28 08:03:31 2017 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 B7B2B132C4D for ; Mon, 28 Aug 2017 08:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaQBl6_rekma for ; Mon, 28 Aug 2017 08:03:28 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FEDB132C4B for ; Mon, 28 Aug 2017 08:03:27 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7SEud6e024870; Mon, 28 Aug 2017 16:03:24 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=qAG+AD/0R3V4ny0FWce7o02CwUTSBgB8GIkh8eDkUz4=; b=gV8W5zzF/exKfHjwew9+tC7HuxU+EShOJkENBtc4BPOrL2vl58kIXeCVA2mM53vgZCVX 1e6YfzrjvdMCm3v9/A045Pb9lVJZ8y+Kz0QKP5ZaEGNVxcARdWhSvFR+pvmLACm1plzX PuZy0qMs6DuMqpnWYUFTePH7g3WAjZzeIBlHgeux41bYoWr2XiyH1sBEMKuChSLNatWI EF26copxOC4G+Frp/k2AX8XpnRJGoUY38I1/t7PDAkyw/ksMBH/fgOdAfdL7BAiLciTF bGV0D/zScZR+wTUvhBlgMeHbe/0TF4rvwnrn2zZsUyZ/H23dSKM3t9w3z0l/dTHEL1y+ 1A== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2ck1d6uny8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Aug 2017 16:03:24 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7SF3OVA030446; Mon, 28 Aug 2017 11:03:24 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2ck4aus08k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 28 Aug 2017 11:03:23 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 28 Aug 2017 11:03:20 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 28 Aug 2017 11:03:20 -0400 From: "Salz, Rich" To: Dmitry Belyavsky CC: Russ Housley , "Dr. Pala" , "spasm@ietf.org" Thread-Topic: [lamps] DRAFT LAMPS Recharter Text Thread-Index: AQHTDtREV2uTgAmGC0Ci5Fyipv6dEKKI0WaAgAtiXYCABf+7gP//yfMAgABFQQD//702gA== Date: Mon, 28 Aug 2017 15:03:20 +0000 Message-ID: <1340920B-A219-4C36-9837-0A5744872C87@akamai.com> References: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> <02CCCC92-7487-444A-A14A-0CC0D4118104@vigilsec.com> <691aeea4-8b96-b0c9-6171-b9d06f414b46@openca.org> <2E78D706-3ED3-4596-8E86-2B5D3D6C365A@vigilsec.com> <942CF4F1-7495-4C23-A2C4-5F4E4124CFA2@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.38.215] Content-Type: multipart/alternative; boundary="_000_1340920BA2194C3698370A5744872C87akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-28_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708280242 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-28_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708280240 Archived-At: Subject: Re: [lamps] DRAFT LAMPS Recharter Text X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 28 Aug 2017 15:03:30 -0000 --_000_1340920BA2194C3698370A5744872C87akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgYXJlIGludGVyZXN0ZWQgaW4gYm90aCB0aGluZ3MuDQoNClRoYXQgaXMgb2YgY291cnNlLCBu b3QgYSBwcm9taXNlIHRvIGNvbW1pdCwgYnV0IHRoZXJlIGlzIGRlZmluaXRlIGludGVyZXN0Lg0K --_000_1340920BA2194C3698370A5744872C87akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <1C6A79EFF1D6524987C99555BE0A8E28@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLmltDQoJe21zby1zdHlsZS1uYW1lOmltO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29s b3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJv ZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5XZSBhcmUgaW50 ZXJlc3RlZCBpbiBib3RoIHRoaW5ncy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGF0IGlz IG9mIGNvdXJzZSwgbm90IGEgcHJvbWlzZSB0byBjb21taXQsIGJ1dCB0aGVyZSBpcyBkZWZpbml0 ZSBpbnRlcmVzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_1340920BA2194C3698370A5744872C87akamaicom_-- From nobody Mon Aug 28 08:14:08 2017 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 C273A132C47 for ; Mon, 28 Aug 2017 08:14:06 -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, HTML_MESSAGE=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 XZbdkzUgxLfN for ; Mon, 28 Aug 2017 08:14:04 -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 B3EF8132C44 for ; Mon, 28 Aug 2017 08:14:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2D5C7300568 for ; Mon, 28 Aug 2017 11:14:03 -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 MqmB780GPv-p for ; Mon, 28 Aug 2017 11:14:01 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 9557F3004C3; Mon, 28 Aug 2017 11:14:01 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4FF5252D-89A1-47FC-A210-92D70346DD5B" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 28 Aug 2017 11:14:04 -0400 In-Reply-To: Cc: "spasm@ietf.org" To: Dmitry Belyavsky References: <3EC3EBBE-D17D-4A25-A61C-27872613FB4D@vigilsec.com> <02CCCC92-7487-444A-A14A-0CC0D4118104@vigilsec.com> <691aeea4-8b96-b0c9-6171-b9d06f414b46@openca.org> <2E78D706-3ED3-4596-8E86-2B5D3D6C365A@vigilsec.com> <942CF4F1-7495-4C23-A2C4-5F4E4124CFA2@akamai.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] DRAFT LAMPS Recharter Text X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 28 Aug 2017 15:14:07 -0000 --Apple-Mail=_4FF5252D-89A1-47FC-A210-92D70346DD5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This definition applies to all work that will be considered by the LAMPS = WG. As I said, this is the definition that was used for the current = items, and it will be used for any new topics as well. Russ > On Aug 28, 2017, at 11:02 AM, Dmitry Belyavsky = wrote: >=20 > Do you mean Dr.Pala's suggestion or mine one? They are related in some = way, but not equivalent. >=20 > Thank you! >=20 > On Mon, Aug 28, 2017 at 5:54 PM, Salz, Rich > wrote: > OpenSSL is interested. >=20 > On 8/28/17, 10:07 AM, "Russ Housley" > wrote: >=20 > For the current items, "active support" meant that more than one = party was willing to implement the RFC produced by the group. --Apple-Mail=_4FF5252D-89A1-47FC-A210-92D70346DD5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This definition applies to all work that will be considered = by the LAMPS WG.  As I said, this is the definition that was used = for the current items, and it will be used for any new topics as = well.

Russ


On = Aug 28, 2017, at 11:02 AM, Dmitry Belyavsky <beldmit@gmail.com> = wrote:

Do you mean Dr.Pala's suggestion or mine one? = They are related in some way, but not equivalent.

Thank you!

On Mon, = Aug 28, 2017 at 5:54 PM, Salz, Rich <rsalz@akamai.com> wrote:
OpenSSL is = interested.

On 8/28/17, 10:07 AM, "Russ Housley" <housley@vigilsec.com> wrote:

    For the current items, "active support" meant that more = than one party was willing to implement the RFC produced by the = group.

= --Apple-Mail=_4FF5252D-89A1-47FC-A210-92D70346DD5B-- From nobody Mon Aug 28 10:03:37 2017 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 5E610132C47 for ; Mon, 28 Aug 2017 10:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name 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 xCfld8WNtaiH for ; Mon, 28 Aug 2017 10:03:35 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [IPv6:2600:3c00:e000:6c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 187A1132942 for ; Mon, 28 Aug 2017 10:03:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1503939814; bh=LLYrsytFqPlV0CEQMbwRvIJekM2Uwc7JaBAjj/e212o=; h=Date:From:To:Subject:In-Reply-To:References; b=fY5qDPumxRze1/XF9SZgCg/8gDEqvF5LGik83iw1Scorksb1fQ6aMSGKiNQG29Byl 9xKvTRzgJrBraUJrE1kIO54/ClghRsDHrAA4V3+KFVmeilwQBtU5fu80pI4ANliEb1 6ZXXAIVAP6Bm82+wQh0JwkNIDimo+3oHLwCaynoHsNupybpubCmXOiAV/qztTqLp0o xaBWVZa3nPzWY98l9NIZI+UheVYT0lSWGariq6je7UtIpGTZE54LYgK/7vf3sT6PXd iARJ8gRLgsS1rRS0Y+Up17Ye4QVyQ/3N87qNz93yfenLiaBBl1JU1etS8QJH17dsaO +nWoizgXJGkew== Date: Mon, 28 Aug 2017 10:03:33 -0700 From: Andrew Ayer To: SPASM Message-Id: <20170828100333.a0b21684ca41aae11edfb299@andrewayer.name> In-Reply-To: References: <20170824151503.172306cafdc978621d14d526@andrewayer.name> <20170825112237.78f046a3bdd502a35f35bb8a@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] CAA DNAME behavior is surprising X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 28 Aug 2017 17:03:36 -0000 On Fri, 25 Aug 2017 16:15:17 -0400 Phillip Hallam-Baker wrote: > Please. No more errata to RFC 6844. > > The point of the work in this WG is to specify a new discovery > mechanism. RFC 6844 already has an errata changing the semantics of > the discovery mechanism that was extensively reviewed.. We do not do > errata of errata. This problem existed prior to and was not introduced by any other erratum, including 5065. It's an independent problem. Should implementers of RFC 6844 follow the current wording - that is, follow the target of the DNAME specified "at" the label X and do a CAA lookup there? > The reason DNAME comes into it is DNSSEC. If you are processing DNSSEC > records then you will encounter DNAME on the wire. It is the only way that > they can be signed. So any description has to cope with that. Why does RFC 6844 need to get into the details of how DNAMEs are validated? It doesn't specify every other minute detail of how DNSSEC works - nor does it need to. Regards, Andrew From nobody Mon Aug 28 12:00:30 2017 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 6480C132D61 for ; Mon, 28 Aug 2017 12:00:28 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgH99ZwbEqyM for ; Mon, 28 Aug 2017 12:00:26 -0700 (PDT) Received: from miucha.iecc.com (www.examp1e.com [IPv6:2001:470:1f07:1126::555:1212]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A83751329A9 for ; Mon, 28 Aug 2017 12:00:23 -0700 (PDT) Received: (qmail 9958 invoked from network); 28 Aug 2017 19:00:22 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 28 Aug 2017 19:00:22 -0000 Date: 28 Aug 2017 19:00:00 -0000 Message-ID: <20170828190000.39762.qmail@ary.lan> From: "John Levine" To: spasm@ietf.org Cc: agwa@andrewayer.name In-Reply-To: <20170828100333.a0b21684ca41aae11edfb299@andrewayer.name> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [lamps] CAA DNAME behavior is surprising X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 28 Aug 2017 19:00:28 -0000 In article <20170828100333.a0b21684ca41aae11edfb299@andrewayer.name> you write: >Should implementers of RFC 6844 follow the current wording - that is, >follow the target of the DNAME specified "at" the label X and do a CAA >lookup there? Am I really the only one who looked at that sentence and read its obvious correct meaning, names that a CNAME or DNAME redirects? R's, John PS: in the legal world, one of the fixed principles of statutory interpretation is that if a statement has one interpretation that is sensible and another that is absurd, you use the sensible one and don't waste time on the absurd one. From nobody Wed Aug 30 10:49:41 2017 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 E43C8132320; Wed, 30 Aug 2017 10:49:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150411537287.21627.718835119292102691@ietfa.amsl.com> Date: Wed, 30 Aug 2017 10:49:32 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-eai-addresses-13.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 17:49:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Internationalized Email Addresses in X.509 certificates Authors : Alexey Melnikov Weihaw Chuang Filename : draft-ietf-lamps-eai-addresses-13.txt Pages : 11 Date : 2017-08-30 Abstract: This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an Internationalized Email Address. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-13 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-eai-addresses-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-13 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/