From nobody Fri Jun 3 08:01:21 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1C3128E19 for ; Fri, 3 Jun 2016 08:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bpy_qsFhR8DR for ; Fri, 3 Jun 2016 08:01:18 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E209C12D1A3 for ; Fri, 3 Jun 2016 08:01:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A98B0BDD0 for ; Fri, 3 Jun 2016 16:01:16 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PL7-HzI8sR8R for ; Fri, 3 Jun 2016 16:01:16 +0100 (IST) Received: from [134.226.62.192] (cswireless62-192.scss.tcd.ie [134.226.62.192]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 14102BDCA for ; Fri, 3 Jun 2016 16:01:16 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1464966076; bh=cuzZSGj7dAw4a5srFDoKe47tqpK8bX7Y7zD0r7JCq3w=; h=To:From:Subject:Date:From; b=freWcn5OD90fbj3En3IAgR8IGBBIXtuoCYvbeB7pK43TUoVPAi8lU+Taj1D6Ox97c SBx7/wMMJlia5gTxDPj+WxSkv4BLh1dEZAbsLp36aXa06jsDAMmZG0D2diP+wl4vm1 V7a+WMoa/ZNgbqtiNj5sJDUW0S5TT6TfvewV/wOQ= To: "spasm@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <57519BBB.8050604@cs.tcd.ie> Date: Fri, 3 Jun 2016 16:01:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090307000100020807090807" Archived-At: Subject: [Spasm] BoF in Berlin or what? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue 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, 03 Jun 2016 15:01:20 -0000 This is a cryptographically signed message in MIME format. --------------ms090307000100020807090807 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, We seem to be approaching but not finalising a charter. Should we have a short BoF in Berlin [1] to discuss this or would folks prefer we just keep doing it on the list? If the former, then the BoF approval call (where the IAB and IESG approve the BoFs to be held in Berlin) is on June 10th, so please express your opinions on this before next Tuesday, June 7th. If the latter, and if we finalise charter text then there is still time to formally create a WG before Berlin, in which case do we think the putative WG would want to meet? If so, again we'd want to get a slot on the agenda and you'd want to speak up before the 7th as well. In either case where we want a meeting slot in Berlin, that'd mean adding information to [2] (which I can do), either for a BoF or as a placeholder for the in-formation WG. I think one hour would be sufficient for either. So - what do folks want? FWIW, I'm happy to go with whatever consensus emerges on the list, but tend to think that a BoF might be right to give more folks a chance to give us input as to which of the work items are likely to see deployment. And in case some folks aren't familiar with IETF meeting scheduling, if we do go for a f2f meeting slot for this, we'll only know the specific day/time around June 24. Thanks, S. [1] https://ietf.org/meeting/96/index.html [2] https://trac.tools.ietf.org/bof/trac/wiki#Security --------------ms090307000100020807090807 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 CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MDMx NTAxMTVaMC8GCSqGSIb3DQEJBDEiBCAxIyiZ5M51CpW+Gjy9PNMj9ihkUYLQXYmnu11STRyb OzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCdi7Ax+aRex3xKeAMIK6HZZVIRpQv+pmcCNzM8aJq83yqBbqGTrDGB ijVLVrEmRJsWnW/F4f7M9G4Li/cS3VfWGEt2i26M0fariocy9KRHCt+ziqjXjnAJIz/ASdEN QiIyj69g/w39i41CrA7nwZlJuBvDMhLgu5/hR7Hea64N2nNEJTiZL/hfmvxoQgfuZB5+6d0t 67CSsuflTh7GqWZhz680BmEIGRvWWOeAWurlUyIaL0BlXsXvNCf3FnWZELooObA3Eb1d7O1q px7lOWAk3AMBtSgHHl65WDxlP0rrQUNIkaWd64xnxWK/BPfWTG+fT6xQlKOwurt0qrsMCC5Y AAAAAAAA --------------ms090307000100020807090807-- From nobody Fri Jun 3 10:00:57 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4795F12D737 for ; Fri, 3 Jun 2016 10:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 TLh7-w7-eCSo for ; Fri, 3 Jun 2016 10:00:54 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 45E0F12D534 for ; Fri, 3 Jun 2016 10:00:53 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id k23so136317922oih.0 for ; Fri, 03 Jun 2016 10:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0pno3b8drkENPgDUit1nAtoDJ4+qzB88n1qcmxPCIvI=; b=Ef2gyQXfQfuzHDFMhsr2eNnrmtxC1hP1vAv3xc/wDlty0zmMUyaLZEnBxPENF2z8Tx VvZGdBv7s/OGxAFKkZyDZRPasCM7rR2B+Jximhyu2xqgK2lwygnVDjZACSeOf3+DVmf2 gEXC8YzxxnKIscJVBe8fY0E4ejXTRcbZ8fpToWZrDiUmpMqytXFNkXZ7o2vUhLiWVR0H GIwe75276bwDyKiAOEx4G7gpEVzyZh8q/YLpvRLjJwacRYsHYapFCpDD6W8sMOokJwaR dpMSXlj/xR2TrG8cVpOjys0mZSZ4C0IWkkDmDz6S16QhvXdrVggOrRQvMon3IPXynLX6 WRUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0pno3b8drkENPgDUit1nAtoDJ4+qzB88n1qcmxPCIvI=; b=kziWGlcLhMDIBShzqDSDofU50yZKRz/yGuNDW8s3kbkh5af8h98hclKGLT0K1vHKef InBM8geK1IZkCMi5Lrwejj9z1g3SLKDiya1f0bfvOLObjkyTmoSCpWmbEym6upVWxBXt V4Y5045J1Aasp+z0xgl0BSYdZzuPpMW3lkyY9jnj61yY5N9cS5iOm5Tx++yrODVxhr3d QGHC4Y3X9YnWdWs+9nOSIUmeNYM13l8pl0UeTmOr/16T8cLKxSpBWVKaJPxktw2TmWZy q1uboNrvgNxl3RBxPqoIhDGJnOCyNKE0xhfQs4gOcYUNV4FlIifjFh01FAxPL5EI4Jmn +buw== X-Gm-Message-State: ALyK8tIVE/4y5u/9MudWQtt7DMZ+5KOnh8Ls8dTmHK4DA7n0naLWY/yKjWWd7WwKAYrubldohkiCIj6Ab/FQXvMK X-Received: by 10.202.225.8 with SMTP id y8mr2569446oig.192.1464973252402; Fri, 03 Jun 2016 10:00:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.1.67 with HTTP; Fri, 3 Jun 2016 10:00:51 -0700 (PDT) In-Reply-To: <57519BBB.8050604@cs.tcd.ie> References: <57519BBB.8050604@cs.tcd.ie> From: Wei Chuang Date: Fri, 3 Jun 2016 10:00:51 -0700 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a113cd17850f17c053462aa19 Archived-At: Cc: "spasm@ietf.org" Subject: Re: [Spasm] BoF in Berlin or what? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue 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, 03 Jun 2016 17:00:56 -0000 --001a113cd17850f17c053462aa19 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Fri, Jun 3, 2016 at 8:01 AM, Stephen Farrell wrote: > > Hiya, > > We seem to be approaching but not finalising a charter. > Should we have a short BoF in Berlin [1] to discuss this > or would folks prefer we just keep doing it on the list? > > If the former, then the BoF approval call (where the > IAB and IESG approve the BoFs to be held in Berlin) is > on June 10th, so please express your opinions on this > before next Tuesday, June 7th. > > If the latter, and if we finalise charter text then > there is still time to formally create a WG before > Berlin, in which case do we think the putative WG > would want to meet? If so, again we'd want to get a > slot on the agenda and you'd want to speak up before > the 7th as well. > > In either case where we want a meeting slot in Berlin, > that'd mean adding information to [2] (which I can do), > either for a BoF or as a placeholder for the in-formation > WG. I think one hour would be sufficient for either. > > So - what do folks want? > I like the idea of meeting up in Berlin. I would prefer as a WG so work on the actual drafts could occur. The draft charter has three items (given below), two of which (1) and (3) are (I believe) non controversial, and I hope doesn't get stuck due to the large discussion on item (2). While understandably that seems to be a bit more controversial, I hope the details of which may be worked out in person in Berlin. Draft work items: 1. Specify the way to include an i18n email address as a subject alternative name and an issuer alternative name. 2. Specify the processing for the Extended Key Usage certificate extension when it appears in the certificate of an intermediate certification authority. 3. Specify the way to use authenticated encryption in S/MIME. > FWIW, I'm happy to go with whatever consensus emerges > on the list, but tend to think that a BoF might be > right to give more folks a chance to give us input as > to which of the work items are likely to see deployment. > > And in case some folks aren't familiar with IETF > meeting scheduling, if we do go for a f2f meeting slot > for this, we'll only know the specific day/time around > June 24. > If a F2F is setup, can date preferences be taken into account? In my case I'll be able to attend for a subset of days due to family restrictions. If so can we collect this up in a separate renamed thread? Thanks very much Stephen for sending this out. -Wei > > Thanks, > S. > > [1] https://ietf.org/meeting/96/index.html > [2] https://trac.tools.ietf.org/bof/trac/wiki#Security > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > --001a113cd17850f17c053462aa19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On Fri, Jun 3, 2016 at 8:01 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

We seem to be approaching but not finalising a charter.
Should we have a short BoF in Berlin [1] to discuss this
or would folks prefer we just keep doing it on the list?

If the former, then the BoF approval call (where the
IAB and IESG approve the BoFs to be held in Berlin) is
on June 10th, so please express your opinions on this
before next Tuesday, June 7th.

If the latter, and if we finalise charter text then
there is still time to formally create a WG before
Berlin, in which case do we think the putative WG
would want to meet? If so, again we'd want to get a
slot on the agenda and you'd want to speak up before
the 7th as well.

In either case where we want a meeting slot in Berlin,
that'd mean adding information to [2] (which I can do),
either for a BoF or as a placeholder for the in-formation
WG. I think one hour would be sufficient for either.

So - what do folks want?

I like the idea of meeting up in Berlin.  I would prefer as a WG so work on the actual drafts could occur.  The draft charter has three items (given below), two of which (1) and (3) are (I believe) non controversial, and I hope doesn't get stuck due to the large discussion on item (2).  While understandably that seems to be a bit more controversial, I hope the details of which may be worked out in person in Berlin.  

Draft work items:
1. Specify the way to include an i18n email address as a subject
   alternative name and an issuer alternative name.

2. Specify the processing for the Extended Key Usage certificate
   extension when it appears in the certificate of an intermediate
   certification authority.

3. Specify the way to use authenticated encryption in S/MIME.


FWIW, I'm happy to go with whatever consensus emerges
on the list, but tend to think that a BoF might be
right to give more folks a chance to give us input as
to which of the work items are likely to see deployment.

And in case some folks aren't familiar with IETF
meeting scheduling, if we do go for a f2f meeting slot
for this, we'll only know the specific day/time around
June 24.

If a F2F is setup, can date preferences be taken into account?   In my case I'll be able to attend for a subset of days due to family restrictions.  If so can we collect this up in a separate renamed thread?

Thanks very much Stephen for sending this out.
-Wei
 

Thanks,
S.

[1] https://ietf.org/meeting/96/index.html
[2] https://trac.tools.ietf.org/bof/trac/wiki#Security


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


--001a113cd17850f17c053462aa19-- From nobody Fri Jun 3 10:10:24 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB80112D5B0 for ; Fri, 3 Jun 2016 10:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w09MkJ0w2WR3 for ; Fri, 3 Jun 2016 10:10:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2583F12D508 for ; Fri, 3 Jun 2016 10:10:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 76287BE33; Fri, 3 Jun 2016 18:10:17 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBuATFaC7ADR; Fri, 3 Jun 2016 18:10:16 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 49D50BE32; Fri, 3 Jun 2016 18:10:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1464973816; bh=4rRtvoB1I/a0gzYCyqLTiMw9wz0QO/KEdosjsSDSFtU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=lDxEoRTEQEyE5xWRe+UF9TrHLyaCGbQqPgnUk7aKuI4cwdYyXjBU0hnexkunnfsUa Qu3oRifBpS8OrizVQagnNwSLU2QeWZXj1FqZIs2701WrOQ9JpgV6HYrbfdpDAzX3EJ qg+JPVF1Cb8apGV1ZOC5VifG6C08KALlbFutza9U= To: Wei Chuang References: <57519BBB.8050604@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5751B9F7.90902@cs.tcd.ie> Date: Fri, 3 Jun 2016 18:10:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050008030106090207070208" Archived-At: Cc: "spasm@ietf.org" Subject: Re: [Spasm] BoF in Berlin or what? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue 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, 03 Jun 2016 17:10:23 -0000 This is a cryptographically signed message in MIME format. --------------ms050008030106090207070208 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 03/06/16 18:00, Wei Chuang wrote: > If a F2F is setup, can date preferences be taken into account? =20 Not very easily sorry, if you take a look at the IETF95 agenda [1] and IEF96 requests from existing WGs,[2] and imagine trying to include all the personnel issues (with ~1100 people) as additional constraints I'm sure you'll agree that's too hard and would likely fail. That said, it is worth knowing if significant contributors have restrictions, as we can sometimes accommodate those, but with no promises. If you think you're in that category for this meeting (if there's consensus to want one) then just email me offlist and we'll see how it pans out. > In my case > I'll be able to attend for a subset of days due to family restrictions.= If > so can we collect this up in a separate renamed thread? I'd prefer we not do that TBH - too likely to cause disappointment. And if all WGs did it, it could even be disruptive I guess;-) Cheers, S. [1] https://datatracker.ietf.org/meeting/95/agenda.html [2] https://datatracker.ietf.org/meeting/96/requests --------------ms050008030106090207070208 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 CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MDMx NzEwMTVaMC8GCSqGSIb3DQEJBDEiBCAPySJfadveGt3pbSyIghEaFVsXPMM6IwABDw1Ge3gT NjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQA9tkjk1WQlYH3rYMh6YQT8lth1ybXyqyAz1s3w74dU44nMzMZwspem RTDgNwhXHNAXDVXvzpG1wK7WVHphlQpBs7Z6doamdIKDalZoBOooVteEAhUo906CeLiueHOG 1WSf8Ffsuha7sewrMDuzpdDw/vgpE8s7M29S2lw3C6Res52IX/DhXBh4wkx1SOuZfsYRPyWK gaVshb/qrHxr9vVnbt968aa1l2B+k7EKB5RpGTw54bJ4jI01fL2bKXQXWwdfKqttGNhphxn3 GFr7oUomyxt8QdT0i7OZgFfVM06QoM1xNzX8tHFHjZ4XJTVwDTp0sxW39YuO7EKJxjHiXxk+ AAAAAAAA --------------ms050008030106090207070208-- From nobody Fri Jun 3 10:55:17 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248CA12D0A7 for ; Fri, 3 Jun 2016 10:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 NZTJve1F6FK0 for ; Fri, 3 Jun 2016 10:55:14 -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 604A312D77B for ; Fri, 3 Jun 2016 10:55:14 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E772A509B8 for ; Fri, 3 Jun 2016 13:55:12 -0400 (EDT) To: spasm@ietf.org References: <57519BBB.8050604@cs.tcd.ie> <5751B9F7.90902@cs.tcd.ie> From: Sean Leonard Message-ID: <1bf342d0-cc08-22dc-a114-8115bfd4115d@seantek.com> Date: Fri, 3 Jun 2016 10:55:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <5751B9F7.90902@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Spasm] BoF in Berlin or what? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue 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, 03 Jun 2016 17:55:16 -0000 On 6/3/2016 10:10 AM, Stephen Farrell wrote: > Hiya, > > On 03/06/16 18:00, Wei Chuang wrote: >> If a F2F is setup, can date preferences be taken into account? > Not very easily sorry, if you take a look at the IETF95 agenda [1] > and IEF96 requests from existing WGs,[2] and imagine trying to include > all the personnel issues (with ~1100 people) as additional constraints > I'm sure you'll agree that's too hard and would likely fail. > > That said, it is worth knowing if significant contributors have > restrictions, as we can sometimes accommodate those, but with no > promises. If you think you're in that category for this meeting > (if there's consensus to want one) then just email me offlist and > we'll see how it pans out. I am 50-50 about going to IETF96, but if there is an official SPASM F2F (whether WG or BoF) I will try to be there. As to the main question: > Should we have a short BoF in Berlin [1] to discuss this > or would folks prefer we just keep doing it on the list? There is a scoping question that I believe is best answered in person. However, I do not know if the people who are most greatly affected, or who are most likely to implement (or not implement), will make it in person. Draft work items: 1. Specify the way to include an i18n email address as a subject alternative name and an issuer alternative name. 2. Specify the processing for the Extended Key Usage certificate extension when it appears in the certificate of an intermediate certification authority. 3. Specify the way to use authenticated encryption in S/MIME. The questions are: a) shall this list be expanded to additional points? b) shall the scope be expanded to include "general PKIX and S/MIME improvement issues"? I think: a) yes (and those points need to be fully enumerated before charter is finalized), b) no -- but we should set a precedent for permissively allowing new scoped WGs to form to address novel or revision issues. Sean From nobody Fri Jun 3 11:21:33 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9194612B007 for ; Fri, 3 Jun 2016 11:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 9d-eSmQ4rPYk for ; Fri, 3 Jun 2016 11:21:30 -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 2564A12D71B for ; Fri, 3 Jun 2016 11:21:30 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0E897509B6; Fri, 3 Jun 2016 14:21:28 -0400 (EDT) To: spasm@ietf.org From: Sean Leonard Message-ID: Date: Fri, 3 Jun 2016 11:22:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Simon Josefsson Subject: [Spasm] Scoping question: RFC7468 errata, revision X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue 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, 03 Jun 2016 18:21:31 -0000 In October 2015, I noticed a post-publication problem with RFC 7468=20 (Simon Josefsson and I are the co-authors). The ABNF is wrong: BEGIN and END are case-sensitive, but the ABNF is=20 case-insensitive. I filed an errata (ID 4508) but it has not been=20 addressed yet. I am not sure what to do about it, but it bothers me. Anyway, I would like to propose that a fix be considered in-scope for=20 this WG, whether that means just approving the errata, or revising RFC=20 7468. So, there is another proposed work item. Thank you, Sean From nobody Fri Jun 3 11:31:53 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110C212D877 for ; Fri, 3 Jun 2016 11:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQdd7l5Yjnji for ; Fri, 3 Jun 2016 11:31:49 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F1912D7B0 for ; Fri, 3 Jun 2016 11:31:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8B66CBDD0; Fri, 3 Jun 2016 19:31:44 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maXk89fXYWOC; Fri, 3 Jun 2016 19:31:43 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B74A9BE25; Fri, 3 Jun 2016 19:31:42 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1464978703; bh=dVT9ApoksmmUKGT+0FtqbuhPg+/7qfeVyMMYxbKbaLM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=u+CCmWv/zBxzcDHT/o8RmkGARyK93POKx5IO2rzopTNg9Xr1getsinw+xVqZOtqnh cO7AyZQ1Ozhr8evsigxs/jTO2kmCHQrXlslHZrbG6iZuh8i0Dp09LAV1CaLS1OrJlp JdqJIE2hjuLF97N7dwEzctzSKHtuEVywWrbRIE74= To: Sean Leonard , spasm@ietf.org References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5751CD0E.1050305@cs.tcd.ie> Date: Fri, 3 Jun 2016 19:31:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020908050900070401050502" Archived-At: Cc: Simon Josefsson Subject: Re: [Spasm] Scoping question: RFC7468 errata, revision X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue 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, 03 Jun 2016 18:31:52 -0000 This is a cryptographically signed message in MIME format. --------------ms020908050900070401050502 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Approving that erratum doesn't seem to me to be a sensible WG work item. If someone else agrees with you that it's valid then I'll approve it. Cheers, S. PS: My attitude to errata is to generally ignore them unless/until someone other than the submitter cares. That's because while many errata are correct, most are useless as they're not read and many are not that useful even if read. On 03/06/16 19:22, Sean Leonard wrote: > In October 2015, I noticed a post-publication problem with RFC 7468 > (Simon Josefsson and I are the co-authors). >=20 > The ABNF is wrong: BEGIN and END are case-sensitive, but the ABNF is > case-insensitive. I filed an errata (ID 4508) but it has not been > addressed yet. I am not sure what to do about it, but it bothers me. >=20 > Anyway, I would like to propose that a fix be considered in-scope for > this WG, whether that means just approving the errata, or revising RFC > 7468. So, there is another proposed work item. >=20 > Thank you, >=20 > Sean >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 --------------ms020908050900070401050502 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 CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MDMx ODMxNDJaMC8GCSqGSIb3DQEJBDEiBCAfkFsq0uzZBO/KHe1Y/LZo1BrgxEijslNzSCIzUbSG EzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAMJdD7cL4igTi04VXgmE2leH0dxTzhBAcqmMVWNvfDWAHoZ5JFYOxI X/fYHuH9aOqruMUpogSBOrhLUpl+8b2meA2IvrCOfinmOEW9EDBSC9IJpxkR5SbwEfjEtmNF ppjSUJiCyQ5JE7Wyq7btFBBA6PZM1qZiFI88UVm3kNS68RlAROm0Sw+ricBfiJETsZpEZCTp 5/6JIk2TMrh9DC7XJNh/2LL+aWVLQC3RN3F4tpHM/syxGjYAWpALENscSObpV1V/PNMC+l5h 5alXPrpZGZ1Dk8qdqWzREdF8IetPGE2ASXEa4/sbhqWZOtrEsubRUzeZUWOI7ovQ1Bk6gxEO AAAAAAAA --------------ms020908050900070401050502-- From nobody Mon Jun 6 14:44:45 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834C312D952 for ; Mon, 6 Jun 2016 14:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 67TcHqPQS3C5 for ; Mon, 6 Jun 2016 14:44:35 -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 1F23812D947 for ; Mon, 6 Jun 2016 14:44:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BFACD3003FE for ; Mon, 6 Jun 2016 17:27:25 -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 l-_ljP60pYpN for ; Mon, 6 Jun 2016 17:27:23 -0400 (EDT) Received: from [172.20.9.181] (unknown [40.141.115.126]) by mail.smeinc.net (Postfix) with ESMTPSA id 81BC53003D1; Mon, 6 Jun 2016 17:27:23 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_B9A51346-466A-4F44-8B99-A2F9DFDF575F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <57519BBB.8050604@cs.tcd.ie> Date: Mon, 6 Jun 2016 15:46:27 -0400 Message-Id: References: <57519BBB.8050604@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "spasm@ietf.org" Subject: Re: [Spasm] BoF in Berlin or what? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue 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, 06 Jun 2016 21:44:37 -0000 --Apple-Mail=_B9A51346-466A-4F44-8B99-A2F9DFDF575F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I=92d like to see you start the chartering discussion. If we cannot get = to consensus, then we can hold a BOF to sort out any chartering issues. = Otherwise, we can get to the meat of the work. Russ On Jun 3, 2016, at 11:01 AM, Stephen Farrell = wrote: >=20 > Hiya, >=20 > We seem to be approaching but not finalising a charter. > Should we have a short BoF in Berlin [1] to discuss this > or would folks prefer we just keep doing it on the list? >=20 > If the former, then the BoF approval call (where the > IAB and IESG approve the BoFs to be held in Berlin) is > on June 10th, so please express your opinions on this > before next Tuesday, June 7th. >=20 > If the latter, and if we finalise charter text then > there is still time to formally create a WG before > Berlin, in which case do we think the putative WG > would want to meet? If so, again we'd want to get a > slot on the agenda and you'd want to speak up before > the 7th as well. >=20 > In either case where we want a meeting slot in Berlin, > that'd mean adding information to [2] (which I can do), > either for a BoF or as a placeholder for the in-formation > WG. I think one hour would be sufficient for either. >=20 > So - what do folks want? >=20 > FWIW, I'm happy to go with whatever consensus emerges > on the list, but tend to think that a BoF might be > right to give more folks a chance to give us input as > to which of the work items are likely to see deployment. >=20 > And in case some folks aren't familiar with IETF > meeting scheduling, if we do go for a f2f meeting slot > for this, we'll only know the specific day/time around > June 24. >=20 > Thanks, > S. >=20 > [1] https://ietf.org/meeting/96/index.html > [2] https://trac.tools.ietf.org/bof/trac/wiki#Security >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --Apple-Mail=_B9A51346-466A-4F44-8B99-A2F9DFDF575F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9zCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUAwggQooAMCAQICEQCzIsUuKpsHVq2Oiy2wXwvCMA0GCSqGSIb3DQEBCwUAMIGbMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTYwMzMxMDAwMDAwWhcNMTcw MzMxMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkBFhRob3VzbGV5QHZpZ2lsc2VjLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAOQwBbNVXhmLbyClWrRBX0GdNQFhVHEpbzM4tr5pdd0q rPp8i+6qqNa4dAbJT6kodJ/LgsBi5EN3li4MJOIlf3rCsK1/VXepRwqUoc1cZfLRGdEj/4zgwrNZ ULvOFiDIvYkAYDWRlYnEXulWr3KriOApHpfzbQvHStU1YsV762AIHVbZUW5tlTC9LfI8r+PIBFzv Y5ujoUnSAgKgeE8gDK9yAxemrQ6wzDpwaf5PxEVnw0gOC2jtDojdzhoQfz57MFrL9pA1QyMbnItV zCYfc5J7EfeCGupcFqwXytbJHSYPfLfM1/3omGgCGD/DZk4z4SUVC19k02iGxAIVDsWJ5oMCAwEA AaOCAfIwggHuMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTrsV85 Y7qY6oVPF5xRd+wqIu3VJTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUaG91c2xleUB2aWdpbHNlYy5jb20wDQYJKoZIhvcN AQELBQADggEBACgHw+/VeC7LgLJs19KZ6Ds2cW+jLSPjA3AIqSxiQ+uyDFwe6FujBUqRCXfla0qg MzbhJ+1uSxcaktsS5idpB5Dfp8SVEGLcjtSJwWVlEofjaRrx6pi2mzazQwfKklY/epvsgnCoY8KW FeSGkpbQXu5WrIL18EFqMCHqDiu5/P49PcZnJRv2xHTi5CkIsI7XgOw4FazS3xuJMVQ5TVtIUeMW OqRlNJaeTiBsOVauS3FE/zRejsAYhHp3EV1PZFhV6hdcK/8qKrqRBtZtsEIm2FNWNsk8p/3RmUQl 4n4qN/NvapmXyYqfHZiuxf2g8H/WHF8IlVDzljLy90Uy0X7Qp0gxggPGMIIDwgIBATCBsTCBmzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAsyLFLiqbB1atjostsF8L wjAJBgUrDgMCGgUAoIIB6TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjA2MDYxOTQ2MjdaMCMGCSqGSIb3DQEJBDEWBBRH/k+4Wf/TYJRE593zxsUV/bZBXjCBwgYJ KwYBBAGCNxAEMYG0MIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCzIsUuKpsHVq2Oiy2wXwvCMIHEBgsqhkiG9w0BCRACCzGBtKCBsTCBmzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAsyLFLiqbB1atjostsF8LwjANBgkqhkiG 9w0BAQEFAASCAQBuJ2VgLxjJpNzzR5GwoQd9cpIdBVyldkAf6w+zT4i/ye3pKW9mkRSAw6krZjpt ZciFOSkukcImxhUp5pe1lrdTQp8zRS1dRz24YrS+J9TFktU0QDr8PLjzAUS6wP23jM8PhWinguvm ltYH28RbZT3NiQUlbWTix8GkBYxwKXsmm5uinsOUK0tD6s0ajl6yxlYX+V9IscAkRXrzX9ZLb3PC +Q87moPOXkjtVstoHYPtKX3lc6kKidDsBM7BN3WyXEF5YtqW0AwCgVD7G8yQvdLCgseNe7evNrEm JE/X+5etP/u5jOi7Cuo7un7XaUOZUyN7+0NcPAM98x92oG0CenPmAAAAAAAA --Apple-Mail=_B9A51346-466A-4F44-8B99-A2F9DFDF575F-- From nobody Tue Jun 7 03:29:40 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA93912D0DC for ; Tue, 7 Jun 2016 03:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brSJt6Qrjltz for ; Tue, 7 Jun 2016 03:29:36 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id C697212B009 for ; Tue, 7 Jun 2016 03:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1465295375; d=isode.com; s=selector; i=@isode.com; bh=VwcV8hfAiwfGOsr5PpZhEySrbxgbw5jNYn15w3iw4iQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=XzvZn+EfkuPpW3ip+7hvVzISRw66kuXNlWztRatjHnMYKnulmq/D0c6IXAWScc9WpqiPs6 gdTVtizjWn6/tXt5Sq8LzXPVAkPyJ04ofUVhQ2ylAlRYn1R3qVUPNDHWH3DdCc8ilAqkoH CErY2xHtpu/fbWKfAMkjSQV3Z9++GBw=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 7 Jun 2016 11:29:35 +0100 To: Russ Housley , Stephen Farrell References: <57519BBB.8050604@cs.tcd.ie> From: Alexey Melnikov Message-ID: <5756A1FD.104@isode.com> Date: Tue, 7 Jun 2016 11:29:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------040002030107090508010307" Archived-At: Cc: "spasm@ietf.org" Subject: Re: [Spasm] BoF in Berlin or what? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue 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, 07 Jun 2016 10:29:39 -0000 --------------040002030107090508010307 Content-Type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: quoted-printable On 06/06/2016 20:46, Russ Housley wrote: > I=92d like to see you start the chartering discussion. If we cannot get t= o consensus, then we can hold a BOF to sort out any chartering issues. Othe= rwise, we can get to the meat of the work. +1. We already started some specific work, I would rather we continue that. > > Russ > > > On Jun 3, 2016, at 11:01 AM, Stephen Farrell w= rote: > >> Hiya, >> >> We seem to be approaching but not finalising a charter. >> Should we have a short BoF in Berlin [1] to discuss this >> or would folks prefer we just keep doing it on the list? >> >> If the former, then the BoF approval call (where the >> IAB and IESG approve the BoFs to be held in Berlin) is >> on June 10th, so please express your opinions on this >> before next Tuesday, June 7th. >> >> If the latter, and if we finalise charter text then >> there is still time to formally create a WG before >> Berlin, in which case do we think the putative WG >> would want to meet? If so, again we'd want to get a >> slot on the agenda and you'd want to speak up before >> the 7th as well. >> >> In either case where we want a meeting slot in Berlin, >> that'd mean adding information to [2] (which I can do), >> either for a BoF or as a placeholder for the in-formation >> WG. I think one hour would be sufficient for either. >> >> So - what do folks want? >> >> FWIW, I'm happy to go with whatever consensus emerges >> on the list, but tend to think that a BoF might be >> right to give more folks a chance to give us input as >> to which of the work items are likely to see deployment. >> >> And in case some folks aren't familiar with IETF >> meeting scheduling, if we do go for a f2f meeting slot >> for this, we'll only know the specific day/time around >> June 24. >> >> Thanks, >> S. >> >> [1] https://ietf.org/meeting/96/index.html >> [2] https://trac.tools.ietf.org/bof/trac/wiki#Security >> >> _______________________________________________ >> 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 --------------040002030107090508010307 Content-Type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable On 06/06/2016 20:46, Russ Housley wrote:
I=92d like to see you start the chartering discussion. =
 If we cannot get to consensus, then we can hold a BOF to sort out any chart=
ering issues.  Otherwise, we can get to the meat of the work.
+1. We already started some specific work, I would rather we continue that.

Russ


On Jun 3, 2016, at 11:01 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie&=
gt; wrote:


Hiya,

We seem to be approaching but not finalising a charter.
Should we have a short BoF in Berlin [1] to discuss this
or would folks prefer we just keep doing it on the list?

If the former, then the BoF approval call (where the
IAB and IESG approve the BoFs to be held in Berlin) is
on June 10th, so please express your opinions on this
before next Tuesday, June 7th.

If the latter, and if we finalise charter text then
there is still time to formally create a WG before
Berlin, in which case do we think the putative WG
would want to meet? If so, again we'd want to get a
slot on the agenda and you'd want to speak up before
the 7th as well.

In either case where we want a meeting slot in Berlin,
that'd mean adding information to [2] (which I can do),
either for a BoF or as a placeholder for the in-formation
WG. I think one hour would be sufficient for either.

So - what do folks want?

FWIW, I'm happy to go with whatever consensus emerges
on the list, but tend to think that a BoF might be
right to give more folks a chance to give us input as
to which of the work items are likely to see deployment.

And in case some folks aren't familiar with IETF
meeting scheduling, if we do go for a f2f meeting slot
for this, we'll only know the specific day/time around
June 24.

Thanks,
S.

[1] https://ietf.org/meeting/96/index.html
[2] https://trac.tools.ietf.org/bof/trac/wiki#Security

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


      

      

      

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


    

    

  


--------------040002030107090508010307--


From nobody Tue Jun  7 03:42:57 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E704912B027 for ; Tue,  7 Jun 2016 03:42:55 -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 EzccXBkoj4nS for ; Tue,  7 Jun 2016 03:42:54 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 3E7EC12B013 for ; Tue,  7 Jun 2016 03:42:54 -0700 (PDT)
Received: by mail-lf0-x22a.google.com with SMTP id b73so112150486lfb.3 for ; Tue, 07 Jun 2016 03:42:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z0NehjENR+5l2l4vTdY2V78aNQaFMhOtTpxruN+7LiE=; b=C6BUN1CPVfvCKMfGPODqER+KRF0837SnwAXAI4xHg5RB7QnFUfEGt9mRwJrDnCXyHq nv/ObHB1U27GRhpS5l4Vbqd//K0mLN1FBuTBWii2bpX0KOQbe3KxfEY96L4wgRdG6UFH bdx9wnGW6gX4b/bRnuQiQ4ZfXVJIiSJ7GL2ZuMASXwDDl2T2pAeYqKkWEHOFGyHNrqZQ 4TlQ3NNusj21G/nmNYi1dosbVZrScYdZwyjQ8u7PDsDb1KwyKz3k7/+yvvobAsa1MUS7 LFrXPR0X0WSUcQWU+g6P5Ih2U8GqHe8xSTC+ZqwrPyXvVeEwZLZTWTEkMSgdu45G9Vt0 jVjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Z0NehjENR+5l2l4vTdY2V78aNQaFMhOtTpxruN+7LiE=; b=Nm2wUx6EHXMYnGQhSxe09CDXWK1TwweO0L6CkJ3m5V7K0wY97dsoYOfWakfbEiNiGE /OLm7FLhqAxqyV21f1GKAJ1dBtpGqpAT9EBT9M4klQYktRRtKlKsiIIZKGdzQMqtjlgm CgQbuWBsUJlLLhi9+EKGFBiPLQSTYiHg1c5aFEgSSKreYt4kxQbt9ouQD7eWIuOYeaN7 tUoPuBiRX9oS64Nc+mrPHOx7ziiuRmUB5ANfxmthugPL3ZXQpWLDwxP5skSjJi86xyfd glN9jPOT+06hdKZ74NBrJGeqNXZduMJBSzcBRtE3FRpKrfqB6PiBuu65QojuOP1kioT+ zBSQ==
X-Gm-Message-State: ALyK8tIoHK0ObS4s8I6ptFPFOgyssp+1d2H0ywgNmaSUtr9MfL5NRVPJdNfEOo2SNRihVXtvX0M+Z9tCJZRAvw==
X-Received: by 10.25.16.230 with SMTP id 99mr2539881lfq.21.1465296172373; Tue, 07 Jun 2016 03:42:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.41.1 with HTTP; Tue, 7 Jun 2016 03:42:51 -0700 (PDT)
In-Reply-To: <57519BBB.8050604@cs.tcd.ie>
References: <57519BBB.8050604@cs.tcd.ie>
From: Dmitry Belyavsky 
Date: Tue, 7 Jun 2016 13:42:51 +0300
Message-ID: 
To: Stephen Farrell 
Content-Type: multipart/alternative; boundary=001a11403604d85bf70534add99f
Archived-At: 
Cc: "spasm@ietf.org" 
Subject: Re: [Spasm] BoF in Berlin or what?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 07 Jun 2016 10:42:56 -0000

--001a11403604d85bf70534add99f
Content-Type: text/plain; charset=UTF-8

Dear Stephen,

On Fri, Jun 3, 2016 at 6:01 PM, Stephen Farrell 
wrote:

>
> Hiya,
>
> We seem to be approaching but not finalising a charter.
> Should we have a short BoF in Berlin [1] to discuss this
> or would folks prefer we just keep doing it on the list?
>
>
>
I think it will be useful to see each other face-to-face. So I strongly
support the idea of BoF.


-- 
SY, Dmitry Belyavsky

--001a11403604d85bf70534add99f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Dear Stephen,=C2=A0

On Fri, Jun 3, 2016 at 6:01 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


Hiya,



We seem to be approaching but not finalising a charter.

Should we have a short BoF in Berlin [1] to discuss this

or would folks prefer we just keep doing it on the list?




I think it will be useful to see e=
ach other face-to-face. So I strongly support the idea of BoF.=C2=A0
<=
/div>

-- 
SY, Dmitry Belyavsky




--001a11403604d85bf70534add99f--


From nobody Wed Jun  8 09:28:06 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC24412D093 for ; Wed,  8 Jun 2016 09:28:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 LOzJBMimfiYZ for ; Wed,  8 Jun 2016 09:28:03 -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 0D8A312D786 for ; Wed,  8 Jun 2016 09:28:02 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 04DFD50A89 for ; Wed,  8 Jun 2016 12:28:01 -0400 (EDT)
References: <20160608161629.19935.86198.idtracker@ietfa.amsl.com>
To: spasm@ietf.org
From: Sean Leonard 
X-Forwarded-Message-Id: <20160608161629.19935.86198.idtracker@ietfa.amsl.com>
Message-ID: 
Date: Wed, 8 Jun 2016 09:28:44 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <20160608161629.19935.86198.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Spasm] certspec work (draft-seantek-certspec-06.txt)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 08 Jun 2016 16:28:04 -0000

Hello SPASM:

I would like to propose "certspec" as a work item for this WG, and that 
it be considered in-scope as we debate the WG's scope.

certspec is a string specification for certificates. It allows protocols 
and systems to identify a certificate in a textual form, and is designed 
with human usability in mind (specifically, copy-and-paste operations).

Previous versions of this draft tried to define certspec as a URN, and 
then as a series of URI schemes. Those approaches were not successful. 
This draft just calls it a string. You can look at the diffs 
(particularly the diff between 04 and 05) to see the differences.

Thanks to Russ Housley for feedback on the most recent versions of this 
draft.

Regards,

Sean

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-seantek-certspec-06.txt
Date: 	Wed, 08 Jun 2016 09:16:29 -0700
From: 	internet-drafts@ietf.org



A new version of I-D, draft-seantek-certspec-06.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-seantek-certspec
Revision:	06
Title:		String Specification for Certificates
Document date:	2016-06-08
Group:		Individual Submission
Pages:		27
URL:            https://www.ietf.org/internet-drafts/draft-seantek-certspec-06.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-certspec/
Htmlized:       https://tools.ietf.org/html/draft-seantek-certspec-06
Diff:           https://www.ietf.org/rfcdiff?url2=draft-seantek-certspec-06

Abstract:
    Digital certificates are used in many systems and protocols to
    identify and authenticate parties.  This document describes a string
    format that identifies certificates, along with optional attributes.
    This string format has been engineered to work without re-encoding in
    a variety of protocol slots.

                                                                                   


From nobody Thu Jun  9 06:43:42 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C5712D0E9 for ; Thu,  9 Jun 2016 06:43:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level: 
X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4eq_j3lURoE for ; Thu,  9 Jun 2016 06:43:39 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDFEA12D6B1 for ; Thu,  9 Jun 2016 06:43:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A5030BDCF for ; Thu,  9 Jun 2016 14:43:27 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrHPGWoLWGSj for ; Thu,  9 Jun 2016 14:43:26 +0100 (IST)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E861ABDCC for ; Thu,  9 Jun 2016 14:43:25 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1465479806; bh=PnEjZLqAu4VJNuTE7+aUqdhgEY08Y0cYwELA8GLPN5c=; h=Subject:To:References:From:Date:In-Reply-To:From; b=mTNKtaxy6vex1O4D7gDHY3yzzPxlB+HtPcqK52DSgcjAfDlMsDBRlaezv6YpKNEXb 7MlTIAsXrQpFzRjKbBn75zLoSncBwvc3beMIvVhFeVkS3PqIfzJi7C8Ylxtpag/At3 u+266AIuaZS0MViRnmsDPYltj2KS+z3V9NbWKhBI=
To: "spasm@ietf.org" 
References: <57519BBB.8050604@cs.tcd.ie>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <5759727D.8050009@cs.tcd.ie>
Date: Thu, 9 Jun 2016 14:43:25 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <57519BBB.8050604@cs.tcd.ie>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040802030503040608090101"
Archived-At: 
Subject: Re: [Spasm] BoF in Berlin or what?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 09 Jun 2016 13:43:41 -0000

This is a cryptographically signed message in MIME format.

--------------ms040802030503040608090101
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

So I got a suggestion off list to maybe delete items 2 and
4 from the charter [1] for now and to proceed to charter a
WG on that basis. The charter already says that addition of
new work items requires a re-charter, so if other bits of work
do need doing they can be added as real demand for them becomes
apparent (and assuming the WG turns out to be productive).

I think that leaves us with two choices:

a) delete items 2 and 4 from [1] and I'll start the formal
chartering process and schedule a WG meeting for Berlin,

or,

b) leave [1] as-is and we have a WG-forming BoF in Berlin.

As of now, I prefer (a).

I'll need to decide in the next 24 hours (the BoF scheduling
call is then), though it's not a final decision, as plan (a)
of course requires an at least 2-week period when the IETF
can comment on the new WG before it's formally created.

So, please yell now if you think (a) is unacceptable.

Cheers,
S.

PS: I think John Levine took an action to try check if
item 4 might actually get deployed when he's at the m3aawg
meeting next week. If that seems to garner consensus that
some reasonable level of deployment is likely, I'd be fine
with adding item 4 back during the chartering process.

[1] https://datatracker.ietf.org/doc/charter-ietf-spasm/


--------------ms040802030503040608090101
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MDkx
MzQzMjVaMC8GCSqGSIb3DQEJBDEiBCAXo/JfCUgPfzM7nvu+Giysvtf+qPSmSEZ8GTJQmwGN
rzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQCd9xxkIg8TPwTPYoTk0lvZR9nfGiWdnYk+hzhHprBQHOMj0PbvIxi8
n6TyU6FAge5fX3gqZYfsGvTsDc87it5dRp60ewMO8nZ+ifxasQQgSb/OFtMEtOLLf4rKi4Bq
GWoi0bs5QjWQl3p13y/35aJ9X+BwJx/ztnXgZ4EP+g/v6lD/YqRIeolsEwQGVbu7KmWOl2U9
pH01LWhtLMhXIQ98O8rzwr6mHAu6GhrpStyGzvYrzcez6yizryd2A7TKA5f6AB6fEu9S7dLX
R3aQ3qQoneOMyW4ZGoDtI4sgJrg42fFRwrXlC4CRthzTcRS33J8j84e0nL8JuGwov1Af0y3T
AAAAAAAA
--------------ms040802030503040608090101--


From nobody Thu Jun  9 06:44:51 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0D912B01F for ; Thu,  9 Jun 2016 06:44:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level: 
X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIP7WQImHDKv for ; Thu,  9 Jun 2016 06:44:49 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 160B912D67D for ; Thu,  9 Jun 2016 06:44:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CC39CBDCC; Thu,  9 Jun 2016 14:44:47 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbJB_OePdksf; Thu,  9 Jun 2016 14:44:43 +0100 (IST)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EF601BDCA; Thu,  9 Jun 2016 14:44:42 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1465479883; bh=tAw7XID8ggSfELIF6PFTVBD5k8D32RmtPxrgY88cEX4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=WCpN9jOy3TKZIZ3HiKlsAMQCA19GoaEzV7qoC9pEiOdzrfmEz8H+ZWZfaU5fCiezn 9ZnnNsXCg2R1Fdmn/ZN3VCQoGZj7AXY1vvjg/ao+xKk9QX4je8VkQ43FP5JzMa8gyV p+hr7PV/bd5xBYkcoL9MRZTJH7p05O3AVMJtCGik=
To: Sean Leonard , spasm@ietf.org
References: <20160608161629.19935.86198.idtracker@ietfa.amsl.com> 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <575972CA.2090806@cs.tcd.ie>
Date: Thu, 9 Jun 2016 14:44:42 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000905080805060802060005"
Archived-At: 
Subject: Re: [Spasm] certspec work (draft-seantek-certspec-06.txt)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 09 Jun 2016 13:44:50 -0000

This is a cryptographically signed message in MIME format.

--------------ms000905080805060802060005
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Sean,

On 08/06/16 17:28, Sean Leonard wrote:
> Hello SPASM:
>=20
> I would like to propose "certspec" as a work item for this WG, and that=

> it be considered in-scope as we debate the WG's scope.
>=20
> certspec is a string specification for certificates. It allows protocol=
s
> and systems to identify a certificate in a textual form, and is designe=
d
> with human usability in mind (specifically, copy-and-paste operations).=

>=20
> Previous versions of this draft tried to define certspec as a URN, and
> then as a series of URI schemes. Those approaches were not successful.
> This draft just calls it a string. You can look at the diffs
> (particularly the diff between 04 and 05) to see the differences.
>=20
> Thanks to Russ Housley for feedback on the most recent versions of this=

> draft.

If there's a bunch of folks saying they'd implement and deploy
that'd be good. Absent that, see earlier charter discussion.

Cheers,
S.

>=20
> Regards,
>=20
> Sean
>=20
> -------- Forwarded Message --------
> Subject:     New Version Notification for draft-seantek-certspec-06.txt=

> Date:     Wed, 08 Jun 2016 09:16:29 -0700
> From:     internet-drafts@ietf.org
>=20
>=20
>=20
> A new version of I-D, draft-seantek-certspec-06.txt
> has been successfully submitted by Sean Leonard and posted to the
> IETF repository.
>=20
> Name:        draft-seantek-certspec
> Revision:    06
> Title:        String Specification for Certificates
> Document date:    2016-06-08
> Group:        Individual Submission
> Pages:        27
> URL:          =20
> https://www.ietf.org/internet-drafts/draft-seantek-certspec-06.txt
> Status:         https://datatracker.ietf.org/doc/draft-seantek-certspec=
/
> Htmlized:       https://tools.ietf.org/html/draft-seantek-certspec-06
> Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-seantek-certs=
pec-06
>=20
> Abstract:
>    Digital certificates are used in many systems and protocols to
>    identify and authenticate parties.  This document describes a string=

>    format that identifies certificates, along with optional attributes.=

>    This string format has been engineered to work without re-encoding i=
n
>    a variety of protocol slots.
>=20
>                                                                        =
         =20
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>=20


--------------ms000905080805060802060005
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MDkx
MzQ0NDJaMC8GCSqGSIb3DQEJBDEiBCB8YrDiKKdzxqu6u2qo+MTIYOUBONj72RQnMJXEh8x5
8jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQCk6UvKFFfD39P9QgtfaLQPSHxlm+IAqwPuY41fiOlySaCE2k31qCtu
Cp3+6wS/eCKlVSxcjzykdfGpqAyxXVO+wNt7DBvr76tjsdHPWq2YdchgbWsTg+r8dxMMezaO
GgT/WDty0eEur9KduAWrqa/dDPW01h9SKPXMv7klc8GJwup6KwmeYN7FiapDv4xBk8On3aNN
GA38Vx0+TEKNQDvDKZBV2MFLrN+ORC0Z7RzMhEvsRaS5jw8XUYkYuwAK+im+94s9y+HyGr/c
Rsz94H3T7YVObaFpGckFjGNWY6NRoYJhCkD9YoClOBybOJIe42iSgAvEYDPIrfG0Ue+1MWXR
AAAAAAAA
--------------ms000905080805060802060005--


From nobody Thu Jun  9 07:19:33 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2383E12D11F for ; Thu,  9 Jun 2016 07:19:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 JNzKlEZShPom for ; Thu,  9 Jun 2016 07:19:29 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 7A2B212D559 for ; Thu,  9 Jun 2016 07:19:28 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id k184so23154147wme.1 for ; Thu, 09 Jun 2016 07:19:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=kxlF2kxfp2iyrJoQ1eCeRM6rBjwgVRPzdfwP6+j65mk=; b=Wg8PdmbaWbhHAWjp5mVgLd4ko20klQzoQHybGL+Gp3PXweWvg4FN12dBNtxJy/AMLy fvICufUBSdX9u2NlVXFpEhqXGpECXLdhrpwUEG88W11DkxP0x3nkCvM42PkTdWio+lR/ 2Nz1VHimKUbPD8OAVDmnjFILS0EDDHuSc4CO9ZsckobRgOB0FWNn1xijTkKzsQwtcHm5 bNsYXq8WqJqGodDLNouEaXa1C4CfnqDwoG9nDnzOd99nc5sSeOwEDUUC1b3TRt/3dPfK zz/1sn3gKJITSq2NjcC+oXpZMG3Z2ZsFXrVlTkogntGJKjNkEDvKV43swMqX7Pc/r56F OoIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=kxlF2kxfp2iyrJoQ1eCeRM6rBjwgVRPzdfwP6+j65mk=; b=fhodQ5SkDQSF8X0MdPELmXZU5Mb0SOoSS2KL12rGXNB9V9hPNni3x+4oKuykooOtTE O4FEZBX3p6kBuXdawe0IICAUtp7HwNMrDDhLKPT/j50pPoUPGLQCCc12jzIkUvtVuY0e PF9Z3RHHfSkSp2jwUPBEADNBukDLBl7QT6g7k2CzECDMbkUPqtLQ+ThwZsK4yDseS8tA wNSjOQ3vHlSqD/glyfGE5rdaFltTpRkbP1RvZgNnMOGpoBbqqSvrMaL1seoOrrGPwfOr ZtN/c+EetpwAgjM+WlJaGOVp7bazg2S6tfLTqQG6rhtXyFcVlVb3Z5w8105UxTlRqH2M o2gg==
X-Gm-Message-State: ALyK8tKtlouZta6uu4/ij2UAUv7qkYDqSprtAmpvcixrQFcsW46zpL1bRzUzhgPO0nL5+Q==
X-Received: by 10.194.74.104 with SMTP id s8mr10109236wjv.20.1465481966959; Thu, 09 Jun 2016 07:19:26 -0700 (PDT)
Received: from [172.24.249.196] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id t1sm7354774wjy.3.2016.06.09.07.19.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Jun 2016 07:19:26 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_B8CCEE0A-6509-4F45-A1AB-0D936DC950BE"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.6b2
From: Yoav Nir 
In-Reply-To: <5759727D.8050009@cs.tcd.ie>
Date: Thu, 9 Jun 2016 17:19:22 +0300
Message-Id: 
References: <57519BBB.8050604@cs.tcd.ie> <5759727D.8050009@cs.tcd.ie>
To: Stephen Farrell 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "spasm@ietf.org" 
Subject: Re: [Spasm] BoF in Berlin or what?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 09 Jun 2016 14:19:31 -0000

--Apple-Mail=_B8CCEE0A-6509-4F45-A1AB-0D936DC950BE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 9 Jun 2016, at 4:43 PM, Stephen Farrell  =
wrote:
>=20
>=20
> Hiya,
>=20
> So I got a suggestion off list to maybe delete items 2 and
> 4 from the charter [1] for now and to proceed to charter a
> WG on that basis. The charter already says that addition of
> new work items requires a re-charter, so if other bits of work
> do need doing they can be added as real demand for them becomes
> apparent (and assuming the WG turns out to be productive).
>=20
> I think that leaves us with two choices:
>=20
> a) delete items 2 and 4 from [1] and I'll start the formal
> chartering process and schedule a WG meeting for Berlin,
>=20
> or,
>=20
> b) leave [1] as-is and we have a WG-forming BoF in Berlin.
>=20
> As of now, I prefer (a).

Me too.

We can dedicate a portion of WG time to the discussion of practicality =
vs what we think is right in item #2. There=E2=80=99s no reason to hold =
back stuff that can progress more quickly while getting that sorted out.

Yoav


--Apple-Mail=_B8CCEE0A-6509-4F45-A1AB-0D936DC950BE
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJXWXrrAAoJECXR4BOacZZUzm8H/A4eJ/5JspXPy3nXLWevhXGv
dwLPN2k50VoJlDDKQLPzTHECgiMuvvacPfQZL9U+CFp/1ioRuOTciZDe71KIHuvy
F0OtAaV3V/FCJFCIllc1tPvwv+rhUQtjiLkRrVBiYdSce4cOQcI9jxYM9Fg/+6YR
ExDo0Lz0dbUiVTPiS5w8QYCAkGj4cSBfS8CF3oBGWg6bJDx/zRJnsrYJEOJ11vKn
3shx1a9fHDcZq5zYeo7r9Kg8LEUiFDW35ZkApYasMes/jIvwISypbjaHFzp653gw
6vDXRldAP0bLsqgQjk4QvC7R2BctZ87j9z2UHTdKCXApkUZpOTEbMTP1H/bCsPg=
=wkdw
-----END PGP SIGNATURE-----

--Apple-Mail=_B8CCEE0A-6509-4F45-A1AB-0D936DC950BE--


From nobody Thu Jun  9 07:27:13 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53DB12D814 for ; Thu,  9 Jun 2016 07:27:11 -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 A4m7nljaydCq for ; Thu,  9 Jun 2016 07:27:10 -0700 (PDT)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::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 7749F12D802 for ; Thu,  9 Jun 2016 07:27:10 -0700 (PDT)
Received: by mail-qg0-x235.google.com with SMTP id v48so2584629qgd.2 for ; Thu, 09 Jun 2016 07:27:10 -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=cFk4BscQCSCnTSyB3svSuuExBGbB3lf6UmzQABi4Z3U=; b=d5Vr20HVL0fm+DSA9pSR6/oTrChKHuE/1icf+whtdVviF6MRehWvYX88ebV6FxWVW+ HiicNrcaP6VZ9kMGmQsn5skJ4t9fH9uLsI7eTbGd+gmsaCTa1b1r6GxlLgIYSbA98+7k 7hxIin0Di2xMGPnNnrVlcNbxckiv5wwVZsIoE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cFk4BscQCSCnTSyB3svSuuExBGbB3lf6UmzQABi4Z3U=; b=mHSnMY20e8OlpRO298mYSDun5B+jQ6ZIzqqEa3h+bdlZwfojdkYK6w3b1sYp8kNCpj 5n2T4LrG0n1X8jftYNdlST+Nmp2Oq9JooHynbto8u3/Zm97fRK5bj1llDSdRYPDUSyZH WbDys3wx38aA8y9R8p6nHthEtyRoweoLgPvxozDwApqUzfzsprICuN+LOSr8mKcYiTzA Kdp+Q5jqreql5mLZAU0Jo17njfs0ktXP7Q8fARti6rIitidJEka2BsXA154E01Phg4Ka m/NLharm6m21Z2qVFIx3Y5U1WAfDVKF/QRM1jhMhwHeN6/7LETVBGl+Ipqa2sJ8QAU1B +38Q==
X-Gm-Message-State: ALyK8tJ7F110ZWsaWPzAMYEEild+t8hjk4qjg5nTg4mx0cYWZ/oYjZAsCkNY+wxq/Sw18w==
X-Received: by 10.140.134.134 with SMTP id 128mr10538438qhg.63.1465482429633;  Thu, 09 Jun 2016 07:27:09 -0700 (PDT)
Received: from [5.5.33.199] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id h108sm1740458qgf.23.2016.06.09.07.27.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Jun 2016 07:27:09 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner 
In-Reply-To: 
Date: Thu, 9 Jun 2016 09:27:07 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <42A4D028-19D2-4DB9-AEF2-221E9FDBF640@sn3rd.com>
References: <57519BBB.8050604@cs.tcd.ie> <5759727D.8050009@cs.tcd.ie> 
To: Stephen Farrell 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "spasm@ietf.org" 
Subject: Re: [Spasm] BoF in Berlin or what?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 09 Jun 2016 14:27:12 -0000

On Jun 09, 2016, at 09:19, Yoav Nir  wrote:
>=20
>=20
>> On 9 Jun 2016, at 4:43 PM, Stephen Farrell =
 wrote:
>>=20
>>=20
>> Hiya,
>>=20
>> So I got a suggestion off list to maybe delete items 2 and
>> 4 from the charter [1] for now and to proceed to charter a
>> WG on that basis. The charter already says that addition of
>> new work items requires a re-charter, so if other bits of work
>> do need doing they can be added as real demand for them becomes
>> apparent (and assuming the WG turns out to be productive).
>>=20
>> I think that leaves us with two choices:
>>=20
>> a) delete items 2 and 4 from [1] and I'll start the formal
>> chartering process and schedule a WG meeting for Berlin,
>>=20
>> or,
>>=20
>> b) leave [1] as-is and we have a WG-forming BoF in Berlin.
>>=20
>> As of now, I prefer (a).
>=20
> Me too.
>=20
> We can dedicate a portion of WG time to the discussion of practicality =
vs what we think is right in item #2. There=E2=80=99s no reason to hold =
back stuff that can progress more quickly while getting that sorted out.
>=20
> Yoav

Not yelling against a; I=E2=80=99m yelling for a.

spt=


From nobody Thu Jun  9 07:37:04 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA8912D62F for ; Thu,  9 Jun 2016 07:37:02 -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 W50n2AfYd1Y4 for ; Thu,  9 Jun 2016 07:37:01 -0700 (PDT)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 EDB9012B018 for ; Thu,  9 Jun 2016 07:37:00 -0700 (PDT)
Received: by mail-lf0-x22b.google.com with SMTP id j5so27626673lfb.3 for ; Thu, 09 Jun 2016 07:37:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r/peqN2Oe7idhtEJhyqjhaA6aaaFIZNYb9KP1vm+FHY=; b=QU4q0icb0ShLnsHEiv1prT+Fg70GlcyzoD/gNiAjq0I7oymlSXmevctadKfObh2VXv MnsaS25U9qx1IBigFs5akUUsp9HwRLpf9whUwlFymtMjTPJHWkPHMTl9JtrUQAd4rB76 4XrupG2Gw3o4iAf8rL+Qw05OLp/IK4FNEFvhM471PtmKl4u32a7JPSovIRUa40LRG0R/ 0w6Wxm4ghiv2wrNbJI+q/XmZovTo2E/PFVkvdgr2sIrypHh46z7onrTe46cAzpw3wrhT fCp32p6z7JhN/6jqJwG8DuwQMstBzQQAz0SSoiOokX01bQMp/Nk8gutCw5BeFav+G7PO IG2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r/peqN2Oe7idhtEJhyqjhaA6aaaFIZNYb9KP1vm+FHY=; b=Bk1tmIDk8h7i51lSeHUdfA3k3RpIwkaeIG9Uv03a7bk9IWaGg5mLzhgo0OInKsKidD 5auPtMoIwb58F48un7EG0gCL+v8x1unASkqB/CElwL6t7bieYw2FH9eVgeDn/WmiaB7S I43RWNXhlgJJfxD1YHRhTn7+GarBB5ZVEtkg7wLi/150lle/W4XNjdAWZhIztXFP+Zmv 8+ZPaXX+Uumu8qfA3GuU2XM8O4zKc/oXsNfx2srF6uH8bqQLyH4R9nldQu30q925q6Tj QFjfLmLxadVC/uT8nAafF+zMJ+UHK49rwI3YWxDtjzOIwWQEMnepqTBoOEMaEpWWnJj7 vZGQ==
X-Gm-Message-State: ALyK8tJCUIgpxv6HBrEt6x7M4+RyyKDz4OrRkBK03r2EXBqJIRVhU2rjyi2p/HVLukmUa4uwvlJrgRnACqn5Lw==
X-Received: by 10.25.127.4 with SMTP id a4mr5944362lfd.111.1465483019215; Thu, 09 Jun 2016 07:36:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.41.1 with HTTP; Thu, 9 Jun 2016 07:36:58 -0700 (PDT)
In-Reply-To: <42A4D028-19D2-4DB9-AEF2-221E9FDBF640@sn3rd.com>
References: <57519BBB.8050604@cs.tcd.ie> <5759727D.8050009@cs.tcd.ie>  <42A4D028-19D2-4DB9-AEF2-221E9FDBF640@sn3rd.com>
From: Dmitry Belyavsky 
Date: Thu, 9 Jun 2016 17:36:58 +0300
Message-ID: 
To: Sean Turner 
Content-Type: multipart/alternative; boundary=001a113eb6e8c8ebb90534d95ad5
Archived-At: 
Cc: "spasm@ietf.org" , Stephen Farrell 
Subject: Re: [Spasm] BoF in Berlin or what?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 09 Jun 2016 14:37:02 -0000

--001a113eb6e8c8ebb90534d95ad5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello,

On Thu, Jun 9, 2016 at 5:27 PM, Sean Turner  wrote:

> On Jun 09, 2016, at 09:19, Yoav Nir  wrote:
> >
> >
> >> On 9 Jun 2016, at 4:43 PM, Stephen Farrell 
> wrote:
> >>
> >>
> >> Hiya,
> >>
> >> So I got a suggestion off list to maybe delete items 2 and
> >> 4 from the charter [1] for now and to proceed to charter a
> >> WG on that basis. The charter already says that addition of
> >> new work items requires a re-charter, so if other bits of work
> >> do need doing they can be added as real demand for them becomes
> >> apparent (and assuming the WG turns out to be productive).
> >>
> >> I think that leaves us with two choices:
> >>
> >> a) delete items 2 and 4 from [1] and I'll start the formal
> >> chartering process and schedule a WG meeting for Berlin,
> >>
> >> or,
> >>
> >> b) leave [1] as-is and we have a WG-forming BoF in Berlin.
> >>
> >> As of now, I prefer (a).
> >
> > Me too.
> >
> > We can dedicate a portion of WG time to the discussion of practicality
> vs what we think is right in item #2. There=E2=80=99s no reason to hold b=
ack stuff
> that can progress more quickly while getting that sorted out.
> >
> > Yoav
>
> Not yelling against a; I=E2=80=99m yelling for a.
>

Me too


--=20
SY, Dmitry Belyavsky

--001a113eb6e8c8ebb90534d95ad5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hello,

On Thu, Jun 9, 2016 at 5:27 PM, Sean Turner <sean@sn3rd.com> wrote:
On Jun 09, 2016, at 09:19, Yoav Nir <ynir.ietf@gmail.com> wrote:

>

>

>> On 9 Jun 2016, at 4:43 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

>>

>>

>> Hiya,

>>

>> So I got a suggestion off list to maybe delete items 2 and

>> 4 from the charter [1] for now and to proceed to charter a

>> WG on that basis. The charter already says that addition of

>> new work items requires a re-charter, so if other bits of work

>> do need doing they can be added as real demand for them becomes
>> apparent (and assuming the WG turns out to be productive).

>>

>> I think that leaves us with two choices:

>>

>> a) delete items 2 and 4 from [1] and I'll start the formal

>> chartering process and schedule a WG meeting for Berlin,

>>

>> or,

>>

>> b) leave [1] as-is and we have a WG-forming BoF in Berlin.

>>

>> As of now, I prefer (a).

>

> Me too.

>

> We can dedicate a portion of WG time to the discussion of practicality=
 vs what we think is right in item #2. There=E2=80=99s no reason to hold ba=
ck stuff that can progress more quickly while getting that sorted out.

>

> Yoav




Not yelling against a; I=E2=80=99m yelling for a.

Me too


-=
- 
SY,=
 Dmitry Belyavsky




--001a113eb6e8c8ebb90534d95ad5--


From nobody Thu Jun  9 08:40:43 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F2012D13B for ; Thu,  9 Jun 2016 08:40:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 75SRY4w7CgKm for ; Thu,  9 Jun 2016 08:40:39 -0700 (PDT)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 F2E8412D0DC for ; Thu,  9 Jun 2016 08:40:38 -0700 (PDT)
Received: by mail-oi0-x235.google.com with SMTP id k23so69547860oih.0 for ; Thu, 09 Jun 2016 08:40:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=frpPH8LBDjyenuablkpuzFDRlXntAwVmKtJ2UitdeAg=; b=dLgcBKX44I8zazUPnzmQWwGrhUSnS6P4NErSZ29PxYEA941b1ClDe7pfIdLwZrrlTk mez0z3+On3DDaHzNvGKH9aw54PJg/EWINwKOGEh6g2UWmOa1S3nxLwgmcrVTCxzWsba5 wBOl+L5Us+ZoEAWwUU/170bvL76RoIytz4RsFr17NfTQj74awjqRiaktH/RylBNll3PZ MXLRNSNL9VmkJVfW3fK5FThGwQQMkZQ3BmdQmNO7X8610ZwOdY7sW4k35qYJo1k27WBp 1MB2mZvKudBhkvQdrRx2OOFvQw6GsCE0+SVZVBVucwEBjn9KYrxNZY/v53LZE2gbcprY WSjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=frpPH8LBDjyenuablkpuzFDRlXntAwVmKtJ2UitdeAg=; b=U0ezknjV2c7Y7jn+FBAeBl0c/prZ97uA/SvqhVNJ9jvlRi837x4A38YLSeZxIDDz6Z PgyHHXfKH6Y4IYss9hSqu3j1bX/1CC0dDeezfkov8MWxCaa8HJ+y58ynyJgMiw/dqTsj hFWJ0Bk2kmfEZXJNxyfNqsLPu0sy3rHUtJpaYOiHJZzaVLKxVfews58X6hxAuiFzNYXE ni6UxQk5KCwGMdnBRAmD2Q787dHAUmbA2Hg6J8VtVZzIeX2ID0EzbLL6PfTlCdTZY93S tAL1lDPKvVZGy1v+KYd/LP/O/noYOHOV6vq1NtcYO6UDn2bjuOungWuCiABX8sTi875F 3nRw==
X-Gm-Message-State: ALyK8tKV/Wd19iL3+QF3pxzSCsrWFWYIpiFnZvUMMCULposkyi7OReyV1PV8pJ5aOqA8wh3n34xOVEBBJd7GdZ/F
X-Received: by 10.202.85.139 with SMTP id j133mr4104246oib.166.1465486837779;  Thu, 09 Jun 2016 08:40:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.1.67 with HTTP; Thu, 9 Jun 2016 08:40:36 -0700 (PDT)
In-Reply-To: 
References: <57519BBB.8050604@cs.tcd.ie> <5759727D.8050009@cs.tcd.ie>  <42A4D028-19D2-4DB9-AEF2-221E9FDBF640@sn3rd.com> 
From: Wei Chuang 
Date: Thu, 9 Jun 2016 08:40:36 -0700
Message-ID: 
To: Dmitry Belyavsky 
Content-Type: multipart/alternative; boundary=001a113def7c6428020534da3e78
Archived-At: 
Cc: "spasm@ietf.org" , Sean Turner , Stephen Farrell 
Subject: Re: [Spasm] BoF in Berlin or what?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 09 Jun 2016 15:40:41 -0000

--001a113def7c6428020534da3e78
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On Thu, Jun 9, 2016 at 7:36 AM, Dmitry Belyavsky  wrote:

> Hello,
>
> On Thu, Jun 9, 2016 at 5:27 PM, Sean Turner  wrote:
>
>> On Jun 09, 2016, at 09:19, Yoav Nir  wrote:
>> >
>> >
>> >> On 9 Jun 2016, at 4:43 PM, Stephen Farrell 
>> wrote:
>> >>
>> >>
>> >> Hiya,
>> >>
>> >> So I got a suggestion off list to maybe delete items 2 and
>> >> 4 from the charter [1] for now and to proceed to charter a
>> >> WG on that basis. The charter already says that addition of
>> >> new work items requires a re-charter, so if other bits of work
>> >> do need doing they can be added as real demand for them becomes
>> >> apparent (and assuming the WG turns out to be productive).
>> >>
>> >> I think that leaves us with two choices:
>> >>
>> >> a) delete items 2 and 4 from [1] and I'll start the formal
>> >> chartering process and schedule a WG meeting for Berlin,
>> >>
>> >> or,
>> >>
>> >> b) leave [1] as-is and we have a WG-forming BoF in Berlin.
>> >>
>> >> As of now, I prefer (a).
>> >
>> > Me too.
>> >
>> > We can dedicate a portion of WG time to the discussion of practicality
>> vs what we think is right in item #2. There’s no reason to hold back stuff
>> that can progress more quickly while getting that sorted out.
>> >
>> > Yoav
>>
>> Not yelling against a; I’m yelling for a.
>>
>
> Me too
>

In case it wasn't clear from before, my vote is for a.

thanks,
-Wei


>
>
> --
> SY, Dmitry Belyavsky
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>
>

--001a113def7c6428020534da3e78
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit




On Thu, Jun 9, 2016 at 7:36 AM, Dmitry Belyavsky <beldmit@gmail.com> wrote:
Hello,

On Thu, Jun 9, 2016 at 5:27 PM, Sean Turner <sean@sn3rd.com> wrote:
On Jun 09, 2016, at 09:19, Yoav Nir <ynir.ietf@gmail.com> wrote:

>

>

>> On 9 Jun 2016, at 4:43 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

>>

>>

>> Hiya,

>>

>> So I got a suggestion off list to maybe delete items 2 and

>> 4 from the charter [1] for now and to proceed to charter a

>> WG on that basis. The charter already says that addition of

>> new work items requires a re-charter, so if other bits of work

>> do need doing they can be added as real demand for them becomes

>> apparent (and assuming the WG turns out to be productive).

>>

>> I think that leaves us with two choices:

>>

>> a) delete items 2 and 4 from [1] and I'll start the formal

>> chartering process and schedule a WG meeting for Berlin,

>>

>> or,

>>

>> b) leave [1] as-is and we have a WG-forming BoF in Berlin.

>>

>> As of now, I prefer (a).

>

> Me too.

>

> We can dedicate a portion of WG time to the discussion of practicality vs what we think is right in item #2. There’s no reason to hold back stuff that can progress more quickly while getting that sorted out.

>

> Yoav




Not yelling against a; I’m yelling for a.

Me too

In case it wasn't clear from before, my vote is for a.

thanks,
-Wei
 


-- 
SY, Dmitry Belyavsky




_______________________________________________

Spasm mailing list

Spasm@ietf.org

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





--001a113def7c6428020534da3e78--


From nobody Thu Jun  9 10:49:08 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6DA12D176 for ; Thu,  9 Jun 2016 10:49:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 f9n-DaYA6-Vv for ; Thu,  9 Jun 2016 10:49:04 -0700 (PDT)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 72EDF12D576 for ; Thu,  9 Jun 2016 10:49:04 -0700 (PDT)
Received: by mail-oi0-x22c.google.com with SMTP id k23so75422500oih.0 for ; Thu, 09 Jun 2016 10:49:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YGt+LYtP74UTUTsHpuRlenuFRpWSWea523M7MJgWuw8=; b=h0nHp72l6ks49GLtyKX0jhbJftoA8yxJ+aCGJti7xi+Opni8/MWurZI3SInTiVZ1va rYmVID21NrXFF0nYEsLVp/HKFM2sw+Csx1G0boE7+vToDZlbi1xtkcfC/XdSrARjMBZF IwnSLV7Reu2Z7YCNi6GOgt2EKYLW6r39PT8epFWy49yszmmW6id0ytkrI7mqLXwGolzS hnMK//loQM4YW5YaU4DSo8APqnWzBHSzUFKHRhfA2kCXCiCrJq+Hsqp8n7Y4Yi3rUSEW Dp1F+BC1a5c/tSViPQN3NSPETb9ZNx7AsnHbYnaW1T87d7BRLLm1Ze2iu8gexTb6U3Bi K/xA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YGt+LYtP74UTUTsHpuRlenuFRpWSWea523M7MJgWuw8=; b=Lwhoq9743DzEXf99uGPqMMxqVtK3fHwQpFka8apWu6jK5sR98HTguu/stiKwyTSp3s RVxI8aoFhkOwkykA9DtKKDYQGVrQin7CAwMdiy2m4zx9zFJMk8g4RT6HNz2IMwbEm87W u44V8yR78CBM4fnYA22o08AVJMtLFZtyCVcOvW6HVkX/WWtL9bDKC46x+Wdgw/fcUA6l a4VhhyrmD7ZzsxAd0Y/UTUeb/46GexHAeaclsGzlEywjEnUQijTqrSIGTg1Kez78i1AP HmPKQgarC3o9+cpyc33EfZg511cb5ebj0KNKLEwdj53ZW2qbX4p6EYMH3FfiM07J24xY 6TNA==
X-Gm-Message-State: ALyK8tLT36DXZtxxcrpzH+IzkDrYw8HkJDnDts5drCb9bwgAr0Zz/5+6auzW8gkFdgR3Qjs2oABn3CRSdMFUylht
X-Received: by 10.202.232.77 with SMTP id f74mr5946216oih.128.1465494543222; Thu, 09 Jun 2016 10:49:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.1.67 with HTTP; Thu, 9 Jun 2016 10:49:02 -0700 (PDT)
In-Reply-To: 
References: <20160608161629.19935.86198.idtracker@ietfa.amsl.com> 
From: Wei Chuang 
Date: Thu, 9 Jun 2016 10:49:02 -0700
Message-ID: 
To: Sean Leonard 
Content-Type: multipart/alternative; boundary=001a1141b0a0abad3c0534dc09d5
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] certspec work (draft-seantek-certspec-06.txt)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 09 Jun 2016 17:49:07 -0000

--001a1141b0a0abad3c0534dc09d5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Just some thoughts about this draft:

1. The title is a little bit confusing, as much of the document is about
naming certificates.  Perhaps "Naming and Metadata Specification for..."?
2. This document would do best when coupled with work on methods to access
certificates such as draft-bhjl-x509-srv-00 that would use it.
3. Modify the ABNF to clearly identify the certspec type vs data
4. Another naming method I'm aware of is CRLSets used in Chromium:
https://dev.chromium.org/Home/chromium-security/crlsets
This might be something to consider and possibly mention in section 6 "Other
Certificate Specifications".
5. Can more motivation be provided for attribute section 8?

thanks,
-Wei

On Wed, Jun 8, 2016 at 9:28 AM, Sean Leonard  wrote:

> Hello SPASM:
>
> I would like to propose "certspec" as a work item for this WG, and that it
> be considered in-scope as we debate the WG's scope.
>
> certspec is a string specification for certificates. It allows protocols
> and systems to identify a certificate in a textual form, and is designed
> with human usability in mind (specifically, copy-and-paste operations).
>
> Previous versions of this draft tried to define certspec as a URN, and
> then as a series of URI schemes. Those approaches were not successful. This
> draft just calls it a string. You can look at the diffs (particularly the
> diff between 04 and 05) to see the differences.
>
> Thanks to Russ Housley for feedback on the most recent versions of this
> draft.
>
> Regards,
>
> Sean
>
> -------- Forwarded Message --------
> Subject:        New Version Notification for draft-seantek-certspec-06.txt
> Date:   Wed, 08 Jun 2016 09:16:29 -0700
> From:   internet-drafts@ietf.org
>
>
>
> A new version of I-D, draft-seantek-certspec-06.txt
> has been successfully submitted by Sean Leonard and posted to the
> IETF repository.
>
> Name:           draft-seantek-certspec
> Revision:       06
> Title:          String Specification for Certificates
> Document date:  2016-06-08
> Group:          Individual Submission
> Pages:          27
> URL:            https://www.ietf.org/internet-
> drafts/draft-seantek-certspec-06.txt
> Status:         https://datatracker.ietf.org/doc/draft-seantek-certspec/
> Htmlized:       https://tools.ietf.org/html/draft-seantek-certspec-06
> Diff:           https://www.ietf.org/rfcdiff?
> url2=draft-seantek-certspec-06
>
> Abstract:
>    Digital certificates are used in many systems and protocols to
>    identify and authenticate parties.  This document describes a string
>    format that identifies certificates, along with optional attributes.
>    This string format has been engineered to work without re-encoding in
>    a variety of protocol slots.
>
>
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>

--001a1141b0a0abad3c0534dc09d5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


Just some thoughts about this draft:

1. The title is a little bit confusing, as much of the document is about naming certificates.  Perhaps "Naming and Metadata Specification for..."?
2. This document would do best when coupled with work on methods to access certificates such as draft-bhjl-x509-srv-00 that would use it. 
3. Modify the ABNF to clearly identify the certspec type vs data
4. Another naming method I'm aware of is CRLSets used in Chromium: https://dev.chromium.org/Home/chromium-security/crlsets
This might be something to consider and possibly mention in section 6 "Other Certificate Specifications".
5. Can more motivation be provided for attribute section 8?

thanks,
-Wei

On Wed, Jun 8, 2016 at 9:28 AM, Sean Leonard <dev+ietf@seantek.com> wrote:
Hello SPASM:



I would like to propose "certspec" as a work item for this WG, and that it be considered in-scope as we debate the WG's scope.



certspec is a string specification for certificates. It allows protocols and systems to identify a certificate in a textual form, and is designed with human usability in mind (specifically, copy-and-paste operations).



Previous versions of this draft tried to define certspec as a URN, and then as a series of URI schemes. Those approaches were not successful. This draft just calls it a string. You can look at the diffs (particularly the diff between 04 and 05) to see the differences.



Thanks to Russ Housley for feedback on the most recent versions of this draft.



Regards,



Sean



-------- Forwarded Message --------

Subject:        New Version Notification for draft-seantek-certspec-06.txt

Date:   Wed, 08 Jun 2016 09:16:29 -0700

From:   internet-drafts@ietf.org







A new version of I-D, draft-seantek-certspec-06.txt

has been successfully submitted by Sean Leonard and posted to the

IETF repository.



Name:           draft-seantek-certspec

Revision:       06

Title:          String Specification for Certificates

Document date:  2016-06-08

Group:          Individual Submission

Pages:          27

URL:            https://www.ietf.org/internet-drafts/draft-seantek-certspec-06.txt

Status:         https://datatracker.ietf.org/doc/draft-seantek-certspec/

Htmlized:       https://tools.ietf.org/html/draft-seantek-certspec-06

Diff:           https://www.ietf.org/rfcdiff?url2=draft-seantek-certspec-06



Abstract:

   Digital certificates are used in many systems and protocols to

   identify and authenticate parties.  This document describes a string

   format that identifies certificates, along with optional attributes.

   This string format has been engineered to work without re-encoding in

   a variety of protocol slots.



                                                                                  

_______________________________________________

Spasm mailing list

Spasm@ietf.org

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





--001a1141b0a0abad3c0534dc09d5--


From nobody Thu Jun  9 13:17:08 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F45612D9DF for ; Thu,  9 Jun 2016 13:17:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 BjnW-O-I8TS0 for ; Thu,  9 Jun 2016 13:17:05 -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 63B3412D9DC for ; Thu,  9 Jun 2016 13:17:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 30F733002C2 for ; Thu,  9 Jun 2016 16:17: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 dELw23eERthk for ; Thu,  9 Jun 2016 16:17:02 -0400 (EDT)
Received: from [172.26.104.58] (63-158-178-242.dia.static.qwest.net [63.158.178.242]) by mail.smeinc.net (Postfix) with ESMTPSA id 86D9830004F; Thu,  9 Jun 2016 16:17:01 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <5759727D.8050009@cs.tcd.ie>
Date: Thu, 9 Jun 2016 16:17:01 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <6F644F2D-6A23-4A14-A18A-7C6899E254EC@vigilsec.com>
References: <57519BBB.8050604@cs.tcd.ie> <5759727D.8050009@cs.tcd.ie>
To: Stephen Farrell 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: "spasm@ietf.org" 
Subject: Re: [Spasm] BoF in Berlin or what?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 09 Jun 2016 20:17:07 -0000

Stephen:

I think we should move forward with option a).

Russ


On Jun 9, 2016, at 9:43 AM, Stephen Farrell  =
wrote:

>=20
> Hiya,
>=20
> So I got a suggestion off list to maybe delete items 2 and
> 4 from the charter [1] for now and to proceed to charter a
> WG on that basis. The charter already says that addition of
> new work items requires a re-charter, so if other bits of work
> do need doing they can be added as real demand for them becomes
> apparent (and assuming the WG turns out to be productive).
>=20
> I think that leaves us with two choices:
>=20
> a) delete items 2 and 4 from [1] and I'll start the formal
> chartering process and schedule a WG meeting for Berlin,
>=20
> or,
>=20
> b) leave [1] as-is and we have a WG-forming BoF in Berlin.
>=20
> As of now, I prefer (a).
>=20
> I'll need to decide in the next 24 hours (the BoF scheduling
> call is then), though it's not a final decision, as plan (a)
> of course requires an at least 2-week period when the IETF
> can comment on the new WG before it's formally created.
>=20
> So, please yell now if you think (a) is unacceptable.
>=20
> Cheers,
> S.
>=20
> PS: I think John Levine took an action to try check if
> item 4 might actually get deployed when he's at the m3aawg
> meeting next week. If that seems to garner consensus that
> some reasonable level of deployment is likely, I'd be fine
> with adding item 4 back during the chartering process.
>=20
> [1] https://datatracker.ietf.org/doc/charter-ietf-spasm/
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


From nobody Fri Jun 10 09:40:33 2016
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 2CAFD12D668; Fri, 10 Jun 2016 09:40:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Meeting Session Request Tool\"" 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.21.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160610164032.30478.67524.idtracker@ietfa.amsl.com>
Date: Fri, 10 Jun 2016 09:40:32 -0700
Archived-At: 
Cc: spasm@ietf.org, avezza@amsl.com, spasm-chairs@ietf.org, stephen.farrell@cs.tcd.ie
Subject: [Spasm] spasm - New Meeting Session Request for IETF 96
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "This is a venue 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, 10 Jun 2016 16:40:32 -0000

A new meeting session request has just been submitted by Amy K. Vezza, on behalf of the spasm working group.


---------------------------------------------------------
Working Group Name: Some PKIX and SMIME
Area Name: Security Area
Session Requester: Amy Vezza

Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 25
Conflicts to Avoid: 
 First Priority:  saag tls




Special Requests:
  There is a note in BoF Wiki there will be more conflicts but they are not listed.
---------------------------------------------------------


From nobody Fri Jun 10 09:43:20 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2FA812D127 for ; Fri, 10 Jun 2016 09:43:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level: 
X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LGFUonKIVRc for ; Fri, 10 Jun 2016 09:43:16 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB61112D5FB for ; Fri, 10 Jun 2016 09:43:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 34960BE2D for ; Fri, 10 Jun 2016 17:43:15 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJ7fae8GquXu for ; Fri, 10 Jun 2016 17:43:13 +0100 (IST)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6F92BBE2C for ; Fri, 10 Jun 2016 17:43:13 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1465576993; bh=VFV8LdHgKVZFPdo1Qefr2T1u2H4cV3ttC4+BfCIsT44=; h=Subject:References:To:From:Date:In-Reply-To:From; b=MyvQDvwUxCoHNIVM4rfwUGqMIpgL8PDBm4TBDfk53BkXd0dovgA2KGeZsf0kv8Q5n mcpRLtFQ+nqDuu5QQ0mCPMtHo2XNkHbpeBqRs2+VohozpTmKT16dlBicOEtAjU5rQC O7urBCJqe7uGiBHcyHJTyDxpFFRH1pmnwm//Kwzo=
References: <20160610164032.30478.67524.idtracker@ietfa.amsl.com>
To: spasm@ietf.org
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <575AEE21.7080700@cs.tcd.ie>
Date: Fri, 10 Jun 2016 17:43:13 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <20160610164032.30478.67524.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090409070201030005040607"
Archived-At: 
Subject: Re: [Spasm] spasm - New Meeting Session Request for IETF 96
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 10 Jun 2016 16:43:19 -0000

This is a cryptographically signed message in MIME format.

--------------ms090409070201030005040607
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hi all,

We're going with plan (a) so:-)

Cheers,
S.

On 10/06/16 17:40, "IETF Meeting Session Request Tool" wrote:
>=20
>=20
> A new meeting session request has just been submitted by Amy K.
> Vezza, on behalf of the spasm working group.
>=20
>=20
> --------------------------------------------------------- Working
> Group Name: Some PKIX and SMIME Area Name: Security Area Session
> Requester: Amy Vezza
>=20
> Number of Sessions: 1 Length of Session(s):  1 Hour Number of
> Attendees: 25 Conflicts to Avoid: First Priority:  saag tls
>=20
>=20
>=20
>=20
> Special Requests: There is a note in BoF Wiki there will be more
> conflicts but they are not listed.=20
> ---------------------------------------------------------
>=20
> _______________________________________________ Spasm mailing list=20
> Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm
>=20


--------------ms090409070201030005040607
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MTAx
NjQzMTNaMC8GCSqGSIb3DQEJBDEiBCDKAlncOpTNipBWL01b1p3txXBFt3g/LFcHcWF43kfn
8zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQAmIPoqhwHzN4W5CwsbOgV8A1ofXQx0v25tDkJasUKMe/i22TEhv4sC
werM7l5cPMncskro46agsesgF3DhJ/ZVz5rI36UuC2XJI3G95IjuC8HXCai/qg+f6qabAGZ2
La4jADdt0qL5tuZPADHbHmZaZIXTi6CXn1q3FXNCN1q4/OmKmcx8aXmAHU9BvY/V2l0CvtcH
gj0annIBsJwzs0fnVn1jQg0tkIj4L9LSG6W2vmnBXFvwNcyG7U1lZiKkFNDPSwTxIaLRjH6V
TqsHH+FKklbWLrdwOrzjVYc8gC2FjAt8oEFLXT/onjVkJxAotds0I3ISrETTwbiLu5L+jnLE
AAAAAAAA
--------------ms090409070201030005040607--


From nobody Fri Jun 10 10:56:10 2016
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 781E812D895; Fri, 10 Jun 2016 10:56:06 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.21.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160610175606.18152.48021.idtracker@ietfa.amsl.com>
Date: Fri, 10 Jun 2016 10:56:06 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [Spasm] ID Tracker State Update Notice: 
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "This is a venue 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, 10 Jun 2016 17:56:06 -0000

State changed to Internal review.
ID Tracker URL: https://datatracker.ietf.org/doc/charter-ietf-spasm/


From nobody Fri Jun 10 10:56:28 2016
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 CD98B12D875; Fri, 10 Jun 2016 10:56:23 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: , "The IESG" , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.21.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160610175623.18214.51524.idtracker@ietfa.amsl.com>
Date: Fri, 10 Jun 2016 10:56:23 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [Spasm] Telechat update notice: 
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "This is a venue 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, 10 Jun 2016 17:56:24 -0000

Placed on agenda for telechat - 2016-06-16
ID Tracker URL: https://datatracker.ietf.org/doc/charter-ietf-spasm/


From nobody Fri Jun 10 12:27:39 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BEF128B44 for ; Fri, 10 Jun 2016 12:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level: 
X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLoSYwZ59I29 for ; Fri, 10 Jun 2016 12:27:34 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C35612D13E for ; Fri, 10 Jun 2016 12:27:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 95865BE2D for ; Fri, 10 Jun 2016 20:27:31 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNg2B9TFQEY5 for ; Fri, 10 Jun 2016 20:27:27 +0100 (IST)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B0168BE2C for ; Fri, 10 Jun 2016 20:27:26 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1465586847; bh=ZdhGASLpkjBD/wni5KMqhpeHrC5DVQkdG7/Ze2D22Dk=; h=To:From:Subject:Date:From; b=jPvfOsJybHe17kh4RQv5f+8YaN5T6M7m1wCvcC0wHkYXRo7bgMTWfPndJ30VMtC0f iKrd3uO5lGnEvJ+bPm9i+B73a2UisJ3G101/TNggcgg/gqNAPDkQ86e8KEkBmyX5pt P/p1OhR/pgqiE2PmwPT7zycLvdPoIjJkqeV63IQw=
To: "spasm@ietf.org" 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <575B149E.5020901@cs.tcd.ie>
Date: Fri, 10 Jun 2016 20:27:26 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080705010303060005090202"
Archived-At: 
Subject: [Spasm] updated charter text and next steps...
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 10 Jun 2016 19:27:38 -0000

This is a cryptographically signed message in MIME format.

--------------ms080705010303060005090202
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

I've updated the draft charter [1] as I think the list
wanted, please correct me if I goofed. Changes are:

- deleted previous work items 2 and 4
- changed to draft-melnikov-spasm-eai-addresses for
  item 1

This is on the IESG telechat for next Thursday June 16th.
After that all going well it goes out for a 2 week review
by whoever cares and then would be back to the IESG for
approval of the final charter and WG creation. So if that
all happens with no delay this should be a WG on June 30th.

If you have comments on the charter now, this list is probably
best. If you have comments on it during the 2 week external
review period, posting those to ietf@ietf.org (as well or
instead as you think) is the right thing to do.

I'll keep the list posted as to status in the meantime.

Cheers,
S.

[1] https://datatracker.ietf.org/doc/charter-ietf-spasm/


--------------ms080705010303060005090202
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MTAx
OTI3MjZaMC8GCSqGSIb3DQEJBDEiBCCZotKl5bnWniiZ19w/JS12BG73mk59fhHOoHougs74
JTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQBxTqLn0EA35yow7R4vcXGxGE/IszAy6LfD7NXm8fEERVdG1eJkxmuV
SDTbToHO/XnbvMYY+iCAayfHOA4xDz8XrnM6eSxtKpXFstk5Nmk5L7CtrW7+FPzUUwe12CiY
iO0idYOB2nW2fCxEC0EQ1B8rWr7K6osRrlFIvvb20rmQNNXouxLah/RGb6mECDKm6Zy2miF8
sakkz14eh4D2t8DQFg3WJD22KWr6Xrmy2+rd7Jx6L3JIf0bcW44cP0jZRE6zNDS75MtkuXRW
RgaGcw652L+7onHn2SQISlY+w1Cr/wliBjvwulIJMoThtLCydmpUSJQFyeqhxOUst6pNoWxx
AAAAAAAA
--------------ms080705010303060005090202--


From nobody Fri Jun 10 14:20:51 2016
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 DE06912D69E; Fri, 10 Jun 2016 14:20:49 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Meeting Session Request Tool\"" 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.21.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160610212049.18265.62521.idtracker@ietfa.amsl.com>
Date: Fri, 10 Jun 2016 14:20:49 -0700
Archived-At: 
Cc: spasm@ietf.org, spasm-chairs@ietf.org, stephen.farrell@cs.tcd.ie
Subject: [Spasm] spasm - Update to a Meeting Session Request for IETF 96
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "This is a venue 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, 10 Jun 2016 21:20:50 -0000

An update to a meeting session request has just been submitted by Stephen Farrell, a SEC Area Director.


---------------------------------------------------------
Working Group Name: Some PKIX and SMIME
Area Name: Security Area
Session Requester: Stephen Farrell

Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 25
Conflicts to Avoid: 
 First Priority: saag tls stir curdle trans artarea




Special Requests:
  There is a note in BoF Wiki there will be more conflicts but they are not listed.
Conflicts added by SF afterwards.
---------------------------------------------------------


From nobody Fri Jun 10 16:12:46 2016
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 8A17C12B04C; Fri, 10 Jun 2016 16:12:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Meeting Session Request Tool\"" 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.21.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160610231244.18233.21035.idtracker@ietfa.amsl.com>
Date: Fri, 10 Jun 2016 16:12:44 -0700
Archived-At: 
Cc: spasm@ietf.org, spasm-chairs@ietf.org, stephen.farrell@cs.tcd.ie
Subject: [Spasm] spasm - Update to a Meeting Session Request for IETF 96
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "This is a venue 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, 10 Jun 2016 23:12:45 -0000

An update to a meeting session request has just been submitted by Stephen Farrell, a SEC Area Director.


---------------------------------------------------------
Working Group Name: Some PKIX and SMIME
Area Name: Security Area
Session Requester: Stephen Farrell

Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 25
Conflicts to Avoid: 
 First Priority: artarea trans curdle stir tls saag




Special Requests:
  If he its BoF happens, please don't conflict with that

There is a note in BoF Wiki there will be more conflicts but they are not listed.
Conflicts added by SF afterwards.
---------------------------------------------------------


From nobody Tue Jun 14 02:03:26 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A91212D122 for ; Tue, 14 Jun 2016 02:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 RYE_h6xoSY1E for ; Tue, 14 Jun 2016 02:03:22 -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 9D2C8127058 for ; Tue, 14 Jun 2016 02:03:21 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 52CA550A73; Tue, 14 Jun 2016 05:03:20 -0400 (EDT)
To: Wei Chuang 
References: <20160608161629.19935.86198.idtracker@ietfa.amsl.com>  
From: Sean Leonard 
Message-ID: 
Date: Tue, 14 Jun 2016 02:03:50 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------30C29AD50E50425E0CB0EDB6"
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] certspec work (draft-seantek-certspec-06.txt)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 14 Jun 2016 09:03:24 -0000

This is a multi-part message in MIME format.
--------------30C29AD50E50425E0CB0EDB6
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

Thank you for the feedback. Based on time, I will respond in multiple=20
e-mails, and out of order...

On 6/9/2016 10:49 AM, Wei Chuang wrote:
> Just some thoughts about this draft:

> 5. Can more motivation be provided for attribute section 8?

Okay. Well I am not sure if more motivation needs to be provided than=20
the first paragraph:

    A certificate can have additional attributes (i.e., metadata)
    operatively associated with--but not intrinsic to--it.  For example,
    the additional attributes may represent preferences.  The syntax is
    intended primarily to convey certificate metadata such as attributes
    found in PKCS #9 [RFC2985], PKCS #11 [PKCS11], PKCS #12 [RFC7292],
    and particular implementations of cryptographic libraries.

However, I suppose that I can provide some backstory.

Many certificate owners (taken broadly, I mean users and systems that=20
actually use certificates on a semi-regular basis, and that hold the=20
corresponding private keys) have preferences attached to those=20
certificates, much like SSH key owners attach metadata to their keys.=20
"friendlyName" is the obvious example. I'm pretty sure all of us around=20
here name our SSH keys certain things, like "use this with foo server"=20
or "generated on my Mac Mini in June". An SSH key's filename also=20
constitutes metadata; ditto for certificates, although certificates with =

private keys tend to get serialized as PKCS #12. I needed a way to store =

the friendly name of a certificate, which is a piece of information that =

people care about but can change more-or-less at will. It has security=20
implications to the extent that it's shown to users, or used as a basis=20
for certificate selection. Some Mozilla NSS-based workflows identify=20
certificates based on the friendly name (NSS calls it "nickname", but=20
uses the same construct).

For S/MIME purposes, there's also smimeCapabilities. Smart clients are=20
supposed to cache smimeCapabilities and track them over time: see RFC=20
5751 for discussion. Of course, not many actually do this. But for=20
tracking purposes, associating smimeCapabilities with the corresponding=20
signing and encryption certificates of messages makes sense.

Manipulating X.690 (BER, CER, DER) is not practical, so we need a=20
textual format for these attributes that does not reinvent the wheel.=20
friendlyName is straightforward: it's just a string, suitably escaped.=20
LDAP string encoding provides some escapes so why not use that.=20
smimeCapabilities is more complicated, so in order not to reinvent the=20
wheel, one can just use ASN.1 value notation directly to get the job=20
done. I threw in the other two from PKCS #9 (localKeyId and=20
signingDescription) for completeness and because they have trivial LDAP=20
string representations. Other attributes are in use, particularly in=20
PKCS #12 blobs, but those attributes tend to be vendor-specific.

What draft-06 calls "certattrs" could easily just be "pkixattrs" or=20
"cmsattrs", since they all are drawing from the same attribute space. I=20
suppose one could go even further and specify an LDAP string format that =

applies to any SET SIZE (1..MAX) OF Attribute. I thought about doing it=20
but didn't go that far in certspec-06.

> 4. Another naming method I'm aware of is CRLSets used in Chromium:=20
> https://dev.chromium.org/Home/chromium-security/crlsets
> This might be something to consider and possibly mention in section 6=20
> "Other Certificate Specifications".

Wei, can you provide more specifics on what you mean when you say=20
"another naming method": do you want a way to identify CRLSets, or are=20
you asking for documentation on how CRLSets identify certificates?

I am only somewhat familiar with CRLSets, but I was under the impression =

that an entry in a (the) CRLSet identifies a certificate by one of:=20
SHA-256 fingerprint, SHA-256 hash of the public key (SPKI), or SHA-256=20
hashes of one of the former two split up into a Merkle tree. I also was=20
under the impression that CRLSets are encoded in JSON and do not have a=20
canonical encoding form: because of this, it's difficult to say that a=20
CRLSet can be identified by a cryptographic fingerprint in any reliable w=
ay.

Best regards,

Sean

--------------30C29AD50E50425E0CB0EDB6
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Thank you for the feedback. Based on
      time, I will respond in multiple e-mails, and out of order...

      

      On 6/9/2016 10:49 AM, Wei Chuang wrote:

    

    

      
Just some thoughts about this draft:

      

    

    

    

      

        
5. Can more motivation be provided for attribute section 8?

      

    

    

    Okay. Well I am not sure if more motivation needs to be provided
    than the first paragraph:

    

       A certificate can have additional attributes (i.e., metadata)

       operatively associated with--but not intrinsic to--it.  For
    example,

       the additional attributes may represent preferences.  The syntax
    is

       intended primarily to convey certificate metadata such as
    attributes

       found in PKCS #9 [RFC2985], PKCS #11 [PKCS11], PKCS #12
    [RFC7292],

       and particular implementations of cryptographic libraries.

    

    However, I suppose that I can provide some backstory.

    

    Many certificate owners (taken broadly, I mean users and systems
    that actually use certificates on a semi-regular basis, and that
    hold the corresponding private keys) have preferences attached to
    those certificates, much like SSH key owners attach metadata to
    their keys. "friendlyName" is the obvious example. I'm pretty sure
    all of us around here name our SSH keys certain things, like "use
    this with foo server" or "generated on my Mac Mini in June". An SSH
    key's filename also constitutes metadata; ditto for certificates,
    although certificates with private keys tend to get serialized as
    PKCS #12. I needed a way to store the friendly name of a
    certificate, which is a piece of information that people care about
    but can change more-or-less at will. It has security implications to
    the extent that it's shown to users, or used as a basis for
    certificate selection. Some Mozilla NSS-based workflows identify
    certificates based on the friendly name (NSS calls it "nickname",
    but uses the same construct).

    

    For S/MIME purposes, there's also smimeCapabilities. Smart clients
    are supposed to cache smimeCapabilities and track them over time:
    see RFC 5751 for discussion. Of course, not many actually do this.
    But for tracking purposes, associating smimeCapabilities with the
    corresponding signing and encryption certificates of messages makes
    sense.

    

    Manipulating X.690 (BER, CER, DER) is not practical, so we need a
    textual format for these attributes that does not reinvent the
    wheel. friendlyName is straightforward: it's just a string, suitably
    escaped. LDAP string encoding provides some escapes so why not use
    that. smimeCapabilities is more complicated, so in order not to
    reinvent the wheel, one can just use ASN.1 value notation directly
    to get the job done. I threw in the other two from PKCS #9
    (localKeyId and signingDescription) for completeness and because
    they have trivial LDAP string representations. Other attributes are
    in use, particularly in PKCS #12 blobs, but those attributes tend to
    be vendor-specific.

    

    What draft-06 calls "certattrs" could easily just be "pkixattrs" or
    "cmsattrs", since they all are drawing from the same attribute
    space. I suppose one could go even further and specify an LDAP
    string format that applies to any SET SIZE (1..MAX) OF Attribute. I
    thought about doing it but didn't go that far in certspec-06.

    

    

      

        
4. Another naming method I'm aware of is CRLSets used in
          Chromium: https://dev.chromium.org/Home/chromium-security/crlsets

        

        
This might be something to consider and possibly mention in
          section 6 "Other Certificate Specifications".

      

    

    

    Wei, can you provide more specifics on what you mean when you say
    "another naming method": do you want a way to identify CRLSets, or
    are you asking for documentation on how CRLSets identify
    certificates?

    

    I am only somewhat familiar with CRLSets, but I was under the
    impression that an entry in a (the) CRLSet identifies a certificate
    by one of: SHA-256 fingerprint, SHA-256 hash of the public key
    (SPKI), or SHA-256 hashes of one of the former two split up into a
    Merkle tree. I also was under the impression that CRLSets are
    encoded in JSON and do not have a canonical encoding form: because
    of this, it's difficult to say that a CRLSet can be identified by a
    cryptographic fingerprint in any reliable way.

    

    Best regards,

    

    Sean

  


--------------30C29AD50E50425E0CB0EDB6--


From nobody Tue Jun 14 02:50:12 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A64212D14A for ; Tue, 14 Jun 2016 02:50:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 qs2FiiUzJ33H for ; Tue, 14 Jun 2016 02:50:09 -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 678F312B064 for ; Tue, 14 Jun 2016 02:50:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3FB4D30042D for ; Tue, 14 Jun 2016 05:50:07 -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 pKaqMmvKkmIT for ; Tue, 14 Jun 2016 05:50:06 -0400 (EDT)
Received: from [10.1.0.67] (csopen.scss.tcd.ie [134.226.52.39]) by mail.smeinc.net (Postfix) with ESMTPSA id DD7BD30025B for ; Tue, 14 Jun 2016 05:50:05 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <57519BBB.8050604@cs.tcd.ie>
Date: Tue, 14 Jun 2016 05:50:05 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <7255B25B-9278-461C-9480-D4326F63D37B@vigilsec.com>
References: <57519BBB.8050604@cs.tcd.ie>
To: "spasm@ietf.org" 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Subject: Re: [Spasm] BoF in Berlin or what?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 14 Jun 2016 09:50:11 -0000

My understanding is that a one hour meeting slot for SPASM was approved =
for Berlin:

	=
https://mailarchive.ietf.org/arch/msg/spasm/23XSrpv0Gc8knO8bU0MAwsGGXKY

We have two work items in the most recent charter:

1. Specify the way to include an i18n email address as a subject
   alternative name and an issuer alternative name.
  draft-melnikov-spasm-eai-addresses is a proposal in this space.=20

2. Specify the way to use authenticated encryption in S/MIME.=20
   draft-schaad-rfc5751-bis is a proposal in this space.

Can we count on Alexey and Jim to give status and open issues on these =
drafts?

Russ




From nobody Tue Jun 14 02:59:41 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402EA12D192 for ; Tue, 14 Jun 2016 02:59:40 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 SaIMrKacAmRe for ; Tue, 14 Jun 2016 02:59:38 -0700 (PDT)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD44112B064 for ; Tue, 14 Jun 2016 02:59:38 -0700 (PDT)
Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 5A7CA38EFD; Tue, 14 Jun 2016 02:59:38 -0700 (PDT)
From: "Jim Schaad" 
To: "'Russ Housley'" , 
References: <57519BBB.8050604@cs.tcd.ie> <7255B25B-9278-461C-9480-D4326F63D37B@vigilsec.com>
In-Reply-To: <7255B25B-9278-461C-9480-D4326F63D37B@vigilsec.com>
Date: Tue, 14 Jun 2016 02:59:37 -0700
Message-ID: <09f701d1c623$767b4480$6371cd80$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHW8767gWSD88kXh4etiVhlBOiuaAHTypiSn8/BDAA=
Content-Language: en-us
Archived-At: 
Subject: Re: [Spasm] BoF in Berlin or what?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 14 Jun 2016 09:59:40 -0000

I will definitely be able to do this.

> -----Original Message-----
> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley
> Sent: Tuesday, June 14, 2016 2:50 AM
> To: spasm@ietf.org
> Subject: Re: [Spasm] BoF in Berlin or what?
> 
> My understanding is that a one hour meeting slot for SPASM was approved
for
> Berlin:
> 
> 	https://mailarchive.ietf.org/arch/msg/spasm/23XSrpv0Gc8knO8bU0MA
> wsGGXKY
> 
> We have two work items in the most recent charter:
> 
> 1. Specify the way to include an i18n email address as a subject
>    alternative name and an issuer alternative name.
>   draft-melnikov-spasm-eai-addresses is a proposal in this space.
> 
> 2. Specify the way to use authenticated encryption in S/MIME.
>    draft-schaad-rfc5751-bis is a proposal in this space.
> 
> Can we count on Alexey and Jim to give status and open issues on these
drafts?
> 
> Russ
> 
> 
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


From nobody Wed Jun 15 06:14:37 2016
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 352A812D61F; Wed, 15 Jun 2016 06:14:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Benoit Claise" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.22.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160615131432.20256.17529.idtracker@ietfa.amsl.com>
Date: Wed, 15 Jun 2016 06:14:32 -0700
Archived-At: 
Cc: spasm@ietf.org, spasm-chairs@ietf.org
Subject: [Spasm] Benoit Claise's No Objection on charter-ietf-spasm-00-03: (with COMMENT)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "This is a venue 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, 15 Jun 2016 13:14:32 -0000

Benoit Claise has entered the following ballot position for
charter-ietf-spasm-00-03: No Objection

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



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



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

As for other charters, the expected status of the work item is a plus
(experimental, informational, proposed standard)
ex:  to the IESG for publication as Proposed Standard RFC

Editorial:
The Some PKIX and S/MIME (SPASM) Working Group
Remove "Some"?



From nobody Wed Jun 15 12:14:37 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF0E12D0C9 for ; Wed, 15 Jun 2016 12:14:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 bBLXr9Srv7OH for ; Wed, 15 Jun 2016 12:14:33 -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 22E7D12D845 for ; Wed, 15 Jun 2016 12:14:33 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9EC8150A87; Wed, 15 Jun 2016 15:14:30 -0400 (EDT)
To: Wei Chuang 
References: <20160608161629.19935.86198.idtracker@ietfa.amsl.com>  
From: Sean Leonard 
Message-ID: <77fea80c-0c58-d64e-1260-074942211258@seantek.com>
Date: Wed, 15 Jun 2016 12:15:00 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------F51F7452E4AA6572EF76B1B1"
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] certspec work (draft-seantek-certspec-06.txt)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 15 Jun 2016 19:14:35 -0000

This is a multi-part message in MIME format.
--------------F51F7452E4AA6572EF76B1B1
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

Returning to the rest of the response:

On 6/9/2016 10:49 AM, Wei Chuang wrote:
> Just some thoughts about this draft:

> 2. This document would do best when coupled with work on methods to=20
> access certificates such as draft-bhjl-x509-srv-00 that would use it.

Yes, I think that would be fine and a useful coupling.

However, the motivator for certspec is to identify a single certificate=20
unambiguously, not a family of certificates. Use cases include in=20
configuration data for Internet-connected devices, such as for=20
administrators administering certificate settings on clients, server, or =

nodes on an internal network, using various configuration formats=20
(config files, YANG, XML, JSON, etc.).

Section 2 says "Certificate specifications, or "certspecs", are not=20
designed or intended to provide a search tool or query language to match =

multiple certificates. The goal is to replace data elements that would=20
otherwise have to include whole certificates, or that employ proprietary =

reference schemes." It does not attempt, for example, to provide a=20
syntax for matching "any certificate for an e-mail address", as=20
draft-bhjl-x509-srv-00 suggests:

https://certs.example.com/certificates/search.cgi?uri=3Dsomeuser%40exampl=
e.com


This is important because it is likely that such a query (it /is/ a=20
query) could return multiple certificates. It would be fine to use=20
draft-bhjl-x509-srv-00 to construct a different query:

https://certs.example.com/certificates/search.cgi?certspec=3DSHA-256:64DF=

42FF3410B579958ADDCC5C35E6BAEAFCCB4EB2B3FCDD29CE4EE06857F68E


That would be okay; the result would have to be strictly limited to a=20
single application/pkix-cert, not multiple certificates (compare with=20
Section 5 of draft-bhjl-x509-srv-00). However, I question the utility of =

such a thing. If you know the SHA-256 hash but not anything else about=20
the certificate, are you sure you want to be asking "example.com"? Maybe =

you should be asking elsewhere? (Compare with the ni: URI scheme.) If=20
you know the SHA-256 hash and you know that you are hunting for a=20
certificate that matches an e-mail address, it makes more sense to use=20
draft-bhjl-x509-srv-00 or something else to return all the known=20
certificates, and then have the client verify that one of the=20
certificates matches the SHA-256 hash. The client has to do this anyway=20
for security reasons.

Certspecs are meant to be "simple" enough that they can be included as=20
components of broader formats, including certificate queries. For example=
:

https://certs.example.com/certificates/search.cgi?uri=3Dsomeuser%40exampl=
e.com&
certspec=3DSHA-256:64DF42FF3410B579958ADDC
C5C35E6BAEAFCCB4EB2B3FCDD29CE4EE06857F68E&certspec=3DSHA-1:FEA3
64082CEACA2AC80E8AECFA2224BCC3210D2A


Would be a better example (assuming that the client really did forget=20
about the original certificate, perhaps because it is very=20
resource-constrained): the premise being that bandwidth can be saved by=20
doing server-side filtering.

> 1. The title is a little bit confusing, as much of the document is=20
> about naming certificates.  Perhaps "Naming and Metadata Specification =

> for..."?
Actually...none of the document is about naming certificates, because=20
they aren't names.

Certificates don't have globally unique "names". The closest thing to a=20
name is Issuer + Serial Number, as issuer is theoretically unique and=20
serial number is supposed to be unique for every cert issued by a=20
particular CA. But we know this is not true because CA issuers are not=20
bound to follow some global Directory, which never materialized.

The family of element-based specs is included for compatibility (e.g.,=20
with CMS, which identifies certificates based on issuerAndSerialNumber=20
or SubjectKeyIdentifier; also compatibility with the MS CryptoAPI and=20
Mozilla NSS major implementations ) and efficiency (e.g., database=20
lookups), rather than absolute unambiguity. They are only unambiguous=20
given certain assumptions, namely assumptions about the store(s) where=20
the certificates are being looked up.

Several drafts ago, I tried to call these things names by stuffing them=20
into the URN protocol slot. That ultimately failed, mainly because a lot =

of these things aren't names. Hashes (fingerprints) of certificates are=20
also not truly unambiguous names--they are only unambiguous given=20
certain engineering assumptions for certain periods of time. If you=20
doubt this, consider whether MD5:01332f309262d789097cdda53be5174d is=20
really the kind of "name" that we are looking for. All cryptographic=20
hash algorithms are susceptible to cryptanalysis; it's just a matter of=20
time and ingenuity. The data-based specs are also not really names; it=20
would be like "naming" a human being by his or her entire genome sequence=
=2E

So they aren't names; they are just ways of getting at a (single)=20
certificate in text.

> 3. Modify the ABNF to clearly identify the certspec type vs data

The current ABNF is intentional. Prior drafts had "certspec-type", but=20
the most recent drafts remove that because it gets in the way of human=20
usability (copy-and-paste-ability).

I thought about "path:" or "file:" for the filesystem-based path specs,=20
but "file:" looks too much like a file: URI (it's not a file URI), and=20
"path:" is both a bit superfluous, and a bit ambiguous (i.e., what kind=20
of path?). Overall, a conforming implementation can recognize additional =

specs in its own special way, if it wants to. This specification only=20
requires implementations to recognize a few important string patterns.

This reminds me...I was going to include Registry keys, such as
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\CA\Certificates\=
109F1CAED645BB78B3EA2B94C0697C740733031C\Blob

In that example, it's totally obvious that "HKEY_LOCAL_MACHINE\" is the=20
prefix to a Registry key or value (and, notably, not a filesystem path). =

That would be an example of a class of certspecs that is not so great to =

exchange on the open Internet, but is very useful for a managed intranet.=


Best regards,

Sean

--------------F51F7452E4AA6572EF76B1B1
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Returning to the rest of the response:

      

      On 6/9/2016 10:49 AM, Wei Chuang wrote:

    

    

      
Just some thoughts about this draft:

      

    

    

    

      

        
2. This document would do best when coupled with work on
          methods to access certificates such as draft-bhjl-x509-srv-00
          that would use it. 

        

      

    

    

    Yes, I think that would be fine and a useful coupling.

    

    However, the motivator for certspec is to identify a single
    certificate unambiguously, not a family of certificates. Use cases
    include in configuration data for Internet-connected devices, such
    as for administrators administering certificate settings on clients,
    server, or nodes on an internal network, using various configuration
    formats (config files, YANG, XML, JSON, etc.).

    

    Section 2 says "Certificate specifications, or "certspecs", are not
    designed or intended to provide a search tool or query language to
    match multiple certificates. The goal is to replace data elements
    that would otherwise have to include whole certificates, or that
    employ proprietary reference schemes." It does not attempt, for
    example, to provide a syntax for matching "any certificate for an
    e-mail address", as draft-bhjl-x509-srv-00 suggests:

    

    
https://certs.example.com/certificates/search.cgi?uri=someuser%40example.com

    

    This is important because it is likely that such a query (it is
    a query) could return multiple certificates. It would be fine to use
    draft-bhjl-x509-srv-00 to construct a different query:

    

    
https://certs.example.com/certificates/search.cgi?certspec=SHA-256:64DF
42FF3410B579958ADDCC5C35E6BAEAFCCB4EB2B3FCDD29CE4EE06857F68E

    

    That would be okay; the result would have to be strictly limited to
    a single application/pkix-cert, not multiple certificates (compare
    with Section 5 of draft-bhjl-x509-srv-00). However, I question the
    utility of such a thing. If you know the SHA-256 hash but not
    anything else about the certificate, are you sure you want to be
    asking "example.com"? Maybe you should be asking elsewhere? (Compare
    with the ni: URI scheme.) If you know the SHA-256 hash and you know
    that you are hunting for a certificate that matches an e-mail
    address, it makes more sense to use draft-bhjl-x509-srv-00 or
    something else to return all the known certificates, and then have
    the client verify that one of the certificates matches the SHA-256
    hash. The client has to do this anyway for security reasons.

    

      


        Certspecs are meant to be "simple" enough that they can be
        included as components of broader formats, including certificate
        queries. For example:

        

        
https://certs.example.com/certificates/search.cgi?uri=someuser%40example.com&
certspec=SHA-256:64DF42FF3410B579958ADDC
C5C35E6BAEAFCCB4EB2B3FCDD29CE4EE06857F68E&certspec=SHA-1:FEA3
64082CEACA2AC80E8AECFA2224BCC3210D2A

        

        Would be a better example (assuming that the client really did
        forget about the original certificate, perhaps because it is
        very resource-constrained): the premise being that bandwidth can
        be saved by doing server-side filtering.

        

      

    

    

      

        
1. The title is a little bit confusing, as much of the
          document is about naming certificates.  Perhaps "Naming and
          Metadata Specification for..."?

      

    

    Actually...none of the document is about naming certificates,
    because they aren't names.

    

    Certificates don't have globally unique "names". The closest thing
    to a name is Issuer + Serial Number, as issuer is theoretically
    unique and serial number is supposed to be unique for every cert
    issued by a particular CA. But we know this is not true because CA
    issuers are not bound to follow some global Directory, which never
    materialized.

    

    The family of element-based specs is included for compatibility
    (e.g., with CMS, which identifies certificates based on
    issuerAndSerialNumber or SubjectKeyIdentifier; also compatibility
    with the MS CryptoAPI and Mozilla NSS major implementations ) and
    efficiency (e.g., database lookups), rather than absolute
    unambiguity. They are only unambiguous given certain assumptions,
    namely assumptions about the store(s) where the certificates are
    being looked up.

    

    Several drafts ago, I tried to call these things names by stuffing
    them into the URN protocol slot. That ultimately failed, mainly
    because a lot of these things aren't names. Hashes (fingerprints) of
    certificates are also not truly unambiguous names--they are only
    unambiguous given certain engineering assumptions for certain
    periods of time. If you doubt this, consider whether
    MD5:01332f309262d789097cdda53be5174d is really the kind of "name"
    that we are looking for. All cryptographic hash algorithms are
    susceptible to cryptanalysis; it's just a matter of time and
    ingenuity. The data-based specs are also not really names; it would
    be like "naming" a human being by his or her entire genome sequence.

    

    So they aren't names; they are just ways of getting at a (single)
    certificate in text.

    

    

      

        
3. Modify the ABNF to clearly identify the certspec type vs
          data

      

    

    

    The current ABNF is intentional. Prior drafts had "certspec-type",
    but the most recent drafts remove that because it gets in the way of
    human usability (copy-and-paste-ability).

    

    I thought about "path:" or "file:" for the filesystem-based path
    specs, but "file:" looks too much like a file: URI (it's not a file
    URI), and "path:" is both a bit superfluous, and a bit ambiguous
    (i.e., what kind of path?). Overall, a conforming implementation can
    recognize additional specs in its own special way, if it wants to.
    This specification only requires implementations to recognize a few
    important string patterns.

    

    This reminds me...I was going to include Registry keys, such as

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\CA\Certificates\109F1CAED645BB78B3EA2B94C0697C740733031C\Blob

    

    In that example, it's totally obvious that "HKEY_LOCAL_MACHINE\" is
    the prefix to a Registry key or value (and, notably, not a
    filesystem path). That would be an example of a class of certspecs
    that is not so great to exchange on the open Internet, but is very
    useful for a managed intranet.

    

    Best regards,

    

    Sean
  


--------------F51F7452E4AA6572EF76B1B1--


From nobody Wed Jun 15 14:21:34 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9311312DBE3 for ; Wed, 15 Jun 2016 14:21:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 72naUd_Q04kw for ; Wed, 15 Jun 2016 14:21:31 -0700 (PDT)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 A6F0C12D9A5 for ; Wed, 15 Jun 2016 14:21:31 -0700 (PDT)
Received: by mail-oi0-x231.google.com with SMTP id d132so40044310oig.1 for ; Wed, 15 Jun 2016 14:21:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VUSuOwItjKBTcstNBmrQSGBK1y8ZeOPz9ajo2+ubf8U=; b=fOzpltVuIQIEk9aGzx2ZZnUzRJA20+zRg77ziZhRLL3TtoXLiWBQrCHtPfFgnYBcq0 hMztP5AhnxCA7Gr//BH5XT6SVsWnuZy3hcLorPgBk8klUiLryDX0QofFzsofHjQhilQr IQRW+lJ+cETbn0D6MaOPCgnUqua30iBR7/DEuzstxOlSIWbUjkmySf571ymD8BXpNndm 2ZlLVku+dy4D+g78eTK/8holo2c3Qp5Wav3ZDTbeqGukR3Jj3z5ZqDKFKA5DgpUKOFmB 1a/Ve35gzcaeOmZrzO7vzMz4w3yGt6/E9YuF3K1RSv8KImoGIJ6gw9QdQQ0oRl0+JWdo Z4kA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VUSuOwItjKBTcstNBmrQSGBK1y8ZeOPz9ajo2+ubf8U=; b=PhuIrQoZSpUYh2cgUgX2gj9EPJbwkT7Pc3LD9wpWnqwoABSA3hkhlO6HLOe3pT/aaI qZqN5CzmwQwyWOYJrArycbeZQvJC5IqUbi3p3Z19oIU3KNrS1c+ku9X87r+x7VU0nwFk WT23ZtHDYwYt73e+Z/FJh7RL0TZJKbmt6lmfAuQe2TJUa/KHGjl3sYPnf4/JiHGrcDVQ UqwYjueMcTRL+JbRXoLVtdg0jCT0E3Rnj0mC6kkSZK0olWiuosn73EwgrRbCcuITdScg LDryhvJT3/Q6QzkmTmcuwcuVZY90FLtKJqb1HfT+d20VrmRrqO64RjaChEE07c6M/oFl J41g==
X-Gm-Message-State: ALyK8tKZntbG/tcysW33Vlyq46xoLqo0+YqV9hm2nUqQpxOQw1V+WGH9TsAbWaXfGy80ZR8inS68s2nIMSUJP0G5
X-Received: by 10.157.11.9 with SMTP id a9mr524952ota.10.1466025690562; Wed, 15 Jun 2016 14:21:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.27.139 with HTTP; Wed, 15 Jun 2016 14:21:29 -0700 (PDT)
In-Reply-To: 
References: <20160608161629.19935.86198.idtracker@ietfa.amsl.com>   
From: Wei Chuang 
Date: Wed, 15 Jun 2016 14:21:29 -0700
Message-ID: 
To: Sean Leonard 
Content-Type: multipart/alternative; boundary=001a113ddce284dc10053557b4ee
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] certspec work (draft-seantek-certspec-06.txt)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 15 Jun 2016 21:21:33 -0000

--001a113ddce284dc10053557b4ee
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On Tue, Jun 14, 2016 at 2:03 AM, Sean Leonard  wrote:

> Thank you for the feedback. Based on time, I will respond in multiple
> e-mails, and out of order...
>
> On 6/9/2016 10:49 AM, Wei Chuang wrote:
>
> Just some thoughts about this draft:
>
>
> 5. Can more motivation be provided for attribute section 8?
>
>
> Okay. Well I am not sure if more motivation needs to be provided than the
> first paragraph:
>
>    A certificate can have additional attributes (i.e., metadata)
>    operatively associated with--but not intrinsic to--it.  For example,
>    the additional attributes may represent preferences.  The syntax is
>    intended primarily to convey certificate metadata such as attributes
>    found in PKCS #9 [RFC2985], PKCS #11 [PKCS11], PKCS #12 [RFC7292],
>    and particular implementations of cryptographic libraries.
>
> However, I suppose that I can provide some backstory.
>
> Many certificate owners (taken broadly, I mean users and systems that
> actually use certificates on a semi-regular basis, and that hold the
> corresponding private keys) have preferences attached to those
> certificates, much like SSH key owners attach metadata to their keys.
> "friendlyName" is the obvious example. I'm pretty sure all of us around
> here name our SSH keys certain things, like "use this with foo server" or
> "generated on my Mac Mini in June". An SSH key's filename also constitutes
> metadata; ditto for certificates, although certificates with private keys
> tend to get serialized as PKCS #12. I needed a way to store the friendly
> name of a certificate, which is a piece of information that people care
> about but can change more-or-less at will. It has security implications to
> the extent that it's shown to users, or used as a basis for certificate
> selection. Some Mozilla NSS-based workflows identify certificates based on
> the friendly name (NSS calls it "nickname", but uses the same construct).
>
> For S/MIME purposes, there's also smimeCapabilities. Smart clients are
> supposed to cache smimeCapabilities and track them over time: see RFC 5751
> for discussion. Of course, not many actually do this. But for tracking
> purposes, associating smimeCapabilities with the corresponding signing and
> encryption certificates of messages makes sense.
>
> Manipulating X.690 (BER, CER, DER) is not practical, so we need a textual
> format for these attributes that does not reinvent the wheel. friendlyName
> is straightforward: it's just a string, suitably escaped. LDAP string
> encoding provides some escapes so why not use that. smimeCapabilities is
> more complicated, so in order not to reinvent the wheel, one can just use
> ASN.1 value notation directly to get the job done. I threw in the other two
> from PKCS #9 (localKeyId and signingDescription) for completeness and
> because they have trivial LDAP string representations. Other attributes are
> in use, particularly in PKCS #12 blobs, but those attributes tend to be
> vendor-specific.
>
> What draft-06 calls "certattrs" could easily just be "pkixattrs" or
> "cmsattrs", since they all are drawing from the same attribute space. I
> suppose one could go even further and specify an LDAP string format that
> applies to any SET SIZE (1..MAX) OF Attribute. I thought about doing it but
> didn't go that far in certspec-06.
>

Thanks.


>
>
> 4. Another naming method I'm aware of is CRLSets used in Chromium:
> https://dev.chromium.org/Home/chromium-security/crlsets
> This might be something to consider and possibly mention in section 6 "Other
> Certificate Specifications".
>
>
> Wei, can you provide more specifics on what you mean when you say "another
> naming method": do you want a way to identify CRLSets, or are you asking
> for documentation on how CRLSets identify certificates?
>

This is another technique for identifying a certificate.  I point it out
for completeness in case its useful.  I believe its advantage is that its
supposed to be compact, and general.


>
> I am only somewhat familiar with CRLSets, but I was under the impression
> that an entry in a (the) CRLSet identifies a certificate by one of: SHA-256
> fingerprint, SHA-256 hash of the public key (SPKI), or SHA-256 hashes of
> one of the former two split up into a Merkle tree.
>

I believe its simpler than that.  Its the SHA-256 hash of the issuer SPKI
and the certificate serial number.  I don't recall it being tied to Json
(but I could be wrong).

-Wei


> I also was under the impression that CRLSets are encoded in JSON and do
> not have a canonical encoding form: because of this, it's difficult to say
> that a CRLSet can be identified by a cryptographic fingerprint in any
> reliable way.
>
> Best regards,
>
> Sean
>

--001a113ddce284dc10053557b4ee
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit




On Tue, Jun 14, 2016 at 2:03 AM, Sean Leonard <dev+ietf@seantek.com> wrote:

  
    
  
  

    
Thank you for the feedback. Based on
      time, I will respond in multiple e-mails, and out of order...

      

      On 6/9/2016 10:49 AM, Wei Chuang wrote:

    

    

      
Just some thoughts about this draft:

      

    

    

    

      

        
5. Can more motivation be provided for attribute section 8?

      

    

    

    Okay. Well I am not sure if more motivation needs to be provided
    than the first paragraph:

    

       A certificate can have additional attributes (i.e., metadata)

       operatively associated with--but not intrinsic to--it.  For
    example,

       the additional attributes may represent preferences.  The syntax
    is

       intended primarily to convey certificate metadata such as
    attributes

       found in PKCS #9 [RFC2985], PKCS #11 [PKCS11], PKCS #12
    [RFC7292],

       and particular implementations of cryptographic libraries.

    

    However, I suppose that I can provide some backstory.

    

    Many certificate owners (taken broadly, I mean users and systems
    that actually use certificates on a semi-regular basis, and that
    hold the corresponding private keys) have preferences attached to
    those certificates, much like SSH key owners attach metadata to
    their keys. "friendlyName" is the obvious example. I'm pretty sure
    all of us around here name our SSH keys certain things, like "use
    this with foo server" or "generated on my Mac Mini in June". An SSH
    key's filename also constitutes metadata; ditto for certificates,
    although certificates with private keys tend to get serialized as
    PKCS #12. I needed a way to store the friendly name of a
    certificate, which is a piece of information that people care about
    but can change more-or-less at will. It has security implications to
    the extent that it's shown to users, or used as a basis for
    certificate selection. Some Mozilla NSS-based workflows identify
    certificates based on the friendly name (NSS calls it "nickname",
    but uses the same construct).

    

    For S/MIME purposes, there's also smimeCapabilities. Smart clients
    are supposed to cache smimeCapabilities and track them over time:
    see RFC 5751 for discussion. Of course, not many actually do this.
    But for tracking purposes, associating smimeCapabilities with the
    corresponding signing and encryption certificates of messages makes
    sense.

    

    Manipulating X.690 (BER, CER, DER) is not practical, so we need a
    textual format for these attributes that does not reinvent the
    wheel. friendlyName is straightforward: it's just a string, suitably
    escaped. LDAP string encoding provides some escapes so why not use
    that. smimeCapabilities is more complicated, so in order not to
    reinvent the wheel, one can just use ASN.1 value notation directly
    to get the job done. I threw in the other two from PKCS #9
    (localKeyId and signingDescription) for completeness and because
    they have trivial LDAP string representations. Other attributes are
    in use, particularly in PKCS #12 blobs, but those attributes tend to
    be vendor-specific.

    

    What draft-06 calls "certattrs" could easily just be "pkixattrs" or
    "cmsattrs", since they all are drawing from the same attribute
    space. I suppose one could go even further and specify an LDAP
    string format that applies to any SET SIZE (1..MAX) OF Attribute. I
    thought about doing it but didn't go that far in certspec-06.

Thanks.
 


    

    

      

        
4. Another naming method I'm aware of is CRLSets used in
          Chromium: https://dev.chromium.org/Home/chromium-security/crlsets

        

        
This might be something to consider and possibly mention in
          section 6 "Other Certificate Specifications".

      

    

    

    Wei, can you provide more specifics on what you mean when you say
    "another naming method": do you want a way to identify CRLSets, or
    are you asking for documentation on how CRLSets identify
    certificates?

This is another technique for identifying a certificate.  I point it out for completeness in case its useful.  I believe its advantage is that its supposed to be compact, and general.
 

    

    I am only somewhat familiar with CRLSets, but I was under the
    impression that an entry in a (the) CRLSet identifies a certificate
    by one of: SHA-256 fingerprint, SHA-256 hash of the public key
    (SPKI), or SHA-256 hashes of one of the former two split up into a
    Merkle tree. 

I believe its simpler than that.  Its the SHA-256 hash of the issuer SPKI and the certificate serial number.  I don't recall it being tied to Json (but I could be wrong).

-Wei
 
I also was under the impression that CRLSets are
    encoded in JSON and do not have a canonical encoding form: because
    of this, it's difficult to say that a CRLSet can be identified by a
    cryptographic fingerprint in any reliable way.

    

    Best regards,

    

    Sean

  






--001a113ddce284dc10053557b4ee--


From nobody Wed Jun 15 14:26:42 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F9912DBF4 for ; Wed, 15 Jun 2016 14:26:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 EoBFIjm0tp6T for ; Wed, 15 Jun 2016 14:26:38 -0700 (PDT)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 AF83A12DBF3 for ; Wed, 15 Jun 2016 14:26:37 -0700 (PDT)
Received: by mail-oi0-x22c.google.com with SMTP id d132so40225508oig.1 for ; Wed, 15 Jun 2016 14:26:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ASa6L63K8AEFBIz1RHwd3071gFap/thl66A/Jkk6Y3I=; b=V7dl4KLdYRyJsVYttkHPnRDlHTwISxZVzuyxduqX106J2NMoTTBY9UfU+l7vbCuWjn cvPFE+mIsEsmXcWjZuRhlTqTfKAhTdXT1jv/MsFte4RyzFViLhrbTIGSqTGLLIUWSysV ibnWEu9k4ikLSBzAHBlGXf++afIdjDPBboVVe4UnjNTTSuafoIjIHgC5QiZEg45bDNhn ny7aCsEeYzOj1o7/yKGZ4BvwazNzWBqtWM44vn5WEd9EvIvKjNIIRMd03U1q7ZlrmWX8 FqcCkTjIdTYka4gseZSDYc70p7mmrt7w/IrVSzr3OUy+z3qe66R2nnunwtIBdNQT6rXb woWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ASa6L63K8AEFBIz1RHwd3071gFap/thl66A/Jkk6Y3I=; b=LFSRwV77BhG8fWtQq/fwVwiFJQY3IbhiNBncAmQYH2hlTOFaI73zw56Rbsgt28aJXk ofHxIrHZnb9Y/TzTTzDDTRemqAOwJJs+GOV6VJ+oqnc4VlXJBc2pf0htyf9ddz6PuJ1g r9V8qhpvO3CP5Ecc3x4E+tl4TDqibhBGrXspWybMSQG4GgwjzpuPADX4OI6HUGYQW533 8MmwrRRhZ68e8SWbHY0rv1/qyGas8M+SsnXg2x0QAc5kdwJXY0RY9a9WCeGN3n8jNoZo F/5JblS+fcafv7XPOwpOIanVridjBXZbVHkugJu+NONdSAOrxV2K8bxtJ2V7GSvUcKPf 2yxw==
X-Gm-Message-State: ALyK8tLqTg0JkzhQCvJl6KYZt/NdjKNki9lxmSAN+oAP975w0bzJW3J/LlEj9qUVQaqXvct4H/OyTlhlUoJUeELM
X-Received: by 10.202.184.213 with SMTP id i204mr501276oif.128.1466025996594;  Wed, 15 Jun 2016 14:26:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.27.139 with HTTP; Wed, 15 Jun 2016 14:26:35 -0700 (PDT)
In-Reply-To: <77fea80c-0c58-d64e-1260-074942211258@seantek.com>
References: <20160608161629.19935.86198.idtracker@ietfa.amsl.com>   <77fea80c-0c58-d64e-1260-074942211258@seantek.com>
From: Wei Chuang 
Date: Wed, 15 Jun 2016 14:26:35 -0700
Message-ID: 
To: Sean Leonard 
Content-Type: multipart/alternative; boundary=001a113ce9a8c29fe1053557c61d
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] certspec work (draft-seantek-certspec-06.txt)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 15 Jun 2016 21:26:41 -0000

--001a113ce9a8c29fe1053557c61d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On Wed, Jun 15, 2016 at 12:15 PM, Sean Leonard  wrote:

> Returning to the rest of the response:
>
> On 6/9/2016 10:49 AM, Wei Chuang wrote:
>
> Just some thoughts about this draft:
>
>
> 2. This document would do best when coupled with work on methods to access
> certificates such as draft-bhjl-x509-srv-00 that would use it.
>
>
> Yes, I think that would be fine and a useful coupling.
>
> However, the motivator for certspec is to identify a single certificate
> unambiguously, not a family of certificates. Use cases include in
> configuration data for Internet-connected devices, such as for
> administrators administering certificate settings on clients, server, or
> nodes on an internal network, using various configuration formats (config
> files, YANG, XML, JSON, etc.).
>
> Section 2 says "Certificate specifications, or "certspecs", are not
> designed or intended to provide a search tool or query language to match
> multiple certificates. The goal is to replace data elements that would
> otherwise have to include whole certificates, or that employ proprietary
> reference schemes." It does not attempt, for example, to provide a syntax
> for matching "any certificate for an e-mail address", as
> draft-bhjl-x509-srv-00 suggests:
>
> https://certs.example.com/certificates/search.cgi?uri=someuser%40example.com
>
>
> This is important because it is likely that such a query (it *is* a
> query) could return multiple certificates. It would be fine to use
> draft-bhjl-x509-srv-00 to construct a different query:
>
> https://certs.example.com/certificates/search.cgi?certspec=SHA-256:64DF
> 42FF3410B579958ADDCC5C35E6BAEAFCCB4EB2B3FCDD29CE4EE06857F68E
>
>
> That would be okay; the result would have to be strictly limited to a
> single application/pkix-cert, not multiple certificates (compare with
> Section 5 of draft-bhjl-x509-srv-00). However, I question the utility of
> such a thing. If you know the SHA-256 hash but not anything else about the
> certificate, are you sure you want to be asking "example.com"? Maybe you
> should be asking elsewhere? (Compare with the ni: URI scheme.) If you know
> the SHA-256 hash and you know that you are hunting for a certificate that
> matches an e-mail address, it makes more sense to use
> draft-bhjl-x509-srv-00 or something else to return all the known
> certificates, and then have the client verify that one of the certificates
> matches the SHA-256 hash. The client has to do this anyway for security
> reasons.
>
> Certspecs are meant to be "simple" enough that they can be included as
> components of broader formats, including certificate queries. For example:
>
> https://certs.example.com/certificates/search.cgi?uri=someuser%40example.com&
> certspec=SHA-256:64DF42FF3410B579958ADDC
> C5C35E6BAEAFCCB4EB2B3FCDD29CE4EE06857F68E&certspec=SHA-1:FEA3
> 64082CEACA2AC80E8AECFA2224BCC3210D2A
>
>
> Would be a better example (assuming that the client really did forget
> about the original certificate, perhaps because it is very
> resource-constrained): the premise being that bandwidth can be saved by
> doing server-side filtering.
>
> 1. The title is a little bit confusing, as much of the document is about
> naming certificates.  Perhaps "Naming and Metadata Specification for..."?
>
> Actually...none of the document is about naming certificates, because they
> aren't names.
>

Regarding the title, then perhaps something describing how this document is
to be used?


>
> Certificates don't have globally unique "names". The closest thing to a
> name is Issuer + Serial Number, as issuer is theoretically unique and
> serial number is supposed to be unique for every cert issued by a
> particular CA. But we know this is not true because CA issuers are not
> bound to follow some global Directory, which never materialized.
>
> The family of element-based specs is included for compatibility (e.g.,
> with CMS, which identifies certificates based on issuerAndSerialNumber or
> SubjectKeyIdentifier; also compatibility with the MS CryptoAPI and Mozilla
> NSS major implementations ) and efficiency (e.g., database lookups), rather
> than absolute unambiguity. They are only unambiguous given certain
> assumptions, namely assumptions about the store(s) where the certificates
> are being looked up.
>
> Several drafts ago, I tried to call these things names by stuffing them
> into the URN protocol slot. That ultimately failed, mainly because a lot of
> these things aren't names. Hashes (fingerprints) of certificates are also
> not truly unambiguous names--they are only unambiguous given certain
> engineering assumptions for certain periods of time. If you doubt this,
> consider whether MD5:01332f309262d789097cdda53be5174d is really the kind
> of "name" that we are looking for. All cryptographic hash algorithms are
> susceptible to cryptanalysis; it's just a matter of time and ingenuity. The
> data-based specs are also not really names; it would be like "naming" a
> human being by his or her entire genome sequence.
>
> So they aren't names; they are just ways of getting at a (single)
> certificate in text.
>

And yet there's value in identifying certificates for lookup and such.
Just pointing what I thought was a use for the specification.

-Wei


>
>
> 3. Modify the ABNF to clearly identify the certspec type vs data
>
>
> The current ABNF is intentional. Prior drafts had "certspec-type", but the
> most recent drafts remove that because it gets in the way of human
> usability (copy-and-paste-ability).
>
> I thought about "path:" or "file:" for the filesystem-based path specs,
> but "file:" looks too much like a file: URI (it's not a file URI), and
> "path:" is both a bit superfluous, and a bit ambiguous (i.e., what kind of
> path?). Overall, a conforming implementation can recognize additional specs
> in its own special way, if it wants to. This specification only requires
> implementations to recognize a few important string patterns.
>
> This reminds me...I was going to include Registry keys, such as
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\CA\Certificates\
> 109F1CAED645BB78B3EA2B94C0697C740733031C\Blob
>
> In that example, it's totally obvious that "HKEY_LOCAL_MACHINE\" is the
> prefix to a Registry key or value (and, notably, not a filesystem path).
> That would be an example of a class of certspecs that is not so great to
> exchange on the open Internet, but is very useful for a managed intranet.
>
> Best regards,
>
> Sean
>

--001a113ce9a8c29fe1053557c61d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit




On Wed, Jun 15, 2016 at 12:15 PM, Sean Leonard <dev+ietf@seantek.com> wrote:

  
    
  
  

    
Returning to the rest of the response:

      

      On 6/9/2016 10:49 AM, Wei Chuang wrote:

    

    

      
Just some thoughts about this draft:

      

    

    

    

      

        
2. This document would do best when coupled with work on
          methods to access certificates such as draft-bhjl-x509-srv-00
          that would use it. 

        

      

    

    

    Yes, I think that would be fine and a useful coupling.

    

    However, the motivator for certspec is to identify a single
    certificate unambiguously, not a family of certificates. Use cases
    include in configuration data for Internet-connected devices, such
    as for administrators administering certificate settings on clients,
    server, or nodes on an internal network, using various configuration
    formats (config files, YANG, XML, JSON, etc.).

    

    Section 2 says "Certificate specifications, or "certspecs", are not
    designed or intended to provide a search tool or query language to
    match multiple certificates. The goal is to replace data elements
    that would otherwise have to include whole certificates, or that
    employ proprietary reference schemes." It does not attempt, for
    example, to provide a syntax for matching "any certificate for an
    e-mail address", as draft-bhjl-x509-srv-00 suggests:

    

    
https://certs.example.com/certificates/search.cgi?uri=someuser%40example.com

    

    This is important because it is likely that such a query (it is
    a query) could return multiple certificates. It would be fine to use
    draft-bhjl-x509-srv-00 to construct a different query:

    

    
https://certs.example.com/certificates/search.cgi?certspec=SHA-256:64DF
42FF3410B579958ADDCC5C35E6BAEAFCCB4EB2B3FCDD29CE4EE06857F68E

    

    That would be okay; the result would have to be strictly limited to
    a single application/pkix-cert, not multiple certificates (compare
    with Section 5 of draft-bhjl-x509-srv-00). However, I question the
    utility of such a thing. If you know the SHA-256 hash but not
    anything else about the certificate, are you sure you want to be
    asking "example.com"? Maybe you should be asking elsewhere? (Compare
    with the ni: URI scheme.) If you know the SHA-256 hash and you know
    that you are hunting for a certificate that matches an e-mail
    address, it makes more sense to use draft-bhjl-x509-srv-00 or
    something else to return all the known certificates, and then have
    the client verify that one of the certificates matches the SHA-256
    hash. The client has to do this anyway for security reasons.

    

      


        Certspecs are meant to be "simple" enough that they can be
        included as components of broader formats, including certificate
        queries. For example:

        

        
https://certs.example.com/certificates/search.cgi?uri=someuser%40example.com&
certspec=SHA-256:64DF42FF3410B579958ADDC
C5C35E6BAEAFCCB4EB2B3FCDD29CE4EE06857F68E&certspec=SHA-1:FEA3
64082CEACA2AC80E8AECFA2224BCC3210D2A

        

        Would be a better example (assuming that the client really did
        forget about the original certificate, perhaps because it is
        very resource-constrained): the premise being that bandwidth can
        be saved by doing server-side filtering.

        

      

    

    

      

        
1. The title is a little bit confusing, as much of the
          document is about naming certificates.  Perhaps "Naming and
          Metadata Specification for..."?

      

    

    Actually...none of the document is about naming certificates,
    because they aren't names.

Regarding the title, then perhaps something describing how this document is to be used?
 

    

    Certificates don't have globally unique "names". The closest thing
    to a name is Issuer + Serial Number, as issuer is theoretically
    unique and serial number is supposed to be unique for every cert
    issued by a particular CA. But we know this is not true because CA
    issuers are not bound to follow some global Directory, which never
    materialized.

    

    The family of element-based specs is included for compatibility
    (e.g., with CMS, which identifies certificates based on
    issuerAndSerialNumber or SubjectKeyIdentifier; also compatibility
    with the MS CryptoAPI and Mozilla NSS major implementations ) and
    efficiency (e.g., database lookups), rather than absolute
    unambiguity. They are only unambiguous given certain assumptions,
    namely assumptions about the store(s) where the certificates are
    being looked up.

    

    Several drafts ago, I tried to call these things names by stuffing
    them into the URN protocol slot. That ultimately failed, mainly
    because a lot of these things aren't names. Hashes (fingerprints) of
    certificates are also not truly unambiguous names--they are only
    unambiguous given certain engineering assumptions for certain
    periods of time. If you doubt this, consider whether
    MD5:01332f309262d789097cdda53be5174d is really the kind of "name"
    that we are looking for. All cryptographic hash algorithms are
    susceptible to cryptanalysis; it's just a matter of time and
    ingenuity. The data-based specs are also not really names; it would
    be like "naming" a human being by his or her entire genome sequence.

    

    So they aren't names; they are just ways of getting at a (single)
    certificate in text.

And yet there's value in identifying certificates for lookup and such.  Just pointing what I thought was a use for the specification.

-Wei
 


    

    

      

        
3. Modify the ABNF to clearly identify the certspec type vs
          data

      

    

    

    The current ABNF is intentional. Prior drafts had "certspec-type",
    but the most recent drafts remove that because it gets in the way of
    human usability (copy-and-paste-ability).

    

    I thought about "path:" or "file:" for the filesystem-based path
    specs, but "file:" looks too much like a file: URI (it's not a file
    URI), and "path:" is both a bit superfluous, and a bit ambiguous
    (i.e., what kind of path?). Overall, a conforming implementation can
    recognize additional specs in its own special way, if it wants to.
    This specification only requires implementations to recognize a few
    important string patterns.

    

    This reminds me...I was going to include Registry keys, such as

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\CA\Certificates\109F1CAED645BB78B3EA2B94C0697C740733031C\Blob

    

    In that example, it's totally obvious that "HKEY_LOCAL_MACHINE\" is
    the prefix to a Registry key or value (and, notably, not a
    filesystem path). That would be an example of a class of certspecs
    that is not so great to exchange on the open Internet, but is very
    useful for a managed intranet.

    

    Best regards,

    

    Sean
  






--001a113ce9a8c29fe1053557c61d--


From nobody Wed Jun 15 14:29:44 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB0C12DBF1 for ; Wed, 15 Jun 2016 14:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 z-71uF9HPC1p for ; Wed, 15 Jun 2016 14:29:39 -0700 (PDT)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 B0BCA12D9A0 for ; Wed, 15 Jun 2016 14:29:39 -0700 (PDT)
Received: by mail-oi0-x233.google.com with SMTP id w5so40318874oib.2 for ; Wed, 15 Jun 2016 14:29:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fFy/sQ1htTF07EvH92zCl4Es4J/dO2/0aQwstOTdS/8=; b=pQF2eHqLD76l7jnr0qY3Xm5raFMK+sCbke33RrnsLa1qEdIyuFd8aymv0VRA4voWcG uSyQ8/Q5M8PB/wI+cA2jie8fur4GZNfBAhXgQzYIR3dO/rg3jM4fh6n/L3C4XWTijr2M XuMEnjrHxKwiUsVVa4coJ1ZsjiME91T5J54F0ZnzKJbWkLi7r0FFLHOI5g1KcS1RAalv Q+xssyM8RZpDghbgCiBJtjn0Mh+sCs4HMPg01Hzr8x+VxQDHIPiy8dmsZ/OMN7O9fXOG r8K5zTVYPr7R4IR0E4OMbi2JTvYrnS2dJ+zsNsIpsQPomFlg0hg0JA6vFcXxr8QAJV2h 2Ogw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fFy/sQ1htTF07EvH92zCl4Es4J/dO2/0aQwstOTdS/8=; b=FGzaF2SUYbax26Y9NHtwJ0bSubdYcvrUUeqZsXWajy1hbKvQcQEI6qyKeV/sm+EcVV LMsrD13BW+KvHO6hUWR9kl8KPGOIbP5yjy1GVFyrszyW0wvkKdN2kDDttuju6nTK/45w RixNyxX1TKCXUY28gj/SMD2ttU6WBzG9CG9jPUUDtd98hRmwQIVGYmgwlaP2j3yERqAx 8WjSPyxpeSq+QYr5qxA5k8WT6dEht/2wWi01xtQWUyPB7JlBxxZu0SAGtlot4HOPVNkU DkmzJDI+Ttxt27XpZE/EjTmP65OZeAf/crxisRdt3s7lDlWeFwW/u7XtuXUQLXvVEclm UriQ==
X-Gm-Message-State: ALyK8tJKC2gT2+rP5fLfIvxbGhyq4+pt06dY5JShIeTdKjJga2JDdOKUbkzQ07OCO5oAbH8ybTL5cqzig7kvFr3d
X-Received: by 10.157.42.5 with SMTP id t5mr589443ota.94.1466026178584; Wed, 15 Jun 2016 14:29:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.27.139 with HTTP; Wed, 15 Jun 2016 14:29:37 -0700 (PDT)
In-Reply-To: <7255B25B-9278-461C-9480-D4326F63D37B@vigilsec.com>
References: <57519BBB.8050604@cs.tcd.ie> <7255B25B-9278-461C-9480-D4326F63D37B@vigilsec.com>
From: Wei Chuang 
Date: Wed, 15 Jun 2016 14:29:37 -0700
Message-ID: 
To: Russ Housley 
Content-Type: multipart/alternative; boundary=001a11404e7e9b882f053557d142
Archived-At: 
Cc: "spasm@ietf.org" , Alexey Melnikov 
Subject: Re: [Spasm] BoF in Berlin or what?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 15 Jun 2016 21:29:42 -0000

--001a11404e7e9b882f053557d142
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On Tue, Jun 14, 2016 at 2:50 AM, Russ Housley  wrote:

> My understanding is that a one hour meeting slot for SPASM was approved
> for Berlin:
>
>         https://mailarchive.ietf.org/arch/msg/spasm/
> 23XSrpv0Gc8knO8bU0MAwsGGXKY
>
> We have two work items in the most recent charter:
>
> 1. Specify the way to include an i18n email address as a subject
>    alternative name and an issuer alternative name.
>   draft-melnikov-spasm-eai-addresses is a proposal in this space.
>
> 2. Specify the way to use authenticated encryption in S/MIME.
>    draft-schaad-rfc5751-bis is a proposal in this space.
>
> Can we count on Alexey and Jim to give status and open issues on these
> drafts?
>

If Alexey can't make this, I can give an update.

-Wei


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

--001a11404e7e9b882f053557d142
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit




On Tue, Jun 14, 2016 at 2:50 AM, Russ Housley <housley@vigilsec.com> wrote:
My understanding is that a one hour meeting slot for SPASM was approved for Berlin:



        https://mailarchive.ietf.org/arch/msg/spasm/23XSrpv0Gc8knO8bU0MAwsGGXKY



We have two work items in the most recent charter:



1. Specify the way to include an i18n email address as a subject

   alternative name and an issuer alternative name.

  draft-melnikov-spasm-eai-addresses is a proposal in this space.



2. Specify the way to use authenticated encryption in S/MIME.

   draft-schaad-rfc5751-bis is a proposal in this space.



Can we count on Alexey and Jim to give status and open issues on these drafts?

If Alexey can't make this, I can give an update.

-Wei
 



Russ








_______________________________________________

Spasm mailing list

Spasm@ietf.org

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





--001a11404e7e9b882f053557d142--


From nobody Thu Jun 16 06:11:46 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F3512D606 for ; Thu, 16 Jun 2016 06:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 1rc8XHBAdT5I for ; Thu, 16 Jun 2016 06:11:36 -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 2479112D5F2 for ; Thu, 16 Jun 2016 06:11:24 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3C165509B5; Thu, 16 Jun 2016 09:11:21 -0400 (EDT)
To: Wei Chuang 
References: <20160608161629.19935.86198.idtracker@ietfa.amsl.com>   <77fea80c-0c58-d64e-1260-074942211258@seantek.com> 
From: Sean Leonard 
Message-ID: 
Date: Thu, 16 Jun 2016 06:11:52 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------DB7B7300952A9F856F31676F"
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] certspec work (draft-seantek-certspec-06.txt)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 16 Jun 2016 13:11:45 -0000

This is a multi-part message in MIME format.
--------------DB7B7300952A9F856F31676F
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

On 6/15/2016 2:26 PM, Wei Chuang wrote:
>
>
> On Wed, Jun 15, 2016 at 12:15 PM, Sean Leonard  > wrote:
>
>     Returning to the rest of the response:
>
>     On 6/9/2016 10:49 AM, Wei Chuang wrote:
>>     Just some thoughts about this draft:
>
>>     2. This document would do best when coupled with work on methods
>>     to access certificates such as draft-bhjl-x509-srv-00 that would
>>     use it.
>
>     Yes, I think that would be fine and a useful coupling.
>
>     However, the motivator for certspec is to identify a single
>     certificate unambiguously, not a family of certificates. Use cases
>     include in configuration data for Internet-connected devices, such
>     as for administrators administering certificate settings on
>     clients, server, or nodes on an internal network, using various
>     configuration formats (config files, YANG, XML, JSON, etc.).
>
>     Section 2 says "Certificate specifications, or "certspecs", are
>     not designed or intended to provide a search tool or query
>     language to match multiple certificates. The goal is to replace
>     data elements that would otherwise have to include whole
>     certificates, or that employ proprietary reference schemes." It
>     does not attempt, for example, to provide a syntax for matching
>     "any certificate for an e-mail address", as draft-bhjl-x509-srv-00
>     suggests:
>
>     https://certs.example.com/certificates/search.cgi?uri=3Dsomeuser%40=
example.com
>     
>
>     This is important because it is likely that such a query (it /is/
>     a query) could return multiple certificates. It would be fine to
>     use draft-bhjl-x509-srv-00 to construct a different query:
>
>     https://certs.example.com/certificates/search.cgi?certspec=3DSHA-25=
6:64DF
>     
>     42FF3410B579958ADDCC5C35E6BAEAFCCB4EB2B3FCDD29CE4EE06857F68E
>
>     That would be okay; the result would have to be strictly limited
>     to a single application/pkix-cert, not multiple certificates
>     (compare with Section 5 of draft-bhjl-x509-srv-00). However, I
>     question the utility of such a thing. If you know the SHA-256 hash
>     but not anything else about the certificate, are you sure you want
>     to be asking "example.com "? Maybe you should
>     be asking elsewhere? (Compare with the ni: URI scheme.) If you
>     know the SHA-256 hash and you know that you are hunting for a
>     certificate that matches an e-mail address, it makes more sense to
>     use draft-bhjl-x509-srv-00 or something else to return all the
>     known certificates, and then have the client verify that one of
>     the certificates matches the SHA-256 hash. The client has to do
>     this anyway for security reasons.
>     Certspecs are meant to be "simple" enough that they can be
>     included as components of broader formats, including certificate
>     queries. For example:
>
>     https://certs.example.com/certificates/search.cgi?uri=3Dsomeuser%40=
example.com&
>     
>     certspec=3DSHA-256:64DF42FF3410B579958ADDC
>     C5C35E6BAEAFCCB4EB2B3FCDD29CE4EE06857F68E&certspec=3DSHA-1:FEA3
>     64082CEACA2AC80E8AECFA2224BCC3210D2A
>
>     Would be a better example (assuming that the client really did
>     forget about the original certificate, perhaps because it is very
>     resource-constrained): the premise being that bandwidth can be
>     saved by doing server-side filtering.
>>     1. The title is a little bit confusing, as much of the document
>>     is about naming certificates.  Perhaps "Naming and Metadata
>>     Specification for..."?
>     Actually...none of the document is about naming certificates,
>     because they aren't names.=20
>
> Regarding the title, then perhaps something describing how this=20
> document is to be used?
Hmm... Textual Format for Identifying Certificates Identifying=20
Certficates in Text Conveying Certificates in Textual Formats and=20
Protocols, with Attributes
>
>     Certificates don't have globally unique "names". The closest thing
>     to a name is Issuer + Serial Number, as issuer is theoretically
>     unique and serial number is supposed to be unique for every cert
>     issued by a particular CA. But we know this is not true because CA
>     issuers are not bound to follow some global Directory, which never
>     materialized. The family of element-based specs is included for
>     compatibility (e.g., with CMS, which identifies certificates based
>     on issuerAndSerialNumber or SubjectKeyIdentifier; also
>     compatibility with the MS CryptoAPI and Mozilla NSS major
>     implementations ) and efficiency (e.g., database lookups), rather
>     than absolute unambiguity. They are only unambiguous given certain
>     assumptions, namely assumptions about the store(s) where the
>     certificates are being looked up. Several drafts ago, I tried to
>     call these things names by stuffing them into the URN protocol
>     slot. That ultimately failed, mainly because a lot of these things
>     aren't names. Hashes (fingerprints) of certificates are also not
>     truly unambiguous names--they are only unambiguous given certain
>     engineering assumptions for certain periods of time. If you doubt
>     this, consider whether MD5:01332f309262d789097cdda53be5174d is
>     really the kind of "name" that we are looking for. All
>     cryptographic hash algorithms are susceptible to cryptanalysis;
>     it's just a matter of time and ingenuity. The data-based specs are
>     also not really names; it would be like "naming" a human being by
>     his or her entire genome sequence. So they aren't names; they are
>     just ways of getting at a (single) certificate in text.
>
> And yet there's value in identifying certificates for lookup and=20
> such.  Just pointing what I thought was a use for the specification.
Yes, there is definitely value. Actually when it comes to actual names,=20
it makes sense to have a string format that can be used to look up=20
certificates by the names that the certificate certifies. SUBJECTEXP:=20
comes close in the current draft, but appending the notAfter date is=20
supposed to narrow it down to just one certificate (in theory, anyway).=20
Perhaps there is demand for a textual format (namely, the "LDAP string=20
syntax") for GeneralName. If so, I would not mind including it in this=20
draft or in a companion document. In keeping with using OpenSSL as=20
inspiration, basically GeneralName would look like the syntax of Subject =

Alternative Name in=20
. While=20
such a syntax is not a "certspec" in the sense that it doesn't aim to=20
identify a single certificate, but rather, a family of certificates, it=20
could be used in a lookup using an appropriate, adjacent protocol slot,=20
and is syntactically compatible. I am also willing to include a textual=20
format that specifies the subject DN, for analogous reasons to=20
specifying the GeneralName. A "search" or "lookup" operation has "has"=20
semantics: if a certificate /has/ a name component, then it matches. In=20
contrast, an "identify" operation has "is" semantics: if a certificate's =

name /is/ all of the components specified (for subject DN and for SAN,=20
this also means, /in order/), then it matches. (I do not feel that=20
providing a GeneralName spec with "is" semantics adds value, but can be=20
convinced otherwise.) There is a relationship between GeneralName and=20
draft-ietf-pkix-eai-addresses-01 that needs to be addressed: if a=20
textual encoding specifies email:f=F3o@b=E1r.com, an implementation ought=
 to=20
be smart about encoding (and searching) for the pkix-eai-addresses=20
method instead of the rfc822Name method. This should be discussed in any =

context that searches for certificates based on e-mail addresses. Sean
> -Wei
>
>>     3. Modify the ABNF to clearly identify the certspec type vs data
>     The current ABNF is intentional. Prior drafts had "certspec-type",
>     but the most recent drafts remove that because it gets in the way
>     of human usability (copy-and-paste-ability). I thought about
>     "path:" or "file:" for the filesystem-based path specs, but
>     "file:" looks too much like a file: URI (it's not a file URI), and
>     "path:" is both a bit superfluous, and a bit ambiguous (i.e., what
>     kind of path?). Overall, a conforming implementation can recognize
>     additional specs in its own special way, if it wants to. This
>     specification only requires implementations to recognize a few
>     important string patterns. This reminds me...I was going to
>     include Registry keys, such as
>     HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\CA\Certifi=
cates\109F1CAED645BB78B3EA2B94C0697C740733031C\Blob
>     In that example, it's totally obvious that "HKEY_LOCAL_MACHINE\"
>     is the prefix to a Registry key or value (and, notably, not a
>     filesystem path). That would be an example of a class of certspecs
>     that is not so great to exchange on the open Internet, but is very
>     useful for a managed intranet. Best regards, Sean
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


--------------DB7B7300952A9F856F31676F
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 6/15/2016 2:26 PM, Wei Chuang wrote:

    

    

      


        


          
On Wed, Jun 15, 2016 at 12:15 PM,
            Sean Leonard <dev+ietf@seantek.com>
            wrote:

            

              

                
Returning
                  to the rest of the response:

                    

                    On 6/9/2016 10:49 AM, Wei Chuang wrote:

                  

                
                  

                    
Just some thoughts about this draft:

                    

                  

                  

                
                  

                    

                      
2. This document would do best when coupled
                        with work on methods to access certificates such
                        as draft-bhjl-x509-srv-00 that would use it. 

                      

                    

                  

                  

                 Yes, I think that would be fine and a useful
                coupling.

                

                However, the motivator for certspec is to identify a
                single certificate unambiguously, not a family of
                certificates. Use cases include in configuration data
                for Internet-connected devices, such as for
                administrators administering certificate settings on
                clients, server, or nodes on an internal network, using
                various configuration formats (config files, YANG, XML,
                JSON, etc.).

                

                Section 2 says "Certificate specifications, or
                "certspecs", are not designed or intended to provide a
                search tool or query language to match multiple
                certificates. The goal is to replace data elements that
                would otherwise have to include whole certificates, or
                that employ proprietary reference schemes." It does not
                attempt, for example, to provide a syntax for matching
                "any certificate for an e-mail address", as
                draft-bhjl-x509-srv-00 suggests:

                

                
https://certs.example.com/certificates/search.cgi?uri=someuser%40example.com

    

    This is important because it is likely that such a query (it is
    a query) could return multiple certificates. It would be fine to use
    draft-bhjl-x509-srv-00 to construct a different query:

    

    
https://certs.example.com/certificates/search.cgi?certspec=SHA-256:64DF
42FF3410B579958ADDCC5C35E6BAEAFCCB4EB2B3FCDD29CE4EE06857F68E

    

    That would be okay; the result would have to be strictly limited to
    a single application/pkix-cert, not multiple certificates (compare
    with Section 5 of draft-bhjl-x509-srv-00). However, I question the
    utility of such a thing. If you know the SHA-256 hash but not
    anything else about the certificate, are you sure you want to be
    asking "example.com"? Maybe you should be asking elsewhere? (Compare
    with the ni: URI scheme.) If you know the SHA-256 hash and you know
    that you are hunting for a certificate that matches an e-mail
    address, it makes more sense to use draft-bhjl-x509-srv-00 or
    something else to return all the known certificates, and then have
    the client verify that one of the certificates matches the SHA-256
    hash. The client has to do this anyway for security reasons.

    

      


        Certspecs are meant to be "simple" enough that they can be
        included as components of broader formats, including certificate
        queries. For example:

        

        
https://certs.example.com/certificates/search.cgi?uri=someuser%40example.com&
certspec=SHA-256:64DF42FF3410B579958ADDC
C5C35E6BAEAFCCB4EB2B3FCDD29CE4EE06857F68E&certspec=SHA-1:FEA3
64082CEACA2AC80E8AECFA2224BCC3210D2A

        

        Would be a better example (assuming that the client really did
        forget about the original certificate, perhaps because it is
        very resource-constrained): the premise being that bandwidth can
        be saved by doing server-side filtering.

        

      

    

    

      

        
1. The title is a little bit confusing, as much of the
          document is about naming certificates.  Perhaps "Naming and
          Metadata Specification for..."?

      

    

    Actually...none of the document is about naming certificates,
    because they aren't names.



Regarding the title, then perhaps something describing how this document is to be used?

Hmm...
Textual Format for Identifying Certificates
Identifying Certficates in Text
Conveying Certificates in Textual Formats and Protocols, with Attributes




 

    

    Certificates don't have globally unique "names". The closest thing
    to a name is Issuer + Serial Number, as issuer is theoretically
    unique and serial number is supposed to be unique for every cert
    issued by a particular CA. But we know this is not true because CA
    issuers are not bound to follow some global Directory, which never
    materialized.

    

    The family of element-based specs is included for compatibility
    (e.g., with CMS, which identifies certificates based on
    issuerAndSerialNumber or SubjectKeyIdentifier; also compatibility
    with the MS CryptoAPI and Mozilla NSS major implementations ) and
    efficiency (e.g., database lookups), rather than absolute
    unambiguity. They are only unambiguous given certain assumptions,
    namely assumptions about the store(s) where the certificates are
    being looked up.

    

    Several drafts ago, I tried to call these things names by stuffing
    them into the URN protocol slot. That ultimately failed, mainly
    because a lot of these things aren't names. Hashes (fingerprints) of
    certificates are also not truly unambiguous names--they are only
    unambiguous given certain engineering assumptions for certain
    periods of time. If you doubt this, consider whether
    MD5:01332f309262d789097cdda53be5174d is really the kind of "name"
    that we are looking for. All cryptographic hash algorithms are
    susceptible to cryptanalysis; it's just a matter of time and
    ingenuity. The data-based specs are also not really names; it would
    be like "naming" a human being by his or her entire genome sequence.

    

    So they aren't names; they are just ways of getting at a (single)
    certificate in text.


And yet there's value in identifying certificates for lookup and such.  Just pointing what I thought was a use for the specification.

Yes, there is definitely value.

Actually when it comes to actual names, it makes sense to have a string format that can be used to look up certificates by the names that the certificate certifies. SUBJECTEXP: comes close in the current draft, but appending the notAfter date is supposed to narrow it down to just one certificate (in theory, anyway).

Perhaps there is demand for a textual format (namely, the "LDAP string syntax") for GeneralName. If so, I would not mind including it in this draft or in a companion document. In keeping with using OpenSSL as inspiration, basically GeneralName would look like the syntax of Subject Alternative Name in <https://www.openssl.org/docs/manmaster/apps/x509v3_config.html>. While such a syntax is not a "certspec" in the sense that it doesn't aim to identify a single certificate, but rather, a family of certificates, it could be used in a lookup using an appropriate, adjacent protocol slot, and is syntactically compatible.

I am also willing to include a textual format that specifies the subject DN, for analogous reasons to specifying the GeneralName. A "search" or "lookup" operation has "has" semantics: if a certificate has a name component, then it matches. In contrast, an "identify" operation has "is" semantics: if a certificate's name is all of the components specified (for subject DN and for SAN, this also means, in order), then it matches. (I do not feel that providing a GeneralName spec with "is" semantics adds value, but can be convinced otherwise.)

There is a relationship between GeneralName and draft-ietf-pkix-eai-addresses-01 that needs to be addressed: if a textual encoding specifies email:fóo@bár.com, an implementation ought to be smart about encoding (and searching) for the pkix-eai-addresses method instead of the rfc822Name method. This should be discussed in any context that searches for certificates based on e-mail addresses.

Sean




-Wei
 


    

    

      

        
3. Modify the ABNF to clearly identify the certspec type vs
          data

      

    

    

    The current ABNF is intentional. Prior drafts had "certspec-type",
    but the most recent drafts remove that because it gets in the way of
    human usability (copy-and-paste-ability).

    

    I thought about "path:" or "file:" for the filesystem-based path
    specs, but "file:" looks too much like a file: URI (it's not a file
    URI), and "path:" is both a bit superfluous, and a bit ambiguous
    (i.e., what kind of path?). Overall, a conforming implementation can
    recognize additional specs in its own special way, if it wants to.
    This specification only requires implementations to recognize a few
    important string patterns.

    

    This reminds me...I was going to include Registry keys, such as

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\CA\Certificates\109F1CAED645BB78B3EA2B94C0697C740733031C\Blob

    

    In that example, it's totally obvious that "HKEY_LOCAL_MACHINE\" is
    the prefix to a Registry key or value (and, notably, not a
    filesystem path). That would be an example of a class of certspecs
    that is not so great to exchange on the open Internet, but is very
    useful for a managed intranet.

    

    Best regards,

    

    Sean
  











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







--------------DB7B7300952A9F856F31676F--


From nobody Thu Jun 16 06:31:10 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A9B12D664 for ; Thu, 16 Jun 2016 06:31:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 jOSjmpD8jGo2 for ; Thu, 16 Jun 2016 06:31:07 -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 4B89012D650 for ; Thu, 16 Jun 2016 06:31:07 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 601EB50A84 for ; Thu, 16 Jun 2016 09:31:06 -0400 (EDT)
To: spasm@ietf.org
References: <064201d1ada1$0b94dc20$22be9460$@augustcellars.com> <5740CA5D.9000900@isode.com> <000301d1b4a3$f6fdc470$e4f94d50$@augustcellars.com>
From: Sean Leonard 
Message-ID: 
Date: Thu, 16 Jun 2016 06:31:36 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <000301d1b4a3$f6fdc470$e4f94d50$@augustcellars.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 16 Jun 2016 13:31:08 -0000

A few additional points popped out at me:

Currently, draft-melnikov-spasm-eai-addresses-01 does not restrict out 
plain (ASCII-only) e-mail addresses. This means that ASCII-only e-mail 
addresses can be "hidden" from implementations that don't support this 
new eai method. I am not in favor of this. The text is not really clear 
about whether non-internationalized email addresses are allowed in 
eaiName. It should be clear in saying that eaiName is restricted to 
internationalized email addresses, i.e., where there is at least one 
character beyond the ASCII range in the local-part. Email addresses that 
are limited to ASCII in the local-part MUST be encoded in rfc822Name only.

Can the ASN.1 reflect this with an appropriate string restriction?

The comparison algorithm is convoluted. There will be implementations 
that don't bother with the convoluted algorithm, and running the 
convoluted algorithm over thousands or hundreds of millions of 
certificates is going to have a meaningful impact on performance. It's 
better to put the address in a form that is amenable to octet-by-octet 
comparison. This argues in favor of requiring the domain name to be in 
U-labels instead of A-labels, and to normalize case (to lowercase) for 
characters in the ASCII range.

Sean


From nobody Thu Jun 16 10:34:17 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A08512DA3B for ; Thu, 16 Jun 2016 10:34:15 -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 F06VvvnbbDwM for ; Thu, 16 Jun 2016 10:34:13 -0700 (PDT)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FCD412D9F3 for ; Thu, 16 Jun 2016 10:34:11 -0700 (PDT)
Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 7D60F2CA3E; Thu, 16 Jun 2016 10:34:11 -0700 (PDT)
From: "Jim Schaad" 
To: "'Sean Leonard'" , 
References: <064201d1ada1$0b94dc20$22be9460$@augustcellars.com> <5740CA5D.9000900@isode.com> <000301d1b4a3$f6fdc470$e4f94d50$@augustcellars.com> 
In-Reply-To: 
Date: Thu, 16 Jun 2016 10:34:10 -0700
Message-ID: <015a01d1c7f5$4b63ed50$e22bc7f0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGKZnjtH2+4jtNhP837mF1TA1TL1wGQkjeNAaji1GsCk4ACcqBMsXjw
Content-Language: en-us
Archived-At: 
Subject: Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 16 Jun 2016 17:34:16 -0000

> -----Original Message-----
> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean Leonard
> Sent: Thursday, June 16, 2016 6:32 AM
> To: spasm@ietf.org
> Subject: Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01
> 
> A few additional points popped out at me:
> 
> Currently, draft-melnikov-spasm-eai-addresses-01 does not restrict out
plain
> (ASCII-only) e-mail addresses. This means that ASCII-only e-mail addresses
can
> be "hidden" from implementations that don't support this new eai method. I
am
> not in favor of this. The text is not really clear about whether non-
> internationalized email addresses are allowed in eaiName. It should be
clear in
> saying that eaiName is restricted to internationalized email addresses,
i.e.,
> where there is at least one character beyond the ASCII range in the
local-part.
> Email addresses that are limited to ASCII in the local-part MUST be
encoded in
> rfc822Name only.
> 
> Can the ASN.1 reflect this with an appropriate string restriction?

Almost nobody implements it but it would be

eaiName ::= UTF8String (SIZE(1..MAX)) (PATTERN [^!-}]*)

The pattern can probably be improved if one has a better sense of what
characters are permitted in an email address.  This one just says don't
allow for any string which consists of just these characters.

This is probably a case where you do not care if the pattern matches too
many items as one would not care if you matched things which were not email
addresses.

Jim


> 
> The comparison algorithm is convoluted. There will be implementations that
> don't bother with the convoluted algorithm, and running the convoluted
> algorithm over thousands or hundreds of millions of certificates is going
to have
> a meaningful impact on performance. It's better to put the address in a
form
> that is amenable to octet-by-octet comparison. This argues in favor of
requiring
> the domain name to be in U-labels instead of A-labels, and to normalize
case (to
> lowercase) for characters in the ASCII range.
> 
> Sean
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


From nobody Fri Jun 17 09:30:09 2016
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 B225112D805; Fri, 17 Jun 2016 09:30:06 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160617163006.9726.2742.idtracker@ietfa.amsl.com>
Date: Fri, 17 Jun 2016 09:30:06 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [Spasm] ID Tracker State Update Notice: 
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "This is a venue 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, 17 Jun 2016 16:30:07 -0000

State changed to External review.
ID Tracker URL: https://datatracker.ietf.org/doc/charter-ietf-spasm/


From nobody Fri Jun 17 09:33:42 2016
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 7091D12D85E; Fri, 17 Jun 2016 09:33:37 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160617163337.9633.3485.idtracker@ietfa.amsl.com>
Date: Fri, 17 Jun 2016 09:33:37 -0700
Archived-At: 
Cc: spasm@ietf.org
Subject: [Spasm] WG Review: Some PKIX and SMIME (spasm)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "This is a venue 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, 17 Jun 2016 16:33:37 -0000

A new IETF WG has been proposed in the Security Area. The IESG has not
made any determination yet. The following draft charter was submitted,
and is provided for informational purposes only. Please send your
comments to the IESG mailing list (iesg@ietf.org) by 2016-06-27.

Some PKIX and SMIME (spasm)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
  TBD

Assigned Area Director:
  Stephen Farrell 

Security Area Directors:
  Stephen Farrell 
  Kathleen Moriarty 
 
Mailing list:
  Address: spasm@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/spasm
  Archive: https://www.ietf.org/mail-archive/web/spasm/

Charter: https://datatracker.ietf.org/doc/charter-ietf-spasm/


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 SPASM (Some PKIX and S/MIME) Working Group is chartered to make
updates where there is a known constituency interested in real 
deployment and there is at least one sufficiently well specified 
approach to the update so that the working group can sensibly evaluate 
whether to adopt a proposal.  The current charter encompasses updates to 
satisfy the following needs:

1. Specify the way to include an i18n email address as a subject
   alternative name and an issuer alternative name.
   draft-melnikov-spasm-eai-addresses is a proposal in this space. 

2. Specify the way to use authenticated encryption in S/MIME. 
   draft-schaad-rfc5751-bis is a proposal in this space.

In addition, the SPASM Working Group may investigate other updates to 
the documents produced by the PKIX and S/MIME Working Groups, but the 
SPASM Working Group shall not adopt any of these potential work items 
without rechartering. No such re-chartering is envisaged until one or 
more of the above work items have been successfully delivered to the RFC 
editor queue. 

Milestones:

TBD


From nobody Fri Jun 17 09:34:09 2016
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 93DC112D87C; Fri, 17 Jun 2016 09:33:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: , "The IESG" , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160617163350.9641.52088.idtracker@ietfa.amsl.com>
Date: Fri, 17 Jun 2016 09:33:50 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [Spasm] Telechat update notice: 
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "This is a venue 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, 17 Jun 2016 16:33:53 -0000

Telechat date has been changed to 2016-06-30 from 2016-06-16
ID Tracker URL: https://datatracker.ietf.org/doc/charter-ietf-spasm/


From nobody Fri Jun 17 11:35:40 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792EA12D815 for ; Fri, 17 Jun 2016 11:35:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 YyISkB4sYnRW for ; Fri, 17 Jun 2016 11:35:37 -0700 (PDT)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 ABE8912D84D for ; Fri, 17 Jun 2016 11:35:37 -0700 (PDT)
Received: by mail-oi0-x22d.google.com with SMTP id p204so129668500oih.3 for ; Fri, 17 Jun 2016 11:35:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IrzYGavzUXeEbHFKLj+ESo89L8VYL5XXXSpunwpEeR0=; b=MAkdmPtQGLuc7+9QPTJVhEmKNW3q/NB/0eY/XW1EovArk/STwWLO/kSRs1vgRuQx79 1T48GJE5RpKcqU3PngN6Yqg1T8ObVdezsZ2UpVZxoYUHAfO7j8ET74EtwqAizBnsFTN3 2fSx2HlfKKquT6M+IfYjmPfRa5pSwCCuC7o0iLBX776Pp9cjzhz1DpabB3A+Qk9KprL8 uwL6aC4kFAbbWkqRZ1jCZchd4MRIwKq/zgMrkg5xFX4wP6Rzz9OG4apuKdWsSwhCUGTX 3BC5Xr4Sk6txo2fyUDROVo1XOy1d7/r0rBmqMUeOAZw5weGcd7lNheT7I/A9arKiEti5 G3QQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IrzYGavzUXeEbHFKLj+ESo89L8VYL5XXXSpunwpEeR0=; b=KmO1Q0TqX/e7I/JiWEy1GFQUa5m/vq7AbwPMQH4wfTkMk+CJWytygyEOMSlaBYZ2+N LC189I9qFIu03ZqrW5DW3Bd275mOxNJLZIXZCKfI3KRKCGr37ik/bWebC8vWBFj9keZy 2UYY1eKRPBgU43pOxU/ylJfvCy1dmUZ1YvICoTslCg8bBGUI/zMQS7EdJHo1gv1j5FD7 +vYU42vI/Lxrwr6ZPSYZ9zMEPCWs6TMLakBJV0WZPg/pOf8DAPmm4ua6f/+UhHBxzcLz CeQnd5nethddDGIHk076T+0WutHE5LWBvIZJly40KsAax10nsAhvuTGrjrxgCghJTfBq S5VA==
X-Gm-Message-State: ALyK8tKaPsBJ109FM097I2vXAVAdE17IGDYdKFwoOmQx/Zvl6TQOQY0WhQXn4L9tsmEh5QaCXugVScz0ZEwUsZg/
X-Received: by 10.202.171.143 with SMTP id u137mr2359173oie.31.1466188536345;  Fri, 17 Jun 2016 11:35:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.27.139 with HTTP; Fri, 17 Jun 2016 11:35:35 -0700 (PDT)
In-Reply-To: 
References: <064201d1ada1$0b94dc20$22be9460$@augustcellars.com> <5740CA5D.9000900@isode.com> <000301d1b4a3$f6fdc470$e4f94d50$@augustcellars.com> 
From: Wei Chuang 
Date: Fri, 17 Jun 2016 11:35:35 -0700
Message-ID: 
To: Sean Leonard 
Content-Type: multipart/alternative; boundary=001a113c2efee25c6005357d9eca
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 17 Jun 2016 18:35:39 -0000

--001a113c2efee25c6005357d9eca
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On Thu, Jun 16, 2016 at 6:31 AM, Sean Leonard  wrote:

> A few additional points popped out at me:
>
> Currently, draft-melnikov-spasm-eai-addresses-01 does not restrict out
> plain (ASCII-only) e-mail addresses. This means that ASCII-only e-mail
> addresses can be "hidden" from implementations that don't support this new
> eai method. I am not in favor of this. The text is not really clear about
> whether non-internationalized email addresses are allowed in eaiName. It
> should be clear in saying that eaiName is restricted to internationalized
> email addresses, i.e., where there is at least one character beyond the
> ASCII range in the local-part. Email addresses that are limited to ASCII in
> the local-part MUST be encoded in rfc822Name only.
>

Handling coexistence of rfc822Name and eaiName is an interesting question
and in an ideal world we could switch from one to the other to reduce the
implementation cost.  Realistically we'll have to support both for awhile.
I think your suggestion is good which is to support both but restrict usage
and will likely reduce deployment confusion.  This consequence of this will
likely mean keeping rfc822Name and eaiName as acceptable email address
representations for the foreseeable future.

Let me pose another suggestion I received which is to start a transition to
eaiName- we could add a SHOULD recommendation that all future PKIX subject
email addresses be represented as eaiName, with language stating the intent
to transition to eaiName as the sole representation, along with a SHOULD
NOT on future usage of rfc822Name.  Some future revision could change this
to MUST/MUST-NOT.  What do you think of this approach?


>
> Can the ASN.1 reflect this with an appropriate string restriction?


> The comparison algorithm is convoluted.


Domain name represented in A-labels is what RFC5280 requires for its
verification process (step 7.2).  The draft just simply states insuring it
is represented as A-label in the certificate stored form to reduce risk of
translation error by verifier implementation.


> There will be implementations that don't bother with the convoluted
> algorithm, and running the convoluted algorithm over thousands or hundreds
> of millions of certificates is going to have a meaningful impact on
> performance. It's better to put the address in a form that is amenable to
> octet-by-octet comparison. This argues in favor of requiring the domain
> name to be in U-labels instead of A-labels, and to normalize case (to
> lowercase) for characters in the ASCII range.


A better place to ask for this change, is to update RFC5280 to mandate
comparison as U-label domains.  This draft is just taking the position that
there ought to be just one in certificate domain form which is going to be
whatever the RFC5280 comparison form is.

-Wei


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

--001a113c2efee25c6005357d9eca
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit




On Thu, Jun 16, 2016 at 6:31 AM, Sean Leonard <dev+ietf@seantek.com> wrote:
A few additional points popped out at me:



Currently, draft-melnikov-spasm-eai-addresses-01 does not restrict out plain (ASCII-only) e-mail addresses. This means that ASCII-only e-mail addresses can be "hidden" from implementations that don't support this new eai method. I am not in favor of this. The text is not really clear about whether non-internationalized email addresses are allowed in eaiName. It should be clear in saying that eaiName is restricted to internationalized email addresses, i.e., where there is at least one character beyond the ASCII range in the local-part. Email addresses that are limited to ASCII in the local-part MUST be encoded in rfc822Name only.

Handling coexistence of rfc822Name and eaiName is an interesting question and in an ideal world we could switch from one to the other to reduce the implementation cost.  Realistically we'll have to support both for awhile.  I think your suggestion is good which is to support both but restrict usage and will likely reduce deployment confusion.  This consequence of this will likely mean keeping rfc822Name and eaiName as acceptable email address representations for the foreseeable future.  

Let me pose another suggestion I received which is to start a transition to eaiName- we could add a SHOULD recommendation that all future PKIX subject email addresses be represented as eaiName, with language stating the intent to transition to eaiName as the sole representation, along with a SHOULD NOT on future usage of rfc822Name.  Some future revision could change this to MUST/MUST-NOT.  What do you think of this approach?
 



Can the ASN.1 reflect this with an appropriate string restriction?



The comparison algorithm is convoluted. 

Domain name represented in A-labels is what RFC5280 requires for its verification process (step 7.2).  The draft just simply states insuring it is represented as A-label in the certificate stored form to reduce risk of translation error by verifier implementation.  
 
There will be implementations that don't bother with the convoluted algorithm, and running the convoluted algorithm over thousands or hundreds of millions of certificates is going to have a meaningful impact on performance. It's better to put the address in a form that is amenable to octet-by-octet comparison. This argues in favor of requiring the domain name to be in U-labels instead of A-labels, and to normalize case (to lowercase) for characters in the ASCII range.

A better place to ask for this change, is to update RFC5280 to mandate comparison as U-label domains.  This draft is just taking the position that there ought to be just one in certificate domain form which is going to be whatever the RFC5280 comparison form is.

-Wei
 




Sean




_______________________________________________

Spasm mailing list

Spasm@ietf.org

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





--001a113c2efee25c6005357d9eca--


From nobody Fri Jun 17 12:16:29 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B333012DA1E for ; Fri, 17 Jun 2016 12:16:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 o-WGW1efPNJy for ; Fri, 17 Jun 2016 12:16:26 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6E512DA1C for ; Fri, 17 Jun 2016 12:16:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C949E300436 for ; Fri, 17 Jun 2016 15:16:23 -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 B735oLfSTTQb for ; Fri, 17 Jun 2016 15:16:23 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id E108C300229 for ; Fri, 17 Jun 2016 15:16:22 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: 
Date: Fri, 17 Jun 2016 15:16:24 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <438E0183-E149-4580-B6C2-8D120E070E4C@vigilsec.com>
References: <57519BBB.8050604@cs.tcd.ie> <7255B25B-9278-461C-9480-D4326F63D37B@vigilsec.com> 
To: "spasm@ietf.org" 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Subject: Re: [Spasm] BoF in Berlin or what?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 17 Jun 2016 19:16:28 -0000

Seing that SPASM has a one hour slot on the preliminary schedule and =
that document authors have agreed to do status and open issue =
presentations, I propose the following agenda=85

	SPASM WG Agenda

	0)  Minutes, Jabber Scribe, Bluesheets
	1)  Agenda Bash
	2)  Status and open issues for =
draft-melnikov-spasm-eai-addresses
	3)  Status and open issues for draft-schaad-rfc5751-bis
	4)  WG document adoption
	5)  Wrap Up

The 4th item will be dropped if the IESG has not chartered the SPASM WG =
in time.

Thoughts?

Russ


From nobody Fri Jun 17 15:48:11 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C8A12DC1A for ; Fri, 17 Jun 2016 15:48:09 -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 Z7JdEDrkvz7l for ; Fri, 17 Jun 2016 15:48:08 -0700 (PDT)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE08112DBEB for ; Fri, 17 Jun 2016 15:48:08 -0700 (PDT)
Received: from hebrews (augustcellars.com [50.45.239.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 39B2A2C9FD; Fri, 17 Jun 2016 15:48:08 -0700 (PDT)
From: "Jim Schaad" 
To: "'Russ Housley'" , 
References: <57519BBB.8050604@cs.tcd.ie> <7255B25B-9278-461C-9480-D4326F63D37B@vigilsec.com>  <438E0183-E149-4580-B6C2-8D120E070E4C@vigilsec.com>
In-Reply-To: <438E0183-E149-4580-B6C2-8D120E070E4C@vigilsec.com>
Date: Fri, 17 Jun 2016 15:48:07 -0700
Message-ID: <02c101d1c8ea$515b85b0$f4129110$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHW8767gWSD88kXh4etiVhlBOiuaAHTypiSAkyacpkA+howEJ+7GP2Q
Content-Language: en-us
Archived-At: 
Subject: Re: [Spasm] BoF in Berlin or what?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 17 Jun 2016 22:48:10 -0000

Given the constraints of a one-hour meeting, that looks reasonable.

Jim


> -----Original Message-----
> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley
> Sent: Friday, June 17, 2016 12:16 PM
> To: spasm@ietf.org
> Subject: Re: [Spasm] BoF in Berlin or what?
> 
> Seing that SPASM has a one hour slot on the preliminary schedule and that
> document authors have agreed to do status and open issue presentations, I
> propose the following agenda.
> 
> 	SPASM WG Agenda
> 
> 	0)  Minutes, Jabber Scribe, Bluesheets
> 	1)  Agenda Bash
> 	2)  Status and open issues for draft-melnikov-spasm-eai-addresses
> 	3)  Status and open issues for draft-schaad-rfc5751-bis
> 	4)  WG document adoption
> 	5)  Wrap Up
> 
> The 4th item will be dropped if the IESG has not chartered the SPASM WG in
> time.
> 
> Thoughts?
> 
> Russ
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


From nobody Fri Jun 17 16:12:07 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B57C12DC2C for ; Fri, 17 Jun 2016 16:12:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 10sN1BEiGT42 for ; Fri, 17 Jun 2016 16:12:03 -0700 (PDT)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 B1DE612B046 for ; Fri, 17 Jun 2016 16:12:03 -0700 (PDT)
Received: by mail-oi0-x234.google.com with SMTP id u201so138097967oie.0 for ; Fri, 17 Jun 2016 16:12:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KUqeHABf/5SPG+8KHpF9JW3iUK3vkrB5gpfgSz6Ysqo=; b=f5F0PmZUxVEnatwQAi01UeGZOzyuTWfU5A8Eb3nsGovZEvFttftmHxxiyOz8lVp8zY abfdJrr363Buu7uBlkFbRofL4fnMFHWIbNaMw5FnmRvaY/iC6V3OHj+GMNeiW60BET62 xKoJ3p9QRVns8VJAPfdx+vjO+qRisOHIRDuTGGanhZ+YR/NWlWD9brg2RDDqvBGqpX61 UdoWO2r4lYw4kFtkuBBGqQHE+ujxI1FHp9evBLWkm9QiN3iNd0fAykV+iaA1V5+rQvNH xZ7LB1nDvIm+NHa7ou3dkCVImkVSr2e0NWljSYBo2ArxhefV2Mk9UT+NBRe8QaectvwO zr/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KUqeHABf/5SPG+8KHpF9JW3iUK3vkrB5gpfgSz6Ysqo=; b=Q6Q7biUJXdZbTAQimYs6+sgT+4mDp1TbvxrxwV2Y3xCKUeqSFlLI+wpbg6AScxW/TO 6QWosrYNpZLSRN7KsTUDcl5nKP83/K08q9jbemcEFnWrIYxlWn8zrPx7Ge41RnkHOqTS KdHFKngq0wEs8KY0ysfODbgwui/O23g+I7ykjHd1+byzvapujGPbELgVuBokh+PNZ8uL 0Ca4aGQXMFWnuO9UlnNklgy0k85DUIKjseCgKL9wWLxyugv1NwlJHsCqxPmPkkd24F5q 9YElqW9Qqjq3QfqUpR71P+yRX+PNA9QdDcdldPoc2qT+yOpALWFoPztiiY0zDeVRotzp iV3A==
X-Gm-Message-State: ALyK8tJKStF0V/ErLylOQHoEqM51loMjxxyTiUNFgP8/JUL/vXENKIWs0IWz7I7LIRZ6UTATutr4hhJAyRG9LXt8
X-Received: by 10.202.225.8 with SMTP id y8mr2973196oig.192.1466205122967; Fri, 17 Jun 2016 16:12:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.27.139 with HTTP; Fri, 17 Jun 2016 16:12:02 -0700 (PDT)
In-Reply-To: <02c101d1c8ea$515b85b0$f4129110$@augustcellars.com>
References: <57519BBB.8050604@cs.tcd.ie> <7255B25B-9278-461C-9480-D4326F63D37B@vigilsec.com>  <438E0183-E149-4580-B6C2-8D120E070E4C@vigilsec.com> <02c101d1c8ea$515b85b0$f4129110$@augustcellars.com>
From: Wei Chuang 
Date: Fri, 17 Jun 2016 16:12:02 -0700
Message-ID: 
To: Jim Schaad 
Content-Type: multipart/alternative; boundary=001a113cd17886124a0535817b9e
Archived-At: 
Cc: spasm@ietf.org, Russ Housley 
Subject: Re: [Spasm] BoF in Berlin or what?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 17 Jun 2016 23:12:05 -0000

--001a113cd17886124a0535817b9e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

That schedule looks good to me too.

-Wei

On Fri, Jun 17, 2016 at 3:48 PM, Jim Schaad  wrote:

> Given the constraints of a one-hour meeting, that looks reasonable.
>
> Jim
>
>
> > -----Original Message-----
> > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley
> > Sent: Friday, June 17, 2016 12:16 PM
> > To: spasm@ietf.org
> > Subject: Re: [Spasm] BoF in Berlin or what?
> >
> > Seing that SPASM has a one hour slot on the preliminary schedule and that
> > document authors have agreed to do status and open issue presentations, I
> > propose the following agenda.
> >
> >       SPASM WG Agenda
> >
> >       0)  Minutes, Jabber Scribe, Bluesheets
> >       1)  Agenda Bash
> >       2)  Status and open issues for draft-melnikov-spasm-eai-addresses
> >       3)  Status and open issues for draft-schaad-rfc5751-bis
> >       4)  WG document adoption
> >       5)  Wrap Up
> >
> > The 4th item will be dropped if the IESG has not chartered the SPASM WG
> in
> > time.
> >
> > Thoughts?
> >
> > Russ
> >
> > _______________________________________________
> > Spasm mailing list
> > Spasm@ietf.org
> > https://www.ietf.org/mailman/listinfo/spasm
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>

--001a113cd17886124a0535817b9e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


That schedule looks good to me too.

-Wei

On Fri, Jun 17, 2016 at 3:48 PM, Jim Schaad <ietf@augustcellars.com> wrote:
Given the constraints of a one-hour meeting, that looks reasonable.



Jim





> -----Original Message-----

> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley

> Sent: Friday, June 17, 2016 12:16 PM

> To: spasm@ietf.org

> Subject: Re: [Spasm] BoF in Berlin or what?

>

> Seing that SPASM has a one hour slot on the preliminary schedule and that

> document authors have agreed to do status and open issue presentations, I

> propose the following agenda.


>

>       SPASM WG Agenda

>

>       0)  Minutes, Jabber Scribe, Bluesheets

>       1)  Agenda Bash

>       2)  Status and open issues for draft-melnikov-spasm-eai-addresses

>       3)  Status and open issues for draft-schaad-rfc5751-bis

>       4)  WG document adoption

>       5)  Wrap Up

>

> The 4th item will be dropped if the IESG has not chartered the SPASM WG in

> time.

>

> Thoughts?

>

> Russ

>

> _______________________________________________

> Spasm mailing list

> Spasm@ietf.org

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



_______________________________________________

Spasm mailing list

Spasm@ietf.org

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





--001a113cd17886124a0535817b9e--


From nobody Sat Jun 18 07:12:48 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2301A12D528 for ; Sat, 18 Jun 2016 07:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 Pm4z4x-UIhPr for ; Sat, 18 Jun 2016 07:12:41 -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 2741F12D1BD for ; Sat, 18 Jun 2016 07:12:41 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7E93F509B6; Sat, 18 Jun 2016 10:12:39 -0400 (EDT)
To: Wei Chuang 
References: <064201d1ada1$0b94dc20$22be9460$@augustcellars.com> <5740CA5D.9000900@isode.com> <000301d1b4a3$f6fdc470$e4f94d50$@augustcellars.com>  
From: Sean Leonard 
Message-ID: 
Date: Sat, 18 Jun 2016 07:13:09 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------D51ED7447CF6D1D47AB501BC"
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 18 Jun 2016 14:12:44 -0000

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

On 6/17/2016 11:35 AM, Wei Chuang wrote:
>
>
> On Thu, Jun 16, 2016 at 6:31 AM, Sean Leonard  > wrote:
>
>     A few additional points popped out at me:
>
>     Currently, draft-melnikov-spasm-eai-addresses-01 does not restrict
>     out plain (ASCII-only) e-mail addresses. This means that
>     ASCII-only e-mail addresses can be "hidden" from implementations
>     that don't support this new eai method. I am not in favor of this.
>     The text is not really clear about whether non-internationalized
>     email addresses are allowed in eaiName. It should be clear in
>     saying that eaiName is restricted to internationalized email
>     addresses, i.e., where there is at least one character beyond the
>     ASCII range in the local-part. Email addresses that are limited to
>     ASCII in the local-part MUST be encoded in rfc822Name only.
>
>
> Handling coexistence of rfc822Name and eaiName is an interesting 
> question and in an ideal world we could switch from one to the other 
> to reduce the implementation cost. Realistically we'll have to support 
> both for awhile.  I think your suggestion is good which is to support 
> both but restrict usage and will likely reduce deployment confusion.  
> This consequence of this will likely mean keeping rfc822Name and 
> eaiName as acceptable email address representations for the 
> foreseeable future.

Okay.

>
> Let me pose another suggestion I received which is to start a 
> transition to eaiName- we could add a SHOULD recommendation that all 
> future PKIX subject email addresses be represented as eaiName, with 
> language stating the intent to transition to eaiName as the sole 
> representation, along with a SHOULD NOT on future usage of 
> rfc822Name.  Some future revision could change this to MUST/MUST-NOT.  
> What do you think of this approach?

TL;DR: I don't believe that rfc822Name [1] can formally or practically 
be deprecated unless you work closely with ITU-T, and evaluate market 
impact.

The way that GeneralName works is that there are certain "core" name 
types that are given an explicit "CONTEXT-SPECIFIC" tag class 
identifier, leading to a very compact representation. rfc822Name is [1], 
dNSName is [2], etc.

For "non-core types", GeneralName works using the general model of type 
extension using TYPE-IDENTIFIER, namely, an OID and the open type 
defined by the OID. The otherName extended type is itself tagged with 
[0]. When otherName = eaiName gets an OID, that OID is going to bloat 
the GeneralName, for each and every name. (We are only talking about ~10 
bytes, but ~10 bytes multiplied over possibly multiple e-mail addresses 
multiplied over billions of certificates...and other protocols in which 
it might be used...) Moreover, it's going to make validation and 
name-comparing logic more complicated. Consider that Section 4.2.1.10 of 
RFC 5280 says that both dNSName and rfc822Name SHOULD be supported for 
name constraints.

If the long-term goal is to use one field exclusively, it makes a lot 
more engineering sense to change the definition of rfc822Name to 
UTF8String, or, to add a new eaiName [9] UTF8String. Both of those paths 
will have to be done with ITU-T coordination. I have raised this issue 
before and the consensus on this list was against those approaches. Just 
pointing it out. As long as GeneralName is formally controlled by ITU-T 
X.509, if you want to take a step beyond "supporting eaiName" and go to 
"mandate eaiName and deprecate rfc822Name", you have to do something in 
X.509 to deprecate it. At that point, you may as well do something in 
X.509 to replace rfc822Name with a name form the compact way.


>
>     Can the ASN.1 reflect this with an appropriate string restriction?
>
>
>     The comparison algorithm is convoluted. 
>
>
> Domain name represented in A-labels is what RFC5280 requires for its 
> verification process (step 7.2).  The draft just simply states 
> insuring it is represented as A-label in the certificate stored form 
> to reduce risk of translation error by verifier implementation.

Section 7.2 of RFC 5280 only applies to dNSName field; it does not apply 
to other fields.

That also doesn't change the fact that it's convoluted. :)

>     There will be implementations that don't bother with the
>     convoluted algorithm, and running the convoluted algorithm over
>     thousands or hundreds of millions of certificates is going to have
>     a meaningful impact on performance. It's better to put the address
>     in a form that is amenable to octet-by-octet comparison. This
>     argues in favor of requiring the domain name to be in U-labels
>     instead of A-labels, and to normalize case (to lowercase) for
>     characters in the ASCII range.
>
>
> A better place to ask for this change, is to update RFC5280 to mandate 
> comparison as U-label domains.  This draft is just taking the position 
> that there ought to be just one in certificate domain form which is 
> going to be whatever the RFC5280 comparison form is.

Section 7.2 of RFC 5280 limits itself to dNSName. It actually doesn't 
say anything about other name slots, including URI or rfc822Name. The 
reason why RFC 5280 says anything is because dNSName is limited to 
IA5String, but IDNs were "a real thing" back in 2008. EAI was not a real 
thing back then.

If folks insist on case-sensitive comparison of the local-part and 
case-insensitive comparison of the domain part in the ASCII range, then 
maybe it makes more sense to define eaiName as:
SEQUENCE {
  localPart UTF8String,
  domain IA5String }

That way, an application can easily compare the localPart with memcmp 
(because it can contain NULLs), and the domain with stricmp. No hunting 
for quotations or "@" needed.

The advantage of using U-labels (in conjunction with mandatory 
quote-or-no-quote rules) is that the eaiName can be represented in a 
single UTF8String, and can be compared in a single memcmp.


Sean


--------------D51ED7447CF6D1D47AB501BC
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 6/17/2016 11:35 AM, Wei Chuang
      wrote:

    

    

      


        


          
On Thu, Jun 16, 2016 at 6:31 AM, Sean
            Leonard <dev+ietf@seantek.com>
            wrote:

            
A few
              additional points popped out at me:

              

              Currently, draft-melnikov-spasm-eai-addresses-01 does
              not restrict out plain (ASCII-only) e-mail addresses. This
              means that ASCII-only e-mail addresses can be "hidden"
              from implementations that don't support this new eai
              method. I am not in favor of this. The text is not really
              clear about whether non-internationalized email addresses
              are allowed in eaiName. It should be clear in saying that
              eaiName is restricted to internationalized email
              addresses, i.e., where there is at least one character
              beyond the ASCII range in the local-part. Email addresses
              that are limited to ASCII in the local-part MUST be
              encoded in rfc822Name only.

            

            


            

            
Handling coexistence of rfc822Name and eaiName is an
              interesting question and in an ideal world we could switch
              from one to the other to reduce the implementation cost. 
              Realistically we'll have to support both for awhile.  I
              think your suggestion
              is good which is to support both but restrict usage and will likely
              reduce deployment confusion.  This consequence of this
              will likely mean keeping rfc822Name and eaiName as
              acceptable email address representations for the
              foreseeable future.  

            

          

        

      

    

    

    Okay.

    

    

      

        

          

            


            

            
Let me pose another suggestion I received which is to
              start a transition to eaiName- we could add a SHOULD
              recommendation that all future PKIX subject email
              addresses be represented as eaiName, with language stating
              the intent to transition to eaiName as the sole
              representation, along with a SHOULD NOT on future usage of
              rfc822Name.  Some future revision could change this to
              MUST/MUST-NOT.  What do you think of this approach?

            

          

        

      

    

    

    TL;DR: I don't believe that rfc822Name [1] can formally or
    practically be deprecated unless you work closely with ITU-T, and
    evaluate market impact.

    

    The way that GeneralName works is that there are certain "core" name
    types that are given an explicit "CONTEXT-SPECIFIC" tag class
    identifier, leading to a very compact representation. rfc822Name is
    [1], dNSName is [2], etc.

    

    For "non-core types", GeneralName works using the general model of
    type extension using TYPE-IDENTIFIER, namely, an OID and the open
    type defined by the OID. The otherName extended type is itself
    tagged with [0]. When otherName = eaiName gets an OID, that OID is
    going to bloat the GeneralName, for each and every name. (We are
    only talking about ~10 bytes, but ~10 bytes multiplied over possibly
    multiple e-mail addresses multiplied over billions of
    certificates...and other protocols in which it might be used...)
    Moreover, it's going to make validation and name-comparing logic
    more complicated. Consider that Section 4.2.1.10 of RFC 5280 says
    that both dNSName and rfc822Name SHOULD be supported for name
    constraints.

    

    If the long-term goal is to use one field exclusively, it makes a
    lot more engineering sense to change the definition of rfc822Name to
    UTF8String, or, to add a new eaiName [9] UTF8String. Both of those
    paths will have to be done with ITU-T coordination. I have raised
    this issue before and the consensus on this list was against those
    approaches. Just pointing it out. As long as GeneralName is formally
    controlled by ITU-T X.509, if you want to take a step beyond
    "supporting eaiName" and go to "mandate eaiName and deprecate
    rfc822Name", you have to do something in X.509 to deprecate it. At
    that point, you may as well do something in X.509 to replace
    rfc822Name with a name form the compact way.

    

    

    

      

        

          

            

              

              Can the ASN.1 reflect this with an appropriate string
              restriction?

            

              

              The comparison algorithm is convoluted. 

            


            

            
Domain name represented in A-labels is what RFC5280
              requires for its verification process (step 7.2).  The
              draft just simply states insuring it is represented as
              A-label in the certificate stored form to reduce risk of
              translation error by verifier implementation.  

            

          

        

      

    

    

    Section 7.2 of RFC 5280 only applies to dNSName field; it does not
    apply to other fields.

    

    That also doesn't change the fact that it's convoluted. :)

    

    

      

        

          

            
 

            
There
              will be implementations that don't bother with the
              convoluted algorithm, and running the convoluted algorithm
              over thousands or hundreds of millions of certificates is
              going to have a meaningful impact on performance. It's
              better to put the address in a form that is amenable to
              octet-by-octet comparison. This argues in favor of
              requiring the domain name to be in U-labels instead of
              A-labels, and to normalize case (to lowercase) for
              characters in the ASCII range.

            


            

            
A better place to ask for this change, is to update
              RFC5280 to mandate comparison as U-label domains.  This
              draft is just taking the position that there ought to be
              just one in certificate domain form which is going to be
              whatever the RFC5280 comparison form is.

          

        

      

    

    

    Section 7.2 of RFC 5280 limits itself to dNSName. It actually
    doesn't say anything about other name slots, including URI or
    rfc822Name. The reason why RFC 5280 says anything is because dNSName
    is limited to IA5String, but IDNs were "a real thing" back in 2008.
    EAI was not a real thing back then.

    

    If folks insist on case-sensitive comparison of the local-part and
    case-insensitive comparison of the domain part in the ASCII range,
    then maybe it makes more sense to define eaiName as:

    SEQUENCE {

     localPart UTF8String,

     domain IA5String }

    

    That way, an application can easily compare the localPart with
    memcmp (because it can contain NULLs), and the domain with stricmp.
    No hunting for quotations or "@" needed.

    

    The advantage of using U-labels (in conjunction with mandatory
    quote-or-no-quote rules) is that the eaiName can be represented in a
    single UTF8String, and can be compared in a single memcmp.

    

    

    Sean

    

  


--------------D51ED7447CF6D1D47AB501BC--


From nobody Sat Jun 18 07:29:28 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07C112D552 for ; Sat, 18 Jun 2016 07:29:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 YOK_ngMQdOK7 for ; Sat, 18 Jun 2016 07:29:26 -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 8E86112D54C for ; Sat, 18 Jun 2016 07:29:26 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 73A2E509B8 for ; Sat, 18 Jun 2016 10:29:25 -0400 (EDT)
To: spasm@ietf.org
From: Sean Leonard 
Message-ID: <270ecf29-302a-c038-ab87-207d0dbe7ffc@seantek.com>
Date: Sat, 18 Jun 2016 07:29:56 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Spasm] Can we address the emailAddress DN issue
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 18 Jun 2016 14:29:27 -0000

Since we are spending all this time on eai addresses in GeneralName, can 
we address the emailAddress DN issue, and the mail (or other identifier) 
LDAP issue?

Many LDAP directories store e-mail addresses in the mail 
0.9.2342.19200300.100.1.3 attribute (derived from COSINE).

RFC 5280 (and S/MIME) say specific things about handling the 
emailAddress 1.2.840.113549.1.9.1 attribute (derived from PKCS #9).

I think we ought to deal with it/them.

Even if you are of the view that emailAddress is a legacy attribute that 
ought not be used for "new applications", there's no denying that CAs 
still issue certificates with that attribute. Furthermore, the mail 
attribute is actively used in LDAP, including (for example) as an LDAP 
search query term to look up certificates.

Ideally we could unify the attributes so that both LDAP and 
(PKIX-related) DN use the same attribute.

Sean


From nobody Sun Jun 19 02:59:40 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58FD12B00E for ; Sun, 19 Jun 2016 02:59:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.426
X-Spam-Level: 
X-Spam-Status: No, score=-3.426 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 9uklgdJHyQbR for ; Sun, 19 Jun 2016 02:59:37 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 38E6A12B006 for ; Sun, 19 Jun 2016 02:59:37 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id d132so173717171oig.1 for ; Sun, 19 Jun 2016 02:59:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mSXrWZOvXmooCVyga1KeNd5zTeXdIAA7lyiNLAgfBgA=; b=Ik+Q83a27U5j7AnrnFH2JFxoO6Rpzn+iBvUtZ3MZ/1RyktnJdHRyRPD1x2zSTZGvOC ENJStH29iAp6zA39L7qdWW5CTpso2CIyuYzB49ps4c9uw5Py0CqLocgx/vY82L639WPa Vh1wixx2w/KQ90gGW7UKa9wVfMgnqpNY8RKw1zE3Ue3Kf9HlM29xiKw4YWqmE+2v8J5S egjlUPRbnqQ2arMPZruQmUWH5m+i7J6KkT1CS8gFGuZpTW0n3Yga42zuoe48awJkCYe7 sjdrbf5KMVSPqGb47KT0L1//dg/dUmA27Irm/Wv2EttoWBIiwp0OdT6gA0BBx5rHLAfu 1FTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mSXrWZOvXmooCVyga1KeNd5zTeXdIAA7lyiNLAgfBgA=; b=QXC1TYia1ELoLDX1iefUVAJzudeAMUlQNckAoP9F8R40j5lc+LcIzrXMzIErNLMlSZ c6xsvv/gybwBi2aHMf/YvQgFo+qKcPQBAVnrHVeW2FwPkjSTF2jMqOIJj8rUdO+XUzGo MqwYFTnlpanousSKBujWs3KUraZ95aj+bsZRS/g/B44ljVLHyNlbQlimxdkvpm6Zj77a iuApTg4bly7Uo8f+1ZFyCXpQFYkhkR4sQo5ktfVGmJ2rHTvhKhBMHzQzysIMCnDE61tB ifLQIu968um29R9XJ3YVuTdiTSCSQSAhVKGeV0zbe7eDumNqeeFLK3ZbrPisCEnPF1UG BeaA==
X-Gm-Message-State: ALyK8tIFofYpAzdnz2yCj/YSIEv85qKZGdNeLLr26YS5qoehOlUhfXgoNBons18YCs5qKRI+WYbpXdgpXOXz9eo8
X-Received: by 10.157.37.242 with SMTP id q105mr5596388ota.29.1466330375992; Sun, 19 Jun 2016 02:59:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.27.139 with HTTP; Sun, 19 Jun 2016 02:59:35 -0700 (PDT)
In-Reply-To: 
References: <064201d1ada1$0b94dc20$22be9460$@augustcellars.com> <5740CA5D.9000900@isode.com> <000301d1b4a3$f6fdc470$e4f94d50$@augustcellars.com>   
From: Wei Chuang 
Date: Sun, 19 Jun 2016 02:59:35 -0700
Message-ID: 
To: Sean Leonard 
Content-Type: multipart/alternative; boundary=001a113cf5982f87e505359ea507
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 19 Jun 2016 09:59:39 -0000

--001a113cf5982f87e505359ea507
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On Sat, Jun 18, 2016 at 7:13 AM, Sean Leonard  wrote:

> On 6/17/2016 11:35 AM, Wei Chuang wrote:
>
>
>
> On Thu, Jun 16, 2016 at 6:31 AM, Sean Leonard 
> wrote:
>
>> A few additional points popped out at me:
>>
>> Currently, draft-melnikov-spasm-eai-addresses-01 does not restrict out
>> plain (ASCII-only) e-mail addresses. This means that ASCII-only e-mail
>> addresses can be "hidden" from implementations that don't support this new
>> eai method. I am not in favor of this. The text is not really clear about
>> whether non-internationalized email addresses are allowed in eaiName. It
>> should be clear in saying that eaiName is restricted to internationalized
>> email addresses, i.e., where there is at least one character beyond the
>> ASCII range in the local-part. Email addresses that are limited to ASCII in
>> the local-part MUST be encoded in rfc822Name only.
>>
>
> Handling coexistence of rfc822Name and eaiName is an interesting question
> and in an ideal world we could switch from one to the other to reduce the
> implementation cost.  Realistically we'll have to support both for awhile.
> I think your suggestion is good which is to support both but restrict usage
> and will likely reduce deployment confusion.  This consequence of this will
> likely mean keeping rfc822Name and eaiName as acceptable email address
> representations for the foreseeable future.
>
>
> Okay.
>
>
> Let me pose another suggestion I received which is to start a transition
> to eaiName- we could add a SHOULD recommendation that all future PKIX
> subject email addresses be represented as eaiName, with language stating
> the intent to transition to eaiName as the sole representation, along with
> a SHOULD NOT on future usage of rfc822Name.  Some future revision could
> change this to MUST/MUST-NOT.  What do you think of this approach?
>
>
> TL;DR: I don't believe that rfc822Name [1] can formally or practically be
> deprecated unless you work closely with ITU-T, and evaluate market impact.
>
> The way that GeneralName works is that there are certain "core" name types
> that are given an explicit "CONTEXT-SPECIFIC" tag class identifier, leading
> to a very compact representation. rfc822Name is [1], dNSName is [2], etc.
>
> For "non-core types", GeneralName works using the general model of type
> extension using TYPE-IDENTIFIER, namely, an OID and the open type defined
> by the OID. The otherName extended type is itself tagged with [0]. When
> otherName = eaiName gets an OID, that OID is going to bloat the
> GeneralName, for each and every name. (We are only talking about ~10 bytes,
> but ~10 bytes multiplied over possibly multiple e-mail addresses multiplied
> over billions of certificates...and other protocols in which it might be
> used...) Moreover, it's going to make validation and name-comparing logic
> more complicated. Consider that Section 4.2.1.10 of RFC 5280 says that both
> dNSName and rfc822Name SHOULD be supported for name constraints.
>
> If the long-term goal is to use one field exclusively, it makes a lot more
> engineering sense to change the definition of rfc822Name to UTF8String, or,
> to add a new eaiName [9] UTF8String. Both of those paths will have to be
> done with ITU-T coordination. I have raised this issue before and the
> consensus on this list was against those approaches. Just pointing it out.
> As long as GeneralName is formally controlled by ITU-T X.509, if you want
> to take a step beyond "supporting eaiName" and go to "mandate eaiName and
> deprecate rfc822Name", you have to do something in X.509 to deprecate it.
> At that point, you may as well do something in X.509 to replace rfc822Name
> with a name form the compact way.
>

Got it.  Sure I can add language to restrict eaiName to when needed to
support UTF-8 local parts only.


>
>
>
>
>> Can the ASN.1 reflect this with an appropriate string restriction?
>
>
>> The comparison algorithm is convoluted.
>
>
> Domain name represented in A-labels is what RFC5280 requires for its
> verification process (step 7.2).  The draft just simply states insuring it
> is represented as A-label in the certificate stored form to reduce risk of
> translation error by verifier implementation.
>
>
> Section 7.2 of RFC 5280 only applies to dNSName field; it does not apply
> to other fields.
>

Sorry I should have been more precise for purposes of discussion as I
skipped a step.  See section 7.5 "Internationalized Electronic Mail
Addresses" which then points back to 7.2.


   To accommodate email
   addresses with internationalized domain names using the current
   structure, conforming implementations MUST convert the addresses into
   an ASCII representation.

   Where the host-part (the Domain of the Mailbox) contains an
   internationalized name, the domain name MUST be converted from an IDN
   to the ASCII Compatible Encoding (ACE) format as specified in
Section 
   7.2 .

   Two email addresses are considered to match if:

      1)  the local-part of each name is an exact match, AND

      2)  the host-part of each name matches using a case-insensitive
          ASCII comparison.


The approach in the draft comes from this precedence and a desire to
eliminate the conversation at verification time.

To do what your requesting, I think we need to get context as to why
RFC5280 converts domains to A-labels instead of U-labels.  Its certainly
useful to explore if this change is reasonable, as the upside is a more
compact representation and typically a simpler comparison- just have to
make sure there isn't a significant negative impact though.  Hopefully some
of the RFC5280 authors can help clarify why the domain in ASCII format is
required for comparison?

thanks,
-Wei


> That also doesn't change the fact that it's convoluted. :)
>
>
>
>> There will be implementations that don't bother with the convoluted
>> algorithm, and running the convoluted algorithm over thousands or hundreds
>> of millions of certificates is going to have a meaningful impact on
>> performance. It's better to put the address in a form that is amenable to
>> octet-by-octet comparison. This argues in favor of requiring the domain
>> name to be in U-labels instead of A-labels, and to normalize case (to
>> lowercase) for characters in the ASCII range.
>
>
> A better place to ask for this change, is to update RFC5280 to mandate
> comparison as U-label domains.  This draft is just taking the position that
> there ought to be just one in certificate domain form which is going to be
> whatever the RFC5280 comparison form is.
>
>
> Section 7.2 of RFC 5280 limits itself to dNSName. It actually doesn't say
> anything about other name slots, including URI or rfc822Name. The reason
> why RFC 5280 says anything is because dNSName is limited to IA5String, but
> IDNs were "a real thing" back in 2008. EAI was not a real thing back then.
>
> If folks insist on case-sensitive comparison of the local-part and
> case-insensitive comparison of the domain part in the ASCII range, then
> maybe it makes more sense to define eaiName as:
> SEQUENCE {
>  localPart UTF8String,
>  domain IA5String }
>
> That way, an application can easily compare the localPart with memcmp
> (because it can contain NULLs), and the domain with stricmp. No hunting for
> quotations or "@" needed.
>
> The advantage of using U-labels (in conjunction with mandatory
> quote-or-no-quote rules) is that the eaiName can be represented in a single
> UTF8String, and can be compared in a single memcmp.
>
>
> Sean
>
>

--001a113cf5982f87e505359ea507
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit




On Sat, Jun 18, 2016 at 7:13 AM, Sean Leonard <dev+ietf@seantek.com> wrote:

  
    
  
  

    
On 6/17/2016 11:35 AM, Wei Chuang
      wrote:

    

    

      


        


          
On Thu, Jun 16, 2016 at 6:31 AM, Sean
            Leonard <dev+ietf@seantek.com>
            wrote:

            
A few
              additional points popped out at me:

              

              Currently, draft-melnikov-spasm-eai-addresses-01 does
              not restrict out plain (ASCII-only) e-mail addresses. This
              means that ASCII-only e-mail addresses can be "hidden"
              from implementations that don't support this new eai
              method. I am not in favor of this. The text is not really
              clear about whether non-internationalized email addresses
              are allowed in eaiName. It should be clear in saying that
              eaiName is restricted to internationalized email
              addresses, i.e., where there is at least one character
              beyond the ASCII range in the local-part. Email addresses
              that are limited to ASCII in the local-part MUST be
              encoded in rfc822Name only.

            

            


            

            
Handling coexistence of rfc822Name and eaiName is an
              interesting question and in an ideal world we could switch
              from one to the other to reduce the implementation cost. 
              Realistically we'll have to support both for awhile.  I
              think your suggestion
              is good which is to support both but restrict usage and will likely
              reduce deployment confusion.  This consequence of this
              will likely mean keeping rfc822Name and eaiName as
              acceptable email address representations for the
              foreseeable future.  

            

          

        

      

    

    

    Okay.

    

    

      

        

          

            


            

            
Let me pose another suggestion I received which is to
              start a transition to eaiName- we could add a SHOULD
              recommendation that all future PKIX subject email
              addresses be represented as eaiName, with language stating
              the intent to transition to eaiName as the sole
              representation, along with a SHOULD NOT on future usage of
              rfc822Name.  Some future revision could change this to
              MUST/MUST-NOT.  What do you think of this approach?

            

          

        

      

    

    

    TL;DR: I don't believe that rfc822Name [1] can formally or
    practically be deprecated unless you work closely with ITU-T, and
    evaluate market impact.

    

    The way that GeneralName works is that there are certain "core" name
    types that are given an explicit "CONTEXT-SPECIFIC" tag class
    identifier, leading to a very compact representation. rfc822Name is
    [1], dNSName is [2], etc.

    

    For "non-core types", GeneralName works using the general model of
    type extension using TYPE-IDENTIFIER, namely, an OID and the open
    type defined by the OID. The otherName extended type is itself
    tagged with [0]. When otherName = eaiName gets an OID, that OID is
    going to bloat the GeneralName, for each and every name. (We are
    only talking about ~10 bytes, but ~10 bytes multiplied over possibly
    multiple e-mail addresses multiplied over billions of
    certificates...and other protocols in which it might be used...)
    Moreover, it's going to make validation and name-comparing logic
    more complicated. Consider that Section 4.2.1.10 of RFC 5280 says
    that both dNSName and rfc822Name SHOULD be supported for name
    constraints.

    

    If the long-term goal is to use one field exclusively, it makes a
    lot more engineering sense to change the definition of rfc822Name to
    UTF8String, or, to add a new eaiName [9] UTF8String. Both of those
    paths will have to be done with ITU-T coordination. I have raised
    this issue before and the consensus on this list was against those
    approaches. Just pointing it out. As long as GeneralName is formally
    controlled by ITU-T X.509, if you want to take a step beyond
    "supporting eaiName" and go to "mandate eaiName and deprecate
    rfc822Name", you have to do something in X.509 to deprecate it. At
    that point, you may as well do something in X.509 to replace
    rfc822Name with a name form the compact way.

Got it.  Sure I can add language to restrict eaiName to when needed to support UTF-8 local parts only.
 


    

    

    

      

        

          

            

              

              Can the ASN.1 reflect this with an appropriate string
              restriction?

            

              

              The comparison algorithm is convoluted. 

            


            

            
Domain name represented in A-labels is what RFC5280
              requires for its verification process (step 7.2).  The
              draft just simply states insuring it is represented as
              A-label in the certificate stored form to reduce risk of
              translation error by verifier implementation.  

            

          

        

      

    

    

    Section 7.2 of RFC 5280 only applies to dNSName field; it does not
    apply to other fields.

Sorry I should have been more precise for purposes of discussion as I skipped a step.  See section 7.5 "Internationalized Electronic Mail Addresses" which then points back to 7.2.

   To accommodate email
   addresses with internationalized domain names using the current
   structure, conforming implementations MUST convert the addresses into
   an ASCII representation.

   Where the host-part (the Domain of the Mailbox) contains an
   internationalized name, the domain name MUST be converted from an IDN
   to the ASCII Compatible Encoding (ACE) format as specified in Section
   7.2.

   Two email addresses are considered to match if:

      1)  the local-part of each name is an exact match, AND

      2)  the host-part of each name matches using a case-insensitive
          ASCII comparison.


The approach in the draft comes from this precedence and a desire to eliminate the conversation at verification time.  

To do what your requesting, I think we need to get context as to why RFC5280 converts domains to A-labels instead of U-labels.  Its certainly useful to explore if this change is reasonable, as the upside is a more compact representation and typically a simpler comparison- just have to make sure there isn't a significant negative impact though.  Hopefully some of the RFC5280 authors can help clarify why the domain in ASCII format is required for comparison?

thanks,
-Wei


    

    That also doesn't change the fact that it's convoluted. :)

    

    

      

        

          

            
 

            
There
              will be implementations that don't bother with the
              convoluted algorithm, and running the convoluted algorithm
              over thousands or hundreds of millions of certificates is
              going to have a meaningful impact on performance. It's
              better to put the address in a form that is amenable to
              octet-by-octet comparison. This argues in favor of
              requiring the domain name to be in U-labels instead of
              A-labels, and to normalize case (to lowercase) for
              characters in the ASCII range.

            


            

            
A better place to ask for this change, is to update
              RFC5280 to mandate comparison as U-label domains.  This
              draft is just taking the position that there ought to be
              just one in certificate domain form which is going to be
              whatever the RFC5280 comparison form is.

          

        

      

    

    

    Section 7.2 of RFC 5280 limits itself to dNSName. It actually
    doesn't say anything about other name slots, including URI or
    rfc822Name. The reason why RFC 5280 says anything is because dNSName
    is limited to IA5String, but IDNs were "a real thing" back in 2008.
    EAI was not a real thing back then.

    

    If folks insist on case-sensitive comparison of the local-part and
    case-insensitive comparison of the domain part in the ASCII range,
    then maybe it makes more sense to define eaiName as:

    SEQUENCE {

     localPart UTF8String,

     domain IA5String }

    

    That way, an application can easily compare the localPart with
    memcmp (because it can contain NULLs), and the domain with stricmp.
    No hunting for quotations or "@" needed.

    

    The advantage of using U-labels (in conjunction with mandatory
    quote-or-no-quote rules) is that the eaiName can be represented in a
    single UTF8String, and can be compared in a single memcmp.

    

    

    Sean

    

  






--001a113cf5982f87e505359ea507--


From nobody Sun Jun 19 11:17:19 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC1E12D688 for ; Sun, 19 Jun 2016 11:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 4XodQ4kpucbP for ; Sun, 19 Jun 2016 11:17:15 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E70512D686 for ; Sun, 19 Jun 2016 11:17:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D4565300431 for ; Sun, 19 Jun 2016 14:17:12 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8hPHM0QW5RyB for ; Sun, 19 Jun 2016 14:17:11 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 85A6C300263; Sun, 19 Jun 2016 14:17:11 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <6cfb577bce984651830ab5cf526663f3@usma1ex-dag1mb1.msg.corp.akamai.com>
Date: Sun, 19 Jun 2016 14:16:41 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <2D4F0589-0B3B-4ADD-9547-EE770D4C2F09@vigilsec.com>
References: <57519BBB.8050604@cs.tcd.ie> <7255B25B-9278-461C-9480-D4326F63D37B@vigilsec.com>  <438E0183-E149-4580-B6C2-8D120E070E4C@vigilsec.com> <6cfb577bce984651830ab5cf526663f3@usma1ex-dag1mb1.msg.corp.akamai.com>
To: "Salz, Rich" 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] BoF in Berlin or what?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 19 Jun 2016 18:17:17 -0000

I agree with Jim and Wei, we could easily add one agenda item for that =
topic.

Russ


On Jun 17, 2016, at 3:18 PM, Salz, Rich  wrote:

> If CURDLE doesn't meet, could we handle those issues here?
>=20
>>> I would really like to discuss how the ECDH and EdDSA algorithms are=20=

>>> being identified in PKIX, in part because I want it to match what is=20=

>>> being done in other groups.  So I would appreciate a meeting.
>>=20
>> This needs to get sorted out.  It has an impact on the CMS-related =
drafts too.
>> That said, we might be able to sort it out on the mail list before =
Berlin.
>=20
> -- =20
> Senior Architect, Akamai Technologies
> IM: richsalz@jabber.at Twitter: RichSalz
>=20
>=20
>> -----Original Message-----
>> From: Russ Housley [mailto:housley@vigilsec.com]
>> Sent: Friday, June 17, 2016 3:16 PM
>> To: spasm@ietf.org
>> Subject: Re: [Spasm] BoF in Berlin or what?
>>=20
>> Seing that SPASM has a one hour slot on the preliminary schedule and =
that
>> document authors have agreed to do status and open issue =
presentations, I
>> propose the following agenda=85
>>=20
>> 	SPASM WG Agenda
>>=20
>> 	0)  Minutes, Jabber Scribe, Bluesheets
>> 	1)  Agenda Bash
>> 	2)  Status and open issues for =
draft-melnikov-spasm-eai-addresses
>> 	3)  Status and open issues for draft-schaad-rfc5751-bis
>> 	4)  WG document adoption
>> 	5)  Wrap Up
>>=20
>> The 4th item will be dropped if the IESG has not chartered the SPASM =
WG in
>> time.
>>=20
>> Thoughts?
>>=20
>> Russ
>>=20
>> _______________________________________________
>> Spasm mailing list
>> Spasm@ietf.org
>> https://www.ietf.org/mailman/listinfo/spasm


From nobody Mon Jun 20 09:53:23 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B5E12D7F1 for ; Mon, 20 Jun 2016 09:53:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 kRTPMVMeN9Du for ; Mon, 20 Jun 2016 09:53:17 -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 1408612D5D1 for ; Mon, 20 Jun 2016 09:53:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D1A6D30048C for ; Mon, 20 Jun 2016 12:53:14 -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 rTcdFtAXQpvD for ; Mon, 20 Jun 2016 12:53:13 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id C13CA300256; Mon, 20 Jun 2016 12:53:13 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <270ecf29-302a-c038-ab87-207d0dbe7ffc@seantek.com>
Date: Mon, 20 Jun 2016 12:53:32 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <13DB0F93-B0C4-4C81-9E20-C1A865552D39@vigilsec.com>
References: <270ecf29-302a-c038-ab87-207d0dbe7ffc@seantek.com>
To: Sean Leonard 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Can we address the emailAddress DN issue
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 20 Jun 2016 16:53:21 -0000

Sean:

The emailAddress attribute is defined n PKCS#9 (which was republished as =
RFC 2985).  I do not see how we could redefine this attribute.  A new =
attribute would need to be defined to carry an internationalized email =
address, and then the various procedures for name constraints would also =
need to be specified.

Russ


On Jun 18, 2016, at 10:29 AM, Sean Leonard  wrote:

> Since we are spending all this time on eai addresses in GeneralName, =
can we address the emailAddress DN issue, and the mail (or other =
identifier) LDAP issue?
>=20
> Many LDAP directories store e-mail addresses in the mail =
0.9.2342.19200300.100.1.3 attribute (derived from COSINE).
>=20
> RFC 5280 (and S/MIME) say specific things about handling the =
emailAddress 1.2.840.113549.1.9.1 attribute (derived from PKCS #9).
>=20
> I think we ought to deal with it/them.
>=20
> Even if you are of the view that emailAddress is a legacy attribute =
that ought not be used for "new applications", there's no denying that =
CAs still issue certificates with that attribute. Furthermore, the mail =
attribute is actively used in LDAP, including (for example) as an LDAP =
search query term to look up certificates.
>=20
> Ideally we could unify the attributes so that both LDAP and =
(PKIX-related) DN use the same attribute.
>=20
> Sean


From nobody Mon Jun 20 10:00:23 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824D212D7EE for ; Mon, 20 Jun 2016 10:00:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 JKqccb9Vhs-x for ; Mon, 20 Jun 2016 10:00:20 -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 7C90812D57B for ; Mon, 20 Jun 2016 10:00:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 72C9730048C for ; Mon, 20 Jun 2016 13:00:18 -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 KthcRjNBMG2O for ; Mon, 20 Jun 2016 13:00:17 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 85EB1300256; Mon, 20 Jun 2016 13:00:17 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: 
Date: Mon, 20 Jun 2016 13:00:36 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <064201d1ada1$0b94dc20$22be9460$@augustcellars.com> <5740CA5D.9000900@isode.com> <000301d1b4a3$f6fdc470$e4f94d50$@augustcellars.com>   
To: Sean Leonard 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 20 Jun 2016 17:00:21 -0000

> Section 7.2 of RFC 5280 limits itself to dNSName. It actually doesn't =
say anything about other name slots, including URI or rfc822Name. The =
reason why RFC 5280 says anything is because dNSName is limited to =
IA5String, but IDNs were "a real thing" back in 2008. EAI was not a real =
thing back then.
>=20
> If folks insist on case-sensitive comparison of the local-part and =
case-insensitive comparison of the domain part in the ASCII range, then =
maybe it makes more sense to define eaiName as:
> SEQUENCE {
>  localPart UTF8String,
>  domain IA5String }

I think we need to consider internationalized domain names in this work.

Russ



From nobody Mon Jun 20 10:09:24 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9624212D587 for ; Mon, 20 Jun 2016 10:09:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 RjT8U3D91LDA for ; Mon, 20 Jun 2016 10:09:22 -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 5485C12D556 for ; Mon, 20 Jun 2016 10:09:22 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 16C5C509B6; Mon, 20 Jun 2016 13:09:20 -0400 (EDT)
To: Russ Housley 
References: <270ecf29-302a-c038-ab87-207d0dbe7ffc@seantek.com> <13DB0F93-B0C4-4C81-9E20-C1A865552D39@vigilsec.com>
From: Sean Leonard 
Message-ID: 
Date: Mon, 20 Jun 2016 10:09:26 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <13DB0F93-B0C4-4C81-9E20-C1A865552D39@vigilsec.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Can we address the emailAddress DN issue
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 20 Jun 2016 17:09:23 -0000

My jab is that we ought to work on a new attribute,=20
"internationalizedEmailAddress" (or simply "eai"), that is used by both=20
security applications (i.e., PKIX) and directory applications (i.e., LDAP=
).

It is a thorn in our collective side that mail and emailAddress are=20
defined as IA5String and caseIgnoreMatch /pkcs9CaseIgnoreMatch. RFC 5280 =

even has a warning about that issue (based on PKCS #9 aka RFC 2985). I=20
am not proposing that we redefine the emailAddress or mail attributes.=20
However, if we do work on an eai attribute, the overlap will have to be=20
addressed.

(May I suggest that an eai attribute be case sensitive, and that=20
local-part email addresses that are known to be case sensitive, or are=20
unknown whether they are case sensitive or not, ought to be put in eai=20
attribute and NOT in emailAddress/mail attributes.)

Sean

On 6/20/2016 9:53 AM, Russ Housley wrote:
> Sean:
>
> The emailAddress attribute is defined n PKCS#9 (which was republished a=
s RFC 2985).  I do not see how we could redefine this attribute.  A new a=
ttribute would need to be defined to carry an internationalized email add=
ress, and then the various procedures for name constraints would also nee=
d to be specified.
>
> Russ
>
>
> On Jun 18, 2016, at 10:29 AM, Sean Leonard  wrote=
:
>
>> Since we are spending all this time on eai addresses in GeneralName, c=
an we address the emailAddress DN issue, and the mail (or other identifie=
r) LDAP issue?
>>
>> Many LDAP directories store e-mail addresses in the mail 0.9.2342.1920=
0300.100.1.3 attribute (derived from COSINE).
>>
>> RFC 5280 (and S/MIME) say specific things about handling the emailAddr=
ess 1.2.840.113549.1.9.1 attribute (derived from PKCS #9).
>>
>> I think we ought to deal with it/them.
>>
>> Even if you are of the view that emailAddress is a legacy attribute th=
at ought not be used for "new applications", there's no denying that CAs =
still issue certificates with that attribute. Furthermore, the mail attri=
bute is actively used in LDAP, including (for example) as an LDAP search =
query term to look up certificates.
>>
>> Ideally we could unify the attributes so that both LDAP and (PKIX-rela=
ted) DN use the same attribute.
>>
>> Sean




From nobody Mon Jun 20 10:09:47 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4A512D587 for ; Mon, 20 Jun 2016 10:09:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 1oRsR_tB6Iwc for ; Mon, 20 Jun 2016 10:09:45 -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 B2DF912D556 for ; Mon, 20 Jun 2016 10:09:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A6327300426 for ; Mon, 20 Jun 2016 13:09:43 -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 r5pbe5uz6OLk for ; Mon, 20 Jun 2016 13:09:42 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 66D04300263; Mon, 20 Jun 2016 13:09:42 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: 
Date: Mon, 20 Jun 2016 13:10:01 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <064201d1ada1$0b94dc20$22be9460$@augustcellars.com> <5740CA5D.9000900@isode.com> <000301d1b4a3$f6fdc470$e4f94d50$@augustcellars.com>   
To: Sean Leonard 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 20 Jun 2016 17:09:47 -0000

> Section 7.2 of RFC 5280 limits itself to dNSName. It actually doesn't =
say anything about other name slots, including URI or rfc822Name. The =
reason why RFC 5280 says anything is because dNSName is limited to =
IA5String, but IDNs were "a real thing" back in 2008. EAI was not a real =
thing back then.
>=20
> If folks insist on case-sensitive comparison of the local-part and =
case-insensitive comparison of the domain part in the ASCII range, then =
maybe it makes more sense to define eaiName as:
> SEQUENCE {
> localPart UTF8String,
> domain IA5String }

Sorry, I hit send before I intend.  Trying again=85

I think we need to consider internationalized domain names in this work. =
 Section 7.2 of RFC 5280 covers this topic.  Notice that it requires =
conversion to Unicode for display, but they are always carried in their =
ASCII form.

The approach that Sean recommends allows the domain name to be handled =
as already specified in RFC 5280, and this allows the group to focus on =
the left hand side of the @ sign.

I observe that this is not the for that the eaiName will appear in email =
messages.  We need to be able to compare them in the certificate and the =
email headers.  So, I=92d like to hear from implementors what is the =
best form for their code.

Russ



From nobody Mon Jun 20 11:22:40 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED9F12D90E for ; Mon, 20 Jun 2016 11:22:37 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 76aEtrFVc3fZ for ; Mon, 20 Jun 2016 11:22:36 -0700 (PDT)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EF6312D629 for ; Mon, 20 Jun 2016 11:22:35 -0700 (PDT)
Received: from hebrews (augustcellars.com [50.45.239.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 70CEA38EFD; Mon, 20 Jun 2016 11:22:35 -0700 (PDT)
From: "Jim Schaad" 
To: "'Russ Housley'" , "'Sean Leonard'" 
References: <270ecf29-302a-c038-ab87-207d0dbe7ffc@seantek.com> <13DB0F93-B0C4-4C81-9E20-C1A865552D39@vigilsec.com>
In-Reply-To: <13DB0F93-B0C4-4C81-9E20-C1A865552D39@vigilsec.com>
Date: Mon, 20 Jun 2016 11:22:35 -0700
Message-ID: <022a01d1cb20$b7fa4800$27eed800$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHWS4NEMVmYwZ7VPuQxRaCDfQZt4gLgo0axn9Kk4FA=
Content-Language: en-us
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Can we address the emailAddress DN issue
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 20 Jun 2016 18:22:38 -0000

I would be against defining a new attribute unless there was someplace other
than a certificate where this attribute was going to be used.  Certificates
are defined to use subject other names for this type of entry, putting into
the subject field means that there are two places that need to be checked.
This does not seem to be an advantage.

Jim


> -----Original Message-----
> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley
> Sent: Monday, June 20, 2016 9:54 AM
> To: Sean Leonard 
> Cc: spasm@ietf.org
> Subject: Re: [Spasm] Can we address the emailAddress DN issue
> 
> Sean:
> 
> The emailAddress attribute is defined n PKCS#9 (which was republished as
RFC
> 2985).  I do not see how we could redefine this attribute.  A new
attribute would
> need to be defined to carry an internationalized email address, and then
the
> various procedures for name constraints would also need to be specified.
> 
> Russ
> 
> 
> On Jun 18, 2016, at 10:29 AM, Sean Leonard  wrote:
> 
> > Since we are spending all this time on eai addresses in GeneralName, can
we
> address the emailAddress DN issue, and the mail (or other identifier) LDAP
issue?
> >
> > Many LDAP directories store e-mail addresses in the mail
> 0.9.2342.19200300.100.1.3 attribute (derived from COSINE).
> >
> > RFC 5280 (and S/MIME) say specific things about handling the
emailAddress
> 1.2.840.113549.1.9.1 attribute (derived from PKCS #9).
> >
> > I think we ought to deal with it/them.
> >
> > Even if you are of the view that emailAddress is a legacy attribute that
ought
> not be used for "new applications", there's no denying that CAs still
issue
> certificates with that attribute. Furthermore, the mail attribute is
actively used in
> LDAP, including (for example) as an LDAP search query term to look up
> certificates.
> >
> > Ideally we could unify the attributes so that both LDAP and
(PKIX-related) DN
> use the same attribute.
> >
> > Sean
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


From nobody Mon Jun 20 17:50:37 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E15F12D7EC for ; Mon, 20 Jun 2016 17:50:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 IiqYTQZXTp3N for ; Mon, 20 Jun 2016 17:50:34 -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 659A012D764 for ; Mon, 20 Jun 2016 17:50:34 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 213EC509B5; Mon, 20 Jun 2016 20:50:32 -0400 (EDT)
To: Jim Schaad , 'Russ Housley' 
References: <270ecf29-302a-c038-ab87-207d0dbe7ffc@seantek.com> <13DB0F93-B0C4-4C81-9E20-C1A865552D39@vigilsec.com> <022a01d1cb20$b7fa4800$27eed800$@augustcellars.com>
From: Sean Leonard 
Message-ID: <81365f13-5854-2ba4-4e51-0f8f02965830@seantek.com>
Date: Mon, 20 Jun 2016 17:50:38 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <022a01d1cb20$b7fa4800$27eed800$@augustcellars.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Can we address the emailAddress DN issue
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 21 Jun 2016 00:50:36 -0000

Again, the mail attribute is used extensively by many LDAP=20
implementations, and by certificate-fetching systems when looking up=20
certificates via LDAP.

I am not aware how prevalent it is to store the emailAddress attribute=20
in LDAP. We need an LDAP expert to say. However, I would venture a guess =

that it's more than 0.

I agree that it would be a good idea to discourage or prohibit putting=20
e-mail addresses of any kind in the Subject DN. Perhaps the eai draft=20
should say something about that, i.e., don't attempt to shoehorn=20
emailAddress in when a SAN is an eaiName (because it's not syntactically =

compatible).

However, there are CA issuers who issue free e-mail certificates, where=20
the only thing they really check is the e-mail address. What therefore=20
should those issuers put in the subject field, when they can't put an=20
e-mail address properly identified as an emailAddress?

They could put the e-mail address in the Common Name, but that runs the=20
same risk as what happened with ye olde SSLv3- certificates, where=20
people checked the CN for domain name content. (Some CAs to my knowledge =

put e-mail address content in both the E and CN fields in the subject DN.=
)

It seems that since E can't be used and you don't want to put a=20
different field in, the draft should say something about the=20
consequences of either a blank DN (namely the UI and identification=20
issues), or that it's necessary to put some random junk such as=20
SERIALNUMBER, UUID, DESCRIPTION, etc. in the subject field anyway.

Sean

On 6/20/2016 11:22 AM, Jim Schaad wrote:
> I would be against defining a new attribute unless there was someplace =
other
> than a certificate where this attribute was going to be used.  Certific=
ates
> are defined to use subject other names for this type of entry, putting =
into
> the subject field means that there are two places that need to be check=
ed.
> This does not seem to be an advantage.
>
> Jim
>
>
>> -----Original Message-----
>> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley
>> Sent: Monday, June 20, 2016 9:54 AM
>> To: Sean Leonard 
>> Cc: spasm@ietf.org
>> Subject: Re: [Spasm] Can we address the emailAddress DN issue
>>
>> Sean:
>>
>> The emailAddress attribute is defined n PKCS#9 (which was republished =
as
> RFC
>> 2985).  I do not see how we could redefine this attribute.  A new
> attribute would
>> need to be defined to carry an internationalized email address, and th=
en
> the
>> various procedures for name constraints would also need to be specifie=
d.
>>
>> Russ
>>
>>
>> On Jun 18, 2016, at 10:29 AM, Sean Leonard  wrot=
e:
>>
>>> Since we are spending all this time on eai addresses in GeneralName, =
can
> we
>> address the emailAddress DN issue, and the mail (or other identifier) =
LDAP
> issue?
>>> Many LDAP directories store e-mail addresses in the mail
>> 0.9.2342.19200300.100.1.3 attribute (derived from COSINE).
>>> RFC 5280 (and S/MIME) say specific things about handling the
> emailAddress
>> 1.2.840.113549.1.9.1 attribute (derived from PKCS #9).
>>> I think we ought to deal with it/them.
>>>
>>> Even if you are of the view that emailAddress is a legacy attribute t=
hat
> ought
>> not be used for "new applications", there's no denying that CAs still
> issue
>> certificates with that attribute. Furthermore, the mail attribute is
> actively used in
>> LDAP, including (for example) as an LDAP search query term to look up
>> certificates.
>>> Ideally we could unify the attributes so that both LDAP and
> (PKIX-related) DN
>> use the same attribute.
>>> Sean
>> _______________________________________________
>> Spasm mailing list
>> Spasm@ietf.org
>> https://www.ietf.org/mailman/listinfo/spasm
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm




From nobody Mon Jun 20 19:44:40 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E958912D8A1 for ; Mon, 20 Jun 2016 19:44:38 -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 eCnx9VXGjM6q for ; Mon, 20 Jun 2016 19:44:36 -0700 (PDT)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1E312D888 for ; Mon, 20 Jun 2016 19:44:36 -0700 (PDT)
Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id DE5EB2C9F4; Mon, 20 Jun 2016 19:44:35 -0700 (PDT)
From: "Jim Schaad" 
To: "'Sean Leonard'" , "'Russ Housley'" 
References: <270ecf29-302a-c038-ab87-207d0dbe7ffc@seantek.com> <13DB0F93-B0C4-4C81-9E20-C1A865552D39@vigilsec.com> <022a01d1cb20$b7fa4800$27eed800$@augustcellars.com> <81365f13-5854-2ba4-4e51-0f8f02965830@seantek.com>
In-Reply-To: <81365f13-5854-2ba4-4e51-0f8f02965830@seantek.com>
Date: Mon, 20 Jun 2016 19:44:35 -0700
Message-ID: <02c901d1cb66$d9174a60$8b45df20$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHWS4NEMVmYwZ7VPuQxRaCDfQZt4gLgo0axAuKNawcB7s4o0p+spT3w
Content-Language: en-us
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Can we address the emailAddress DN issue
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 21 Jun 2016 02:44:39 -0000

> -----Original Message-----
> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Sean Leonard
> Sent: Monday, June 20, 2016 5:51 PM
> To: Jim Schaad ; 'Russ Housley'
> 
> Cc: spasm@ietf.org
> Subject: Re: [Spasm] Can we address the emailAddress DN issue
> 
> Again, the mail attribute is used extensively by many LDAP
implementations, and
> by certificate-fetching systems when looking up certificates via LDAP.
> 
> I am not aware how prevalent it is to store the emailAddress attribute in
LDAP.
> We need an LDAP expert to say. However, I would venture a guess that it's
more
> than 0.
> 
> I agree that it would be a good idea to discourage or prohibit putting
e-mail
> addresses of any kind in the Subject DN. Perhaps the eai draft should say
> something about that, i.e., don't attempt to shoehorn emailAddress in when
a
> SAN is an eaiName (because it's not syntactically compatible).
> 
> However, there are CA issuers who issue free e-mail certificates, where
the only
> thing they really check is the e-mail address. What therefore should those
> issuers put in the subject field, when they can't put an e-mail address
properly
> identified as an emailAddress?

You do not put anything in the subject field.  It is an empty sequence.  You
put the name in the SubjectAltName extension and mark it critical.  The only
case that this would be a problem for is if you had a CA which has an email
name as it's only subject name.   However, this is a corner case that I
would be happy to let die.

RFC 5280 says that you should not be using the emailAddress field in the
subject anyway.  This is deprecated behavior.

Jim

> 
> They could put the e-mail address in the Common Name, but that runs the
same
> risk as what happened with ye olde SSLv3- certificates, where people
checked
> the CN for domain name content. (Some CAs to my knowledge put e-mail
> address content in both the E and CN fields in the subject DN.)
> 
> It seems that since E can't be used and you don't want to put a different
field in,
> the draft should say something about the consequences of either a blank DN
> (namely the UI and identification issues), or that it's necessary to put
some
> random junk such as SERIALNUMBER, UUID, DESCRIPTION, etc. in the subject
> field anyway.
> 
> Sean
> 
> On 6/20/2016 11:22 AM, Jim Schaad wrote:
> > I would be against defining a new attribute unless there was someplace
> > other than a certificate where this attribute was going to be used.
> > Certificates are defined to use subject other names for this type of
> > entry, putting into the subject field means that there are two places
that need
> to be checked.
> > This does not seem to be an advantage.
> >
> > Jim
> >
> >
> >> -----Original Message-----
> >> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley
> >> Sent: Monday, June 20, 2016 9:54 AM
> >> To: Sean Leonard 
> >> Cc: spasm@ietf.org
> >> Subject: Re: [Spasm] Can we address the emailAddress DN issue
> >>
> >> Sean:
> >>
> >> The emailAddress attribute is defined n PKCS#9 (which was republished
> >> as
> > RFC
> >> 2985).  I do not see how we could redefine this attribute.  A new
> > attribute would
> >> need to be defined to carry an internationalized email address, and
> >> then
> > the
> >> various procedures for name constraints would also need to be
specified.
> >>
> >> Russ
> >>
> >>
> >> On Jun 18, 2016, at 10:29 AM, Sean Leonard 
> wrote:
> >>
> >>> Since we are spending all this time on eai addresses in GeneralName,
> >>> can
> > we
> >> address the emailAddress DN issue, and the mail (or other identifier)
> >> LDAP
> > issue?
> >>> Many LDAP directories store e-mail addresses in the mail
> >> 0.9.2342.19200300.100.1.3 attribute (derived from COSINE).
> >>> RFC 5280 (and S/MIME) say specific things about handling the
> > emailAddress
> >> 1.2.840.113549.1.9.1 attribute (derived from PKCS #9).
> >>> I think we ought to deal with it/them.
> >>>
> >>> Even if you are of the view that emailAddress is a legacy attribute
> >>> that
> > ought
> >> not be used for "new applications", there's no denying that CAs still
> > issue
> >> certificates with that attribute. Furthermore, the mail attribute is
> > actively used in
> >> LDAP, including (for example) as an LDAP search query term to look up
> >> certificates.
> >>> Ideally we could unify the attributes so that both LDAP and
> > (PKIX-related) DN
> >> use the same attribute.
> >>> Sean
> >> _______________________________________________
> >> Spasm mailing list
> >> Spasm@ietf.org
> >> https://www.ietf.org/mailman/listinfo/spasm
> > _______________________________________________
> > Spasm mailing list
> > Spasm@ietf.org
> > https://www.ietf.org/mailman/listinfo/spasm
> 
> 
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


From nobody Wed Jun 22 07:27:33 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B4512D678 for ; Wed, 22 Jun 2016 07:27:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 0KKg2ZEZwMM0 for ; Wed, 22 Jun 2016 07:27:30 -0700 (PDT)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 768B712D5CF for ; Wed, 22 Jun 2016 07:26:14 -0700 (PDT)
Received: by mail-oi0-x235.google.com with SMTP id s66so24328082oif.1 for ; Wed, 22 Jun 2016 07:26:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4XcjjKdOsT5K922+du//VAPxnUc23O14wtJ2yemcON8=; b=Ls2YxkKp1ILLMry3NEcDRfoW6P170Bf7yytau3W0xqbNH9hWlpQPTmc3naXZjR6ezB KwWf24I0sJCNCQ4Q0vqIUF6wxIjFtZCT91lfHB8ywelQ7NzqnFgi23sTvT9t8dWOOCt4 hrudk674PXpMVdId161B4dw92VNWfaG6NbQhqYo7TnKa/HTQTsEZZhVyaHJMcaqtjIhv IAUzA46DWxdsLima8FJCzqdrUQA4S2Y0OrKY8cphQqS5yMokrUUsUWfY/Ovvmh2oc/Rq 2CRQCA5WHQU9lTVfiMsqa5ElDV1mE7hml+V6l7/ITy0pgQUCUXcfPxBscodq8Siw1d46 6jZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4XcjjKdOsT5K922+du//VAPxnUc23O14wtJ2yemcON8=; b=Kao0JetcyvcTQDe5toNM6I9HcMGh91e8YzdJfxbVKTkw1vWTRN/40oFGsvWU9KyoNP 5fwjP5o6W8LXHz17qjQ0QgHHfPXAiK7fOnkYvyG9pKPbJ1iOyMmCeEKEEgkRhkG5UMfB g+dMssmLRyzkEgI9SGnBKZk/33orJiEmLajXnmjnWZF0/87QxraByul8GoKlx2MqypOU 2VTCKw1qvKsgOvBWRrno62TSIDwCWHAS/edfMO+KWuf4Ylz+yxyu5165BcPj/Fa/0SUM CNGHh0TqioCDv2zUdm9ra5Enwv/tdNmYMzHMY4lk3WeUn9lGc/kGgtgjER0sJr2xtOok hJfA==
X-Gm-Message-State: ALyK8tKdyY3KpK6XN7xJfJyu8uFN8vcJLgIA6LyW174u/hq6s8NztvOE1BBeq/OPEMoUiYa3Kpgc22KzRZk/zJWT
X-Received: by 10.202.72.208 with SMTP id v199mr1787322oia.128.1466605573244;  Wed, 22 Jun 2016 07:26:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.27.139 with HTTP; Wed, 22 Jun 2016 07:26:12 -0700 (PDT)
In-Reply-To: 
References: <064201d1ada1$0b94dc20$22be9460$@augustcellars.com> <5740CA5D.9000900@isode.com> <000301d1b4a3$f6fdc470$e4f94d50$@augustcellars.com>    
From: Wei Chuang 
Date: Wed, 22 Jun 2016 07:26:12 -0700
Message-ID: 
To: Russ Housley 
Content-Type: multipart/alternative; boundary=001a1134fcfa3877420535deb897
Archived-At: 
Cc: spasm@ietf.org, Sean Leonard 
Subject: Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 22 Jun 2016 14:27:32 -0000

--001a1134fcfa3877420535deb897
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On Mon, Jun 20, 2016 at 10:10 AM, Russ Housley  wrote:

>
> > Section 7.2 of RFC 5280 limits itself to dNSName. It actually doesn't
> say anything about other name slots, including URI or rfc822Name. The
> reason why RFC 5280 says anything is because dNSName is limited to
> IA5String, but IDNs were "a real thing" back in 2008. EAI was not a real
> thing back then.
> >
> > If folks insist on case-sensitive comparison of the local-part and
> case-insensitive comparison of the domain part in the ASCII range, then
> maybe it makes more sense to define eaiName as:
> > SEQUENCE {
> > localPart UTF8String,
> > domain IA5String }
>
> Sorry, I hit send before I intend.  Trying again…
>
> I think we need to consider internationalized domain names in this work.
> Section 7.2 of RFC 5280 covers this topic.  Notice that it requires
> conversion to Unicode for display, but they are always carried in their
> ASCII form.
>
> The approach that Sean recommends allows the domain name to be handled as
> already specified in RFC 5280, and this allows the group to focus on the
> left hand side of the @ sign.
>
> I observe that this is not the for that the eaiName will appear in email
> messages.  We need to be able to compare them in the certificate and the
> email headers.  So, I’d like to hear from implementors what is the best
> form for their code.
>

I checked with the Gmail delivery folks, and while the delivery system both
supports receiving A and U label domains and can sends both forms depending
on circumstances, they would prefer future standardization around U-labels
domain in the certificate as that's where the perceive e-mail formatting is
going.

I can rewrite the draft to cover this, but want to make sure the folks are
okay with this.  Also if this is the case, then presumably eaiName should
remain as a UTF8String i.e. not need the sequence.  But I also wanted to
check what folks thought too.

-Wei


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

--001a1134fcfa3877420535deb897
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit




On Mon, Jun 20, 2016 at 10:10 AM, Russ Housley <housley@vigilsec.com> wrote:


> Section 7.2 of RFC 5280 limits itself to dNSName. It actually doesn't say anything about other name slots, including URI or rfc822Name. The reason why RFC 5280 says anything is because dNSName is limited to IA5String, but IDNs were "a real thing" back in 2008. EAI was not a real thing back then.

>

> If folks insist on case-sensitive comparison of the local-part and case-insensitive comparison of the domain part in the ASCII range, then maybe it makes more sense to define eaiName as:

> SEQUENCE {

> localPart UTF8String,

> domain IA5String }



Sorry, I hit send before I intend.  Trying again…



I think we need to consider internationalized domain names in this work.  Section 7.2 of RFC 5280 covers this topic.  Notice that it requires conversion to Unicode for display, but they are always carried in their ASCII form.



The approach that Sean recommends allows the domain name to be handled as already specified in RFC 5280, and this allows the group to focus on the left hand side of the @ sign.



I observe that this is not the for that the eaiName will appear in email messages.  We need to be able to compare them in the certificate and the email headers.  So, I’d like to hear from implementors what is the best form for their code.

I checked with the Gmail delivery folks, and while the delivery system both supports receiving A and U label domains and can sends both forms depending on circumstances, they would prefer future standardization around U-labels domain in the certificate as that's where the perceive e-mail formatting is going.  

I can rewrite the draft to cover this, but want to make sure the folks are okay with this.  Also if this is the case, then presumably eaiName should remain as a UTF8String i.e. not need the sequence.  But I also wanted to check what folks thought too.

-Wei 




Russ






_______________________________________________

Spasm mailing list

Spasm@ietf.org

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





--001a1134fcfa3877420535deb897--


From nobody Wed Jun 22 07:36:57 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2765512D590 for ; Wed, 22 Jun 2016 07:36:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level: 
X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBm7iUriYtEG for ; Wed, 22 Jun 2016 07:36:52 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8BB12D5C3 for ; Wed, 22 Jun 2016 07:33:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 762DBBE5C for ; Wed, 22 Jun 2016 15:33:49 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kK8THQI2X_2G for ; Wed, 22 Jun 2016 15:33:49 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 13C42BE38 for ; Wed, 22 Jun 2016 15:33:45 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1466606025; bh=ZRb3SdLq814sajgK/CK6H5FCODQq/GRCZ0aGVmiVAR8=; h=Subject:References:To:From:Date:In-Reply-To:From; b=KiaeNeLn3LZisZXpLg4pSsHWBWFVdMsRreCQO+ygYEXNljl0WtGolJ/vfkKn83ePi w/2HIIlxaECRsiMD6Mfters79NeQa3qly/kQe6GPGUufBUVXKdcFgBk7mp2Fno+1D2 ixkjhr97ycstEMYhvBv2hWcKAbifgcCL9rzPbc7s=
References: <20160617163337.9633.3485.idtracker@ietfa.amsl.com>
To: spasm@ietf.org
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <576AA1C8.1070604@cs.tcd.ie>
Date: Wed, 22 Jun 2016 15:33:44 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <20160617163337.9633.3485.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090709070001050402020100"
Archived-At: 
Subject: Re: [Spasm] WG Review: Some PKIX and SMIME (spasm)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 22 Jun 2016 14:36:55 -0000

This is a cryptographically signed message in MIME format.

--------------ms090709070001050402020100
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Two things:

1. The IETF96 slot for this may be moving. I'll send mail when/if
that happens but please be aware of it as you plan travel. (The
draft agenda remains a draft agenda until it's a final agenda:-)

2. We got a comment that the WG name might be considered undesirable.
I don't want to debate that but since it's a "don't care" we'll
likely change the WG name. Feel free to suggest other names here in
the next day or two and Kathleen and I will pick a winner. Or if
folks don't suggest stuff, Kathleen and I will just pick something.
(We'll ensure the mailing list migrates etc. and will send a
heads-up on that as it happens.)

Cheers,
S.

On 17/06/16 17:33, The IESG wrote:
> A new IETF WG has been proposed in the Security Area. The IESG has not
> made any determination yet. The following draft charter was submitted,
> and is provided for informational purposes only. Please send your
> comments to the IESG mailing list (iesg@ietf.org) by 2016-06-27.
>=20
> Some PKIX and SMIME (spasm)
> -----------------------------------------------------------------------=

> Current status: Proposed WG
>=20
> Chairs:
>   TBD
>=20
> Assigned Area Director:
>   Stephen Farrell 
>=20
> Security Area Directors:
>   Stephen Farrell 
>   Kathleen Moriarty 
> =20
> Mailing list:
>   Address: spasm@ietf.org
>   To subscribe: https://www.ietf.org/mailman/listinfo/spasm
>   Archive: https://www.ietf.org/mail-archive/web/spasm/
>=20
> Charter: https://datatracker.ietf.org/doc/charter-ietf-spasm/
>=20
>=20
> The PKIX and S/MIME Working Groups have been closed for some time.  Som=
e
> updates have been proposed to the X.509 certificate documents produced =

> by the PKIX Working Group and the electronic mail security documents=20
> produced by the S/MIME Working Group.
>=20
> The SPASM (Some PKIX and S/MIME) Working Group is chartered to make
> updates where there is a known constituency interested in real=20
> deployment and there is at least one sufficiently well specified=20
> approach to the update so that the working group can sensibly evaluate =

> whether to adopt a proposal.  The current charter encompasses updates t=
o=20
> satisfy the following needs:
>=20
> 1. Specify the way to include an i18n email address as a subject
>    alternative name and an issuer alternative name.
>    draft-melnikov-spasm-eai-addresses is a proposal in this space.=20
>=20
> 2. Specify the way to use authenticated encryption in S/MIME.=20
>    draft-schaad-rfc5751-bis is a proposal in this space.
>=20
> In addition, the SPASM Working Group may investigate other updates to=20
> the documents produced by the PKIX and S/MIME Working Groups, but the=20
> SPASM Working Group shall not adopt any of these potential work items=20
> without rechartering. No such re-chartering is envisaged until one or=20
> more of the above work items have been successfully delivered to the RF=
C=20
> editor queue.=20
>=20
> Milestones:
>=20
> TBD
>=20
>=20


--------------ms090709070001050402020100
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MjIx
NDMzNDRaMC8GCSqGSIb3DQEJBDEiBCCHvwWf6I0S8M74//SbWZsBNqoMiAo5ZysJVUez0rhp
JDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQBu0v2eEqyCU12J0+hSPlyAWsLgi4YiqeLDX8uxIDCbf6VFE5xfcd6n
y1lRgNqxTO8lruiSvm/98rZCS+l2sLR3RbxR+aFHFZ+yuJNkcRS+Q1uUFxaG9O/x1MLgXWWq
1aNcOGudcMqomvtV9xi+mWmJKAz9PIU/xePIZhOSDtqmvAQsZDimOUKbOtO2+jzyo2U/yczv
7nNOH31eGarymv4aFTxXt2rJhiTtSE6wpNODn2PqExAc3zfiRryDDYxEdHj/zszs/7wdbuNb
YhJ6pquKOeRsHRzrc9klw1AgHQLKe+6ZXEF6crhhOGiXvgDs6wCYS/sbigSioTu5LHCNLJnH
AAAAAAAA
--------------ms090709070001050402020100--


From nobody Wed Jun 22 10:14:28 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E62412D964 for ; Wed, 22 Jun 2016 10:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 jJtu3A31lzTV for ; Wed, 22 Jun 2016 10:14:24 -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 55F1A12D09D for ; Wed, 22 Jun 2016 10:14:24 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4BD1E509B5 for ; Wed, 22 Jun 2016 13:14:22 -0400 (EDT)
To: spasm@ietf.org
References: <20160617163337.9633.3485.idtracker@ietfa.amsl.com> <576AA1C8.1070604@cs.tcd.ie>
From: Sean Leonard 
Message-ID: 
Date: Wed, 22 Jun 2016 10:14:20 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <576AA1C8.1070604@cs.tcd.ie>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Spasm] WG Review: Some PKIX and SMIME (spasm)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 22 Jun 2016 17:14:26 -0000

On 6/22/2016 7:33 AM, Stephen Farrell wrote:
> Two things:
>
> 1. The IETF96 slot for this may be moving. I'll send mail when/if
> that happens but please be aware of it as you plan travel. (The
> draft agenda remains a draft agenda until it's a final agenda:-)
>
> 2. We got a comment that the WG name might be considered undesirable.
> I don't want to debate that but since it's a "don't care" we'll
> likely change the WG name. Feel free to suggest other names here in
> the next day or two and Kathleen and I will pick a winner. Or if
> folks don't suggest stuff, Kathleen and I will just pick something.
> (We'll ensure the mailing list migrates etc. and will send a
> heads-up on that as it happens.)

PAIN: PKIX and Internationalized Names

:)

Sean

> Cheers,
> S.
>
> On 17/06/16 17:33, The IESG wrote:
>> A new IETF WG has been proposed in the Security Area. The IESG has not
>> made any determination yet. The following draft charter was submitted,
>> and is provided for informational purposes only. Please send your
>> comments to the IESG mailing list (iesg@ietf.org) by 2016-06-27.
>>
>> Some PKIX and SMIME (spasm)
>> -----------------------------------------------------------------------
>> Current status: Proposed WG
>>
>> Chairs:
>>    TBD
>>
>> Assigned Area Director:
>>    Stephen Farrell 
>>
>> Security Area Directors:
>>    Stephen Farrell 
>>    Kathleen Moriarty 
>>   
>> Mailing list:
>>    Address: spasm@ietf.org
>>    To subscribe: https://www.ietf.org/mailman/listinfo/spasm
>>    Archive: https://www.ietf.org/mail-archive/web/spasm/
>>
>> Charter: https://datatracker.ietf.org/doc/charter-ietf-spasm/
>>
>>
>> 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 SPASM (Some PKIX and S/MIME) Working Group is chartered to make
>> updates where there is a known constituency interested in real
>> deployment and there is at least one sufficiently well specified
>> approach to the update so that the working group can sensibly evaluate
>> whether to adopt a proposal.  The current charter encompasses updates to
>> satisfy the following needs:
>>
>> 1. Specify the way to include an i18n email address as a subject
>>     alternative name and an issuer alternative name.
>>     draft-melnikov-spasm-eai-addresses is a proposal in this space.
>>
>> 2. Specify the way to use authenticated encryption in S/MIME.
>>     draft-schaad-rfc5751-bis is a proposal in this space.
>>
>> In addition, the SPASM Working Group may investigate other updates to
>> the documents produced by the PKIX and S/MIME Working Groups, but the
>> SPASM Working Group shall not adopt any of these potential work items
>> without rechartering. No such re-chartering is envisaged until one or
>> more of the above work items have been successfully delivered to the RFC
>> editor queue.
>>
>> Milestones:
>>
>> TBD
>>
>>
>
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm



From nobody Wed Jun 22 12:07:27 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CB612DB4C for ; Wed, 22 Jun 2016 12:07:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 XT5MRQaoxDa0 for ; Wed, 22 Jun 2016 12:07:23 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 4091712DB55 for ; Wed, 22 Jun 2016 12:07:23 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id l188so79762617lfe.2 for ; Wed, 22 Jun 2016 12:07:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to;  bh=B0+MLTPx920EtVcwA9kYFF15vYy4VhfGXgOJsAPfs+g=; b=uopKLuSrgg8Vt0cTuddQQC7ffBKvv8RFF6ouVGZypeWpvqcMv3a4PlQE1e6ICkqBOU EpzrwGHRLURn1MQiK6LrOjM1LPVnHfZaG0S+yVrjp0qdxBOSP8pdRSr/DCwPM7E5DQdt 2ZlRr2l4nMsVtfrFpM+HwByX/O1RMg9w1mnfyaGJUtRp51zWkGLmIxQtn67lQQTjn9xM J+eL+Y/7NTZ9pZwtae/uJUzZRVW0JwxqZ15XC/R9PPJNBj06mKAt7N1pigDQ8S9w2Qhz a7Psx9E1EwTvrfWF2ugyr9DcMq2aYQy32ALPk72VRnL3hUywcHDvePhomN/pKOPc0THb andA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=B0+MLTPx920EtVcwA9kYFF15vYy4VhfGXgOJsAPfs+g=; b=NXXX81IabuBqVqkoc15i76WQdZfB1DIIqpJV1GrcDyu6rc/Y4zPy3iObc5qnSLtayg oUMNUef4SWxewcWGyN3vYPnrdsHoUqLg7jPPnoDB4wXGYp16ULATsixY6oyDzltQ0l13 iMJurkLYNbNib/JV8ojT79h2gZjRp85aAJPxOMuzPWCAg5s30JhoLuBs/6jGg4z0KrAe 5mEDu/OARdaT+q7AvIJlr96dxlX/Ek2e9CtZnvD8NaC/fk5KLwNFbq+b/cb1l6pHYYAX SjV16SpoUDsW9I7pT6gNRvYPApSXhVJoBNExtNdfzNUFVgqW6WR1dv08Sc/W5dbB7FtU 9S+w==
X-Gm-Message-State: ALyK8tIysRmo3uDO75tBNVtgN9np6PIj0Mxgiu0VWaT+K6Nfs89/15Jmxs6m7M+7kJP9P2QdBEWMRkcGQ7//4A==
X-Received: by 10.25.21.106 with SMTP id l103mr8283857lfi.27.1466622441194; Wed, 22 Jun 2016 12:07:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.141.132 with HTTP; Wed, 22 Jun 2016 12:07:20 -0700 (PDT)
In-Reply-To: 
References: <20160617163337.9633.3485.idtracker@ietfa.amsl.com> <576AA1C8.1070604@cs.tcd.ie> 
From: Michael Jenkins 
Date: Wed, 22 Jun 2016 15:07:20 -0400
Message-ID: 
To: spasm@ietf.org
Content-Type: multipart/alternative; boundary=001a113f17e8a089b20535e2a5bb
Archived-At: 
Subject: Re: [Spasm] WG Review: Some PKIX and SMIME (spasm)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 22 Jun 2016 19:07:26 -0000

--001a113f17e8a089b20535e2a5bb
Content-Type: text/plain; charset=UTF-8

lamps - Limited Additional Mechanisms for PKIX and SMIME
psych - PKIX (and) SMIME You Can Hack
slew - Short Lived Extra Work - this could be indefinitely rechartered for
any defunct WG


On Wed, Jun 22, 2016 at 1:14 PM, Sean Leonard  wrote:

> On 6/22/2016 7:33 AM, Stephen Farrell wrote:
>
>> Two things:
>>
>> 1. The IETF96 slot for this may be moving. I'll send mail when/if
>> that happens but please be aware of it as you plan travel. (The
>> draft agenda remains a draft agenda until it's a final agenda:-)
>>
>> 2. We got a comment that the WG name might be considered undesirable.
>> I don't want to debate that but since it's a "don't care" we'll
>> likely change the WG name. Feel free to suggest other names here in
>> the next day or two and Kathleen and I will pick a winner. Or if
>> folks don't suggest stuff, Kathleen and I will just pick something.
>> (We'll ensure the mailing list migrates etc. and will send a
>> heads-up on that as it happens.)
>>
>
> PAIN: PKIX and Internationalized Names
>
> :)
>
> Sean
>
> Cheers,
>> S.
>>
>> On 17/06/16 17:33, The IESG wrote:
>>
>>> A new IETF WG has been proposed in the Security Area. The IESG has not
>>> made any determination yet. The following draft charter was submitted,
>>> and is provided for informational purposes only. Please send your
>>> comments to the IESG mailing list (iesg@ietf.org) by 2016-06-27.
>>>
>>> Some PKIX and SMIME (spasm)
>>> -----------------------------------------------------------------------
>>> Current status: Proposed WG
>>>
>>> Chairs:
>>>    TBD
>>>
>>> Assigned Area Director:
>>>    Stephen Farrell 
>>>
>>> Security Area Directors:
>>>    Stephen Farrell 
>>>    Kathleen Moriarty 
>>>   Mailing list:
>>>    Address: spasm@ietf.org
>>>    To subscribe: https://www.ietf.org/mailman/listinfo/spasm
>>>    Archive: https://www.ietf.org/mail-archive/web/spasm/
>>>
>>> Charter: https://datatracker.ietf.org/doc/charter-ietf-spasm/
>>>
>>>
>>> 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 SPASM (Some PKIX and S/MIME) Working Group is chartered to make
>>> updates where there is a known constituency interested in real
>>> deployment and there is at least one sufficiently well specified
>>> approach to the update so that the working group can sensibly evaluate
>>> whether to adopt a proposal.  The current charter encompasses updates to
>>> satisfy the following needs:
>>>
>>> 1. Specify the way to include an i18n email address as a subject
>>>     alternative name and an issuer alternative name.
>>>     draft-melnikov-spasm-eai-addresses is a proposal in this space.
>>>
>>> 2. Specify the way to use authenticated encryption in S/MIME.
>>>     draft-schaad-rfc5751-bis is a proposal in this space.
>>>
>>> In addition, the SPASM Working Group may investigate other updates to
>>> the documents produced by the PKIX and S/MIME Working Groups, but the
>>> SPASM Working Group shall not adopt any of these potential work items
>>> without rechartering. No such re-chartering is envisaged until one or
>>> more of the above work items have been successfully delivered to the RFC
>>> editor queue.
>>>
>>> Milestones:
>>>
>>> TBD
>>>
>>>
>>>
>>
>> _______________________________________________
>> 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
>



-- 
Mike Jenkins
mjjenki@tycho.ncsc.mil - if you want me to read it only at my desk
m.jenkins.364706@gmail.com - to read everywhere
443-634-3951

--001a113f17e8a089b20535e2a5bb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


lamps - Limited Additional Mechanisms for PKIX and SMIMEpsych - PKIX (and) SMIME You Can Hack
slew - Short Lived Extra Work - =
this could be indefinitely rechartered for any defunct WG


On Wed, Jun 22, 2016 =
at 1:14 PM, Sean Leonard <dev+ietf@seantek.com> wrote:
On 6/22/2016 7:33 AM, Step=
hen Farrell wrote:



Two things:



1. The IETF96 slot for this may be moving. I'll send mail when/if

that happens but please be aware of it as you plan travel. (The

draft agenda remains a draft agenda until it's a final agenda:-)



2. We got a comment that the WG name might be considered undesirable.

I don't want to debate that but since it's a "don't care&q=
uot; we'll

likely change the WG name. Feel free to suggest other names here in

the next day or two and Kathleen and I will pick a winner. Or if

folks don't suggest stuff, Kathleen and I will just pick something.

(We'll ensure the mailing list migrates etc. and will send a

heads-up on that as it happens.)





PAIN: PKIX and Internationalized Names



:)



Sean





Cheers,

S.



On 17/06/16 17:33, The IESG wrote:



A new IETF WG has been proposed in the Security Area. The IESG has not

made any determination yet. The following draft charter was submitted,

and is provided for informational purposes only. Please send your

comments to the IESG mailing list (iesg@ietf.org) by 2016-06-27.



Some PKIX and SMIME (spasm)

-----------------------------------------------------------------------

Current status: Proposed WG



Chairs:

=C2=A0 =C2=A0TBD



Assigned Area Director:

=C2=A0 =C2=A0Stephen Farrell <stephen.farrell@cs.tcd.ie>



Security Area Directors:

=C2=A0 =C2=A0Stephen Farrell <stephen.farrell@cs.tcd.ie>

=C2=A0 =C2=A0Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>

=C2=A0 Mailing list:

=C2=A0 =C2=A0Address: s=
pasm@ietf.org

=C2=A0 =C2=A0To subscribe: https://www.ietf.org/mailman/l=
istinfo/spasm

=C2=A0 =C2=A0Archive: https://www.ietf.org/mail-archive/=
web/spasm/



Charter: https://datatracker.ietf.org/doc/charte=
r-ietf-spasm/





The PKIX and S/MIME Working Groups have been closed for some time.=C2=A0 So=
me

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 SPASM (Some PKIX and S/MIME) 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.=C2=A0 The current charter encompasses updates =
to

satisfy the following needs:



1. Specify the way to include an i18n email address as a subject

=C2=A0 =C2=A0 alternative name and an issuer alternative name.

=C2=A0 =C2=A0 draft-melnikov-spasm-eai-addresses is a proposal in this spac=
e.



2. Specify the way to use authenticated encryption in S/MIME.

=C2=A0 =C2=A0 draft-schaad-rfc5751-bis is a proposal in this space.



In addition, the SPASM Working Group may investigate other updates to

the documents produced by the PKIX and S/MIME Working Groups, but the

SPASM Working Group shall not adopt any of these potential work items

without rechartering. No such re-chartering is envisaged until one or

more of the above work items have been successfully delivered to the RFC
editor queue.



Milestones:



TBD











_______________________________________________

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





-- 
Mike Jenkins
mjjenki@tycho.ncsc.mil - if you want me to re=
ad it only at my desk
m.jenkins.364706@gmail.com - to read everywhere
=
443-634-3951



--001a113f17e8a089b20535e2a5bb--


From nobody Wed Jun 22 17:40:48 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8B612DE01 for ; Wed, 22 Jun 2016 17:40:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 Qvm1JpgBHc9C for ; Wed, 22 Jun 2016 17:40: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 C0DA912DE29 for ; Wed, 22 Jun 2016 17:40:43 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6E2B6509B6; Wed, 22 Jun 2016 20:40:42 -0400 (EDT)
To: Wei Chuang 
References: <20160608161629.19935.86198.idtracker@ietfa.amsl.com>    
From: Sean Leonard 
Message-ID: <74ff1afa-2edf-0868-7d34-e8675be4511b@seantek.com>
Date: Wed, 22 Jun 2016 17:40:37 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------7CEFAAB3FDAD4FF85871C15E"
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] certspec work (draft-seantek-certspec-06.txt)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 23 Jun 2016 00:40:47 -0000

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

On 6/15/2016 2:21 PM, Wei Chuang wrote:
>
>
>
>>     4. Another naming method I'm aware of is CRLSets used in
>>     Chromium: https://dev.chromium.org/Home/chromium-security/crlsets
>>     
>>     This might be something to consider and possibly mention in
>>     section 6 "Other Certificate Specifications".
>
>     Wei, can you provide more specifics on what you mean when you say
>     "another naming method": do you want a way to identify CRLSets, or
>     are you asking for documentation on how CRLSets identify certificat=
es?
>
>
> This is another technique for identifying a certificate.  I point it=20
> out for completeness in case its useful.  I believe its advantage is=20
> that its supposed to be compact, and general.
>
>
>     I am only somewhat familiar with CRLSets, but I was under the
>     impression that an entry in a (the) CRLSet identifies a
>     certificate by one of: SHA-256 fingerprint, SHA-256 hash of the
>     public key (SPKI), or SHA-256 hashes of one of the former two
>     split up into a Merkle tree.
>
>
> I believe its simpler than that.  Its the SHA-256 hash of the issuer=20
> SPKI and the certificate serial number.  I don't recall it being tied=20
> to Json (but I could be wrong).

Hello Wei, I wanted to follow up on this. I am willing to write in a=20
spec that includes the hash of the issuer's SPKI.

It will look like:

ISSUERSN:SPKI/SHA-256:3434ABAB..00DA;04FDBDA0

namely, the issuer part will be of the form "SPKI", a slash, and the=20
hash name. This preserves algorithm agility, and is syntactically=20
distinguishable from the LDAP string encoding.

Compare with:

ISSUERSN:O=3DDigiCert,ST=3DUT,C=3DUS;04FDBDA0


The question I would like to pose is: does Chromium or some other=20
implementation actually index certificates based on the issuer's SPKI=20
hash, followed by the serial number?

The other certspecs (well, most of them anyway) are intended to be=20
indexes or keys in a database or other lookup system. There are known=20
systems that index by SHA-1 hash, by issuer + SN, etc. (as has been=20
previously discussed). File paths are obviously indexes. Notably, pretty =

much all of the certspecs in draft-06 are based on data in the subject=20
certificate, or operatively associated directly with the subject=20
certificate (e.g., file path). The issuer DN is present in the subject=20
certificate, so it is "direct" (no certificate path building required).=20
In contrast, an arbitrary verifier has to perform several steps:
1. hunt for the issuer certificate based on the SPKI (hash)
2. extract the issuer DN(s) (there could be multiple issuer=20
certificates, e.g., certificate rollover. Clearly not key rollover)
3. then run the algorithm as if ISSUERSN: is specified with the issuer=20
DN(s) rather than the SPKIs.

This seems sub-optimal to me, unless the implementation is truly=20
indexing based on the hash of the issuer's SPKI, and has some live or=20
precomputed table that keeps the issuer's SPKI and certificate(s) togethe=
r.

I would appreciate some citation to the Chromium source code or writeup, =

regarding how Chromium keeps track of certificates.

Sean

PS An implementation could index certificates purely based on=20
serialNumber, and then sift through all matching certificates by=20
comparing issuer DN(s) and/or issuer SPKIs. Assuming that serialNumbers=20
are supposed to be relatively large and random, this will be pretty=20
efficient.

PPS If I enable this, I will also enable SPKI specification in=20
SUBJECTEXP:. However specifying the hash of the subjectPublicKeyInfo is=20
"direct" because the SPKI is contained in the subject's own certificate.


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


  
    
  
  
    
On 6/15/2016 2:21 PM, Wei Chuang wrote:

    

    

      


        


          


             
            

              

                  

                    

                      
4. Another naming method I'm aware of is
                        CRLSets used in Chromium: https://dev.chromium.org/Home/chromium-security/crlsets

                      

                      
This might be something to consider and
                        possibly mention in section 6 "Other Certificate Specifications".

                    

                  

                  

                 Wei, can you provide more specifics on what you
                mean when you say "another naming method": do you want a
                way to identify CRLSets, or are you asking for
                documentation on how CRLSets identify certificates?

              

            

            


            

            
This is another technique for identifying a
              certificate.  I point it out for completeness in case its
              useful.  I believe its advantage is that its supposed to
              be compact, and general.

            
 

            

              
 

                I am only somewhat familiar with CRLSets, but I was
                under the impression that an entry in a (the) CRLSet
                identifies a certificate by one of: SHA-256 fingerprint,
                SHA-256 hash of the public key (SPKI), or SHA-256 hashes
                of one of the former two split up into a Merkle tree. 

            

            


            

            
I believe its simpler than that.  Its the SHA-256 hash
              of the issuer SPKI and the certificate serial number.  I
              don't recall it being tied to Json (but I could be wrong).

          

        

      

    

    

    Hello Wei, I wanted to follow up on this. I am willing to write in a
    spec that includes the hash of the issuer's SPKI.

    

    It will look like:

    

    ISSUERSN:SPKI/SHA-256:3434ABAB..00DA;04FDBDA0

    

    namely, the issuer part will be of the form "SPKI", a slash, and the
    hash name. This preserves algorithm agility, and is syntactically
    distinguishable from the LDAP string encoding.

    

    Compare with:

    

    ISSUERSN:O=DigiCert,ST=UT,C=US;04FDBDA0

    

    

    The question I would like to pose is: does Chromium or some other
    implementation actually index certificates based on the issuer's
    SPKI hash, followed by the serial number?

    

    The other certspecs (well, most of them anyway) are intended to be
    indexes or keys in a database or other lookup system. There are
    known systems that index by SHA-1 hash, by issuer + SN, etc. (as has
    been previously discussed). File paths are obviously indexes.
    Notably, pretty much all of the certspecs in draft-06 are based on
    data in the subject certificate, or operatively associated directly
    with the subject certificate (e.g., file path). The issuer DN is
    present in the subject certificate, so it is "direct" (no
    certificate path building required). In contrast, an arbitrary
    verifier has to perform several steps:

    1. hunt for the issuer certificate based on the SPKI (hash)

    2. extract the issuer DN(s) (there could be multiple issuer
    certificates, e.g., certificate rollover. Clearly not key rollover)

    3. then run the algorithm as if ISSUERSN: is specified with the
    issuer DN(s) rather than the SPKIs.

    

    This seems sub-optimal to me, unless the implementation is truly
    indexing based on the hash of the issuer's SPKI, and has some live
    or precomputed table that keeps the issuer's SPKI and certificate(s)
    together.

    

    I would appreciate some citation to the Chromium source code or
    writeup, regarding how Chromium keeps track of certificates.

    

    Sean

    

    PS An implementation could index certificates purely based on
    serialNumber, and then sift through all matching certificates by
    comparing issuer DN(s) and/or issuer SPKIs. Assuming that
    serialNumbers are supposed to be relatively large and random, this
    will be pretty efficient.

    

    PPS If I enable this, I will also enable SPKI specification in
    SUBJECTEXP:. However specifying the hash of the subjectPublicKeyInfo
    is "direct" because the SPKI is contained in the subject's own
    certificate.

    

  


--------------7CEFAAB3FDAD4FF85871C15E--


From nobody Fri Jun 24 09:02:58 2016
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 3BD0612DC7C; Fri, 24 Jun 2016 09:00:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160624160042.10933.48167.idtracker@ietfa.amsl.com>
Date: Fri, 24 Jun 2016 09:00:42 -0700
Archived-At: 
Cc: spasm@ietf.org, stephen.farrell@cs.tcd.ie
Subject: [Spasm] spasm - Requested session has been scheduled for IETF 96
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "This is a venue 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, 24 Jun 2016 16:00:42 -0000

Dear Amy Vezza,

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

spasm Session 1 (1:00:00)
    Wednesday, Morning Session I 1000-1230
    Room Name: Charlottenburg I size: 80
    ---------------------------------------------
    

Special Note: 11:30-12:30


Request Information:


---------------------------------------------------------
Working Group Name: Some PKIX and SMIME
Area Name: Security Area
Session Requester: Amy Vezza

Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 25
Conflicts to Avoid: 
 First Priority: artarea trans curdle stir tls saag




Special Requests:
  If he its BoF happens, please don't conflict with that

There is a note in BoF Wiki there will be more conflicts but they are not listed.
Conflicts added by SF afterwards.
---------------------------------------------------------


From nobody Fri Jun 24 13:32:52 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A204812D678 for ; Fri, 24 Jun 2016 13:32:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 c7ADFBpMvCmh for ; Fri, 24 Jun 2016 13:32:49 -0700 (PDT)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 CA6DA12D697 for ; Fri, 24 Jun 2016 13:32:48 -0700 (PDT)
Received: by mail-oi0-x22d.google.com with SMTP id f189so130655951oig.3 for ; Fri, 24 Jun 2016 13:32:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wsC1hGSR/BxZZRrvmH68Wex3FeIJMGKbpVmpOiMcNj4=; b=DfnC3MWrWgCz3rLdfC+ihH+5xT82WGny6WtjOONdPPzjC4tPdVPIsw5wWZPi0MCQSE 3GuwnLm2jC1XnPpT3yeYR4VTAnm7tnPMBbhkUNl1xJ4fZRK6/1sfIfnwPlIazJ2YpWIN AYcg5sXzaA7lKYgqUORk380e0Ip8lTChwYIlXdOBqVO01en5uq8UqstmXLUg+M/c0ujv +iXjbvDB4qKGMEp84zcF1uE9graCIP3C62+q90FepUBqVtpgluZrEfmYXclUOZ2kSQe2 YASzQwWupRZayDgq243EKSv45Jehyres1x34Qtd4ov65ePz2EplvwP01d5wdXEBQv+S9 M1dQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wsC1hGSR/BxZZRrvmH68Wex3FeIJMGKbpVmpOiMcNj4=; b=UqKQmecvFjLVJChYExCT1eKh6d3Tn58pCfWwTGN2Kj6l8roopN//RvPG9r+r8GtfFB zNATR+yGK1t0oJXr0UjYc+KJU/SwyOejsRVKR/6qYfW80N+693VOAok0l0fH7elPnBCf Ps2H3mEdjZtU18fFesEPBlFNSF6B+yWnbambVjgnwgwdiOkevGgsOVbUlRaJlLAElIRf 46qBi+P1MhF4Mf51ndSIzNAybz5HMJOODJVAeqAdwHgTg+DuTjVv20b2NJOhvpKYxREW QuhQgkCGc5Fc1AO61F3Fg93SyBEwR/rLazQxEz1z1SVCVYy3HRF8dhP9Q6XOp8HVy0fT fV5g==
X-Gm-Message-State: ALyK8tJJ+bCpi/ohERtb+UOepXv1SwYOEwdedZcGHUzwgFxxlEiW+ArcM5we7Ksk8tJiTa4yshEWYK21s+qAlB5Q
X-Received: by 10.202.229.131 with SMTP id c125mr4332802oih.166.1466800367853;  Fri, 24 Jun 2016 13:32:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.27.139 with HTTP; Fri, 24 Jun 2016 13:32:47 -0700 (PDT)
In-Reply-To: <74ff1afa-2edf-0868-7d34-e8675be4511b@seantek.com>
References: <20160608161629.19935.86198.idtracker@ietfa.amsl.com>     <74ff1afa-2edf-0868-7d34-e8675be4511b@seantek.com>
From: Wei Chuang 
Date: Fri, 24 Jun 2016 13:32:47 -0700
Message-ID: 
To: Sean Leonard 
Content-Type: multipart/alternative; boundary=001a1141c1bee23e3905360c1297
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] certspec work (draft-seantek-certspec-06.txt)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 24 Jun 2016 20:32:51 -0000

--001a1141c1bee23e3905360c1297
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On Wed, Jun 22, 2016 at 5:40 PM, Sean Leonard  wrote:

> On 6/15/2016 2:21 PM, Wei Chuang wrote:
>
>
>
>
> 4. Another naming method I'm aware of is CRLSets used in Chromium:
>> https://dev
>> .chromium.org/Home/chromium-security/crlsets
>> This might be something to consider and possibly mention in section 6 "Other
>> Certificate Specifications".
>>
>>
>> Wei, can you provide more specifics on what you mean when you say
>> "another naming method": do you want a way to identify CRLSets, or are you
>> asking for documentation on how CRLSets identify certificates?
>>
>
> This is another technique for identifying a certificate.  I point it out
> for completeness in case its useful.  I believe its advantage is that its
> supposed to be compact, and general.
>
>
>>
>> I am only somewhat familiar with CRLSets, but I was under the impression
>> that an entry in a (the) CRLSet identifies a certificate by one of: SHA-256
>> fingerprint, SHA-256 hash of the public key (SPKI), or SHA-256 hashes of
>> one of the former two split up into a Merkle tree.
>>
>
> I believe its simpler than that.  Its the SHA-256 hash of the issuer SPKI
> and the certificate serial number.  I don't recall it being tied to Json
> (but I could be wrong).
>
>
> Hello Wei, I wanted to follow up on this. I am willing to write in a spec
> that includes the hash of the issuer's SPKI.
>
> It will look like:
>
> ISSUERSN:SPKI/SHA-256:3434ABAB..00DA;04FDBDA0
>
> namely, the issuer part will be of the form "SPKI", a slash, and the hash
> name. This preserves algorithm agility, and is syntactically
> distinguishable from the LDAP string encoding.
>
> Compare with:
>
> ISSUERSN:O=DigiCert,ST=UT,C=US;04FDBDA0
>
>
> The question I would like to pose is: does Chromium or some other
> implementation actually index certificates based on the issuer's SPKI hash,
> followed by the serial number?
>

Yes.  CRLSets are used in Chromium:
https://www.imperialviolet.org/2012/02/05/crlsets.html
https://www.imperialviolet.org/2014/04/29/revocationagain.html


>
> The other certspecs (well, most of them anyway) are intended to be indexes
> or keys in a database or other lookup system. There are known systems that
> index by SHA-1 hash, by issuer + SN, etc. (as has been previously
> discussed). File paths are obviously indexes. Notably, pretty much all of
> the certspecs in draft-06 are based on data in the subject certificate, or
> operatively associated directly with the subject certificate (e.g., file
> path). The issuer DN is present in the subject certificate, so it is
> "direct" (no certificate path building required). In contrast, an arbitrary
> verifier has to perform several steps:
> 1. hunt for the issuer certificate based on the SPKI (hash)
> 2. extract the issuer DN(s) (there could be multiple issuer certificates,
> e.g., certificate rollover. Clearly not key rollover)
> 3. then run the algorithm as if ISSUERSN: is specified with the issuer
> DN(s) rather than the SPKIs.
>
> This seems sub-optimal to me, unless the implementation is truly indexing
> based on the hash of the issuer's SPKI, and has some live or precomputed
> table that keeps the issuer's SPKI and certificate(s) together.
>
> I would appreciate some citation to the Chromium source code or writeup,
> regarding how Chromium keeps track of certificates.
>

agl's github link:
https://github.com/agl/crlset-tools

-Wei


>
> Sean
>
> PS An implementation could index certificates purely based on
> serialNumber, and then sift through all matching certificates by comparing
> issuer DN(s) and/or issuer SPKIs. Assuming that serialNumbers are supposed
> to be relatively large and random, this will be pretty efficient.
>
> PPS If I enable this, I will also enable SPKI specification in
> SUBJECTEXP:. However specifying the hash of the subjectPublicKeyInfo is
> "direct" because the SPKI is contained in the subject's own certificate.
>
>

--001a1141c1bee23e3905360c1297
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit




On Wed, Jun 22, 2016 at 5:40 PM, Sean Leonard <dev+ietf@seantek.com> wrote:

  
    
  
  

    
On 6/15/2016 2:21 PM, Wei Chuang wrote:

    

    

      


        


          


             
            

              

                  

                    

                      
4. Another naming method I'm aware of is
                        CRLSets used in Chromium: https://dev.chromium.org/Home/chromium-security/crlsets

                      

                      
This might be something to consider and
                        possibly mention in section 6 "Other Certificate Specifications".

                    

                  

                  

                 Wei, can you provide more specifics on what you
                mean when you say "another naming method": do you want a
                way to identify CRLSets, or are you asking for
                documentation on how CRLSets identify certificates?

              

            

            


            

            
This is another technique for identifying a
              certificate.  I point it out for completeness in case its
              useful.  I believe its advantage is that its supposed to
              be compact, and general.

            
 

            

              
 

                I am only somewhat familiar with CRLSets, but I was
                under the impression that an entry in a (the) CRLSet
                identifies a certificate by one of: SHA-256 fingerprint,
                SHA-256 hash of the public key (SPKI), or SHA-256 hashes
                of one of the former two split up into a Merkle tree. 

            

            


            

            
I believe its simpler than that.  Its the SHA-256 hash
              of the issuer SPKI and the certificate serial number.  I
              don't recall it being tied to Json (but I could be wrong).

          

        

      

    

    

    Hello Wei, I wanted to follow up on this. I am willing to write in a
    spec that includes the hash of the issuer's SPKI.

    

    It will look like:

    

    ISSUERSN:SPKI/SHA-256:3434ABAB..00DA;04FDBDA0

    

    namely, the issuer part will be of the form "SPKI", a slash, and the
    hash name. This preserves algorithm agility, and is syntactically
    distinguishable from the LDAP string encoding.

    

    Compare with:

    

    ISSUERSN:O=DigiCert,ST=UT,C=US;04FDBDA0

    

    

    The question I would like to pose is: does Chromium or some other
    implementation actually index certificates based on the issuer's
    SPKI hash, followed by the serial number?

Yes.  CRLSets are used in Chromium:
 

    

    The other certspecs (well, most of them anyway) are intended to be
    indexes or keys in a database or other lookup system. There are
    known systems that index by SHA-1 hash, by issuer + SN, etc. (as has
    been previously discussed). File paths are obviously indexes.
    Notably, pretty much all of the certspecs in draft-06 are based on
    data in the subject certificate, or operatively associated directly
    with the subject certificate (e.g., file path). The issuer DN is
    present in the subject certificate, so it is "direct" (no
    certificate path building required). In contrast, an arbitrary
    verifier has to perform several steps:

    1. hunt for the issuer certificate based on the SPKI (hash)

    2. extract the issuer DN(s) (there could be multiple issuer
    certificates, e.g., certificate rollover. Clearly not key rollover)

    3. then run the algorithm as if ISSUERSN: is specified with the
    issuer DN(s) rather than the SPKIs.

    

    This seems sub-optimal to me, unless the implementation is truly
    indexing based on the hash of the issuer's SPKI, and has some live
    or precomputed table that keeps the issuer's SPKI and certificate(s)
    together.

    

    I would appreciate some citation to the Chromium source code or
    writeup, regarding how Chromium keeps track of certificates.

agl's github link:

-Wei
 

    

    Sean

    

    PS An implementation could index certificates purely based on
    serialNumber, and then sift through all matching certificates by
    comparing issuer DN(s) and/or issuer SPKIs. Assuming that
    serialNumbers are supposed to be relatively large and random, this
    will be pretty efficient.

    

    PPS If I enable this, I will also enable SPKI specification in
    SUBJECTEXP:. However specifying the hash of the subjectPublicKeyInfo
    is "direct" because the SPKI is contained in the subject's own
    certificate.

    

  






--001a1141c1bee23e3905360c1297--


From nobody Wed Jun 29 06:57:57 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B2212B030 for ; Wed, 29 Jun 2016 06:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level: 
X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9HKrSuNzOt0 for ; Wed, 29 Jun 2016 06:57:53 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A9EA12DE21 for ; Wed, 29 Jun 2016 06:57:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 868BABE5D; Wed, 29 Jun 2016 14:57:48 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZGij-yK6f3K; Wed, 29 Jun 2016 14:57:48 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CC715BE5B; Wed, 29 Jun 2016 14:57:47 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1467208668; bh=GxESSDgEa0spqESbOmPQaXpUwGZ54Vl7fTrTXZn4qEk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=B8dcF3T3QTPWchNnXRbFHcrMq4L+x9LFdoFn3aZGt2xRvLXmrjMcjtbn37gpGLU5E yp8tc2ud5jP1EGXC6OyFd33MxCGBIvAM/tndmKK0/DkXPRReweYxRISajYkLJrCRCf OFVJKptYQETZ5PIipYex9CvZ3CSFxQwER8ByQM+U=
To: Michael Jenkins , spasm@ietf.org
References: <20160617163337.9633.3485.idtracker@ietfa.amsl.com> <576AA1C8.1070604@cs.tcd.ie>  
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <5773D3DC.6090306@cs.tcd.ie>
Date: Wed, 29 Jun 2016 14:57:48 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090800050902080804050706"
Archived-At: 
Subject: Re: [Spasm] WG Review: Some PKIX and SMIME (spasm)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 29 Jun 2016 13:57:56 -0000

This is a cryptographically signed message in MIME format.

--------------ms090800050902080804050706
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 22/06/16 20:07, Michael Jenkins wrote:
> lamps - Limited Additional Mechanisms for PKIX and SMIME

That's the winner!

You'll see various mails on this shortly probably if the
secretariat can get this changed for the Berlin agenda
(which I think they can).

The secretariat will migrate the mailing list without
you having to do stuff, but I'm not yet sure when that'll
happen.

Thanks,
S.



--------------ms090800050902080804050706
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2Mjkx
MzU3NDhaMC8GCSqGSIb3DQEJBDEiBCBoYHHPQz/KQu52g8SNSPIPUymjAmVJz/wZV1EkKLIQ
cjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQCPIrba02YaaK7hl1jYS/FudcbNGf/IIO6rcb2oq2WO9f4+SOzg1Hp7
D1Q8DTTO4uhgpvZCFIK7ZooT3OfWFg2/0aVY0UIzCc9TQtrOjHsKxCkCH3q/iDdPUgc8id2P
8IbEZ/a8LuE+rbw27T2b/XkLc80OUdg3ziQY+gsWHLAzdqSXW+JdqmN0OdDVDDUs0o9h8yEg
DSIjXf2UeU9wqQrxmki5uuE3eqNaOaWdbW7p9MhdmZ2jki7Ff/sVJ74bsrRqk5s5aB5TEqVv
qDwdvpWMbRyGoh4fHU3L605uTDF7DOuB6cStZdinch4xb/EZPMmw6uGycMnf4wtCsPUe5nVF
AAAAAAAA
--------------ms090800050902080804050706--


From nobody Wed Jun 29 07:28:05 2016
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 DFDB112D134; Wed, 29 Jun 2016 07:28:04 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Stephen Farrell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.25.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160629142804.18877.55791.idtracker@ietfa.amsl.com>
Date: Wed, 29 Jun 2016 07:28:04 -0700
Archived-At: 
Cc: spasm@ietf.org, spasm-chairs@ietf.org
Subject: [Spasm] Stephen Farrell's Yes on charter-ietf-spasm-00-04: (with COMMENT)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "This is a venue 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, 29 Jun 2016 14:28:05 -0000

Stephen Farrell has entered the following ballot position for
charter-ietf-spasm-00-04: Yes

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



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



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


We got a comment about the name "spasm" being undesirable, and so will
be changing to "lamps - Limited Additional Mechanisms for PKIX and
SMIME"
I'll explain more in email and on the call but hope that we conclude that
there's
no need for a 2nd external review just because of the name change.



From nobody Wed Jun 29 08:03:52 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D65128874; Wed, 29 Jun 2016 08:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level: 
X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJFRI1BAReim; Wed, 29 Jun 2016 08:03:41 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACDB212B004; Wed, 29 Jun 2016 08:03:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 385D7BE59; Wed, 29 Jun 2016 16:03:40 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRMYv6JFq7Gw; Wed, 29 Jun 2016 16:03:40 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A3787BE47; Wed, 29 Jun 2016 16:03:39 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1467212620; bh=dmaO3/5QJKkPmMlO7XwykcxVSUWLocw1PL7jitFbEpk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=NIy9tqhYAnPl5iSdhXJpTippGVwYbsTeFJ79ZP4XaP9Le0dPzFpLSO0GDUao1x28X 8xXayRKJZZlSktKA6Kxcuo8+W/bv9W9pIPzRCnZ4RtAuYtqXYXy7twqWrGa/nFs8Mb kcmrxuGd8lIvu9JlnGv0ucFC30YBBBCjxfI/MF/0=
To: IETF-Announce 
References: <20160617163337.9633.3485.idtracker@ietfa.amsl.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <5773E34B.9080503@cs.tcd.ie>
Date: Wed, 29 Jun 2016 16:03:39 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <20160617163337.9633.3485.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000407090702010904060106"
Archived-At: 
Cc: spasm@ietf.org, IETF-Discussion 
Subject: Re: [Spasm] WG Review: Some PKIX and SMIME (spasm)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 29 Jun 2016 15:03:46 -0000

This is a cryptographically signed message in MIME format.

--------------ms000407090702010904060106
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hi,

During chartering we got a comment that the proposed name of
this WG might be considered insensitive. We don't need to
have a discussion about that, as it makes little difference
otherwise, but we will be changing the name of the proposed
working group to:

lamps - Limited Additional Mechanisms for PKIX and SMIME

Thanks to Michael Jenkins for the suggestion on the current
WG mailing list. [1]

The secretariat will handle migrating the mailing list in
the coming weeks, and the IETF96 agenda will be updated
accordingly, assuming that the IESG approve the new working
group on the telechat tomorrow. If approved, the announcement
of the working group will use the new name, "lamps."

There are no other substantive changes to the draft charter. [2]

Thanks,
S.

[1] https://mailarchive.ietf.org/arch/msg/spasm/t4f5LKRJILn0KsLQdzA1fo8B1=
lM
[2] https://datatracker.ietf.org/doc/charter-ietf-spasm/


On 17/06/16 17:33, The IESG wrote:
> A new IETF WG has been proposed in the Security Area. The IESG has not
> made any determination yet. The following draft charter was submitted,
> and is provided for informational purposes only. Please send your
> comments to the IESG mailing list (iesg@ietf.org) by 2016-06-27.
>=20
> Some PKIX and SMIME (spasm)
> -----------------------------------------------------------------------=

> Current status: Proposed WG
>=20
> Chairs:
>   TBD
>=20
> Assigned Area Director:
>   Stephen Farrell 
>=20
> Security Area Directors:
>   Stephen Farrell 
>   Kathleen Moriarty 
> =20
> Mailing list:
>   Address: spasm@ietf.org
>   To subscribe: https://www.ietf.org/mailman/listinfo/spasm
>   Archive: https://www.ietf.org/mail-archive/web/spasm/
>=20
> Charter: https://datatracker.ietf.org/doc/charter-ietf-spasm/
>=20
>=20
> The PKIX and S/MIME Working Groups have been closed for some time.  Som=
e
> updates have been proposed to the X.509 certificate documents produced =

> by the PKIX Working Group and the electronic mail security documents=20
> produced by the S/MIME Working Group.
>=20
> The SPASM (Some PKIX and S/MIME) Working Group is chartered to make
> updates where there is a known constituency interested in real=20
> deployment and there is at least one sufficiently well specified=20
> approach to the update so that the working group can sensibly evaluate =

> whether to adopt a proposal.  The current charter encompasses updates t=
o=20
> satisfy the following needs:
>=20
> 1. Specify the way to include an i18n email address as a subject
>    alternative name and an issuer alternative name.
>    draft-melnikov-spasm-eai-addresses is a proposal in this space.=20
>=20
> 2. Specify the way to use authenticated encryption in S/MIME.=20
>    draft-schaad-rfc5751-bis is a proposal in this space.
>=20
> In addition, the SPASM Working Group may investigate other updates to=20
> the documents produced by the PKIX and S/MIME Working Groups, but the=20
> SPASM Working Group shall not adopt any of these potential work items=20
> without rechartering. No such re-chartering is envisaged until one or=20
> more of the above work items have been successfully delivered to the RF=
C=20
> editor queue.=20
>=20
> Milestones:
>=20
> TBD
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>=20


--------------ms000407090702010904060106
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2Mjkx
NTAzMzlaMC8GCSqGSIb3DQEJBDEiBCDLlB65cOaMjqYHBlvOUTb4WSE6/e7a/j0CFYQwfZRq
SzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQCo2qY8xMPJWZsOmye5tzZKiWbP1cHeFdxeThq40fmWbekuHIrG2NtC
59q2gm0iJl/fmDVr7hosoSpBedb2D4e/mWirNXIFvXjT2q84bWprXdqcoHhwvx1LVIbaoriC
HL4egX/E9bPgl/VhlGSVzjMgoK1UjP+rcr/UDzmWSfgWKfWefZS4eabUs14B5bRIDOubiAqr
C8kZNZ6ysZ+DIA5EcJ0hT7vzMRTpnz5HeIscqMzXOvXp0oMAVdfdOpHXBaDC9MrcrvW+G2vm
zB90kX4kG44E0Bt6JVb6BDaTdQ/UJ5TqYJ9R3z618xES2yjlJICrqMnV87/LgL19M04jvCPf
AAAAAAAA
--------------ms000407090702010904060106--


From nobody Wed Jun 29 08:53:48 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7683912D1B2 for ; Wed, 29 Jun 2016 08:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 AlwN5edyW4sp for ; Wed, 29 Jun 2016 08:53:45 -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 D3D7412D0A3 for ; Wed, 29 Jun 2016 08:53:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B042F300494 for ; Wed, 29 Jun 2016 11:53:43 -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 3zA5_jte7L90 for ; Wed, 29 Jun 2016 11:53:42 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id CA35D3002A3 for ; Wed, 29 Jun 2016 11:53:42 -0400 (EDT)
From: Russ Housley 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <1903B2F2-879C-47AC-A2E6-A5D19A8449EE@vigilsec.com>
Date: Wed, 29 Jun 2016 11:49:43 -0400
To: spasm@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Subject: [Spasm] DRAFT Agenda for LAMPS WG session in Berlin
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 29 Jun 2016 15:53:47 -0000

Please review and comment.

Russ

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

LAMPS WG Agenda

0)  Minute Taker, Jabber Scribe, Bluesheets
1)  Agenda Bash
2)  Status and open issues for draft-schaad-rfc5751-bis (Jim)
3)  Status and open issues for draft-melnikov-spasm-eai-addresses =
(Alexey and Wei)
4)  Open issues for draft-ietf-curdle-pkix (Simon or Jim)
5)  WG document adoption
6)  Wrap Up


From nobody Wed Jun 29 10:35:12 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D6512DD52 for ; Wed, 29 Jun 2016 10:35:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 t9KRqAyEN6nL for ; Wed, 29 Jun 2016 10:35:09 -0700 (PDT)
Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (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 DD13712DD44 for ; Wed, 29 Jun 2016 10:35:08 -0700 (PDT)
Received: by mail-ob0-x22b.google.com with SMTP id mu6so35856314obc.3 for ; Wed, 29 Jun 2016 10:35:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r0UmVGEl0hlBXYKYw330bm9QbvLUFLlnnNHrN6WWxtM=; b=A/D6xzslqmXJ7W4vXKr4TejuVJi3cIFXOwwcbzUntSBAPbftIqKd/jc6tXatjIIHp5 o5bTGhrDlxuSBVAHPJINCZW6DUjaYCEnpcrIHgmonW92Ql54vCQYcD0h6GS+s44bC7SY aP4cobbG9ttocn8u0mQczOvBCqXGxunSgX5n39kgRDGP8QTHYMIIk7iMqMj+ZtlQsABQ MbgeFGcFRdgTL5HTuw1Cj9MvLT0yIsXVnbC4hZ/v/adMdrxsPXk95g0Q5q5eLG8PvPwX uR6rN2sBK1EYCK5O30xqIvwqlcEsBLGJAnF6yNLgCDNZJaD1BpjPMXlZO78D6vpcmHbz FGeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r0UmVGEl0hlBXYKYw330bm9QbvLUFLlnnNHrN6WWxtM=; b=Ff52ZiAZLdfv2gdjpUGb4RW2UoJQsFmJ5Y3EP9ACOAYJo4ggP6oVmOmc93G5jcVpBT QoPeQnG2OPnEN4r9B4NcTdeuKQxGnUglwKVDgUljBkB7j0ELXYKSr69M+sk+EXsVW2bP Cmh6AQhfPqY9z0Ynb06UnH+Qt3d+U10TvPmXinirwUSwi+Jjban59EMZl5vcqY/3iDuk AJJbSeS0bqM6gPjnRyGEkKmAJqDae1pDRIbHAW8JdZ/x4yacRXC35ln5olGkjKRYxv9t VksJTi6XV0wFsVIzbux3O8igPTbPWbRAkyuHDIuagd9L5sk202DkBEgi3ivnAiYiwMvm iVjQ==
X-Gm-Message-State: ALyK8tImWsY6/Of4QtrD+KXzVKuO7zgTBO8d3+dukh2jXg1mplH5WznFaJl9lfVG5W5Y9Jan2DjFRRaf32WQt/vW
X-Received: by 10.157.37.242 with SMTP id q105mr6420342ota.29.1467221708157; Wed, 29 Jun 2016 10:35:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.27.139 with HTTP; Wed, 29 Jun 2016 10:35:07 -0700 (PDT)
In-Reply-To: <1903B2F2-879C-47AC-A2E6-A5D19A8449EE@vigilsec.com>
References: <1903B2F2-879C-47AC-A2E6-A5D19A8449EE@vigilsec.com>
From: Wei Chuang 
Date: Wed, 29 Jun 2016 10:35:07 -0700
Message-ID: 
To: Russ Housley 
Content-Type: multipart/alternative; boundary=001a113cf598b921f305366e2c2d
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] DRAFT Agenda for LAMPS WG session in Berlin
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 29 Jun 2016 17:35:11 -0000

--001a113cf598b921f305366e2c2d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

I think this agenda looks good.

Another thing to consider are the CMS algorithm updates which as I recall
was going to Curdle.  It would be very useful to hear how the progress for
these drafts:
        draft-housley-cms-eddsa-signatures
        draft-housley-cms-ecdh-new-curves
        draft-housley-cms-chacha20-poly1305

thanks,

-Wei

On Wed, Jun 29, 2016 at 8:49 AM, Russ Housley  wrote:

> Please review and comment.
>
> Russ
>
> = = = = = = = = =
>
> LAMPS WG Agenda
>
> 0)  Minute Taker, Jabber Scribe, Bluesheets
> 1)  Agenda Bash
> 2)  Status and open issues for draft-schaad-rfc5751-bis (Jim)
> 3)  Status and open issues for draft-melnikov-spasm-eai-addresses (Alexey
> and Wei)
> 4)  Open issues for draft-ietf-curdle-pkix (Simon or Jim)
> 5)  WG document adoption
> 6)  Wrap Up
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>

--001a113cf598b921f305366e2c2d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


I think this agenda looks good.

Another thing to consider are the CMS algorithm updates which as I recall was going to Curdle.  It would be very useful to hear how the progress for these drafts:
        draft-housley-cms-eddsa-signatures
        draft-housley-cms-ecdh-new-curves
        draft-housley-cms-chacha20-poly1305

thanks,

-Wei

On Wed, Jun 29, 2016 at 8:49 AM, Russ Housley <housley@vigilsec.com> wrote:
Please review and comment.



Russ



= = = = = = = = =



LAMPS WG Agenda



0)  Minute Taker, Jabber Scribe, Bluesheets

1)  Agenda Bash

2)  Status and open issues for draft-schaad-rfc5751-bis (Jim)

3)  Status and open issues for draft-melnikov-spasm-eai-addresses (Alexey and Wei)

4)  Open issues for draft-ietf-curdle-pkix (Simon or Jim)

5)  WG document adoption

6)  Wrap Up



_______________________________________________

Spasm mailing list

Spasm@ietf.org

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





--001a113cf598b921f305366e2c2d--


From nobody Wed Jun 29 10:38:12 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEF212D134 for ; Wed, 29 Jun 2016 10:38:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.426
X-Spam-Level: 
X-Spam-Status: No, score=-3.426 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4Bv2JvRCeSS for ; Wed, 29 Jun 2016 10:38:10 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9E812B048 for ; Wed, 29 Jun 2016 10:38:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1467221889; d=isode.com; s=june2016; i=@isode.com; bh=P3rNZbWKkjdXk7jvWWtIfQ9/aM9EgGABG8tOjtgtdh0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=xdRqPpw4Riu/LsSxdR8Hsrr5PNn0WguhLoPpq5QqxErlqdOtTAxQYjwljUEcVf2Jv1bLtE bT119AY8oHeEftsB3kjqv6RiUsCExGmyBoLyAlvqCnkHLHKJoJvLLTqyha+idO7VOVrVRZ FE4GXZ8qm/0/3kjr9J1Hz7IeWz0WW00=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215])  by waldorf.isode.com (submission channel) via TCP with ESMTPSA  id ; Wed, 29 Jun 2016 18:38:09 +0100
To: Wei Chuang , Russ Housley 
References: <1903B2F2-879C-47AC-A2E6-A5D19A8449EE@vigilsec.com> 
From: Alexey Melnikov 
Message-ID: <29cdb03f-9d35-5467-a9d0-1d73c7b474ee@isode.com>
Date: Wed, 29 Jun 2016 18:37:50 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------43A80B5A6603CD4AADBF7AF9"
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] DRAFT Agenda for LAMPS WG session in Berlin
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 29 Jun 2016 17:38:11 -0000

--------------43A80B5A6603CD4AADBF7AF9
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 29/06/2016 18:35, Wei Chuang wrote:

> I think this agenda looks good.
>
> Another thing to consider are the CMS algorithm updates which as I 
> recall was going to Curdle.  It would be very useful to hear how the 
> progress for these drafts:
>         draft-housley-cms-eddsa-signatures
>         draft-housley-cms-ecdh-new-curves
>         draft-housley-cms-chacha20-poly1305
+1 (if we have time)
>
> thanks,
>
> -Wei
>
> On Wed, Jun 29, 2016 at 8:49 AM, Russ Housley  > wrote:
>
>     Please review and comment.
>
>     Russ
>
>     = = = = = = = = =
>
>     LAMPS WG Agenda
>
>     0)  Minute Taker, Jabber Scribe, Bluesheets
>     1)  Agenda Bash
>     2)  Status and open issues for draft-schaad-rfc5751-bis (Jim)
>     3)  Status and open issues for draft-melnikov-spasm-eai-addresses
>     (Alexey and Wei)
>     4)  Open issues for draft-ietf-curdle-pkix (Simon or Jim)
>     5)  WG document adoption
>     6)  Wrap Up
>
>     _______________________________________________
>     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


--------------43A80B5A6603CD4AADBF7AF9
Content-Type: text/html; charset=UTF-8
Content-transfer-encoding: quoted-printable


  
    
  
  
    
On 29/06/2016 18:35, Wei Chuang wrote:

    

    

      
I think this agenda looks good.
        


        

        
Another thing to consider are the CMS algorithm updates
          which as I recall was going to Curdle.=C2=A0 It would be very
          useful to hear how the progress for these drafts:

        

          
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-housley-cms-eddsa-signature=
s

          
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-housley-cms-ecdh-new-curves=


          
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-housley-cms-chacha20-poly13=
05

        

      

    

    +1 (if we have time)

    

      

        


        

        
thanks,

        


        

        
-Wei

        


        

        

          

            
On Wed, Jun 29, 2016 at 8:49 AM,
              Russ Housley <housley@vigilsec.com>
              wrote:

              
Please
                review and comment.

                

                Russ

                

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

                

                LAMPS WG Agenda

                

                0)=C2=A0 Minute Taker, Jabber Scribe, Bluesheets

                1)=C2=A0 Agenda Bash

                2)=C2=A0 Status and open issues for draft-schaad-rfc5751-bis
                (Jim)

                3)=C2=A0 Status and open issues for draft-melnikov-spasm-eai=
-addresses
                (Alexey and Wei)

                4)=C2=A0 Open issues for draft-ietf-curdle-pkix (Simon or
                Jim)

                5)=C2=A0 WG document adoption

                6)=C2=A0 Wrap Up

                

                _______________________________________________

                Spasm mailing list

                S=
pasm@ietf.org

                https://www.ietf.org/mailman/listi=
nfo/spasm

              

            

            

          

        

      

      

      

      

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


    

    

  


--------------43A80B5A6603CD4AADBF7AF9--


From nobody Wed Jun 29 11:08:27 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC6712D1D8 for ; Wed, 29 Jun 2016 11:08:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 yNt86ItQgPv6 for ; Wed, 29 Jun 2016 11:08:24 -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 582CE12B01C for ; Wed, 29 Jun 2016 11:08:24 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5AADF509B6 for ; Wed, 29 Jun 2016 14:08:22 -0400 (EDT)
To: spasm@ietf.org
References: <1903B2F2-879C-47AC-A2E6-A5D19A8449EE@vigilsec.com>  <29cdb03f-9d35-5467-a9d0-1d73c7b474ee@isode.com>
From: Sean Leonard 
Message-ID: <2264b4d0-f1a9-3273-9d91-4df6852cd3f0@seantek.com>
Date: Wed, 29 Jun 2016 11:08:05 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <29cdb03f-9d35-5467-a9d0-1d73c7b474ee@isode.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Spasm] DRAFT Agenda for LAMPS WG session in Berlin
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 29 Jun 2016 18:08:26 -0000

On 6/29/2016 10:37 AM, Alexey Melnikov wrote:
>
> On 29/06/2016 18:35, Wei Chuang wrote:
>
>> I think this agenda looks good.
>>
>> Another thing to consider are the CMS algorithm updates which as I 
>> recall was going to Curdle.  It would be very useful to hear how the 
>> progress for these drafts:
>>         draft-housley-cms-eddsa-signatures
>>         draft-housley-cms-ecdh-new-curves
>>         draft-housley-cms-chacha20-poly1305
> +1 (if we have time)

+1 as well.

Sean


From nobody Wed Jun 29 11:47:13 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3354412D5E9 for ; Wed, 29 Jun 2016 11:47:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.899
X-Spam-Level: 
X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 9rDEjjvC85L4 for ; Wed, 29 Jun 2016 11:47:09 -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 0B3A712D5C8 for ; Wed, 29 Jun 2016 11:47:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CE4E33004DC for ; Wed, 29 Jun 2016 14:47:06 -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 C1JSahzOxxwO for ; Wed, 29 Jun 2016 14:47:05 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 7933B3002BF; Wed, 29 Jun 2016 14:47:05 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_30409663-EC34-4CC8-8A50-F6634787F944"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: 
Date: Wed, 29 Jun 2016 14:46:24 -0400
Message-Id: <6BB7AB58-01A3-43BF-ACDB-6AA0FCC4B638@vigilsec.com>
References: <1903B2F2-879C-47AC-A2E6-A5D19A8449EE@vigilsec.com> 
To: Wei Chuang 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] DRAFT Agenda for LAMPS WG session in Berlin
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 29 Jun 2016 18:47:11 -0000

--Apple-Mail=_30409663-EC34-4CC8-8A50-F6634787F944
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Wei:

Once we know what direction we are going with draft-ietf-curdle-pkix, it =
will be easy to align the CMS documents.  This alignment is the only =
open issue, so I do not think discussion of them is needed.

Russ


On Jun 29, 2016, at 1:35 PM, Wei Chuang  wrote:

> I think this agenda looks good.
>=20
> Another thing to consider are the CMS algorithm updates which as I =
recall was going to Curdle.  It would be very useful to hear how the =
progress for these drafts:
>         draft-housley-cms-eddsa-signatures
>         draft-housley-cms-ecdh-new-curves
>         draft-housley-cms-chacha20-poly1305
>=20
> thanks,
>=20
> -Wei
>=20
> On Wed, Jun 29, 2016 at 8:49 AM, Russ Housley  =
wrote:
> Please review and comment.
>=20
> Russ
>=20
> =3D =3D =3D =3D =3D =3D =3D =3D =3D
>=20
> LAMPS WG Agenda
>=20
> 0)  Minute Taker, Jabber Scribe, Bluesheets
> 1)  Agenda Bash
> 2)  Status and open issues for draft-schaad-rfc5751-bis (Jim)
> 3)  Status and open issues for draft-melnikov-spasm-eai-addresses =
(Alexey and Wei)
> 4)  Open issues for draft-ietf-curdle-pkix (Simon or Jim)
> 5)  WG document adoption
> 6)  Wrap Up
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>=20


--Apple-Mail=_30409663-EC34-4CC8-8A50-F6634787F944
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Wei:

Once we know what direction =
we are going with draft-ietf-curdle-pkix, it will be easy to align =
the CMS documents.  This alignment is the only open issue, so I do =
not think discussion of them is =
needed.

Russ


<=
div>
On Jun 29, 2016, at 1:35 PM, Wei Chuang <weihaw@google.com> =
wrote:

I think this agenda looks =
good.

Another thing to consider are the CMS algorithm =
updates which as I recall was going to Curdle.  It would be very =
useful to hear how the progress for these drafts:
  =
      draft-housley-cms-eddsa-signatures
  =
      draft-housley-cms-ecdh-new-curves
  =
      =
draft-housley-cms-chacha20-poly1305

thanks,=


-Wei

On Wed, Jun 29, 2016 at =
8:49 AM, Russ Housley <housley@vigilsec.com> =
wrote:
Please review and comment.



Russ



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



LAMPS WG Agenda



0)  Minute Taker, Jabber Scribe, Bluesheets

1)  Agenda Bash

2)  Status and open issues for draft-schaad-rfc5751-bis (Jim)

3)  Status and open issues for =
draft-melnikov-spasm-eai-addresses (Alexey and Wei)

4)  Open issues for draft-ietf-curdle-pkix (Simon or Jim)

5)  WG document adoption

6)  Wrap Up



_______________________________________________

Spasm mailing list

Spasm@ietf.org

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





=

--Apple-Mail=_30409663-EC34-4CC8-8A50-F6634787F944--


From nobody Wed Jun 29 14:17:00 2016
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 BD7DF12DEE2; Wed, 29 Jun 2016 14:16:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Alia Atlas" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.25.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160629211654.30333.58161.idtracker@ietfa.amsl.com>
Date: Wed, 29 Jun 2016 14:16:54 -0700
Archived-At: 
Cc: spasm@ietf.org, spasm-chairs@ietf.org
Subject: [Spasm] Alia Atlas' No Objection on charter-ietf-spasm-00-04: (with COMMENT)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "This is a venue 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, 29 Jun 2016 21:16:55 -0000

Alia Atlas has entered the following ballot position for
charter-ietf-spasm-00-04: No Objection

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



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



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

I agree that milestones are nice; this point was also brought up for
previous WGs by the IAB.



From nobody Thu Jun 30 00:18:39 2016
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 A41F012D980; Thu, 30 Jun 2016 00:18:33 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Benoit Claise" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.25.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160630071833.29538.17321.idtracker@ietfa.amsl.com>
Date: Thu, 30 Jun 2016 00:18:33 -0700
Archived-At: 
Cc: spasm@ietf.org, spasm-chairs@ietf.org
Subject: [Spasm] Benoit Claise's No Objection on charter-ietf-spasm-00-04: (with COMMENT)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "This is a venue 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, 30 Jun 2016 07:18:34 -0000

Benoit Claise has entered the following ballot position for
charter-ietf-spasm-00-04: No Objection

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



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



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

I always prefer to provide early guidelines about the deliverables
intended statuses.
And yes, the intended status is only a guideline and could change with
the right justifications.



From nobody Thu Jun 30 01:56:15 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC50A12B032; Thu, 30 Jun 2016 01:56:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level: 
X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8y6QLYi7dnX; Thu, 30 Jun 2016 01:56:12 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A30012D53B; Thu, 30 Jun 2016 01:56:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B9E62BDF9; Thu, 30 Jun 2016 09:56:09 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XstIUz6pYvui; Thu, 30 Jun 2016 09:56:08 +0100 (IST)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E14FEBE59; Thu, 30 Jun 2016 09:56:07 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1467276968; bh=i/oz3uLhs5PyE4l3y6K6LaQSd8egAM9xVsC/nYDtIRM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=hWdBzXd+ySjuOswvRmIamcnWHn7B7PYEpELE2i45XR1Op5deruQiQ0bN516qSM3cd OLwy1URwb0wlN3fLRa60/+gspNg0Z5V9PFXKlkqfk1k3scKuFDEDTh9h3lFL0QRg6u ZlNpkaRgNTiK9a9P2OeIqyE4pRe0Zl0gG0DbiCiw=
To: Benoit Claise , The IESG 
References: <20160630071833.29538.17321.idtracker@ietfa.amsl.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <5774DEA7.2000601@cs.tcd.ie>
Date: Thu, 30 Jun 2016 09:56:07 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <20160630071833.29538.17321.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000500090800010109050306"
Archived-At: 
Cc: spasm@ietf.org, spasm-chairs@ietf.org
Subject: Re: [Spasm] Benoit Claise's No Objection on charter-ietf-spasm-00-04: (with COMMENT)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 30 Jun 2016 08:56:15 -0000

This is a cryptographically signed message in MIME format.

--------------ms000500090800010109050306
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 30/06/16 08:18, Benoit Claise wrote:
> Benoit Claise has entered the following ballot position for
> charter-ietf-spasm-00-04: No Objection
>=20
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this=

> introductory paragraph, however.)
>=20
>=20
>=20
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-spasm/
>=20
>=20
>=20
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>=20
> I always prefer to provide early guidelines about the deliverables
> intended statuses.
> And yes, the intended status is only a guideline and could change with
> the right justifications.

My guess is PS, but the list hasn't discussed that and it
makes little to zero difference in this particular case so
I think I'll not try to add more to the milestone pile at
this point.

Cheers,
S.


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


--------------ms000500090800010109050306
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MzAw
ODU2MDdaMC8GCSqGSIb3DQEJBDEiBCDrOCknHCbow2QHcdsrlZ3R4fXorhXizwKATMWFYVhm
ETBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQBzmH3RMEQD+EmpUme03jHXUZotztB7NvzROszfQUwpGDRosZz2zeeM
dD2VEZIHBaYMp/1+5M5wfNr9D9ItmIZjQXrZ/aiFheiNkA+x79rapQpbPLcHSjJh8GInTFfj
YvykOLhmkz3lzaFKPOT/+4cm0Lr+y0OOTWtEJXKokZJfGtVuiNqRxFb0mwt1fejxCU1SJ9xQ
aGnhzB9TVw/Q8npvjYnvLECMSFw2m2s994/mzahfwDhYYiVlLeJE8Tokz8mUHu6DB/JWba32
7zt0toIEF+PARgNQCVH2gpwcCpnIxbuziGMF3sFts8qatMM2G1O+QqvYS+qdLtvLo4nfwF7N
AAAAAAAA
--------------ms000500090800010109050306--


From nobody Thu Jun 30 08:24:48 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A303212DAA7 for ; Thu, 30 Jun 2016 08:24:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTpyj6g8VZ_N for ; Thu, 30 Jun 2016 08:24:39 -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 A861312DAA9 for ; Thu, 30 Jun 2016 08:24:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 98E86300525 for ; Thu, 30 Jun 2016 11:24:36 -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 5QuaXCUpNgt3 for ; Thu, 30 Jun 2016 11:24:35 -0400 (EDT)
Received: from [10.85.3.71] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id AB350300090; Thu, 30 Jun 2016 11:24:34 -0400 (EDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_84448477-6275-41A3-B316-0372CB639EE9"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <5774DEA7.2000601@cs.tcd.ie>
Date: Thu, 30 Jun 2016 11:23:41 -0400
Message-Id: 
References: <20160630071833.29538.17321.idtracker@ietfa.amsl.com> <5774DEA7.2000601@cs.tcd.ie>
To: Stephen Farrell 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: spasm@ietf.org, IESG , spasm-chairs@ietf.org
Subject: Re: [Spasm] Benoit Claise's No Objection on charter-ietf-spasm-00-04: (with COMMENT)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 30 Jun 2016 15:24:41 -0000

--Apple-Mail=_84448477-6275-41A3-B316-0372CB639EE9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Jun 30, 2016, at 4:56 AM, Stephen Farrell  =
wrote:

>=20
>=20
> On 30/06/16 08:18, Benoit Claise wrote:
>> Benoit Claise has entered the following ballot position for
>> charter-ietf-spasm-00-04: No Objection
>>=20
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut =
this
>> introductory paragraph, however.)
>>=20
>>=20
>>=20
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/charter-ietf-spasm/
>>=20
>>=20
>>=20
>> =
----------------------------------------------------------------------
>> COMMENT:
>> =
----------------------------------------------------------------------
>>=20
>> I always prefer to provide early guidelines about the deliverables
>> intended statuses.
>> And yes, the intended status is only a guideline and could change =
with
>> the right justifications.
>=20
> My guess is PS, but the list hasn't discussed that and it
> makes little to zero difference in this particular case so
> I think I'll not try to add more to the milestone pile at
> this point.
>=20
> Cheers,
> S.

Yes, I think that Proposed Standard is the intended result for both of =
the deliverables.

Russ


--Apple-Mail=_84448477-6275-41A3-B316-0372CB639EE9
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9zCCBK8w
ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF
MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l
dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw
WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV
BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW
51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD
FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI
kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az
aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA
P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD
VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG
AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw
RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu
YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl
cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm
am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7
BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl
nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK
2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7
mzCCBUAwggQooAMCAQICEQCzIsUuKpsHVq2Oiy2wXwvCMA0GCSqGSIb3DQEBCwUAMIGbMQswCQYD
VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow
GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50
IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTYwMzMxMDAwMDAwWhcNMTcw
MzMxMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkBFhRob3VzbGV5QHZpZ2lsc2VjLmNvbTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAOQwBbNVXhmLbyClWrRBX0GdNQFhVHEpbzM4tr5pdd0q
rPp8i+6qqNa4dAbJT6kodJ/LgsBi5EN3li4MJOIlf3rCsK1/VXepRwqUoc1cZfLRGdEj/4zgwrNZ
ULvOFiDIvYkAYDWRlYnEXulWr3KriOApHpfzbQvHStU1YsV762AIHVbZUW5tlTC9LfI8r+PIBFzv
Y5ujoUnSAgKgeE8gDK9yAxemrQ6wzDpwaf5PxEVnw0gOC2jtDojdzhoQfz57MFrL9pA1QyMbnItV
zCYfc5J7EfeCGupcFqwXytbJHSYPfLfM1/3omGgCGD/DZk4z4SUVC19k02iGxAIVDsWJ5oMCAwEA
AaOCAfIwggHuMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTrsV85
Y7qY6oVPF5xRd+wqIu3VJTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX
BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM
KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT
MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs
aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA
MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB
dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz
cC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUaG91c2xleUB2aWdpbHNlYy5jb20wDQYJKoZIhvcN
AQELBQADggEBACgHw+/VeC7LgLJs19KZ6Ds2cW+jLSPjA3AIqSxiQ+uyDFwe6FujBUqRCXfla0qg
MzbhJ+1uSxcaktsS5idpB5Dfp8SVEGLcjtSJwWVlEofjaRrx6pi2mzazQwfKklY/epvsgnCoY8KW
FeSGkpbQXu5WrIL18EFqMCHqDiu5/P49PcZnJRv2xHTi5CkIsI7XgOw4FazS3xuJMVQ5TVtIUeMW
OqRlNJaeTiBsOVauS3FE/zRejsAYhHp3EV1PZFhV6hdcK/8qKrqRBtZtsEIm2FNWNsk8p/3RmUQl
4n4qN/NvapmXyYqfHZiuxf2g8H/WHF8IlVDzljLy90Uy0X7Qp0gxggPGMIIDwgIBATCBsTCBmzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAsyLFLiqbB1atjostsF8L
wjAJBgUrDgMCGgUAoIIB6TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNjA2MzAxNTIzNDJaMCMGCSqGSIb3DQEJBDEWBBTThHVbiW6aqEBA/hVJmCYwTJ72ezCBwgYJ
KwYBBAGCNxAEMYG0MIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz
dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEQCzIsUuKpsHVq2Oiy2wXwvCMIHEBgsqhkiG9w0BCRACCzGBtKCBsTCBmzELMAkGA1UEBhMC
R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE
ChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAsyLFLiqbB1atjostsF8LwjANBgkqhkiG
9w0BAQEFAASCAQCdYEhN6j2NboCvcchiRosUrceRkrIcHFy1XXzu8yEPgdQl2XlBROtZQFYQugsx
viOXKzttJtLrWCB/W2XOMbCEQv7ZLbE/Kr5vjMijipp+JrdUYzrWEoje9DoyvKdje76xt81AHV3V
zZyTcFM96fveZWhOCw47XSf9dRw7C40+BACGx6JJwCfcbIPB8bc6DD8vO/vGS3stmhkA2+efFrnv
m2Y9VN1oO0w3ZgUBL+JKPO4IVkAzc0Z4obyKqoPZe2m1dbjzr/dwmQRaiZb/c6IwAu/+NCEzfltm
egM3GH/Se1usYMRdN0b0+ASRC29j31ml/+m0VyZooVK9hSxDnYEYAAAAAAAA

--Apple-Mail=_84448477-6275-41A3-B316-0372CB639EE9--


From nobody Thu Jun 30 08:38:13 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE8712D193 for ; Thu, 30 Jun 2016 08:37:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level: 
X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPxA6LYOyLSz for ; Thu, 30 Jun 2016 08:37:42 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1986212D1A1 for ; Thu, 30 Jun 2016 08:37:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DDFD1BE59; Thu, 30 Jun 2016 16:37:40 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGPjxntITNvJ; Thu, 30 Jun 2016 16:37:40 +0100 (IST)
Received: from [134.226.62.192] (cswireless62-192.scss.tcd.ie [134.226.62.192]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6BB29BE35; Thu, 30 Jun 2016 16:37:40 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1467301060; bh=wfEoIvpFcu/Oi3nqIsPHb75brPPyFfn3fxNS8SkTNT0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=LC7YumFoWuDzh1+oft+0MoWs7Sd+lARvcjop2fr5J4dTCqkhmb3OVS/8g/hMz4Zsi XQ6qS4ADtMHQFtfVBeiCl6xogWNuSNm/Og8kwnKmT1z7ACvwwpHa8Ks03zkh3wCNQU RrhGwR83xiwe7GoATnLYtRj6JmN06sD/bcXJPZps=
To: Russ Housley , spasm@ietf.org
References: <1903B2F2-879C-47AC-A2E6-A5D19A8449EE@vigilsec.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <57753CC6.5080602@cs.tcd.ie>
Date: Thu, 30 Jun 2016 16:37:42 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <1903B2F2-879C-47AC-A2E6-A5D19A8449EE@vigilsec.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010000040409010206090508"
Archived-At: 
Subject: Re: [Spasm] DRAFT Agenda for LAMPS WG session in Berlin
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 30 Jun 2016 15:37:51 -0000

This is a cryptographically signed message in MIME format.

--------------ms010000040409010206090508
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Thanks Russ.

The IESG has just approved creation of the WG,
which as described will be named LAMPS.

The secretariat will do various bits of magic
that will result in that happening and at some
point in this list being migrated to a new one
without any of you having to take action. (Sorry
about your local filters, you will of course
need to change those if you have them.)

Given next Monday is a holiday in the US and
the name-change that might take a few more days.

And in case it's not obvious already, Russ has
kindly agreed to chair the WG. Please join me in
thanking him, esp. as that means the WG is in
hugely experienced hands.

We'll likely add a 2nd co-chair later, so if you
are interested in helping out with that please do
get in touch with me offlist.

Since Russ has so much experience with IETF matters,
this seems like it will be a fine WG for a 2nd
co-chair who hasn't previously chaired a WG but
who is interested in learning about how to do that
well, so that's the kind of person for which I'll
be looking out.

Cheers,
S.

On 29/06/16 16:49, Russ Housley wrote:
> Please review and comment.
>=20
> Russ
>=20
> =3D =3D =3D =3D =3D =3D =3D =3D =3D
>=20
> LAMPS WG Agenda
>=20
> 0)  Minute Taker, Jabber Scribe, Bluesheets
> 1)  Agenda Bash
> 2)  Status and open issues for draft-schaad-rfc5751-bis (Jim)
> 3)  Status and open issues for draft-melnikov-spasm-eai-addresses (Alex=
ey and Wei)
> 4)  Open issues for draft-ietf-curdle-pkix (Simon or Jim)
> 5)  WG document adoption
> 6)  Wrap Up
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>=20


--------------ms010000040409010206090508
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MzAx
NTM3NDJaMC8GCSqGSIb3DQEJBDEiBCCiefcBh50oG0kD7DyRCAzpmt+DLCSpJU6NnOorKbZ9
NjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQBVqaO59oBOehuFT1jin+CCVD/BU43PWGzuaWUszmy6X0DdPk7A6tB/
E0ndjiJWl8D+jcJ5K6rtkoL0DObmHGoOQtJnFDmzMLLeDxqwiDNTvDZPvxN4hIbZ0TeCDlTI
6xHx3uDTmW4DprwXSX9LzGeTUGnVOrm5MUPk3WFKAbiALSegaFBZHboah50+s3Dj3/pn9Rl9
XvlGl5rbicM0dgWgA3CLk3vyqstBGB0fEnfe9RuGOW5Qwm5Zmps9qgeKG23eemTj+MFmxti1
ivkjEY2qO7g4aoh8a3XUPwhdx9NCnsd5EVo6/Ujk5r5zlWUiBDeWuVn1nqm6rwLQ9ZkGB8Qv
AAAAAAAA
--------------ms010000040409010206090508--


From nobody Thu Jun 30 10:36:24 2016
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 C415412B00B; Thu, 30 Jun 2016 10:36:11 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Meeting Session Request Tool\"" 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.25.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160630173611.29626.96691.idtracker@ietfa.amsl.com>
Date: Thu, 30 Jun 2016 10:36:11 -0700
Archived-At: 
Cc: spasm@ietf.org, lamps-chairs@ietf.org, smccammon@amsl.com, stephen.farrell@cs.tcd.ie
Subject: [Spasm] lamps - New Meeting Session Request for IETF 96
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "This is a venue 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, 30 Jun 2016 17:36:12 -0000

A new meeting session request has just been submitted by Stephanie McCammon, on behalf of the lamps working group.


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

Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 25
Conflicts to Avoid: 
 First Priority:  artarea trans curdle stir tls saag




Special Requests:
  If he its BoF happens, please don't conflict with that There is a note in BoF Wiki there will be more conflicts but they are not listed. Conflicts added by SF afterwards.
---------------------------------------------------------


From nobody Thu Jun 30 10:40:49 2016
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 E2E03128B44; Thu, 30 Jun 2016 10:40:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Meeting Session Request Tool\"" 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.25.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160630174047.29554.46544.idtracker@ietfa.amsl.com>
Date: Thu, 30 Jun 2016 10:40:47 -0700
Archived-At: 
Cc: spasm@ietf.org, spasm-chairs@ietf.org, smccammon@amsl.com, stephen.farrell@cs.tcd.ie
Subject: [Spasm] spasm - Cancelling a meeting request for IETF 96
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "This is a venue 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, 30 Jun 2016 17:40:48 -0000

A request to cancel a meeting session has just been submitted by .


From nobody Thu Jun 30 10:45:06 2016
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 894EA12DB1E; Thu, 30 Jun 2016 10:44:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.25.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160630174447.29606.61953.idtracker@ietfa.amsl.com>
Date: Thu, 30 Jun 2016 10:44:47 -0700
Archived-At: 
Cc: spasm@ietf.org, stephen.farrell@cs.tcd.ie
Subject: [Spasm] lamps - Requested session has been scheduled for IETF 96
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "This is a venue 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, 30 Jun 2016 17:44:48 -0000

Dear Stephanie McCammon,

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

lamps Session 1 (1:00:00)
    Wednesday, Morning Session I 1000-1230
    Room Name: Charlottenburg I size: 80
    ---------------------------------------------
    

Special Note: 10:00-11:00


Request Information:


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

Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 25
Conflicts to Avoid: 
 First Priority: artarea trans curdle stir tls saag




Special Requests:
  If he its BoF happens, please don't conflict with that There is a note in BoF Wiki there will be more conflicts but they are not listed. Conflicts added by SF afterwards.
---------------------------------------------------------


From nobody Thu Jun 30 11:01:49 2016
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 0D12C12D94A; Thu, 30 Jun 2016 11:01:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Meeting Session Request Tool\"" 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.25.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160630180148.29590.60476.idtracker@ietfa.amsl.com>
Date: Thu, 30 Jun 2016 11:01:48 -0700
Archived-At: 
Cc: spasm@ietf.org, lamps-chairs@ietf.org, smccammon@amsl.com, stephen.farrell@cs.tcd.ie
Subject: [Spasm] lamps - Update to a Meeting Session Request for IETF 96
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "This is a venue 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, 30 Jun 2016 18:01:48 -0000

An update to a meeting session request has just been submitted by Stephanie McCammon, on behalf of the lamps working group.


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

Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 25
Conflicts to Avoid: 
 First Priority: artarea trans curdle stir tls saag its




Special Requests:
  If he its BoF happens, please don't conflict with that There is a note in BoF Wiki there will be more conflicts but they are not listed. Conflicts added by SF afterwards.
---------------------------------------------------------


From nobody Thu Jun 30 14:21:11 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E297128874 for ; Thu, 30 Jun 2016 14:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 ifwiYJ5oIyUu for ; Thu, 30 Jun 2016 14:21:08 -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 C663112B020 for ; Thu, 30 Jun 2016 14:21:07 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B1A0A509B8 for ; Thu, 30 Jun 2016 17:21:06 -0400 (EDT)
To: spasm@ietf.org
From: Sean Leonard 
Message-ID: <6c58ff04-1af1-b3f9-dbb9-2a4534616f6d@seantek.com>
Date: Thu, 30 Jun 2016 14:20:49 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [Spasm] Want us to do LDAP eaiMail, or decide for someone else to do it
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 30 Jun 2016 21:21:10 -0000

Hello LAMPS (formerly SPASM):

Further to my comments last week, it's important that the IETF=20
standardize on how to encode internationalized e-mail addresses in=20
Directories (LDAP), and by extension, Directory-related protocol slots.

It would be nice if this WG decides whether that work is in-scope for=20
here. Ideally, to reduce implementation errors and duplicate code, the=20
format of the attribute should be the same as the format of the eaiName=20
GeneralName option under discussion. (I.e., if we decide on UTF8String=20
with U-labels--which is what it's trending towards--we use the same=20
format for the LDAP attribute.)

Conversely, if people feel that it's not in-scope here, then it should=20
be considered in-scope for some other IETF area (or get directly=20
sponsored), and coordinated appropriately with this eaiName work and=20
with the LDAP folks.

So, uh, how shall this proceed? Should it get a time slot at the IETF 96 =

meeting to talk about what people want to do?

Best regards,

Sean

PS I am fine with the premise that a certificate parser should not be=20
trolling through the subject DN for said attribute. Note that the LDAP=20
mail attribute is almost never included in a certificate subject DN so I =

see a putative LDAP eaiMail attribute pretty much the same way.



From nobody Thu Jun 30 23:39:58 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB4B12B014 for ; Thu, 30 Jun 2016 23:39:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.427
X-Spam-Level: 
X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcjuxYTVRRxd for ; Thu, 30 Jun 2016 23:39:55 -0700 (PDT)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id B608912D106 for ; Thu, 30 Jun 2016 23:39:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1467355194; d=isode.com; s=june2016; i=@isode.com; bh=GVaNQ1rCWwqY1rLfuJ3G77A6ns0dMwvKDc000Ip8Fsc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=HUJ/36e5jA3pfoUxV/Njtgu++u3FD3T3laA2fe9WWg2EIr6Tzle8Uefb9qZda+ppxcfCAi uuohQKpnmLwfDCXuuR/d2JQs16967pyzy2fWUxLsuFFg3h76jFEHlXYdTkmVP2bQ8Bl3Zp bNhj72JUDFMGdQNMznhH8SBR7+7WrEk=;
Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25])  by statler.isode.com (submission channel) via TCP with ESMTPSA  id ; Fri, 1 Jul 2016 07:39:54 +0100
X-SMTP-Protocol-Errors: PIPELINING
From: Alexey Melnikov 
X-Mailer: iPad Mail (13F69)
In-Reply-To: <6c58ff04-1af1-b3f9-dbb9-2a4534616f6d@seantek.com>
Date: Fri, 1 Jul 2016 07:49:51 +0100
Message-Id: 
References: <6c58ff04-1af1-b3f9-dbb9-2a4534616f6d@seantek.com>
To: Sean Leonard 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: spasm@ietf.org
Subject: Re: [Spasm] Want us to do LDAP eaiMail, or decide for someone else to do it
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue 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, 01 Jul 2016 06:39:57 -0000

Hi Sean,

> On 30 Jun 2016, at 22:20, Sean Leonard  wrote:
>=20
> Hello LAMPS (formerly SPASM):
>=20
> Further to my comments last week, it's important that the IETF standardize=
 on how to encode internationalized e-mail addresses in Directories (LDAP), a=
nd by extension, Directory-related protocol slots.

I agree that that would be desirable. There might have been LDAP related dra=
ft(s) on this topic already?

> It would be nice if this WG decides whether that work is in-scope for here=
. Ideally, to reduce implementation errors and duplicate code, the format of=
 the attribute should be the same as the format of the eaiName GeneralName o=
ption under discussion. (I.e., if we decide on UTF8String with U-labels--whi=
ch is what it's trending towards--we use the same format for the LDAP attrib=
ute.)
>=20
> Conversely, if people feel that it's not in-scope here, then it should be c=
onsidered in-scope for some other IETF area (or get directly sponsored), and=
 coordinated appropriately with this eaiName work and with the LDAP folks.

Probably not in scope for this WG, but I would be happy to AD sponsor this o=
ne.

> So, uh, how shall this proceed? Should it get a time slot at the IETF 96 m=
eeting to talk about what people want to do?

In LAMPS or somewhere else?
>=20
> Best regards,
>=20
> Sean
>=20
> PS I am fine with the premise that a certificate parser should not be trol=
ling through the subject DN for said attribute. Note that the LDAP mail attr=
ibute is almost never included in a certificate subject DN so I see a putati=
ve LDAP eaiMail attribute pretty much the same way.
>=20
>=20
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm