From nobody Fri Nov 4 07:25: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 481A41288B8 for ; Fri, 4 Nov 2016 07:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 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.497, 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 jiw8LFHG4_Mt for ; Fri, 4 Nov 2016 07:25:39 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 31E17129464 for ; Fri, 4 Nov 2016 07:25:38 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id v84so163589846oie.3 for ; Fri, 04 Nov 2016 07:25: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=loRMAvXYEfrT/Jnp7lU9yPfS4XnECU+YGE0fsm1kbNo=; b=alkucuVSAAf4O128A9I5R5ePsmLWRJTr0VMjz3ljR0KGO4Ml5ENTkwACzFu0c+wV3y OKPOmDDh8t9VUbOAUVTkUHTgQgpwN1pbp+4eO4xzAkTHESlse7IXcup4MTxGhI6xNWUa 1kvABk0wPqWRY+JrmEfYE9oQL+byrkLL5G5sq2a+7Rk0pjOQM44ICzjJMIxn9MHiW3Sj qzcclYcLMIGHa+rdfPJwDrzSOgUzNWtwJfNbOq+7IB66bK+51pKAuQKqukvpNW7e5x8Y 5STpKIVoK8Grx+kfs4wFPa4Fdn6H6X/lj8PsODetuzCooGRRLz0Lwj/7VdFeAVphgA9w Jehg== 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=loRMAvXYEfrT/Jnp7lU9yPfS4XnECU+YGE0fsm1kbNo=; b=a0VAikhw5cJGlOk8EG/QjnUJlGCgRAKKPqt0brRvqAKipJSAdCP/+hdi2iHO15+GLM 4lcM8K7Jsm6Garf7brS1P7UtEkLFvJaD6LffIb9Pbyx8T0ctyqiwLYwxUoPL8W3/WHCS b6+dQ+XRi4m974nmt//9jtrRZ8HcSoArbzdvHmkxtrO4IkNCxGkTEU/bwH40+2UIr4XU SYSORY51XdM3Eqgjp3kY3MInqmK8jyzy+Lz5cijEWAv5wlOX1tjagMCknBgfW35bV2R0 HPGFp3apeI/nkrdNoHeod3FRs1fWwN0euo1ZP2hYaVanIYOhPNWD1lFRxAoARK1B7h6q n6dw== X-Gm-Message-State: ABUngvfGI+SBdBbywTRTVPBG8yMJGv04RI9u5+3htT5LckRwlOTYWwgKjhqEG0MULwtV8CC2fA7V73DvYfgpLvnZ X-Received: by 10.157.4.84 with SMTP id 78mr11275025otc.205.1478269537944; Fri, 04 Nov 2016 07:25:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.14.226 with HTTP; Fri, 4 Nov 2016 07:25:37 -0700 (PDT) In-Reply-To: References: From: Wei Chuang Date: Fri, 4 Nov 2016 07:25:37 -0700 Message-ID: To: Phillip Hallam-Baker Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113f14d2b67a7b05407a7270" Archived-At: Cc: SPASM Subject: Re: [Spasm] CAB Forum efforts on S/MIME and client certs 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, 04 Nov 2016 14:25:41 -0000 --001a113f14d2b67a7b05407a7270 Content-Type: multipart/alternative; boundary=001a113f14d2b167cc05407a72ea --001a113f14d2b167cc05407a72ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I was wondering if S/MIME EV-like certificate was discussed before? The closest was this: https://www.ietf.org/mail-archive/web/smime/current/msg18970.html FWIW the combination of EV like profile and UI behavior (logo + other visual designator), and organizational level attestation with CT is what I think is a good direction as well. Going back to the IETF and CABF discussion. Presumably having discussions in both forums is fine as this type of proposal would overlaps different parts of what both organizations seem to be interested in. As only a recent participant in the IETF, it seems that the IETF is mostly interested in standards, security and infrastructure and probably policy but less so for UI and UX work. Where as the CABF is very much interested in the UI, UX and policy aspects. It seems like there's overlap in people, so at least to me, it seems like such a discussion could work. Perhaps cross posting common relevant discussions would help too. I bring this up, because it might be helpful to figure this out in advance to prevent confusion. -Wei On Fri, Oct 28, 2016 at 7:12 AM, Phillip Hallam-Baker wrote: > Just a heads up for people in this group that there is a working group > starting in CABForum looking at client certificate validation processes. > > One point that it might be useful to work on jointly would be ways of > making use of organization level certificates in S/MIME systems. The WebPKI > works well at what it is designed to do. The problem with the WebPKI is > that is a subset of people want it to do. > > > By 2030 I would love to see secure email to have got to the point where > there is something like 'booths in shopping malls' where professionals, > doctors, lawyers, etc. go to get their credentials notarized. But we aren't > close to that yet and we won't ever get there unless we have another way to > get to critical mass. > > Making use of EV guidelines or some variant thereof to jumpstart the > process of issue seems like it could be a way to get to deployment of > S/MIME in the public space. > > > Right now we have a perfect storm as far as end to end email security is > concerned. Snowden has got the tech community worked up on the issue. And > email security is currently the top issue in the US Presidential election. > I think that is a ludicrous situation but whoever wins is very likely to > make fixing email insecurity a priority. > > And no, I don't think the opponents of strong crypto are going to stand in > the way this time. In fact I think they will soon be looking for new jobs. > Yes, even the one who thinks he has tenure. > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > --001a113f14d2b167cc05407a72ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
I was wondering if S/MIME EV-like certificate was discussed before?  The closest was this:
FWIW the combination of EV like profile and UI behavior (logo + other visual designator), and organizational level attestation with CT is what I think is a good direction as well.  

Going back to the IETF and CABF discussion.  Presumably having discussions in both forums is fine as this type of proposal would overlaps different parts of what both organizations seem to be interested in.  As only a recent participant in the IETF, it seems that the IETF is mostly interested in standards, security and infrastructure and probably policy but less so for UI and UX work.  Where as the CABF is very much interested in the UI, UX and policy aspects.  It seems like there's overlap in people, so at least to me, it seems like such a discussion could work.  Perhaps cross posting common relevant discussions would help too.  I bring this up, because it might be helpful to figure this out in advance to prevent confusion.

-Wei 




On Fri, Oct 28, 2016 at 7:12 AM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
Just a heads up for people in this group that there is a working group starting in CABForum looking at client certificate validation processes.

One point that it might be useful to work on jointly would be ways of making use of organization level certificates in S/MIME systems. The WebPKI works well at what it is designed to do. The problem with the WebPKI is that is a subset of people want it to do.


By 2030 I would love to see secure email to have got to the point where there is something like 'booths in shopping malls' where professionals, doctors, lawyers, etc. go to get their credentials notarized. But we aren't close to that yet and we won't ever get there unless we have another way to get to critical mass.

Making use of EV guidelines or some variant thereof to jumpstart the process of issue seems like it could be a way to get to deployment of S/MIME in the public space.


Right now we have a perfect storm as far as end to end email security is concerned. Snowden has got the tech community worked up on the issue. And email security is currently the top issue in the US Presidential election. I think that is a ludicrous situation but whoever wins is very likely to make fixing email insecurity a priority.

And no, I don't think the opponents of strong crypto are going to stand in the way this time. In fact I think they will soon be looking for new jobs. Yes, even the one who thinks he has tenure.

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


--001a113f14d2b167cc05407a72ea-- --001a113f14d2b67a7b05407a7270 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDoR8DOJZ4KyieWM2Vn7Ci1 jIpjEfACaFsFnMLEU7BwmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjExMDQxNDI1MzhaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAXGsQi2GD7CmFczarqqK5TdCF9bkhMLECAQsGQDiB ceu4dEYInLjE/MsGCeJd2MC5364KmzT3Nr82kPCVTOLQ8/0FRPV4/04NDW9XtPXNLFqrjtlF9ZpT 5v8CDT//5m1EryWiWxTKLnUxVbjEW9BBOQ3iZ6QR5N/tNNcb+iz+B/UCPM9q9rYaknR3UCckX8uO A24p0p0D8ogk2qAHt01uY63Jou/wl4QlcVd5NK74WVV7apywmrJMcblwOLl3dYOBNLyp8UAjo4ho y2mW8+ExQzbnyafQUbgx2OoYd+qRIM7xN3jtTKkd7EvLG19PGcOzIC090ba+zcFWLd8n0qm22A== --001a113f14d2b67a7b05407a7270-- From nobody Mon Nov 7 12:05: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 99F5D12998B for ; Mon, 7 Nov 2016 12:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.308 X-Spam-Level: X-Spam-Status: No, score=-100.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, USER_IN_WHITELIST=-100] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QT0u2mnSPDUB for ; Mon, 7 Nov 2016 12:05:18 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24EFB12986C for ; Mon, 7 Nov 2016 12:05:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6AE10300AD5 for ; Mon, 7 Nov 2016 15:05:17 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id R4McpjonwnUr for ; Mon, 7 Nov 2016 15:05:16 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 61B053005C5 for ; Mon, 7 Nov 2016 15:05:16 -0500 (EST) 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: <147776174688.30589.3759161241757522148.idtracker@ietfa.amsl.com> Date: Mon, 7 Nov 2016 10:12:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3880FAF1-77B5-46DB-B0BA-12DCA726841C@vigilsec.com> References: <147776174688.30589.3759161241757522148.idtracker@ietfa.amsl.com> To: SPASM X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [Spasm] draft-ietf-lamps-rfc5750-bis-01.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: Mon, 07 Nov 2016 20:05:19 -0000 Section 1.3 includes: Appendix A contains information about algorithms are were used for prior versions of S/MIME but are no longer considered to meet modern security standards. Support of these algorithms may be needed to support historic S/MIME messages but SHOULD NOT be used for new mail. I think we need to say that the historic algorithms and smaller key = sizes might be needed to decrypt or validate signatures on stored email = messages. Section 4.3 includes: Implementations SHOULD use deterministic generation for the parameter 'k' for ECDSA as outlined in [RFC6979]. EdDSA is defined to generate this parameter deterministically. I think we might confuse the reader here. I think it would be better to = treat ECDSA and EdDSA are tow different signature algorithms. In this = case, I think the second sentence should be deleted. Russ On Oct 29, 2016, at 1:22 PM, Internet-Drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Limited Additional Mechanisms for = PKIX and SMIME of the IETF. >=20 > Title : Secure/Multipurpose Internet Mail Extensions = (S/ MIME) Version 4.0 Certificate Handling > Authors : Jim Schaad > Blake Ramsdell > Sean Turner > Filename : draft-ietf-lamps-rfc5750-bis-01.txt > Pages : 25 > Date : 2016-10-29 >=20 > Abstract: > This document specifies conventions for X.509 certificate usage by > Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. > S/MIME provides a method to send and receive secure MIME messages, > and certificates are an integral part of S/MIME agent processing. > S/MIME agents validate certificates as described in RFC 5280, the > Internet X.509 Public Key Infrastructure Certificate and CRL = Profile. > S/MIME agents must meet the certificate processing requirements in > this document as well as those in RFC 5280. This document obsoletes > RFC 3850. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-lamps-rfc5750-bis-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-rfc5750-bis-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Nov 7 21:42: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 91C961298A9 for ; Mon, 7 Nov 2016 21:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzvRJ1MNtKO4 for ; Mon, 7 Nov 2016 21:42:24 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D1A51299BC for ; Mon, 7 Nov 2016 21:42:21 -0800 (PST) Received: from hebrews (173.164.84.129) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 7 Nov 2016 21:59:43 -0800 From: Jim Schaad To: 'Russ Housley' , 'SPASM' References: <147776174688.30589.3759161241757522148.idtracker@ietfa.amsl.com> <3880FAF1-77B5-46DB-B0BA-12DCA726841C@vigilsec.com> In-Reply-To: <3880FAF1-77B5-46DB-B0BA-12DCA726841C@vigilsec.com> Date: Mon, 7 Nov 2016 21:42:05 -0800 Message-ID: <004f01d23982$d7f67270$87e35750$@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: AQHYZ1qJ54rLSTdaGyohgsJWxdXvfgKlxCbDoK0IicA= Content-Language: en-us X-Originating-IP: [173.164.84.129] Archived-At: Subject: Re: [Spasm] draft-ietf-lamps-rfc5750-bis-01.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, 08 Nov 2016 05:42:26 -0000 > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley > Sent: Monday, November 07, 2016 7:13 AM > To: SPASM > Subject: [Spasm] draft-ietf-lamps-rfc5750-bis-01.txt > > Section 1.3 includes: > > Appendix A contains information about algorithms are were used for > prior versions of S/MIME but are no longer considered to meet modern > security standards. Support of these algorithms may be needed to > support historic S/MIME messages but SHOULD NOT be used for new mail. > > I think we need to say that the historic algorithms and smaller key sizes might be > needed to decrypt or validate signatures on stored email messages. So, expand what it means to "support" historic messages? > > Section 4.3 includes: > > Implementations SHOULD use deterministic generation for the parameter > 'k' for ECDSA as outlined in [RFC6979]. EdDSA is defined to generate > this parameter deterministically. > > I think we might confuse the reader here. I think it would be better to treat > ECDSA and EdDSA are tow different signature algorithms. In this case, I think > the second sentence should be deleted. I have no problems with this. Jim > > Russ > > On Oct 29, 2016, at 1:22 PM, Internet-Drafts@ietf.org wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Limited Additional Mechanisms for PKIX and > SMIME of the IETF. > > > > Title : Secure/Multipurpose Internet Mail Extensions (S/ MIME) > Version 4.0 Certificate Handling > > Authors : Jim Schaad > > Blake Ramsdell > > Sean Turner > > Filename : draft-ietf-lamps-rfc5750-bis-01.txt > > Pages : 25 > > Date : 2016-10-29 > > > > Abstract: > > This document specifies conventions for X.509 certificate usage by > > Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. > > S/MIME provides a method to send and receive secure MIME messages, > > and certificates are an integral part of S/MIME agent processing. > > S/MIME agents validate certificates as described in RFC 5280, the > > Internet X.509 Public Key Infrastructure Certificate and CRL Profile. > > S/MIME agents must meet the certificate processing requirements in > > this document as well as those in RFC 5280. This document obsoletes > > RFC 3850. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-lamps-rfc5750-bis-01 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5750-bis-01 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Spasm mailing list > > Spasm@ietf.org > > https://www.ietf.org/mailman/listinfo/spasm > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Nov 10 03:25:14 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 98D49129684 for ; Thu, 10 Nov 2016 03:25:13 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-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 JGotNfgqZKg4 for ; Thu, 10 Nov 2016 03:25:11 -0800 (PST) Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [194.9.95.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B540A129489 for ; Thu, 10 Nov 2016 03:25:11 -0800 (PST) Received: from s554.loopia.se (localhost [127.0.0.1]) by s554.loopia.se (Postfix) with ESMTP id 986D41A53BE6 for ; Thu, 10 Nov 2016 12:25:08 +0100 (CET) Received: from s499.loopia.se (unknown [172.21.200.97]) by s554.loopia.se (Postfix) with ESMTP id 77E0695058E for ; Thu, 10 Nov 2016 12:25:08 +0100 (CET) Received: from s404.loopia.se (unknown [172.21.200.105]) by s499.loopia.se (Postfix) with ESMTP id DACBB136469A for ; Thu, 10 Nov 2016 12:24:49 +0100 (CET) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s500.loopia.se ([172.21.200.105]) by s404.loopia.se (s404.loopia.se [172.21.200.134]) (amavisd-new, port 10024) with LMTP id J4I07mqVe15y for ; Thu, 10 Nov 2016 12:24:49 +0100 (CET) X-Loopia-Auth: user X-Loopia-User: stefan@fiddler.nu X-Loopia-Originating-IP: 90.229.17.25 Received: from [10.0.1.51] (unknown [90.229.17.25]) (Authenticated sender: stefan@fiddler.nu) by s500.loopia.se (Postfix) with ESMTPSA id 29D10A9B9B3 for ; Thu, 10 Nov 2016 12:24:36 +0100 (CET) User-Agent: Microsoft-MacOutlook/f.1b.0.161010 Date: Thu, 10 Nov 2016 12:24:34 +0100 From: Stefan Santesson To: 'SPASM' Message-ID: <3E9DF91B-0986-4496-851A-B33F873DB7CE@aaa-sec.com> Thread-Topic: A generic ocsp-nocheck extension Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [Spasm] A generic ocsp-nocheck extension 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, 10 Nov 2016 11:25:13 -0000 Hi, I know this group will probably not want to do this, but just asking for feedback in general ETSI want to create a mechanism in X.509 certificates to declare that the certificate do not need to be checked for revocation which can be used in any certificate (not just OCSP certificates). The basic idea is that this extension could be used in situations where the private key is kept under such control that such statement could be done and that the private key is destroyed when no longer used. This could be the case for example in systems where the private key is generated, used once and then destroyed immediately, but the certificate could be valid for as long as it is needed to validate that one signature. Any thought about this. Is this a bad idea? Could it ever be a task for lamps to define such extension? /Stefan From nobody Thu Nov 10 05:17: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 8AC63129655 for ; Thu, 10 Nov 2016 05:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 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.497, 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 3Ok06mt_uFfl for ; Thu, 10 Nov 2016 05:17:16 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2579012953F for ; Thu, 10 Nov 2016 05:17:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 90FAABE4C; Thu, 10 Nov 2016 13:17:13 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ls9bj34EbCxt; Thu, 10 Nov 2016 13:17:12 +0000 (GMT) Received: from [172.19.19.46] (unknown [84.203.178.21]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 733E1BE2C; Thu, 10 Nov 2016 13:17:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1478783831; bh=SXUTkk1OF7m2okWp7P3aTWzXgQqUQzXbD9Qd3ZmGfQo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=vn8BZYuznC+pZTg4PBmVs+VxfGeZvBVdif5yMZRZikP49kbS4jL53V+epKsDF25Y/ LqtKLbseDs2s6fe84sZY8lrsz8BnXd36TTn631jjr04R3w4rSM7o6C2t/1BlFz7ZfJ CLPM6QwfkXutulyq3CsbMwJDDERbMERQfDQj/864= To: Stefan Santesson , 'SPASM' References: <3E9DF91B-0986-4496-851A-B33F873DB7CE@aaa-sec.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <1872233b-2278-f1e1-ec33-df1bd7f44622@cs.tcd.ie> Date: Thu, 10 Nov 2016 13:17:09 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <3E9DF91B-0986-4496-851A-B33F873DB7CE@aaa-sec.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000305070902030307040106" Archived-At: Subject: Re: [Spasm] A generic ocsp-nocheck extension 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, 10 Nov 2016 13:17:19 -0000 This is a cryptographically signed message in MIME format. --------------ms000305070902030307040106 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable https://tools.ietf.org/html/rfc5755#section-4.3.6 Just put that in a public key cert I guess. S On 10/11/16 11:24, Stefan Santesson wrote: > Hi, >=20 > I know this group will probably not want to do this, but just asking fo= r feedback in general >=20 > ETSI want to create a mechanism in X.509 certificates to declare that t= he certificate do not need to be checked for revocation which can be used= in any certificate (not just OCSP certificates). >=20 > The basic idea is that this extension could be used in situations where= the private key is kept under such control that such statement could be = done and that the private key is destroyed when no longer used. >=20 > This could be the case for example in systems where the private key is = generated, used once and then destroyed immediately, but the certificate = could be valid for as long as it is needed to validate that one signature= =2E >=20 >=20 > Any thought about this. > Is this a bad idea? > Could it ever be a task for lamps to define such extension? >=20 > /Stefan > =20 >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 --------------ms000305070902030307040106 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMTAx MzE3MDlaMC8GCSqGSIb3DQEJBDEiBCBhWJTGSyrx7ZxyOj1WKyY05e/eqJu8G22WiiNybCOv HzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCRXsMp9U6esE7bs+h91dTaq/S/+IOnZHIx/i2EGGBw25S8MFm3i9Fp c4Lo5QCeaQeofenSLzv/+IlKR89633j95C96wLk0t9auxMJiTJf7i/k2lUipKabrSvGhgxeA mRJLapEcuOmEL4JSE+lOUlAJz0OwfvvVne91PZpn87uEclwSWWqgmwRTaUT2eufjmqtScNM6 YL902QTb5bKX2Ak3A6l9YCXzBJ8qfUOviYRE/J9lu3BgbaUH8JP3RD/+piOZ6GD0AI+cwW2N ahGejPQ0Kre/dkjDPEb+yzOnhps+2R+P2VzKmn3liTM+Bgtyaa1f1Lghf6MvPaLWYlURXZZZ AAAAAAAA --------------ms000305070902030307040106-- From nobody Thu Nov 10 05:53: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 80096129445 for ; Thu, 10 Nov 2016 05:53:44 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 SukwuTsFE-VZ for ; Thu, 10 Nov 2016 05:53:42 -0800 (PST) Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [194.9.95.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF3B7129632 for ; Thu, 10 Nov 2016 05:53:41 -0800 (PST) Received: from s554.loopia.se (localhost [127.0.0.1]) by s554.loopia.se (Postfix) with ESMTP id 3570E1A51C05 for ; Thu, 10 Nov 2016 14:53:39 +0100 (CET) Received: from s499.loopia.se (unknown [172.21.200.97]) by s554.loopia.se (Postfix) with ESMTP id 12B63959CF0; Thu, 10 Nov 2016 14:53:39 +0100 (CET) Received: from s549.loopia.se (unknown [172.21.200.105]) by s499.loopia.se (Postfix) with ESMTP id 0D1D51363243; Thu, 10 Nov 2016 14:53:39 +0100 (CET) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s500.loopia.se ([172.21.200.105]) by s549.loopia.se (s549.loopia.se [172.21.200.137]) (amavisd-new, port 10024) with LMTP id LEQVR4D5buPt; Thu, 10 Nov 2016 14:53:38 +0100 (CET) X-Loopia-Auth: user X-Loopia-User: stefan@fiddler.nu X-Loopia-Originating-IP: 90.229.17.25 Received: from [10.0.1.51] (unknown [90.229.17.25]) (Authenticated sender: stefan@fiddler.nu) by s500.loopia.se (Postfix) with ESMTPSA id 36AB6A9D40F; Thu, 10 Nov 2016 14:53:38 +0100 (CET) User-Agent: Microsoft-MacOutlook/f.1b.0.161010 Date: Thu, 10 Nov 2016 14:53:37 +0100 From: Stefan Santesson To: Stephen Farrell , 'SPASM' Message-ID: <8351D074-A442-4A65-87B0-3E7D46B59589@aaa-sec.com> Thread-Topic: [Spasm] A generic ocsp-nocheck extension References: <3E9DF91B-0986-4496-851A-B33F873DB7CE@aaa-sec.com> <1872233b-2278-f1e1-ec33-df1bd7f44622@cs.tcd.ie> In-Reply-To: <1872233b-2278-f1e1-ec33-df1bd7f44622@cs.tcd.ie> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Spasm] A generic ocsp-nocheck extension 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, 10 Nov 2016 13:53:45 -0000 Hi Stephen, This is close, but not there. This extension states that there are no revocation information available. My extension would not say that. In fact, in the case I=E2=80=99m talking about r= evocation information would be available in order to support legacy implemen= tations. My extension would just say: You don=E2=80=99t have to check the revocation infor= mation that is available, because this certificate has a private key that is= protected against misuse, i.e. because it was destroyed before this certifi= cate was even issued. /Stefan On 10/11/16 14:17, "Stephen Farrell" wrote: =20 https://tools.ietf.org/html/rfc5755#section-4.3.6 =20 Just put that in a public key cert I guess. =20 S =20 On 10/11/16 11:24, Stefan Santesson wrote: > Hi, >=20 > I know this group will probably not want to do this, but just asking = for feedback in general >=20 > ETSI want to create a mechanism in X.509 certificates to declare that= the certificate do not need to be checked for revocation which can be used = in any certificate (not just OCSP certificates). >=20 > The basic idea is that this extension could be used in situations whe= re the private key is kept under such control that such statement could be d= one and that the private key is destroyed when no longer used. >=20 > This could be the case for example in systems where the private key i= s generated, used once and then destroyed immediately, but the certificate c= ould be valid for as long as it is needed to validate that one signature. >=20 >=20 > Any thought about this. > Is this a bad idea? > Could it ever be a task for lamps to define such extension? >=20 > /Stefan > =20 >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 =20 =20 From nobody Sat Nov 12 14:04:03 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 5D37912950F for ; Sat, 12 Nov 2016 14:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFFzPlg57oZ5 for ; Sat, 12 Nov 2016 14:04:01 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F07BA129412 for ; Sat, 12 Nov 2016 14:04:00 -0800 (PST) Received: from dooku.sandelman.ca (unknown [182.172.168.109]) by relay.sandelman.ca (Postfix) with ESMTPS id 360611F42F; Sat, 12 Nov 2016 22:03:59 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 6B7E83433; Sat, 12 Nov 2016 16:32:17 -0500 (EST) From: Michael Richardson To: Stefan Santesson In-reply-to: <8351D074-A442-4A65-87B0-3E7D46B59589@aaa-sec.com> References: <3E9DF91B-0986-4496-851A-B33F873DB7CE@aaa-sec.com> <1872233b-2278-f1e1-ec33-df1bd7f44622@cs.tcd.ie> <8351D074-A442-4A65-87B0-3E7D46B59589@aaa-sec.com> Comments: In-reply-to Stefan Santesson message dated "Thu, 10 Nov 2016 14:53:37 +0100." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 13 Nov 2016 06:32:17 +0900 Message-ID: <1869.1478986337@dooku.sandelman.ca> Archived-At: Cc: 'SPASM' , Stephen Farrell Subject: Re: [Spasm] A generic ocsp-nocheck extension 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, 12 Nov 2016 22:04:02 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stefan Santesson wrote: > My extension would just say: You don=E2=80=99t have to check the revo= cation > information that is available, because this certificate has a private > key that is protected against misuse, i.e. because it was destroyed > before this certificate was even issued. Can you give us a real-life example of how this one-time signature key would be used? --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYJ4phAAoJEJVM4Vb9/EKQObAH/RRAHFLQkrPQbfbh8iTtv4vN WNYZnWNEgfoNbDd3AxCXSEiw3C7o++bpIZCJQTW0bnFChtHU977f6z1hnI83uX7Q D7YrwYD9hkEURC2nQkIZ3EQdqkFrVNiTbecEfYVHUJWqK+e7E/c4j3jRhyEOQJWZ XOjxacVkhD0tJjRzrERYkUFvtZYkiaTgEQS/q5SMVsrEszLs39VhKYnpN6tNvqgv ZMmdenBJYCSX+r9OLPJejflaCRC8iPHcWnQw3mYDhpavRoGGSCe+G1iRfgUjlyGX mdHRRpD1E6sAcsZZexsS6bJsnJS7KTqC9jWrBZGTMkmRYnb4ORwBXUrc2VrS+MY= =Ewas -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Nov 12 17:13:01 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 5F8411296A0 for ; Sat, 12 Nov 2016 17:13:00 -0800 (PST) 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 et4GVxaPNyrt for ; Sat, 12 Nov 2016 17:12:58 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 A8198127ABE for ; Sat, 12 Nov 2016 17:12:58 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id q124so40070525itd.1 for ; Sat, 12 Nov 2016 17:12:58 -0800 (PST) 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=mBB2tdbd9aOujTcpIwo0ZhkS8+gmLqGAj8O1w4aDGq8=; b=MfKUVkPJCVc+GlHCmH/HnxlWkFDQajO2a17fQIqO5NjieFrgi/UUa8kOqLa9zc1A65 D1qjqtMgizYaEIdwakFz7hcyGUzf4rp4VAlVHwiL9MX2t0lxncme3QCcthHuBAfmaxyr tuck7x/KyYYx7vNCy0PgcOXX9tC1uBCNrPiY/zxWPKGqVTgJ0ZjUmaRClT9d18LMN43Q 5dyKlRuc3zOUwe+VFKkUg0R05YJyz5/W+xuKHD9OUAo7J/bAicGqNI8kjeVkXiTHFFiq ZM3CZFsicvO1kwWOYaEqYEA32xdFtcZahjr4HS0FTlkuJNemTNoFukWXd7//UH+i5x40 OewQ== 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=mBB2tdbd9aOujTcpIwo0ZhkS8+gmLqGAj8O1w4aDGq8=; b=LVmQ/yt/RQxdEnXbGqrQMjevy3Vo9WYrFexOcpxPyIsr4UVEdImJ02pFSRYcVtgZF2 5JqGu5XWsW81mDnJpbveUElv6R8x1Rn+FbgAQCKcb4tT1lZlBnoUtlPuXuSPKAqhUIJb EHVmgJWu7ULYQ/mdHvYLG4WeMzQfpBNdsnQdsRFiNjvrAZBhtbjwyxU6tsjzkmGjNzmS Xihzm5kcrtNNFSU2mFgHipn+FaWGXjW82Fk4JapyFOudhGfixE2VPyj7FI6QbJ5baNGP vVVP+3LpTuh2QLLpB9pyrQA97z2H9rfz8mmclsE7NftM4kHl4f93/5eYrk6S5NuGLGnV v8xA== X-Gm-Message-State: ABUngveVQREOC6IVntnbg0rug7Lj2zOQjZ3yP7ZcwKlZ4A6Cqp76zD4UT8sr71M+MEqPH9j2oBBO8jAcAsyzuw== X-Received: by 10.36.88.65 with SMTP id f62mr2767879itb.89.1478999577895; Sat, 12 Nov 2016 17:12:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.3.140 with HTTP; Sat, 12 Nov 2016 17:12:57 -0800 (PST) In-Reply-To: <3E9DF91B-0986-4496-851A-B33F873DB7CE@aaa-sec.com> References: <3E9DF91B-0986-4496-851A-B33F873DB7CE@aaa-sec.com> From: Michael Jenkins Date: Sat, 12 Nov 2016 20:12:57 -0500 Message-ID: To: Stefan Santesson Content-Type: multipart/alternative; boundary=001a114490be76ab4d0541246c59 Archived-At: Cc: SPASM Subject: Re: [Spasm] A generic ocsp-nocheck extension 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, 13 Nov 2016 01:13:00 -0000 --001a114490be76ab4d0541246c59 Content-Type: text/plain; charset=UTF-8 This sounds like a private-label extension; does it really call for standardization? In fact, I'd (my certificate-consuming application) would have to have a VERY strong reason to trust that the private key had been handled in the expected way, which sort of cries out for a small community of use. On Thu, Nov 10, 2016 at 6:24 AM, Stefan Santesson wrote: > Hi, > > I know this group will probably not want to do this, but just asking for > feedback in general > > ETSI want to create a mechanism in X.509 certificates to declare that the > certificate do not need to be checked for revocation which can be used in > any certificate (not just OCSP certificates). > > The basic idea is that this extension could be used in situations where > the private key is kept under such control that such statement could be > done and that the private key is destroyed when no longer used. > > This could be the case for example in systems where the private key is > generated, used once and then destroyed immediately, but the certificate > could be valid for as long as it is needed to validate that one signature. > > > Any thought about this. > Is this a bad idea? > Could it ever be a task for lamps to define such extension? > > /Stefan > > > > _______________________________________________ > 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 --001a114490be76ab4d0541246c59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This sounds like a private-label extension; does it r= eally call for standardization?

In fact, I'd (my certifica= te-consuming application) would have to have a VERY strong reason to trust = that the private key had been handled in the expected way, which sort of cr= ies out for a small community of use.
<= br>
On Thu, Nov 10, 2016 at 6:24 AM, Stefan Sante= sson <stefan@aaa-sec.com> wrote:
Hi,

I know this group will probably not want to do this, but just asking for fe= edback in general

ETSI want to create a mechanism in X.509 certificates to declare that the c= ertificate do not need to be checked for revocation which can be used in an= y certificate (not just OCSP certificates).

The basic idea is that this extension could be used in situations where the= private key is kept under such control that such statement could be done a= nd that the private key is destroyed when no longer used.

This could be the case for example in systems where the private key is gene= rated, used once and then destroyed immediately, but the certificate could = be valid for as long as it is needed to validate that one signature.


Any thought about this.
Is this a bad idea?
Could it ever be a task for lamps to define such extension?

/Stefan



_______________________________________________
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-395= 1
--001a114490be76ab4d0541246c59-- From nobody Sat Nov 12 22:12:05 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 758F41295C0 for ; Sat, 12 Nov 2016 22:12:04 -0800 (PST) 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 X6YK8IdBsTtP for ; Sat, 12 Nov 2016 22:12:02 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B889D128874 for ; Sat, 12 Nov 2016 22:12:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id ECDF6300AC2 for ; Sun, 13 Nov 2016 01:12:01 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QrN6J7K-1plo for ; Sun, 13 Nov 2016 01:12:00 -0500 (EST) Received: from dhcp-8c4e.meeting.ietf.org (dhcp-8c4e.meeting.ietf.org [31.133.140.78]) by mail.smeinc.net (Postfix) with ESMTPSA id 87AF7300A2A; Sun, 13 Nov 2016 01:11:58 -0500 (EST) 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: <8351D074-A442-4A65-87B0-3E7D46B59589@aaa-sec.com> Date: Sun, 13 Nov 2016 01:11:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3E9DF91B-0986-4496-851A-B33F873DB7CE@aaa-sec.com> <1872233b-2278-f1e1-ec33-df1bd7f44622@cs.tcd.ie> <8351D074-A442-4A65-87B0-3E7D46B59589@aaa-sec.com> To: Stefan Santesson X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM Subject: Re: [Spasm] A generic ocsp-nocheck extension 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, 13 Nov 2016 06:12:04 -0000 Stefan: No revocation information is available. Does the software need to know = the reason that it is not being made available? Is it sufficient for = the CP to state the reason for humans? Russ On Nov 10, 2016, at 8:53 AM, Stefan Santesson = wrote: > Hi Stephen, >=20 > This is close, but not there. > This extension states that there are no revocation information = available. >=20 > My extension would not say that. In fact, in the case I=92m talking = about revocation information would be available in order to support = legacy implementations. >=20 > My extension would just say: You don=92t have to check the revocation = information that is available, because this certificate has a private = key that is protected against misuse, i.e. because it was destroyed = before this certificate was even issued. >=20 >=20 > /Stefan >=20 >=20 >=20 >=20 > On 10/11/16 14:17, "Stephen Farrell" = wrote: >=20 >=20 > https://tools.ietf.org/html/rfc5755#section-4.3.6 >=20 > Just put that in a public key cert I guess. >=20 > S >=20 > On 10/11/16 11:24, Stefan Santesson wrote: >> Hi, >>=20 >> I know this group will probably not want to do this, but just asking = for feedback in general >>=20 >> ETSI want to create a mechanism in X.509 certificates to declare that = the certificate do not need to be checked for revocation which can be = used in any certificate (not just OCSP certificates). >>=20 >> The basic idea is that this extension could be used in situations = where the private key is kept under such control that such statement = could be done and that the private key is destroyed when no longer used. >>=20 >> This could be the case for example in systems where the private key = is generated, used once and then destroyed immediately, but the = certificate could be valid for as long as it is needed to validate that = one signature. >>=20 >>=20 >> Any thought about this. >> Is this a bad idea? >> Could it ever be a task for lamps to define such extension? >>=20 >> /Stefan >>=20 >>=20 >>=20 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >>=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Sat Nov 12 22:13:25 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 15FA71296BC for ; Sat, 12 Nov 2016 22:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 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, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IN0KEHtgjacc for ; Sat, 12 Nov 2016 22:13:17 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3ED1295C0 for ; Sat, 12 Nov 2016 22:13:16 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 32DA5496C3C; Sun, 13 Nov 2016 06:13:16 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 1CBEF496C0A; Sun, 13 Nov 2016 06:13:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1479017596; bh=p90gH8hyNw/mb3brOHuX+NC8Eea2swudp2WKdwDgnD4=; l=198; h=From:To:CC:Date:References:In-Reply-To:From; b=w2JEKB7MkGBH2m+vs4hxtSg73DjBvmGk4+lADRNz37pNNQM+D868bN9QQXzeq15Yk kBgxCCL1+pfHZSL/jzfsioTlWGGQ2bxVw2hW9b2uV3OKVpaOBxBJ4zwxsJt3+aGfFp vRyFxElAH+CeVLi6QzTJr0N0xo6QEhkoqTPNMCqU= Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 18B9F1E084; Sun, 13 Nov 2016 06:13:16 +0000 (GMT) Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 13 Nov 2016 00:13:15 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1178.000; Sun, 13 Nov 2016 00:13:15 -0600 From: "Salz, Rich" To: Russ Housley , Stefan Santesson Thread-Topic: [Spasm] A generic ocsp-nocheck extension Thread-Index: AQHSO0Udq92RKJrFjEGZRY9vVT/htqDShsKAgAAKMICABEbCAP//m7KQ Date: Sun, 13 Nov 2016 06:13:14 +0000 Message-ID: <024868a587a44f359359e127fcee4198@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <3E9DF91B-0986-4496-851A-B33F873DB7CE@aaa-sec.com> <1872233b-2278-f1e1-ec33-df1bd7f44622@cs.tcd.ie> <8351D074-A442-4A65-87B0-3E7D46B59589@aaa-sec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.87] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: SPASM Subject: Re: [Spasm] A generic ocsp-nocheck extension 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, 13 Nov 2016 06:13:21 -0000 I would think that this would allow specific apps to use generic PKI stacks= . -- =20 Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz From nobody Sun Nov 13 08:10: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 CF387129408 for ; Sun, 13 Nov 2016 08:10:27 -0800 (PST) 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 Sr4gHY55STvc for ; Sun, 13 Nov 2016 08:10:26 -0800 (PST) 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 161AF128DF6 for ; Sun, 13 Nov 2016 08:10:26 -0800 (PST) Received: from dhcp-97aa.meeting.ietf.org (unknown [31.133.151.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C9D85509B8; Sun, 13 Nov 2016 11:10:23 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: <8351D074-A442-4A65-87B0-3E7D46B59589@aaa-sec.com> Date: Mon, 14 Nov 2016 01:10:24 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <7865D04E-0A9E-454C-A4AE-B7639B6E376B@seantek.com> References: <3E9DF91B-0986-4496-851A-B33F873DB7CE@aaa-sec.com> <1872233b-2278-f1e1-ec33-df1bd7f44622@cs.tcd.ie> <8351D074-A442-4A65-87B0-3E7D46B59589@aaa-sec.com> To: Stefan Santesson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SPASM , Stephen Farrell Subject: Re: [Spasm] A generic ocsp-nocheck extension 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, 13 Nov 2016 16:10:28 -0000 I am not convinced that this semantic change is worth writing a raft of = code over, across the world=E2=80=99s crypto implementations. Also, =E2=80=9Cprivate key compromise=E2=80=9D is just one reason why a = certificate might be revoked. Other reasons include that the privilege = has been withdrawn (e.g., =E2=80=9Cstopped paying=E2=80=9D), or the = subject=E2=80=99s affiliation changed. noRevAvail (RFC 5755 Section 4.3.6) is okay; it gets the same result = that you are looking for anyway. Another option is to issue a CRL with a nextUpdate date that is waaaay = far in the future, namely, at least the valid notAfter date of the = certificate. Sean > On Nov 10, 2016, at 10:53 PM, Stefan Santesson = wrote: >=20 > Hi Stephen, >=20 > This is close, but not there. > This extension states that there are no revocation information = available. >=20 > My extension would not say that. In fact, in the case I=E2=80=99m = talking about revocation information would be available in order to = support legacy implementations. >=20 > My extension would just say: You don=E2=80=99t have to check the = revocation information that is available, because this certificate has a = private key that is protected against misuse, i.e. because it was = destroyed before this certificate was even issued. >=20 >=20 > /Stefan >=20 >=20 >=20 >=20 > On 10/11/16 14:17, "Stephen Farrell" = wrote: >=20 >=20 > https://tools.ietf.org/html/rfc5755#section-4.3.6 >=20 > Just put that in a public key cert I guess. >=20 > S >=20 > On 10/11/16 11:24, Stefan Santesson wrote: >> Hi, >>=20 >> I know this group will probably not want to do this, but just asking = for feedback in general >>=20 >> ETSI want to create a mechanism in X.509 certificates to declare that = the certificate do not need to be checked for revocation which can be = used in any certificate (not just OCSP certificates). >>=20 >> The basic idea is that this extension could be used in situations = where the private key is kept under such control that such statement = could be done and that the private key is destroyed when no longer used. >>=20 >> This could be the case for example in systems where the private key = is generated, used once and then destroyed immediately, but the = certificate could be valid for as long as it is needed to validate that = one signature. >>=20 >>=20 >> Any thought about this. >> Is this a bad idea? >> Could it ever be a task for lamps to define such extension? >>=20 >> /Stefan >>=20 >>=20 >>=20 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >>=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Nov 14 00:54: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 7D02B1295C4 for ; Mon, 14 Nov 2016 00:54:18 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 uA2OmXft3wlN for ; Mon, 14 Nov 2016 00:54:08 -0800 (PST) Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [194.9.95.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51249129401 for ; Mon, 14 Nov 2016 00:54:06 -0800 (PST) Received: from s554.loopia.se (localhost [127.0.0.1]) by s554.loopia.se (Postfix) with ESMTP id 42F711A4FF41 for ; Mon, 14 Nov 2016 09:54:04 +0100 (CET) Received: from s500.loopia.se (unknown [172.21.200.98]) by s554.loopia.se (Postfix) with ESMTP id 20BE4943E18 for ; Mon, 14 Nov 2016 09:54:04 +0100 (CET) Received: from s405.loopia.se (unknown [172.21.200.105]) by s500.loopia.se (Postfix) with ESMTP id 1DC93A9EA5F for ; Mon, 14 Nov 2016 09:54:04 +0100 (CET) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s500.loopia.se ([172.21.200.105]) by s405.loopia.se (s405.loopia.se [172.21.200.135]) (amavisd-new, port 10024) with LMTP id JSXrfj5fw80r for ; Mon, 14 Nov 2016 09:54:03 +0100 (CET) X-Loopia-Auth: user X-Loopia-User: stefan@fiddler.nu X-Loopia-Originating-IP: 85.235.7.89 Received: from [192.168.1.3] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: stefan@fiddler.nu) by s500.loopia.se (Postfix) with ESMTPSA id 3210EA9E472 for ; Mon, 14 Nov 2016 09:54:03 +0100 (CET) User-Agent: Microsoft-MacOutlook/f.1b.0.161010 Date: Mon, 14 Nov 2016 09:54:00 +0100 From: Stefan Santesson To: SPASM Message-ID: Thread-Topic: [Spasm] A generic ocsp-nocheck extension References: <3E9DF91B-0986-4496-851A-B33F873DB7CE@aaa-sec.com> <1872233b-2278-f1e1-ec33-df1bd7f44622@cs.tcd.ie> <8351D074-A442-4A65-87B0-3E7D46B59589@aaa-sec.com> <7865D04E-0A9E-454C-A4AE-B7639B6E376B@seantek.com> In-Reply-To: <7865D04E-0A9E-454C-A4AE-B7639B6E376B@seantek.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Spasm] A generic ocsp-nocheck extension 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, 14 Nov 2016 08:54:18 -0000 Thanks for thoughts and questions, I=E2=80=99ll try to address them all in one go: Russ,=20 As I said, the semantics asked for is NOT that there is no revocation infor= mation available. The semantics discussed is a hint that revocation checking is not necessary= . This may not look like much difference but it is. If revocation is not avai= lable, then standard X.509 validators will fail. With the discussed semantics that would not be the case. Those who are conf= igured to always look for revocation data, would still find it. The idea here is to allow systems to use the certificate, e.g. for signatur= e validation, even when being off line. The use case, I have one specific use case and that is our signature services. They gener= ate a new private key for each signature and validates the signer=E2=80=99s identi= ty at the time of signing. The certificate is generated also at the time of = signing. Once this is done, the private key is destroyed. Note that the cert= ificate is not short lived, just the private key is. Our certificates contains the authn context extension (RFC 7773) so revocat= ion in general is handled on the authentication layer=20 Why standardization? Well, that I also ask myself. It is not my proposal to make this a standard= . But ETSI plans to do this as an EU standard in response to the EU regulatio= n =E2=80=9CeIDAS=E2=80=9D. I have so far been critical to the proposal, but if such extension should b= e standardized, I=E2=80=99d much rather have an IETF extension (made simple and to= the point), than a possible over engineered European extension that I have = to deal with. This is why I turn to you. Either for good arguments to not do this, or possible support for doing an = IETF extension. /Stefan=20 On 13/11/16 17:10, "Spasm on behalf of Sean Leonard" wrote: I am not convinced that this semantic change is worth writing a raft of= code over, across the world=E2=80=99s crypto implementations. =20 Also, =E2=80=9Cprivate key compromise=E2=80=9D is just one reason why a certificate= might be revoked. Other reasons include that the privilege has been withdra= wn (e.g., =E2=80=9Cstopped paying=E2=80=9D), or the subject=E2=80=99s affiliation changed. =20 noRevAvail (RFC 5755 Section 4.3.6) is okay; it gets the same result th= at you are looking for anyway. =20 Another option is to issue a CRL with a nextUpdate date that is waaaay = far in the future, namely, at least the valid notAfter date of the certifica= te. =20 Sean =20 > On Nov 10, 2016, at 10:53 PM, Stefan Santesson w= rote: >=20 > Hi Stephen, >=20 > This is close, but not there. > This extension states that there are no revocation information availa= ble. >=20 > My extension would not say that. In fact, in the case I=E2=80=99m talking a= bout revocation information would be available in order to support legacy im= plementations. >=20 > My extension would just say: You don=E2=80=99t have to check the revocation= information that is available, because this certificate has a private key t= hat is protected against misuse, i.e. because it was destroyed before this c= ertificate was even issued. >=20 >=20 > /Stefan >=20 >=20 >=20 >=20 > On 10/11/16 14:17, "Stephen Farrell" wrot= e: >=20 >=20 > https://tools.ietf.org/html/rfc5755#section-4.3.6 >=20 > Just put that in a public key cert I guess. >=20 > S >=20 > On 10/11/16 11:24, Stefan Santesson wrote: >> Hi, >>=20 >> I know this group will probably not want to do this, but just asking= for feedback in general >>=20 >> ETSI want to create a mechanism in X.509 certificates to declare tha= t the certificate do not need to be checked for revocation which can be used= in any certificate (not just OCSP certificates). >>=20 >> The basic idea is that this extension could be used in situations wh= ere the private key is kept under such control that such statement could be = done and that the private key is destroyed when no longer used. >>=20 >> This could be the case for example in systems where the private key = is generated, used once and then destroyed immediately, but the certificate = could be valid for as long as it is needed to validate that one signature. >>=20 >>=20 >> Any thought about this. >> Is this a bad idea? >> Could it ever be a task for lamps to define such extension? >>=20 >> /Stefan >>=20 >>=20 >>=20 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >>=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm =20 _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm =20 From nobody Mon Nov 14 20:10: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 909CA1296B0 for ; Mon, 14 Nov 2016 20:10:19 -0800 (PST) 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 d3xpWqhg3SOD for ; Mon, 14 Nov 2016 20:10:18 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72FD512943D for ; Mon, 14 Nov 2016 20:10:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9D674300AD1 for ; Mon, 14 Nov 2016 23:10:17 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id APB9fqlGxbo0 for ; Mon, 14 Nov 2016 23:10:16 -0500 (EST) Received: from dhcp-8c4e.meeting.ietf.org (dhcp-8c4e.meeting.ietf.org [31.133.140.78]) by mail.smeinc.net (Postfix) with ESMTPSA id 8B56B300A23 for ; Mon, 14 Nov 2016 23:10:15 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <897230ED-8D25-49C6-A546-C106FC0C5ACC@vigilsec.com> Date: Mon, 14 Nov 2016 23:10:11 -0500 To: SPASM Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [Spasm] Need volunteers for minutes and jabber scribe 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, 15 Nov 2016 04:10:19 -0000 Please let me know if you are willing to take minutes or jabber scribe = for the LAMPS session at IETF 97.= From nobody Tue Nov 15 17:40:00 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 11D4D1293D6 for ; Tue, 15 Nov 2016 17:39:58 -0800 (PST) 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 Te7rYGpo5ArR for ; Tue, 15 Nov 2016 17:39:56 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69327129405 for ; Tue, 15 Nov 2016 17:39:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id AC776300AD3 for ; Tue, 15 Nov 2016 20:39:55 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OmG3Ha2qoqSd for ; Tue, 15 Nov 2016 20:39:55 -0500 (EST) Received: from dhcp-8c4e.meeting.ietf.org (dhcp-8c4e.meeting.ietf.org [31.133.140.78]) by mail.smeinc.net (Postfix) with ESMTPSA id 1D32B300259 for ; Tue, 15 Nov 2016 20:39:53 -0500 (EST) 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: <897230ED-8D25-49C6-A546-C106FC0C5ACC@vigilsec.com> Date: Tue, 15 Nov 2016 20:40:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <897230ED-8D25-49C6-A546-C106FC0C5ACC@vigilsec.com> To: SPASM X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [Spasm] Need volunteers for minutes and jabber scribe 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, 16 Nov 2016 01:39:58 -0000 > Please let me know if you are willing to take minutes or jabber scribe = for the LAMPS session at IETF 97. Thanks to the volunteers: - Rich Salz agreed to be the jabber scribe, and - Sean Leonard agreed to take minutes. Russ From nobody Wed Nov 16 01:57: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 73225129695; Wed, 16 Nov 2016 01:57:46 -0800 (PST) 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 tyBCiFno8hTc; Wed, 16 Nov 2016 01:57:45 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 67D571296B9; Wed, 16 Nov 2016 01:57:45 -0800 (PST) Received: from dhcp-898b.meeting.ietf.org (unknown [31.133.137.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 77B9522E1FA; Wed, 16 Nov 2016 04:57:43 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: <5bccb0b7-d9b9-db1e-3235-bec35f7112ce@cs.tcd.ie> Date: Wed, 16 Nov 2016 18:57:41 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <28F25680-B482-4C8A-9BC2-5D041D96CF27@seantek.com> References: <5bccb0b7-d9b9-db1e-3235-bec35f7112ce@cs.tcd.ie> To: Stephen Farrell , SPASM X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sec-ads@ietf.org, draft-turner-est-extensions@tools.ietf.org Subject: Re: [Spasm] est-extensions in-scope for LAMPS 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, 16 Nov 2016 09:57:46 -0000 Okay. Hi LAMPS: There was discussion in the LAMPS WG (in the F2F meeting) about making = draft-turner-est-extensions in-scope for LAMPS. I think it should be = pursued through the LAMPS WG, so please consider it. Sean > On Nov 16, 2016, at 6:44 PM, Stephen Farrell = wrote: >=20 >=20 > Hi Sean, >=20 > Sending that to the lamps wg list would be good. >=20 > Cheers, > S >=20 > On 16/11/16 03:07, Sean Leonard wrote: >> There was discussion in the LAMPS WG about making = draft-turner-est-extensions in-scope for LAMPS. I think it should be = pursued through the LAMPS WG, so please consider it. >>=20 >> Regards, >>=20 >> Sean Leonard >>=20 >=20 From nobody Wed Nov 16 23:25:54 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 5A554129467 for ; Wed, 16 Nov 2016 23:25:52 -0800 (PST) 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 bWDy6vuasIgS for ; Wed, 16 Nov 2016 23:25:51 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 58F231279EB for ; Wed, 16 Nov 2016 23:25:50 -0800 (PST) Received: from dhcp-898b.meeting.ietf.org (unknown [31.133.137.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1640722E255; Thu, 17 Nov 2016 02:25:42 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: <004f01d23982$d7f67270$87e35750$@augustcellars.com> Date: Thu, 17 Nov 2016 16:25:39 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <04D96AB7-4A9F-4F87-B2AF-E6626E0AA3AD@seantek.com> References: <147776174688.30589.3759161241757522148.idtracker@ietfa.amsl.com> <3880FAF1-77B5-46DB-B0BA-12DCA726841C@vigilsec.com> <004f01d23982$d7f67270$87e35750$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SPASM , Russ Housley Subject: Re: [Spasm] draft-ietf-lamps-rfc5750-bis-01.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, 17 Nov 2016 07:25:52 -0000 > On Nov 8, 2016, at 2:42 PM, Jim Schaad wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley >> Sent: Monday, November 07, 2016 7:13 AM >> To: SPASM >> Subject: [Spasm] draft-ietf-lamps-rfc5750-bis-01.txt >>=20 >> Section 1.3 includes: >>=20 >> Appendix A contains information about algorithms are were used for >> prior versions of S/MIME but are no longer considered to meet = modern >> security standards. Support of these algorithms may be needed to >> support historic S/MIME messages but SHOULD NOT be used for new = mail. >>=20 >> I think we need to say that the historic algorithms and smaller key = sizes > might be >> needed to decrypt or validate signatures on stored email messages. >=20 > So, expand what it means to "support" historic messages? Yes; I agree with Russ. Support =3D needed to decrypt, or validate = signatures on, stored email messages. Regards, Sean From nobody Fri Nov 18 00:07:54 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 D3B601294AE for ; Fri, 18 Nov 2016 00:07:52 -0800 (PST) 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 LVdt1hQONjI1 for ; Fri, 18 Nov 2016 00:07:51 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7BA512943F for ; Fri, 18 Nov 2016 00:07:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2532A300AD9 for ; Fri, 18 Nov 2016 02:57:34 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7UQ5U16jLu8Y for ; Fri, 18 Nov 2016 02:57:33 -0500 (EST) Received: from [10.35.131.136] (unknown [58.123.138.206]) by mail.smeinc.net (Postfix) with ESMTPSA id 9EB65300429 for ; Fri, 18 Nov 2016 02:57:32 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <23AC28CB-27B0-4FA8-99A4-3B020759007A@vigilsec.com> Date: Fri, 18 Nov 2016 03:07:46 -0500 To: SPASM Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [Spasm] WG Last Call for draft-ietf-lamps-eai-addresses-02 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, 18 Nov 2016 08:07:53 -0000 This is the LAMPS WG Last Call for "Internationalized Email Addresses in = X.509 Certificates=94 . Please = review the document and send your comments to the list by 9 December = 2016.=20 Thanks, Russ= From nobody Mon Nov 21 13:27:01 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 218FC1295E6 for ; Mon, 21 Nov 2016 13:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=redhoundsoftware.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 tv5qEicyf00k for ; Mon, 21 Nov 2016 13:26:57 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 92D3B129BEB for ; Mon, 21 Nov 2016 13:26:57 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id c47so213607962qtc.2 for ; Mon, 21 Nov 2016 13:26:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-transfer-encoding; bh=TkANnpba4ax6qUWoL9sR5J6PA/WAAydokb74LwbTliU=; b=qKwOPMFGd8yCVpurJH/TTwfQTWGhMUNTka69z2pVeS9Dg1cDCxBPMSubGWaNEUgX2+ nXkAKKh24vP8oMcNRJgjdwqMqN7Stb68kVMf8Rz0YdrC30d6u9rzLS+6ysWNjBwtthDz gNfMClfXXiAsZ0Tc73UkOS8UgVQwP8aazj1Uo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-transfer-encoding; bh=TkANnpba4ax6qUWoL9sR5J6PA/WAAydokb74LwbTliU=; b=ih4UN5ih3zbjlcwyY4vi7NPxkw99F1QpT0MAdaXuQ8xp3kzYAgGAxP0CS8P+m4baT6 ubUTpUD9Yhv868GqWUew570luGeerXOS6k6S6PIMIj6/t0C7yX2JO4djGl2lSbShHfPP KFmmRSBOdxSFDaThSpiYSsZS7aYhLSR/1kwfs6NUrismR9qTD/hrInYjy90ZBIJnJ1jE NqaNvGQl8FjQ7GoUzzRhcN6N+9PEglAo+I+eCnMRUUhhAJuze4bdSpiE0jZA5YSakeF1 vghuAguyFtXcXyBzZ+rO5jdxvXhrGElVrlym6eBH5nLC+O0gjhBajkg9X1H/n/6bUsG4 1SCg== X-Gm-Message-State: AKaTC01u7SMSW3EWyjNVwfSzD3gloL5gtqQ1E7p6fQPH983H6wv3XHZZPii4Vh/Lbx9ytw== X-Received: by 10.200.38.50 with SMTP id u47mr11025354qtu.288.1479763616139; Mon, 21 Nov 2016 13:26:56 -0800 (PST) Received: from [192.168.2.27] (pool-96-241-54-192.washdc.fios.verizon.net. [96.241.54.192]) by smtp.googlemail.com with ESMTPSA id q3sm12151451qte.41.2016.11.21.13.26.54 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 21 Nov 2016 13:26:55 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.5.8.151023 Date: Mon, 21 Nov 2016 16:26:50 -0500 From: Carl Wallace To: SPASM Message-ID: Thread-Topic: RFC 6960 CertID hash algorithm mismatches Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [Spasm] RFC 6960 CertID hash algorithm mismatches 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, 21 Nov 2016 21:26:59 -0000 RFC 6960 (and RFC 2560 before it) includes a hash algorithm field in the CertID structure, as shown below. CertID ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of issuer's DN issuerKeyHash OCTET STRING, -- Hash of issuer's public key serialNumber CertificateSerialNumber } However, neither includes any text that compels the responder to use the same hash algorithm in the response as the requestor used in the request. This seems like an oversight. If this is not required, OCSP clients would potentially need to calculate multiple sets of hash values in order to find the status in response. RFC5019 requires clients to use SHA1, but it also requires nothing in terms of requiring responses match the CertID value and places no similar SHA1 requirement on the responder. Simply requiring responders to also use SHA1 seems like the easiest fix. Is this something LAMPS could address with an errata? From nobody Wed Nov 23 12:38:56 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 6C20812A264 for ; Wed, 23 Nov 2016 12:38:55 -0800 (PST) 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 g7eAAWClyKKF for ; Wed, 23 Nov 2016 12:38:54 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34AEC1294BA for ; Wed, 23 Nov 2016 12:38:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 96614300AE0 for ; Wed, 23 Nov 2016 15:28:36 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id k0-nkewXxuh2 for ; Wed, 23 Nov 2016 15:28:35 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id CB7313000D0 for ; Wed, 23 Nov 2016 15:28:35 -0500 (EST) 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: <23AC28CB-27B0-4FA8-99A4-3B020759007A@vigilsec.com> Date: Wed, 23 Nov 2016 15:39:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <23AC28CB-27B0-4FA8-99A4-3B020759007A@vigilsec.com> To: SPASM X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-eai-addresses-02 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, 23 Nov 2016 20:38:55 -0000 I have two WG Last Call comments. (1) Please update the Abstract to indicate that the EAI name can appear = in the SubjectAltName or the IssuerAltName. It already says this in the = Introduction. (2) The IMPORTS portion of the ASN.1 module is incorrect. It needs to = import OTHER-NAME and id-pkix. It should say: IMPORT OTHER-NAME FROM PKIX1Implicit-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) } id-pkix FROM PKIX1Explicit-2009 { iso(1) identified-organization(3) dod(6) internet(1) = security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } ; From nobody Fri Nov 25 00:35: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 A0766129512 for ; Fri, 25 Nov 2016 00:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.399 X-Spam-Level: X-Spam-Status: No, score=-8.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsYFAkh7Mdnt for ; Fri, 25 Nov 2016 00:35:31 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4B921293E1 for ; Fri, 25 Nov 2016 00:35:31 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 63A65C05AA48 for ; Fri, 25 Nov 2016 08:35:31 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.184]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAP8ZTtH026672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 25 Nov 2016 03:35:30 -0500 Message-ID: <1480062929.2875.5.camel@redhat.com> From: Nikos Mavrogiannopoulos To: spasm@ietf.org Date: Fri, 25 Nov 2016 09:35:29 +0100 Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 25 Nov 2016 08:35:31 +0000 (UTC) Archived-At: Subject: [Spasm] IDNA2008 and PKIX certificates 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, 25 Nov 2016 08:35:32 -0000 Hi,  RFC5280 and its update (6818), reference IDNA2003 (rfc3490) for storing internationalized DNS names. However, IDNA2003 is already obsolete standard (it seems it was already deprecated when RFC6818 was published [0]), in practice phased out, and incompatible with IDNA2008. My understanding is that the situation with internationalized names in certificates/https is not at a good state (you are lucky if it works). Is there some plan to update RFC5280 to fix that situation? an example would be to switch to IDNA2008 and to the corresponding ToUnicode operation for the reverse mapping. regards, Nikos PS. Originally posted in PKIX-list and precis groups.