From hotz@jpl.nasa.gov Thu Feb 3 10:19:28 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31CA93A67CC for ; Thu, 3 Feb 2011 10:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOmcyzBLdtxW for ; Thu, 3 Feb 2011 10:19:27 -0800 (PST) Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) by core3.amsl.com (Postfix) with ESMTP id 05E093A67B8 for ; Thu, 3 Feb 2011 10:19:26 -0800 (PST) Received: from dhcp-137-79-177-242.jpl.nasa.gov (dhcp-137-79-177-242.jpl.nasa.gov [137.79.177.242]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id p13IMTKG027844 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Thu, 3 Feb 2011 10:22:49 -0800 From: "Henry B. Hotz" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Feb 2011 10:22:29 -0800 Message-Id: To: pkix Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Source-IP: dhcp-137-79-177-242.jpl.nasa.gov [137.79.177.242] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Subject: [pkix] Guidelines for Need for CRL/OCSP? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 18:19:28 -0000 If your certificates are always issued with really short lifetimes (a = few hours) it makes no sense to incur the deployment overhead of = maintaining CRL/OCSP infrastructure. OTOH if they have lifetimes of a = year or more, it seems foolish not to. Is there any recommended policy covering this? Any recommended = crossover point that could be referenced in another specification? ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From turners@ieca.com Thu Feb 3 10:21:17 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDC833A67C3 for ; Thu, 3 Feb 2011 10:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBtXcjhZAsoe for ; Thu, 3 Feb 2011 10:21:16 -0800 (PST) Received: from nm4-vm0.bullet.mail.ac4.yahoo.com (nm4-vm0.bullet.mail.ac4.yahoo.com [98.139.53.206]) by core3.amsl.com (Postfix) with SMTP id A7F2B3A67A3 for ; Thu, 3 Feb 2011 10:21:16 -0800 (PST) Received: from [98.139.52.196] by nm4.bullet.mail.ac4.yahoo.com with NNFMP; 03 Feb 2011 18:24:37 -0000 Received: from [98.139.52.149] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 03 Feb 2011 18:24:37 -0000 Received: from [127.0.0.1] by omp1032.mail.ac4.yahoo.com with NNFMP; 03 Feb 2011 18:24:37 -0000 X-Yahoo-Newman-Id: 2311.34241.bm@omp1032.mail.ac4.yahoo.com Received: (qmail 47341 invoked from network); 3 Feb 2011 18:24:36 -0000 Received: from thunderfish.local (turners@71.191.2.76 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 03 Feb 2011 10:24:36 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: reeq3V8VM1lj.F23L1R1y_iVJw81cC6H8eCekCtuRZ7DPV1 Y2wyhhXDSbTHH_L88t.Z_uF1PZrtl6lWsXCSNsyVVpKZlsMxAdOcZzfQoZj4 x4N7quQqx14ELe.tp5XAL4OIk2Vvurxeb8MJg13lB5wYwWAn7g6WSLe6m3Dd GSin0UnI9TtOdwMIAOiVS0IiWeuoYo8uEWJfjKDEYYdbVWntXnOIz6j2goOc Mjz4Qq94..sUujrSJ5_mkwJpUWm2vDi3vdA4OJt4MvCm9x6RC7cU97NY8sWF W93.gyBQy5DNEQJeI X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D4AF2E3.6050001@ieca.com> Date: Thu, 03 Feb 2011 13:24:35 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Henry B. Hotz" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix Subject: Re: [pkix] Guidelines for Need for CRL/OCSP? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 18:21:18 -0000 Start using OCSP as soon as your CRL might be bigger than an OCSP response ;) spt On 2/3/11 1:22 PM, Henry B. Hotz wrote: > If your certificates are always issued with really short lifetimes (a few hours) it makes no sense to incur the deployment overhead of maintaining CRL/OCSP infrastructure. OTOH if they have lifetimes of a year or more, it seems foolish not to. > > Is there any recommended policy covering this? Any recommended crossover point that could be referenced in another specification? > ------------------------------------------------------ > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From ppavlenyi@carillon.ca Thu Feb 3 11:04:25 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B6093A6AB8 for ; Thu, 3 Feb 2011 11:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.745 X-Spam-Level: X-Spam-Status: No, score=-0.745 tagged_above=-999 required=5 tests=[AWL=1.854, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0obL9d8z8Fk5 for ; Thu, 3 Feb 2011 11:04:24 -0800 (PST) Received: from mail.carillon.ca (mail.carillon.ca [207.115.107.27]) by core3.amsl.com (Postfix) with ESMTP id DC40B3A6AB7 for ; Thu, 3 Feb 2011 11:04:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.carillon.ca (Postfix) with ESMTP id 5DB13328062 for ; Thu, 3 Feb 2011 14:04:22 -0500 (EST) Received: from mail.carillon.ca ([127.0.0.1]) by localhost (rhea.carillon.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrxBowFbzBJa for ; Thu, 3 Feb 2011 14:04:21 -0500 (EST) Received: from [192.168.6.228] (69-196-152-118.dsl.teksavvy.com [69.196.152.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.carillon.ca (Postfix) with ESMTPSA id 4038332805E for ; Thu, 3 Feb 2011 14:04:21 -0500 (EST) From: Pierre Pavlenyi Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-70-625284062; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 3 Feb 2011 14:07:43 -0500 In-Reply-To: <4D4AF2E3.6050001@ieca.com> To: pkix References: <4D4AF2E3.6050001@ieca.com> Message-Id: <133B3820-DE76-4820-9F4F-C333BD818B83@carillon.ca> X-Mailer: Apple Mail (2.1082) Subject: Re: [pkix] Guidelines for Need for CRL/OCSP? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 19:04:25 -0000 --Apple-Mail-70-625284062 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Henry, There is no "recommended" policy that I am aware of in terms of when you = should or should not use CRLs and/or OCSP. This begs the question: What is(are) your use case(s)? If your Relying Party (RP) never has to see if the certificate has been = revoked, and are happy simply checking the validity and/or perform path = validation, then yes, you don't need to incur the overhead of a CRL/OCSP = infrastructure. Note the "never" part of the previous sentence though. = If you don't have CRL and/or OCSP in your certificate, then the RP can = never check for certificate revocation; they can only check validity and = perform path validation. If anywhere in your use case your RP needs to see if a Certificate has = been revoked, your stuck having to use CRL and/or OCSP. At which point = you have to ask yourself another question: what kind of response is my = RP looking for in terms of making a revocation determination? This will = help you decide if you want CRL and/or OCSP. Nail down your use case(s), and that will lead you down the right path = :-) ----------------------- Pierre Pavlenyi, P.Eng Identity Management Architect ppavlenyi@carillon.ca The opinions expressed here are strictly my own, and do not represent = those of any other party. On 2011-02-03, at 1:24 PM, Sean Turner wrote: > Start using OCSP as soon as your CRL might be bigger than an OCSP = response ;) >=20 > spt >=20 > On 2/3/11 1:22 PM, Henry B. Hotz wrote: >> If your certificates are always issued with really short lifetimes (a = few hours) it makes no sense to incur the deployment overhead of = maintaining CRL/OCSP infrastructure. OTOH if they have lifetimes of a = year or more, it seems foolish not to. >>=20 >> Is there any recommended policy covering this? Any recommended = crossover point that could be referenced in another specification? >> ------------------------------------------------------ >> The opinions expressed in this message are mine, >> not those of Caltech, JPL, NASA, or the US Government. >> Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu >>=20 >>=20 >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >>=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail-70-625284062 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIgzDCCBzsw ggYjoAMCAQICAXkwDQYJKoZIhvcNAQEFBQAwfzELMAkGA1UEBhMCQ0ExKzApBgNVBAoMIkNhcmls bG9uIEluZm9ybWF0aW9uIFNlY3VyaXR5IEluYy4xJDAiBgNVBAsMG0RFTU8gQ2VydGlmaWNhdGlv biBTZXJ2aWNlczEdMBsGA1UEAwwUVEVTVCBSU0EgU2lnbmluZyBDQTEwHhcNMTAwMTA3MTc0NDI0 WhcNMTMwMTA2MTc0NDI0WjByMQswCQYDVQQGEwJDQTErMCkGA1UEChMiQ2FyaWxsb24gSW5mb3Jt YXRpb24gU2VjdXJpdHkgSW5jLjEPMA0GA1UECxMGUGVvcGxlMSUwIwYDVQQDExxQaWVycmUgUGF2 bGVueWkgKEVuY3J5cHRpb24pMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqrz6mD/e ery3kzEQa7OfNtwQmOUfuKyK0H+JZaBCsQuk2QhwmbOAKTaLWOVYxHfX822vzPlLb6grw5kWP4Qt EUuPVSRb8VyfvSh/7M2Q3zTA94FbQVUfnqDnIaeuwBJSYSXN1pr0ZNjy7YScAOQYubgqeXWFRXYz I7uVJ5z/ksfDoZ/3UY1Mxls16OYyfwOQRiEwppQlPX3p7m0QfEZD3LOYBOPWCZ25fYXUyFRWap3M EWcFtwBdU0VbUlYYeNRb7ZXediKyojWHPT23uYRv5f9pjXGNl0NvFyu4gmsFDR9loNIOQt0UcUn5 ObkR525gYgzbTVgBkbG/7deVODaH8wIDAQABo4IDzTCCA8kwCQYDVR0TBAIwADAOBgNVHQ8BAf8E BAMCBDAwEwYDVR0lBAwwCgYIKwYBBQUHAwQwWAYJYIZIAYb4QgENBEsWSURvIE5vdCB0cnVzdCAt IENlcnRpUGF0aCBjb21wbGlhbnQgRW5jcnlwdGlvbiBDZXJ0IGZvciBURVNUIHB1cnBvc2VzIG9u bHkwHQYDVR0OBBYEFKdvSqxsl1qp6eH2QPjYVm14ZVTvMB8GA1UdIwQYMBaAFFnIy6kxRgHbITgP 0W7kIVkyuHvXMCAGA1UdEQQZMBeBFXBwYXZsZW55aUBjYXJpbGxvbi5jYTCCAUkGCCsGAQUFBwEB BIIBOzCCATcwSQYIKwYBBQUHMAKGPWh0dHA6Ly93d3cuY2FyaWxsb24uY2EvY2FvcHMvQ2FyaWxs b24tbWVkaXVtLXRlc3QtYnVuZGxlMS5wN2MwgcAGCCsGAQUFBzAChoGzbGRhcDovL2Rpci5jYXJp bGxvbi5jYS9DTj1URVNUJTIwUlNBJTIwU2lnbmluZyUyMENBMSxPVT1ERU1PJTIwQ2VydGlmaWNh dGlvbiUyMFNlcnZpY2VzLE89Q2FyaWxsb24lMjBJbmZvcm1hdGlvbiUyMFNlY3VyaXR5JTIwSW5j LixDPUNBP2NBQ2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9cGtpQ0EwJwYIKwYB BQUHMAGGG2h0dHA6Ly93d3cuY2FyaWxsb24uY2Evb2NzcDCCAREGA1UdHwSCAQgwggEEMDegNaAz hjFodHRwOi8vd3d3LmNhcmlsbG9uLmNhL2Nhb3BzL3Rlc3Qtc2lnbmNhMS1jcmwuY3JsMIHIoIHF oIHChoG/bGRhcDovL2Rpci5jYXJpbGxvbi5jYS9DTj1URVNUJTIwUlNBJTIwU2lnbmluZyUyMENB MSxPVT1ERU1PJTIwQ2VydGlmaWNhdGlvbiUyMFNlcnZpY2VzLE89Q2FyaWxsb24lMjBJbmZvcm1h dGlvbiUyMFNlY3VyaXR5JTIwSW5jLixDPUNBP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7Ymlu YXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9cGtpQ0EweQYDVR0gBHIwcDBuBgsrBgEEAYHDXgEDZTBfMF0G CCsGAQUFBwICMFEwKRYiQ2FyaWxsb24gSW5mb3JtYXRpb24gU2VjdXJpdHkgSW5jLjADAgEBGiRU RVNUIG1lZGl1bSBzdyBwb2xpY3kgLSBkbyBub3QgdHJ1c3QwDQYJKoZIhvcNAQEFBQADggEBAJj2 zJKttRIiC0dXH2ehcCORTH2TXjAuxnr1qJ85Ya0TUb1MxSLO+FvafMYXgSv+28xd2bUhLPrhDZiQ tTR5K/ls9a8Lch8g6PWNavS9eHn0WzJEDZcGZFHwsude+3tfcTTebRkhozp+l3t8l1UKqF7nFwyp 8XuduDf5mSXyktXjFfw8Q72qclnX8IqhZD5iN9kAH/q0Bmzaws8vJp+39SstjRckAWijV0sZ0XK4 dn7yiiYvPfqsB2oXw76QHxxlctCjBUrN3BcVsPifZK3nN/cBcee3bgppTTVJUcS5InenjUPsBw2k bwokMTS816vVakKHIJ8GExGvK5xbW1pRYHowggdDMIIGK6ADAgECAgF3MA0GCSqGSIb3DQEBBQUA MH8xCzAJBgNVBAYTAkNBMSswKQYDVQQKDCJDYXJpbGxvbiBJbmZvcm1hdGlvbiBTZWN1cml0eSBJ bmMuMSQwIgYDVQQLDBtERU1PIENlcnRpZmljYXRpb24gU2VydmljZXMxHTAbBgNVBAMMFFRFU1Qg UlNBIFNpZ25pbmcgQ0ExMB4XDTEwMDEwNzE3NDQyM1oXDTEzMDEwNjE3NDQyM1owcTELMAkGA1UE BhMCQ0ExKzApBgNVBAoTIkNhcmlsbG9uIEluZm9ybWF0aW9uIFNlY3VyaXR5IEluYy4xDzANBgNV BAsTBlBlb3BsZTEkMCIGA1UEAxMbUGllcnJlIFBhdmxlbnlpIChTaWduYXR1cmUpMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA67bssby2i0HnlgPuw3OHNGgKUHlarJybpVP1otoN1Z1c Q8YrPrBlKllWyvVsahodWsC9IqGQd0jMEWcym9b+N/cgde7A89I4TIS7uqXmPbzMYiUOl1V7sJw2 SiWcljFV/l/ll71vMQ3xQaQ4D1XVaron2YtBtjy+c1Q8CUlnZQ5vnQVngsepFe6XA15WxuvBuMYP U2igOVPFEgV7HwX1X3f4xiqnHGsFA5NUb8uy/rNuYFxQeAylRQQAq7GKLuOYYZCfZokFtFYbymnD dqAzScxMFbuK8rnJOyPJlKPogAdkcTZLwZk/esb2LHJ2SsHNXZr6UlT+FeU35f1AeIBe0wIDAQAB o4ID1jCCA9IwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBsAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMFcGCWCGSAGG+EIBDQRKFkhEbyBOb3QgdHJ1c3QgLSBDZXJ0aVBhdGggY29tcGxp YW50IFNpZ25hdHVyZSBDZXJ0IGZvciBURVNUIHB1cnBvc2VzIG9ubHkwHQYDVR0OBBYEFC/Rg7ER e/OArm2zq2yvB9Tj4c8SMB8GA1UdIwQYMBaAFFnIy6kxRgHbITgP0W7kIVkyuHvXMCAGA1UdEQQZ MBeBFXBwYXZsZW55aUBjYXJpbGxvbi5jYTCCAUkGCCsGAQUFBwEBBIIBOzCCATcwSQYIKwYBBQUH MAKGPWh0dHA6Ly93d3cuY2FyaWxsb24uY2EvY2FvcHMvQ2FyaWxsb24tbWVkaXVtLXRlc3QtYnVu ZGxlMS5wN2MwgcAGCCsGAQUFBzAChoGzbGRhcDovL2Rpci5jYXJpbGxvbi5jYS9DTj1URVNUJTIw UlNBJTIwU2lnbmluZyUyMENBMSxPVT1ERU1PJTIwQ2VydGlmaWNhdGlvbiUyMFNlcnZpY2VzLE89 Q2FyaWxsb24lMjBJbmZvcm1hdGlvbiUyMFNlY3VyaXR5JTIwSW5jLixDPUNBP2NBQ2VydGlmaWNh dGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9cGtpQ0EwJwYIKwYBBQUHMAGGG2h0dHA6Ly93d3cu Y2FyaWxsb24uY2Evb2NzcDCCAREGA1UdHwSCAQgwggEEMDegNaAzhjFodHRwOi8vd3d3LmNhcmls bG9uLmNhL2Nhb3BzL3Rlc3Qtc2lnbmNhMS1jcmwuY3JsMIHIoIHFoIHChoG/bGRhcDovL2Rpci5j YXJpbGxvbi5jYS9DTj1URVNUJTIwUlNBJTIwU2lnbmluZyUyMENBMSxPVT1ERU1PJTIwQ2VydGlm aWNhdGlvbiUyMFNlcnZpY2VzLE89Q2FyaWxsb24lMjBJbmZvcm1hdGlvbiUyMFNlY3VyaXR5JTIw SW5jLixDPUNBP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9cGtpQ0EweQYDVR0gBHIwcDBuBgsrBgEEAYHDXgEDZTBfMF0GCCsGAQUFBwICMFEwKRYiQ2Fy aWxsb24gSW5mb3JtYXRpb24gU2VjdXJpdHkgSW5jLjADAgEBGiRURVNUIG1lZGl1bSBzdyBwb2xp Y3kgLSBkbyBub3QgdHJ1c3QwDQYJKoZIhvcNAQEFBQADggEBAAm+yULMT6dHXE6hI1ljaHB4SJcW Aqz+/tPGYJ0J0u6bueLrYWpvNQZXJubR5GHEaAEx3ljbJB5i1qC4l1urfefNmmm7OFt0sj832WJN ZucKGtYzlE0rVwqmMab4L6PsD+lk0gTE+S+p29E9T7TWfJKgO2ZqJ1bRxB1frVTyJ9cII7e0SYay 6LD1nzWfpgYBoVI5KzudDA3z6YKz6ahc9kk10zhgGfGQXbUJN0JJLjsx3ws2qSEuM3y/YFIFPpyW nMx7gpHWfa60xuw54YON3FieWFMq+yvOsvmNgXDuNhUqnrBn5csZNqSt9eJT6FPU8QqJyEGiINg/ XPTLWW5nZ0IwggkfMIIIB6ADAgECAgEBMA0GCSqGSIb3DQEBBQUAMHwxCzAJBgNVBAYTAkNBMSsw KQYDVQQKEyJDYXJpbGxvbiBJbmZvcm1hdGlvbiBTZWN1cml0eSBJbmMuMSQwIgYDVQQLExtERU1P IENlcnRpZmljYXRpb24gU2VydmljZXMxGjAYBgNVBAMTEVRFU1QgUlNBIFJvb3QgQ0ExMB4XDTA4 MTEwMzE5NTMxMloXDTE4MTEwMTE5NTMxMlowfzELMAkGA1UEBhMCQ0ExKzApBgNVBAoMIkNhcmls bG9uIEluZm9ybWF0aW9uIFNlY3VyaXR5IEluYy4xJDAiBgNVBAsMG0RFTU8gQ2VydGlmaWNhdGlv biBTZXJ2aWNlczEdMBsGA1UEAwwUVEVTVCBSU0EgU2lnbmluZyBDQTEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC7gz9Zx3kkglCnrVugUilhz71Y9jLyrJkj7dysVmpdHOrw3hq4yZ+e WYopiJOdtaMyjN+Rma4VBBuOs3tNPobleoao7zgGub117gGLdKm3BJZiqwD7hqvnpUHmkN6Gpu3D UqrdoLuGZXnNxlUZM/AZSFxXCVFp+gG1E/PH+L0nDB9AZHJrwzOUXmlMXUA/jHjuhtyhfmreiduV T/HcGMYqKItp9iujHYpGqGNY6JRD+t8a1pHIz5c2O/cK0mdltjjmscwnHNpfHdH2ER90eJbW/AAe tiL6qxfFPUcZycdmmJk3t08nRWv13E/Aya3O7vE0njXPbpS1NRIT9EnEknBBAgMBAAGjggWnMIIF ozAdBgNVHQ4EFgQUWcjLqTFGAdshOA/RbuQhWTK4e9cwHwYDVR0jBBgwFoAUPNyRe+0y1rF0WdXs zjmdW6rOnV4wDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAYYwggKABgNVHSAEggJ3MIIC czB0BgsrBgEEAYHDXgEDZjBlMGMGCCsGAQUFBwICMFcwKRoiQ2FyaWxsb24gSW5mb3JtYXRpb24g U2VjdXJpdHkgSW5jLjADAgEBGipURVNUIG1lZGl1bSBoYXJkd2FyZSBwb2xpY3kgLSBkbyBub3Qg dHJ1c3QwbgYLKwYBBAGBw14BA2UwXzBdBggrBgEFBQcCAjBRMCkaIkNhcmlsbG9uIEluZm9ybWF0 aW9uIFNlY3VyaXR5IEluYy4wAwIBARokVEVTVCBtZWRpdW0gc3cgcG9saWN5IC0gZG8gbm90IHRy dXN0MIGNBgsrBgEEAYHDXgECZjB+MHwGCCsGAQUFBwICMHAwKRoiQ2FyaWxsb24gSW5mb3JtYXRp b24gU2VjdXJpdHkgSW5jLjADAgEBGkNURVNUIG1lZGl1bSBIYXJkd2FyZSBDb21tZXJjaWFsIEJl c3QgUHJhY3RpY2UgcG9saWN5IC0gZG8gbm90IHRydXN0MIGNBgsrBgEEAYHDXgECZTB+MHwGCCsG AQUFBwICMHAwKRoiQ2FyaWxsb24gSW5mb3JtYXRpb24gU2VjdXJpdHkgSW5jLjADAgEBGkNURVNU IG1lZGl1bSBTb2Z0d2FyZSBDb21tZXJjaWFsIEJlc3QgUHJhY3RpY2UgcG9saWN5IC0gZG8gbm90 IHRydXN0MGsGCysGAQQBgcNeAQFlMFwwWgYIKwYBBQUHAgIwTjApGiJDYXJpbGxvbiBJbmZvcm1h dGlvbiBTZWN1cml0eSBJbmMuMAMCAQEaIVRFU1QgbG93IHN3IHBvbGljeSAtIGRvIG5vdCB0cnVz dDAMBgNVHSQEBTADgQEAMHsGA1UdHgR0MHKgcDA+pDwwOjELMAkGA1UEBhMCQ0ExKzApBgNVBAoT IkNhcmlsbG9uIEluZm9ybWF0aW9uIFNlY3VyaXR5IEluYy4wDYILY2FyaWxsb24uY2EwEIIOY2Fy aWxsb25pcy5jb20wDYELY2FyaWxsb24uY2EwggEdBggrBgEFBQcBAQSCAQ8wggELMEkGCCsGAQUF BzAChj1odHRwOi8vd3d3LmNhcmlsbG9uLmNhL2Nhb3BzL0NhcmlsbG9uLW1lZGl1bS10ZXN0LWJ1 bmRsZTEucDdjMIG9BggrBgEFBQcwAoaBsGxkYXA6Ly9kaXIuY2FyaWxsb24uY2EvQ049VEVTVCUy MFJTQSUyMFJvb3QlMjBDQTEsT1U9REVNTyUyMENlcnRpZmljYXRpb24lMjBTZXJ2aWNlcyxPPUNh cmlsbG9uJTIwSW5mb3JtYXRpb24lMjBTZWN1cml0eSUyMEluYy4sQz1DQT9jQUNlcnRpZmljYXRl O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPXBraUNBMIIBDgYDVR0fBIIBBTCCAQEwN6A1oDOGMWh0 dHA6Ly93d3cuY2FyaWxsb24uY2EvY2FvcHMvdGVzdC1yb290Y2EyLWFybC5jcmwwgcWggcKggb+G gbxsZGFwOi8vZGlyLmNhcmlsbG9uL2NhL0NOPVRFU1QlMjBSU0ElMjBSb290JTIwQ0ExLE9VPURF TU8lMjBDZXJ0aWZpY2F0aW9uJTIwU2VydmljZXMsTz1DYXJpbGxvbiUyMEluZm9ybWF0aW9uJTIw U2VjdXJpdHklMjBJbmMuLEM9Q0E/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1wa2lDQTANBgkqhkiG9w0BAQUFAAOCAQEAAE3WGvhoGyzp5sy8TDNASdNz VxdQ9eeuPCYeYlh04UyjeluFuG5Cn333dfUSIaU+DcEs/alRpK/ce3o7nbeJyJU8v/8gDNczh7t+ s7T19cWmA7x1veQrQOVV95Xf9eIIS4jjGNl2azF4ATfIMpAYSUYy9yc1h14sI5sDs0J36L6Q+gZq gRLf39w1dNFvj+g0hItT4EzdZ26FVkVUH7EjrBzkf3+C1/ZKXZSRESKFJNVn6BzF6thgricsZcb8 QOgyRO8d+jMMmO55lGcOIy0vUfBhjb6bHaqZAqSSEZRVISzhYclv021n4jOB9cUKQ6ZQUXen8GU4 EKezYUc56OvhRjCCCR8wgggHoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwfDELMAkGA1UEBhMCQ0Ex KzApBgNVBAoTIkNhcmlsbG9uIEluZm9ybWF0aW9uIFNlY3VyaXR5IEluYy4xJDAiBgNVBAsTG0RF TU8gQ2VydGlmaWNhdGlvbiBTZXJ2aWNlczEaMBgGA1UEAxMRVEVTVCBSU0EgUm9vdCBDQTEwHhcN MDgxMTAzMTk1MzEyWhcNMTgxMTAxMTk1MzEyWjB/MQswCQYDVQQGEwJDQTErMCkGA1UECgwiQ2Fy aWxsb24gSW5mb3JtYXRpb24gU2VjdXJpdHkgSW5jLjEkMCIGA1UECwwbREVNTyBDZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzMR0wGwYDVQQDDBRURVNUIFJTQSBTaWduaW5nIENBMTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBALuDP1nHeSSCUKetW6BSKWHPvVj2MvKsmSPt3KxWal0c6vDeGrjJ n55ZiimIk521ozKM35GZrhUEG46ze00+huV6hqjvOAa5vXXuAYt0qbcElmKrAPuGq+elQeaQ3oam 7cNSqt2gu4Zlec3GVRkz8BlIXFcJUWn6AbUT88f4vScMH0BkcmvDM5ReaUxdQD+MeO6G3KF+at6J 25VP8dwYxiooi2n2K6MdikaoY1jolEP63xrWkcjPlzY79wrSZ2W2OOaxzCcc2l8d0fYRH3R4ltb8 AB62IvqrF8U9RxnJx2aYmTe3TydFa/XcT8DJrc7u8TSeNc9ulLU1EhP0ScSScEECAwEAAaOCBacw ggWjMB0GA1UdDgQWBBRZyMupMUYB2yE4D9Fu5CFZMrh71zAfBgNVHSMEGDAWgBQ83JF77TLWsXRZ 1ezOOZ1bqs6dXjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBhjCCAoAGA1UdIASCAncw ggJzMHQGCysGAQQBgcNeAQNmMGUwYwYIKwYBBQUHAgIwVzApGiJDYXJpbGxvbiBJbmZvcm1hdGlv biBTZWN1cml0eSBJbmMuMAMCAQEaKlRFU1QgbWVkaXVtIGhhcmR3YXJlIHBvbGljeSAtIGRvIG5v dCB0cnVzdDBuBgsrBgEEAYHDXgEDZTBfMF0GCCsGAQUFBwICMFEwKRoiQ2FyaWxsb24gSW5mb3Jt YXRpb24gU2VjdXJpdHkgSW5jLjADAgEBGiRURVNUIG1lZGl1bSBzdyBwb2xpY3kgLSBkbyBub3Qg dHJ1c3QwgY0GCysGAQQBgcNeAQJmMH4wfAYIKwYBBQUHAgIwcDApGiJDYXJpbGxvbiBJbmZvcm1h dGlvbiBTZWN1cml0eSBJbmMuMAMCAQEaQ1RFU1QgbWVkaXVtIEhhcmR3YXJlIENvbW1lcmNpYWwg QmVzdCBQcmFjdGljZSBwb2xpY3kgLSBkbyBub3QgdHJ1c3QwgY0GCysGAQQBgcNeAQJlMH4wfAYI KwYBBQUHAgIwcDApGiJDYXJpbGxvbiBJbmZvcm1hdGlvbiBTZWN1cml0eSBJbmMuMAMCAQEaQ1RF U1QgbWVkaXVtIFNvZnR3YXJlIENvbW1lcmNpYWwgQmVzdCBQcmFjdGljZSBwb2xpY3kgLSBkbyBu b3QgdHJ1c3QwawYLKwYBBAGBw14BAWUwXDBaBggrBgEFBQcCAjBOMCkaIkNhcmlsbG9uIEluZm9y bWF0aW9uIFNlY3VyaXR5IEluYy4wAwIBARohVEVTVCBsb3cgc3cgcG9saWN5IC0gZG8gbm90IHRy dXN0MAwGA1UdJAQFMAOBAQAwewYDVR0eBHQwcqBwMD6kPDA6MQswCQYDVQQGEwJDQTErMCkGA1UE ChMiQ2FyaWxsb24gSW5mb3JtYXRpb24gU2VjdXJpdHkgSW5jLjANggtjYXJpbGxvbi5jYTAQgg5j YXJpbGxvbmlzLmNvbTANgQtjYXJpbGxvbi5jYTCCAR0GCCsGAQUFBwEBBIIBDzCCAQswSQYIKwYB BQUHMAKGPWh0dHA6Ly93d3cuY2FyaWxsb24uY2EvY2FvcHMvQ2FyaWxsb24tbWVkaXVtLXRlc3Qt YnVuZGxlMS5wN2Mwgb0GCCsGAQUFBzAChoGwbGRhcDovL2Rpci5jYXJpbGxvbi5jYS9DTj1URVNU JTIwUlNBJTIwUm9vdCUyMENBMSxPVT1ERU1PJTIwQ2VydGlmaWNhdGlvbiUyMFNlcnZpY2VzLE89 Q2FyaWxsb24lMjBJbmZvcm1hdGlvbiUyMFNlY3VyaXR5JTIwSW5jLixDPUNBP2NBQ2VydGlmaWNh dGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9cGtpQ0EwggEOBgNVHR8EggEFMIIBATA3oDWgM4Yx aHR0cDovL3d3dy5jYXJpbGxvbi5jYS9jYW9wcy90ZXN0LXJvb3RjYTItYXJsLmNybDCBxaCBwqCB v4aBvGxkYXA6Ly9kaXIuY2FyaWxsb24vY2EvQ049VEVTVCUyMFJTQSUyMFJvb3QlMjBDQTEsT1U9 REVNTyUyMENlcnRpZmljYXRpb24lMjBTZXJ2aWNlcyxPPUNhcmlsbG9uJTIwSW5mb3JtYXRpb24l MjBTZWN1cml0eSUyMEluYy4sQz1DQT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeT9i YXNlP29iamVjdGNsYXNzPXBraUNBMA0GCSqGSIb3DQEBBQUAA4IBAQAATdYa+GgbLOnmzLxMM0BJ 03NXF1D15648Jh5iWHThTKN6W4W4bkKfffd19RIhpT4NwSz9qVGkr9x7ejudt4nIlTy//yAM1zOH u36ztPX1xaYDvHW95CtA5VX3ld/14ghLiOMY2XZrMXgBN8gykBhJRjL3JzWHXiwjmwOzQnfovpD6 BmqBEt/f3DV00W+P6DSEi1PgTN1nboVWRVQfsSOsHOR/f4LX9kpdlJERIoUk1WfoHMXq2GCuJyxl xvxA6DJE7x36MwyY7nmUZw4jLS9R8GGNvpsdqpkCpJIRlFUhLOFhyW/TbWfiM4H1xQpDplBRd6fw ZTgQp7NhRzno6+FGMYIDPzCCAzsCAQEwgYQwfzELMAkGA1UEBhMCQ0ExKzApBgNVBAoMIkNhcmls bG9uIEluZm9ybWF0aW9uIFNlY3VyaXR5IEluYy4xJDAiBgNVBAsMG0RFTU8gQ2VydGlmaWNhdGlv biBTZXJ2aWNlczEdMBsGA1UEAwwUVEVTVCBSU0EgU2lnbmluZyBDQTECAXcwCQYFKw4DAhoFAKCC AY8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwMjAzMTkwNzQ0 WjAjBgkqhkiG9w0BCQQxFgQUYQstvuus2DvrESFwlvxNz/2iH7UwgZUGCSsGAQQBgjcQBDGBhzCB hDB/MQswCQYDVQQGEwJDQTErMCkGA1UECgwiQ2FyaWxsb24gSW5mb3JtYXRpb24gU2VjdXJpdHkg SW5jLjEkMCIGA1UECwwbREVNTyBDZXJ0aWZpY2F0aW9uIFNlcnZpY2VzMR0wGwYDVQQDDBRURVNU IFJTQSBTaWduaW5nIENBMQIBeTCBlwYLKoZIhvcNAQkQAgsxgYeggYQwfzELMAkGA1UEBhMCQ0Ex KzApBgNVBAoMIkNhcmlsbG9uIEluZm9ybWF0aW9uIFNlY3VyaXR5IEluYy4xJDAiBgNVBAsMG0RF TU8gQ2VydGlmaWNhdGlvbiBTZXJ2aWNlczEdMBsGA1UEAwwUVEVTVCBSU0EgU2lnbmluZyBDQTEC AXkwDQYJKoZIhvcNAQEBBQAEggEAi3y2aSoqw90RPfbDcUH/O8ZouzqVSBR3UsmwFLXC31apcpa8 /+Nsw9z5fXOWdSF5bgSvISLMDy566MQCFaXvU3SsodBiQJpXW/rSGYlos8hSM1ac5MyyIuPBGPmT EkNnsusBKQ8oF/uUaDYaNQ+7eI1J8Iu8Q09pbm6QThTmmRjre5BIkMS4nYu/mf65ULpP1lefX23L v10aIKPi05O43Itvt1/ai5RZtrR52qqxPFQDS+TeC46fmaEF/P87il+1nDnSN1M02pibaKcVwr94 IYQrTCDuOPuKICs6KDYMvT+3ZEsmCU69LRQbQVSRAWHz4+xo/vJjusdSD6dEDvS5lQAAAAAAAA== --Apple-Mail-70-625284062-- From helm@fionn.es.net Thu Feb 3 11:30:53 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E74553A6A30 for ; Thu, 3 Feb 2011 11:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpUa787QVvTP for ; Thu, 3 Feb 2011 11:30:53 -0800 (PST) Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by core3.amsl.com (Postfix) with ESMTP id 2B0713A67B0 for ; Thu, 3 Feb 2011 11:30:53 -0800 (PST) Received: from fionn.es.net (localhost [127.0.0.1]) by fionn.es.net (8.13.7+Sun/8.13.7) with ESMTP id p13JYCn6014710; Thu, 3 Feb 2011 11:34:12 -0800 (PST) Message-Id: <201102031934.p13JYCn6014710@fionn.es.net> To: Pierre Pavlenyi In-reply-to: Your message of "Thu, 03 Feb 2011 14:07:43 EST." <133B3820-DE76-4820-9F4F-C333BD818B83@carillon.ca> Date: Thu, 03 Feb 2011 11:34:12 -0800 From: Mike Helm Cc: pkix Subject: Re: [pkix] Guidelines for Need for CRL/OCSP? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: helm@fionn.es.net List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 19:30:54 -0000 Pierre Pavlenyi writes: > If anywhere in your use case your RP needs to see if a Certificate has = > been revoked, your stuck having to use CRL and/or OCSP. At which point = > Nail down your use case(s), and that will lead you down the right path = > >> If your certificates are always issued with really short lifetimes (a = A lot of the use cases, especially those associated with really short lifetime certificates, are faulty - or circular: the reason the lifetime is short is to avoid CRLs, or at least make them infeasible. Two things have shown up in practice: (1) the short lifetimes are inconvenient, so the the lifetime has inflationary pressure :^) to get longer & longer (2) even if the the lifetime is kept short, you never need CRLs - until the one day when you really, really, wish you had them instead of having to revoke the CA and tell all the RPs to stop working (or take the risk) for a few hours/days until the garbage certificates time out. I personally do not think that any authentication mechanism should be used that lacks a revocation method. I understand there is a cost associated. Regards, ==mwh Michael Helm ESnet/LBNL From hotz@jpl.nasa.gov Thu Feb 3 13:41:47 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED5E3A69EE for ; Thu, 3 Feb 2011 13:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMF6hzbDqogL for ; Thu, 3 Feb 2011 13:41:46 -0800 (PST) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) by core3.amsl.com (Postfix) with ESMTP id DFFB03A69C1 for ; Thu, 3 Feb 2011 13:41:46 -0800 (PST) Received: from dhcp-137-79-177-242.jpl.nasa.gov (dhcp-137-79-177-242.jpl.nasa.gov [137.79.177.242]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id p13Lit1U024967 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Thu, 3 Feb 2011 13:45:02 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <133B3820-DE76-4820-9F4F-C333BD818B83@carillon.ca> Date: Thu, 3 Feb 2011 13:44:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4D7EE79B-FF99-4E22-93E3-680C976D59B8@jpl.nasa.gov> References: <4D4AF2E3.6050001@ieca.com> <133B3820-DE76-4820-9F4F-C333BD818B83@carillon.ca> To: Pierre Pavlenyi X-Mailer: Apple Mail (2.1082) X-Source-IP: dhcp-137-79-177-242.jpl.nasa.gov [137.79.177.242] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: pkix Subject: Re: [pkix] Guidelines for Need for CRL/OCSP? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 21:41:47 -0000 The use case is KX509, which is a protocol for acquiring X.509 client = certs using a Kerberos ticket to prove identity to an automated CA. = These certs are only useful for TLS client authentication, and typically = are issued with the same (short) expiration time as the original = Kerberos ticket. I've had it pointed out that there is nothing inherent to the protocol = which prevents issuing X.509 client certs with a longer lifetime. The = Kerberos is presumably tuned so tickets expire before you could = reasonably grind through the process of revoking an identity. If the = cert lifetime is no longer so restricted, then is there relevant = guidance to reference or repeat? Does that help? On Feb 3, 2011, at 11:07 AM, Pierre Pavlenyi wrote: > Henry, >=20 > There is no "recommended" policy that I am aware of in terms of when = you should or should not use CRLs and/or OCSP. >=20 > This begs the question: What is(are) your use case(s)? >=20 > If your Relying Party (RP) never has to see if the certificate has = been revoked, and are happy simply checking the validity and/or perform = path validation, then yes, you don't need to incur the overhead of a = CRL/OCSP infrastructure. Note the "never" part of the previous sentence = though. If you don't have CRL and/or OCSP in your certificate, then the = RP can never check for certificate revocation; they can only check = validity and perform path validation. >=20 > If anywhere in your use case your RP needs to see if a Certificate has = been revoked, your stuck having to use CRL and/or OCSP. At which point = you have to ask yourself another question: what kind of response is my = RP looking for in terms of making a revocation determination? This will = help you decide if you want CRL and/or OCSP. >=20 > Nail down your use case(s), and that will lead you down the right path = :-) >=20 > ----------------------- > Pierre Pavlenyi, P.Eng > Identity Management Architect > ppavlenyi@carillon.ca >=20 > The opinions expressed here are strictly my own, and do not represent = those of any other party. >=20 >=20 > On 2011-02-03, at 1:24 PM, Sean Turner wrote: >=20 >> Start using OCSP as soon as your CRL might be bigger than an OCSP = response ;) >>=20 >> spt >>=20 >> On 2/3/11 1:22 PM, Henry B. Hotz wrote: >>> If your certificates are always issued with really short lifetimes = (a few hours) it makes no sense to incur the deployment overhead of = maintaining CRL/OCSP infrastructure. OTOH if they have lifetimes of a = year or more, it seems foolish not to. >>>=20 >>> Is there any recommended policy covering this? Any recommended = crossover point that could be referenced in another specification? >>> ------------------------------------------------------ >>> The opinions expressed in this message are mine, >>> not those of Caltech, JPL, NASA, or the US Government. >>> Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From DPKemp@missi.ncsc.mil Thu Feb 3 13:46:28 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB00D3A6A19 for ; Thu, 3 Feb 2011 13:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3hHYUJKdiLO for ; Thu, 3 Feb 2011 13:46:27 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id 86BD23A6998 for ; Thu, 3 Feb 2011 13:46:27 -0800 (PST) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p13LnnHt075486; Thu, 3 Feb 2011 16:49:49 -0500 (EST) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 16:49:05 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 3 Feb 2011 16:49:48 -0500 Message-ID: In-Reply-To: <4D4AF2E3.6050001@ieca.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Guidelines for Need for CRL/OCSP? Thread-Index: AcvDz5KkxH2r3Aq/TH6jvkcc/9tSiQAFn/Yw References: <4D4AF2E3.6050001@ieca.com> From: "Kemp, David P." To: "Sean Turner" , "Henry B. Hotz" X-OriginalArrivalTime: 03 Feb 2011 21:49:05.0562 (UTC) FILETIME=[2DA41FA0:01CBC3EC] Cc: pkix Subject: Re: [pkix] Guidelines for Need for CRL/OCSP? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 21:46:28 -0000 Sean, That doesn't address the question, which was on blacklisting (CRL or OCSP) vs. whitelisting (short lifetime certs). But for the revocation case if you compare apples to apples (same number of certificate statuses returned), a CRL will never be bigger than an OCSP response because OCSP is a much less efficient encoding of the information. Of course, if you build a CRL covering a million certificates and build OCSP responses covering only 20 certificates each, then a single OCSP response will be smaller than a single CRL. But 50,000 20-cert OCSPs are much larger than one 1M-cert CRL, and 50,000 20-cert OCSPs are also much larger than 50,000 20-cert CRLs. The blacklist vs. whitelist question can only be answered by modeling - how many subscribers, how often do they use certs, how many relying parties does a subscriber access, what is the accuracy of the RP clocks, what products do they use, etc. In theory, a CA could sign a renewed certificate with 15 minute validity upon request from either the subscriber or RP. There is no reason for this to be inconvenient except that current CAs, RP applications, and subscriber applications are not designed to operate that way. The bandwidth of sending new certs every 15 minutes will be higher than sending revocation info every 15 minutes, but if subscribers are low-duty-cycle the "ticket" cert approach should be fine if custom software development is not an issue. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Sean Turner Sent: Thursday, February 03, 2011 1:25 PM To: Henry B. Hotz Cc: pkix Subject: Re: [pkix] Guidelines for Need for CRL/OCSP? Start using OCSP as soon as your CRL might be bigger than an OCSP=20 response ;) spt On 2/3/11 1:22 PM, Henry B. Hotz wrote: > If your certificates are always issued with really short lifetimes (a few hours) it makes no sense to incur the deployment overhead of maintaining CRL/OCSP infrastructure. OTOH if they have lifetimes of a year or more, it seems foolish not to. > > Is there any recommended policy covering this? Any recommended crossover point that could be referenced in another specification? > ------------------------------------------------------ > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From DPKemp@missi.ncsc.mil Thu Feb 3 13:54:29 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F2563A6AB2 for ; Thu, 3 Feb 2011 13:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vf-i7-7befSj for ; Thu, 3 Feb 2011 13:54:27 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id 2F8883A6A7F for ; Thu, 3 Feb 2011 13:54:27 -0800 (PST) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p13Lvnwe075661; Thu, 3 Feb 2011 16:57:49 -0500 (EST) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 16:57:04 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 3 Feb 2011 16:57:48 -0500 Message-ID: In-Reply-To: <133B3820-DE76-4820-9F4F-C333BD818B83@carillon.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Guidelines for Need for CRL/OCSP? Thread-Index: AcvD1ZwiQ5b9ji6sRdaLIdJO9arJbgAFsItw References: <4D4AF2E3.6050001@ieca.com> <133B3820-DE76-4820-9F4F-C333BD818B83@carillon.ca> From: "Kemp, David P." To: "Pierre Pavlenyi" , "pkix" X-OriginalArrivalTime: 03 Feb 2011 21:57:04.0843 (UTC) FILETIME=[4B5099B0:01CBC3ED] Subject: Re: [pkix] Guidelines for Need for CRL/OCSP? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 21:54:29 -0000 Pierre, Revocation is a means to an end, not an end in itself. RPs should not have a use case or policy for "checking revocation", they should have a policy for authentication freshness. If the policy is never to authenticate a user based on information more than 24 hours old, that policy can be satisfied either by 1 year certs + 24 hour revocation, or by 24 hour certs with no revocation. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Pierre Pavlenyi Sent: Thursday, February 03, 2011 2:08 PM To: pkix Subject: Re: [pkix] Guidelines for Need for CRL/OCSP? Henry, There is no "recommended" policy that I am aware of in terms of when you should or should not use CRLs and/or OCSP. This begs the question: What is(are) your use case(s)? If your Relying Party (RP) never has to see if the certificate has been revoked, and are happy simply checking the validity and/or perform path validation, then yes, you don't need to incur the overhead of a CRL/OCSP infrastructure. Note the "never" part of the previous sentence though. If you don't have CRL and/or OCSP in your certificate, then the RP can never check for certificate revocation; they can only check validity and perform path validation. If anywhere in your use case your RP needs to see if a Certificate has been revoked, your stuck having to use CRL and/or OCSP. At which point you have to ask yourself another question: what kind of response is my RP looking for in terms of making a revocation determination? This will help you decide if you want CRL and/or OCSP. Nail down your use case(s), and that will lead you down the right path :-) ----------------------- Pierre Pavlenyi, P.Eng Identity Management Architect ppavlenyi@carillon.ca The opinions expressed here are strictly my own, and do not represent those of any other party. On 2011-02-03, at 1:24 PM, Sean Turner wrote: > Start using OCSP as soon as your CRL might be bigger than an OCSP=20 > response ;) >=20 > spt >=20 > On 2/3/11 1:22 PM, Henry B. Hotz wrote: >> If your certificates are always issued with really short lifetimes (a few hours) it makes no sense to incur the deployment overhead of maintaining CRL/OCSP infrastructure. OTOH if they have lifetimes of a year or more, it seems foolish not to. >>=20 >> Is there any recommended policy covering this? Any recommended crossover point that could be referenced in another specification? >> ------------------------------------------------------ >> The opinions expressed in this message are mine, not those of=20 >> Caltech, JPL, NASA, or the US Government. >> Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu >>=20 >>=20 >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >>=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From ppavlenyi@carillon.ca Thu Feb 3 14:31:35 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AA5A3A6B08 for ; Thu, 3 Feb 2011 14:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oNWPcuVPfof for ; Thu, 3 Feb 2011 14:31:34 -0800 (PST) Received: from mail.carillon.ca (mail.carillon.ca [207.115.107.27]) by core3.amsl.com (Postfix) with ESMTP id 8491D3A6A17 for ; Thu, 3 Feb 2011 14:31:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.carillon.ca (Postfix) with ESMTP id 1A0A6328062; Thu, 3 Feb 2011 17:31:32 -0500 (EST) Received: from mail.carillon.ca ([127.0.0.1]) by localhost (rhea.carillon.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jfc6NcvzqyZ5; Thu, 3 Feb 2011 17:31:30 -0500 (EST) Received: from [192.168.6.236] (69-196-152-118.dsl.teksavvy.com [69.196.152.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.carillon.ca (Postfix) with ESMTPSA id 276DC328061; Thu, 3 Feb 2011 17:31:30 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-74-637713454; protocol="application/pkcs7-signature"; micalg=sha1 From: Pierre Pavlenyi In-Reply-To: <4D7EE79B-FF99-4E22-93E3-680C976D59B8@jpl.nasa.gov> Date: Thu, 3 Feb 2011 17:34:53 -0500 Message-Id: References: <4D4AF2E3.6050001@ieca.com> <133B3820-DE76-4820-9F4F-C333BD818B83@carillon.ca> <4D7EE79B-FF99-4E22-93E3-680C976D59B8@jpl.nasa.gov> To: Henry B. Hotz X-Mailer: Apple Mail (2.1082) Cc: pkix Subject: Re: [pkix] Guidelines for Need for CRL/OCSP? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 22:31:35 -0000 --Apple-Mail-74-637713454 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Henry, Again, I have to ask if the TLS server you're authenticating your client = to using the certs in question does revocation checking. If no, then = you don't need to supply a CDP or AIA-OCSP location. If your TLS = servers do revocation check, then I'm afraid you'll have to go with a = CDP or AIA-OCSP location. David Kemp also posted a reply to your original message that could help = you out in terms of spec'ing out a CDP/OCSP infrastructure, should you = need it. As there are many OCSP implementations, you'd have to see how your = particular OCSP product is configured to meet your needs, and how it can = be tweaked. ----------------------- Pierre=20 On 2011-02-03, at 4:44 PM, Henry B. Hotz wrote: > The use case is KX509, which is a protocol for acquiring X.509 client = certs using a Kerberos ticket to prove identity to an automated CA. = These certs are only useful for TLS client authentication, and typically = are issued with the same (short) expiration time as the original = Kerberos ticket. >=20 > I've had it pointed out that there is nothing inherent to the protocol = which prevents issuing X.509 client certs with a longer lifetime. The = Kerberos is presumably tuned so tickets expire before you could = reasonably grind through the process of revoking an identity. If the = cert lifetime is no longer so restricted, then is there relevant = guidance to reference or repeat? >=20 > Does that help? >=20 > On Feb 3, 2011, at 11:07 AM, Pierre Pavlenyi wrote: >=20 >> Henry, >>=20 >> There is no "recommended" policy that I am aware of in terms of when = you should or should not use CRLs and/or OCSP. >>=20 >> This begs the question: What is(are) your use case(s)? >>=20 >> If your Relying Party (RP) never has to see if the certificate has = been revoked, and are happy simply checking the validity and/or perform = path validation, then yes, you don't need to incur the overhead of a = CRL/OCSP infrastructure. Note the "never" part of the previous sentence = though. If you don't have CRL and/or OCSP in your certificate, then the = RP can never check for certificate revocation; they can only check = validity and perform path validation. >>=20 >> If anywhere in your use case your RP needs to see if a Certificate = has been revoked, your stuck having to use CRL and/or OCSP. At which = point you have to ask yourself another question: what kind of response = is my RP looking for in terms of making a revocation determination? = This will help you decide if you want CRL and/or OCSP. >>=20 >> Nail down your use case(s), and that will lead you down the right = path :-) >>=20 >> ----------------------- >> Pierre Pavlenyi, P.Eng >> Identity Management Architect >> ppavlenyi@carillon.ca >>=20 >> The opinions expressed here are strictly my own, and do not represent = those of any other party. >>=20 >>=20 >> On 2011-02-03, at 1:24 PM, Sean Turner wrote: >>=20 >>> Start using OCSP as soon as your CRL might be bigger than an OCSP = response ;) >>>=20 >>> spt >>>=20 >>> On 2/3/11 1:22 PM, Henry B. Hotz wrote: >>>> If your certificates are always issued with really short lifetimes = (a few hours) it makes no sense to incur the deployment overhead of = maintaining CRL/OCSP infrastructure. OTOH if they have lifetimes of a = year or more, it seems foolish not to. >>>>=20 >>>> Is there any recommended policy covering this? Any recommended = crossover point that could be referenced in another specification? >>>> ------------------------------------------------------ >>>> The opinions expressed in this message are mine, >>>> not those of Caltech, JPL, NASA, or the US Government. >>>> Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>>>=20 >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >=20 > ------------------------------------------------------ > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu >=20 >=20 >=20 --Apple-Mail-74-637713454 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIgzDCCBzsw ggYjoAMCAQICAXkwDQYJKoZIhvcNAQEFBQAwfzELMAkGA1UEBhMCQ0ExKzApBgNVBAoMIkNhcmls bG9uIEluZm9ybWF0aW9uIFNlY3VyaXR5IEluYy4xJDAiBgNVBAsMG0RFTU8gQ2VydGlmaWNhdGlv biBTZXJ2aWNlczEdMBsGA1UEAwwUVEVTVCBSU0EgU2lnbmluZyBDQTEwHhcNMTAwMTA3MTc0NDI0 WhcNMTMwMTA2MTc0NDI0WjByMQswCQYDVQQGEwJDQTErMCkGA1UEChMiQ2FyaWxsb24gSW5mb3Jt YXRpb24gU2VjdXJpdHkgSW5jLjEPMA0GA1UECxMGUGVvcGxlMSUwIwYDVQQDExxQaWVycmUgUGF2 bGVueWkgKEVuY3J5cHRpb24pMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqrz6mD/e ery3kzEQa7OfNtwQmOUfuKyK0H+JZaBCsQuk2QhwmbOAKTaLWOVYxHfX822vzPlLb6grw5kWP4Qt EUuPVSRb8VyfvSh/7M2Q3zTA94FbQVUfnqDnIaeuwBJSYSXN1pr0ZNjy7YScAOQYubgqeXWFRXYz I7uVJ5z/ksfDoZ/3UY1Mxls16OYyfwOQRiEwppQlPX3p7m0QfEZD3LOYBOPWCZ25fYXUyFRWap3M EWcFtwBdU0VbUlYYeNRb7ZXediKyojWHPT23uYRv5f9pjXGNl0NvFyu4gmsFDR9loNIOQt0UcUn5 ObkR525gYgzbTVgBkbG/7deVODaH8wIDAQABo4IDzTCCA8kwCQYDVR0TBAIwADAOBgNVHQ8BAf8E BAMCBDAwEwYDVR0lBAwwCgYIKwYBBQUHAwQwWAYJYIZIAYb4QgENBEsWSURvIE5vdCB0cnVzdCAt IENlcnRpUGF0aCBjb21wbGlhbnQgRW5jcnlwdGlvbiBDZXJ0IGZvciBURVNUIHB1cnBvc2VzIG9u bHkwHQYDVR0OBBYEFKdvSqxsl1qp6eH2QPjYVm14ZVTvMB8GA1UdIwQYMBaAFFnIy6kxRgHbITgP 0W7kIVkyuHvXMCAGA1UdEQQZMBeBFXBwYXZsZW55aUBjYXJpbGxvbi5jYTCCAUkGCCsGAQUFBwEB BIIBOzCCATcwSQYIKwYBBQUHMAKGPWh0dHA6Ly93d3cuY2FyaWxsb24uY2EvY2FvcHMvQ2FyaWxs b24tbWVkaXVtLXRlc3QtYnVuZGxlMS5wN2MwgcAGCCsGAQUFBzAChoGzbGRhcDovL2Rpci5jYXJp bGxvbi5jYS9DTj1URVNUJTIwUlNBJTIwU2lnbmluZyUyMENBMSxPVT1ERU1PJTIwQ2VydGlmaWNh dGlvbiUyMFNlcnZpY2VzLE89Q2FyaWxsb24lMjBJbmZvcm1hdGlvbiUyMFNlY3VyaXR5JTIwSW5j LixDPUNBP2NBQ2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9cGtpQ0EwJwYIKwYB BQUHMAGGG2h0dHA6Ly93d3cuY2FyaWxsb24uY2Evb2NzcDCCAREGA1UdHwSCAQgwggEEMDegNaAz hjFodHRwOi8vd3d3LmNhcmlsbG9uLmNhL2Nhb3BzL3Rlc3Qtc2lnbmNhMS1jcmwuY3JsMIHIoIHF oIHChoG/bGRhcDovL2Rpci5jYXJpbGxvbi5jYS9DTj1URVNUJTIwUlNBJTIwU2lnbmluZyUyMENB MSxPVT1ERU1PJTIwQ2VydGlmaWNhdGlvbiUyMFNlcnZpY2VzLE89Q2FyaWxsb24lMjBJbmZvcm1h dGlvbiUyMFNlY3VyaXR5JTIwSW5jLixDPUNBP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7Ymlu YXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9cGtpQ0EweQYDVR0gBHIwcDBuBgsrBgEEAYHDXgEDZTBfMF0G CCsGAQUFBwICMFEwKRYiQ2FyaWxsb24gSW5mb3JtYXRpb24gU2VjdXJpdHkgSW5jLjADAgEBGiRU RVNUIG1lZGl1bSBzdyBwb2xpY3kgLSBkbyBub3QgdHJ1c3QwDQYJKoZIhvcNAQEFBQADggEBAJj2 zJKttRIiC0dXH2ehcCORTH2TXjAuxnr1qJ85Ya0TUb1MxSLO+FvafMYXgSv+28xd2bUhLPrhDZiQ tTR5K/ls9a8Lch8g6PWNavS9eHn0WzJEDZcGZFHwsude+3tfcTTebRkhozp+l3t8l1UKqF7nFwyp 8XuduDf5mSXyktXjFfw8Q72qclnX8IqhZD5iN9kAH/q0Bmzaws8vJp+39SstjRckAWijV0sZ0XK4 dn7yiiYvPfqsB2oXw76QHxxlctCjBUrN3BcVsPifZK3nN/cBcee3bgppTTVJUcS5InenjUPsBw2k bwokMTS816vVakKHIJ8GExGvK5xbW1pRYHowggdDMIIGK6ADAgECAgF3MA0GCSqGSIb3DQEBBQUA MH8xCzAJBgNVBAYTAkNBMSswKQYDVQQKDCJDYXJpbGxvbiBJbmZvcm1hdGlvbiBTZWN1cml0eSBJ bmMuMSQwIgYDVQQLDBtERU1PIENlcnRpZmljYXRpb24gU2VydmljZXMxHTAbBgNVBAMMFFRFU1Qg UlNBIFNpZ25pbmcgQ0ExMB4XDTEwMDEwNzE3NDQyM1oXDTEzMDEwNjE3NDQyM1owcTELMAkGA1UE BhMCQ0ExKzApBgNVBAoTIkNhcmlsbG9uIEluZm9ybWF0aW9uIFNlY3VyaXR5IEluYy4xDzANBgNV BAsTBlBlb3BsZTEkMCIGA1UEAxMbUGllcnJlIFBhdmxlbnlpIChTaWduYXR1cmUpMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA67bssby2i0HnlgPuw3OHNGgKUHlarJybpVP1otoN1Z1c Q8YrPrBlKllWyvVsahodWsC9IqGQd0jMEWcym9b+N/cgde7A89I4TIS7uqXmPbzMYiUOl1V7sJw2 SiWcljFV/l/ll71vMQ3xQaQ4D1XVaron2YtBtjy+c1Q8CUlnZQ5vnQVngsepFe6XA15WxuvBuMYP U2igOVPFEgV7HwX1X3f4xiqnHGsFA5NUb8uy/rNuYFxQeAylRQQAq7GKLuOYYZCfZokFtFYbymnD dqAzScxMFbuK8rnJOyPJlKPogAdkcTZLwZk/esb2LHJ2SsHNXZr6UlT+FeU35f1AeIBe0wIDAQAB o4ID1jCCA9IwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBsAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMFcGCWCGSAGG+EIBDQRKFkhEbyBOb3QgdHJ1c3QgLSBDZXJ0aVBhdGggY29tcGxp YW50IFNpZ25hdHVyZSBDZXJ0IGZvciBURVNUIHB1cnBvc2VzIG9ubHkwHQYDVR0OBBYEFC/Rg7ER e/OArm2zq2yvB9Tj4c8SMB8GA1UdIwQYMBaAFFnIy6kxRgHbITgP0W7kIVkyuHvXMCAGA1UdEQQZ MBeBFXBwYXZsZW55aUBjYXJpbGxvbi5jYTCCAUkGCCsGAQUFBwEBBIIBOzCCATcwSQYIKwYBBQUH MAKGPWh0dHA6Ly93d3cuY2FyaWxsb24uY2EvY2FvcHMvQ2FyaWxsb24tbWVkaXVtLXRlc3QtYnVu ZGxlMS5wN2MwgcAGCCsGAQUFBzAChoGzbGRhcDovL2Rpci5jYXJpbGxvbi5jYS9DTj1URVNUJTIw UlNBJTIwU2lnbmluZyUyMENBMSxPVT1ERU1PJTIwQ2VydGlmaWNhdGlvbiUyMFNlcnZpY2VzLE89 Q2FyaWxsb24lMjBJbmZvcm1hdGlvbiUyMFNlY3VyaXR5JTIwSW5jLixDPUNBP2NBQ2VydGlmaWNh dGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9cGtpQ0EwJwYIKwYBBQUHMAGGG2h0dHA6Ly93d3cu Y2FyaWxsb24uY2Evb2NzcDCCAREGA1UdHwSCAQgwggEEMDegNaAzhjFodHRwOi8vd3d3LmNhcmls bG9uLmNhL2Nhb3BzL3Rlc3Qtc2lnbmNhMS1jcmwuY3JsMIHIoIHFoIHChoG/bGRhcDovL2Rpci5j YXJpbGxvbi5jYS9DTj1URVNUJTIwUlNBJTIwU2lnbmluZyUyMENBMSxPVT1ERU1PJTIwQ2VydGlm aWNhdGlvbiUyMFNlcnZpY2VzLE89Q2FyaWxsb24lMjBJbmZvcm1hdGlvbiUyMFNlY3VyaXR5JTIw SW5jLixDPUNBP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9cGtpQ0EweQYDVR0gBHIwcDBuBgsrBgEEAYHDXgEDZTBfMF0GCCsGAQUFBwICMFEwKRYiQ2Fy aWxsb24gSW5mb3JtYXRpb24gU2VjdXJpdHkgSW5jLjADAgEBGiRURVNUIG1lZGl1bSBzdyBwb2xp Y3kgLSBkbyBub3QgdHJ1c3QwDQYJKoZIhvcNAQEFBQADggEBAAm+yULMT6dHXE6hI1ljaHB4SJcW Aqz+/tPGYJ0J0u6bueLrYWpvNQZXJubR5GHEaAEx3ljbJB5i1qC4l1urfefNmmm7OFt0sj832WJN ZucKGtYzlE0rVwqmMab4L6PsD+lk0gTE+S+p29E9T7TWfJKgO2ZqJ1bRxB1frVTyJ9cII7e0SYay 6LD1nzWfpgYBoVI5KzudDA3z6YKz6ahc9kk10zhgGfGQXbUJN0JJLjsx3ws2qSEuM3y/YFIFPpyW nMx7gpHWfa60xuw54YON3FieWFMq+yvOsvmNgXDuNhUqnrBn5csZNqSt9eJT6FPU8QqJyEGiINg/ XPTLWW5nZ0IwggkfMIIIB6ADAgECAgEBMA0GCSqGSIb3DQEBBQUAMHwxCzAJBgNVBAYTAkNBMSsw KQYDVQQKEyJDYXJpbGxvbiBJbmZvcm1hdGlvbiBTZWN1cml0eSBJbmMuMSQwIgYDVQQLExtERU1P IENlcnRpZmljYXRpb24gU2VydmljZXMxGjAYBgNVBAMTEVRFU1QgUlNBIFJvb3QgQ0ExMB4XDTA4 MTEwMzE5NTMxMloXDTE4MTEwMTE5NTMxMlowfzELMAkGA1UEBhMCQ0ExKzApBgNVBAoMIkNhcmls bG9uIEluZm9ybWF0aW9uIFNlY3VyaXR5IEluYy4xJDAiBgNVBAsMG0RFTU8gQ2VydGlmaWNhdGlv biBTZXJ2aWNlczEdMBsGA1UEAwwUVEVTVCBSU0EgU2lnbmluZyBDQTEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC7gz9Zx3kkglCnrVugUilhz71Y9jLyrJkj7dysVmpdHOrw3hq4yZ+e WYopiJOdtaMyjN+Rma4VBBuOs3tNPobleoao7zgGub117gGLdKm3BJZiqwD7hqvnpUHmkN6Gpu3D UqrdoLuGZXnNxlUZM/AZSFxXCVFp+gG1E/PH+L0nDB9AZHJrwzOUXmlMXUA/jHjuhtyhfmreiduV T/HcGMYqKItp9iujHYpGqGNY6JRD+t8a1pHIz5c2O/cK0mdltjjmscwnHNpfHdH2ER90eJbW/AAe tiL6qxfFPUcZycdmmJk3t08nRWv13E/Aya3O7vE0njXPbpS1NRIT9EnEknBBAgMBAAGjggWnMIIF ozAdBgNVHQ4EFgQUWcjLqTFGAdshOA/RbuQhWTK4e9cwHwYDVR0jBBgwFoAUPNyRe+0y1rF0WdXs zjmdW6rOnV4wDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAYYwggKABgNVHSAEggJ3MIIC czB0BgsrBgEEAYHDXgEDZjBlMGMGCCsGAQUFBwICMFcwKRoiQ2FyaWxsb24gSW5mb3JtYXRpb24g U2VjdXJpdHkgSW5jLjADAgEBGipURVNUIG1lZGl1bSBoYXJkd2FyZSBwb2xpY3kgLSBkbyBub3Qg dHJ1c3QwbgYLKwYBBAGBw14BA2UwXzBdBggrBgEFBQcCAjBRMCkaIkNhcmlsbG9uIEluZm9ybWF0 aW9uIFNlY3VyaXR5IEluYy4wAwIBARokVEVTVCBtZWRpdW0gc3cgcG9saWN5IC0gZG8gbm90IHRy dXN0MIGNBgsrBgEEAYHDXgECZjB+MHwGCCsGAQUFBwICMHAwKRoiQ2FyaWxsb24gSW5mb3JtYXRp b24gU2VjdXJpdHkgSW5jLjADAgEBGkNURVNUIG1lZGl1bSBIYXJkd2FyZSBDb21tZXJjaWFsIEJl c3QgUHJhY3RpY2UgcG9saWN5IC0gZG8gbm90IHRydXN0MIGNBgsrBgEEAYHDXgECZTB+MHwGCCsG AQUFBwICMHAwKRoiQ2FyaWxsb24gSW5mb3JtYXRpb24gU2VjdXJpdHkgSW5jLjADAgEBGkNURVNU IG1lZGl1bSBTb2Z0d2FyZSBDb21tZXJjaWFsIEJlc3QgUHJhY3RpY2UgcG9saWN5IC0gZG8gbm90 IHRydXN0MGsGCysGAQQBgcNeAQFlMFwwWgYIKwYBBQUHAgIwTjApGiJDYXJpbGxvbiBJbmZvcm1h dGlvbiBTZWN1cml0eSBJbmMuMAMCAQEaIVRFU1QgbG93IHN3IHBvbGljeSAtIGRvIG5vdCB0cnVz dDAMBgNVHSQEBTADgQEAMHsGA1UdHgR0MHKgcDA+pDwwOjELMAkGA1UEBhMCQ0ExKzApBgNVBAoT IkNhcmlsbG9uIEluZm9ybWF0aW9uIFNlY3VyaXR5IEluYy4wDYILY2FyaWxsb24uY2EwEIIOY2Fy aWxsb25pcy5jb20wDYELY2FyaWxsb24uY2EwggEdBggrBgEFBQcBAQSCAQ8wggELMEkGCCsGAQUF BzAChj1odHRwOi8vd3d3LmNhcmlsbG9uLmNhL2Nhb3BzL0NhcmlsbG9uLW1lZGl1bS10ZXN0LWJ1 bmRsZTEucDdjMIG9BggrBgEFBQcwAoaBsGxkYXA6Ly9kaXIuY2FyaWxsb24uY2EvQ049VEVTVCUy MFJTQSUyMFJvb3QlMjBDQTEsT1U9REVNTyUyMENlcnRpZmljYXRpb24lMjBTZXJ2aWNlcyxPPUNh cmlsbG9uJTIwSW5mb3JtYXRpb24lMjBTZWN1cml0eSUyMEluYy4sQz1DQT9jQUNlcnRpZmljYXRl O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPXBraUNBMIIBDgYDVR0fBIIBBTCCAQEwN6A1oDOGMWh0 dHA6Ly93d3cuY2FyaWxsb24uY2EvY2FvcHMvdGVzdC1yb290Y2EyLWFybC5jcmwwgcWggcKggb+G gbxsZGFwOi8vZGlyLmNhcmlsbG9uL2NhL0NOPVRFU1QlMjBSU0ElMjBSb290JTIwQ0ExLE9VPURF TU8lMjBDZXJ0aWZpY2F0aW9uJTIwU2VydmljZXMsTz1DYXJpbGxvbiUyMEluZm9ybWF0aW9uJTIw U2VjdXJpdHklMjBJbmMuLEM9Q0E/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1wa2lDQTANBgkqhkiG9w0BAQUFAAOCAQEAAE3WGvhoGyzp5sy8TDNASdNz VxdQ9eeuPCYeYlh04UyjeluFuG5Cn333dfUSIaU+DcEs/alRpK/ce3o7nbeJyJU8v/8gDNczh7t+ s7T19cWmA7x1veQrQOVV95Xf9eIIS4jjGNl2azF4ATfIMpAYSUYy9yc1h14sI5sDs0J36L6Q+gZq gRLf39w1dNFvj+g0hItT4EzdZ26FVkVUH7EjrBzkf3+C1/ZKXZSRESKFJNVn6BzF6thgricsZcb8 QOgyRO8d+jMMmO55lGcOIy0vUfBhjb6bHaqZAqSSEZRVISzhYclv021n4jOB9cUKQ6ZQUXen8GU4 EKezYUc56OvhRjCCCR8wgggHoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwfDELMAkGA1UEBhMCQ0Ex KzApBgNVBAoTIkNhcmlsbG9uIEluZm9ybWF0aW9uIFNlY3VyaXR5IEluYy4xJDAiBgNVBAsTG0RF TU8gQ2VydGlmaWNhdGlvbiBTZXJ2aWNlczEaMBgGA1UEAxMRVEVTVCBSU0EgUm9vdCBDQTEwHhcN MDgxMTAzMTk1MzEyWhcNMTgxMTAxMTk1MzEyWjB/MQswCQYDVQQGEwJDQTErMCkGA1UECgwiQ2Fy aWxsb24gSW5mb3JtYXRpb24gU2VjdXJpdHkgSW5jLjEkMCIGA1UECwwbREVNTyBDZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzMR0wGwYDVQQDDBRURVNUIFJTQSBTaWduaW5nIENBMTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBALuDP1nHeSSCUKetW6BSKWHPvVj2MvKsmSPt3KxWal0c6vDeGrjJ n55ZiimIk521ozKM35GZrhUEG46ze00+huV6hqjvOAa5vXXuAYt0qbcElmKrAPuGq+elQeaQ3oam 7cNSqt2gu4Zlec3GVRkz8BlIXFcJUWn6AbUT88f4vScMH0BkcmvDM5ReaUxdQD+MeO6G3KF+at6J 25VP8dwYxiooi2n2K6MdikaoY1jolEP63xrWkcjPlzY79wrSZ2W2OOaxzCcc2l8d0fYRH3R4ltb8 AB62IvqrF8U9RxnJx2aYmTe3TydFa/XcT8DJrc7u8TSeNc9ulLU1EhP0ScSScEECAwEAAaOCBacw ggWjMB0GA1UdDgQWBBRZyMupMUYB2yE4D9Fu5CFZMrh71zAfBgNVHSMEGDAWgBQ83JF77TLWsXRZ 1ezOOZ1bqs6dXjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBhjCCAoAGA1UdIASCAncw ggJzMHQGCysGAQQBgcNeAQNmMGUwYwYIKwYBBQUHAgIwVzApGiJDYXJpbGxvbiBJbmZvcm1hdGlv biBTZWN1cml0eSBJbmMuMAMCAQEaKlRFU1QgbWVkaXVtIGhhcmR3YXJlIHBvbGljeSAtIGRvIG5v dCB0cnVzdDBuBgsrBgEEAYHDXgEDZTBfMF0GCCsGAQUFBwICMFEwKRoiQ2FyaWxsb24gSW5mb3Jt YXRpb24gU2VjdXJpdHkgSW5jLjADAgEBGiRURVNUIG1lZGl1bSBzdyBwb2xpY3kgLSBkbyBub3Qg dHJ1c3QwgY0GCysGAQQBgcNeAQJmMH4wfAYIKwYBBQUHAgIwcDApGiJDYXJpbGxvbiBJbmZvcm1h dGlvbiBTZWN1cml0eSBJbmMuMAMCAQEaQ1RFU1QgbWVkaXVtIEhhcmR3YXJlIENvbW1lcmNpYWwg QmVzdCBQcmFjdGljZSBwb2xpY3kgLSBkbyBub3QgdHJ1c3QwgY0GCysGAQQBgcNeAQJlMH4wfAYI KwYBBQUHAgIwcDApGiJDYXJpbGxvbiBJbmZvcm1hdGlvbiBTZWN1cml0eSBJbmMuMAMCAQEaQ1RF U1QgbWVkaXVtIFNvZnR3YXJlIENvbW1lcmNpYWwgQmVzdCBQcmFjdGljZSBwb2xpY3kgLSBkbyBu b3QgdHJ1c3QwawYLKwYBBAGBw14BAWUwXDBaBggrBgEFBQcCAjBOMCkaIkNhcmlsbG9uIEluZm9y bWF0aW9uIFNlY3VyaXR5IEluYy4wAwIBARohVEVTVCBsb3cgc3cgcG9saWN5IC0gZG8gbm90IHRy dXN0MAwGA1UdJAQFMAOBAQAwewYDVR0eBHQwcqBwMD6kPDA6MQswCQYDVQQGEwJDQTErMCkGA1UE ChMiQ2FyaWxsb24gSW5mb3JtYXRpb24gU2VjdXJpdHkgSW5jLjANggtjYXJpbGxvbi5jYTAQgg5j YXJpbGxvbmlzLmNvbTANgQtjYXJpbGxvbi5jYTCCAR0GCCsGAQUFBwEBBIIBDzCCAQswSQYIKwYB BQUHMAKGPWh0dHA6Ly93d3cuY2FyaWxsb24uY2EvY2FvcHMvQ2FyaWxsb24tbWVkaXVtLXRlc3Qt YnVuZGxlMS5wN2Mwgb0GCCsGAQUFBzAChoGwbGRhcDovL2Rpci5jYXJpbGxvbi5jYS9DTj1URVNU JTIwUlNBJTIwUm9vdCUyMENBMSxPVT1ERU1PJTIwQ2VydGlmaWNhdGlvbiUyMFNlcnZpY2VzLE89 Q2FyaWxsb24lMjBJbmZvcm1hdGlvbiUyMFNlY3VyaXR5JTIwSW5jLixDPUNBP2NBQ2VydGlmaWNh dGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9cGtpQ0EwggEOBgNVHR8EggEFMIIBATA3oDWgM4Yx aHR0cDovL3d3dy5jYXJpbGxvbi5jYS9jYW9wcy90ZXN0LXJvb3RjYTItYXJsLmNybDCBxaCBwqCB v4aBvGxkYXA6Ly9kaXIuY2FyaWxsb24vY2EvQ049VEVTVCUyMFJTQSUyMFJvb3QlMjBDQTEsT1U9 REVNTyUyMENlcnRpZmljYXRpb24lMjBTZXJ2aWNlcyxPPUNhcmlsbG9uJTIwSW5mb3JtYXRpb24l MjBTZWN1cml0eSUyMEluYy4sQz1DQT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeT9i YXNlP29iamVjdGNsYXNzPXBraUNBMA0GCSqGSIb3DQEBBQUAA4IBAQAATdYa+GgbLOnmzLxMM0BJ 03NXF1D15648Jh5iWHThTKN6W4W4bkKfffd19RIhpT4NwSz9qVGkr9x7ejudt4nIlTy//yAM1zOH u36ztPX1xaYDvHW95CtA5VX3ld/14ghLiOMY2XZrMXgBN8gykBhJRjL3JzWHXiwjmwOzQnfovpD6 BmqBEt/f3DV00W+P6DSEi1PgTN1nboVWRVQfsSOsHOR/f4LX9kpdlJERIoUk1WfoHMXq2GCuJyxl xvxA6DJE7x36MwyY7nmUZw4jLS9R8GGNvpsdqpkCpJIRlFUhLOFhyW/TbWfiM4H1xQpDplBRd6fw ZTgQp7NhRzno6+FGMYIDPzCCAzsCAQEwgYQwfzELMAkGA1UEBhMCQ0ExKzApBgNVBAoMIkNhcmls bG9uIEluZm9ybWF0aW9uIFNlY3VyaXR5IEluYy4xJDAiBgNVBAsMG0RFTU8gQ2VydGlmaWNhdGlv biBTZXJ2aWNlczEdMBsGA1UEAwwUVEVTVCBSU0EgU2lnbmluZyBDQTECAXcwCQYFKw4DAhoFAKCC AY8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwMjAzMjIzNDUz WjAjBgkqhkiG9w0BCQQxFgQUv8JQJE8ar9HztIiIeoATsAjCL4YwgZUGCSsGAQQBgjcQBDGBhzCB hDB/MQswCQYDVQQGEwJDQTErMCkGA1UECgwiQ2FyaWxsb24gSW5mb3JtYXRpb24gU2VjdXJpdHkg SW5jLjEkMCIGA1UECwwbREVNTyBDZXJ0aWZpY2F0aW9uIFNlcnZpY2VzMR0wGwYDVQQDDBRURVNU IFJTQSBTaWduaW5nIENBMQIBeTCBlwYLKoZIhvcNAQkQAgsxgYeggYQwfzELMAkGA1UEBhMCQ0Ex KzApBgNVBAoMIkNhcmlsbG9uIEluZm9ybWF0aW9uIFNlY3VyaXR5IEluYy4xJDAiBgNVBAsMG0RF TU8gQ2VydGlmaWNhdGlvbiBTZXJ2aWNlczEdMBsGA1UEAwwUVEVTVCBSU0EgU2lnbmluZyBDQTEC AXkwDQYJKoZIhvcNAQEBBQAEggEA6chK/y0/kTH30tbE4JVSwBF6GR/b5vxcwlOSZbNIXHB3OlsS afvTFLQK0E6rdtaRt4sskR9ZJAF1Je5DKOOq9KiXLRQF3QlcndWpZ0KwWJBWPnx3RhfW62VyXD6a 4/9fOSYrL2bmvOvLM0WU3kmv2dAKvRVLuXeWkSjW+eP9k5q0DUHDXlnhR6QQQt0SlqzmHE0o4K4r DwYRVeb/zbEeDQDQdlr8gcrHPnzgTuxj4AQPIUlLArmDvg1LiM1k26l/Ji9T+Ovs4AWGTfG4jWL9 QzlDimEVXdGdyD0TKvojLL219/UhLpU2g5FObCztnnQfVtApUt4R5kLmiTDZrjCEzgAAAAAAAA== --Apple-Mail-74-637713454-- From ppavlenyi@carillon.ca Thu Feb 3 14:33:14 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35343A6B2D for ; Thu, 3 Feb 2011 14:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[AWL=0.718, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgmuZCyn0IXl for ; Thu, 3 Feb 2011 14:33:13 -0800 (PST) Received: from mail.carillon.ca (mail.carillon.ca [207.115.107.27]) by core3.amsl.com (Postfix) with ESMTP id 945303A6B21 for ; Thu, 3 Feb 2011 14:33:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.carillon.ca (Postfix) with ESMTP id 4B895328062; Thu, 3 Feb 2011 17:33:12 -0500 (EST) Received: from mail.carillon.ca ([127.0.0.1]) by localhost (rhea.carillon.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNAoCSOOJ59l; Thu, 3 Feb 2011 17:33:11 -0500 (EST) Received: from [192.168.6.236] (69-196-152-118.dsl.teksavvy.com [69.196.152.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.carillon.ca (Postfix) with ESMTPSA id 5DFC232805E; Thu, 3 Feb 2011 17:33:11 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-75-637815016; protocol="application/pkcs7-signature"; micalg=sha1 From: Pierre Pavlenyi In-Reply-To: Date: Thu, 3 Feb 2011 17:36:34 -0500 Message-Id: <1599FA0C-DADF-43CD-AA03-EBC0B53BBB1E@carillon.ca> References: <4D4AF2E3.6050001@ieca.com> <133B3820-DE76-4820-9F4F-C333BD818B83@carillon.ca> To: "Kemp, David P." X-Mailer: Apple Mail (2.1082) Cc: pkix Subject: Re: [pkix] Guidelines for Need for CRL/OCSP? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 22:33:14 -0000 --Apple-Mail-75-637815016 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii David, Yes, very true. Essentially just another way to specify what your use = case is, and fit your certificate profile to that use case :-) ----------------------- Pierre Pavlenyi, P.Eng Identity Management Architect ppavlenyi@carillon.ca 514-638-8522 On 2011-02-03, at 4:57 PM, Kemp, David P. wrote: > Pierre, >=20 > Revocation is a means to an end, not an end in itself. >=20 > RPs should not have a use case or policy for "checking revocation", = they > should have a policy for authentication freshness. If the policy is > never to authenticate a user based on information more than 24 hours > old, that policy can be satisfied either by 1 year certs + 24 hour > revocation, or by 24 hour certs with no revocation. >=20 > Dave >=20 >=20 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of > Pierre Pavlenyi > Sent: Thursday, February 03, 2011 2:08 PM > To: pkix > Subject: Re: [pkix] Guidelines for Need for CRL/OCSP? >=20 > Henry, >=20 > There is no "recommended" policy that I am aware of in terms of when = you > should or should not use CRLs and/or OCSP. >=20 > This begs the question: What is(are) your use case(s)? >=20 > If your Relying Party (RP) never has to see if the certificate has = been > revoked, and are happy simply checking the validity and/or perform = path > validation, then yes, you don't need to incur the overhead of a = CRL/OCSP > infrastructure. Note the "never" part of the previous sentence = though. > If you don't have CRL and/or OCSP in your certificate, then the RP can > never check for certificate revocation; they can only check validity = and > perform path validation. >=20 > If anywhere in your use case your RP needs to see if a Certificate has > been revoked, your stuck having to use CRL and/or OCSP. At which = point > you have to ask yourself another question: what kind of response is = my > RP looking for in terms of making a revocation determination? This = will > help you decide if you want CRL and/or OCSP. >=20 > Nail down your use case(s), and that will lead you down the right path > :-) >=20 > ----------------------- > Pierre Pavlenyi, P.Eng > Identity Management Architect > ppavlenyi@carillon.ca >=20 > The opinions expressed here are strictly my own, and do not represent > those of any other party. >=20 >=20 > On 2011-02-03, at 1:24 PM, Sean Turner wrote: >=20 >> Start using OCSP as soon as your CRL might be bigger than an OCSP=20 >> response ;) >>=20 >> spt >>=20 >> On 2/3/11 1:22 PM, Henry B. Hotz wrote: >>> If your certificates are always issued with really short lifetimes = (a > few hours) it makes no sense to incur the deployment overhead of > maintaining CRL/OCSP infrastructure. OTOH if they have lifetimes of a > year or more, it seems foolish not to. >>>=20 >>> Is there any recommended policy covering this? Any recommended > crossover point that could be referenced in another specification? >>> ------------------------------------------------------ >>> The opinions expressed in this message are mine, not those of=20 >>> Caltech, JPL, NASA, or the US Government. >>> Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >=20 --Apple-Mail-75-637815016 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIgzDCCBzsw ggYjoAMCAQICAXkwDQYJKoZIhvcNAQEFBQAwfzELMAkGA1UEBhMCQ0ExKzApBgNVBAoMIkNhcmls bG9uIEluZm9ybWF0aW9uIFNlY3VyaXR5IEluYy4xJDAiBgNVBAsMG0RFTU8gQ2VydGlmaWNhdGlv biBTZXJ2aWNlczEdMBsGA1UEAwwUVEVTVCBSU0EgU2lnbmluZyBDQTEwHhcNMTAwMTA3MTc0NDI0 WhcNMTMwMTA2MTc0NDI0WjByMQswCQYDVQQGEwJDQTErMCkGA1UEChMiQ2FyaWxsb24gSW5mb3Jt YXRpb24gU2VjdXJpdHkgSW5jLjEPMA0GA1UECxMGUGVvcGxlMSUwIwYDVQQDExxQaWVycmUgUGF2 bGVueWkgKEVuY3J5cHRpb24pMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqrz6mD/e ery3kzEQa7OfNtwQmOUfuKyK0H+JZaBCsQuk2QhwmbOAKTaLWOVYxHfX822vzPlLb6grw5kWP4Qt EUuPVSRb8VyfvSh/7M2Q3zTA94FbQVUfnqDnIaeuwBJSYSXN1pr0ZNjy7YScAOQYubgqeXWFRXYz I7uVJ5z/ksfDoZ/3UY1Mxls16OYyfwOQRiEwppQlPX3p7m0QfEZD3LOYBOPWCZ25fYXUyFRWap3M EWcFtwBdU0VbUlYYeNRb7ZXediKyojWHPT23uYRv5f9pjXGNl0NvFyu4gmsFDR9loNIOQt0UcUn5 ObkR525gYgzbTVgBkbG/7deVODaH8wIDAQABo4IDzTCCA8kwCQYDVR0TBAIwADAOBgNVHQ8BAf8E BAMCBDAwEwYDVR0lBAwwCgYIKwYBBQUHAwQwWAYJYIZIAYb4QgENBEsWSURvIE5vdCB0cnVzdCAt IENlcnRpUGF0aCBjb21wbGlhbnQgRW5jcnlwdGlvbiBDZXJ0IGZvciBURVNUIHB1cnBvc2VzIG9u bHkwHQYDVR0OBBYEFKdvSqxsl1qp6eH2QPjYVm14ZVTvMB8GA1UdIwQYMBaAFFnIy6kxRgHbITgP 0W7kIVkyuHvXMCAGA1UdEQQZMBeBFXBwYXZsZW55aUBjYXJpbGxvbi5jYTCCAUkGCCsGAQUFBwEB BIIBOzCCATcwSQYIKwYBBQUHMAKGPWh0dHA6Ly93d3cuY2FyaWxsb24uY2EvY2FvcHMvQ2FyaWxs b24tbWVkaXVtLXRlc3QtYnVuZGxlMS5wN2MwgcAGCCsGAQUFBzAChoGzbGRhcDovL2Rpci5jYXJp bGxvbi5jYS9DTj1URVNUJTIwUlNBJTIwU2lnbmluZyUyMENBMSxPVT1ERU1PJTIwQ2VydGlmaWNh dGlvbiUyMFNlcnZpY2VzLE89Q2FyaWxsb24lMjBJbmZvcm1hdGlvbiUyMFNlY3VyaXR5JTIwSW5j LixDPUNBP2NBQ2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9cGtpQ0EwJwYIKwYB BQUHMAGGG2h0dHA6Ly93d3cuY2FyaWxsb24uY2Evb2NzcDCCAREGA1UdHwSCAQgwggEEMDegNaAz hjFodHRwOi8vd3d3LmNhcmlsbG9uLmNhL2Nhb3BzL3Rlc3Qtc2lnbmNhMS1jcmwuY3JsMIHIoIHF oIHChoG/bGRhcDovL2Rpci5jYXJpbGxvbi5jYS9DTj1URVNUJTIwUlNBJTIwU2lnbmluZyUyMENB MSxPVT1ERU1PJTIwQ2VydGlmaWNhdGlvbiUyMFNlcnZpY2VzLE89Q2FyaWxsb24lMjBJbmZvcm1h dGlvbiUyMFNlY3VyaXR5JTIwSW5jLixDPUNBP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7Ymlu YXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9cGtpQ0EweQYDVR0gBHIwcDBuBgsrBgEEAYHDXgEDZTBfMF0G CCsGAQUFBwICMFEwKRYiQ2FyaWxsb24gSW5mb3JtYXRpb24gU2VjdXJpdHkgSW5jLjADAgEBGiRU RVNUIG1lZGl1bSBzdyBwb2xpY3kgLSBkbyBub3QgdHJ1c3QwDQYJKoZIhvcNAQEFBQADggEBAJj2 zJKttRIiC0dXH2ehcCORTH2TXjAuxnr1qJ85Ya0TUb1MxSLO+FvafMYXgSv+28xd2bUhLPrhDZiQ tTR5K/ls9a8Lch8g6PWNavS9eHn0WzJEDZcGZFHwsude+3tfcTTebRkhozp+l3t8l1UKqF7nFwyp 8XuduDf5mSXyktXjFfw8Q72qclnX8IqhZD5iN9kAH/q0Bmzaws8vJp+39SstjRckAWijV0sZ0XK4 dn7yiiYvPfqsB2oXw76QHxxlctCjBUrN3BcVsPifZK3nN/cBcee3bgppTTVJUcS5InenjUPsBw2k bwokMTS816vVakKHIJ8GExGvK5xbW1pRYHowggdDMIIGK6ADAgECAgF3MA0GCSqGSIb3DQEBBQUA MH8xCzAJBgNVBAYTAkNBMSswKQYDVQQKDCJDYXJpbGxvbiBJbmZvcm1hdGlvbiBTZWN1cml0eSBJ bmMuMSQwIgYDVQQLDBtERU1PIENlcnRpZmljYXRpb24gU2VydmljZXMxHTAbBgNVBAMMFFRFU1Qg UlNBIFNpZ25pbmcgQ0ExMB4XDTEwMDEwNzE3NDQyM1oXDTEzMDEwNjE3NDQyM1owcTELMAkGA1UE BhMCQ0ExKzApBgNVBAoTIkNhcmlsbG9uIEluZm9ybWF0aW9uIFNlY3VyaXR5IEluYy4xDzANBgNV BAsTBlBlb3BsZTEkMCIGA1UEAxMbUGllcnJlIFBhdmxlbnlpIChTaWduYXR1cmUpMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA67bssby2i0HnlgPuw3OHNGgKUHlarJybpVP1otoN1Z1c Q8YrPrBlKllWyvVsahodWsC9IqGQd0jMEWcym9b+N/cgde7A89I4TIS7uqXmPbzMYiUOl1V7sJw2 SiWcljFV/l/ll71vMQ3xQaQ4D1XVaron2YtBtjy+c1Q8CUlnZQ5vnQVngsepFe6XA15WxuvBuMYP U2igOVPFEgV7HwX1X3f4xiqnHGsFA5NUb8uy/rNuYFxQeAylRQQAq7GKLuOYYZCfZokFtFYbymnD dqAzScxMFbuK8rnJOyPJlKPogAdkcTZLwZk/esb2LHJ2SsHNXZr6UlT+FeU35f1AeIBe0wIDAQAB o4ID1jCCA9IwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBsAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMFcGCWCGSAGG+EIBDQRKFkhEbyBOb3QgdHJ1c3QgLSBDZXJ0aVBhdGggY29tcGxp YW50IFNpZ25hdHVyZSBDZXJ0IGZvciBURVNUIHB1cnBvc2VzIG9ubHkwHQYDVR0OBBYEFC/Rg7ER e/OArm2zq2yvB9Tj4c8SMB8GA1UdIwQYMBaAFFnIy6kxRgHbITgP0W7kIVkyuHvXMCAGA1UdEQQZ MBeBFXBwYXZsZW55aUBjYXJpbGxvbi5jYTCCAUkGCCsGAQUFBwEBBIIBOzCCATcwSQYIKwYBBQUH MAKGPWh0dHA6Ly93d3cuY2FyaWxsb24uY2EvY2FvcHMvQ2FyaWxsb24tbWVkaXVtLXRlc3QtYnVu ZGxlMS5wN2MwgcAGCCsGAQUFBzAChoGzbGRhcDovL2Rpci5jYXJpbGxvbi5jYS9DTj1URVNUJTIw UlNBJTIwU2lnbmluZyUyMENBMSxPVT1ERU1PJTIwQ2VydGlmaWNhdGlvbiUyMFNlcnZpY2VzLE89 Q2FyaWxsb24lMjBJbmZvcm1hdGlvbiUyMFNlY3VyaXR5JTIwSW5jLixDPUNBP2NBQ2VydGlmaWNh dGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9cGtpQ0EwJwYIKwYBBQUHMAGGG2h0dHA6Ly93d3cu Y2FyaWxsb24uY2Evb2NzcDCCAREGA1UdHwSCAQgwggEEMDegNaAzhjFodHRwOi8vd3d3LmNhcmls bG9uLmNhL2Nhb3BzL3Rlc3Qtc2lnbmNhMS1jcmwuY3JsMIHIoIHFoIHChoG/bGRhcDovL2Rpci5j YXJpbGxvbi5jYS9DTj1URVNUJTIwUlNBJTIwU2lnbmluZyUyMENBMSxPVT1ERU1PJTIwQ2VydGlm aWNhdGlvbiUyMFNlcnZpY2VzLE89Q2FyaWxsb24lMjBJbmZvcm1hdGlvbiUyMFNlY3VyaXR5JTIw SW5jLixDPUNBP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9cGtpQ0EweQYDVR0gBHIwcDBuBgsrBgEEAYHDXgEDZTBfMF0GCCsGAQUFBwICMFEwKRYiQ2Fy aWxsb24gSW5mb3JtYXRpb24gU2VjdXJpdHkgSW5jLjADAgEBGiRURVNUIG1lZGl1bSBzdyBwb2xp Y3kgLSBkbyBub3QgdHJ1c3QwDQYJKoZIhvcNAQEFBQADggEBAAm+yULMT6dHXE6hI1ljaHB4SJcW Aqz+/tPGYJ0J0u6bueLrYWpvNQZXJubR5GHEaAEx3ljbJB5i1qC4l1urfefNmmm7OFt0sj832WJN ZucKGtYzlE0rVwqmMab4L6PsD+lk0gTE+S+p29E9T7TWfJKgO2ZqJ1bRxB1frVTyJ9cII7e0SYay 6LD1nzWfpgYBoVI5KzudDA3z6YKz6ahc9kk10zhgGfGQXbUJN0JJLjsx3ws2qSEuM3y/YFIFPpyW nMx7gpHWfa60xuw54YON3FieWFMq+yvOsvmNgXDuNhUqnrBn5csZNqSt9eJT6FPU8QqJyEGiINg/ XPTLWW5nZ0IwggkfMIIIB6ADAgECAgEBMA0GCSqGSIb3DQEBBQUAMHwxCzAJBgNVBAYTAkNBMSsw KQYDVQQKEyJDYXJpbGxvbiBJbmZvcm1hdGlvbiBTZWN1cml0eSBJbmMuMSQwIgYDVQQLExtERU1P IENlcnRpZmljYXRpb24gU2VydmljZXMxGjAYBgNVBAMTEVRFU1QgUlNBIFJvb3QgQ0ExMB4XDTA4 MTEwMzE5NTMxMloXDTE4MTEwMTE5NTMxMlowfzELMAkGA1UEBhMCQ0ExKzApBgNVBAoMIkNhcmls bG9uIEluZm9ybWF0aW9uIFNlY3VyaXR5IEluYy4xJDAiBgNVBAsMG0RFTU8gQ2VydGlmaWNhdGlv biBTZXJ2aWNlczEdMBsGA1UEAwwUVEVTVCBSU0EgU2lnbmluZyBDQTEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC7gz9Zx3kkglCnrVugUilhz71Y9jLyrJkj7dysVmpdHOrw3hq4yZ+e WYopiJOdtaMyjN+Rma4VBBuOs3tNPobleoao7zgGub117gGLdKm3BJZiqwD7hqvnpUHmkN6Gpu3D UqrdoLuGZXnNxlUZM/AZSFxXCVFp+gG1E/PH+L0nDB9AZHJrwzOUXmlMXUA/jHjuhtyhfmreiduV T/HcGMYqKItp9iujHYpGqGNY6JRD+t8a1pHIz5c2O/cK0mdltjjmscwnHNpfHdH2ER90eJbW/AAe tiL6qxfFPUcZycdmmJk3t08nRWv13E/Aya3O7vE0njXPbpS1NRIT9EnEknBBAgMBAAGjggWnMIIF ozAdBgNVHQ4EFgQUWcjLqTFGAdshOA/RbuQhWTK4e9cwHwYDVR0jBBgwFoAUPNyRe+0y1rF0WdXs zjmdW6rOnV4wDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAYYwggKABgNVHSAEggJ3MIIC czB0BgsrBgEEAYHDXgEDZjBlMGMGCCsGAQUFBwICMFcwKRoiQ2FyaWxsb24gSW5mb3JtYXRpb24g U2VjdXJpdHkgSW5jLjADAgEBGipURVNUIG1lZGl1bSBoYXJkd2FyZSBwb2xpY3kgLSBkbyBub3Qg dHJ1c3QwbgYLKwYBBAGBw14BA2UwXzBdBggrBgEFBQcCAjBRMCkaIkNhcmlsbG9uIEluZm9ybWF0 aW9uIFNlY3VyaXR5IEluYy4wAwIBARokVEVTVCBtZWRpdW0gc3cgcG9saWN5IC0gZG8gbm90IHRy dXN0MIGNBgsrBgEEAYHDXgECZjB+MHwGCCsGAQUFBwICMHAwKRoiQ2FyaWxsb24gSW5mb3JtYXRp b24gU2VjdXJpdHkgSW5jLjADAgEBGkNURVNUIG1lZGl1bSBIYXJkd2FyZSBDb21tZXJjaWFsIEJl c3QgUHJhY3RpY2UgcG9saWN5IC0gZG8gbm90IHRydXN0MIGNBgsrBgEEAYHDXgECZTB+MHwGCCsG AQUFBwICMHAwKRoiQ2FyaWxsb24gSW5mb3JtYXRpb24gU2VjdXJpdHkgSW5jLjADAgEBGkNURVNU IG1lZGl1bSBTb2Z0d2FyZSBDb21tZXJjaWFsIEJlc3QgUHJhY3RpY2UgcG9saWN5IC0gZG8gbm90 IHRydXN0MGsGCysGAQQBgcNeAQFlMFwwWgYIKwYBBQUHAgIwTjApGiJDYXJpbGxvbiBJbmZvcm1h dGlvbiBTZWN1cml0eSBJbmMuMAMCAQEaIVRFU1QgbG93IHN3IHBvbGljeSAtIGRvIG5vdCB0cnVz dDAMBgNVHSQEBTADgQEAMHsGA1UdHgR0MHKgcDA+pDwwOjELMAkGA1UEBhMCQ0ExKzApBgNVBAoT IkNhcmlsbG9uIEluZm9ybWF0aW9uIFNlY3VyaXR5IEluYy4wDYILY2FyaWxsb24uY2EwEIIOY2Fy aWxsb25pcy5jb20wDYELY2FyaWxsb24uY2EwggEdBggrBgEFBQcBAQSCAQ8wggELMEkGCCsGAQUF BzAChj1odHRwOi8vd3d3LmNhcmlsbG9uLmNhL2Nhb3BzL0NhcmlsbG9uLW1lZGl1bS10ZXN0LWJ1 bmRsZTEucDdjMIG9BggrBgEFBQcwAoaBsGxkYXA6Ly9kaXIuY2FyaWxsb24uY2EvQ049VEVTVCUy MFJTQSUyMFJvb3QlMjBDQTEsT1U9REVNTyUyMENlcnRpZmljYXRpb24lMjBTZXJ2aWNlcyxPPUNh cmlsbG9uJTIwSW5mb3JtYXRpb24lMjBTZWN1cml0eSUyMEluYy4sQz1DQT9jQUNlcnRpZmljYXRl O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPXBraUNBMIIBDgYDVR0fBIIBBTCCAQEwN6A1oDOGMWh0 dHA6Ly93d3cuY2FyaWxsb24uY2EvY2FvcHMvdGVzdC1yb290Y2EyLWFybC5jcmwwgcWggcKggb+G gbxsZGFwOi8vZGlyLmNhcmlsbG9uL2NhL0NOPVRFU1QlMjBSU0ElMjBSb290JTIwQ0ExLE9VPURF TU8lMjBDZXJ0aWZpY2F0aW9uJTIwU2VydmljZXMsTz1DYXJpbGxvbiUyMEluZm9ybWF0aW9uJTIw U2VjdXJpdHklMjBJbmMuLEM9Q0E/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1wa2lDQTANBgkqhkiG9w0BAQUFAAOCAQEAAE3WGvhoGyzp5sy8TDNASdNz VxdQ9eeuPCYeYlh04UyjeluFuG5Cn333dfUSIaU+DcEs/alRpK/ce3o7nbeJyJU8v/8gDNczh7t+ s7T19cWmA7x1veQrQOVV95Xf9eIIS4jjGNl2azF4ATfIMpAYSUYy9yc1h14sI5sDs0J36L6Q+gZq gRLf39w1dNFvj+g0hItT4EzdZ26FVkVUH7EjrBzkf3+C1/ZKXZSRESKFJNVn6BzF6thgricsZcb8 QOgyRO8d+jMMmO55lGcOIy0vUfBhjb6bHaqZAqSSEZRVISzhYclv021n4jOB9cUKQ6ZQUXen8GU4 EKezYUc56OvhRjCCCR8wgggHoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwfDELMAkGA1UEBhMCQ0Ex KzApBgNVBAoTIkNhcmlsbG9uIEluZm9ybWF0aW9uIFNlY3VyaXR5IEluYy4xJDAiBgNVBAsTG0RF TU8gQ2VydGlmaWNhdGlvbiBTZXJ2aWNlczEaMBgGA1UEAxMRVEVTVCBSU0EgUm9vdCBDQTEwHhcN MDgxMTAzMTk1MzEyWhcNMTgxMTAxMTk1MzEyWjB/MQswCQYDVQQGEwJDQTErMCkGA1UECgwiQ2Fy aWxsb24gSW5mb3JtYXRpb24gU2VjdXJpdHkgSW5jLjEkMCIGA1UECwwbREVNTyBDZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzMR0wGwYDVQQDDBRURVNUIFJTQSBTaWduaW5nIENBMTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBALuDP1nHeSSCUKetW6BSKWHPvVj2MvKsmSPt3KxWal0c6vDeGrjJ n55ZiimIk521ozKM35GZrhUEG46ze00+huV6hqjvOAa5vXXuAYt0qbcElmKrAPuGq+elQeaQ3oam 7cNSqt2gu4Zlec3GVRkz8BlIXFcJUWn6AbUT88f4vScMH0BkcmvDM5ReaUxdQD+MeO6G3KF+at6J 25VP8dwYxiooi2n2K6MdikaoY1jolEP63xrWkcjPlzY79wrSZ2W2OOaxzCcc2l8d0fYRH3R4ltb8 AB62IvqrF8U9RxnJx2aYmTe3TydFa/XcT8DJrc7u8TSeNc9ulLU1EhP0ScSScEECAwEAAaOCBacw ggWjMB0GA1UdDgQWBBRZyMupMUYB2yE4D9Fu5CFZMrh71zAfBgNVHSMEGDAWgBQ83JF77TLWsXRZ 1ezOOZ1bqs6dXjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBhjCCAoAGA1UdIASCAncw ggJzMHQGCysGAQQBgcNeAQNmMGUwYwYIKwYBBQUHAgIwVzApGiJDYXJpbGxvbiBJbmZvcm1hdGlv biBTZWN1cml0eSBJbmMuMAMCAQEaKlRFU1QgbWVkaXVtIGhhcmR3YXJlIHBvbGljeSAtIGRvIG5v dCB0cnVzdDBuBgsrBgEEAYHDXgEDZTBfMF0GCCsGAQUFBwICMFEwKRoiQ2FyaWxsb24gSW5mb3Jt YXRpb24gU2VjdXJpdHkgSW5jLjADAgEBGiRURVNUIG1lZGl1bSBzdyBwb2xpY3kgLSBkbyBub3Qg dHJ1c3QwgY0GCysGAQQBgcNeAQJmMH4wfAYIKwYBBQUHAgIwcDApGiJDYXJpbGxvbiBJbmZvcm1h dGlvbiBTZWN1cml0eSBJbmMuMAMCAQEaQ1RFU1QgbWVkaXVtIEhhcmR3YXJlIENvbW1lcmNpYWwg QmVzdCBQcmFjdGljZSBwb2xpY3kgLSBkbyBub3QgdHJ1c3QwgY0GCysGAQQBgcNeAQJlMH4wfAYI KwYBBQUHAgIwcDApGiJDYXJpbGxvbiBJbmZvcm1hdGlvbiBTZWN1cml0eSBJbmMuMAMCAQEaQ1RF U1QgbWVkaXVtIFNvZnR3YXJlIENvbW1lcmNpYWwgQmVzdCBQcmFjdGljZSBwb2xpY3kgLSBkbyBu b3QgdHJ1c3QwawYLKwYBBAGBw14BAWUwXDBaBggrBgEFBQcCAjBOMCkaIkNhcmlsbG9uIEluZm9y bWF0aW9uIFNlY3VyaXR5IEluYy4wAwIBARohVEVTVCBsb3cgc3cgcG9saWN5IC0gZG8gbm90IHRy dXN0MAwGA1UdJAQFMAOBAQAwewYDVR0eBHQwcqBwMD6kPDA6MQswCQYDVQQGEwJDQTErMCkGA1UE ChMiQ2FyaWxsb24gSW5mb3JtYXRpb24gU2VjdXJpdHkgSW5jLjANggtjYXJpbGxvbi5jYTAQgg5j YXJpbGxvbmlzLmNvbTANgQtjYXJpbGxvbi5jYTCCAR0GCCsGAQUFBwEBBIIBDzCCAQswSQYIKwYB BQUHMAKGPWh0dHA6Ly93d3cuY2FyaWxsb24uY2EvY2FvcHMvQ2FyaWxsb24tbWVkaXVtLXRlc3Qt YnVuZGxlMS5wN2Mwgb0GCCsGAQUFBzAChoGwbGRhcDovL2Rpci5jYXJpbGxvbi5jYS9DTj1URVNU JTIwUlNBJTIwUm9vdCUyMENBMSxPVT1ERU1PJTIwQ2VydGlmaWNhdGlvbiUyMFNlcnZpY2VzLE89 Q2FyaWxsb24lMjBJbmZvcm1hdGlvbiUyMFNlY3VyaXR5JTIwSW5jLixDPUNBP2NBQ2VydGlmaWNh dGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9cGtpQ0EwggEOBgNVHR8EggEFMIIBATA3oDWgM4Yx aHR0cDovL3d3dy5jYXJpbGxvbi5jYS9jYW9wcy90ZXN0LXJvb3RjYTItYXJsLmNybDCBxaCBwqCB v4aBvGxkYXA6Ly9kaXIuY2FyaWxsb24vY2EvQ049VEVTVCUyMFJTQSUyMFJvb3QlMjBDQTEsT1U9 REVNTyUyMENlcnRpZmljYXRpb24lMjBTZXJ2aWNlcyxPPUNhcmlsbG9uJTIwSW5mb3JtYXRpb24l MjBTZWN1cml0eSUyMEluYy4sQz1DQT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeT9i YXNlP29iamVjdGNsYXNzPXBraUNBMA0GCSqGSIb3DQEBBQUAA4IBAQAATdYa+GgbLOnmzLxMM0BJ 03NXF1D15648Jh5iWHThTKN6W4W4bkKfffd19RIhpT4NwSz9qVGkr9x7ejudt4nIlTy//yAM1zOH u36ztPX1xaYDvHW95CtA5VX3ld/14ghLiOMY2XZrMXgBN8gykBhJRjL3JzWHXiwjmwOzQnfovpD6 BmqBEt/f3DV00W+P6DSEi1PgTN1nboVWRVQfsSOsHOR/f4LX9kpdlJERIoUk1WfoHMXq2GCuJyxl xvxA6DJE7x36MwyY7nmUZw4jLS9R8GGNvpsdqpkCpJIRlFUhLOFhyW/TbWfiM4H1xQpDplBRd6fw ZTgQp7NhRzno6+FGMYIDPzCCAzsCAQEwgYQwfzELMAkGA1UEBhMCQ0ExKzApBgNVBAoMIkNhcmls bG9uIEluZm9ybWF0aW9uIFNlY3VyaXR5IEluYy4xJDAiBgNVBAsMG0RFTU8gQ2VydGlmaWNhdGlv biBTZXJ2aWNlczEdMBsGA1UEAwwUVEVTVCBSU0EgU2lnbmluZyBDQTECAXcwCQYFKw4DAhoFAKCC AY8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwMjAzMjIzNjM1 WjAjBgkqhkiG9w0BCQQxFgQU4pch6x3v1ilIePkR3KtrGeQZ0OwwgZUGCSsGAQQBgjcQBDGBhzCB hDB/MQswCQYDVQQGEwJDQTErMCkGA1UECgwiQ2FyaWxsb24gSW5mb3JtYXRpb24gU2VjdXJpdHkg SW5jLjEkMCIGA1UECwwbREVNTyBDZXJ0aWZpY2F0aW9uIFNlcnZpY2VzMR0wGwYDVQQDDBRURVNU IFJTQSBTaWduaW5nIENBMQIBeTCBlwYLKoZIhvcNAQkQAgsxgYeggYQwfzELMAkGA1UEBhMCQ0Ex KzApBgNVBAoMIkNhcmlsbG9uIEluZm9ybWF0aW9uIFNlY3VyaXR5IEluYy4xJDAiBgNVBAsMG0RF TU8gQ2VydGlmaWNhdGlvbiBTZXJ2aWNlczEdMBsGA1UEAwwUVEVTVCBSU0EgU2lnbmluZyBDQTEC AXkwDQYJKoZIhvcNAQEBBQAEggEA6TM1n87Wn9lFFS9Q7m9/iMN0+pZGAcRUeaoGU87rmIm656cE Wf7nNzhDm8q+JrAjkKBpwEqr9OL6zVxeQzCcphw7KiEBk0M8W7nuoK/9ysbxjOHGEK5o051Hf1jz WX1eEgL/gsMZQismNuiWiWoQ5Pc8c+Jn509k2nwtcbWJxsUzI8c6he4mX5nsWfc79v9p2PgYYsan Y9ErszOnCrDBWso6OOSrT6NAYzQmSzfR/ydanRJ+mown9KNb4WchKEPdLq8tDEHSon7l66/+UkJP H8ASV48c/h/o2c1fSfA7z5FoZaEQ2bJ9klMBKXM45OSWuao41t95sZfBIbBUgiKW5AAAAAAAAA== --Apple-Mail-75-637815016-- From trevorf@exchange.microsoft.com Thu Feb 3 15:11:21 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FB2F3A6A4F for ; Thu, 3 Feb 2011 15:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtzV14gqMrO4 for ; Thu, 3 Feb 2011 15:11:16 -0800 (PST) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by core3.amsl.com (Postfix) with ESMTP id 2C8AB3A6B2B for ; Thu, 3 Feb 2011 15:11:13 -0800 (PST) Received: from df-h14-02.exchange.corp.microsoft.com (157.54.78.140) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.1.218.15; Thu, 3 Feb 2011 15:14:36 -0800 Received: from DF-MLT-01.exchange.corp.microsoft.com (157.54.94.40) by DF-H14-02.exchange.corp.microsoft.com (157.54.78.140) with Microsoft SMTP Server (TLS) id 14.1.270.2; Thu, 3 Feb 2011 15:14:36 -0800 Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by DF-MLT-01.exchange.corp.microsoft.com ([157.54.94.40]) with mapi id 14.01.0218.012; Thu, 3 Feb 2011 15:14:36 -0800 From: Trevor Freeman To: "Pkix List (pkix@ietf.org)" Thread-Topic: New Non-WG Mailing List: plasma -- The PoLicy Augmented S/Mime (plasma) bof discussion list Thread-Index: AcvD9cul75cjLDVbT2eG1xtsXvOEyQAAilaw Date: Thu, 3 Feb 2011 23:14:36 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [pkix] FW: New Non-WG Mailing List: plasma -- The PoLicy Augmented S/Mime (plasma) bof discussion list X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 23:11:21 -0000 DQpQTEFTTUEgLSBQb2xpY3kgQXVnbWVudGVkIFMvTWltZSANCg0KRGVzY3JpcHRpb246IEN1cnJl bnQgUy9NSU1FIG1lY2hhbmlzbXMgcHJvdmlkZSBjcnlwdG9ncmFwaGljIGFjY2VzcyB0byB0aGUg bWVzc2FnZSBiYXNlZCBvbiB0aGUgaWRlbnRpdHkgb2YgdGhlIHJlY2lwaWVudCBhdCB0aGUgdGlt ZSBvZiB0cmFuc21pc3Npb24uIEFueSBhZGRpdGlvbmFsIGFjY2VzcyBjb250cm9sIGVuZm9yY2Vt ZW50IGRlcGVuZHMgb24gdGhlIGNvbmZpZ3VyYXRpb24gb2YgdGhlIHJlY2lwaWVudHMgZW1haWwg Y2xpZW50LiBTZXZlcmFsIEludGVybmV0LURyYWZ0cyBoYXZlIGJlZW4gc3VibWl0dGVkIHRoYXQg ZXN0YWJsaXNoIGEgbW9yZSByb2J1c3QgYWNjZXNzIGNvbnRyb2wgbWVjaGFuaXNtIHdoZXJlIGNy eXB0b2dyYXBoaWMgYWNjZXNzIHRvIHRoZSBtZXNzYWdlIGlzIG9ubHkgZ3JhbnRlZCBhZnRlciB0 aGUgYWNjZXNzIGNoZWNrLg0KDQpUaGlzIHByb3Bvc2VkIHdvcmtpbmcgZ3JvdXAgd291bGQgZGV2 ZWxvcCBhIGZyYW1ld29yayBmb3IgZW5mb3JjaW5nIGEgbW9yZSByb2J1c3QgYWNjZXNzIGNvbnRy b2wgbWVjaGFuaXNtLCBiYXNlZCBvbiBleGlzdGluZyBDTVMsIFMvTUlNRSBhbmQgU0FNTC1iYXNl ZCBwb2xpY3kgZW5mb3JjZW1lbnQgc3RhbmRhcmRzLiBUaGUgd29ya2luZyBncm91cCB3aWxsIGFs c28gZGV2ZWxvcCBhbnkgbmVjZXNzYXJ5IGV4dGVuc2lvbnMgdG8gdGhlc2UgYmFzZSBwcm90b2Nv bHMgc3BlY2lmaWMgdG8gdGhpcyBwcm9ibGVtIHNwYWNlLiANCg0KR2l2ZW4gc29tZSBvZiB0aGUg d29yayBpbiBwa2l4IHJlbGF0ZXMgdG8gUy9taW1lIC0gdGhpcyB3b3JrIG1heSBiZSBvZiBpbnRl cmVzdCB0byBzb21lIG9mIHlvdS4gDQoNClRyZXZvcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogSUVURiBTZWNyZXRhcmlhdCBbbWFpbHRvOmlldGYtc2VjcmV0YXJpYXRAaWV0 Zi5vcmddIA0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDAzLCAyMDExIDExOjU0IEFNDQpUbzog SUVURiBBbm5vdW5jZW1lbnQgbGlzdA0KQ2M6IHBsYXNtYUBpZXRmLm9yZzsgamltc2NoQG53bGlu ay5jb207IFRyZXZvciBGcmVlbWFuDQpTdWJqZWN0OiBOZXcgTm9uLVdHIE1haWxpbmcgTGlzdDog cGxhc21hIC0tIFRoZSBQb0xpY3kgQXVnbWVudGVkIFMvTWltZSAocGxhc21hKSBib2YgZGlzY3Vz c2lvbiBsaXN0IA0KDQpBIG5ldyBJRVRGIG5vbi13b3JraW5nIGdyb3VwIGVtYWlsIGxpc3QgaGFz IGJlZW4gY3JlYXRlZC4NCg0KTGlzdCBhZGRyZXNzOiBwbGFzbWFAaWV0Zi5vcmcNCkFyY2hpdmU6 IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9wbGFzbWEvDQpUbyBzdWJzY3Jp YmU6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGxhc21hDQoNCkRlc2Ny aXB0aW9uOiANCkN1cnJlbnQgUy9NSU1FIG1lY2hhbmlzbXMgcHJvdmlkZSBjcnlwdG9ncmFwaGlj IGFjY2VzcyB0byB0aGUgbWVzc2FnZSBiYXNlZCBvbiB0aGUgaWRlbnRpdHkgb2YgdGhlIHJlY2lw aWVudCBhdCB0aGUgdGltZSBvZiB0cmFuc21pc3Npb24uIEFueSBhZGRpdGlvbmFsIGFjY2VzcyBj b250cm9sIGVuZm9yY2VtZW50IGRlcGVuZHMgb24gdGhlIGNvbmZpZ3VyYXRpb24gb2YgdGhlIHJl Y2lwaWVudHMgZW1haWwgY2xpZW50LiBTZXZlcmFsIEludGVybmV0LURyYWZ0cyBoYXZlIGJlZW4g c3VibWl0dGVkIHRoYXQgZXN0YWJsaXNoIGEgbW9yZSByb2J1c3QgYWNjZXNzIGNvbnRyb2wgbWVj aGFuaXNtIHdoZXJlIGNyeXB0b2dyYXBoaWMgYWNjZXNzIHRvIHRoZSBtZXNzYWdlIGlzIG9ubHkg Z3JhbnRlZCBhZnRlciB0aGUgYWNjZXNzIGNoZWNrLiBUaGlzIGxpc3QgaXMgZGV2b3RlZCB0byB0 aGUgZGlzY3Vzc2lvbiBvZiB0aGVzZSBkcmFmdHMgYW5kIGFueSByZWxhdGVkIGZ1dHVyZSBzdWJt aXNzaW9ucy4gDQoNCkZvciBhZGRpdGlvbmFsIGluZm9ybWF0aW9uLCBwbGVhc2UgY29udGFjdCB0 aGUgbGlzdCBhZG1pbmlzdHJhdG9ycy4NCg== From hotz@jpl.nasa.gov Thu Feb 3 17:34:54 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799863A672F for ; Thu, 3 Feb 2011 17:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wCu2ys5SSjO for ; Thu, 3 Feb 2011 17:34:53 -0800 (PST) Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109]) by core3.amsl.com (Postfix) with ESMTP id C22E63A659C for ; Thu, 3 Feb 2011 17:34:53 -0800 (PST) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id p141cCf4014030 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Thu, 3 Feb 2011 17:38:13 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Thu, 3 Feb 2011 17:38:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4AF2E3.6050001@ieca.com> <133B3820-DE76-4820-9F4F-C333BD818B83@carillon.ca> <4D7EE79B-FF99-4E22-93E3-680C976D59B8@jpl.nasa.gov> To: Pierre Pavlenyi X-Mailer: Apple Mail (2.1082) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: pkix , "Kemp, David P." Subject: Re: [pkix] Guidelines for Need for CRL/OCSP? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 01:34:54 -0000 On Feb 3, 2011, at 2:34 PM, Pierre Pavlenyi wrote: > Henry, >=20 > Again, I have to ask if the TLS server you're authenticating your = client to using the certs in question does revocation checking. If no, = then you don't need to supply a CDP or AIA-OCSP location. If your TLS = servers do revocation check, then I'm afraid you'll have to go with a = CDP or AIA-OCSP location. Ignoring that part of your email may have given the wrong impression, = sorry. It's a valid, important point for how the server side use of = such certs need to be set up. I'm not sure if it needs to be mentioned = in a client-side (of TLS) specification like KX509, but it probably = wouldn't hurt. As for my own deployment, my (unverified) expectation is that the server = folk would rather not have to think about doing CRL/OCSP checking if = they don't have to. Absent an actual specification, or other official guidance, I agree that = David Kemp did a really good job of putting things in perspective. = Thanks David! ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From Internet-Drafts@ietf.org Tue Feb 15 05:00:06 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C25B93A6D14; Tue, 15 Feb 2011 05:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hqupDslC1Sb; Tue, 15 Feb 2011 05:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3100E3A6956; Tue, 15 Feb 2011 05:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110215130002.26577.69930.idtracker@localhost> Date: Tue, 15 Feb 2011 05:00:02 -0800 Cc: pkix@ietf.org Subject: [pkix] I-D Action:draft-ietf-pkix-certimage-11.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 13:00:06 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure - Certificate Image Author(s) : S. Santesson, et al. Filename : draft-ietf-pkix-certimage-11.txt Pages : 14 Date : 2011-02-15 This document specifies a method to bind a visual representation of a certificate in the form of a certificate image to a public key certificate as defined in RFC 5280 [RFC5280] by defining a new otherLogos image type according to RFC 3709 [RFC3709]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-certimage-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pkix-certimage-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-15045505.I-D@ietf.org> --NextPart-- From iesg-secretary@ietf.org Tue Feb 15 09:04:47 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB3A63A6D27; Tue, 15 Feb 2011 09:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxFOxspMeD0b; Tue, 15 Feb 2011 09:04:47 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E89E3A6D33; Tue, 15 Feb 2011 09:04:46 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110215170446.7946.94549.idtracker@localhost> Date: Tue, 15 Feb 2011 09:04:46 -0800 Cc: pkix mailing list , pkix chair , Internet Architecture Board , RFC Editor Subject: [pkix] Protocol Action: 'Internet X.509 Public Key Infrastructure - Certificate Image' to Proposed Standard (draft-ietf-pkix-certimage-11.txt) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 17:04:48 -0000 The IESG has approved the following document: - 'Internet X.509 Public Key Infrastructure - Certificate Image' (draft-ietf-pkix-certimage-11.txt) as a Proposed Standard This document is the product of the Public-Key Infrastructure (X.509) Working Group. The IESG contact persons are Tim Polk and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pkix-certimage/ Technical Summary RFC 3709 defines a way to bind a logo or analogous image to a certificate, to aid human interpretation of a certificate by providing meaningful visual information to the user interface. This document specifies three new encodings for visual representations, as an extension of RFC 3709, using the otherLogos extension capability of that RFC. Thus it represents an incremental change to the fundamental capability provided by 3709. Working Group Summary WG process was not particularly smooth. At the first WGLC this document generated a fairly large amount of discussion where several WG members voiced security concerns as well as concerns whether the problem addressed by this draft requires a solution or whether this problem would be better served by another solution. These security concerns were addressed as a result of changes made after the first WGLC. The residual objection that was raised by a few individuals (during the second WGLC) is whether this solution is will be successful, i.e., deployed. The WG chair judged this document to have "very rough consensus". The wg emails were reviewed by both SEC ADs, and believe that sufficient consensus existed to progress. Document Quality We have seen no deployment of certificates with the 3709 extension, nor are we aware of code to make use of this extension in relying party software. However, several major implementers have stated their support for the current draft. The ETSI ESI (Electronic Signature Infrastructure) group is also referencing this specification as a component for their Visible Signatures work. Personnel Steve Kent is the Document Shepherd for this document. Tim Polk is the Responsible Area Director. RFC Editor Note In section 4.1, please make the following substitution: OLD LogotypeDetails ::= SEQUENCE { mediaType IA5String, -- MIME media type name and optional -- parameters NEW LogotypeDetails ::= SEQUENCE { mediaType IA5String, -- MIME media type name and optional -- parameters (see section 5) In Section 5.2, please make the following substitution: OLD The referenced SVG file MAY be provided in GZIP [RFC1952] compressed form as an SVGZ file according to section 1.2 in SVG 1.1 [SVG]. NEW The referenced SVG file MAY be provided in GZIP [RFC1952] compressed form as an SVGZ file. In this case, the extension 'svgz' is used as an alias for 'svg.gz' [RFC1952], i.e. octet streams of type image/svg+xml, subsequently compressed with gzip as specified in [SVGR]. In Section 5.2, please replace the 2nd to the last paragraph to read: OLD: When the SVG image is embedded using the "data" URL scheme as defined in section 5, SVG image data SHOULD be provided in SVGZ (GZIP ^ ^^^^^^ compressed) form and MAY be provided in uncompressed SVG form. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Compliant implementations that process embedded SVG images MUST be able to handle both compressed and uncompressed image data. NEW: When the SVG image is embedded using the "data" URL scheme as defined in section 4, SVG image data MUST be provided in SVGZ (GZIP ^ ^^^^ compressed) form (i.e. it MUST NOT be provided in uncompressed SVG form). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Please add the following informative reference: [SVGR] "Media Type Registration for image/svg+xml", http://dev.w3.org/SVG/profiles/1.1F2/master/mimereg.html From roberto@opazo.cl Wed Feb 16 10:49:24 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 394673A6E25 for ; Wed, 16 Feb 2011 10:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qnq2wKRoTiQr for ; Wed, 16 Feb 2011 10:49:23 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 29A1B3A6CB0 for ; Wed, 16 Feb 2011 10:49:22 -0800 (PST) Received: by eyd10 with SMTP id 10so1080722eyd.31 for ; Wed, 16 Feb 2011 10:49:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.14.127.206 with SMTP id d54mr998842eei.36.1297882190540; Wed, 16 Feb 2011 10:49:50 -0800 (PST) Received: by 10.14.121.212 with HTTP; Wed, 16 Feb 2011 10:49:50 -0800 (PST) Date: Wed, 16 Feb 2011 15:49:50 -0300 Message-ID: From: Roberto Opazo To: IETF Content-Type: text/plain; charset=ISO-8859-1 Subject: [pkix] What should be in "Next Update" field of the last CRL? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 18:49:24 -0000 Hello: I can't find an specification about what to put in the "Next Update" field of the last CRL issued by one CA in its last day. I mean, the day when this CA certificates expires. Is there any recommendation? Without a recommendation you could chose very different options: * NULL. The field is optional after all, but RFC5280 states "Conforming CRL issuers MUST include the nextUpdate field in all CRLs." * 24 hours, as all other CRL's. But that's a lie, CA is going to be expired in 24 hours, son It can't sign. * Year 2999. So no one alive today is going to be alive that they, but it's a lie any way and there could be systems not prepared to process that date. So, could you help me with an official recommendation? -- Best regards, Roberto Opazo From housley@vigilsec.com Wed Feb 16 11:46:06 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D33C3A6D34 for ; Wed, 16 Feb 2011 11:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPfW67LyqpMf for ; Wed, 16 Feb 2011 11:46:05 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 5C1993A6AB3 for ; Wed, 16 Feb 2011 11:46:05 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 733329A477D; Wed, 16 Feb 2011 14:46:57 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id pIUHpPla7IMG; Wed, 16 Feb 2011 14:46:20 -0500 (EST) Received: from [192.168.2.105] (pool-71-178-218-117.washdc.fios.verizon.net [71.178.218.117]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 81DB99A477C; Wed, 16 Feb 2011 14:46:56 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Wed, 16 Feb 2011 14:46:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Roberto Opazo X-Mailer: Apple Mail (2.1082) Cc: IETF Subject: Re: [pkix] What should be in "Next Update" field of the last CRL? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 19:46:06 -0000 Is the CA being shut down forever? Or, is a new CA taking over using = the key rollover stuff specified in CMP? Russ On Feb 16, 2011, at 1:49 PM, Roberto Opazo wrote: > Hello: >=20 > I can't find an specification about what to put in the "Next Update" > field of the last CRL issued by one CA in its last day. I mean, the > day when this CA certificates expires. >=20 > Is there any recommendation? >=20 > Without a recommendation you could chose very different options: >=20 > * NULL. The field is optional after all, but RFC5280 states > "Conforming CRL issuers MUST include the nextUpdate field in all > CRLs." >=20 > * 24 hours, as all other CRL's. But that's a lie, CA is going to be > expired in 24 hours, son It can't sign. >=20 > * Year 2999. So no one alive today is going to be alive that they, but > it's a lie any way and there could be systems not prepared to process > that date. >=20 > So, could you help me with an official recommendation? >=20 > --=20 > Best regards, >=20 > Roberto Opazo > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From housley@vigilsec.com Wed Feb 16 13:55:41 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DB173A6CE0 for ; Wed, 16 Feb 2011 13:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBoRlSGKm2eR for ; Wed, 16 Feb 2011 13:55:40 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 631D03A6CB0 for ; Wed, 16 Feb 2011 13:55:40 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id B38EE9A477C; Wed, 16 Feb 2011 16:56:50 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id oKzrVW8+xNLW; Wed, 16 Feb 2011 16:55:27 -0500 (EST) Received: from [192.168.2.105] (pool-71-178-218-117.washdc.fios.verizon.net [71.178.218.117]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id BCB119A4782; Wed, 16 Feb 2011 16:56:49 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Wed, 16 Feb 2011 16:56:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Roberto Opazo X-Mailer: Apple Mail (2.1082) Cc: IETF PKIX Subject: Re: [pkix] What should be in "Next Update" field of the last CRL? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 21:55:41 -0000 RFC 5280 says the following about a certificate notAfter field: To indicate that a certificate has no well-defined expiration date, the notAfter SHOULD be assigned the GeneralizedTime value of 99991231235959Z. It seems to me that the same value is appropriate for a CRL. Russ On Feb 16, 2011, at 3:32 PM, Roberto Opazo wrote: > CA being shut down forever. >=20 > 2011/2/16 Russ Housley : >> Is the CA being shut down forever? Or, is a new CA taking over using = the key rollover stuff specified in CMP? >>=20 >> Russ >>=20 >>=20 >> On Feb 16, 2011, at 1:49 PM, Roberto Opazo wrote: >>=20 >>> Hello: >>>=20 >>> I can't find an specification about what to put in the "Next Update" >>> field of the last CRL issued by one CA in its last day. I mean, the >>> day when this CA certificates expires. >>>=20 >>> Is there any recommendation? >>>=20 >>> Without a recommendation you could chose very different options: >>>=20 >>> * NULL. The field is optional after all, but RFC5280 states >>> "Conforming CRL issuers MUST include the nextUpdate field in all >>> CRLs." >>>=20 >>> * 24 hours, as all other CRL's. But that's a lie, CA is going to be >>> expired in 24 hours, son It can't sign. >>>=20 >>> * Year 2999. So no one alive today is going to be alive that they, = but >>> it's a lie any way and there could be systems not prepared to = process >>> that date. >>>=20 >>> So, could you help me with an official recommendation? >>>=20 >>> -- >>> Best regards, >>>=20 >>> Roberto Opazo >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>=20 >>=20 >=20 >=20 >=20 > --=20 > Saludos, >=20 > Roberto Opazo From mstjohns@comcast.net Wed Feb 16 17:23:34 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84383A6EC5 for ; Wed, 16 Feb 2011 17:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDjLhpiPZ4eT for ; Wed, 16 Feb 2011 17:23:31 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 055DD3A6BA0 for ; Wed, 16 Feb 2011 17:23:30 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta07.westchester.pa.mail.comcast.net with comcast id 8oSW1g0011ap0As57pQ1Cm; Thu, 17 Feb 2011 01:24:01 +0000 Received: from Mike-PC3.comcast.net ([67.99.198.2]) by omta22.westchester.pa.mail.comcast.net with comcast id 8pPn1g00N03bYCr3ipPp2e; Thu, 17 Feb 2011 01:23:59 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 16 Feb 2011 20:23:45 -0500 To: Russ Housley ,Roberto Opazo From: Michael StJohns In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20110217012331.055DD3A6BA0@core3.amsl.com> Cc: IETF PKIX Subject: Re: [pkix] What should be in "Next Update" field of the last CRL? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 01:23:34 -0000 That's probably the most right choice, but hard to implement programmatically I think. The code generating the signature doesn't know/can't know (absent outside info) whether or not the signing cert will be reissued. I'd suggest that using the same interval time for "Next Update" - at that point, either the cert has been reissued or it hasn't. If it has, the date is appropriate. If it hasn't - well the CRL becomes moot as the signing cert is no longer valid. Mike At 04:56 PM 2/16/2011, Russ Housley wrote: >RFC 5280 says the following about a certificate notAfter field: > > To indicate that a certificate has no well-defined expiration date, > the notAfter SHOULD be assigned the GeneralizedTime value of > 99991231235959Z. > >It seems to me that the same value is appropriate for a CRL. > >Russ > > >On Feb 16, 2011, at 3:32 PM, Roberto Opazo wrote: > >> CA being shut down forever. >> >> 2011/2/16 Russ Housley : >>> Is the CA being shut down forever? Or, is a new CA taking over using the key rollover stuff specified in CMP? >>> >>> Russ >>> >>> >>> On Feb 16, 2011, at 1:49 PM, Roberto Opazo wrote: >>> >>>> Hello: >>>> >>>> I can't find an specification about what to put in the "Next Update" >>>> field of the last CRL issued by one CA in its last day. I mean, the >>>> day when this CA certificates expires. >>>> >>>> Is there any recommendation? >>>> >>>> Without a recommendation you could chose very different options: >>>> >>>> * NULL. The field is optional after all, but RFC5280 states >>>> "Conforming CRL issuers MUST include the nextUpdate field in all >>>> CRLs." >>>> >>>> * 24 hours, as all other CRL's. But that's a lie, CA is going to be >>>> expired in 24 hours, son It can't sign. >>>> >>>> * Year 2999. So no one alive today is going to be alive that they, but >>>> it's a lie any way and there could be systems not prepared to process >>>> that date. >>>> >>>> So, could you help me with an official recommendation? >>>> >>>> -- >>>> Best regards, >>>> >>>> Roberto Opazo >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>> >>> >> >> >> >> -- >> Saludos, >> >> Roberto Opazo > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From mstjohns@comcast.net Wed Feb 16 17:34:38 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFB603A6F0C for ; Wed, 16 Feb 2011 17:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEgURcRqQ9W3 for ; Wed, 16 Feb 2011 17:33:59 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 0A2213A6F09 for ; Wed, 16 Feb 2011 17:33:58 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta07.westchester.pa.mail.comcast.net with comcast id 8pLt1g0031ZXKqc57paVSk; Thu, 17 Feb 2011 01:34:29 +0000 Received: from Mike-PC3.comcast.net ([67.99.198.2]) by omta21.westchester.pa.mail.comcast.net with comcast id 8paF1g00k03bYCr3hpaJQj; Thu, 17 Feb 2011 01:34:27 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 16 Feb 2011 20:34:13 -0500 To: Russ Housley ,Roberto Opazo From: Michael StJohns In-Reply-To: <20110217012331.055DD3A6BA0@core3.amsl.com> References: <20110217012331.055DD3A6BA0@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20110217013359.0A2213A6F09@core3.amsl.com> Cc: IETF PKIX Subject: Re: [pkix] What should be in "Next Update" field of the last CRL? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 01:34:38 -0000 To expand on this - consider a CA with a CRL interval quite a bit longer - say 30 days. The CA cert will expire 20 days into that period. It seems to me that issuing a CRL at day 0 with a Next Update of "sometime far in the future" would become problematic if the CA were resigned with a longer expiration date around day 15. Mike At 08:23 PM 2/16/2011, Michael StJohns wrote: >That's probably the most right choice, but hard to implement programmatically I think. The code generating the signature doesn't know/can't know (absent outside info) whether or not the signing cert will be reissued. I'd suggest that using the same interval time for "Next Update" - at that point, either the cert has been reissued or it hasn't. If it has, the date is appropriate. If it hasn't - well the CRL becomes moot as the signing cert is no longer valid. > >Mike > > > >At 04:56 PM 2/16/2011, Russ Housley wrote: >>RFC 5280 says the following about a certificate notAfter field: >> >> To indicate that a certificate has no well-defined expiration date, >> the notAfter SHOULD be assigned the GeneralizedTime value of >> 99991231235959Z. >> >>It seems to me that the same value is appropriate for a CRL. >> >>Russ >> >> >>On Feb 16, 2011, at 3:32 PM, Roberto Opazo wrote: >> >>> CA being shut down forever. >>> >>> 2011/2/16 Russ Housley : >>>> Is the CA being shut down forever? Or, is a new CA taking over using the key rollover stuff specified in CMP? >>>> >>>> Russ >>>> >>>> >>>> On Feb 16, 2011, at 1:49 PM, Roberto Opazo wrote: >>>> >>>>> Hello: >>>>> >>>>> I can't find an specification about what to put in the "Next Update" >>>>> field of the last CRL issued by one CA in its last day. I mean, the >>>>> day when this CA certificates expires. >>>>> >>>>> Is there any recommendation? >>>>> >>>>> Without a recommendation you could chose very different options: >>>>> >>>>> * NULL. The field is optional after all, but RFC5280 states >>>>> "Conforming CRL issuers MUST include the nextUpdate field in all >>>>> CRLs." >>>>> >>>>> * 24 hours, as all other CRL's. But that's a lie, CA is going to be >>>>> expired in 24 hours, son It can't sign. >>>>> >>>>> * Year 2999. So no one alive today is going to be alive that they, but >>>>> it's a lie any way and there could be systems not prepared to process >>>>> that date. >>>>> >>>>> So, could you help me with an official recommendation? >>>>> >>>>> -- >>>>> Best regards, >>>>> >>>>> Roberto Opazo >>>>> _______________________________________________ >>>>> pkix mailing list >>>>> pkix@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pkix >>>> >>>> >>> >>> >>> >>> -- >>> Saludos, >>> >>> Roberto Opazo >> >>_______________________________________________ >>pkix mailing list >>pkix@ietf.org >>https://www.ietf.org/mailman/listinfo/pkix > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From alan.sill@ttu.edu Wed Feb 16 17:46:37 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC0F3A6F16 for ; Wed, 16 Feb 2011 17:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLqCcPPjcqma for ; Wed, 16 Feb 2011 17:46:36 -0800 (PST) Received: from eurynomus.ttu.edu (eurynomus.ttu.edu [129.118.1.242]) by core3.amsl.com (Postfix) with ESMTP id 47A853A6F15 for ; Wed, 16 Feb 2011 17:46:36 -0800 (PST) Received: from hippolytus.net.ttu.edu (129.118.1.212) by mxout3.ttu.edu (129.118.1.201) with Microsoft SMTP Server id 8.2.255.0; Wed, 16 Feb 2011 19:47:05 -0600 Received: from dr247.dhcp.ttu.edu (129.118.91.167) by smtp.ttu.edu (129.118.240.206) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 16 Feb 2011 19:47:04 -0600 Message-ID: <4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu> From: Alan Sill To: Michael StJohns In-Reply-To: <20110217013359.0A2213A6F09@core3.amsl.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Date: Wed, 16 Feb 2011 19:47:04 -0600 References: <20110217012331.055DD3A6BA0@core3.amsl.com> <20110217013359.0A2213A6F09@core3.amsl.com> X-Mailer: Apple Mail (2.936) Received-SPF: Pass (eurynomus.ttu.edu: domain of Alan.Sill@ttu.edu designates 129.118.1.212 as permitted sender) receiver=eurynomus.ttu.edu; client-ip=129.118.1.212; helo=hippolytus.net.ttu.edu; X-TechMail-Edge-Route: TTU Cc: IETF PKIX , Alan Sill Subject: Re: [pkix] What should be in "Next Update" field of the last CRL? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 01:46:37 -0000 A CA can become inactive for the purposes of issuing new credentials without necessarily invalidating the certificates already issued. The CRL server can be maintained and can be used to revoke previously issued certificates for as long as they are of use to the relying parties making use of those certificates. In principle, a CRL server should be maintained and should issue updates (with valid "Next Update" fields) through the full period that includes any certificate previously issued by the CA. Otherwise, any relying parties making use of the certificates either to assert or grant trust will be unaware of any change to the status of the previously issued certs. An option is to revoke all previously issued certs at a time of your choice and put them all into your last CRL update. the "next Update" time would then be set to the previously quoted GeneralizedTime value (99991231235959Z) to indicate that there will be no further updates. It would also be perfectly valid to leave previously issued certs that you as the CA operator would like to allow to remain active out of the CRL, and continue to issue CRL updates through the expiration date of the last remaining active certificate. Alan On Feb 16, 2011, at 7:34 PM, Michael StJohns wrote: > To expand on this - consider a CA with a CRL interval quite a bit > longer - say 30 days. The CA cert will expire 20 days into that > period. It seems to me that issuing a CRL at day 0 with a Next > Update of "sometime far in the future" would become problematic if > the CA were resigned with a longer expiration date around day 15. > > Mike > > > > At 08:23 PM 2/16/2011, Michael StJohns wrote: >> That's probably the most right choice, but hard to implement >> programmatically I think. The code generating the signature >> doesn't know/can't know (absent outside info) whether or not the >> signing cert will be reissued. I'd suggest that using the same >> interval time for "Next Update" - at that point, either the cert >> has been reissued or it hasn't. If it has, the date is >> appropriate. If it hasn't - well the CRL becomes moot as the >> signing cert is no longer valid. >> >> Mike >> >> >> >> At 04:56 PM 2/16/2011, Russ Housley wrote: >>> RFC 5280 says the following about a certificate notAfter field: >>> >>> To indicate that a certificate has no well-defined expiration date, >>> the notAfter SHOULD be assigned the GeneralizedTime value of >>> 99991231235959Z. >>> >>> It seems to me that the same value is appropriate for a CRL. >>> >>> Russ >>> >>> >>> On Feb 16, 2011, at 3:32 PM, Roberto Opazo wrote: >>> >>>> CA being shut down forever. >>>> >>>> 2011/2/16 Russ Housley : >>>>> Is the CA being shut down forever? Or, is a new CA taking over >>>>> using the key rollover stuff specified in CMP? >>>>> >>>>> Russ >>>>> >>>>> >>>>> On Feb 16, 2011, at 1:49 PM, Roberto Opazo wrote: >>>>> >>>>>> Hello: >>>>>> >>>>>> I can't find an specification about what to put in the "Next >>>>>> Update" >>>>>> field of the last CRL issued by one CA in its last day. I mean, >>>>>> the >>>>>> day when this CA certificates expires. >>>>>> >>>>>> Is there any recommendation? >>>>>> >>>>>> Without a recommendation you could chose very different options: >>>>>> >>>>>> * NULL. The field is optional after all, but RFC5280 states >>>>>> "Conforming CRL issuers MUST include the nextUpdate field in all >>>>>> CRLs." >>>>>> >>>>>> * 24 hours, as all other CRL's. But that's a lie, CA is going >>>>>> to be >>>>>> expired in 24 hours, son It can't sign. >>>>>> >>>>>> * Year 2999. So no one alive today is going to be alive that >>>>>> they, but >>>>>> it's a lie any way and there could be systems not prepared to >>>>>> process >>>>>> that date. >>>>>> >>>>>> So, could you help me with an official recommendation? >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> >>>>>> Roberto Opazo >>>>>> _______________________________________________ >>>>>> pkix mailing list >>>>>> pkix@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Saludos, >>>> >>>> Roberto Opazo >>> Alan Sill, Ph.D Senior Scientist, High Performance Computing Center Adjunct Professor of Physics, TTU Vice President of Standards, Open Grid Forum ==================================================================== : Alan Sill, Texas Tech University Office: Drane 162, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ==================================================================== From mstjohns@comcast.net Wed Feb 16 17:57:33 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3BDC3A6BA0 for ; Wed, 16 Feb 2011 17:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBApD6JUlLRa for ; Wed, 16 Feb 2011 17:57:32 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id B4C3E3A6B60 for ; Wed, 16 Feb 2011 17:57:32 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta04.westchester.pa.mail.comcast.net with comcast id 8pQL1g0071vXlb854py3jp; Thu, 17 Feb 2011 01:58:03 +0000 Received: from Mike-PC3.comcast.net ([67.99.198.2]) by omta17.westchester.pa.mail.comcast.net with comcast id 8pxi1g00p03bYCr3dpxmvc; Thu, 17 Feb 2011 01:58:01 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 16 Feb 2011 20:57:40 -0500 To: Alan Sill From: Michael StJohns In-Reply-To: <4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu> References: <20110217012331.055DD3A6BA0@core3.amsl.com> <20110217013359.0A2213A6F09@core3.amsl.com> <4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20110217015732.B4C3E3A6B60@core3.amsl.com> Cc: IETF PKIX , Alan Sill Subject: Re: [pkix] What should be in "Next Update" field of the last CRL? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 01:57:33 -0000 At 08:47 PM 2/16/2011, Alan Sill wrote: >A CA can become inactive for the purposes of issuing new credentials >without necessarily invalidating the certificates already issued. The specific question referred to a CA certificate that was expiring. If the CA certificate expires, then the certificates under that certificate (absent a re-signed replacement) are invalid by definition - or am I missing your point? Mike From alan.sill@ttu.edu Wed Feb 16 18:34:17 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 612453A6CE5 for ; Wed, 16 Feb 2011 18:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aId-qw1Vkfbq for ; Wed, 16 Feb 2011 18:34:16 -0800 (PST) Received: from eurymedon.net.ttu.edu (eurymedon.net.ttu.edu [129.118.1.225]) by core3.amsl.com (Postfix) with ESMTP id 7F5CF3A6C24 for ; Wed, 16 Feb 2011 18:34:16 -0800 (PST) Received: from hoplodamus.net.ttu.edu (129.118.1.213) by tmrc.ttu.edu (129.118.1.179) with Microsoft SMTP Server id 8.2.255.0; Wed, 16 Feb 2011 20:34:45 -0600 Received: from CRIUS.ttu.edu ([129.118.1.211]) by hoplodamus.net.ttu.edu ([129.118.1.213]) with mapi; Wed, 16 Feb 2011 20:34:45 -0600 From: "Sill, Alan" To: Michael StJohns Date: Wed, 16 Feb 2011 20:34:47 -0600 Thread-Topic: [pkix] What should be in "Next Update" field of the last CRL? Thread-Index: AcvOSzynZC2aJKHFQ/uZcmka8B5x3Q== Message-ID: <52B2DBB0-6E2D-4067-B8E3-C8F26E55B0E6@ttu.edu> References: <20110217012331.055DD3A6BA0@core3.amsl.com> <20110217013359.0A2213A6F09@core3.amsl.com> <4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu> <20110217015732.B4C3E3A6B60@core3.amsl.com> In-Reply-To: <20110217015732.B4C3E3A6B60@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received-SPF: Pass (eurymedon.net.ttu.edu: domain of alan.sill@ttu.edu designates 129.118.1.213 as permitted sender) receiver=eurymedon.net.ttu.edu; client-ip=129.118.1.213; helo=hoplodamus.net.ttu.edu; X-TechMail-Edge-Route: TTU Cc: IETF PKIX Subject: Re: [pkix] What should be in "Next Update" field of the last CRL? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 02:34:17 -0000 On Feb 16, 2011, at 7:58 PM, "Michael StJohns" wrote= : > At 08:47 PM 2/16/2011, Alan Sill wrote: >> A CA can become inactive for the purposes of issuing new credentials =20 >> without necessarily invalidating the certificates already issued. >=20 > The specific question referred to a CA certificate that was expiring. If= the CA certificate expires, then the certificates under that certificate (= absent a re-signed replacement) are invalid by definition - or am I missing= your point? >=20 > Mike Mike, Yes, with respect, you're missing my point. The user or relying party has n= o way of determining that your CA is no longer in existence. The CRL server= can convey information about the revoked certificates you have issued from= it previously, if any, and properly written relying party services will fa= il to accept any certificates from your current or previously existing CA a= t any time beyond the last "Next Update" time of your most recently fetched= CRL, but otherwise no one actually communicates with your CA itself to ver= ify its existence. They don't need to, as the public key that they already = have for your CA, along with that of the certificate, are all that they nee= d to check that the cryptography of the certificate is valid.=20 Hope this helps, Alan= From alan.sill@ttu.edu Wed Feb 16 18:37:43 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA3753A6D72 for ; Wed, 16 Feb 2011 18:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFkgxW27oZUJ for ; Wed, 16 Feb 2011 18:37:43 -0800 (PST) Received: from eurymedon.net.ttu.edu (eurymedon.net.ttu.edu [129.118.1.225]) by core3.amsl.com (Postfix) with ESMTP id D4C503A6CE5 for ; Wed, 16 Feb 2011 18:37:42 -0800 (PST) Received: from hyperbius.net.ttu.edu (129.118.1.214) by tmrc.ttu.edu (129.118.1.179) with Microsoft SMTP Server id 8.2.255.0; Wed, 16 Feb 2011 20:38:12 -0600 Received: from CRIUS.ttu.edu ([129.118.1.211]) by hyperbius.net.ttu.edu ([129.118.1.214]) with mapi; Wed, 16 Feb 2011 20:38:12 -0600 From: "Sill, Alan" To: Michael StJohns Date: Wed, 16 Feb 2011 20:38:15 -0600 Thread-Topic: [pkix] What should be in "Next Update" field of the last CRL? Thread-Index: AcvOS7hOUT1KwMFKS7eBPf/PKxyZYA== Message-ID: <60C013EE-3487-4E80-B7DB-CDA73104079B@ttu.edu> References: <20110217012331.055DD3A6BA0@core3.amsl.com> <20110217013359.0A2213A6F09@core3.amsl.com> <4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu> <20110217015732.B4C3E3A6B60@core3.amsl.com> In-Reply-To: <20110217015732.B4C3E3A6B60@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received-SPF: Pass (eurymedon.net.ttu.edu: domain of alan.sill@ttu.edu designates 129.118.1.214 as permitted sender) receiver=eurymedon.net.ttu.edu; client-ip=129.118.1.214; helo=hyperbius.net.ttu.edu; X-TechMail-Edge-Route: TTU Cc: IETF PKIX Subject: Re: [pkix] What should be in "Next Update" field of the last CRL? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 02:37:43 -0000 On Feb 16, 2011, at 7:58 PM, "Michael StJohns" wrote= : > At 08:47 PM 2/16/2011, Alan Sill wrote: >> A CA can become inactive for the purposes of issuing new credentials =20 >> without necessarily invalidating the certificates already issued. >=20 > The specific question referred to a CA certificate that was expiring. If= the CA certificate expires, then the certificates under that certificate (= absent a re-signed replacement) are invalid by definition - or am I missing= your point? >=20 > Mike Woops -- you're right; if the CA certificate itself has expired, then the q= uestion is of course moot.=20 Sorry, I missed that in the original question.=20 Alan= From wwwrun@rfc-editor.org Wed Feb 16 19:13:19 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CC8F3A6C24 for ; Wed, 16 Feb 2011 19:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.4 X-Spam-Level: X-Spam-Status: No, score=-102.4 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAryEnipEVVl for ; Wed, 16 Feb 2011 19:13:18 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 893D63A6C21 for ; Wed, 16 Feb 2011 19:13:18 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 95328E070A; Wed, 16 Feb 2011 19:13:48 -0800 (PST) To: jimsch@exmsft.com, bkaliski@rsasecurity.com, housley@vigilsec.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, tim.polk@nist.gov, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20110217031348.95328E070A@rfc-editor.org> Date: Wed, 16 Feb 2011 19:13:48 -0800 (PST) X-Mailman-Approved-At: Wed, 16 Feb 2011 19:37:37 -0800 Cc: pkix@ietf.org, rfc-editor@rfc-editor.org Subject: [pkix] [Editorial Errata Reported] RFC4055 (2724) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 03:13:19 -0000 The following errata report has been submitted for RFC4055, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4055&eid=2724 -------------------------------------- Type: Editorial Reported by: Sean Turner Section: 2.1 Original Text ------------- id-sha224 OBJECT IDENTIFIER ::= {{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 4 } Corrected Text -------------- id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 4 } Notes ----- There's an extra "{". This is incorrect ASN.1. I marked it as editorial because the ASN.1 module does not contain this error. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4055 (draft-ietf-pkix-rsa-pkalgs-03) -------------------------------------- Title : Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Publication Date : June 2005 Author(s) : J. Schaad, B. Kaliski, R. Housley Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From roberto@opazo.cl Wed Feb 16 19:44:18 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D48663A6B6A for ; Wed, 16 Feb 2011 19:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qT3jDZdiDaV for ; Wed, 16 Feb 2011 19:44:17 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 4DC533A6C37 for ; Wed, 16 Feb 2011 19:44:16 -0800 (PST) Received: by ewy8 with SMTP id 8so914009ewy.31 for ; Wed, 16 Feb 2011 19:44:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.14.136.17 with SMTP id v17mr1547255eei.29.1297914283551; Wed, 16 Feb 2011 19:44:43 -0800 (PST) Received: by 10.14.121.212 with HTTP; Wed, 16 Feb 2011 19:44:43 -0800 (PST) In-Reply-To: <60C013EE-3487-4E80-B7DB-CDA73104079B@ttu.edu> References: <20110217012331.055DD3A6BA0@core3.amsl.com> <20110217013359.0A2213A6F09@core3.amsl.com> <4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu> <20110217015732.B4C3E3A6B60@core3.amsl.com> <60C013EE-3487-4E80-B7DB-CDA73104079B@ttu.edu> Date: Thu, 17 Feb 2011 00:44:43 -0300 Message-ID: From: Roberto Opazo To: "Sill, Alan" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF PKIX Subject: Re: [pkix] What should be in "Next Update" field of the last CRL? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 03:44:18 -0000 Well, the real situation is... Next Monday the CA certificate expires after 10 years of work. So CA certificate has not been expired yet and we have a little time to take some decisions. This is the first time for us on these situation. Next time is going to be in 20 years, so I expect there will be and standard way to finish CA live at that time. Have anybody an experience to share? How have other CAs ended? I think using a 24 hours valid period for the last CRL is not good choice. For instance, the next year a relaying party (RP) could try to validate a valid signature (like an XML signed last week) and the RP will get and expired CRL, I mean a CRL whit "Next Update" field expired. RP would have to note than "Next Update" is pointing to a date out of the CA's certificate validity period and assume that is the reason why there are no other CRL and then, decide to trust in an expired CRL. I think there are no many sw with this logic on the marked. That's why I prefer Rus recommendation, but I think It would be nice having an RFC with a sentence like "CAs conforming to this profile MUST create a final CRL with 99991231235959Z on "Next Update" field. After all, Rus is a guru to me, but I can't say to others "Rus told me to...". So I will have to repeat Rus argument, but It's not the same when it's me or the company I work for, the person saying that. Best regards, Roberto Opazo 2011/2/16 Sill, Alan : > > > > > On Feb 16, 2011, at 7:58 PM, "Michael StJohns" wro= te: > >> At 08:47 PM 2/16/2011, Alan Sill wrote: >>> A CA can become inactive for the purposes of issuing new credentials >>> without necessarily invalidating the certificates already issued. >> >> The specific question referred to a CA certificate that was expiring. = =A0If the CA certificate expires, then the certificates under that certific= ate (absent a re-signed replacement) are invalid by definition - or am I mi= ssing your point? >> >> Mike > > Woops -- you're right; if the CA certificate itself has expired, then the= question is of course moot. > > Sorry, I missed that in the original question. > > Alan > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --=20 Saludos, Roberto Opazo From alan.sill@ttu.edu Wed Feb 16 20:12:28 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E1ED3A6C4E for ; Wed, 16 Feb 2011 20:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03Lj5b0alO6v for ; Wed, 16 Feb 2011 20:12:27 -0800 (PST) Received: from eurymedon.net.ttu.edu (eurymedon.net.ttu.edu [129.118.1.225]) by core3.amsl.com (Postfix) with ESMTP id BE04C3A6C4F for ; Wed, 16 Feb 2011 20:12:27 -0800 (PST) Received: from hippolytus.net.ttu.edu (129.118.1.212) by tmrc.ttu.edu (129.118.1.179) with Microsoft SMTP Server id 8.2.255.0; Wed, 16 Feb 2011 22:12:57 -0600 Received: from CRIUS.ttu.edu ([129.118.1.211]) by hippolytus.net.ttu.edu ([129.118.1.212]) with mapi; Wed, 16 Feb 2011 22:12:56 -0600 From: "Sill, Alan" To: Roberto Opazo Date: Wed, 16 Feb 2011 22:12:59 -0600 Thread-Topic: [pkix] What should be in "Next Update" field of the last CRL? Thread-Index: AcvOWPQ6J12YD7HJTIq+nmKIspyK3A== Message-ID: <0ED5D8F9-C6C9-4599-B343-CEB1003883E9@ttu.edu> References: <20110217012331.055DD3A6BA0@core3.amsl.com> <20110217013359.0A2213A6F09@core3.amsl.com> <4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu> <20110217015732.B4C3E3A6B60@core3.amsl.com> <60C013EE-3487-4E80-B7DB-CDA73104079B@ttu.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received-SPF: Pass (eurymedon.net.ttu.edu: domain of alan.sill@ttu.edu designates 129.118.1.212 as permitted sender) receiver=eurymedon.net.ttu.edu; client-ip=129.118.1.212; helo=hippolytus.net.ttu.edu; X-TechMail-Edge-Route: TTU Cc: IETF PKIX Subject: Re: [pkix] What should be in "Next Update" field of the last CRL? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 04:12:28 -0000 On Feb 16, 2011, at 9:45 PM, "Roberto Opazo" wrote: > I think using a 24 hours valid period for the last CRL is not good > choice. For instance, the next year a relaying party (RP) could try to > validate a valid signature (like an XML signed last week) and the RP > will get and expired CRL, I mean a CRL whit "Next Update" field > expired. RP would have to note than "Next Update" is pointing to a > date out of the CA's certificate validity period and assume that is > the reason why there are no other CRL and then, decide to trust in an > expired CRL. Any correctly implemented RP software would fail to validate any certificat= e from a CA with an expired CA certificate, or any certificate at all from = a CA that has a most recent "Next Update" in the past. Itdoes no good to se= cond-guess conditions under which a RP would trust a cert that they cannot = check for possible revocation. = From denis.pinkas@bull.net Thu Feb 17 02:03:14 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEB1E3A6DD7 for ; Thu, 17 Feb 2011 02:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.342 X-Spam-Level: ** X-Spam-Status: No, score=2.342 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_BAD_ID=2.837] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShyxYff-GI5Z for ; Thu, 17 Feb 2011 02:03:13 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by core3.amsl.com (Postfix) with ESMTP id 8AA3D3A6DB8 for ; Thu, 17 Feb 2011 02:03:12 -0800 (PST) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (Bull S.A.) with ESMTP id E304C158096; Thu, 17 Feb 2011 11:11:32 +0100 (CET) Received: from B016404 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2011021711033958:23688 ; Thu, 17 Feb 2011 11:03:39 +0100 From: "Denis Pinkas" To: "roberto" Date: Thu, 17 Feb 2011 11:03:37 +0100 Message-Id: References: MIME-Version: 1.0 X-Priority: 3 (Normal) X-Mailer: DreamMail 4.4.1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 17/02/2011 11:03:39, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 17/02/2011 11:03:41, Serialize complete at 17/02/2011 11:03:41 Content-Type: multipart/alternative; boundary="----=_NextPart_11021711033730107252573_002" Cc: pkix Subject: Re: [pkix] What should be in "Next Update" field of the last CRL? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: denis.pinkas@bull.net List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 10:03:14 -0000 ------=_NextPart_11021711033730107252573_002 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="ISO-8859-1" UnVzcywNCg0KSSBkb24ndCBiZWxpZXZlIHRoYXQgdXNpbmcgOTk5OTEyMzEyMzU5NTlaIGlzIHRo ZSBiZXN0IGFwcHJvYWNoIHNpbmNlIHRoaXMgdmFsdWUgaXMgdG8gYmUgdXNlZCBmb3IgdGhlIGNl cnRpZmljYXRlIHZhbGlkaXR5IHBlcmlvZCBvbmx5Lg0KSXRzIHNlbWFudGljcyBpcyBub3QgYXBw cm9wcmlhdGUgZWl0aGVyLiBNYW55IGltcGxlbWVudGF0aW9ucyBtaWdodCBmYWlsIHdpdGggc3Vj aCBhIHZhbHVlLg0KDQpTaW5jZSB0aGVyZSBpcyBubyBwcmVmZWN0IHNvbHV0aW9uLCB0aGUgYmVz dCBJIGNhbiBpbWFnaW5lIGlzIHRoZSBmb2xsb3dpbmc6DQoNCiAtIHBsYWNlIHRoZSBlbmQgb2Yg dmFsaWRpdHkgb2YgdGhlIHJvb3Qga2V5IGFzIHRoZSBuZXh0dXBkYXRlIGZpZWxkIG9mIHRoZSBs YXN0IGlzc3VlZCBDUkwuDQoNCiAgIEFsbCBpbXBsZW50YXRpb25zIHdpbGwgd29yayBuaWNlbHku IA0KICAgSXQgaXMgdHJ1ZSB0aGF0IGl0IGlzIGEgbGllLCBzaW5jZSBubyBDUkwgd2lsbCBiZSBp c3N1ZWQgYXQgdGhhdCBkYXRlLCBidXQgDQogICBzaW5jZSB0aGUgQ0Egd2lsbCBiZSBkZWFkIG9u ZSBzZWNvbmQgYWZ0ZXIgdGhhdCBkYXRlLA0KICAgbm8gb25lIGNhbiBjb21wbHkgYWJvdXQgYSBk ZWFkIGF1dGhvcml0eS4NCg0KRGVuaXMNCi0tLS0tIE1lc3NhZ2UgcmXndSAtLS0tLSANCkRlIDog cGtpeC1ib3VuY2VzIA0KwCA6IFJvYmVydG8gT3Bhem8gDQpEYXRlIDogMjAxMS0wMi0xNiwgMjI6 NTY6MDgNClN1amV0IDogUmU6IFtwa2l4XSBXaGF0IHNob3VsZCBiZSBpbiAiTmV4dCBVcGRhdGUi IGZpZWxkIG9mIHRoZSBsYXN0IENSTD8NCg0KDQpSRkMgNTI4MCBzYXlzIHRoZSBmb2xsb3dpbmcg YWJvdXQgYSBjZXJ0aWZpY2F0ZSBub3RBZnRlciBmaWVsZDoNCg0KICAgVG8gaW5kaWNhdGUgdGhh dCBhIGNlcnRpZmljYXRlIGhhcyBubyB3ZWxsLWRlZmluZWQgZXhwaXJhdGlvbiBkYXRlLA0KICAg dGhlIG5vdEFmdGVyIFNIT1VMRCBiZSBhc3NpZ25lZCB0aGUgR2VuZXJhbGl6ZWRUaW1lIHZhbHVl IG9mDQogICA5OTk5MTIzMTIzNTk1OVouDQoNCkl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIHNhbWUg dmFsdWUgaXMgYXBwcm9wcmlhdGUgZm9yIGEgQ1JMLg0KDQpSdXNzDQoNCg0KT24gRmViIDE2LCAy MDExLCBhdCAzOjMyIFBNLCBSb2JlcnRvIE9wYXpvIHdyb3RlOg0KDQo+IENBIGJlaW5nIHNodXQg ZG93biBmb3JldmVyLg0KPiANCj4gMjAxMS8yLzE2IFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdp bHNlYy5jb20+Og0KPj4gSXMgdGhlIENBIGJlaW5nIHNodXQgZG93biBmb3JldmVyPyBPciwgaXMg YSBuZXcgQ0EgdGFraW5nIG92ZXIgdXNpbmcgdGhlIGtleSByb2xsb3ZlciBzdHVmZiBzcGVjaWZp ZWQgaW4gQ01QPw0KPj4gDQo+PiBSdXNzDQo+PiANCj4+IA0KPj4gT24gRmViIDE2LCAyMDExLCBh dCAxOjQ5IFBNLCBSb2JlcnRvIE9wYXpvIHdyb3RlOg0KPj4gDQo+Pj4gSGVsbG86DQo+Pj4gDQo+ Pj4gSSBjYW4ndCBmaW5kIGFuIHNwZWNpZmljYXRpb24gYWJvdXQgd2hhdCB0byBwdXQgaW4gdGhl ICJOZXh0IFVwZGF0ZSINCj4+PiBmaWVsZCBvZiB0aGUgbGFzdCBDUkwgaXNzdWVkIGJ5IG9uZSBD QSBpbiBpdHMgbGFzdCBkYXkuIEkgbWVhbiwgdGhlDQo+Pj4gZGF5IHdoZW4gdGhpcyBDQSBjZXJ0 aWZpY2F0ZXMgZXhwaXJlcy4NCj4+PiANCj4+PiBJcyB0aGVyZSBhbnkgcmVjb21tZW5kYXRpb24/ DQo+Pj4gDQo+Pj4gV2l0aG91dCBhIHJlY29tbWVuZGF0aW9uIHlvdSBjb3VsZCBjaG9zZSB2ZXJ5 IGRpZmZlcmVudCBvcHRpb25zOg0KPj4+IA0KPj4+ICogTlVMTC4gVGhlIGZpZWxkIGlzIG9wdGlv bmFsIGFmdGVyIGFsbCwgYnV0IFJGQzUyODAgc3RhdGVzDQo+Pj4gIkNvbmZvcm1pbmcgQ1JMIGlz c3VlcnMgTVVTVCBpbmNsdWRlIHRoZSBuZXh0VXBkYXRlIGZpZWxkIGluIGFsbA0KPj4+IENSTHMu Ig0KPj4+IA0KPj4+ICogMjQgaG91cnMsIGFzIGFsbCBvdGhlciBDUkwncy4gQnV0IHRoYXQncyBh IGxpZSwgQ0EgaXMgZ29pbmcgdG8gYmUNCj4+PiBleHBpcmVkIGluIDI0IGhvdXJzLCBzb24gSXQg Y2FuJ3Qgc2lnbi4NCj4+PiANCj4+PiAqIFllYXIgMjk5OS4gU28gbm8gb25lIGFsaXZlIHRvZGF5 IGlzIGdvaW5nIHRvIGJlIGFsaXZlIHRoYXQgdGhleSwgYnV0DQo+Pj4gaXQncyBhIGxpZSBhbnkg d2F5IGFuZCB0aGVyZSBjb3VsZCBiZSBzeXN0ZW1zIG5vdCBwcmVwYXJlZCB0byBwcm9jZXNzDQo+ Pj4gdGhhdCBkYXRlLg0KPj4+IA0KPj4+IFNvLCBjb3VsZCB5b3UgaGVscCBtZSB3aXRoIGFuIG9m ZmljaWFsIHJlY29tbWVuZGF0aW9uPw0KPj4+IA0KPj4+IC0tDQo+Pj4gQmVzdCByZWdhcmRzLA0K Pj4+IA0KPj4+IFJvYmVydG8gT3Bhem8NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+IHBraXggbWFpbGluZyBsaXN0DQo+Pj4gcGtpeEBpZXRm Lm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGtpeA0KPj4g DQo+PiANCj4gDQo+IA0KPiANCj4gLS0gDQo+IFNhbHVkb3MsDQo+IA0KPiBSb2JlcnRvIE9wYXpv DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwa2l4 IG1haWxpbmcgbGlzdA0KcGtpeEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9wa2l4DQo= ------=_NextPart_11021711033730107252573_002 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="ISO-8859-1" PEhUTUw+PEhFQUQ+PFRJVExFPjwvVElUTEU+DQo8TUVUQSBjb250ZW50PSJLc0RIVE1MRURMaWIu b2N4LCBGcmVlV2FyZSBIVE1MIEVkaXRvciAxLjE2NC4yLCCpIEt1cnQgU2VuZmVyIiANCm5hbWU9 R0VORVJBVE9SPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPjwvSEVBRD4NCjxCT0RZIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBUYWhvbWEiIGxlZnRNYXJnaW49NSB0b3BNYXJnaW49NSANCiNm ZmZmZmY+DQo8RElWPlJ1c3MsPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5JIGRvbid0 IGJlbGlldmUgdGhhdCB1c2luZyA5OTk5MTIzMTIzNTk1OVogaXMgdGhlIGJlc3QgYXBwcm9hY2gg c2luY2UgdGhpcyANCnZhbHVlIGlzIHRvIGJlIHVzZWQgZm9yIHRoZSA8U1BBTiBsYW5nPUVOLVVT IA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4n OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1hbnNpLWxh bmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEZSOyBtc28tYmlkaS1sYW5ndWFn ZTogQVItU0EiPmNlcnRpZmljYXRlIA0KdmFsaWRpdHkgcGVyaW9kIG9ubHk8L1NQQU4+LjxCUj5J dHMgc2VtYW50aWNzIGlzIG5vdCBhcHByb3ByaWF0ZSBlaXRoZXIuIE1hbnkgDQppbXBsZW1lbnRh dGlvbnMgbWlnaHQmbmJzcDtmYWlsIHdpdGggc3VjaCBhIHZhbHVlLjwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+U2luY2UgdGhlcmUgaXMgbm8gcHJlZmVjdCBzb2x1dGlvbiwgdGhlIGJl c3QgSSBjYW4gaW1hZ2luZSBpcyB0aGUgDQpmb2xsb3dpbmc6PC9ESVY+DQo8RElWPiZuYnNwOzwv RElWPg0KPERJVj4mbmJzcDstIHBsYWNlIHRoZSBlbmQgb2YgdmFsaWRpdHkgb2YgdGhlIHJvb3Qg a2V5IGFzIHRoZSBuZXh0dXBkYXRlIGZpZWxkIA0Kb2YgdGhlIGxhc3QgaXNzdWVkIENSTC48QlI+ PEJSPiZuYnNwOyZuYnNwOyZuYnNwO0FsbCBpbXBsZW50YXRpb25zIHdpbGwgd29yayANCm5pY2Vs eS4mbmJzcDs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7SXQgaXMgdHJ1ZSB0aGF0IGl0IGlzJm5ic3A7 YSBsaWUsJm5ic3A7c2luY2UgDQpubyBDUkwgd2lsbCBiZSBpc3N1ZWQgYXQgdGhhdCBkYXRlLCBi dXQgPEJSPiZuYnNwOyZuYnNwOyBzaW5jZSB0aGUgQ0Egd2lsbCANCmJlJm5ic3A7ZGVhZCBvbmUg c2Vjb25kIGFmdGVyIHRoYXQgZGF0ZSw8QlI+Jm5ic3A7Jm5ic3A7IG5vIG9uZSBjYW4gY29tcGx5 IGFib3V0IA0KYSBkZWFkIGF1dGhvcml0eS48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PjwvRElWPg0KPERJVj48IS0tQUlEX0ZST01OQU1FX0JFR0lOLS0+RGVuaXM8L0RJVj4NCjxCTE9D S1FVT1RFIA0Kc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1B UkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJ R0hUOiAwcHgiPg0KICA8RElWIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IG5vcm1hbDsgRk9OVC1T SVpFOiA5cHQ7IExJTkUtSEVJR0hUOiBub3JtYWw7IEZPTlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1W QVJJQU5UOiBub3JtYWwiPi0tLS0tIA0KICBNZXNzYWdlIHJl53UgLS0tLS0gPC9ESVY+DQogIDxE SVYgDQogIHN0eWxlPSJGT05ULVdFSUdIVDogbm9ybWFsOyBGT05ULVNJWkU6IDlwdDsgQkFDS0dS T1VORDogI2U0ZTRlNDsgTElORS1IRUlHSFQ6IG5vcm1hbDsgRk9OVC1TVFlMRTogbm9ybWFsOyBG T05ULVZBUklBTlQ6IG5vcm1hbDsgZm9udC1jb2xvcjogYmxhY2siPjxCPkRlIA0KICA6PC9CPiA8 QSBocmVmPSJtYWlsdG8gOnBraXgtYm91bmNlc0BpZXRmLm9yZyI+cGtpeC1ib3VuY2VzPC9BPiA8 L0RJVj4NCiAgPERJViANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBub3JtYWw7IEZPTlQtU0laRTog OXB0OyBMSU5FLUhFSUdIVDogbm9ybWFsOyBGT05ULVNUWUxFOiBub3JtYWw7IEZPTlQtVkFSSUFO VDogbm9ybWFsIj48Qj7AIA0KICA6PC9CPiA8QSBocmVmPSJtYWlsdG8gOnJvYmVydG9Ab3Bhem8u Y2wiPlJvYmVydG8gT3Bhem88L0E+IDwvRElWPg0KICA8RElWIA0KICBzdHlsZT0iRk9OVC1XRUlH SFQ6IG5vcm1hbDsgRk9OVC1TSVpFOiA5cHQ7IExJTkUtSEVJR0hUOiBub3JtYWw7IEZPTlQtU1RZ TEU6IG5vcm1hbDsgRk9OVC1WQVJJQU5UOiBub3JtYWwiPjxCPkRhdGUgDQogIDo8L0I+IDIwMTEt MDItMTYsIDIyOjU2OjA4PC9ESVY+DQogIDxESVYgDQogIHN0eWxlPSJGT05ULVdFSUdIVDogbm9y bWFsOyBGT05ULVNJWkU6IDlwdDsgTElORS1IRUlHSFQ6IG5vcm1hbDsgRk9OVC1TVFlMRTogbm9y bWFsOyBGT05ULVZBUklBTlQ6IG5vcm1hbCI+PEI+U3VqZXQgDQogIDo8L0I+IFJlOiBbcGtpeF0g V2hhdCBzaG91bGQgYmUgaW4gIk5leHQgVXBkYXRlIiBmaWVsZCBvZiB0aGUgbGFzdCBDUkw/PC9E SVY+DQogIDxESVY+PEJSPjwvRElWPg0KICA8RElWPjwvRElWPg0KICA8RElWPjwvRElWPg0KICA8 RElWPg0KICA8RElWPlJGQyA1MjgwIHNheXMgdGhlIGZvbGxvd2luZyBhYm91dCBhIGNlcnRpZmlj YXRlIG5vdEFmdGVyIA0KICBmaWVsZDo8QlI+PEJSPiZuYnNwOyZuYnNwOyZuYnNwO1RvIGluZGlj YXRlIHRoYXQgYSBjZXJ0aWZpY2F0ZSBoYXMgbm8gDQogIHdlbGwtZGVmaW5lZCBleHBpcmF0aW9u IGRhdGUsPEJSPiZuYnNwOyZuYnNwOyZuYnNwO3RoZSBub3RBZnRlciBTSE9VTEQgYmUgDQogIGFz c2lnbmVkIHRoZSBHZW5lcmFsaXplZFRpbWUgdmFsdWUgDQogIG9mPEJSPiZuYnNwOyZuYnNwOyZu YnNwOzk5OTkxMjMxMjM1OTU5Wi48QlI+PEJSPkl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIHNhbWUg DQogIHZhbHVlIGlzIGFwcHJvcHJpYXRlIGZvciBhIENSTC48QlI+PEJSPlJ1c3M8QlI+PEJSPjxC Uj5PbiBGZWIgMTYsIDIwMTEsIGF0IA0KICAzOjMyIFBNLCBSb2JlcnRvIE9wYXpvIHdyb3RlOjxC Uj48QlI+Jmd0OyBDQSBiZWluZyBzaHV0IGRvd24gZm9yZXZlci48QlI+Jmd0OyANCiAgPEJSPiZn dDsgMjAxMS8yLzE2IFJ1c3MgSG91c2xleSAmbHQ7PEEgDQogIGhyZWY9Im1haWx0bzogaG91c2xl eUB2aWdpbHNlYy5jb20iPmhvdXNsZXlAdmlnaWxzZWMuY29tPC9BPiZndDs6PEJSPiZndDsmZ3Q7 IA0KICBJcyB0aGUgQ0EgYmVpbmcgc2h1dCBkb3duIGZvcmV2ZXI/IE9yLCBpcyBhIG5ldyBDQSB0 YWtpbmcgb3ZlciB1c2luZyB0aGUga2V5IA0KICByb2xsb3ZlciBzdHVmZiBzcGVjaWZpZWQgaW4g Q01QPzxCUj4mZ3Q7Jmd0OyA8QlI+Jmd0OyZndDsgUnVzczxCUj4mZ3Q7Jmd0OyANCiAgPEJSPiZn dDsmZ3Q7IDxCUj4mZ3Q7Jmd0OyBPbiBGZWIgMTYsIDIwMTEsIGF0IDE6NDkgUE0sIFJvYmVydG8g T3Bhem8gDQogIHdyb3RlOjxCUj4mZ3Q7Jmd0OyA8QlI+Jmd0OyZndDsmZ3Q7IEhlbGxvOjxCUj4m Z3Q7Jmd0OyZndDsgPEJSPiZndDsmZ3Q7Jmd0OyBJIA0KICBjYW4ndCBmaW5kIGFuIHNwZWNpZmlj YXRpb24gYWJvdXQgd2hhdCB0byBwdXQgaW4gdGhlICJOZXh0IA0KICBVcGRhdGUiPEJSPiZndDsm Z3Q7Jmd0OyBmaWVsZCBvZiB0aGUgbGFzdCBDUkwgaXNzdWVkIGJ5IG9uZSBDQSBpbiBpdHMgbGFz dCANCiAgZGF5LiBJIG1lYW4sIHRoZTxCUj4mZ3Q7Jmd0OyZndDsgZGF5IHdoZW4gdGhpcyBDQSBj ZXJ0aWZpY2F0ZXMgDQogIGV4cGlyZXMuPEJSPiZndDsmZ3Q7Jmd0OyA8QlI+Jmd0OyZndDsmZ3Q7 IElzIHRoZXJlIGFueSANCiAgcmVjb21tZW5kYXRpb24/PEJSPiZndDsmZ3Q7Jmd0OyA8QlI+Jmd0 OyZndDsmZ3Q7IFdpdGhvdXQgYSByZWNvbW1lbmRhdGlvbiB5b3UgDQogIGNvdWxkIGNob3NlIHZl cnkgZGlmZmVyZW50IG9wdGlvbnM6PEJSPiZndDsmZ3Q7Jmd0OyA8QlI+Jmd0OyZndDsmZ3Q7ICog TlVMTC4gDQogIFRoZSBmaWVsZCBpcyBvcHRpb25hbCBhZnRlciBhbGwsIGJ1dCBSRkM1MjgwIHN0 YXRlczxCUj4mZ3Q7Jmd0OyZndDsgDQogICJDb25mb3JtaW5nIENSTCBpc3N1ZXJzIE1VU1QgaW5j bHVkZSB0aGUgbmV4dFVwZGF0ZSBmaWVsZCBpbiANCiAgYWxsPEJSPiZndDsmZ3Q7Jmd0OyBDUkxz LiI8QlI+Jmd0OyZndDsmZ3Q7IDxCUj4mZ3Q7Jmd0OyZndDsgKiAyNCBob3VycywgYXMgYWxsIA0K ICBvdGhlciBDUkwncy4gQnV0IHRoYXQncyBhIGxpZSwgQ0EgaXMgZ29pbmcgdG8gYmU8QlI+Jmd0 OyZndDsmZ3Q7IGV4cGlyZWQgaW4gMjQgDQogIGhvdXJzLCBzb24gSXQgY2FuJ3Qgc2lnbi48QlI+ Jmd0OyZndDsmZ3Q7IDxCUj4mZ3Q7Jmd0OyZndDsgKiBZZWFyIDI5OTkuIFNvIG5vIA0KICBvbmUg YWxpdmUgdG9kYXkgaXMgZ29pbmcgdG8gYmUgYWxpdmUgdGhhdCB0aGV5LCBidXQ8QlI+Jmd0OyZn dDsmZ3Q7IGl0J3MgYSBsaWUgDQogIGFueSB3YXkgYW5kIHRoZXJlIGNvdWxkIGJlIHN5c3RlbXMg bm90IHByZXBhcmVkIHRvIHByb2Nlc3M8QlI+Jmd0OyZndDsmZ3Q7IA0KICB0aGF0IGRhdGUuPEJS PiZndDsmZ3Q7Jmd0OyA8QlI+Jmd0OyZndDsmZ3Q7IFNvLCBjb3VsZCB5b3UgaGVscCBtZSB3aXRo IGFuIA0KICBvZmZpY2lhbCByZWNvbW1lbmRhdGlvbj88QlI+Jmd0OyZndDsmZ3Q7IDxCUj4mZ3Q7 Jmd0OyZndDsgLS08QlI+Jmd0OyZndDsmZ3Q7IA0KICBCZXN0IHJlZ2FyZHMsPEJSPiZndDsmZ3Q7 Jmd0OyA8QlI+Jmd0OyZndDsmZ3Q7IFJvYmVydG8gT3Bhem88QlI+Jmd0OyZndDsmZ3Q7IA0KICBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4mZ3Q7Jmd0 OyZndDsgcGtpeCBtYWlsaW5nIA0KICBsaXN0PEJSPiZndDsmZ3Q7Jmd0OyA8QSANCiAgaHJlZj0i bWFpbHRvOiBwa2l4QGlldGYub3JnIj5wa2l4QGlldGYub3JnPC9BPjxCUj4mZ3Q7Jmd0OyZndDsg PEEgDQogIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGtpeCI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wa2l4PC9BPjxCUj4mZ3Q7Jmd0 OyANCiAgPEJSPiZndDsmZ3Q7IDxCUj4mZ3Q7IDxCUj4mZ3Q7IDxCUj4mZ3Q7IDxCUj4mZ3Q7IC0t IDxCUj4mZ3Q7IFNhbHVkb3MsPEJSPiZndDsgDQogIDxCUj4mZ3Q7IFJvYmVydG8gDQogIE9wYXpv PEJSPjxCUj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxC Uj5wa2l4IG1haWxpbmcgDQogIGxpc3Q8QlI+PEEgaHJlZj0ibWFpbHRvOiBwa2l4QGlldGYub3Jn Ij5wa2l4QGlldGYub3JnPC9BPjxCUj48QSANCiAgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wa2l4Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3BraXg8L0E+PEJSPjxCUj48L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRN TD4NCg== ------=_NextPart_11021711033730107252573_002-- From tmiller@mitre.org Thu Feb 17 05:50:23 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B973A6CAC for ; Thu, 17 Feb 2011 05:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckeyyRrNniE8 for ; Thu, 17 Feb 2011 05:50:19 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id A45493A6CC6 for ; Thu, 17 Feb 2011 05:50:19 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0976521B1782; Thu, 17 Feb 2011 08:50:49 -0500 (EST) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0244B21B1635; Thu, 17 Feb 2011 08:50:49 -0500 (EST) Received: from IMCMBX2.MITRE.ORG ([129.83.29.209]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Thu, 17 Feb 2011 08:50:06 -0500 From: "Miller, Timothy J." To: Roberto Opazo Date: Thu, 17 Feb 2011 08:50:04 -0500 Thread-Topic: [pkix] What should be in "Next Update" field of the last CRL? Thread-Index: AcvOqZVO3bnMKeMMTkCWvWAirCa1hw== Message-ID: <0E53BA7F-61B8-4BA6-B13C-CF3B2A615CE9@mitre.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-3--331658391"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: IETF Subject: Re: [pkix] What should be in "Next Update" field of the last CRL? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 13:50:23 -0000 --Apple-Mail-3--331658391 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Simple answer: the notAfter date of the issuing CA. No cert issued by = the CA is valid after this date anyway, so the CRL is moot thereafter. -- Tim On Feb 16, 2011, at 12:49 PM, Roberto Opazo wrote: > Hello: >=20 > I can't find an specification about what to put in the "Next Update" > field of the last CRL issued by one CA in its last day. I mean, the > day when this CA certificates expires. >=20 > Is there any recommendation? >=20 > Without a recommendation you could chose very different options: >=20 > * NULL. The field is optional after all, but RFC5280 states > "Conforming CRL issuers MUST include the nextUpdate field in all > CRLs." >=20 > * 24 hours, as all other CRL's. But that's a lie, CA is going to be > expired in 24 hours, son It can't sign. >=20 > * Year 2999. So no one alive today is going to be alive that they, but > it's a lie any way and there could be systems not prepared to process > that date. >=20 > So, could you help me with an official recommendation? >=20 > --=20 > Best regards, >=20 > Roberto Opazo > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail-3--331658391 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTAyMTcxMzUwMDVaMCMGCSqGSIb3DQEJBDEWBBRiZXW78B/tE260HtXT 411/C1+vtTByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgBeBientluNZRipoDyU4dlxCfg5pT01R1H3g 1KgJgRkBxWOTyheqU2g5LxEjYwatmel2HUvrAXKbTyrbSoMKfek0flT+GP3kYLEZ3eGOH2hlueIz VvPv9SCxzxuZdY5oH0mEQNlY02PE+3T8Y/lSRfyXtG42UzrpT8LOD1Amt9ZcAAAAAAAA --Apple-Mail-3--331658391-- From tmiller@mitre.org Thu Feb 17 06:01:36 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D5D23A6B6C for ; Thu, 17 Feb 2011 06:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUtBFtJhY4u3 for ; Thu, 17 Feb 2011 06:01:34 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id D15D93A6E0C for ; Thu, 17 Feb 2011 06:01:29 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D82EE21B0060; Thu, 17 Feb 2011 09:01:48 -0500 (EST) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D1CB821B177D; Thu, 17 Feb 2011 09:01:48 -0500 (EST) Received: from IMCMBX2.MITRE.ORG ([129.83.29.209]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Thu, 17 Feb 2011 09:01:48 -0500 From: "Miller, Timothy J." To: Roberto Opazo Date: Thu, 17 Feb 2011 09:01:45 -0500 Thread-Topic: [pkix] What should be in "Next Update" field of the last CRL? Thread-Index: AcvOqzdYU6ydrxVuR16j5AdswmnJ2w== Message-ID: References: <20110217012331.055DD3A6BA0@core3.amsl.com> <20110217013359.0A2213A6F09@core3.amsl.com> <4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu> <20110217015732.B4C3E3A6B60@core3.amsl.com> <60C013EE-3487-4E80-B7DB-CDA73104079B@ttu.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-4--330957668"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] What should be in "Next Update" field of the last CRL? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 14:01:36 -0000 --Apple-Mail-4--330957668 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 16, 2011, at 9:44 PM, Roberto Opazo wrote: > Well, the real situation is... Next Monday the CA certificate expires > after 10 years of work. So CA certificate has not been expired yet and > we have a little time to take some decisions. Subscriber certs should have a notAfter date equal to the maximum = validity period or the notAfter date of the issuer's certificate, = *whichever is shorter*. =20 However, even this doesn't matter because subscriber certs are invalid = when the CA cert expires no matter what notAfter date they assert. Any = cert or CRL which claims dates past this date is moot. "Proper" PKI planning would have each CA retire from active issuance but = remain to issue CRLs until all subscriber certs have expired; this = 'inactive' period is equal to the maximum validity period of the certs = it issued. At that point the CA can simply be shut off (assuming you've = archived all the artifacts you need for proving validity of historical = signatures). This is an operational nicety rather than a technical one, = as it's the only way to extract the full validity period for all issued = certs; failure to do so means as the CA cert expiry time approaches the = subscriber cert lifecycle gets shorter and shorter. OTOH, you *could* simply resign the CA key, assuming you're OK with that = key remaining in service. I don't recommend this option but I think it = would technically work. As long as the SKID and Subject DN don't = change, relying parties may still be able to build a valid chain. -- Tim --Apple-Mail-4--330957668 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTAyMTcxNDAxNDZaMCMGCSqGSIb3DQEJBDEWBBTfSsruTU4jZeRgqzMG 32N+YzyXhzByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgBKWYi9iZUV8WCiNI+5ASvyQkUu25v9pAkMR XH2Arh32T9UfHE9A8Theo8+JnGpj3E2MqDTJkPUxbHku2XyU8rej64wftIFlkUoyNA9edofXqgEr +6b8qMlftkR/sFm1GiwruFC2WsQ65cRO70i9Be9PLqW1/S0LYFohrMt+qp0LAAAAAAAA --Apple-Mail-4--330957668-- From tmiller@mitre.org Thu Feb 17 06:05:43 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E7B03A6CAC for ; Thu, 17 Feb 2011 06:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ep2dzDiuTksa for ; Thu, 17 Feb 2011 06:05:42 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 9AA743A6B6C for ; Thu, 17 Feb 2011 06:05:41 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D213021B0D9E; Thu, 17 Feb 2011 09:06:12 -0500 (EST) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C26D421B0D91; Thu, 17 Feb 2011 09:06:12 -0500 (EST) Received: from IMCMBX2.MITRE.ORG ([129.83.29.209]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Thu, 17 Feb 2011 09:06:12 -0500 From: "Miller, Timothy J." To: "Sill, Alan" Date: Thu, 17 Feb 2011 09:06:05 -0500 Thread-Topic: [pkix] What should be in "Next Update" field of the last CRL? Thread-Index: AcvOq9TxB5r5qQ2ySW+wvRvgqZLA0A== Message-ID: References: <20110217012331.055DD3A6BA0@core3.amsl.com> <20110217013359.0A2213A6F09@core3.amsl.com> <4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu> <20110217015732.B4C3E3A6B60@core3.amsl.com> <60C013EE-3487-4E80-B7DB-CDA73104079B@ttu.edu> <0ED5D8F9-C6C9-4599-B343-CEB1003883E9@ttu.edu> In-Reply-To: <0ED5D8F9-C6C9-4599-B343-CEB1003883E9@ttu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-5--330697875"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] What should be in "Next Update" field of the last CRL? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 14:05:43 -0000 --Apple-Mail-5--330697875 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 16, 2011, at 10:12 PM, Sill, Alan wrote: > Any correctly implemented RP software would fail to validate any = certificate from a CA with an expired CA certificate, or any certificate = at all from a CA that has a most recent "Next Update" in the past. ITYM CRL instead of CA; only CRLs have nextUpdate. That said, you're incorrect. CRLs don't expire. CRLs only go stale. A = relying party that uses a stale CRLs increases its risk of accepting = revoked certs, but they remain valid statements from the CA. It *is* = common for RPs to *interpret* netUpdate as a "CRL expiry" date, but it = is most certainly not correct to do so. In fact, in some operational = scenarios (e.g., intermittently connected networks) this interpretation = causes denial-of-service. -- Tim --Apple-Mail-5--330697875 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTAyMTcxNDA2MDZaMCMGCSqGSIb3DQEJBDEWBBTrcfEWU/LdaEIP+cQV 6emDoQxRBjByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgBeCapE+n46y3PnwbSY/yFk/75CNMtOWlW7T LImmiOanFR1AYg5j0U5N40PEskLtKV2P7J3H4ckAnRH6GWqJ3z8wpKxVES2BOVAKmb8bRqLmYgl/ 5fQmwApZhP4+dUn+Rgov2vmISicp5S6ZzRkNOxhdkLjy11RyLXgCnKQ8h5bLAAAAAAAA --Apple-Mail-5--330697875-- From nuno.ponte@multicert.com Thu Feb 17 06:10:43 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88FA43A6E0A for ; Thu, 17 Feb 2011 06:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nB537BBvYox for ; Thu, 17 Feb 2011 06:10:39 -0800 (PST) Received: from mail.multicert.com (mail.multicert.com [62.48.217.200]) by core3.amsl.com (Postfix) with ESMTP id 8F7623A6DFE for ; Thu, 17 Feb 2011 06:10:38 -0800 (PST) Received: from [192.168.128.136] (33.14.103.87.rev.vodafone.pt [87.103.14.33]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Nuno Miguel Arieiro Rodrigues da Ponte", Issuer "MULTICERT-CA 02" (verified OK)) by mail.multicert.com (Postfix) with ESMTP id B7BA713DD5C; Thu, 17 Feb 2011 14:11:08 +0000 (WET) Message-ID: <4D5D2C7B.7070204@multicert.com> Date: Thu, 17 Feb 2011 14:11:07 +0000 From: Nuno Ponte Organization: MULTICERT - =?ISO-8859-1?Q?Servi=E7os_de_Certifica=E7=E3?= =?ISO-8859-1?Q?o_Electr=F3nica=2C_S=2EA=2E?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; pt-PT; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: "Miller, Timothy J." References: <0E53BA7F-61B8-4BA6-B13C-CF3B2A615CE9@mitre.org> In-Reply-To: <0E53BA7F-61B8-4BA6-B13C-CF3B2A615CE9@mitre.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020704010500020404000101" Cc: IETF Subject: Re: [pkix] What should be in "Next Update" field of the last CRL? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 14:10:43 -0000 This is a cryptographically signed message in MIME format. --------------ms020704010500020404000101 Content-Type: multipart/alternative; boundary="------------090700010100040806040601" This is a multi-part message in MIME format. --------------090700010100040806040601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, That was also the first thing that came to my mind when I read this = question. However, if a certificate is revoked meanwhile, that means it will=20 never show up in an issued CRL. What about having a last and definitive=20 CRL created at exactly the CA expire date, i.e. CRL_thisUpdate =3D=20 CRL_nextUpdate =3D CA_notAfter ? Regards, Nuno Ponte Em 17-02-2011 13:50, Miller, Timothy J. escreveu: > Simple answer: the notAfter date of the issuing CA. No cert issued by = the CA is valid after this date anyway, so the CRL is moot thereafter. > > -- Tim > > On Feb 16, 2011, at 12:49 PM, Roberto Opazo wrote: > >> Hello: >> >> I can't find an specification about what to put in the "Next Update" >> field of the last CRL issued by one CA in its last day. I mean, the >> day when this CA certificates expires. >> >> Is there any recommendation? >> >> Without a recommendation you could chose very different options: >> >> * NULL. The field is optional after all, but RFC5280 states >> "Conforming CRL issuers MUST include the nextUpdate field in all >> CRLs." >> >> * 24 hours, as all other CRL's. But that's a lie, CA is going to be >> expired in 24 hours, son It can't sign. >> >> * Year 2999. So no one alive today is going to be alive that they, but= >> it's a lie any way and there could be systems not prepared to process >> that date. >> >> So, could you help me with an official recommendation? >> >> --=20 >> Best regards, >> >> Roberto Opazo >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------090700010100040806040601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable     Hi,

    That was also the first thing that came to my mind= when I read this question.

    However, if a certificate is revoked meanwhile, th= at means it will never show up in an issued CRL. What about having a last and definitive CRL created at exactly the CA expire date, i.e. CRL_thisUpdate =3D CRL_nextUpdate =3D CA_notAfter ?

    Regards,

              =   Nuno Ponte

Em 17-02-2011 13:50, Miller, Timothy J. escreveu: 
Simple answer: the notAfter date of the issuing CA. =
 No cert issued by the CA is valid after this date anyway, so the CRL is =
moot thereafter.

-- Tim

On Feb 16, 2011, at 12:49 PM, Roberto Opazo wrote:


Hello:

I can't find an specification about what to put in the "Next Update"
field of the last CRL issued by one CA in its last day. I mean, the
day when this CA certificates expires.

Is there any recommendation?

Without a recommendation you could chose very different options:

* NULL. The field is optional after all, but RFC5280 states
"Conforming CRL issuers MUST include the nextUpdate field in all
CRLs."

* 24 hours, as all other CRL's. But that's a lie, CA is going to be
expired in 24 hours, son It can't sign.

* Year 2999. So no one alive today is going to be alive that they, but
it's a lie any way and there could be systems not prepared to process
that date.

So, could you help me with an official recommendation?

--=20
Best regards,

Roberto Opazo
_______________________________________________
pkix mailing list
pkix@=
ietf.org
https://www.ietf.org/mailman/listinfo/pkix


      

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


    

    

  


--------------090700010100040806040601--

--------------ms020704010500020404000101
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRLTCC
BCEwggOKoAMCAQICBAcnPOUwDQYJKoZIhvcNAQEFBQAwdTELMAkGA1UEBhMCVVMxGDAWBgNV
BAoTD0dURSBDb3Jwb3JhdGlvbjEnMCUGA1UECxMeR1RFIEN5YmVyVHJ1c3QgU29sdXRpb25z
LCBJbmMuMSMwIQYDVQQDExpHVEUgQ3liZXJUcnVzdCBHbG9iYWwgUm9vdDAeFw0wOTA2MDMx
MzUwMzdaFw0xMzEwMDIxMzQ5MjBaMD4xCzAJBgNVBAYTAnB0MRUwEwYDVQQKEwxNVUxUSUNF
UlQtQ0ExGDAWBgNVBAMTD01VTFRJQ0VSVC1DQSAwMjCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAN0N2tOSOeBzmTNW52Z0lF8dai+9/j7REYIiJfjG2GrD/lC/pd8kBHaZZtYQ
Yo6QuoD8Rz1y6Mz9+bZEgm9r+E7HWOoBPIeuVF2Q3Tol/4gcnBvNeubCwMtjQJYnz2zHiho8
iPRXmtDLfWkXzVzPtUgsjooZh1w1ePr95tdiF4+fjv5eUcYn/27Oxj0Gy+FwCU9nAKZ2nO8g
/92NgJZOP1uQgap4+GBlAK3xKyGkj0WohkhAGYhEuvfol8aeS7Hgq9EmeCqvpVIIJc+jORHs
HAzG+69xAiTN+KZf3LsJc47QDQibzU4kcifaLfBk/+vuZf9GX/QYAcifB3cvKBqP4jcCAwEA
AaOCAW8wggFrMBIGA1UdEwEB/wQIMAYBAf8CAQEwUwYDVR0gBEwwSjBIBgkrBgEEAbE+AQAw
OzA5BggrBgEFBQcCARYtaHR0cDovL2N5YmVydHJ1c3Qub21uaXJvb3QuY29tL3JlcG9zaXRv
cnkuY2ZtMA4GA1UdDwEB/wQEAwIBBjCBiQYDVR0jBIGBMH+heaR3MHUxCzAJBgNVBAYTAlVT
MRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xJzAlBgNVBAsTHkdURSBDeWJlclRydXN0IFNv
bHV0aW9ucywgSW5jLjEjMCEGA1UEAxMaR1RFIEN5YmVyVHJ1c3QgR2xvYmFsIFJvb3SCAgGl
MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly93d3cucHVibGljLXRydXN0LmNvbS9jZ2ktYmlu
L0NSTC8yMDE4L2NkcC5jcmwwHQYDVR0OBBYEFB3DuYilGL5gpyymY8pmKvwMJ8G9MA0GCSqG
SIb3DQEBBQUAA4GBAGdeo/BVd0dFHGtojr3ZGcXMf1+u73vffYppORb9gyNDQz/CEMWsgQAr
dO+L/AC0MVbXES516StmkPQhLEvfxUg2ZvXgu3Fe38/l8d4r+Xj0lPxCp1zvgd0RKj2i0kaw
nP/VVb/kUXxpEVFoUB64HFOhPRAtyaezykhmhRCqm3SVMIIGgDCCBWigAwIBAgIEQmzuqjAN
BgkqhkiG9w0BAQUFADA+MQswCQYDVQQGEwJwdDEVMBMGA1UEChMMTVVMVElDRVJULUNBMRgw
FgYDVQQDEw9NVUxUSUNFUlQtQ0EgMDIwHhcNMTAxMDIwMDk0NzQ0WhcNMTExMTE3MDk0NjMy
WjCCAQoxCzAJBgNVBAYTAlBUMRUwEwYDVQQKEwxNVUxUSUNFUlQtQ0ExFjAUBgNVBAsTDUNF
UlRJUE9SIC0gUkExEjAQBgNVBAsTCUNvcnBvcmF0ZTE+MDwGA1UECxM1TVVMVElDRVJUIC0g
U2Vydmljb3MgZGUgQ2VydGlmaWNhY2FvIEVsZWN0cm9uaWNhIFMuQS4xMTAvBgNVBAsTKElu
dGVncmFjYW8gRGVzZW52b2x2aW1lbnRvIGUgQ29uc3VsdG9yaWExFDASBgNVBAsTC1BlcnNv
bmFsIElEMS8wLQYDVQQDEyZOdW5vIE1pZ3VlbCBBcmllaXJvIFJvZHJpZ3VlcyBkYSBQb250
ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANAhACTptkJRu/UjevcdIjQk6B57
p/KnTEJX6T1E0XHy9FVIQaxZqn1YvK5KcevRH1KARJzasHfDqIkt/MwsUk/pzVR4q5en/Usb
epVeAAew6Dl136Lq4TG5RjVZcXaOymIQmiFpaithswqYXdmPacwlHUw1HNdYOsbSpuC/JYNN
LyTSWaM5AmtYPW7wdPgUe17LCpnC4DayLBAjJcp8PLR3VhDPrKuJXniT851LPWpsfRznR4da
K40svcHhCAXgOvZjPZEQKPAzccdWsl1TyE5Gj6oOlQVdLcXh+IFQG8XWtDLChLekIpimGDLJ
hm+n9Ttwntvdw+vWK1fkGtugkgkCAwEAAaOCArYwggKyMAsGA1UdDwQEAwID+DA4BggrBgEF
BQcBAQQsMCowKAYIKwYBBQUHMAGBHGh0dHA6Ly9vY3NwLm11bHRpY2VydC5jb20vY2EwgeAG
A1UdIASB2DCB1TBNBgkrBgEEAbA8CgIwQDA+BggrBgEFBQcCARYyaHR0cDovL3d3dy5tdWx0
aWNlcnQuY29tL2Nwcy9tdWx0aWNlcnQtY2EtY3BzLmh0bWwwgYMGCysGAQQBsDwKAodtMHQw
cgYIKwYBBQUHAgIwZh5kAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBtAHUAbAB0AGkAYwBlAHIA
dAAuAGMAbwBtAC8AYwBwAC8AbQB1AGwAdABpAGMAZQByAHQALQBjAGEALQAxADAAMAA1AC4A
aAB0AG0AbDARBglghkgBhvhCAQEEBAMCBaAwIwYDVR0RBBwwGoEYbnVuby5wb250ZUBtdWx0
aWNlcnQuY29tMIIBAQYDVR0fBIH5MIH2MIGaoIGXoIGUhi9odHRwOi8vd3d3Lm11bHRpY2Vy
dC5jb20vY2EvbXVsdGljZXJ0LWNhLTAyLmNybIZhbGRhcDovL2xkYXAubXVsdGljZXJ0LmNv
bS9jbj1NVUxUSUNFUlQtQ0ElMjAwMixvPU1VTFRJQ0VSVC1DQSxjPVBUP2NlcnRpZmljYXRl
UmV2b2NhdGlvbkxpc3Q/YmFzZTBXoFWgU6RRME8xCzAJBgNVBAYTAnB0MRUwEwYDVQQKEwxN
VUxUSUNFUlQtQ0ExGDAWBgNVBAMTD01VTFRJQ0VSVC1DQSAwMjEPMA0GA1UEAxMGQ1JMMTkw
MB8GA1UdIwQYMBaAFB3DuYilGL5gpyymY8pmKvwMJ8G9MB0GA1UdDgQWBBRTJxWDusYXRHHg
FrsBwIZpgFVPBDAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUAA4IBAQBWegKZgFwgLRM7UQWx
FJMIgVtVV3EbhFUuqKbB3cn8X1Ktbuah3gkJq1wKnQNXV3I/O/cWWOk5AGb+D3ENDbnR53i5
9ixOm/Y4tqsogAR2JLgYcQvXEhH/qzaeZBwrQTCeYOh0ixkpakOtzp5gjHfaEKTi7u56cRlj
/uzbCL+jLbaP1CA11Mu848qKhBScjUHXZAKF3WdISdtkH+Bk6vSkFkztgXxBrTvVVeQeyrYh
0MftwLkQMvWA0GJNVL7DCoXpUKXUqKHVw481acD5mJiV86IROYRF86qvTcbuRkqe5ddwsYZZ
nbg8ZINARoOIBnbTZckbsizKALu0BWHA34+fMIIGgDCCBWigAwIBAgIEQmzuqjANBgkqhkiG
9w0BAQUFADA+MQswCQYDVQQGEwJwdDEVMBMGA1UEChMMTVVMVElDRVJULUNBMRgwFgYDVQQD
Ew9NVUxUSUNFUlQtQ0EgMDIwHhcNMTAxMDIwMDk0NzQ0WhcNMTExMTE3MDk0NjMyWjCCAQox
CzAJBgNVBAYTAlBUMRUwEwYDVQQKEwxNVUxUSUNFUlQtQ0ExFjAUBgNVBAsTDUNFUlRJUE9S
IC0gUkExEjAQBgNVBAsTCUNvcnBvcmF0ZTE+MDwGA1UECxM1TVVMVElDRVJUIC0gU2Vydmlj
b3MgZGUgQ2VydGlmaWNhY2FvIEVsZWN0cm9uaWNhIFMuQS4xMTAvBgNVBAsTKEludGVncmFj
YW8gRGVzZW52b2x2aW1lbnRvIGUgQ29uc3VsdG9yaWExFDASBgNVBAsTC1BlcnNvbmFsIElE
MS8wLQYDVQQDEyZOdW5vIE1pZ3VlbCBBcmllaXJvIFJvZHJpZ3VlcyBkYSBQb250ZTCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANAhACTptkJRu/UjevcdIjQk6B57p/KnTEJX
6T1E0XHy9FVIQaxZqn1YvK5KcevRH1KARJzasHfDqIkt/MwsUk/pzVR4q5en/UsbepVeAAew
6Dl136Lq4TG5RjVZcXaOymIQmiFpaithswqYXdmPacwlHUw1HNdYOsbSpuC/JYNNLyTSWaM5
AmtYPW7wdPgUe17LCpnC4DayLBAjJcp8PLR3VhDPrKuJXniT851LPWpsfRznR4daK40svcHh
CAXgOvZjPZEQKPAzccdWsl1TyE5Gj6oOlQVdLcXh+IFQG8XWtDLChLekIpimGDLJhm+n9Ttw
ntvdw+vWK1fkGtugkgkCAwEAAaOCArYwggKyMAsGA1UdDwQEAwID+DA4BggrBgEFBQcBAQQs
MCowKAYIKwYBBQUHMAGBHGh0dHA6Ly9vY3NwLm11bHRpY2VydC5jb20vY2EwgeAGA1UdIASB
2DCB1TBNBgkrBgEEAbA8CgIwQDA+BggrBgEFBQcCARYyaHR0cDovL3d3dy5tdWx0aWNlcnQu
Y29tL2Nwcy9tdWx0aWNlcnQtY2EtY3BzLmh0bWwwgYMGCysGAQQBsDwKAodtMHQwcgYIKwYB
BQUHAgIwZh5kAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBtAHUAbAB0AGkAYwBlAHIAdAAuAGMA
bwBtAC8AYwBwAC8AbQB1AGwAdABpAGMAZQByAHQALQBjAGEALQAxADAAMAA1AC4AaAB0AG0A
bDARBglghkgBhvhCAQEEBAMCBaAwIwYDVR0RBBwwGoEYbnVuby5wb250ZUBtdWx0aWNlcnQu
Y29tMIIBAQYDVR0fBIH5MIH2MIGaoIGXoIGUhi9odHRwOi8vd3d3Lm11bHRpY2VydC5jb20v
Y2EvbXVsdGljZXJ0LWNhLTAyLmNybIZhbGRhcDovL2xkYXAubXVsdGljZXJ0LmNvbS9jbj1N
VUxUSUNFUlQtQ0ElMjAwMixvPU1VTFRJQ0VSVC1DQSxjPVBUP2NlcnRpZmljYXRlUmV2b2Nh
dGlvbkxpc3Q/YmFzZTBXoFWgU6RRME8xCzAJBgNVBAYTAnB0MRUwEwYDVQQKEwxNVUxUSUNF
UlQtQ0ExGDAWBgNVBAMTD01VTFRJQ0VSVC1DQSAwMjEPMA0GA1UEAxMGQ1JMMTkwMB8GA1Ud
IwQYMBaAFB3DuYilGL5gpyymY8pmKvwMJ8G9MB0GA1UdDgQWBBRTJxWDusYXRHHgFrsBwIZp
gFVPBDAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUAA4IBAQBWegKZgFwgLRM7UQWxFJMIgVtV
V3EbhFUuqKbB3cn8X1Ktbuah3gkJq1wKnQNXV3I/O/cWWOk5AGb+D3ENDbnR53i59ixOm/Y4
tqsogAR2JLgYcQvXEhH/qzaeZBwrQTCeYOh0ixkpakOtzp5gjHfaEKTi7u56cRlj/uzbCL+j
LbaP1CA11Mu848qKhBScjUHXZAKF3WdISdtkH+Bk6vSkFkztgXxBrTvVVeQeyrYh0MftwLkQ
MvWA0GJNVL7DCoXpUKXUqKHVw481acD5mJiV86IROYRF86qvTcbuRkqe5ddwsYZZnbg8ZINA
RoOIBnbTZckbsizKALu0BWHA34+fMYIC3zCCAtsCAQEwRjA+MQswCQYDVQQGEwJwdDEVMBMG
A1UEChMMTVVMVElDRVJULUNBMRgwFgYDVQQDEw9NVUxUSUNFUlQtQ0EgMDICBEJs7qowCQYF
Kw4DAhoFAKCCAW4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MTEwMjE3MTQxMTA4WjAjBgkqhkiG9w0BCQQxFgQUsokJLL/ShRPhkV2TwvoDX7I89dIwVQYJ
KwYBBAGCNxAEMUgwRjA+MQswCQYDVQQGEwJwdDEVMBMGA1UEChMMTVVMVElDRVJULUNBMRgw
FgYDVQQDEw9NVUxUSUNFUlQtQ0EgMDICBEJs7qowVwYLKoZIhvcNAQkQAgsxSKBGMD4xCzAJ
BgNVBAYTAnB0MRUwEwYDVQQKEwxNVUxUSUNFUlQtQ0ExGDAWBgNVBAMTD01VTFRJQ0VSVC1D
QSAwMgIEQmzuqjBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
DQYJKoZIhvcNAQEBBQAEggEAYLB/e9eJSDnFU/C4No/EMu3i4kBfBTJQ3tC0cJxxE7PsJ9hK
+eTsUkyIFuh3xhCrOhcVe4LG8Uv0Jc7ZzIHKQPXRqBHOmR27KcUqTIU1K2J7qXNFzB0WWrUg
8+uwatdhmVyekeCPj/VEwe5stMulIpOAxY+R454l07K6SHAsZMPi278Ts9jSAwTWi3ZUmPq1
bBIiBU4Mvk8lS3hv5/iRd90NAbLhnGckxyQICGRYi5LOAz7hz389I1vea35Ilqtp88WSXqF3
XM7UbOxA5hA46i8GAJvKkIFBDfnO6Ix57WuyquVpKMp+GOH3FLx7O9pdNy58qnE1rVN6IF7p
owyuGAAAAAAAAA==
--------------ms020704010500020404000101--

From tmiller@mitre.org  Thu Feb 17 06:16:33 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1E643A6CE9 for ; Thu, 17 Feb 2011 06:16:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oN8cH8Sf412i for ; Thu, 17 Feb 2011 06:16:33 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id F19553A6B6C for ; Thu, 17 Feb 2011 06:16:32 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D243621B1738; Thu, 17 Feb 2011 09:17:03 -0500 (EST)
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C9BD521B0D9E; Thu, 17 Feb 2011 09:17:03 -0500 (EST)
Received: from IMCMBX2.MITRE.ORG ([129.83.29.209]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Thu, 17 Feb 2011 09:17:03 -0500
From: "Miller, Timothy J." 
To: Nuno Ponte 
Date: Thu, 17 Feb 2011 09:17:02 -0500
Thread-Topic: [pkix] What should be in "Next Update" field of the last CRL?
Thread-Index: AcvOrVlOd6qV4VW5ScSgZ0K3sAyj7Q==
Message-ID: <8B23B7FE-747A-481C-9E1C-07B8ED6F3F44@mitre.org>
References:  <0E53BA7F-61B8-4BA6-B13C-CF3B2A615CE9@mitre.org> <4D5D2C7B.7070204@multicert.com>
In-Reply-To: <4D5D2C7B.7070204@multicert.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail-7--330041082"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Cc: IETF 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Feb 2011 14:16:33 -0000

--Apple-Mail-7--330041082
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Feb 17, 2011, at 8:11 AM, Nuno Ponte wrote:

> However, if a certificate is revoked meanwhile, that means it will =
never show up in an issued CRL. What about having a last and definitive =
CRL created at exactly the CA expire date, i.e. CRL_thisUpdate =3D =
CRL_nextUpdate =3D CA_notAfter ?

"Meanwhile" is meaningless in this case.  Expired certs can be removed =
from a CRL with zero impact because the validation algorithm discards =
expired certs *before* status is checked.  Checking status prior to =
expiry is far, far less efficient; software that checks status before =
validity should be fixed.

Choosing to keep expired certs on a CRL may be required for legal or =
policy reasons, but there is no technical requirement to do so.

-- Tim


--Apple-Mail-7--330041082
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw
ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE
CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt
YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy
ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT
EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy
PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7
RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ
t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8
rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud
EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I
ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd
dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw
0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F
UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v
Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV
BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp
bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0xMTAyMTcxNDE3MDJaMCMGCSqGSIb3DQEJBDEWBBS/DARLU5KvZJD+The/
+95mE1174TByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV
Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5
IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV
BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp
bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgGeTN3Qce7dGcLDQoURUwnk3+ln0cSeFYo/f
MlXgajWDDUylxCD4N6UCE+FjhVZwgIfLpoz/yHuchUr9dRgCUkB6smisF1CmPYWakD7JqNjymclo
k1SsChI5n4SR+XkhxGhbJWcK+OaDHSNNB954xHAIHXalZ+qZOPjzts8hr9JLAAAAAAAA

--Apple-Mail-7--330041082--

From housley@vigilsec.com  Thu Feb 17 06:42:14 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8E573A6ECF for ; Thu, 17 Feb 2011 06:42:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.549
X-Spam-Level: 
X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIibeqfAi8x3 for ; Thu, 17 Feb 2011 06:42:14 -0800 (PST)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id E280C3A6EC7 for ; Thu, 17 Feb 2011 06:42:13 -0800 (PST)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 895189A4793; Thu, 17 Feb 2011 09:42:59 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id tS+ZWJJugZRG; Thu, 17 Feb 2011 09:42:32 -0500 (EST)
Received: from [192.168.2.105] (pool-71-178-218-117.washdc.fios.verizon.net [71.178.218.117]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 8495B9A478F; Thu, 17 Feb 2011 09:42:55 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Russ Housley 
In-Reply-To: 
Date: Thu, 17 Feb 2011 09:42:39 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:     <20110217012331.055DD3A6BA0@core3.amsl.com> <20110217013359.0A2213A6F09@core3.amsl.com> <4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu> <20110217015732.B4C3E3A6B60@core3.amsl.com> <60C013EE-3487-4E80-B7DB-CDA73104079B@ttu.edu> 
To: Roberto Opazo 
X-Mailer: Apple Mail (2.1082)
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Feb 2011 14:42:15 -0000

Roberto:

Another reasonable choice would be a date just after the expiration of =
every certificate issued by the CA.  This will not disrupt certificates =
that are supposed to be valid, and the CRL will also have an =
end-of-life.

Russ


On Feb 16, 2011, at 10:44 PM, Roberto Opazo wrote:

> Well, the real situation is... Next Monday the CA certificate expires
> after 10 years of work. So CA certificate has not been expired yet and
> we have a little time to take some decisions.
>=20
> This is the first time for us on these situation. Next time is going
> to be in 20 years, so I expect there will be and standard way to
> finish CA live at that time.
>=20
> Have anybody an experience to share?
>=20
> How have other CAs ended?
>=20
> I think using a 24 hours valid period for the last CRL is not good
> choice. For instance, the next year a relaying party (RP) could try to
> validate a valid signature (like an XML signed last week) and the RP
> will get and expired CRL, I mean a CRL whit "Next Update" field
> expired. RP would have to note than "Next Update" is pointing to a
> date out of the CA's certificate validity period and assume that is
> the reason why there are no other CRL and then, decide to trust in an
> expired CRL. I think there are no many sw with this logic on the
> marked.
>=20
> That's why I prefer Rus recommendation, but I think It would be nice
> having an RFC with a sentence like "CAs conforming to this profile
> MUST create a final CRL with 99991231235959Z on "Next Update" field.
>=20
> After all, Rus is a guru to me, but I can't say to others "Rus told me
> to...". So I will have to repeat Rus argument, but It's not the same
> when it's me or the company I work for, the person saying that.
>=20
> Best regards,
>=20
> Roberto Opazo
>=20
> 2011/2/16 Sill, Alan :
>>=20
>>=20
>>=20
>>=20
>> On Feb 16, 2011, at 7:58 PM, "Michael StJohns"  =
wrote:
>>=20
>>> At 08:47 PM 2/16/2011, Alan Sill wrote:
>>>> A CA can become inactive for the purposes of issuing new =
credentials
>>>> without necessarily invalidating the certificates already issued.
>>>=20
>>> The specific question referred to a CA certificate that was =
expiring.  If the CA certificate expires, then the certificates under =
that certificate (absent a re-signed replacement) are invalid by =
definition - or am I missing your point?
>>>=20
>>> Mike
>>=20
>> Woops -- you're right; if the CA certificate itself has expired, then =
the question is of course moot.
>>=20
>> Sorry, I missed that in the original question.
>>=20
>> Alan
>> _______________________________________________
>> pkix mailing list
>> pkix@ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>>=20
>=20
>=20
>=20
> --=20
> Saludos,
>=20
> Roberto Opazo
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix


From housley@vigilsec.com  Thu Feb 17 06:45:43 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4DB63A6F14 for ; Thu, 17 Feb 2011 06:45:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.551
X-Spam-Level: 
X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPajNk9NixEk for ; Thu, 17 Feb 2011 06:45:42 -0800 (PST)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id A61283A6F0B for ; Thu, 17 Feb 2011 06:45:42 -0800 (PST)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 1F1D59A478F; Thu, 17 Feb 2011 09:46:30 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 6ensuhFsuMLc; Thu, 17 Feb 2011 09:45:58 -0500 (EST)
Received: from [192.168.2.105] (pool-71-178-218-117.washdc.fios.verizon.net [71.178.218.117]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 27BB89A4796; Thu, 17 Feb 2011 09:46:28 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Russ Housley 
In-Reply-To: <0ED5D8F9-C6C9-4599-B343-CEB1003883E9@ttu.edu>
Date: Thu, 17 Feb 2011 09:46:11 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:     <20110217012331.055DD3A6BA0@core3.amsl.com> <20110217013359.0A2213A6F09@core3.amsl.com> <4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu> <20110217015732.B4C3E3A6B60@core3.amsl.com> <60C013EE-3487-4E80-B7DB-CDA73104079B@ttu.edu>  <0ED5D8F9-C6C9-4599-B343-CEB1003883E9@ttu.edu>
To: "Sill, Alan" 
X-Mailer: Apple Mail (2.1082)
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Feb 2011 14:45:43 -0000

Alan:

>> I think using a 24 hours valid period for the last CRL is not good
>> choice. For instance, the next year a relaying party (RP) could try =
to
>> validate a valid signature (like an XML signed last week) and the RP
>> will get and expired CRL, I mean a CRL whit "Next Update" field
>> expired. RP would have to note than "Next Update" is pointing to a
>> date out of the CA's certificate validity period and assume that is
>> the reason why there are no other CRL and then, decide to trust in an
>> expired CRL.
>=20
> Any correctly implemented RP software would fail to validate any =
certificate from a CA with an expired CA certificate, or any certificate =
at all from a CA that has a most recent "Next Update" in the past. =
Itdoes no good to second-guess conditions under which a RP would trust a =
cert that they cannot check for possible revocation.

If the CA certificate has been installed as a trust anchor, then the =
expiration time in the self-signed certificate has no role in the =
certification path validation.

Russ


From roberto@opazo.cl  Thu Feb 17 06:57:49 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D92AC3A6CE1 for ; Thu, 17 Feb 2011 06:57:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cs-Bpgiclg2j for ; Thu, 17 Feb 2011 06:57:49 -0800 (PST)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id C62243A6CBF for ; Thu, 17 Feb 2011 06:57:48 -0800 (PST)
Received: by ewy8 with SMTP id 8so1129639ewy.31 for ; Thu, 17 Feb 2011 06:58:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.14.124.133 with SMTP id x5mr2201202eeh.22.1297954699047; Thu, 17 Feb 2011 06:58:19 -0800 (PST)
Received: by 10.14.121.212 with HTTP; Thu, 17 Feb 2011 06:58:19 -0800 (PST)
In-Reply-To: 
References:     <20110217012331.055DD3A6BA0@core3.amsl.com> <20110217013359.0A2213A6F09@core3.amsl.com> <4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu> <20110217015732.B4C3E3A6B60@core3.amsl.com> <60C013EE-3487-4E80-B7DB-CDA73104079B@ttu.edu>  
Date: Thu, 17 Feb 2011 11:58:19 -0300
Message-ID: 
From: Roberto Opazo 
To: IETF PKIX 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Feb 2011 14:57:49 -0000

Tim:

> However, even this doesn't matter because subscriber certs are invalid wh=
en the CA
> cert expires no matter what notAfter date they assert.  Any cert or CRL w=
hich claims
> dates past this date is moot.

After CA expiration date, it's still possible to need EE certificate
validation, not for a new SSL authentication, but for an electronic
document signed in the past, when the EE certificate was valid.

EE certificates expires, but electronic signatures persist and needs
to be validated.


2011/2/17 Miller, Timothy J. :
> On Feb 16, 2011, at 9:44 PM, Roberto Opazo wrote:
>
>> Well, the real situation is... Next Monday the CA certificate expires
>> after 10 years of work. So CA certificate has not been expired yet and
>> we have a little time to take some decisions.
>
> Subscriber certs should have a notAfter date equal to the maximum validit=
y period or the notAfter date of the issuer's certificate, *whichever is sh=
orter*.
>
> However, even this doesn't matter because subscriber certs are invalid wh=
en the CA cert expires no matter what notAfter date they assert. =A0Any cer=
t or CRL which claims dates past this date is moot.
>
> "Proper" PKI planning would have each CA retire from active issuance but =
remain to issue CRLs until all subscriber certs have expired; this 'inactiv=
e' period is equal to the maximum validity period of the certs it issued. =
=A0At that point the CA can simply be shut off (assuming you've archived al=
l the artifacts you need for proving validity of historical signatures). =
=A0This is an operational nicety rather than a technical one, as it's the o=
nly way to extract the full validity period for all issued certs; failure t=
o do so means as the CA cert expiry time approaches the subscriber cert lif=
ecycle gets shorter and shorter.
>
> OTOH, you *could* simply resign the CA key, assuming you're OK with that =
key remaining in service. =A0I don't recommend this option but I think it w=
ould technically work. =A0As long as the SKID and Subject DN don't change, =
relying parties may still be able to build a valid chain.
>
> -- Tim
>
>
>



--=20
Saludos,

Roberto Opazo

From david.cooper@nist.gov  Thu Feb 17 07:24:13 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3A43A6E17 for ; Thu, 17 Feb 2011 07:24:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwjYaiz6OB4f for ; Thu, 17 Feb 2011 07:24:11 -0800 (PST)
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id 204483A6F34 for ; Thu, 17 Feb 2011 07:24:10 -0800 (PST)
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p1HFObsj014893; Thu, 17 Feb 2011 10:24:38 -0500
Message-ID: <4D5D3DAE.1080806@nist.gov>
Date: Thu, 17 Feb 2011 10:24:30 -0500
From: "David A. Cooper" 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20101222 Mandriva/3.0.11-0.1mdv2010.2 (2010.2) Thunderbird/3.0.11
MIME-Version: 1.0
To: Roberto Opazo 
References: 				<20110217012331.055DD3A6BA0@core3.amsl.com>	<20110217013359.0A2213A6F09@core3.amsl.com>	<4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu>	<20110217015732.B4C3E3A6B60@core3.amsl.com>	<60C013EE-3487-4E80-B7DB-CDA73104079B@ttu.edu>		 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Feb 2011 15:24:13 -0000

Robert,

Yes, a relying party may wish to determine if an EE certificate was 
valid at some time in the past, but such a relying party should not be 
looking for a "current" CRL.

As has been noted, if a certificate has been revoked, its serial number 
only needs to be included on CRLs issued before the certificate 
expired.  So, if a certificate expired 6 months ago, and a relying party 
wants to know whether the certificate was valid a year ago when the 
corresponding private key was used to sign a document, the relying party 
would need to find a CRL that was issued at least 6 months ago.  The 
relying party may wish to check that the nextUpdate time in the CRL is 
after the time that the signature was generated, but should not check 
that the nextUpdate time in the CRL is after the current time, as in 
most cases such a CRL would have been issued after the certificate 
expired and so would not provide any information about the revocation 
status of the certificate.

So, if all of the EE certificates issued by your CA expire no later than 
February 21, 2011, it should be sufficient for the final CRL issued by 
the CA to have a nextUpate time of February 22, 2011 (or some time on 
February 21, 2011 that is later than the notAfter time in every 
certificate issued by the CA).  Such a CRL would work well for any 
relying party trying to verify a certificate before its expiration, and 
any relying party trying to verify a certificate after its revocation 
wouldn't (or at least shouldn't) be comparing the nextUpdate time in the 
CRL to the current time.

If the CA has issued certificates that expire after February 21, 2011, 
then the situation is slightly more complicated, if the CA will shut 
down and no longer issue CRLs after that date.  The safe thing to do 
would be to issue a final CRL with a nextUpdate time that is after the 
expiration (notAfter) dates of all issued certificates that lists all of 
the unexpired certificates as revoked.  One could issue such a CRL that 
does not list the unexpired certificates as revoked, but there is a risk 
involved in that (if the CA that issued the certificates is used as a 
trust anchor) since there would be no way to revoke these certificates 
in the future if the need arose.

Dave

On 02/17/2011 09:58 AM, Roberto Opazo wrote:
> Tim:
>> However, even this doesn't matter because subscriber certs are invalid when the CA
>> cert expires no matter what notAfter date they assert.  Any cert or CRL which claims
>> dates past this date is moot.
>>      
> After CA expiration date, it's still possible to need EE certificate
> validation, not for a new SSL authentication, but for an electronic
> document signed in the past, when the EE certificate was valid.
>
> EE certificates expires, but electronic signatures persist and needs
> to be validated.
>
>
> 2011/2/17 Miller, Timothy J.:
>    
>> On Feb 16, 2011, at 9:44 PM, Roberto Opazo wrote:
>>
>>      
>>> Well, the real situation is... Next Monday the CA certificate expires
>>> after 10 years of work. So CA certificate has not been expired yet and
>>> we have a little time to take some decisions.
>>>        
>> Subscriber certs should have a notAfter date equal to the maximum validity period or the notAfter date of the issuer's certificate, *whichever is shorter*.
>>
>> However, even this doesn't matter because subscriber certs are invalid when the CA cert expires no matter what notAfter date they assert.  Any cert or CRL which claims dates past this date is moot.
>>
>> "Proper" PKI planning would have each CA retire from active issuance but remain to issue CRLs until all subscriber certs have expired; this 'inactive' period is equal to the maximum validity period of the certs it issued.  At that point the CA can simply be shut off (assuming you've archived all the artifacts you need for proving validity of historical signatures).  This is an operational nicety rather than a technical one, as it's the only way to extract the full validity period for all issued certs; failure to do so means as the CA cert expiry time approaches the subscriber cert lifecycle gets shorter and shorter.
>>
>> OTOH, you *could* simply resign the CA key, assuming you're OK with that key remaining in service.  I don't recommend this option but I think it would technically work.  As long as the SKID and Subject DN don't change, relying parties may still be able to build a valid chain.
>>
>> -- Tim


From tmiller@mitre.org  Thu Feb 17 07:28:45 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C734A3A6D5C for ; Thu, 17 Feb 2011 07:28:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IywTaq0UXcX1 for ; Thu, 17 Feb 2011 07:28:45 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 004BE3A6C65 for ; Thu, 17 Feb 2011 07:28:44 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EB58E21B15D4; Thu, 17 Feb 2011 10:29:15 -0500 (EST)
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E33ED21B0DD6; Thu, 17 Feb 2011 10:29:15 -0500 (EST)
Received: from IMCMBX2.MITRE.ORG ([129.83.29.209]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Thu, 17 Feb 2011 10:29:15 -0500
From: "Miller, Timothy J." 
To: Roberto Opazo 
Date: Thu, 17 Feb 2011 10:29:14 -0500
Thread-Topic: [pkix] What should be in "Next Update" field of the last CRL?
Thread-Index: AcvOt29WpK8IZ0xxRWi21sZ2p+1oWg==
Message-ID: 
References:     <20110217012331.055DD3A6BA0@core3.amsl.com> <20110217013359.0A2213A6F09@core3.amsl.com> <4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu> <20110217015732.B4C3E3A6B60@core3.amsl.com> <60C013EE-3487-4E80-B7DB-CDA73104079B@ttu.edu>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail-8--325708844"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Feb 2011 15:28:45 -0000

--Apple-Mail-8--325708844
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Feb 17, 2011, at 8:58 AM, Roberto Opazo wrote:

> After CA expiration date, it's still possible to need EE certificate
> validation, not for a new SSL authentication, but for an electronic
> document signed in the past, when the EE certificate was valid.

Historical signature validation is a special case, and requires archived =
status statements--not final status statements.  If a document was =
signed at T and revoked-for-compromise at T+n, the signature at T is =
still binding (though it may be more or less questionable depending on =
the magnitude of n).  An historical signature algorithm would only use =
the CRL issued for the period covering T for validation.

-- Tim


--Apple-Mail-8--325708844
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw
ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE
CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt
YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy
ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT
EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy
PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7
RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ
t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8
rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud
EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I
ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd
dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw
0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F
UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v
Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV
BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp
bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0xMTAyMTcxNTI5MTVaMCMGCSqGSIb3DQEJBDEWBBQCW9nQpbGYHArIKt3z
294ILGpDrTByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV
Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5
IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV
BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp
bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgG4AtRjyqZimFCGqK8/I5aaAQslPHf8DoxA2
GQMPmFVWyeYSPgs3059ii/JjDBT6qYtX16UZbQm38OyIM37b0hjalzlGFyekJnMLP4kHfSIQ+vh5
8+qcnyTKoZRXNxBnHI0NsuLhe4NgMq1dQgmrJgUFPrqeSy3D45Jtr5tUPkFzAAAAAAAA

--Apple-Mail-8--325708844--

From jmdesp@free.fr  Thu Feb 17 08:11:12 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBD7D3A6DE3 for ; Thu, 17 Feb 2011 08:11:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ja9R5AyXNUYX for ; Thu, 17 Feb 2011 08:11:11 -0800 (PST)
Received: from smtp-ft4.fr.colt.net (smtp-ft4.fr.colt.net [213.41.78.208]) by core3.amsl.com (Postfix) with ESMTP id 475B33A6D2B for ; Thu, 17 Feb 2011 08:11:10 -0800 (PST)
Received: from smtp-ex6.fr.colt.net (smtp-ex6.fr.colt.net [213.41.78.122]) by smtp-ft4.fr.colt.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p1HGBcMx004345 for ; Thu, 17 Feb 2011 17:11:38 +0100
Received: from host.104.92.68.195.rev.coltfrance.com ([195.68.92.104] helo=[172.30.24.37]) by smtp-ex6.fr.colt.net with esmtp (Exim) (envelope-from ) id 1Pq6SB-0005KK-1N for ; Thu, 17 Feb 2011 17:11:39 +0100
Message-ID: <4D5D48AE.60409@free.fr>
Date: Thu, 17 Feb 2011 17:11:26 +0100
From: Jean-Marc Desperrier 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.18pre) Gecko/20110202 SeaMonkey/2.0.13pre
MIME-Version: 1.0
To: "pkix@ietf.org" 
References: 		 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Warning: IP [195.68.92.104] is listed at dnsbl.sorbs.net (127.0.0.10: Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?195.68.92.104)
X-ACL-Warn: 1/1 recipients OK.
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Feb 2011 16:11:13 -0000

Russ Housley wrote:
> RFC 5280 says the following about a certificate notAfter field:
>
>     To indicate that a certificate has no well-defined expiration date,
>     the notAfter SHOULD be assigned the GeneralizedTime value of
>     99991231235959Z.
>

I recently saw an implementation that actually uses that date, and it's 
not really a convenient choice.

The use of the date 9999 seems to be in order to use the highest value 
that doesn't have a 5 digits year. But given that the date is 23h 59:59 
on the 31 december, it will result in a date in the morning of 1 january 
10.000 for all locales that have a positive offset to GMT.
I think 99991231120000Z would be more convenient so that the year stays 
9999 whatever the local time used to display it is.

From paul.hoffman@vpnc.org  Thu Feb 17 08:29:42 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 526343A6D40 for ; Thu, 17 Feb 2011 08:29:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.035
X-Spam-Level: 
X-Spam-Status: No, score=-100.035 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pN1GeoJyOv7b for ; Thu, 17 Feb 2011 08:29:41 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 871783A6D2A for ; Thu, 17 Feb 2011 08:29:41 -0800 (PST)
Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1HGUBcs019994 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 17 Feb 2011 09:30:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Message-ID: <4D5D4D13.3030700@vpnc.org>
Date: Thu, 17 Feb 2011 08:30:11 -0800
From: Paul Hoffman 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: pkix@ietf.org
References: 				<20110217012331.055DD3A6BA0@core3.amsl.com>	<20110217013359.0A2213A6F09@core3.amsl.com>	<4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu>	<20110217015732.B4C3E3A6B60@core3.amsl.com>	<60C013EE-3487-4E80-B7DB-CDA73104079B@ttu.edu>		<0ED5D8F9-C6C9-4599-B343-CEB1003883E9@ttu.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Feb 2011 16:29:42 -0000

On 2/17/11 6:46 AM, Russ Housley wrote:
> If the CA certificate has been installed as a trust anchor, then the expiration time in the self-signed certificate has no role in the certification path validation.

Exactly. The previous replies on this thread that said that a relying 
party would not validate a certificate that used this CA either were 
thinking that the CA was an intermediate CA or were forgetting the PKIX 
trust anchor model from section 6.1 of 5280.

Given this, I think Russ' second answer is the correct one:

 >Another reasonable choice would be a date just after the expiration of 
every certificate issued by the CA.  This will not disrupt certificates 
that are supposed to be valid, and the CRL will also have an end-of-life.

This allows the no-longer-used CA to still revoke certificates, such as 
if there is a key compromise on an end-entity certificate that happens 
even after the CA is no longer expected to be used.

From RAndrews@verisign.com  Thu Feb 17 08:46:21 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6CDD3A6D16 for ; Thu, 17 Feb 2011 08:46:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smq4kRF0WppW for ; Thu, 17 Feb 2011 08:46:21 -0800 (PST)
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id E873A3A6CBA for ; Thu, 17 Feb 2011 08:46:20 -0800 (PST)
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id p1HGNCZb030959; Thu, 17 Feb 2011 08:23:12 -0800
Received: from MOU1WNEXMB14.vcorp.ad.vrsn.com ([10.25.13.245]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Feb 2011 08:46:51 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 17 Feb 2011 08:46:51 -0800
Message-ID: <0D028BDBFBA58441BD8E97469148064201A26553@MOU1WNEXMB14.vcorp.ad.vrsn.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [pkix] What should be in "Next Update" field of the last CRL?
Thread-Index: AcvOVQtM3R+aGWfDQLGhMnGDkCLy/gAbJPMg
References: <20110217012331.055DD3A6BA0@core3.amsl.com><20110217013359.0A2213A6F09@core3.amsl.com><4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu><20110217015732.B4C3E3A6B60@core3.amsl.com><60C013EE-3487-4E80-B7DB-CDA73104079B@ttu.edu> 
From: "Andrews, Rick" 
To: "Roberto Opazo" , "Sill, Alan" 
X-OriginalArrivalTime: 17 Feb 2011 16:46:51.0741 (UTC) FILETIME=[46D320D0:01CBCEC2]
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Feb 2011 16:46:21 -0000

> Have anybody an experience to share?
>=20
> How have other CAs ended?

Good question. In January 2010, we retired our "RSA Secure Server" CA,
but apparently we're still issuing empty CRLs with it. I suspect that if
we stopped, and simply removed the latest CRL from our download site, it
would have no effect whatsoever.

-Rick Andrews

From tmiller@mitre.org  Thu Feb 17 08:58:15 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 639503A6D0D for ; Thu, 17 Feb 2011 08:58:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Max10DBFvEVS for ; Thu, 17 Feb 2011 08:58:08 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id B4A233A6AB2 for ; Thu, 17 Feb 2011 08:58:08 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CC4CE21B14C9; Thu, 17 Feb 2011 11:58:39 -0500 (EST)
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C4C2D21B070A; Thu, 17 Feb 2011 11:58:39 -0500 (EST)
Received: from IMCMBX2.MITRE.ORG ([129.83.29.209]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Thu, 17 Feb 2011 11:58:37 -0500
From: "Miller, Timothy J." 
To: Paul Hoffman 
Date: Thu, 17 Feb 2011 11:58:28 -0500
Thread-Topic: [pkix] What should be in "Next Update" field of the last CRL?
Thread-Index: AcvOw+sHgr49eBGPSNau0iYEdmeTOQ==
Message-ID: <15B502E8-8352-4E1A-B238-3E89C6358124@mitre.org>
References:     <20110217012331.055DD3A6BA0@core3.amsl.com> <20110217013359.0A2213A6F09@core3.amsl.com> <4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu> <20110217015732.B4C3E3A6B60@core3.amsl.com> <60C013EE-3487-4E80-B7DB-CDA73104079B@ttu.edu>  <0ED5D8F9-C6C9-4599-B343-CEB1003883E9@ttu.edu>  <4D5D4D13.3030700@vpnc.org>
In-Reply-To: <4D5D4D13.3030700@vpnc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail-10--320354551"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Feb 2011 16:58:15 -0000

--Apple-Mail-10--320354551
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Feb 17, 2011, at 10:30 AM, Paul Hoffman wrote:

> Exactly. The previous replies on this thread that said that a relying=20=

> party would not validate a certificate that used this CA either were=20=

> thinking that the CA was an intermediate CA or were forgetting the =
PKIX=20
> trust anchor model from section 6.1 of 5280.

Good point.  But then again, many (most?) extant implementations make =
the same error.

-- T



--Apple-Mail-10--320354551
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw
ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE
CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt
YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy
ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT
EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy
PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7
RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ
t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8
rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud
EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I
ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd
dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw
0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F
UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v
Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV
BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp
bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0xMTAyMTcxNjU4MjlaMCMGCSqGSIb3DQEJBDEWBBTsfIxQM42tYhekSh4J
yQx811ZusjByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV
Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5
IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV
BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp
bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgL3cNn5IgPIxwQuSqDWaCYfW21FSRQ+P7XTW
0i6jzcijC+ilJmtHcznDw53Bz+LX5pQGHifBZ5q/RU2VqLRlb5/aVAvuNCvMujzA4UR2gGbaYLrV
rTTxdKZpewUqVnO1eb1Ok5Eqxay6DJc379/bvPgEIcQT2LtXYt2nYVkIW28DAAAAAAAA

--Apple-Mail-10--320354551--

From paul.hoffman@vpnc.org  Thu Feb 17 09:26:56 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D4823A6D60 for ; Thu, 17 Feb 2011 09:26:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.717
X-Spam-Level: 
X-Spam-Status: No, score=-99.717 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_57=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ohh5+jCvCzj2 for ; Thu, 17 Feb 2011 09:26:55 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 78A8A3A6CB8 for ; Thu, 17 Feb 2011 09:26:55 -0800 (PST)
Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1HHRQmT022908 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 17 Feb 2011 10:27:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Message-ID: <4D5D5A7E.2090208@vpnc.org>
Date: Thu, 17 Feb 2011 09:27:26 -0800
From: Paul Hoffman 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: "pkix@ietf.org" 
References:     <20110217012331.055DD3A6BA0@core3.amsl.com> <20110217013359.0A2213A6F09@core3.amsl.com> <4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu> <20110217015732.B4C3E3A6B60@core3.amsl.com> <60C013EE-3487-4E80-B7DB-CDA73104079B@ttu.edu>  <0ED5D8F9-C6C9-4599-B343-CEB1003883E9@ttu.edu>  <4D5D4D13.3030700@vpnc.org> <15B502E8-8352-4E1A-B238-3E89C6358124@mitre.org>
In-Reply-To: <15B502E8-8352-4E1A-B238-3E89C6358124@mitre.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Feb 2011 17:26:56 -0000

On 2/17/11 8:58 AM, Miller, Timothy J. wrote:
> On Feb 17, 2011, at 10:30 AM, Paul Hoffman wrote:
>
>> Exactly. The previous replies on this thread that said that a relying
>> party would not validate a certificate that used this CA either were
>> thinking that the CA was an intermediate CA or were forgetting the PKIX
>> trust anchor model from section 6.1 of 5280.
>
> Good point.  But then again, many (most?) extant implementations make the same error.

It is not an error, it is a policy decision based on erroneous 
understanding of PKIX. :-) Seriously, though, because many extant 
implementations do *not* make that error^Wpolicy decision, the answer to 
the question that started this thread should be to deal with both types 
of systems and to continue to set the "next update" to a date when a 
next update can be expected. If the CA has decided to never do a next 
update, use the forever-ish standard for notAfter; otherwise, be honest 
and say when you think you might update the CRL again.

From mstjohns@comcast.net  Thu Feb 17 17:16:54 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E7533A6C72 for ; Thu, 17 Feb 2011 17:16:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aq1RV6aBNVvn for ; Thu, 17 Feb 2011 17:16:54 -0800 (PST)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id CC3393A6A0C for ; Thu, 17 Feb 2011 17:16:53 -0800 (PST)
Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta04.westchester.pa.mail.comcast.net with comcast id 9D5e1g0021ap0As54DHS4W; Fri, 18 Feb 2011 01:17:26 +0000
Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta22.westchester.pa.mail.comcast.net with comcast id 9DHR1g0091EtFYL3iDHSX0; Fri, 18 Feb 2011 01:17:26 +0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 17 Feb 2011 20:17:23 -0500
To: Russ Housley ,"Sill, Alan" 
From: Michael StJohns 
In-Reply-To: 
References:     <20110217012331.055DD3A6BA0@core3.amsl.com> <20110217013359.0A2213A6F09@core3.amsl.com> <4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu> <20110217015732.B4C3E3A6B60@core3.amsl.com> <60C013EE-3487-4E80-B7DB-CDA73104079B@ttu.edu>  <0ED5D8F9-C6C9-4599-B343-CEB1003883E9@ttu.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <20110218011653.CC3393A6A0C@core3.amsl.com>
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last  CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Feb 2011 01:16:54 -0000

At 09:46 AM 2/17/2011, Russ Housley wrote:
>If the CA certificate has been installed as a trust anchor, then the expiration time in the self-signed certificate has no role in the certification path validation.

Is that true in reality?  The typical trust anchor in a browser is a self-signed cert.  I'd have to check, but I'm pretty sure chaining fails if the self-signed cert has expired.

Mike



From housley@vigilsec.com  Thu Feb 17 17:45:52 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EAEF3A6D23 for ; Thu, 17 Feb 2011 17:45:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.602
X-Spam-Level: 
X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1WEPnRagGjD for ; Thu, 17 Feb 2011 17:45:51 -0800 (PST)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 77EC43A6C72 for ; Thu, 17 Feb 2011 17:45:51 -0800 (PST)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 2BDA99A4738; Thu, 17 Feb 2011 20:46:47 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id XA-F7aY1+d9t; Thu, 17 Feb 2011 20:46:19 -0500 (EST)
Received: from [192.168.2.101] (pool-71-178-218-117.washdc.fios.verizon.net [71.178.218.117]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 9DA4B9A472C; Thu, 17 Feb 2011 20:46:46 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Russ Housley 
In-Reply-To: <20110218011750.810FDF24027@odin.smetech.net>
Date: Thu, 17 Feb 2011 20:46:22 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <41235DC4-A625-49F4-9D20-225C23C05C00@vigilsec.com>
References:     <20110217012331.055DD3A6BA0@core3.amsl.com> <20110217013359.0A2213A6F09@core3.amsl.com> <4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu> <20110217015732.B4C3E3A6B60@core3.amsl.com> <60C013EE-3487-4E80-B7DB-CDA73104079B@ttu.edu>  <0ED5D8F9-C6C9-4599-B343-CEB1003883E9@ttu.edu>  <20110218011750.810FDF24027@odin.smetech.net>
To: Michael StJohns 
X-Mailer: Apple Mail (2.1082)
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Feb 2011 01:45:52 -0000

Mike:

>> If the CA certificate has been installed as a trust anchor, then the =
expiration time in the self-signed certificate has no role in the =
certification path validation.
>=20
> Is that true in reality?  The typical trust anchor in a browser is a =
self-signed cert.  I'd have to check, but I'm pretty sure chaining fails =
if the self-signed cert has expired.

Browsers do this check, but nothing in RFC 5280 (or RFC 3280, or RFC =
2459) imposes this requirement.

Russ=

From mstjohns@comcast.net  Thu Feb 17 18:17:49 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51E2C3A6D34 for ; Thu, 17 Feb 2011 18:17:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Y5Aiis+qs7F for ; Thu, 17 Feb 2011 18:17:48 -0800 (PST)
Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 890E63A6D23 for ; Thu, 17 Feb 2011 18:17:48 -0800 (PST)
Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta09.emeryville.ca.mail.comcast.net with comcast id 9EDL1g0051HpZEsA9EJMN6; Fri, 18 Feb 2011 02:18:21 +0000
Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta14.emeryville.ca.mail.comcast.net with comcast id 9EJF1g01h1EtFYL8aEJHT7; Fri, 18 Feb 2011 02:18:20 +0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 17 Feb 2011 21:18:14 -0500
To: Russ Housley 
From: Michael StJohns 
In-Reply-To: <41235DC4-A625-49F4-9D20-225C23C05C00@vigilsec.com>
References:     <20110217012331.055DD3A6BA0@core3.amsl.com> <20110217013359.0A2213A6F09@core3.amsl.com> <4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu> <20110217015732.B4C3E3A6B60@core3.amsl.com> <60C013EE-3487-4E80-B7DB-CDA73104079B@ttu.edu>  <0ED5D8F9-C6C9-4599-B343-CEB1003883E9@ttu.edu>  <20110218011750.810FDF24027@odin.smetech.net> <41235DC4-A625-49F4-9D20-225C23C05C00@vigilsec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <20110218021748.890E63A6D23@core3.amsl.com>
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last  CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Feb 2011 02:17:49 -0000

At 08:46 PM 2/17/2011, Russ Housley wrote:
>Mike:
>
>>> If the CA certificate has been installed as a trust anchor, then the expiration time in the self-signed certificate has no role in the certification path validation.
>> 
>> Is that true in reality?  The typical trust anchor in a browser is a self-signed cert.  I'd have to check, but I'm pretty sure chaining fails if the self-signed cert has expired.
>
>Browsers do this check, but nothing in RFC 5280 (or RFC 3280, or RFC 2459) imposes this requirement.
>
>Russ


Which is kind of funny because a number of implementations treat the nextUpdate field as a CRL expiration date - and that's doesn't appear to be the processing recommended by 5280. 

 I started researching this and found at least three implementations have either a fixed or configurable behavior which treats ALL certs under a CA as invalid if they don't receive a new CRL before the nextUpdate date.  At least one of these implementations does not have this behavior if it sees a CRL without the nextUpdate field  - but 5280 requires CRLs to have the field.  

Section 6.3.3 of 5280 is fairly silent on what to do if you don't have the most recent CRL - I read it that certs not on the CRLs that are in your posession have the status of "UNDETERMINED".

Is it time for a BCP on Certs as Trust Anchors and/or Cert Acceptance Policies given incomplete CRL information?

Mike



 







From alan.sill@ttu.edu  Thu Feb 17 18:39:19 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3D03A6DA1 for ; Thu, 17 Feb 2011 18:39:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.099
X-Spam-Level: 
X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXRngDVZZgrk for ; Thu, 17 Feb 2011 18:39:18 -0800 (PST)
Received: from eurynomus.ttu.edu (eurynomus.ttu.edu [129.118.1.242]) by core3.amsl.com (Postfix) with ESMTP id 512CF3A6ABB for ; Thu, 17 Feb 2011 18:39:18 -0800 (PST)
Received: from hoplodamus.net.ttu.edu (129.118.1.213) by mxout3.ttu.edu (129.118.1.201) with Microsoft SMTP Server id 8.2.255.0; Thu, 17 Feb 2011 20:39:50 -0600
Received: from CRIUS.ttu.edu ([129.118.1.211]) by hoplodamus.net.ttu.edu ([129.118.1.213]) with mapi; Thu, 17 Feb 2011 20:39:50 -0600
From: "Sill, Alan" 
To: Michael StJohns 
Date: Thu, 17 Feb 2011 20:39:47 -0600
Thread-Topic: [pkix] What should be in "Next Update" field of the last  CRL?
Thread-Index: AcvPFRz/yjfWxYonQT2ZMvmUCFeRWg==
Message-ID: <0ED9282B-3132-4792-B44C-6D058248A71A@ttu.edu>
References:     <20110217012331.055DD3A6BA0@core3.amsl.com> <20110217013359.0A2213A6F09@core3.amsl.com> <4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu> <20110217015732.B4C3E3A6B60@core3.amsl.com> <60C013EE-3487-4E80-B7DB-CDA73104079B@ttu.edu>  <0ED5D8F9-C6C9-4599-B343-CEB1003883E9@ttu.edu>  <20110218011750.810FDF24027@odin.smetech.net> <41235DC4-A625-49F4-9D20-225C23C05C00@vigilsec.com> <20110218021748.890E63A6D23@core3.amsl.com>
In-Reply-To: <20110218021748.890E63A6D23@core3.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Received-SPF: Pass (eurynomus.ttu.edu: domain of alan.sill@ttu.edu designates 129.118.1.213 as permitted sender) receiver=eurynomus.ttu.edu;  client-ip=129.118.1.213; helo=hoplodamus.net.ttu.edu;
X-TechMail-Edge-Route: TTU
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last  CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Feb 2011 02:39:19 -0000

On Feb 17, 2011, at 8:18 PM, "Michael StJohns"  wrote=
:

> At 08:46 PM 2/17/2011, Russ Housley wrote:
>> Mike:
>>=20
>>>> If the CA certificate has been installed as a trust anchor, then the e=
xpiration time in the self-signed certificate has no role in the certificat=
ion path validation.
>>>=20
>>> Is that true in reality?  The typical trust anchor in a browser is a se=
lf-signed cert.  I'd have to check, but I'm pretty sure chaining fails if t=
he self-signed cert has expired.
>>=20
>> Browsers do this check, but nothing in RFC 5280 (or RFC 3280, or RFC 245=
9) imposes this requirement.
>>=20
>> Russ
>=20
>=20
> Which is kind of funny because a number of implementations treat the next=
Update field as a CRL expiration date - and that's doesn't appear to be the=
 processing recommended by 5280.=20
>=20
> I started researching this and found at least three implementations have =
either a fixed or configurable behavior which treats ALL certs under a CA a=
s invalid if they don't receive a new CRL before the nextUpdate date.  At l=
east one of these implementations does not have this behavior if it sees a =
CRL without the nextUpdate field  - but 5280 requires CRLs to have the fiel=
d. =20
>=20
> Section 6.3.3 of 5280 is fairly silent on what to do if you don't have th=
e most recent CRL - I read it that certs not on the CRLs that are in your p=
osession have the status of "UNDETERMINED".
>=20
> Is it time for a BCP on Certs as Trust Anchors and/or Cert Acceptance Pol=
icies given incomplete CRL information?
>=20
> Mike
>=20

This is exactly what I tried to point out earlier. It is surely up to each =
relying party, but all production infrastructure implementationd of which I=
 am aware treat things this way: if a CRL is not available after the time o=
f the "next update" value of the most current one expires, then no certific=
ates from that CA are considered valid.  And despite answers to the contrar=
y given by others on this list, I can't think of any popular implementation=
d that will accept EE certs from a CA after the expiration of the CA cert, =
either.=20



From DPKemp@missi.ncsc.mil  Fri Feb 18 06:38:36 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ECEA3A6DC6 for ; Fri, 18 Feb 2011 06:38:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQR4J-xyuS-o for ; Fri, 18 Feb 2011 06:38:34 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id 6D9D73A6CF2 for ; Fri, 18 Feb 2011 06:38:34 -0800 (PST)
Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p1IEd556029671; Fri, 18 Feb 2011 09:39:05 -0500 (EST)
Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 18 Feb 2011 09:38:25 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Fri, 18 Feb 2011 09:30:38 -0500
Message-ID: 
In-Reply-To: <0ED9282B-3132-4792-B44C-6D058248A71A@ttu.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [pkix] What should be in "Next Update" field of the last  CRL?
Thread-Index: AcvPFRz/yjfWxYonQT2ZMvmUCFeRWgAW0d4Q
References: <20110217012331.055DD3A6BA0@core3.amsl.com><20110217013359.0A2213A6F09@core3.amsl.com><4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu><20110217015732.B4C3E3A6B60@core3.amsl.com><60C013EE-3487-4E80-B7DB-CDA73104079B@ttu.edu><0ED5D8F9-C6C9-4599-B343-CEB1003883E9@ttu.edu><20110218011750.810FDF24027@odin.smetech.net><41235DC4-A625-49F4-9D20-225C23C05C00@vigilsec.com><20110218021748.890E63A6D23@core3.amsl.com> <0ED9282B-3132-4792-B44C-6D058248A71A@ttu.edu>
From: "Kemp, David P." 
To: "Sill, Alan" , "Michael StJohns" 
X-OriginalArrivalTime: 18 Feb 2011 14:38:25.0562 (UTC) FILETIME=[7FFF47A0:01CBCF79]
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last  CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Feb 2011 14:38:36 -0000

> I started researching this and found at least three
> implementations have either a fixed or configurable
> behavior which treats ALL certs under a CA as invalid
> if they don't receive a new CRL before the nextUpdate date.

That is particularly broken behavior, akin to running your car out of
gas every time and walking to the gas station with a can to get some
more.  For CAs that do not issue unscheduled CRLs, there is no way to
receive a new CRL before the nextUpdate date, so the application fails
at the end of every CRL waiting until the new CRL can be issued and
retrieved.  The workaround (forcing CAs to lie about nextUpdate so that
broken applications won't fail) is repulsive - the point of standards is
to enable parties that follow the standard to work correctly.

Dave


-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of
Sill, Alan
Sent: Thursday, February 17, 2011 9:40 PM
To: Michael StJohns
Cc: IETF PKIX
Subject: Re: [pkix] What should be in "Next Update" field of the last
CRL?





On Feb 17, 2011, at 8:18 PM, "Michael StJohns" 
wrote:

> At 08:46 PM 2/17/2011, Russ Housley wrote:
>> Mike:
>>=20
>>>> If the CA certificate has been installed as a trust anchor, then
the expiration time in the self-signed certificate has no role in the
certification path validation.
>>>=20
>>> Is that true in reality?  The typical trust anchor in a browser is a
self-signed cert.  I'd have to check, but I'm pretty sure chaining fails
if the self-signed cert has expired.
>>=20
>> Browsers do this check, but nothing in RFC 5280 (or RFC 3280, or RFC
2459) imposes this requirement.
>>=20
>> Russ
>=20
>=20
> Which is kind of funny because a number of implementations treat the
nextUpdate field as a CRL expiration date - and that's doesn't appear to
be the processing recommended by 5280.=20
>=20
> I started researching this and found at least three implementations
have either a fixed or configurable behavior which treats ALL certs
under a CA as invalid if they don't receive a new CRL before the
nextUpdate date.  At least one of these implementations does not have
this behavior if it sees a CRL without the nextUpdate field  - but 5280
requires CRLs to have the field. =20
>=20
> Section 6.3.3 of 5280 is fairly silent on what to do if you don't have
the most recent CRL - I read it that certs not on the CRLs that are in
your posession have the status of "UNDETERMINED".
>=20
> Is it time for a BCP on Certs as Trust Anchors and/or Cert Acceptance
Policies given incomplete CRL information?
>=20
> Mike
>=20

This is exactly what I tried to point out earlier. It is surely up to
each relying party, but all production infrastructure implementationd of
which I am aware treat things this way: if a CRL is not available after
the time of the "next update" value of the most current one expires,
then no certificates from that CA are considered valid.  And despite
answers to the contrary given by others on this list, I can't think of
any popular implementationd that will accept EE certs from a CA after
the expiration of the CA cert, either.=20


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

From helm@fionn.es.net  Fri Feb 18 12:55:39 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6FE3A6EB4 for ; Fri, 18 Feb 2011 12:55:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vho-8rCQ1wan for ; Fri, 18 Feb 2011 12:55:38 -0800 (PST)
Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by core3.amsl.com (Postfix) with ESMTP id 73F973A6DF1 for ; Fri, 18 Feb 2011 12:55:36 -0800 (PST)
Received: from fionn.es.net (localhost [127.0.0.1]) by fionn.es.net (8.13.7+Sun/8.13.7) with ESMTP id p1IKu8jn025982; Fri, 18 Feb 2011 12:56:09 -0800 (PST)
Message-Id: <201102182056.p1IKu8jn025982@fionn.es.net>
To: "Sill, Alan" 
In-reply-to: Your message of "Thu, 17 Feb 2011 20:39:47 CST." <0ED9282B-3132-4792-B44C-6D058248A71A@ttu.edu> 
Date: Fri, 18 Feb 2011 12:56:07 -0800
From: Mike Helm 
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: helm@fionn.es.net
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Feb 2011 20:55:39 -0000

"Sill, Alan" writes:
>  This is exactly what I tried to point out earlier. It is surely up
> to each relying party, but all production infrastructure
> implementationd of which I am aware treat things this way: if a CRL
> is not available after the time of the "next update" value of the
> most current one expires, then no certificates from that CA are
> considered valid. 

(One of )  the guilty party/ies here is openssl, so the problem
is both more widespread than the infrastructure we support,
and not completely that infrastructure's fault.  openssl has some
other crl quirks, at least some versions do.


The idea is very widespread, tho.  I think I remember it was
part of a security PKI checklist that NIST provided - I don't have
a copy of it any more & I don't know that it reached final publication
in NIST.  However many PKI specialists also seem to believe this
is the correct behavior.  I suppose it could be considered
correct behavior in the right framing, I wish it wasn't,
but it seems we have to treat it so.

Thanks, ==mwh
Michael Helm
ESnet/LBNL

From tgindin@us.ibm.com  Fri Feb 18 15:36:12 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10B113A6CB0 for ; Fri, 18 Feb 2011 15:36:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9k1bMHrDSmRL for ; Fri, 18 Feb 2011 15:36:10 -0800 (PST)
Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by core3.amsl.com (Postfix) with ESMTP id 7F9043A6D4D for ; Fri, 18 Feb 2011 15:36:09 -0800 (PST)
Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p1INB2T5026350 for ; Fri, 18 Feb 2011 18:11:02 -0500
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p1INab8u2723844 for ; Fri, 18 Feb 2011 18:36:37 -0500
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p1INaaHQ005748 for ; Fri, 18 Feb 2011 18:36:36 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p1INaaJs005743; Fri, 18 Feb 2011 18:36:36 -0500
In-Reply-To: <20110218021748.890E63A6D23@core3.amsl.com>
References: 	 	 <20110217012331.055DD3A6BA0@core3.amsl.com>	<20110217013359.0A2213A6F09@core3.amsl.com> <4964F50B-4715-479E-89C4-666F7D6C35F6@ttu.edu>	<20110217015732.B4C3E3A6B60@core3.amsl.com> <60C013EE-3487-4E80-B7DB-CDA73104079B@ttu.edu>	 <0ED5D8F9-C6C9-4599-B343-CEB1003883E9@ttu.edu>	 <20110218011750.810FDF24027@odin.smetech.net>	<41235DC4-A625-49F4-9D20-225C23C05C00@vigilsec.com> <20110218021748.890E63A6D23@core3.amsl.com>
To: Michael StJohns 
MIME-Version: 1.0
X-KeepSent: 03F66AC6:D67614F5-8525783B:0080BBB0; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009
From: Tom Gindin 
Message-ID: 
Date: Fri, 18 Feb 2011 18:36:35 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.2FP6|July 15, 2010) at 02/18/2011 18:36:36, Serialize complete at 02/18/2011 18:36:36
Content-Type: text/plain; charset="US-ASCII"
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last  CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Feb 2011 23:36:12 -0000

        In a practical sense, if nextUpdate is taken literally an RP 
should not expect to see a fresh CRL in the first few seconds after it 
because publication is not instantaneous.  So an RP can't really use that 
field as a CRL expiration time to fine granularity.   Treating nextUpdate 
+ gracePeriod as an expiration, with a brief grace period (perhaps less 
than an hour) is far likelier to work.

                Tom Gindin

P.S.    This is my opinion, and not necessarily that of my employer.




From:
Michael StJohns 
To:
Russ Housley 
Cc:
IETF PKIX 
Date:
02/17/2011 09:18 PM
Subject:
Re: [pkix] What should be in "Next Update" field of the last  CRL?
Sent by:
pkix-bounces@ietf.org



At 08:46 PM 2/17/2011, Russ Housley wrote:
>Mike:
>
>>> If the CA certificate has been installed as a trust anchor, then the 
expiration time in the self-signed certificate has no role in the 
certification path validation.
>> 
>> Is that true in reality?  The typical trust anchor in a browser is a 
self-signed cert.  I'd have to check, but I'm pretty sure chaining fails 
if the self-signed cert has expired.
>
>Browsers do this check, but nothing in RFC 5280 (or RFC 3280, or RFC 
2459) imposes this requirement.
>
>Russ


Which is kind of funny because a number of implementations treat the 
nextUpdate field as a CRL expiration date - and that's doesn't appear to 
be the processing recommended by 5280. 

 I started researching this and found at least three implementations have 
either a fixed or configurable behavior which treats ALL certs under a CA 
as invalid if they don't receive a new CRL before the nextUpdate date.  At 
least one of these implementations does not have this behavior if it sees 
a CRL without the nextUpdate field  - but 5280 requires CRLs to have the 
field. 

Section 6.3.3 of 5280 is fairly silent on what to do if you don't have the 
most recent CRL - I read it that certs not on the CRLs that are in your 
posession have the status of "UNDETERMINED".

Is it time for a BCP on Certs as Trust Anchors and/or Cert Acceptance 
Policies given incomplete CRL information?

Mike



 






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




From pgut001@login01.cs.auckland.ac.nz  Fri Feb 18 16:19:26 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8E6F3A6DC0 for ; Fri, 18 Feb 2011 16:19:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm63abRJkRKP for ; Fri, 18 Feb 2011 16:19:25 -0800 (PST)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 37F9B3A6D37 for ; Fri, 18 Feb 2011 16:19:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1298074801; x=1329610801; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20alan.sill@ttu.edu,=20roberto@opazo.cl|Subject:=20R e:=20[pkix]=20What=20should=20be=20in=20"Next=20Update" =20field=20of=20the=20last=20CRL?|Cc:=20pkix@ietf.org |In-Reply-To:=20|Message-Id:=20|Date:=20Sat,=2019=20Feb=202011 =2013:19:51=20+1300; bh=4G0t4WI9kImfH7mvvXLaQ7moCaOQ1wzHzq0PtrC3AQw=; b=jbwiolp6Wnus5HPQxr2TJ6XFfrvL59UOWqAt4BR4IiCIkwON43IAGllc 1RryV1Zba9F9hNVBV+ydeYiswZ7G++RR9cmCskO/gcOSXkq6d+Tomq215 flyo3amaNFXBgxG5kfRwRWeLpJOkd2uSWqyXPh3LX7DC3TKU+PtGJ0guR 8=;
X-IronPort-AV: E=Sophos;i="4.62,190,1296990000"; d="scan'208";a="46879457"
X-Ironport-HAT: APP-SERVERS - $RELAYED
X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing
Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Feb 2011 13:19:51 +1300
Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PqaYB-00020h-Gr; Sat, 19 Feb 2011 13:19:51 +1300
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PqaYB-0004WB-5j; Sat, 19 Feb 2011 13:19:51 +1300
From: Peter Gutmann 
To: alan.sill@ttu.edu, roberto@opazo.cl
In-Reply-To: 
Message-Id: 
Date: Sat, 19 Feb 2011 13:19:51 +1300
Cc: pkix@ietf.org
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Feb 2011 00:19:26 -0000

Roberto Opazo  writes:

>This is the first time for us on these situation. Next time is going to be in
>20 years, so I expect there will be and standard way to finish CA live at that
>time.

Given that we've had this problem for 20-odd years so far and no-one's fixed
it (and indeed I don't know if anyone even knows how to fix it), I doubt it...

>Have anybody an experience to share?
>
>How have other CAs ended?

The first time, very badly.  After that they set their root lifetimes to
longer than the career lifetime of the person who created the cert, so that
they'll be retired by the time it's a problem.

(I know that the above sounds like a tongue-in-cheek comment, but I'm being
serious, that seems to be the way to manage it, the first time it happens to
you you get burnt, then you set the lifetime to as long as you can to make
sure it never happens again).

Peter.

From pgut001@login01.cs.auckland.ac.nz  Fri Feb 18 18:03:41 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 801CF3A6CBA for ; Fri, 18 Feb 2011 18:03:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mT3Vr6AZcddc for ; Fri, 18 Feb 2011 18:03:40 -0800 (PST)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 49FC53A6CA1 for ; Fri, 18 Feb 2011 18:03:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1298081056; x=1329617056; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20jmdesp@free.fr,=20pkix@ietf.org|Subject:=20Re:=20[ pkix]=20What=20should=20be=20in=20"Next=20Update"=20field =20of=20the=20last=20CRL?|In-Reply-To:=20<4D5D48AE.60409@ free.fr>|Message-Id:=20|Date:=20Sat,=2019=20Feb=202011=2015:04:13=20 +1300; bh=Mrf/eDCWFaTUqtI0pc0mPXzzH7P63iSpD0IjDaMKmxk=; b=f9MJ5vEFDXS6ls0hKhlMSZ5QN0Hkre/pDVE5cD5fuCl77Q1c0K07Qp0E APRCEHaDyTEbwCOuA8VsDTqJT3kmMfF3NYRQP5Se9BgkCn+vUM4j/vdnw wzen6vn/2gsJt2wN70QWziouo0tz+bBpCduw12lcPgsD8a2RRlRRTNdvE A=;
X-IronPort-AV: E=Sophos;i="4.62,190,1296990000"; d="scan'208";a="46883644"
X-Ironport-HAT: APP-SERVERS - $RELAYED
X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing
Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Feb 2011 15:04:13 +1300
Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PqcBB-0004sh-Ga; Sat, 19 Feb 2011 15:04:13 +1300
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PqcBB-0001t0-32; Sat, 19 Feb 2011 15:04:13 +1300
From: Peter Gutmann 
To: jmdesp@free.fr, pkix@ietf.org
In-Reply-To: <4D5D48AE.60409@free.fr>
Message-Id: 
Date: Sat, 19 Feb 2011 15:04:13 +1300
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Feb 2011 02:03:41 -0000

Jean-Marc Desperrier  writes:
>Russ Housley wrote:
>> RFC 5280 says the following about a certificate notAfter field:
>>
>>     To indicate that a certificate has no well-defined expiration date,
>>     the notAfter SHOULD be assigned the GeneralizedTime value of
>>     99991231235959Z.
>
>The use of the date 9999 seems to be in order to use the highest value that
>doesn't have a 5 digits year. But given that the date is 23h 59:59 on the 31
>december, it will result in a date in the morning of 1 january 10.000 for all
>locales that have a positive offset to GMT. I think 99991231120000Z would be
>more convenient so that the year stays 9999 whatever the local time used to
>display it is.

Given that many time routines are going to reject this magic-value date anyway
because it exceeds the range of a 32-bit time_t (and/or should fall outside
sanity-check ranges for any sensible implementation), I don't think this will
be a problem, you'd need to implement it as:

  read date string;
  if( !memcmp( string, "9999...", length ) )
    return( special_date );
  convert string -> date;
  return( date );

Peter.

From mstjohns@comcast.net  Sat Feb 19 18:41:51 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5752C3A6D6D for ; Sat, 19 Feb 2011 18:41:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJQs-s7HZIFn for ; Sat, 19 Feb 2011 18:41:50 -0800 (PST)
Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 027033A6CBA for ; Sat, 19 Feb 2011 18:41:49 -0800 (PST)
Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta09.westchester.pa.mail.comcast.net with comcast id A0u21g0041ei1Bg592iUWA; Sun, 20 Feb 2011 02:42:28 +0000
Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta24.westchester.pa.mail.comcast.net with comcast id A2iR1g00e1EtFYL3k2iS5g; Sun, 20 Feb 2011 02:42:28 +0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sat, 19 Feb 2011 21:42:24 -0500
To: helm@fionn.es.net,"Sill, Alan" 
From: Michael StJohns 
In-Reply-To: <201102182056.p1IKu8jn025982@fionn.es.net>
References:  <201102182056.p1IKu8jn025982@fionn.es.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <20110220024150.027033A6CBA@core3.amsl.com>
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last  CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Feb 2011 02:41:51 -0000

*sigh*   

http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf

Items 4.4.11 and 4.4.12.

Somewhere the idea that "undetermined" equaled "not validated" crept into the process rather than being treated as a per acceptor policy decision.

Mike








At 03:56 PM 2/18/2011, Mike Helm wrote:
>"Sill, Alan" writes:
>>  This is exactly what I tried to point out earlier. It is surely up
>> to each relying party, but all production infrastructure
>> implementationd of which I am aware treat things this way: if a CRL
>> is not available after the time of the "next update" value of the
>> most current one expires, then no certificates from that CA are
>> considered valid. 
>
>(One of )  the guilty party/ies here is openssl, so the problem
>is both more widespread than the infrastructure we support,
>and not completely that infrastructure's fault.  openssl has some
>other crl quirks, at least some versions do.
>
>
>The idea is very widespread, tho.  I think I remember it was
>part of a security PKI checklist that NIST provided - I don't have
>a copy of it any more & I don't know that it reached final publication
>in NIST.  However many PKI specialists also seem to believe this
>is the correct behavior.  I suppose it could be considered
>correct behavior in the right framing, I wish it wasn't,
>but it seems we have to treat it so.
>
>Thanks, ==mwh
>Michael Helm
>ESnet/LBNL



From tgindin@us.ibm.com  Sun Feb 20 07:06:29 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD4823A6D9F for ; Sun, 20 Feb 2011 07:06:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYskktdPLIjW for ; Sun, 20 Feb 2011 07:06:28 -0800 (PST)
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id AAC8D3A6CFA for ; Sun, 20 Feb 2011 07:06:28 -0800 (PST)
Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e3.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p1KElDim000503 for ; Sun, 20 Feb 2011 09:47:13 -0500
Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p1KF6xtx282698 for ; Sun, 20 Feb 2011 10:07:01 -0500
Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p1KF6wWK014030 for ; Sun, 20 Feb 2011 10:06:58 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p1KF6wMK014027; Sun, 20 Feb 2011 10:06:58 -0500
In-Reply-To: 
References: <4D5D48AE.60409@free.fr> 
To: Peter Gutmann 
MIME-Version: 1.0
X-KeepSent: 3BE1C5E5:F9030F01-8525783D:00519B31; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009
From: Tom Gindin 
Message-ID: 
Date: Sun, 20 Feb 2011 10:06:58 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.2FP6|July 15, 2010) at 02/20/2011 10:06:58, Serialize complete at 02/20/2011 10:06:58
Content-Type: text/plain; charset="US-ASCII"
Cc: pkix@ietf.org
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Feb 2011 15:06:29 -0000

        Signed 32-bit times will be a problem soon enough for real 
certificates.  Issuers use 20-25 year root lifetimes all the time. and 
2**31 on Unix is Jan. 18 or 19, 2038.  There are a LOT of 2037 root 
expirations in a current standard XP store, but nothing later yet.  We can 
recommend that nobody go beyond rollover until exactly 20 years before it, 
and thus put off the evil day until seven years from now, but that's about 
it.  I'm sure most of the members of this list will still be working in 
2018.

                Tom Gindin




From:
Peter Gutmann 
To:
jmdesp@free.fr, pkix@ietf.org
Date:
02/18/2011 09:04 PM
Subject:
Re: [pkix] What should be in "Next Update" field of the last CRL?
Sent by:
pkix-bounces@ietf.org



Jean-Marc Desperrier  writes:
>Russ Housley wrote:
>> RFC 5280 says the following about a certificate notAfter field:
>>
>>     To indicate that a certificate has no well-defined expiration date,
>>     the notAfter SHOULD be assigned the GeneralizedTime value of
>>     99991231235959Z.
>
>The use of the date 9999 seems to be in order to use the highest value 
that
>doesn't have a 5 digits year. But given that the date is 23h 59:59 on the 
31
>december, it will result in a date in the morning of 1 january 10.000 for 
all
>locales that have a positive offset to GMT. I think 99991231120000Z would 
be
>more convenient so that the year stays 9999 whatever the local time used 
to
>display it is.

Given that many time routines are going to reject this magic-value date 
anyway
because it exceeds the range of a 32-bit time_t (and/or should fall 
outside
sanity-check ranges for any sensible implementation), I don't think this 
will
be a problem, you'd need to implement it as:

  read date string;
  if( !memcmp( string, "9999...", length ) )
    return( special_date );
  convert string -> date;
  return( date );

Peter.
_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix




From andrea.caccia@studiocaccia.com  Sun Feb 20 10:15:47 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B22F3A6F4C for ; Sun, 20 Feb 2011 10:15:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H63q9CTYKUCn for ; Sun, 20 Feb 2011 10:15:46 -0800 (PST)
Received: from smtplq03.aruba.it (smtplq-out8.aruba.it [62.149.158.28]) by core3.amsl.com (Postfix) with SMTP id 3B68B3A6E09 for ; Sun, 20 Feb 2011 10:15:45 -0800 (PST)
Received: (qmail 21770 invoked by uid 89); 20 Feb 2011 18:16:20 -0000
Received: from unknown (HELO smtp6.aruba.it) (62.149.158.226) by smtplq03.aruba.it with SMTP; 20 Feb 2011 18:16:20 -0000
Received: (qmail 3441 invoked by uid 89); 20 Feb 2011 18:16:22 -0000
Received: from unknown (HELO ?192.168.10.100?) (andrea.caccia@studiocaccia.com@79.48.122.46) by smtp6.ad.aruba.it with ESMTPA; 20 Feb 2011 18:16:21 -0000
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1082)
From: Andrea Caccia 
In-Reply-To: 
Date: Sun, 20 Feb 2011 19:16:22 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0CEF838B-AA50-415A-B1B0-C52EAD56A4A8@studiocaccia.com>
References: <4D5D48AE.60409@free.fr>  
To: pkix@ietf.org
X-Mailer: Apple Mail (2.1082)
X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Feb 2011 18:15:47 -0000

After all, why not simply stop the CA when its certificate expires with =
the last CRL next update generated with the same rules of previous ones?
Advantages:
- no special effort to generate a specific CRL
- no RFC 5280 rule breaking
- every CRL next update is somehow a lie, so the better is to choose the =
most effective
- there could be the need to generate an additional CRL in the unlikely =
event that some certificate has been revoked in the time frame between =
issuance of last CRL and CA cert expiration (also those certificates =
MUST be present at least in one CRL)
- verification software should correctly manage correctly without =
modifications the situation and discard signatures because the CA cert =
is expired and/or no fresh CRL is available within the grace period =
after CRL next update
- no problem to manage the date (signed 32bit times, local time =
>31/12/9999, =85)

Disadvantages?

Andrea Caccia


Il giorno 20/feb/2011, alle ore 16.06, Tom Gindin ha scritto:

>        Signed 32-bit times will be a problem soon enough for real=20
> certificates.  Issuers use 20-25 year root lifetimes all the time. and=20=

> 2**31 on Unix is Jan. 18 or 19, 2038.  There are a LOT of 2037 root=20
> expirations in a current standard XP store, but nothing later yet.  We =
can=20
> recommend that nobody go beyond rollover until exactly 20 years before =
it,=20
> and thus put off the evil day until seven years from now, but that's =
about=20
> it.  I'm sure most of the members of this list will still be working =
in=20
> 2018.
>=20
>                Tom Gindin
>=20
>=20
>=20
>=20
> From:
> Peter Gutmann 
> To:
> jmdesp@free.fr, pkix@ietf.org
> Date:
> 02/18/2011 09:04 PM
> Subject:
> Re: [pkix] What should be in "Next Update" field of the last CRL?
> Sent by:
> pkix-bounces@ietf.org
>=20
>=20
>=20
> Jean-Marc Desperrier  writes:
>> Russ Housley wrote:
>>> RFC 5280 says the following about a certificate notAfter field:
>>>=20
>>>    To indicate that a certificate has no well-defined expiration =
date,
>>>    the notAfter SHOULD be assigned the GeneralizedTime value of
>>>    99991231235959Z.
>>=20
>> The use of the date 9999 seems to be in order to use the highest =
value=20
> that
>> doesn't have a 5 digits year. But given that the date is 23h 59:59 on =
the=20
> 31
>> december, it will result in a date in the morning of 1 january 10.000 =
for=20
> all
>> locales that have a positive offset to GMT. I think 99991231120000Z =
would=20
> be
>> more convenient so that the year stays 9999 whatever the local time =
used=20
> to
>> display it is.
>=20
> Given that many time routines are going to reject this magic-value =
date=20
> anyway
> because it exceeds the range of a 32-bit time_t (and/or should fall=20
> outside
> sanity-check ranges for any sensible implementation), I don't think =
this=20
> will
> be a problem, you'd need to implement it as:
>=20
>  read date string;
>  if( !memcmp( string, "9999...", length ) )
>    return( special_date );
>  convert string -> date;
>  return( date );
>=20
> Peter.
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>=20
>=20
>=20
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix


From pgut001@login01.cs.auckland.ac.nz  Sun Feb 20 11:44:16 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1D0E3A6D60 for ; Sun, 20 Feb 2011 11:44:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xbm43Au2XrGi for ; Sun, 20 Feb 2011 11:44:15 -0800 (PST)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 6276E3A6D2B for ; Sun, 20 Feb 2011 11:44:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1298231095; x=1329767095; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20pgut001@cs.auckland.ac.nz,=20tgindin@us.ibm.com |Subject:=20Re:=20[pkix]=20What=20should=20be=20in=20"Nex t=20Update"=20field=20of=20the=20last=20CRL?|Cc:=20pkix@i etf.org|In-Reply-To:=20|Message-Id:=20|Date:=20Mon,=202 1=20Feb=202011=2008:44:51=20+1300; bh=Lsfg1ZpI7+8sVJXjz4Xyi+jmbyEwrC6JBqY5N7FpVWE=; b=VJ9IB/FrBMmnW4hbbGBN4PM5y9uYUetDYrWh9PHNarjazXUNjVbCvj33 v3Vpsl6wIK4lQBIn0gmqiiewLocz4fRfODUyj0bzrd+lFMYfhYsa77Rii cap2/2WXIP0QVnZ882uyk5kH3DMK7Z06fG0BSqUB/v3k6sj68wY0Upnoz 0=;
X-IronPort-AV: E=Sophos;i="4.62,195,1296990000"; d="scan'208";a="46983337"
X-Ironport-HAT: APP-SERVERS - $RELAYED
X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing
Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 21 Feb 2011 08:44:52 +1300
Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PrFD9-0006nH-JI; Mon, 21 Feb 2011 08:44:51 +1300
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PrFD9-00027W-UA; Mon, 21 Feb 2011 08:44:51 +1300
From: Peter Gutmann 
To: pgut001@cs.auckland.ac.nz, tgindin@us.ibm.com
In-Reply-To: 
Message-Id: 
Date: Mon, 21 Feb 2011 08:44:51 +1300
Cc: pkix@ietf.org
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Feb 2011 19:44:17 -0000

Tom Gindin  writes:

>I'm sure most of the members of this list will still be working in 2018.

That's OK, I'm sure most of the rest of us will still be waiting for PKI to
start working in 2018 too :-).

Peter.

From swilson@lockstep.com.au  Sun Feb 20 17:13:38 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E38313A6EAC for ; Sun, 20 Feb 2011 17:13:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.847
X-Spam-Level: 
X-Spam-Status: No, score=-0.847 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E36z-whH7oDh for ; Sun, 20 Feb 2011 17:13:38 -0800 (PST)
Received: from smtp192.iad.emailsrvr.com (smtp192.iad.emailsrvr.com [207.97.245.192]) by core3.amsl.com (Postfix) with ESMTP id 114963A6CC3 for ; Sun, 20 Feb 2011 17:13:38 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp39.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id B9D0D98579; Sun, 20 Feb 2011 20:14:17 -0500 (EST)
X-Virus-Scanned: OK
Received: from dynamic1.wm-web.iad.mlsrvr.com (dynamic1.wm-web.iad1a.rsapps.net [192.168.2.150]) by smtp39.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id A57DD9817F; Sun, 20 Feb 2011 20:14:17 -0500 (EST)
Received: from lockstep.com.au (localhost [127.0.0.1]) by dynamic1.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 9613AC98070;  Sun, 20 Feb 2011 20:14:17 -0500 (EST)
Received: by apps.rackspace.com (Authenticated sender: swilson@lockstep.com.au, from: swilson@lockstep.com.au)  with HTTP; Mon, 21 Feb 2011 12:14:17 +1100 (EST)
Date: Mon, 21 Feb 2011 12:14:17 +1100 (EST)
From: swilson@lockstep.com.au
To: "Peter Gutmann" 
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
In-Reply-To: 
References: 
Message-ID: <1298250857.61254538@192.168.4.58>
X-Mailer: webmail8
Cc: pkix@ietf.org
Subject: Re: [pkix] =?utf-8?q?What_should_be_in_=22Next_Update=22_field_of_the?= =?utf-8?q?_last_CRL=3F?=
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Feb 2011 01:13:39 -0000

=0AFor completeness, here is a boring answer to a very boring quip ... =0A=
=0APKI has been working great for a couple of decades but in closed communi=
ties for authorization rather than in open utopian communities for authenti=
cation.  =0A=0ASee: =0A=0A- the GSM system=0A- EMV DDA cards =0A- cable TV =
set-top boxes =0A- ID cards in Malaysia, Hong Kong, Estonia ... =0A- health=
 smartcards in Austria, Italy, France, Germany, Taiwan ... =0A=0AI have arg=
ued that closed PKI should be actually be regarded as the general case, whi=
le the old idea of open PKI (which is what I presume you're referring to) f=
or stranger-to-stranger trust is a special case, not very useful, and unsur=
prisingly unsuccessful.  =0A=0ASee "Public Key Superstructure" (easily Goog=
led). =0A=0ACheers, =0A=0ASteve Wilson=0ALockstep=0Ahttp://lockstep.com.au=
=0A=0A=0A=0A=0A-----Original Message-----=0AFrom: "Peter Gutmann" =0ASent: Monday, 21 February, 2011 6:44am=0ATo: pgut001@c=
s.auckland.ac.nz, tgindin@us.ibm.com=0ACc: pkix@ietf.org=0ASubject: Re: [pk=
ix] What should be in "Next Update" field of the last CRL?=0A=0ATom Gindin =
 writes:=0A=0A>I'm sure most of the members of this lis=
t will still be working in 2018.=0A=0AThat's OK, I'm sure most of the rest =
of us will still be waiting for PKI to=0Astart working in 2018 too :-).=0A=
=0APeter.=0A_______________________________________________=0Apkix mailing =
list=0Apkix@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/pkix=0A


From tmiller@mitre.org  Mon Feb 21 06:28:58 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDD323A70F8 for ; Mon, 21 Feb 2011 06:28:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Athg9bfjN9aQ for ; Mon, 21 Feb 2011 06:28:57 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 1BBEA3A707F for ; Mon, 21 Feb 2011 06:28:56 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8DCE421B1329; Mon, 21 Feb 2011 09:29:38 -0500 (EST)
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 83C9C21B1971; Mon, 21 Feb 2011 09:29:38 -0500 (EST)
Received: from IMCMBX2.MITRE.ORG ([129.83.29.209]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Mon, 21 Feb 2011 09:05:03 -0500
From: "Miller, Timothy J." 
To: "" 
Date: Mon, 21 Feb 2011 09:05:01 -0500
Thread-Topic: [pkix] What should be in "Next Update" field of the last CRL?
Thread-Index: AcvR0FU1Dh2jKrB/QqiIMr9Qa0jOcg==
Message-ID: 
References:  <1298250857.61254538@192.168.4.58>
In-Reply-To: <1298250857.61254538@192.168.4.58>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail-4-14838607"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Feb 2011 14:28:58 -0000

--Apple-Mail-4-14838607
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Feb 20, 2011, at 7:14 PM,  wrote:

> I have argued that closed PKI should be actually be regarded as the =
general case, while the old idea of open PKI (which is what I presume =
you're referring to) for stranger-to-stranger trust is a special case, =
not very useful, and unsurprisingly unsuccessful. =20

SPKI/SDSI, anyone?  :)

-- T


--Apple-Mail-4-14838607
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw
ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE
CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt
YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy
ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT
EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy
PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7
RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ
t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8
rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud
EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I
ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd
dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw
0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F
UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v
Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV
BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp
bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0xMTAyMjExNDA1MDJaMCMGCSqGSIb3DQEJBDEWBBSgvfdFHnegSYgXKD5f
5Ff5LS0dAzByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV
Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5
IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV
BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp
bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgGX2OnzqXHmAweSZbgbBLoczq8UU0yPNrGCj
c0Nv7j0sAnJKcqEyEVS9jyzXgv2XTq8afeanxYciNaAu8ucVrwC5q4LIkywOaE5J0//ksmIDT5RT
dkVUj8m5zuE6EmMKEXlQsMPK+ToqcrWeVolZFVuZ3NY59V40K395flL1Lg4yAAAAAAAA

--Apple-Mail-4-14838607--

From stefan@aaa-sec.com  Tue Feb 22 06:38:57 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504333A67E1 for ; Tue, 22 Feb 2011 06:38:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.649
X-Spam-Level: 
X-Spam-Status: No, score=-102.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpJKChuOgSsU for ; Tue, 22 Feb 2011 06:38:56 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by core3.amsl.com (Postfix) with ESMTP id 5182F3A67D8 for ; Tue, 22 Feb 2011 06:38:53 -0800 (PST)
Received: from s128.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 0D3862B4670 for ; Tue, 22 Feb 2011 15:39:41 +0100 (CET)
Received: (qmail 36961 invoked from network); 22 Feb 2011 14:39:35 -0000
Received: from cisne-cn13.upc.es (HELO [10.183.18.209]) (stefan@fiddler.nu@[147.83.182.13]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 22 Feb 2011 14:39:35 -0000
User-Agent: Microsoft-MacOutlook/14.2.0.101115
Date: Tue, 22 Feb 2011 15:39:32 +0100
From: Stefan Santesson 
To: "pkix@ietf.org" 
Message-ID: 
Thread-Topic: [pkix] What should be in "Next Update" field of the last CRL?
In-Reply-To: <4D5D5A7E.2090208@vpnc.org>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Feb 2011 14:38:57 -0000

Back to the original topic, I lack the dimension of whether the CA that is
being closed has issued certificates that are still valid.

If there are no valid issued certificates, the issue seems obsolete. Just
close the shop. It's fine if the last CRL has a next-update indicating the
date of death, either of the CA or the last issued certificate.

If there are some certificates still valid and you are closing the CA
anyway, then there is something not entirely right. You either need to
renew the CA or invalidate the still valid certificates.

To in such case set a distant CRL next update time and close the shop
seems to be a confusing solution as it ignores the need for future
revocation and fails to provide a valid CA certificate for the "valid"
issued certificates.

/Stefan

On 11-02-17 6:27 PM, "Paul Hoffman"  wrote:

>On 2/17/11 8:58 AM, Miller, Timothy J. wrote:
>> On Feb 17, 2011, at 10:30 AM, Paul Hoffman wrote:
>>
>>> Exactly. The previous replies on this thread that said that a relying
>>> party would not validate a certificate that used this CA either were
>>> thinking that the CA was an intermediate CA or were forgetting the PKIX
>>> trust anchor model from section 6.1 of 5280.
>>
>> Good point.  But then again, many (most?) extant implementations make
>>the same error.
>
>It is not an error, it is a policy decision based on erroneous
>understanding of PKIX. :-) Seriously, though, because many extant
>implementations do *not* make that error^Wpolicy decision, the answer to
>the question that started this thread should be to deal with both types
>of systems and to continue to set the "next update" to a date when a
>next update can be expected. If the CA has decided to never do a next
>update, use the forever-ish standard for notAfter; otherwise, be honest
>and say when you think you might update the CRL again.
>_______________________________________________
>pkix mailing list
>pkix@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix



From stefan@aaa-sec.com  Tue Feb 22 07:29:01 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99EB33A6907 for ; Tue, 22 Feb 2011 07:29:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.949
X-Spam-Level: 
X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTROQcG1KZOL for ; Tue, 22 Feb 2011 07:28:59 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by core3.amsl.com (Postfix) with ESMTP id 39F673A68F8 for ; Tue, 22 Feb 2011 07:28:58 -0800 (PST)
Received: from s128.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 97AD4290608 for ; Tue, 22 Feb 2011 16:29:46 +0100 (CET)
Received: (qmail 53288 invoked from network); 22 Feb 2011 15:29:40 -0000
Received: from cisne-cn13.upc.es (HELO [10.183.18.209]) (stefan@fiddler.nu@[147.83.182.13]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 22 Feb 2011 15:29:40 -0000
User-Agent: Microsoft-MacOutlook/14.2.0.101115
Date: Tue, 22 Feb 2011 16:29:37 +0100
From: Stefan Santesson 
To: "Kemp, David P." , "Sill, Alan" , Michael StJohns 
Message-ID: 
Thread-Topic: [pkix] What should be in "Next Update" field of the last  CRL?
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last  CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Feb 2011 15:29:01 -0000

In reality this is even worse.

There are clearly real situations where the RP need to have both an expiry
date (Don't use this CRL after..) and a date when the next update is
available.

Since most applications treat nextUpdate as the expiry date, and in order
to stay compliant with these implementations, Microsoft defined the
private extension "nextIssue", expressing the expected date when a new CRL
should be available.

The motivation AFAIK was to allow applications (understanding the private
extension) to start caching the new CRL (which sometimes can be quite big)
in the background before the current CRL expires and thus allow a smooth
user experience, not having to wait for 50 MB CRL downloads on CRL
transitions. At the same time allowing standards compliant implementations
to work without breaking.

I don't promote this for standardization. This is just an example of what
happens when people tries to deal with real issues.

/Stefan



On 11-02-18 3:30 PM, "Kemp, David P."  wrote:

>> I started researching this and found at least three
>> implementations have either a fixed or configurable
>> behavior which treats ALL certs under a CA as invalid
>> if they don't receive a new CRL before the nextUpdate date.
>
>That is particularly broken behavior, akin to running your car out of
>gas every time and walking to the gas station with a can to get some
>more.  For CAs that do not issue unscheduled CRLs, there is no way to
>receive a new CRL before the nextUpdate date, so the application fails
>at the end of every CRL waiting until the new CRL can be issued and
>retrieved.  The workaround (forcing CAs to lie about nextUpdate so that
>broken applications won't fail) is repulsive - the point of standards is
>to enable parties that follow the standard to work correctly.
>
>Dave
>
>
>-----Original Message-----
>From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of
>Sill, Alan
>Sent: Thursday, February 17, 2011 9:40 PM
>To: Michael StJohns
>Cc: IETF PKIX
>Subject: Re: [pkix] What should be in "Next Update" field of the last
>CRL?
>
>
>
>
>
>On Feb 17, 2011, at 8:18 PM, "Michael StJohns" 
>wrote:
>
>> At 08:46 PM 2/17/2011, Russ Housley wrote:
>>> Mike:
>>> 
>>>>> If the CA certificate has been installed as a trust anchor, then
>the expiration time in the self-signed certificate has no role in the
>certification path validation.
>>>> 
>>>> Is that true in reality?  The typical trust anchor in a browser is a
>self-signed cert.  I'd have to check, but I'm pretty sure chaining fails
>if the self-signed cert has expired.
>>> 
>>> Browsers do this check, but nothing in RFC 5280 (or RFC 3280, or RFC
>2459) imposes this requirement.
>>> 
>>> Russ
>> 
>> 
>> Which is kind of funny because a number of implementations treat the
>nextUpdate field as a CRL expiration date - and that's doesn't appear to
>be the processing recommended by 5280.
>> 
>> I started researching this and found at least three implementations
>have either a fixed or configurable behavior which treats ALL certs
>under a CA as invalid if they don't receive a new CRL before the
>nextUpdate date.  At least one of these implementations does not have
>this behavior if it sees a CRL without the nextUpdate field  - but 5280
>requires CRLs to have the field.
>> 
>> Section 6.3.3 of 5280 is fairly silent on what to do if you don't have
>the most recent CRL - I read it that certs not on the CRLs that are in
>your posession have the status of "UNDETERMINED".
>> 
>> Is it time for a BCP on Certs as Trust Anchors and/or Cert Acceptance
>Policies given incomplete CRL information?
>> 
>> Mike
>> 
>
>This is exactly what I tried to point out earlier. It is surely up to
>each relying party, but all production infrastructure implementationd of
>which I am aware treat things this way: if a CRL is not available after
>the time of the "next update" value of the most current one expires,
>then no certificates from that CA are considered valid.  And despite
>answers to the contrary given by others on this list, I can't think of
>any popular implementationd that will accept EE certs from a CA after
>the expiration of the CA cert, either.
>
>
>_______________________________________________
>pkix mailing list
>pkix@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix
>_______________________________________________
>pkix mailing list
>pkix@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix



From david.cooper@nist.gov  Tue Feb 22 09:39:04 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D5A03A693F for ; Tue, 22 Feb 2011 09:39:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.87
X-Spam-Level: 
X-Spam-Status: No, score=-5.87 tagged_above=-999 required=5 tests=[AWL=-0.729,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XETUWb1Jvw4A for ; Tue, 22 Feb 2011 09:39:02 -0800 (PST)
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id 88C5B3A6929 for ; Tue, 22 Feb 2011 09:39:02 -0800 (PST)
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p1MHdhHH022028; Tue, 22 Feb 2011 12:39:43 -0500
Message-ID: <4D63F4D8.7040903@nist.gov>
Date: Tue, 22 Feb 2011 12:39:36 -0500
From: "David A. Cooper" 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20101222 Mandriva/3.0.11-0.1mdv2010.2 (2010.2) Thunderbird/3.0.11
MIME-Version: 1.0
To: Michael StJohns 
References: 	<201102182056.p1IKu8jn025982@fionn.es.net> <20110220024150.027033A6CBA@core3.amsl.com>
In-Reply-To: <20110220024150.027033A6CBA@core3.amsl.com>
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Cc: IETF PKIX 
Subject: [pkix] nextUpdate as expiration date (was Re: What should be in "Next Update" field of the last CRL?)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Feb 2011 17:39:04 -0000




  
  


As the author of
http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf, I
would like to note that it was not the intention of this test suite to
imply that nextUpdate must be treated as an expiration date for a CRL. 
Version 1.0 of PKITS came out in September 2004, and the CRLs for tests
4.4.11 and 4.4.12 had nextUpdate times of January 2002 and January
1999, respectively.  An application could be configured to allow for a
CRL to be used after its nextUpdate time had passed, as long as it
verified that the nextUpdate time was not too far in the past, and
still get the correct results for the tests, and that was intentional.



Section 4.4 of that document contains the introduction to the basic
certificate revocation tests and it says:




The application must be able to retrieve valid revocation
data for each certificate in the path. For a CRL to be considered to
contain valid revocation data for a certificate, the CRL must at a
minimum: (1) be signed by the issuer of the certificate or by an entity
that has been authorized by the certificate issuer to provide status
information for the certificate; (2) have a scope that includes the
certificate of interest; and (3) be sufficiently up-to-date.

  

In general, if the current time is before the time specified in the nextUpdate
field of a CRL, then that CRL should be considered sufficiently
up-to-date since the CRL issuer has indicated that this CRL may contain
the most up-to-date information available. Similarly, if the current
time is after the time specified in the nextUpdate field of a
CRL, then the CRL should not be considered to be sufficiently
up-to-date since the CRL issuer has indicated that more up-to-date
information should be available.

  

Even if the current time is after the time specified in the nextUpdate
field of a CRL, an application may still make a local decision to treat
the CRL as being sufficiently up-to-date. The

application may, for example, be configurable to allow CRLs to be
treated as sufficiently up-to-date, even if the current time is after
the nextUpdate time, if the CRL was issued recently (e.g., the
user or administrator configuring the system could indicate that a CRL
may be used as long as the current time is within 72 hours of the thisUpdate
time in the CRL, no matter how frequently the CRL issuer chooses to
issue CRLs).

  

In this section, there are only two tests in which the nextUpdate
time in a CRL is before the current time. In each case, the nextUpdate
time (and thisUpdate time) is more than two years before the
current time. So, it is expected that applications will be configured
so that these CRLs are not considered to be sufficiently up-to-date.

  

Even if an application is unable to find valid revocation data (that is
considered to be sufficiently up-to-date) for every certificate in the
path, the application may still make a local decision to use the
certification path. The application may, for example, allow the user or
an administrator to configure the application to ignore the
unavailability of revocation data. In the case of an interactive
application, the application may display a warning to the user and then
allow the user to decide whether to proceed to use the certification
path despite the lack of revocation data. However, the application may
not be designed in such a way that the unavailability of revocation
data is always ignored, whether the user (or administrator) wants the
application to behave that way or not. When running the tests in this
section, the application should be configured in such a way that the
certification path is not accepted unless valid, up-to-date revocation
data is available for every certificate in the path. Thus, when run in
this configuration, when the application is unable to find valid,
up-to-date revocation data for every certificate in the path, the
application must either reject the certification path or at least
display a warning to the user indicating that the status of the
certificate can not be determined.







Dave



On 02/19/2011 09:42 PM, Michael StJohns wrote:


  
*sigh*   

http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf

Items 4.4.11 and 4.4.12.

Somewhere the idea that "undetermined" equaled "not validated" crept into the process rather than being treated as a per acceptor policy decision.

Mike

At 03:56 PM 2/18/2011, Mike Helm wrote:
  

  

    
"Sill, Alan" writes:
    

    

      
 This is exactly what I tried to point out earlier. It is surely up
to each relying party, but all production infrastructure
implementationd of which I am aware treat things this way: if a CRL
is not available after the time of the "next update" value of the
most current one expires, then no certificates from that CA are
considered valid. 
      

    

    
(One of )  the guilty party/ies here is openssl, so the problem
is both more widespread than the infrastructure we support,
and not completely that infrastructure's fault.  openssl has some
other crl quirks, at least some versions do.


The idea is very widespread, tho.  I think I remember it was
part of a security PKI checklist that NIST provided - I don't have
a copy of it any more & I don't know that it reached final publication
in NIST.  However many PKI specialists also seem to believe this
is the correct behavior.  I suppose it could be considered
correct behavior in the right framing, I wish it wasn't,
but it seems we have to treat it so.

Thanks, ==mwh
Michael Helm
ESnet/LBNL
    

  








From mstjohns@comcast.net  Tue Feb 22 11:02:55 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D511E3A68EA for ; Tue, 22 Feb 2011 11:02: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=[AWL=-0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMt4HPIvT16y for ; Tue, 22 Feb 2011 11:02:54 -0800 (PST)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id D917F3A67F9 for ; Tue, 22 Feb 2011 11:02:53 -0800 (PST)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta08.westchester.pa.mail.comcast.net with comcast id B6vh1g0060vyq2s5873f9e; Tue, 22 Feb 2011 19:03:39 +0000
Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta05.westchester.pa.mail.comcast.net with comcast id B73d1g00J1EtFYL3R73eub; Tue, 22 Feb 2011 19:03:39 +0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 22 Feb 2011 14:03:35 -0500
To: "David A. Cooper" 
From: Michael StJohns 
In-Reply-To: <4D63F4D8.7040903@nist.gov>
References:  <201102182056.p1IKu8jn025982@fionn.es.net> <20110220024150.027033A6CBA@core3.amsl.com> <4D63F4D8.7040903@nist.gov>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_403922999==.ALT"
Message-Id: <20110222190253.D917F3A67F9@core3.amsl.com>
Cc: IETF PKIX 
Subject: Re: [pkix] nextUpdate as expiration date (was Re: What should be in "Next Update" field of the last CRL?)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Feb 2011 19:02:55 -0000

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

Hi David -

Issue isn't 4.4, but 4.4.11 and 4.4.12 text which says:

>Expected Result: The path should not validate successfully since the status=
 of the end
>entity's certificate can not be determined.

without reference back to the text you cite. =20

It's true that 4.4 has the "local decision to treat the CRL as being=
 sufficiently up-to-date", but the "should not validate successfully" in the=
 test text is going to be or was what gets/got implemented.  Testable=
 criteria always wins...

Mike


At 12:39 PM 2/22/2011, David A. Cooper wrote:
>As the author of=
 http:=
//csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf, I would=
 like to note that it was not the intention of this test suite to imply that=
 nextUpdate must be treated as an expiration date for a CRL.  Version 1.0 of=
 PKITS came out in September 2004, and the CRLs for tests 4.4.11 and 4.4.12=
 had nextUpdate times of January 2002 and January 1999, respectively.  An=
 application could be configured to allow for a CRL to be used after its=
 nextUpdate time had passed, as long as it verified that the nextUpdate time=
 was not too far in the past, and still get the correct results for the=
 tests, and that was intentional.
>
>Section 4.4 of that document contains the introduction to the basic=
 certificate revocation tests and it says:
>
>The application must be able to retrieve valid revocation data for each=
 certificate in the path. For a CRL to be considered to contain valid=
 revocation data for a certificate, the CRL must at a minimum: (1) be signed=
 by the issuer of the certificate or by an entity that has been authorized=
 by the certificate issuer to provide status information for the=
 certificate; (2) have a scope that includes the certificate of interest;=
 and (3) be sufficiently up-to-date.
>
>In general, if the current time is before the time specified in the=
 nextUpdate field of a CRL, then that CRL should be considered sufficiently=
 up-to-date since the CRL issuer has indicated that this CRL may contain the=
 most up-to-date information available. Similarly, if the current time is=
 after the time specified in the nextUpdate field of a CRL, then the CRL=
 should not be considered to be sufficiently up-to-date since the CRL issuer=
 has indicated that more up-to-date information should be available.
>
>Even if the current time is after the time specified in the nextUpdate=
 field of a CRL, an application may still make a local decision to treat the=
 CRL as being sufficiently up-to-date. The
>application may, for example, be configurable to allow CRLs to be treated=
 as sufficiently up-to-date, even if the current time is after the=
 nextUpdate time, if the CRL was issued recently (e.g., the user or=
 administrator configuring the system could indicate that a CRL may be used=
 as long as the current time is within 72 hours of the thisUpdate time in=
 the CRL, no matter how frequently the CRL issuer chooses to issue CRLs).
>
>In this section, there are only two tests in which the nextUpdate time in a=
 CRL is before the current time. In each case, the nextUpdate time (and=
 thisUpdate time) is more than two years before the current time. So, it is=
 expected that applications will be configured so that these CRLs are not=
 considered to be sufficiently up-to-date.
>
>Even if an application is unable to find valid revocation data (that is=
 considered to be sufficiently up-to-date) for every certificate in the=
 path, the application may still make a local decision to use the=
 certification path. The application may, for example, allow the user or an=
 administrator to configure the application to ignore the unavailability of=
 revocation data. In the case of an interactive application, the application=
 may display a warning to the user and then allow the user to decide whether=
 to proceed to use the certification path despite the lack of revocation=
 data. However, the application may not be designed in such a way that the=
 unavailability of revocation data is always ignored, whether the user (or=
 administrator) wants the application to behave that way or not. When=
 running the tests in this section, the application should be configured in=
 such a way that the certification path is not accepted unless valid,=
 up-to-date revocation data is available for every certificate in the path.=
 Thus, when run in this configuration, when the application is unable to=
 find valid, up-to-date revocation data for every certificate in the path,=
 the application must either reject the certification path or at least=
 display a warning to the user indicating that the status of the certificate=
 can not be determined.
>
>
>
>Dave
>
>On 02/19/2011 09:42 PM, Michael StJohns wrote:=20
>>
>>*sigh*  =20
>>
>>http=
://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf
>>
>>Items 4.4.11 and 4.4.12.
>>
>>Somewhere the idea that "undetermined" equaled "not validated" crept into=
 the process rather than being treated as a per acceptor policy decision.
>>
>>Mike
>>
>>At 03:56 PM 2/18/2011, Mike Helm wrote:
>> =20
>>>
>>>"Sill, Alan" writes:
>>>   =20
>>>>
>>>> This is exactly what I tried to point out earlier. It is surely up
>>>>to each relying party, but all production infrastructure
>>>>implementationd of which I am aware treat things this way: if a CRL
>>>>is not available after the time of the "next update" value of the
>>>>most current one expires, then no certificates from that CA are
>>>>considered valid.=20
>>>>     =20
>>>
>>>
>>>(One of )  the guilty party/ies here is openssl, so the problem
>>>is both more widespread than the infrastructure we support,
>>>and not completely that infrastructure's fault.  openssl has some
>>>other crl quirks, at least some versions do.
>>>
>>>
>>>The idea is very widespread, tho.  I think I remember it was
>>>part of a security PKI checklist that NIST provided - I don't have
>>>a copy of it any more & I don't know that it reached final publication
>>>in NIST.  However many PKI specialists also seem to believe this
>>>is the correct behavior.  I suppose it could be considered
>>>correct behavior in the right framing, I wish it wasn't,
>>>but it seems we have to treat it so.
>>>
>>>Thanks, =3D=3Dmwh
>>>Michael Helm
>>>ESnet/LBNL
>>>   =20


--=====================_403922999==.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Hi David -


Issue isn't 4.4, but 4.4.11 and 4.4.12 text which says:




Expected Result: The
path should not validate successfully since the status of the end

entity's certificate can not be determined.


without reference back to the text you cite.  


It's true that 4.4 has the "local decision to treat the CRL as being
sufficiently up-to-date", but the "should not validate
successfully" in the test text is going to be or was what gets/got
implemented.  Testable criteria always wins...


Mike




At 12:39 PM 2/22/2011, David A. Cooper wrote:


As the author of

http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf,
I would like to note that it was not the intention of this test suite to
imply that nextUpdate must be treated as an expiration date for a
CRL.  Version 1.0 of PKITS came out in September 2004, and the CRLs
for tests 4.4.11 and 4.4.12 had nextUpdate times of January 2002 and
January 1999, respectively.  An application could be configured to
allow for a CRL to be used after its nextUpdate time had passed, as long
as it verified that the nextUpdate time was not too far in the past, and
still get the correct results for the tests, and that was
intentional.


Section 4.4 of that document contains the introduction to the basic
certificate revocation tests and it says:






The application must be able to retrieve valid revocation data for
each certificate in the path. For a CRL to be considered to contain valid
revocation data for a certificate, the CRL must at a minimum: (1) be
signed by the issuer of the certificate or by an entity that has been
authorized by the certificate issuer to provide status information for
the certificate; (2) have a scope that includes the certificate of
interest; and (3) be sufficiently up-to-date.




In general, if the current time is before the time specified in the
nextUpdate field of a CRL, then that CRL should be considered
sufficiently up-to-date since the CRL issuer has indicated that this CRL
may contain the most up-to-date information available. Similarly, if the
current time is after the time specified in the nextUpdate field of a
CRL, then the CRL should not be considered to be sufficiently up-to-date
since the CRL issuer has indicated that more up-to-date information
should be available.





Even if the current time is after the time specified in the
nextUpdate field of a CRL, an application may still make a local
decision to treat the CRL as being sufficiently up-to-date. The



application may, for example, be configurable to allow CRLs to be
treated as sufficiently up-to-date, even if the current time is after the
nextUpdate time, if the CRL was issued recently (e.g., the user or
administrator configuring the system could indicate that a CRL may be
used as long as the current time is within 72 hours of the thisUpdate
time in the CRL, no matter how frequently the CRL issuer chooses to issue
CRLs).




In this section, there are only two tests in which the nextUpdate
time in a CRL is before the current time. In each case, the
nextUpdate time (and thisUpdate time) is more than two years
before the current time. So, it is expected that applications will be
configured so that these CRLs are not considered to be sufficiently
up-to-date.




Even if an application is unable to find valid revocation data (that
is considered to be sufficiently up-to-date) for every certificate in the
path, the application may still make a local decision to use the
certification path. The application may, for example, allow the user or
an administrator to configure the application to ignore the
unavailability of revocation data. In the case of an interactive
application, the application may display a warning to the user and then
allow the user to decide whether to proceed to use the certification path
despite the lack of revocation data. However, the application may not be
designed in such a way that the unavailability of revocation data is
always ignored, whether the user (or administrator) wants the application
to behave that way or not. When running the tests in this section, the
application should be configured in such a way that the certification
path is not accepted unless valid, up-to-date revocation data is
available for every certificate in the path. Thus, when run in this
configuration, when the application is unable to find valid, up-to-date
revocation data for every certificate in the path, the application must
either reject the certification path or at least display a warning to the
user indicating that the status of the certificate can not be
determined.







Dave


On 02/19/2011 09:42 PM, Michael StJohns wrote: 





*sigh*  =20


http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf

Items 4.4.11 and 4.4.12.

Somewhere the idea that "undetermined" equaled "not
validated" crept into the process rather than being treated as a per
acceptor policy decision.

Mike

At 03:56 PM 2/18/2011, Mike Helm wrote:
 






"Sill, Alan" writes:
   






 This is exactly what I tried to point out earlier. It is
surely up
to each relying party, but all production infrastructure
implementationd of which I am aware treat things this way: if a CRL
is not available after the time of the "next update" value of
the
most current one expires, then no certificates from that CA are
considered valid.=20
     




(One of )  the guilty party/ies here is openssl, so the problem
is both more widespread than the infrastructure we support,
and not completely that infrastructure's fault.  openssl has some
other crl quirks, at least some versions do.


The idea is very widespread, tho.  I think I remember it was
part of a security PKI checklist that NIST provided - I don't have
a copy of it any more & I don't know that it reached final
publication
in NIST.  However many PKI specialists also seem to believe this
is the correct behavior.  I suppose it could be considered
correct behavior in the right framing, I wish it wasn't,
but it seems we have to treat it so.

Thanks, =3D=3Dmwh
Michael Helm
ESnet/LBNL
   








--=====================_403922999==.ALT--


From david.cooper@nist.gov  Tue Feb 22 14:18:24 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB4113A6934 for ; Tue, 22 Feb 2011 14:18:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.505
X-Spam-Level: 
X-Spam-Status: No, score=-5.505 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aj5UzLnH0eGd for ; Tue, 22 Feb 2011 14:18:23 -0800 (PST)
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id 1C09B3A692C for ; Tue, 22 Feb 2011 14:18:22 -0800 (PST)
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p1MMJB73006864; Tue, 22 Feb 2011 17:19:11 -0500
Message-ID: <4D643650.20005@nist.gov>
Date: Tue, 22 Feb 2011 17:18:56 -0500
From: "David A. Cooper" 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20101222 Mandriva/3.0.11-0.1mdv2010.2 (2010.2) Thunderbird/3.0.11
MIME-Version: 1.0
To: Michael StJohns 
References:  <201102182056.p1IKu8jn025982@fionn.es.net> <20110220024150.027033A6CBA@core3.amsl.com> <4D63F4D8.7040903@nist.gov> <201102221903.p1MJ3cBL009517@spamav2.nist.gov>
In-Reply-To: <201102221903.p1MJ3cBL009517@spamav2.nist.gov>
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Cc: IETF PKIX 
Subject: Re: [pkix] nextUpdate as expiration date (was Re: What should be in "Next Update" field of the last CRL?)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Feb 2011 22:18:24 -0000




  


Mike,



I don't understand your point.  These tests don't involve CRLs with
nextUpdate times are a few hours or days in the past, they involve CRLs
with nextUpdate times that are several years in the past.  If "should
not validate successfully" is an acceptable outcome for tests such as
4.4.1and 4.4.4, where no valid CRL is available, then why isn't is also
an acceptable outcome for tests 4.4.11 and 4.4.12, where the only CRLs
that are available are so out-of-date?  If an application is configured
to reject a certification path when some revocation information is
missing, should it accept a certification path if some of the
revocation information is out-of-date by several years?  What's wrong
with implementing "should not validate successfully" for these tests?



Dave



On 02/22/2011 02:03 PM, Michael StJohns wrote:

Hi David -

  

Issue isn't 4.4, but 4.4.11 and 4.4.12 text which says:

  

  

    Expected Result: The
path
should not validate successfully since the status of the end

entity's certificate can not be determined.

  

without reference back to the text you cite.  

  

It's true that 4.4 has the "local decision to treat the CRL as being
sufficiently up-to-date", but the "should not validate
successfully" in the test text is going to be or was what gets/got
implemented.  Testable criteria always wins...

  

Mike

  

  

At 12:39 PM 2/22/2011, David A. Cooper wrote:

  
As the author of
    http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf,
I
would like to note that it was not the intention of this test suite to
imply that nextUpdate must be treated as an expiration date for a
CRL.  Version 1.0 of PKITS came out in September 2004, and the CRLs
for tests 4.4.11 and 4.4.12 had nextUpdate times of January 2002 and
January 1999, respectively.  An application could be configured to
allow for a CRL to be used after its nextUpdate time had passed, as
long
as it verified that the nextUpdate time was not too far in the past,
and
still get the correct results for the tests, and that was
intentional.

    

Section 4.4 of that document contains the introduction to the basic
certificate revocation tests and it says:

    

    

      
The application must be able to retrieve valid revocation
data for
each certificate in the path. For a CRL to be considered to contain
valid
revocation data for a certificate, the CRL must at a minimum: (1) be
signed by the issuer of the certificate or by an entity that has been
authorized by the certificate issuer to provide status information for
the certificate; (2) have a scope that includes the certificate of
interest; and (3) be sufficiently up-to-date.

        

      

      
In general, if the current time is before the time specified
in the
nextUpdate field of a CRL, then that CRL should be considered
sufficiently up-to-date since the CRL issuer has indicated that this
CRL
may contain the most up-to-date information available. Similarly, if
the
current time is after the time specified in the nextUpdate field of a
CRL, then the CRL should not be considered to be sufficiently
up-to-date
since the CRL issuer has indicated that more up-to-date information
should be available.

        

      

      
Even if the current time is after the time specified in the
nextUpdate field of a CRL, an application may still make a local
decision to treat the CRL as being sufficiently up-to-date. The

      

      
application may, for example, be configurable to allow CRLs
to be
treated as sufficiently up-to-date, even if the current time is after
the
nextUpdate time, if the CRL was issued recently (e.g., the user or
administrator configuring the system could indicate that a CRL may be
used as long as the current time is within 72 hours of the thisUpdate
time in the CRL, no matter how frequently the CRL issuer chooses to
issue
CRLs).

        

      

      
In this section, there are only two tests in which the
nextUpdate
time in a CRL is before the current time. In each case, the
nextUpdate time (and thisUpdate time) is more than two years
before the current time. So, it is expected that applications will be
configured so that these CRLs are not considered to be sufficiently
up-to-date.

        

      

      
Even if an application is unable to find valid revocation
data (that
is considered to be sufficiently up-to-date) for every certificate in
the
path, the application may still make a local decision to use the
certification path. The application may, for example, allow the user or
an administrator to configure the application to ignore the
unavailability of revocation data. In the case of an interactive
application, the application may display a warning to the user and then
allow the user to decide whether to proceed to use the certification
path
despite the lack of revocation data. However, the application may not
be
designed in such a way that the unavailability of revocation data is
always ignored, whether the user (or administrator) wants the
application
to behave that way or not. When running the tests in this section, the
application should be configured in such a way that the certification
path is not accepted unless valid, up-to-date revocation data is
available for every certificate in the path. Thus, when run in this
configuration, when the application is unable to find valid, up-to-date
revocation data for every certificate in the path, the application must
either reject the certification path or at least display a warning to
the
user indicating that the status of the certificate can not be
determined.

        

      

    

    

    

Dave

    

On 02/19/2011 09:42 PM, Michael StJohns wrote: 

    


      
*sigh*   


http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf

Items 4.4.11 and 4.4.12.

Somewhere the idea that "undetermined" equaled "not
validated" crept into the process rather than being treated as a per
acceptor policy decision.

Mike

At 03:56 PM 2/18/2011, Mike Helm wrote:
 
      

      


        
"Sill, Alan" writes:
   
        

        


          
 This is exactly what I tried to point out earlier. It is
surely up
to each relying party, but all production infrastructure
implementationd of which I am aware treat things this way: if a CRL
is not available after the time of the "next update" value of
the
most current one expires, then no certificates from that CA are
considered valid. 
     
          

        

        

        
(One of )  the guilty party/ies here is openssl, so the problem
is both more widespread than the infrastructure we support,
and not completely that infrastructure's fault.  openssl has some
other crl quirks, at least some versions do.


The idea is very widespread, tho.  I think I remember it was
part of a security PKI checklist that NIST provided - I don't have
a copy of it any more & I don't know that it reached final
publication
in NIST.  However many PKI specialists also seem to believe this
is the correct behavior.  I suppose it could be considered
correct behavior in the right framing, I wish it wasn't,
but it seems we have to treat it so.

Thanks, ==mwh
Michael Helm
ESnet/LBNL
        

      

    

  








From mstjohns@comcast.net  Tue Feb 22 19:24:34 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1373A6997 for ; Tue, 22 Feb 2011 19:24:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.726
X-Spam-Level: 
X-Spam-Status: No, score=-101.726 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEpD3gROFfZ7 for ; Tue, 22 Feb 2011 19:24:32 -0800 (PST)
Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 6A4F43A6801 for ; Tue, 22 Feb 2011 19:24:32 -0800 (PST)
Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta09.westchester.pa.mail.comcast.net with comcast id BFJP1g0020ldTLk59FRKAs; Wed, 23 Feb 2011 03:25:19 +0000
Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta04.westchester.pa.mail.comcast.net with comcast id BFRG1g00G1EtFYL3QFRGkm; Wed, 23 Feb 2011 03:25:18 +0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 22 Feb 2011 22:25:13 -0500
To: "David A. Cooper" 
From: Michael StJohns 
In-Reply-To: <4D643650.20005@nist.gov>
References:  <201102182056.p1IKu8jn025982@fionn.es.net> <20110220024150.027033A6CBA@core3.amsl.com> <4D63F4D8.7040903@nist.gov> <201102221903.p1MJ3cBL009517@spamav2.nist.gov> <4D643650.20005@nist.gov>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_434021800==.ALT"
Message-Id: <20110223032432.6A4F43A6801@core3.amsl.com>
Cc: IETF PKIX 
Subject: Re: [pkix] nextUpdate as expiration date (was Re: What should be in "Next Update" field of the last CRL?)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Feb 2011 03:24:34 -0000

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

At 05:18 PM 2/22/2011, David A. Cooper wrote:
>Mike,
>
>I don't understand your point.  These tests don't involve CRLs with=
 nextUpdate times are a few hours or days in the past, they involve CRLs=
 with nextUpdate times that are several years in the past.


This (how old is too old) isn't going to be all that visible from a testing=
 POV - all the tester knows is that the last known CRL is stale - later than=
 the nextUpdate time.  There's no discussion in 4.4.11 of how late is too=
 late (even though 4.4 notes the CRLs are at least 2 years out of date).  So=
 for 4.4.11 and 4.4.12 it doesn't matter whether the CRL is 1 day out of=
 currency or 10 years.  Indeed, the text of 4.4.11 simply says "CRL has a=
 nextUpdateTime that is in the past".  Also, as I read it, 4.4.12 was a "pre=
 2000" test - or more simply a Y2K completeness test.


>  If "should not validate successfully" is an acceptable outcome for tests=
 such as 4.4.1and 4.4.4, where no valid CRL is available, then why isn't is=
 also an acceptable outcome for tests 4.4.11 and 4.4.12, where the only CRLs=
 that are available are so out-of-date?=20

In neither case is this acceptable always.  In both it should be a matter of=
 configuration. E.g. a CA may choose not to issue a CRL *ever* making 4.4.1s=
 assumption that a missing CRL means the cert is invalid overreaching. =20


>Conforming CAs are not required to issue CRLs if other revocation or
>   certificate status mechanisms are provided.=20


> If an application is configured to reject a certification path when some=
 revocation information is missing, should it accept a certification path if=
 some of the revocation information is out-of-date by several years?  What's=
 wrong with implementing "should not validate successfully" for these tests?

Because that's not what 3280 or 5280 says (and they are both silent on that=
 as near as I can tell). It's also not PKITS.pdf seems to test.

See above. Each of these test cases should have noted that the testing was=
 against a specific assumption - that CRLs are mandatory and that if the CRL=
 is stale then all certificates are invalid - and should have noted that the=
 acceptor could configure an alternate acceptance model.  The fact these=
 cases were stated as an absolute probably led to various implementations=
 making similar absolute choices.

Mike



>Dave
>
>On 02/22/2011 02:03 PM, Michael StJohns wrote:=20
>>Hi David -
>>
>>Issue isn't 4.4, but 4.4.11 and 4.4.12 text which says:
>>
>>>Expected Result: The path should not validate successfully since the=
 status of the end
>>>entity's certificate can not be determined.
>>
>>without reference back to the text you cite. =20
>>
>>It's true that 4.4 has the "local decision to treat the CRL as being=
 sufficiently up-to-date", but the "should not validate successfully" in the=
 test text is going to be or was what gets/got implemented.  Testable=
 criteria always wins...
>>
>>Mike
>>
>>
>>At 12:39 PM 2/22/2011, David A. Cooper wrote:
>>>As the author of=
 http:=
//csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf, I would=
 like to note that it was not the intention of this test suite to imply that=
 nextUpdate must be treated as an expiration date for a CRL.  Version 1.0 of=
 PKITS came out in September 2004, and the CRLs for tests 4.4.11 and 4.4.12=
 had nextUpdate times of January 2002 and January 1999, respectively.  An=
 application could be configured to allow for a CRL to be used after its=
 nextUpdate time had passed, as long as it verified that the nextUpdate time=
 was not too far in the past, and still get the correct results for the=
 tests, and that was intentional.
>>>
>>>Section 4.4 of that document contains the introduction to the basic=
 certificate revocation tests and it says:
>>>
>>>The application must be able to retrieve valid revocation data for each=
 certificate in the path. For a CRL to be considered to contain valid=
 revocation data for a certificate, the CRL must at a minimum: (1) be signed=
 by the issuer of the certificate or by an entity that has been authorized=
 by the certificate issuer to provide status information for the=
 certificate; (2) have a scope that includes the certificate of interest;=
 and (3) be sufficiently up-to-date.
>>>In general, if the current time is before the time specified in the=
 nextUpdate field of a CRL, then that CRL should be considered sufficiently=
 up-to-date since the CRL issuer has indicated that this CRL may contain the=
 most up-to-date information available. Similarly, if the current time is=
 after the time specified in the nextUpdate field of a CRL, then the CRL=
 should not be considered to be sufficiently up-to-date since the CRL issuer=
 has indicated that more up-to-date information should be available.
>>>
>>>Even if the current time is after the time specified in the nextUpdate=
 field of a CRL, an application may still make a local decision to treat the=
 CRL as being sufficiently up-to-date. The=20
>>>application may, for example, be configurable to allow CRLs to be treated=
 as sufficiently up-to-date, even if the current time is after the=
 nextUpdate time, if the CRL was issued recently (e.g., the user or=
 administrator configuring the system could indicate that a CRL may be used=
 as long as the current time is within 72 hours of the thisUpdate time in=
 the CRL, no matter how frequently the CRL issuer chooses to issue CRLs).
>>>In this section, there are only two tests in which the nextUpdate time in=
 a CRL is before the current time. In each case, the nextUpdate time (and=
 thisUpdate time) is more than two years before the current time. So, it is=
 expected that applications will be configured so that these CRLs are not=
 considered to be sufficiently up-to-date.
>>>Even if an application is unable to find valid revocation data (that is=
 considered to be sufficiently up-to-date) for every certificate in the=
 path, the application may still make a local decision to use the=
 certification path. The application may, for example, allow the user or an=
 administrator to configure the application to ignore the unavailability of=
 revocation data. In the case of an interactive application, the application=
 may display a warning to the user and then allow the user to decide whether=
 to proceed to use the certification path despite the lack of revocation=
 data. However, the application may not be designed in such a way that the=
 unavailability of revocation data is always ignored, whether the user (or=
 administrator) wants the application to behave that way or not. When=
 running the tests in this section, the application should be configured in=
 such a way that the certification path is not accepted unless valid,=
 up-to-date revocation data is available for every certificate in the path.=
 Thus, when run in this configuration, when the application is unable to=
 find valid, up-to-date revocation data for every certificate in the path,=
 the application must either reject the certification path or at least=
 display a warning to the user indicating that the status of the certificate=
 can not be determined.
>>>
>>>
>>>
>>>Dave
>>>
>>>On 02/19/2011 09:42 PM, Michael StJohns wrote:=20
>>>>
>>>>
>>>>*sigh*  =20
>>>>
>>>>
>>>>http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf
>>>>
>>>>Items 4.4.11 and 4.4.12.
>>>>
>>>>Somewhere the idea that "undetermined" equaled "not
>>>>validated" crept into the process rather than being treated as a per
>>>>acceptor policy decision.
>>>>
>>>>Mike
>>>>
>>>>At 03:56 PM 2/18/2011, Mike Helm wrote:
>>>>=20
>>>>     =20
>>>>>
>>>>>
>>>>>"Sill, Alan" writes:
>>>>>  =20
>>>>>       =20
>>>>>>
>>>>>>
>>>>>> This is exactly what I tried to point out earlier. It is
>>>>>>surely up
>>>>>>to each relying party, but all production infrastructure
>>>>>>implementationd of which I am aware treat things this way: if a CRL
>>>>>>is not available after the time of the "next update" value of
>>>>>>the
>>>>>>most current one expires, then no certificates from that CA are
>>>>>>considered valid.=20
>>>>>>    =20
>>>>>>         =20
>>>>>
>>>>>
>>>>>(One of )  the guilty party/ies here is openssl, so the problem
>>>>>is both more widespread than the infrastructure we support,
>>>>>and not completely that infrastructure's fault.  openssl has some
>>>>>other crl quirks, at least some versions do.
>>>>>
>>>>>
>>>>>The idea is very widespread, tho.  I think I remember it was
>>>>>part of a security PKI checklist that NIST provided - I don't have
>>>>>a copy of it any more & I don't know that it reached final
>>>>>publication
>>>>>in NIST.  However many PKI specialists also seem to believe this
>>>>>is the correct behavior.  I suppose it could be considered
>>>>>correct behavior in the right framing, I wish it wasn't,
>>>>>but it seems we have to treat it so.
>>>>>
>>>>>Thanks, =3D=3Dmwh
>>>>>Michael Helm
>>>>>ESnet/LBNL
>>>>>       =20


--=====================_434021800==.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



At 05:18 PM 2/22/2011, David A. Cooper wrote:


Mike,



I don't understand your point.  These tests don't involve CRLs with
nextUpdate times are a few hours or days in the past, they involve CRLs
with nextUpdate times that are several years in the
past.



This (how old is too old) isn't going to be all that visible from a
testing POV - all the tester knows is that the last known CRL is stale -
later than the nextUpdate time.  There's no discussion in 4.4.11 of
how late is too late (even though 4.4 notes the CRLs are at least 2 years
out of date).  So for 4.4.11 and 4.4.12 it doesn't matter whether
the CRL is 1 day out of currency or 10 years.  Indeed, the text of
4.4.11 simply says "CRL has a nextUpdateTime that is in the
past".  Also, as I read it, 4.4.12 was a "pre 2000"
test - or more simply a Y2K completeness test.





  If "should not
validate successfully" is an acceptable outcome for tests such as
4.4.1and 4.4.4, where no valid CRL is available, then why isn't is also
an acceptable outcome for tests 4.4.11 and 4.4.12, where the only CRLs
that are available are so out-of-date? 


In neither case is this acceptable always.  In both it should be a
matter of configuration. E.g. a CA may choose not to issue a CRL *ever*
making 4.4.1s assumption that a missing CRL means the cert is invalid
overreaching.  





Conforming CAs are not
required to issue CRLs if other revocation or
   certificate status mechanisms are provided.





 If an application is
configured to reject a certification path when some revocation
information is missing, should it accept a certification path if some of
the revocation information is out-of-date by several years?  What's
wrong with implementing "should not validate successfully" for
these tests?


Because that's not what 3280 or 5280 says (and they are both silent on
that as near as I can tell). It's also not PKITS.pdf seems to
test.


See above. Each of these test cases should have noted that the testing
was against a specific assumption - that CRLs are mandatory and that if
the CRL is stale then all certificates are invalid - and should have
noted that the acceptor could configure an alternate acceptance
model.  The fact these cases were stated as an absolute probably led
to various implementations making similar absolute choices.


Mike






Dave


On 02/22/2011 02:03 PM, Michael StJohns wrote: 


Hi David -


Issue isn't 4.4, but 4.4.11 and 4.4.12 text which says:




Expected Result: The path
should not validate successfully since the status of the end

entity's certificate can not be determined.


without reference back to the text you cite.  


It's true that 4.4 has the "local decision to treat the CRL as being
sufficiently up-to-date", but the "should not validate
successfully" in the test text is going to be or was what gets/got
implemented.  Testable criteria always wins...


Mike




At 12:39 PM 2/22/2011, David A. Cooper wrote:


As the author of

http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf,
I would like to note that it was not the intention of this test suite to
imply that nextUpdate must be treated as an expiration date for a
CRL.  Version 1.0 of PKITS came out in September 2004, and the CRLs
for tests 4.4.11 and 4.4.12 had nextUpdate times of January 2002 and
January 1999, respectively.  An application could be configured to
allow for a CRL to be used after its nextUpdate time had passed, as long
as it verified that the nextUpdate time was not too far in the past, and
still get the correct results for the tests, and that was
intentional.


Section 4.4 of that document contains the introduction to the basic
certificate revocation tests and it says:





The application must be able to retrieve valid revocation data for
each certificate in the path. For a CRL to be considered to contain valid
revocation data for a certificate, the CRL must at a minimum: (1) be
signed by the issuer of the certificate or by an entity that has been
authorized by the certificate issuer to provide status information for
the certificate; (2) have a scope that includes the certificate of
interest; and (3) be sufficiently up-to-date.



In general, if the current time is before the time specified in the
nextUpdate field of a CRL, then that CRL should be considered
sufficiently up-to-date since the CRL issuer has indicated that this CRL
may contain the most up-to-date information available. Similarly, if the
current time is after the time specified in the nextUpdate field of a
CRL, then the CRL should not be considered to be sufficiently up-to-date
since the CRL issuer has indicated that more up-to-date information
should be available.




Even if the current time is after the time specified in the
nextUpdate field of a CRL, an application may still make a local decision
to treat the CRL as being sufficiently up-to-date. The

application may, for example, be configurable to allow CRLs to be
treated as sufficiently up-to-date, even if the current time is after the
nextUpdate time, if the CRL was issued recently (e.g., the user or
administrator configuring the system could indicate that a CRL may be
used as long as the current time is within 72 hours of the thisUpdate
time in the CRL, no matter how frequently the CRL issuer chooses to issue
CRLs).



In this section, there are only two tests in which the nextUpdate
time in a CRL is before the current time. In each case, the nextUpdate
time (and thisUpdate time) is more than two years before the current
time. So, it is expected that applications will be configured so that
these CRLs are not considered to be sufficiently up-to-date.



Even if an application is unable to find valid revocation data (that
is considered to be sufficiently up-to-date) for every certificate in the
path, the application may still make a local decision to use the
certification path. The application may, for example, allow the user or
an administrator to configure the application to ignore the
unavailability of revocation data. In the case of an interactive
application, the application may display a warning to the user and then
allow the user to decide whether to proceed to use the certification path
despite the lack of revocation data. However, the application may not be
designed in such a way that the unavailability of revocation data is
always ignored, whether the user (or administrator) wants the application
to behave that way or not. When running the tests in this section, the
application should be configured in such a way that the certification
path is not accepted unless valid, up-to-date revocation data is
available for every certificate in the path. Thus, when run in this
configuration, when the application is unable to find valid, up-to-date
revocation data for every certificate in the path, the application must
either reject the certification path or at least display a warning to the
user indicating that the status of the certificate can not be
determined.






Dave


On 02/19/2011 09:42 PM, Michael StJohns wrote: 






*sigh*  =20



http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/PKITS.pdf

Items 4.4.11 and 4.4.12.

Somewhere the idea that "undetermined" equaled "not
validated" crept into the process rather than being treated as a
per
acceptor policy decision.

Mike

At 03:56 PM 2/18/2011, Mike Helm wrote:
 
     







"Sill, Alan" writes:
  =20
       







 This is exactly what I tried to point out earlier. It is
surely up
to each relying party, but all production infrastructure
implementationd of which I am aware treat things this way: if a CRL
is not available after the time of the "next update" value of
the
most current one expires, then no certificates from that CA are
considered valid.=20
    =20
         





(One of )  the guilty party/ies here is openssl, so the
problem
is both more widespread than the infrastructure we support,
and not completely that infrastructure's fault.  openssl has some
other crl quirks, at least some versions do.


The idea is very widespread, tho.  I think I remember it was
part of a security PKI checklist that NIST provided - I don't have
a copy of it any more & I don't know that it reached final
publication
in NIST.  However many PKI specialists also seem to believe this
is the correct behavior.  I suppose it could be considered
correct behavior in the right framing, I wish it wasn't,
but it seems we have to treat it so.

Thanks, =3D=3Dmwh
Michael Helm
ESnet/LBNL
       








--=====================_434021800==.ALT--


From kent@bbn.com  Tue Feb 22 20:26:11 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38B5A3A69B6 for ; Tue, 22 Feb 2011 20:26:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.543
X-Spam-Level: 
X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHAGmfAuRXXO for ; Tue, 22 Feb 2011 20:26:10 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 53E7A3A69A1 for ; Tue, 22 Feb 2011 20:26:10 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15]:52538 helo=[169.223.148.236]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Ps6JR-000DcY-Kh; Tue, 22 Feb 2011 23:26:54 -0500
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: 
Date: Tue, 22 Feb 2011 23:26:48 -0500
To: Stefan Santesson 
From: Stephen Kent 
Content-Type: multipart/alternative; boundary="============_-913687283==_ma============"
Cc: IETF PKIX , "Kemp, David P." 
Subject: Re: [pkix] What should be in "Next Update" field of the last  CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Feb 2011 04:26:11 -0000

--============_-913687283==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 4:29 PM +0100 2/22/11, Stefan Santesson wrote:
>In reality this is even worse.
>
>There are clearly real situations where the RP need to have both an expiry
>date (Don't use this CRL after..) and a date when the next update is
>available.

yes, that would be nice, but I do not recall anyone proposing an extension
to carry the first data (with a nicer name :-)).

>
>Since most applications treat nextUpdate as the expiry date, and in order
>to stay compliant with these implementations, Microsoft defined the
>private extension "nextIssue", expressing the expected date when a new CRL
>should be available.

This is an unfortunate name, as the next update value is the next 
issue date :-). I appreciate the motivation, but ...

The next update value is like a "best is used before" date, analogous 
to what one sees on perishable products. You don't HAVE to consume 
the product before that date, but you may get a stomach ache if you 
consume it too long afterwards :-).

Steve

--============_-913687283==_ma============
Content-Type: text/html; charset="us-ascii"


Re: [pkix] What should be in "Next Update"
field of the la

At 4:29 PM +0100 2/22/11, Stefan Santesson wrote:


In reality this is even worse.



There are clearly real situations where the RP need to have both an
expiry

date (Don't use this CRL after..) and a date when the next update
is

available.





yes, that would be nice, but I do not recall anyone proposing an
extension


to carry the first data (with a nicer name :-)).







Since most applications treat nextUpdate as the expiry date, and in
order

to stay compliant with these implementations, Microsoft defined
the

private extension "nextIssue", expressing the expected date
when a new CRL


should be available.





This is an unfortunate name, as the next update value is
the next issue date :-). I appreciate the motivation, but ...





The next update value is like a "best is used before"
date, analogous to what one sees on perishable products. You don't
HAVE to consume the product before that date, but you may get a
stomach ache if you consume it too long afterwards :-).





Steve






--============_-913687283==_ma============--

From stefan@aaa-sec.com  Tue Feb 22 23:05:08 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 442923A6997 for ; Tue, 22 Feb 2011 23:05:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.401
X-Spam-Level: 
X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2iKnmiAczMv for ; Tue, 22 Feb 2011 23:05:06 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by core3.amsl.com (Postfix) with ESMTP id F19A13A6862 for ; Tue, 22 Feb 2011 23:05:05 -0800 (PST)
Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 3849C28BAB5 for ; Wed, 23 Feb 2011 08:05:52 +0100 (CET)
Received: (qmail 27033 invoked from network); 23 Feb 2011 07:05:50 -0000
Received: from resid-tg104.upc.es (HELO [147.83.129.204]) (stefan@fiddler.nu@[147.83.129.204]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 23 Feb 2011 07:05:50 -0000
User-Agent: Microsoft-MacOutlook/14.2.0.101115
Date: Wed, 23 Feb 2011 08:05:46 +0100
From: Stefan Santesson 
To: Stephen Kent 
Message-ID: 
Thread-Topic: [pkix] What should be in "Next Update" field of the last  CRL?
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3381293150_10364548"
Cc: IETF PKIX , "Kemp, David P." 
Subject: Re: [pkix] What should be in "Next Update" field of the last  CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Feb 2011 07:05:08 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3381293150_10364548
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit



From:  Stephen Kent 
Date:  Tue, 22 Feb 2011 23:26:48 -0500
To:  Stefan Santesson 
Cc:  "Kemp, David P." , "Sill, Alan"
, Michael StJohns , IETF PKIX

Subject:  Re: [pkix] What should be in "Next Update" field of the last  CRL?
> 
> This is an unfortunate name, as the next update value is the next issue date
> :-). I appreciate the motivation, but ...
> 
> The next update value is like a "best is used before" date, analogous to what
> one sees on perishable products. You don't HAVE to consume the product before
> that date, but you may get a stomach ache if you consume it too long
> afterwards :-).

Yes, that all sound logical. However on a practical ground that is quite
hard to code into a crypto API. There you need more distinct rules and
predictable outcome. It would of course have been more clean if they defined
a private "notValidAfter" extension, but that would not have produced the
outcome they needed.

To standardize on such extension may however be the least evil thing to do.

/Stefan



--B_3381293150_10364548
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable




From:  Stephen Kent <kent@bbn.com>
Date:  Tue, 22 Feb 2011 23:26:48 -0500
To:  Stefan Santesson <stefan@aaa-sec=
.com>
Cc:  "Kemp, David P." =
<DPKemp@missi.ncsc.mil>, "S=
ill, Alan" <alan.sill@ttu.edu>,=
 Michael StJohns <mstjohns@comcast.=
net>, IETF PKIX <pkix@ietf.org&=
gt;
Subject:  Re: [pkix] What shoul=
d be in "Next Update" field of the last  CRL?

This is an unfortuna=
te name, as the next update value is
the next issue date :-). I appreciate the motivation, but ...
The next update value is like a "best is used before"
date, analogous to what one sees on perishable products. You don't
HAVE to consume the product before that date, but you may get a
stomach ache if you consume it too long afterwards :-).

Yes, that all sound logical. However o=
n a practical ground that is quite hard to code into a crypto API. There you=
 need more distinct rules and predictable outcome. It would of course have b=
een more clean if they defined a private "notValidAfter" extension, but that=
 would not have produced the outcome they needed.

T=
o standardize on such extension may however be the least evil thing to do.

/Stefan


--B_3381293150_10364548--



From pornin@bolet.org  Wed Feb 23 06:03:48 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 168F93A68D5 for ; Wed, 23 Feb 2011 06:03:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dMOkR0jjcbK for ; Wed, 23 Feb 2011 06:03:47 -0800 (PST)
Received: from arges.bolet.org (arges.bolet.org [88.191.65.205]) by core3.amsl.com (Postfix) with ESMTP id A70123A68AB for ; Wed, 23 Feb 2011 06:03:46 -0800 (PST)
Received: from [10.0.1.101] (modemcable051.204-200-24.mc.videotron.ca [24.200.204.51]) by arges.bolet.org (Postfix) with ESMTPSA id 04F1F68C04F; Wed, 23 Feb 2011 15:04:28 +0100 (CET)
From: Thomas Pornin 
To: IETF PKIX 
In-Reply-To: 
References: 
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 23 Feb 2011 09:04:23 -0500
Message-ID: <1298469863.2360.68.camel@nostromo>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Content-Transfer-Encoding: 7bit
Cc: Stefan Santesson 
Subject: Re: [pkix] What should be in "Next Update" field of the last  CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Feb 2011 14:03:48 -0000

On Wed, 2011-02-23 at 08:05 +0100, Stefan Santesson wrote:
> Yes, that all sound logical. However on a practical ground that is
> quite hard to code into a crypto API. There you need more distinct
> rules and predictable outcome.

I second that. Theoretically, each RP would decide, according to its own
arbitrary policy, whether a given CRL is fresh enough. But the rules for
appropriate freshness depend upon the context and are likely to be
CA-specific. Revocation is mostly a kind of damage containment: a way to
"cancel" an existing certificate, even though the signature on the
certificate is cryptographically verifiable, in order to cope with an
unfortunate occurrence, e.g. a key compromise. The revocation
information freshness is a measure of the time-wise extent of the issue:
by accepting a week-old CRL, the RP effectively accepts the risk that it
could be fooled into using a public key which has been compromised
during the last week.

How much freshness is needed ? It really depends on the procedures
deployed by the CA to detect the revocation-implying occurrences, and
how fast it can publish revocation information. Those procedures are
normally described in the Certification Policy Statement of the CA, and
supposedly are compatible with the CPS of the CA's CA, and so on.
Ultimately, this leads to the trust anchor's CPS; however, the TA CPS is
not necessarily precise about applicable freshness for all CA which it
has directly or indirectly issued.

One point of PKI (maybe _the_ point of PKI) is to be able to validate
links between public keys and identities, for an arbitrary large set of
identities and public keys, using a small, fixed set of a priori known
information (the trust anchors). We want to be able to validate
certificates issued by intermediate CA about which we had no prior
knowledge. We cannot have CA-specific knowledge for all possible CA.
Hence, the policy which a RP will use to decide CRL freshness must feed
on whatever CA-specific information it can get hold of, and the only
validated sources it can get, in all generality, are the CA certificate
and the CRL itself (and the CRL issuer certificate, if distinct from the
CA). Whatever CPS say in human language, the validation process is,
ultimately, executed by a computer, which needs Turing-compatible rules.

Using the nextUpdate field as an end-of-validity date is not incorrect.
This is certainly allowed by RFC 5280; if the freshness-decision is a
matter of local policy, that local policy can certainly be: "use
nextUpdate as an end-of-validity date". RFC 5280 even hints at that
usage, in the 6.3.3 section ("CRL Processing"): it is said that the
"local CRL cache" should be updated with a "current CRL" if the
nextUpdate field of the most recent CRL is in the past (RFC 5280 does
not tell what should be done if such an update fails). Moreover, using
the nextUpdate as end-of-validity is not a bad policy, as policies go:
basically, it is the policy known as: "issuing CA knows best". Since
appropriate freshness is CA-specific, it makes sense to follow the rules
used by the CA. Ideally, the CA would publish the CRL end-of-validity
date, which should be at some date after the nextUpdate (there should be
no date without a valid CRL at all): the nextUpdate is a lower bound for
the CRL end-of-validity. If more extensive information is not available,
then the best that can be done is to use the nextUpdate as an
approximation of the end-of-validity.

The point, here, is that whatever entity implements the certificate
validation process needs information, which must be:
  1. processable by a computer;
  2. CA-specific, for CA which the RP might not have been aware of
beforehand.
As I see it, given the current state of standard certificate and CRL
extensions, the nextUpdate field is the only information source that can
be used for that. This does not prevent other freshness policies from
being also correct in the RFC 5280 sense, and possibly appropriate
(although the widespread policy known as "meh, no need to check, it is
probably not revoked anyway" kind of stretches my notion of "appropriate
freshness check"). But the "nextUpdate as end-of-validity" policy is a
good policy, or, at least, as good as a generic policy can get in that
matter.


> To standardize on such extension may however be the least evil thing
> to do.

As I explain above, such an extension is a way for the CA to make a
statement about what freshness measure is appropriate for the procedures
that it applies to decide about the revocation status. It is a good
thing (as long as the CA does not botch it by publishing an
end-of-validity date which is _before_ the nextUpdate).

"Standardize" is an important word. In many usages of validation, we not
only want to have a validation process which yields a trustworthy
answer; we also want it to yield the same trustworthy answer than for
other people. For instance, in the context of a signed contract, I want
my system to accept the contract as signed only if a judge, applying
validation on the same signature, would also declare it as valid and
binding. Right now, this entails using nextUpdate as an end-of-validity
date because, whether you like it or not, that's what everybody does.


	--Thomas Pornin




From housley@vigilsec.com  Wed Feb 23 06:36:40 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AED33A68E0 for ; Wed, 23 Feb 2011 06:36:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level: 
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMVfHGoZiAUV for ; Wed, 23 Feb 2011 06:36:39 -0800 (PST)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id B02283A6859 for ; Wed, 23 Feb 2011 06:36:39 -0800 (PST)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id E3A539A4739 for ; Wed, 23 Feb 2011 09:37:40 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id lhIO1icHu9f0 for ; Wed, 23 Feb 2011 09:37:07 -0500 (EST)
Received: from [192.168.2.105] (pool-71-178-218-117.washdc.fios.verizon.net [71.178.218.117]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 5A4789A4725 for ; Wed, 23 Feb 2011 09:37:40 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: Russ Housley 
In-Reply-To: 
Date: Wed, 23 Feb 2011 09:37:25 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com>
References:  
To: IETF PKIX 
X-Mailer: Apple Mail (2.1082)
Subject: Re: [pkix] What should be in "Next Update" field of the last  CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Feb 2011 14:36:40 -0000

>> There are clearly real situations where the RP need to have both an =
expiry
>> date (Don't use this CRL after..) and a date when the next update is
>> available.
>=20
> yes, that would be nice, but I do not recall anyone proposing an =
extension
> to carry the first data (with a nicer name :-)).
>=20
>>=20
>> Since most applications treat nextUpdate as the expiry date, and in =
order
>> to stay compliant with these implementations, Microsoft defined the
>> private extension "nextIssue", expressing the expected date when a =
new CRL
>> should be available.
>=20
> This is an unfortunate name, as the next update value is the next =
issue date :-). I appreciate the motivation, but ...
>=20
> The next update value is like a "best is used before" date, analogous =
to what one sees on perishable products. You don't HAVE to consume the =
product before that date, but you may get a stomach ache if you consume =
it too long afterwards :-).

I am aware of applications that expect the new CRL to be posted by the =
nextUpdate, but allow a grace time for it to published and distributed.  =
This seems like a reasonable approach since there are not separate next =
publication and expiration times.

Russ


From roberto@opazo.cl  Wed Feb 23 11:34:34 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61B633A67F9 for ; Wed, 23 Feb 2011 11:34:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjpAhl4ZerkL for ; Wed, 23 Feb 2011 11:34:32 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 73EDF3A6940 for ; Wed, 23 Feb 2011 11:34:16 -0800 (PST)
Received: by eye13 with SMTP id 13so1275396eye.31 for ; Wed, 23 Feb 2011 11:34:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.14.11.154 with SMTP id 26mr4577000eex.0.1298489693902; Wed, 23 Feb 2011 11:34:53 -0800 (PST)
Received: by 10.14.121.212 with HTTP; Wed, 23 Feb 2011 11:34:52 -0800 (PST)
In-Reply-To: <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com>
References:   <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com>
Date: Wed, 23 Feb 2011 16:34:52 -0300
Message-ID: 
From: Roberto Opazo 
To: IETF PKIX 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Feb 2011 19:34:34 -0000

I think this thread is mixing two different point:

* How should a RP interpret Next Update field in a CRL? Is it an
expiration date?

* What should be en Next Update field in the last CRL? This scenario
is different than the previous one because there is not going to be
any next CRL in any time. There are many choices here and I really
think that's a problem. If there would not be so many applications
already in the market I would recommend a NULL value. But
unfortunately, I think making a choice is hurter than that. No choice
is going to be perfect, but there should be only one way to fill Next
Update field of the last CRL.

Best regards,

Roberto Opazo


2011/2/23 Russ Housley :
>
>>> There are clearly real situations where the RP need to have both an exp=
iry
>>> date (Don't use this CRL after..) and a date when the next update is
>>> available.
>>
>> yes, that would be nice, but I do not recall anyone proposing an extensi=
on
>> to carry the first data (with a nicer name :-)).
>>
>>>
>>> Since most applications treat nextUpdate as the expiry date, and in ord=
er
>>> to stay compliant with these implementations, Microsoft defined the
>>> private extension "nextIssue", expressing the expected date when a new =
CRL
>>> should be available.
>>
>> This is an unfortunate name, as the next update value is the next issue =
date :-). I appreciate the motivation, but ...
>>
>> The next update value is like a "best is used before" date, analogous to=
 what one sees on perishable products. You don't HAVE to consume the produc=
t before that date, but you may get a stomach ache if you consume it too lo=
ng afterwards :-).
>
> I am aware of applications that expect the new CRL to be posted by the ne=
xtUpdate, but allow a grace time for it to published and distributed. =A0Th=
is seems like a reasonable approach since there are not separate next publi=
cation and expiration times.
>
> Russ
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>



--=20
Saludos,

Roberto Opazo

From DPKemp@missi.ncsc.mil  Wed Feb 23 14:26:35 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49E523A692D for ; Wed, 23 Feb 2011 14:26:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxmOSQ7-3bYv for ; Wed, 23 Feb 2011 14:26:34 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id 3CBD33A68EE for ; Wed, 23 Feb 2011 14:26:34 -0800 (PST)
Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p1NMRLQt003854; Wed, 23 Feb 2011 17:27:21 -0500 (EST)
Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 23 Feb 2011 17:26:43 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Wed, 23 Feb 2011 17:22:23 -0500
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [pkix] What should be in "Next Update" field of the last CRL?
Thread-Index: AcvTliOoRguFE/gmRHa3MG31mTuagAADVV4w
References: <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com> 
From: "Kemp, David P." 
To: "Roberto Opazo" , "IETF PKIX" 
X-OriginalArrivalTime: 23 Feb 2011 22:26:43.0390 (UTC) FILETIME=[BFAC55E0:01CBD3A8]
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Feb 2011 22:26:35 -0000

"If a tree falls in an empty forest, does it make a sound"?

If there are no valid certificates (because either or both of the CA =
certificate and the EE certificate have expired), does it matter what =
goes into nextUpdate of the last CRL issued by the CA?  There are indeed =
many choices, but all of them yield the identical result - an expired =
certificate is not valid.  For that reason the simplest choice (filling =
nextUpdate with the same value it would have had if the CA were not =
expiring) seems best.

Because no choice has any effect (other than perhaps confusing apps with =
unexpected magic values), I don't agree that the standard needs to =
specify only one.  40 years ago when electrical engineers (the original =
EEs) were doing Karnaugh maps, we would have called nextUpdate an "X" =
(don't care) input.
=09


-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of =
Roberto Opazo
Sent: Wednesday, February 23, 2011 2:35 PM
To: IETF PKIX
Subject: Re: [pkix] What should be in "Next Update" field of the last =
CRL?

I think this thread is mixing two different point:

* How should a RP interpret Next Update field in a CRL? Is it an
expiration date?

* What should be en Next Update field in the last CRL? This scenario
is different than the previous one because there is not going to be
any next CRL in any time. There are many choices here and I really
think that's a problem. If there would not be so many applications
already in the market I would recommend a NULL value. But
unfortunately, I think making a choice is hurter than that. No choice
is going to be perfect, but there should be only one way to fill Next
Update field of the last CRL.

Best regards,

Roberto Opazo


2011/2/23 Russ Housley :
>
>>> There are clearly real situations where the RP need to have both an =
expiry
>>> date (Don't use this CRL after..) and a date when the next update is
>>> available.
>>
>> yes, that would be nice, but I do not recall anyone proposing an =
extension
>> to carry the first data (with a nicer name :-)).
>>
>>>
>>> Since most applications treat nextUpdate as the expiry date, and in =
order
>>> to stay compliant with these implementations, Microsoft defined the
>>> private extension "nextIssue", expressing the expected date when a =
new CRL
>>> should be available.
>>
>> This is an unfortunate name, as the next update value is the next =
issue date :-). I appreciate the motivation, but ...
>>
>> The next update value is like a "best is used before" date, analogous =
to what one sees on perishable products. You don't HAVE to consume the =
product before that date, but you may get a stomach ache if you consume =
it too long afterwards :-).
>
> I am aware of applications that expect the new CRL to be posted by the =
nextUpdate, but allow a grace time for it to published and distributed. =
=A0This seems like a reasonable approach since there are not separate =
next publication and expiration times.
>
> Russ
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>



--=20
Saludos,

Roberto Opazo
_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

From pornin@bolet.org  Wed Feb 23 14:37:30 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40A93A692D for ; Wed, 23 Feb 2011 14:37:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eun6okzg0fx0 for ; Wed, 23 Feb 2011 14:37:29 -0800 (PST)
Received: from arges.bolet.org (arges.bolet.org [88.191.65.205]) by core3.amsl.com (Postfix) with ESMTP id C75193A68FD for ; Wed, 23 Feb 2011 14:37:29 -0800 (PST)
Received: from [10.0.1.101] (modemcable051.204-200-24.mc.videotron.ca [24.200.204.51]) by arges.bolet.org (Postfix) with ESMTPSA id C2C2A68C04F; Wed, 23 Feb 2011 23:38:15 +0100 (CET)
From: Thomas Pornin 
To: IETF PKIX 
In-Reply-To: 
References:   <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com>  
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 23 Feb 2011 17:38:11 -0500
Message-ID: <1298500691.3187.3.camel@nostromo>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Content-Transfer-Encoding: 7bit
Cc: "Kemp, David P." 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Feb 2011 22:37:30 -0000

On Wed, 2011-02-23 at 17:22 -0500, Kemp, David P. wrote:
> For that reason the simplest choice (filling nextUpdate with the same value it would have had if the CA were not expiring) seems best.

Also, using the same nextUpdate rules helps quite a lot if, one or two
days after having issued the "last" CRL, someone decides that the CA
should not be closed after all, and reissues the certificate using the
same name and public key, and new validity dates. The simplest choice is
also the choice which entails the lowest risk.


	--Thomas Pornin



From hotz@jpl.nasa.gov  Wed Feb 23 16:26:23 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF0503A6933 for ; Wed, 23 Feb 2011 16:26:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvPuAaq+7c+B for ; Wed, 23 Feb 2011 16:26:22 -0800 (PST)
Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) by core3.amsl.com (Postfix) with ESMTP id 34D733A6403 for ; Wed, 23 Feb 2011 16:26:20 -0800 (PST)
Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1O0R7sZ020932 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 23 Feb 2011 16:27:07 -0800
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Henry B. Hotz" 
In-Reply-To: 
Date: Wed, 23 Feb 2011 16:27:06 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com>  
To: "Kemp, David P." 
X-Mailer: Apple Mail (2.1082)
X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44]
X-Source-Sender: hotz@jpl.nasa.gov
X-AUTH: Authorized
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Feb 2011 00:26:23 -0000

There's the digital signature use case.  You want to know that the EE =
and CA(s) were valid at the time the document was signed, and you want =
to know that nobody has subsequently compromised them either.

On Feb 23, 2011, at 2:22 PM, Kemp, David P. wrote:

> "If a tree falls in an empty forest, does it make a sound"?
>=20
> If there are no valid certificates (because either or both of the CA =
certificate and the EE certificate have expired), does it matter what =
goes into nextUpdate of the last CRL issued by the CA?  There are indeed =
many choices, but all of them yield the identical result - an expired =
certificate is not valid.  For that reason the simplest choice (filling =
nextUpdate with the same value it would have had if the CA were not =
expiring) seems best.
>=20
> Because no choice has any effect (other than perhaps confusing apps =
with unexpected magic values), I don't agree that the standard needs to =
specify only one.  40 years ago when electrical engineers (the original =
EEs) were doing Karnaugh maps, we would have called nextUpdate an "X" =
(don't care) input.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu




From paul.hoffman@vpnc.org  Wed Feb 23 16:30:44 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84BFF3A659A for ; Wed, 23 Feb 2011 16:30:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.447
X-Spam-Level: 
X-Spam-Status: No, score=-101.447 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYTtTnpEQuut for ; Wed, 23 Feb 2011 16:30:43 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id CE39B3A6975 for ; Wed, 23 Feb 2011 16:30:43 -0800 (PST)
Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1O0VV5P031266 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 23 Feb 2011 17:31:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Message-ID: <4D65A6E3.3090302@vpnc.org>
Date: Wed, 23 Feb 2011 16:31:31 -0800
From: Paul Hoffman 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: pkix@ietf.org
References: <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com>		 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Feb 2011 00:30:44 -0000

On 2/23/11 4:27 PM, Henry B. Hotz wrote:
> There's the digital signature use case.  You want to know that the EE and CA(s) were valid at the time the document was signed, and you want to know that nobody has subsequently compromised them either.

No, you know that the key was not known by the CA to be compromised 
before the certificate expired. That's a big difference.

From hotz@jpl.nasa.gov  Wed Feb 23 16:55:41 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7733F3A693F for ; Wed, 23 Feb 2011 16:55:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVxQcsz8Sap4 for ; Wed, 23 Feb 2011 16:55:40 -0800 (PST)
Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) by core3.amsl.com (Postfix) with ESMTP id B29893A691B for ; Wed, 23 Feb 2011 16:55:40 -0800 (PST)
Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1O0uR4C001223 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 23 Feb 2011 16:56:28 -0800
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Henry B. Hotz" 
In-Reply-To: <4D65A6E3.3090302@vpnc.org>
Date: Wed, 23 Feb 2011 16:56:27 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com>    <4D65A6E3.3090302@vpnc.org>
To: Paul Hoffman 
X-Mailer: Apple Mail (2.1082)
X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44]
X-Source-Sender: hotz@jpl.nasa.gov
X-AUTH: Authorized
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Feb 2011 00:55:41 -0000

On Feb 23, 2011, at 4:31 PM, Paul Hoffman wrote:

> On 2/23/11 4:27 PM, Henry B. Hotz wrote:
>> There's the digital signature use case.  You want to know that the EE =
and CA(s) were valid at the time the document was signed, and you want =
to know that nobody has subsequently compromised them either.
>=20
> No, you know that the key was not known by the CA to be compromised=20
> before the certificate expired. That's a big difference.

Yes, it is.  However I'm talking about what a verifier wants to know, =
not what a likely CRL implementation will actually tell me.  That there =
is "a big difference" is an unfortunate state of affairs.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu




From kent@bbn.com  Wed Feb 23 19:51:10 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 527043A6960 for ; Wed, 23 Feb 2011 19:51:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.551
X-Spam-Level: 
X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39qxBDI24nB3 for ; Wed, 23 Feb 2011 19:51:09 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 670723A6955 for ; Wed, 23 Feb 2011 19:51:09 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15]:40350 helo=[169.223.148.236]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PsSFA-0007F1-NJ; Wed, 23 Feb 2011 22:51:57 -0500
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:   <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com> 
Date: Wed, 23 Feb 2011 20:02:01 -0500
To: Roberto Opazo 
From: Stephen Kent 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Feb 2011 03:51:10 -0000

At 4:34 PM -0300 2/23/11, Roberto Opazo wrote:
>I think this thread is mixing two different point:
>
>* How should a RP interpret Next Update field in a CRL? Is it an
>expiration date?

the short answers is NO, it it not an expiration date, even if a lot 
of folks have misinterpreted it as such.

>* What should be en Next Update field in the last CRL? This scenario
>is different than the previous one because there is not going to be
>any next CRL in any time. There are many choices here and I really
>think that's a problem. If there would not be so many applications
>already in the market I would recommend a NULL value. But
>unfortunately, I think making a choice is hurter than that. No choice
>is going to be perfect, but there should be only one way to fill Next
>Update field of the last CRL.
>
>Best regards,
>
>Roberto Opazo

You have received several suggestions based on other aspects of the
EOL of the CA, e.g., whether there are subordinate certs that will 
still be valid, whether the certs are used for auth vs. 
non-repudiaiton, etc. So there is not one, right answer for all of 
these contexts. Also, since the problem you raise also is made worse 
by folks misinterpreting the standards re next update, it is not 
clear what a standards body ought to do.

Steve

From kent@bbn.com  Wed Feb 23 19:51:30 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D56393A6985 for ; Wed, 23 Feb 2011 19:51:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.554
X-Spam-Level: 
X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBRLRzoGVjLR for ; Wed, 23 Feb 2011 19:51:29 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 7127A3A6981 for ; Wed, 23 Feb 2011 19:51:29 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15]:40350 helo=[169.223.148.236]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PsSFV-0007F1-LB; Wed, 23 Feb 2011 22:52:18 -0500
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <1298469863.2360.68.camel@nostromo>
References:  <1298469863.2360.68.camel@nostromo>
Date: Wed, 23 Feb 2011 20:42:52 -0500
To: Thomas Pornin 
From: Stephen Kent 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last  CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Feb 2011 03:51:31 -0000

At 9:04 AM -0500 2/23/11, Thomas Pornin wrote:
>On Wed, 2011-02-23 at 08:05 +0100, Stefan Santesson wrote:
>>  Yes, that all sound logical. However on a practical ground that is
>>  quite hard to code into a crypto API. There you need more distinct
>>  rules and predictable outcome.
>
>I second that. Theoretically, each RP would decide, according to its own
>arbitrary policy, whether a given CRL is fresh enough. But the rules for
>appropriate freshness depend upon the context and are likely to be
>CA-specific. Revocation is mostly a kind of damage containment: a way to
>"cancel" an existing certificate, even though the signature on the
>certificate is cryptographically verifiable, in order to cope with an
>unfortunate occurrence, e.g. a key compromise.

Although often cited as such, many folks have found that the principle
reason for revocation is not key compromise, but rather the change of 
the value of some attribute in the cert.

>The revocation
>information freshness is a measure of the time-wise extent of the issue:
>by accepting a week-old CRL, the RP effectively accepts the risk that it
>could be fooled into using a public key which has been compromised
>during the last week.
>
>How much freshness is needed ? It really depends on the procedures
>deployed by the CA to detect the revocation-implying occurrences, and
>how fast it can publish revocation information. Those procedures are
>normally described in the Certification Policy Statement of the CA, and
>supposedly are compatible with the CPS of the CA's CA, and so on.
>Ultimately, this leads to the trust anchor's CPS; however, the TA CPS is
>not necessarily precise about applicable freshness for all CA which it
>has directly or indirectly issued.

The question of how fresh is fresh enough is purely an RP decision. 
Also, while a careful reading of a CPS can help an RP decide what 
might be the right freshness value on a per CA basis, this might 
impose a serious configuration management burden if an RP deals with 
a lot of different CAs. So I think we are heading down a serious rat 
hole here.

>One point of PKI (maybe _the_ point of PKI) is to be able to validate
>links between public keys and identities, for an arbitrary large set of
>identities and public keys, using a small, fixed set of a priori known
>information (the trust anchors).

not always true.  see the RPKI in the SIDR WG for a counter example, i.e.,
cert identities are mot relevant in that PKI.

>...

I agree that an RP can elect to treat the next update value as an 
expiration date, because the RP can do anything that it wants in this 
regard. But, I believe that RPs are not getting the option to make 
this decision. Instead, SW used by RPs are unilaterally interpreting 
the next update value this way, and not allowing the RP to choose 
otherwise. That's not good.

Steve

From wwwrun@rfc-editor.org  Wed Feb 23 14:52:57 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D021A3A68EE for ; Wed, 23 Feb 2011 14:52:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.429
X-Spam-Level: 
X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tSyORJlruek for ; Wed, 23 Feb 2011 14:52:54 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 154893A68F5 for ; Wed, 23 Feb 2011 14:52:54 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 5FD4FE06EE; Wed, 23 Feb 2011 14:53:42 -0800 (PST)
To: jimsch@nwlink.com, mmyers@fastq.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, tim.polk@nist.gov, kent@bbn.com, stefan@aaa-sec.com
From: RFC Errata System 
Message-Id: <20110223225342.5FD4FE06EE@rfc-editor.org>
Date: Wed, 23 Feb 2011 14:53:42 -0800 (PST)
X-Mailman-Approved-At: Wed, 23 Feb 2011 19:54:47 -0800
Cc: pkix@ietf.org, rfc-editor@rfc-editor.org
Subject: [pkix] [Editorial Errata Reported] RFC5272 (2731)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Feb 2011 22:52:57 -0000

The following errata report has been submitted for RFC5272,
"Certificate Management over CMS (CMC)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5272&eid=2731

--------------------------------------
Type: Editorial
Reported by: Sean Turner 

Section: 2.2

Original Text
-------------
Full PKI Response
------------------------
+----------------+
| CMS ContentInfo|
| CMS SignedData |
|   or Auth Data |
|     object     |
+----------------+--------+
|                         |
| PKIResponseBody         |

Corrected Text
--------------
Full PKI Response
------------------------
+----------------+
| CMS ContentInfo|
| CMS SignedData |
|   or Auth Data |
|     object     |
+----------------+--------+
|                         |
| PKIResponse             |


Notes
-----
PKIResponse should be PKIResponse.  It's the name of the content type.  PKIResponseBody only appears once in this RFC and it's in Figure 2.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5272 (draft-ietf-pkix-2797-bis-07)
--------------------------------------
Title               : Certificate Management over CMS (CMC)
Publication Date    : June 2008
Author(s)           : J. Schaad, M. Myers
Category            : PROPOSED STANDARD
Source              : Public-Key Infrastructure (X.509)
Area                : Security
Stream              : IETF
Verifying Party     : IESG

From kent@bbn.com  Wed Feb 23 20:09:44 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57F723A6929 for ; Wed, 23 Feb 2011 20:09:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.555
X-Spam-Level: 
X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBUT5jICSt05 for ; Wed, 23 Feb 2011 20:09:43 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 9E36A3A67F8 for ; Wed, 23 Feb 2011 20:09:43 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15]:44721 helo=[169.223.148.236]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PsSTS-0007KB-Lb; Wed, 23 Feb 2011 23:06:43 -0500
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:  <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com>   
Date: Wed, 23 Feb 2011 23:02:49 -0500
To: "Henry B. Hotz" 
From: Stephen Kent 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: IETF PKIX , "Kemp, David P." 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Feb 2011 04:09:44 -0000

At 4:27 PM -0800 2/23/11, Henry B. Hotz wrote:
>There's the digital signature use case.  You want to know that the 
>EE and CA(s) were valid at the time the document was signed, and you 
>want to know that nobody has subsequently compromised them either.
>

For non-repudiation purposes, the RP should have acquired the CRL(s) 
issued for  the relevant cert(s) immediately after the time of the 
transaction in question.  Also, the transaction, and the certs and 
CRLs, should be time-stamped by a TSA.  For more details, see the 
LTANS WG RFCs.

Steve

From andrea.caccia@studiocaccia.com  Thu Feb 24 01:39:51 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C6F3A6A36 for ; Thu, 24 Feb 2011 01:39:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlZ5kH0fPypz for ; Thu, 24 Feb 2011 01:39:50 -0800 (PST)
Received: from smtplq03.aruba.it (smtplq-out8.aruba.it [62.149.158.28]) by core3.amsl.com (Postfix) with SMTP id 5FF7A3A6A34 for ; Thu, 24 Feb 2011 01:39:49 -0800 (PST)
Received: (qmail 21190 invoked by uid 89); 24 Feb 2011 09:40:10 -0000
Received: from unknown (HELO smtp8.aruba.it) (62.149.158.228) by smtplq03.aruba.it with SMTP; 24 Feb 2011 09:40:10 -0000
Received: (qmail 18156 invoked by uid 89); 24 Feb 2011 09:40:07 -0000
Received: from unknown (HELO ?192.168.49.60?) (andrea.caccia@studiocaccia.com@93.62.162.58) by smtp8.ad.aruba.it with ESMTPA; 24 Feb 2011 09:40:07 -0000
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: Andrea Caccia 
In-Reply-To: 
Date: Thu, 24 Feb 2011 10:40:09 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <438C7354-AC85-4EC6-88AE-3B1E4EE2E4EB@studiocaccia.com>
References:  <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com>    
To: IETF PKIX 
X-Mailer: Apple Mail (2.1082)
X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Feb 2011 09:39:51 -0000

Il giorno 24/feb/2011, alle ore 05.02, Stephen Kent ha scritto:

> At 4:27 PM -0800 2/23/11, Henry B. Hotz wrote:
>> There's the digital signature use case.  You want to know that the EE =
and CA(s) were valid at the time the document was signed, and you want =
to know that nobody has subsequently compromised them either.
>>=20
>=20
> For non-repudiation purposes, the RP should have acquired the CRL(s) =
issued for  the relevant cert(s) immediately after the time of the =
transaction in question.  Also, the transaction, and the certs and CRLs, =
should be time-stamped by a TSA.  For more details, see the LTANS WG =
RFCs.

Possibly 2 CRLs as "immediately after the time of the transaction" the =
CA could not had time to revoke the cert.
For this reason, it there are still valid issued certificates the last =
CRL should be issued at the time the CA cert expires or even after if =
there are revocations not processed.

In case there are valid certificates the safest way (not necessarily the =
best for all perspectives) would be to revoke all valid certificates =
with a revocation date =3D CA cert expiration.

Andrea Caccia


From kent@bbn.com  Thu Feb 24 02:03:52 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4BDC3A6407 for ; Thu, 24 Feb 2011 02:03:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.258
X-Spam-Level: 
X-Spam-Status: No, score=-102.258 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+YsgUf4zDaB for ; Thu, 24 Feb 2011 02:03:52 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 1CF563A6843 for ; Thu, 24 Feb 2011 02:03:52 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15]:57032 helo=[210.245.149.101]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PsY3s-0009yl-7d; Thu, 24 Feb 2011 05:04:40 -0500
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <438C7354-AC85-4EC6-88AE-3B1E4EE2E4EB@studiocaccia.com>
References:  <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com>     <438C7354-AC85-4EC6-88AE-3B1E4EE2E4EB@studiocaccia.com>
Date: Thu, 24 Feb 2011 05:04:34 -0500
To: Andrea Caccia 
From: Stephen Kent 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Feb 2011 10:03:53 -0000

At 10:40 AM +0100 2/24/11, Andrea Caccia wrote:
>Il giorno 24/feb/2011, alle ore 05.02, Stephen Kent ha scritto:
>
>>  At 4:27 PM -0800 2/23/11, Henry B. Hotz wrote:
>>>  There's the digital signature use case.  You want to know that 
>>>the EE and CA(s) were valid at the time the document was signed, 
>>>and you want to know that nobody has subsequently compromised them 
>>>either.
>>>
>>
>>  For non-repudiation purposes, the RP should have acquired the 
>>CRL(s) issued for  the relevant cert(s) immediately after the time 
>>of the transaction in question.  Also, the transaction, and the 
>>certs and CRLs, should be time-stamped by a TSA.  For more details, 
>>see the LTANS WG RFCs.
>
>Possibly 2 CRLs as "immediately after the time of the transaction" 
>the CA could not had time to revoke the cert.

If a transaction occurs at time T, and a CRL is issued at T+delta, 
and if the CPS for the CA says that it processes all revocation 
requests in less than delta
time, one CRL should suffice.  It may not be reasonable for an RP to wait for
multiple CRL intervals to consider a transaction safe, depdnding on 
the frequency of issuance of CRLs, the CPS details, etc.


>For this reason, it there are still valid issued certificates the 
>last CRL should be issued at the time the CA cert expires or even 
>after if there are revocations not processed.

If the public key from the CA cert is used to verify the CRL, a CRL 
signed by the CA after the CA's cert expires probably ought not be 
verifiable.


>In case there are valid certificates the safest way (not necessarily 
>the best for all perspectives) would be to revoke all valid 
>certificates with a revocation date = CA cert expiration.

probably a bit before the CA cert expiration date, for the reasons I 
cited above.

Steve

From tmiller@mitre.org  Thu Feb 24 05:24:54 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12FD33A6B16 for ; Thu, 24 Feb 2011 05:24:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dy9uWOz8mHw for ; Thu, 24 Feb 2011 05:24:53 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 363D23A6B12 for ; Thu, 24 Feb 2011 05:24:53 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 89A8121B028B; Thu, 24 Feb 2011 08:25:42 -0500 (EST)
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8353721B0277; Thu, 24 Feb 2011 08:25:42 -0500 (EST)
Received: from IMCMBX2.MITRE.ORG ([129.83.29.209]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Thu, 24 Feb 2011 08:25:42 -0500
From: "Miller, Timothy J." 
To: Stephen Kent 
Date: Thu, 24 Feb 2011 08:25:42 -0500
Thread-Topic: [pkix] What should be in "Next Update" field of the last CRL?
Thread-Index: AcvUJlUgQSfCBEvtTnGD6PqG/5xZ3A==
Message-ID: 
References:  <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com>     <438C7354-AC85-4EC6-88AE-3B1E4EE2E4EB@studiocaccia.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail-1-271679462"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Feb 2011 13:24:54 -0000

--Apple-Mail-1-271679462
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Feb 24, 2011, at 4:04 AM, Stephen Kent wrote:

> If a transaction occurs at time T, and a CRL is issued at T+delta,=20
> and if the CPS for the CA says that it processes all revocation=20
> requests in less than delta
> time, one CRL should suffice.  It may not be reasonable for an RP to =
wait for
> multiple CRL intervals to consider a transaction safe, depdnding on=20
> the frequency of issuance of CRLs, the CPS details, etc.

I think you have to figure in epsilon, which I'll define as "the time =
the CA CP/CPS defines as the maximum reporting window."  IOW, if the CP =
says the CA will process revocation requests hourly and publish a CRL =
immediately *and* requires Subscribers to report lost or suspected =
compromised key material within 72 hours, then the CRL you want is the =
CRL published at T+73h rather than T+1h.

OTOH, a CP that permits retroactive revocation (revocation request at =
time T for claimed time T-n) can really mess up your day. =20

This is why we pay lawyers.  :)

-- T


--Apple-Mail-1-271679462
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw
ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE
CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt
YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy
ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT
EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy
PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7
RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ
t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8
rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud
EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I
ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd
dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw
0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F
UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v
Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV
BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp
bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0xMTAyMjQxMzI1NDNaMCMGCSqGSIb3DQEJBDEWBBQbZmbs5/eNfKOyUlN2
21f+psn1xzByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV
Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5
IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV
BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp
bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgEQzUkzsnMScZ1+efJxMiysFQrLhto5EVmJh
p5ugUkQkoKDgX3D3+8xszFI0Clekf4OCxVCQxAWaXct7oa93daylzt0EgbU1VM27Ax5j1AP3fBS+
REOuKvOYRSb+H7fKJvUkbfk4DqYN5bS/MrSarSfdTHZYE4y2C26wq+nscTXsAAAAAAAA

--Apple-Mail-1-271679462--

From jdilles@mountaireygroup.com  Thu Feb 24 07:57:42 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0938F3A672F for ; Thu, 24 Feb 2011 07:57:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuBbVXPtggMV for ; Thu, 24 Feb 2011 07:57:41 -0800 (PST)
Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id AA1243A672E for ; Thu, 24 Feb 2011 07:57:40 -0800 (PST)
Received: from st20.mx1.myoutlookonline.com (localhost [127.0.0.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id D538F8BE971; Thu, 24 Feb 2011 10:58:29 -0500 (EST)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from mx1.myoutlookonline.com (unknown [10.110.2.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id 696728BEB5D; Thu, 24 Feb 2011 10:58:29 -0500 (EST)
Received: from BH012.mail.lan ([10.110.21.112]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 24 Feb 2011 10:57:54 -0500
Received: from HUB012.mail.lan ([10.110.17.12]) by BH012.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Feb 2011 10:57:47 -0500
Received: from MAILR001.mail.lan ([192.168.1.2]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Thu, 24 Feb 2011 10:57:47 -0500
From: Jacob Dilles 
To: IETF PKIX 
Date: Thu, 24 Feb 2011 10:58:27 -0500
Thread-Topic: [pkix] What should be in "Next Update" field of the last CRL?
Thread-Index: AcvUO5EH/LqvhQ6iSLaAFQzVrO7eyw==
Message-ID: 
References: <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_E64D667DF1A34BF0B2545279164492DFmountaireygroupcom_"
MIME-Version: 1.0
X-OriginalArrivalTime: 24 Feb 2011 15:57:47.0870 (UTC) FILETIME=[95084FE0:01CBD43B]
Cc: "Kemp, David P." 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Feb 2011 16:07:15 -0000

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

On Feb 23, 2011, at 5:22 PM, Kemp, David P. wrote:

If there are no valid certificates (because either or both of the CA certif=
icate and the EE certificate have expired), does it matter what goes into n=
extUpdate of the last CRL issued by the CA?  There are indeed many choices,=
 but all of them yield the identical result - an expired certificate is not=
 valid.  For that reason the simplest choice (filling nextUpdate with the s=
ame value it would have had if the CA were not expiring) seems best.

Because no choice has any effect (other than perhaps confusing apps with un=
expected magic values), I don't agree that the standard needs to specify on=
ly one.  40 years ago when electrical engineers (the original EEs) were doi=
ng Karnaugh maps, we would have called nextUpdate an "X" (don't care) input=
.

I think the point of the IETF is to write complete specifications - that is=
, one's without "don't care" inputs. Specification SHOULD discourage the us=
e of magic values in any field, but especially one that  that might be used=
 to "reduce the amount of work" an implementation must do in validation. Le=
aving aspects of interoperability to the imagination of developers, even if=
 it shouldn't matter, is typically a bad idea.

BTW,


"If a tree falls in an empty forest, does it make a sound"?

Assuming:
 - "Tree" implies respiration of CO2->02+C via ambient gaseous atmosphere c=
onsisting of at least those elements, with one or more leaves consisting of=
 a solid matrix holding the necessities for said respiration.
 - "Falls" implies some sort of force, e.g. gravity, which accelerates said=
 tree through said atmosphere.
 - "Sound" implies a compression wave traveling through said gaseous atmosp=
here.
Then yes. A solid object with non-zero velocity relative to a gaseous atmos=
phere will generate a compression wave.


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


On Feb 23, 2011, at 5=
:22 PM, Kemp, David P. wrote:

If th=
ere are no valid certificates (because either or both of the CA certificate=
 and the EE certificate have expired), does it matter what goes into nextUp=
date of the last CRL issued by the CA?  There are indeed many cho=
ices, but all of them yield the identical result - an expired certificate i=
s not valid.  For that reason the simplest choice (filling nextUpdate =
with the same value it would have had if the CA were not expiring) see=
ms best.

Because no choice has any effect (other t=
han perhaps confusing apps with unexpected magic values), I don't agree tha=
t the standard needs to specify only one.  40 years ago when electrica=
l engineers (the original EEs) were doing Karnaugh maps, we would have=
 called nextUpdate an "X" (don't care) input.
	

I think the point of the IETF is to write complete specifications - that=
 is, one's without "don't care" inputs. Specification SHOULD discourage the=
 use of magic values in any field, but especially one that  that might=
 be used to "reduce the amount of work" an implementation must do in valida=
tion. Leaving aspects of interoperability to the imagination of developers,=
 even if it shouldn't matter, is typically a bad idea. 

=

BTW,


"If =
a tree falls in an empty forest, does it make a sound"?
<=
div>
Assuming: 
 - "Tree" implies respiration of CO2=
->02+C via ambient gaseous atmosphere consisting of at least those eleme=
nts, with one or more leaves consisting of a solid matrix holding the neces=
sities for said respiration.
 - "Falls" implies some sort of=
 force, e.g. gravity, which accelerates said tree through said atmosphere.<=
/div>
 - "Sound" implies a compression wave traveling through said=
 gaseous atmosphere.
Then yes. A solid object with non-zero veloc=
ity relative to a gaseous atmosphere will generate a compression wave. =
;

=

--_000_E64D667DF1A34BF0B2545279164492DFmountaireygroupcom_--

From roberto@opazo.cl  Thu Feb 24 08:20:58 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BACA43A67A7 for ; Thu, 24 Feb 2011 08:20:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEILNX-U27At for ; Thu, 24 Feb 2011 08:20:58 -0800 (PST)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id A952D3A6784 for ; Thu, 24 Feb 2011 08:20:57 -0800 (PST)
Received: by ewy9 with SMTP id 9so299898ewy.31 for ; Thu, 24 Feb 2011 08:21:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.213.114.79 with SMTP id d15mr828029ebq.78.1298564506801; Thu, 24 Feb 2011 08:21:46 -0800 (PST)
Received: by 10.14.121.212 with HTTP; Thu, 24 Feb 2011 08:21:46 -0800 (PST)
In-Reply-To: 
References:   <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com>  
Date: Thu, 24 Feb 2011 13:21:46 -0300
Message-ID: 
From: Roberto Opazo 
To: IETF 
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Feb 2011 16:20:58 -0000

> Because no choice has any effect (other than perhaps confusing apps with unexpected magic values), I don't agree that the standard needs to specify only one.

Choices has effects, no matter if you see it or not.

Right now, if you put a 24 more hour time in Next Update of the last
CRL, you will have problems validating signatures than wore generated
when certificates were valid, but are been validated after the time
you put on Next Update field of the last CRL.

Magic values create confusion, that is why I think standards should
have a reference for this special situation.

---

Best regards,

Roberto Opazo

From tmiller@mitre.org  Thu Feb 24 09:26:55 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944003A67ED for ; Thu, 24 Feb 2011 09:26:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level: 
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65LweERWZOWi for ; Thu, 24 Feb 2011 09:26:54 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id A9B523A67E3 for ; Thu, 24 Feb 2011 09:26:54 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8247E21B09AE; Thu, 24 Feb 2011 12:27:44 -0500 (EST)
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 72B4A21B0320; Thu, 24 Feb 2011 12:27:44 -0500 (EST)
Received: from IMCMBX2.MITRE.ORG ([129.83.29.209]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Thu, 24 Feb 2011 12:27:44 -0500
From: "Miller, Timothy J." 
To: Roberto Opazo 
Date: Thu, 24 Feb 2011 12:27:42 -0500
Thread-Topic: [pkix] What should be in "Next Update" field of the last CRL?
Thread-Index: AcvUSCTWt4eAVR1dTWGURaz7TJJuxw==
Message-ID: <8B079EAE-11C8-4DDC-B631-DE309206511B@mitre.org>
References:   <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail-2-286199341"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Cc: IETF 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Feb 2011 17:26:55 -0000

--Apple-Mail-2-286199341
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Feb 24, 2011, at 10:21 AM, Roberto Opazo wrote:

> Right now, if you put a 24 more hour time in Next Update of the last
> CRL, you will have problems validating signatures than wore generated
> when certificates were valid, but are been validated after the time
> you put on Next Update field of the last CRL.

Signature validation after certificate expiry is a *special case* that's =
already covered.  You validate using the CRL valid at the *time of =
signing*, not the final CRL from the PKI.

This is why secure time stamping is so important.  Else you introduce =
the question of "what time was it signed?"

-- T


--Apple-Mail-2-286199341
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw
ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE
CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt
YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy
ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT
EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy
PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7
RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ
t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8
rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud
EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I
ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd
dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw
0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F
UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v
Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV
BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp
bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0xMTAyMjQxNzI3NDNaMCMGCSqGSIb3DQEJBDEWBBSjEJUk7sHKByGEe93K
PppbCxrBCzByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV
Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5
IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV
BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp
bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgLeUcnTpWohH6ySemUgaTG6XQW+8b/2kB6Mu
UH1mxF9BQjQ+dWQGF9cEFwngdmW7m6Qce2FO/TbaGPY+g2fgKv0CVnx3vfFxT4qOTqULO8C2F0EF
n47bYbtGj5W+3mGAroOJsCUH6HLsY4An1PqjIcfGcwKJGoQKAfiHpHsATPDUAAAAAAAA

--Apple-Mail-2-286199341--

From david.cooper@nist.gov  Thu Feb 24 09:32:47 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AF9E3A67E3 for ; Thu, 24 Feb 2011 09:32:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.384
X-Spam-Level: 
X-Spam-Status: No, score=-5.384 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRyu4gLZYKiL for ; Thu, 24 Feb 2011 09:32:46 -0800 (PST)
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id 56DAE3A67D3 for ; Thu, 24 Feb 2011 09:32:45 -0800 (PST)
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p1OHXhRL031822; Thu, 24 Feb 2011 12:33:43 -0500
Message-ID: <4D669667.5090303@nist.gov>
Date: Thu, 24 Feb 2011 12:33:27 -0500
From: "David A. Cooper" 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20101222 Mandriva/3.0.11-0.1mdv2010.2 (2010.2) Thunderbird/3.0.11
MIME-Version: 1.0
To: Roberto Opazo 
References: 		<215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com>		 
In-Reply-To: 
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Cc: IETF 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Feb 2011 17:32:47 -0000




  
  


The issue that you raise has nothing to do with the value of nextUpdate
in the last CRL.  X.509 defines the Validity field (notBefore and
notAfter) in a certificate as follows:



      validity is the time interval during which the CA
warrants that

      it will maintain information about the status of the certificate.



You cannot use the same process to determine whether a certificate was
valid at some time in the past (e.g., when a signature was generated)
that you use to determine whether a certificate is currently valid,
particularly if the certificate has already expired.



The problem in the scenario that you describe below isn't the value of
nextUpdate in the last CRL, it is the validation procedure that you
think relying parties may use.  The relying party in this scenario should
not be comparing the nextUpdate time in the CRL to the current
time.  In this scenario, the relying party needs to find a CRL with
thisUpdate and nextUpdate times that satisfy these two criteria:



1)  The CRL is sufficiently recent relative to the time the
signature was generated.  As previously described in this thread,
the meaning of "sufficiently recent" may depend on the application.  It
may mean a CRL with a nextUpdate time that is later than the time the
signature was generated (even if the thisUpdate time was before the
signature was generated) or it may mean a CRL with a thisUpdate time
that is long enough after the signature generation time to allow for
any potential key compromise to have been reported and processed.



2) The CRL must either have a thisUpdate time that is before
the notAfter time in the certificate or have an expiredCertsOnCRL
extension that specifies a time that is before the notAfter time in the
certificate.  (The expiredCertsOnCRL extension indicates that the CRL
includes revocation status for certificates that expired on or after
the time specified in the extension.)  If neither of these conditions
are satisfied, then the CRL may not include status information for the
certificate.



Consider a scenario similar to the one you describe, but in which the
CA is not at the end of its life.  A subscriber generates a signature
two days before his or her certificate expires, a relying party wishes
to validate this signature 3 days after the certificate expires, and
the CA issues CRLs once a day with nextUpdate times that are 24 hours
after the thisUpdate times.  If the relying party insisted on using a
CRL with a nextUpdate time that is after the current time, the only
such CRL available would be one that was issued after the certificate
expired.  Such a CRL may not provide status information for the
certificate since it had already expired before the CRL was issued, and
so cannot be used to verify that the certificate had not been revoked.



Similarly, if a CA that was getting ready to shut down issued its last
CRL shortly after the final certificate that it had issued had expired,
this CRL could be empty since a CRL only needs to list revoked
certificates that have not yet expired.  So again, this last CRL could
not be used to determine whether a certificate was valid at some time
in the past before it expired, regardless of the value of nextUpdate in
the CRL.



In either case, the relying party will not be able to obtain a CRL with
a nextUpate time that is after the current time that can be relied upon
to indicate whether the certificate had been revoked before it expired.



On 02/24/2011 11:21 AM, Roberto Opazo wrote:


  

    
Because no choice has any effect (other than perhaps confusing apps with unexpected magic values), I don't agree that the standard needs to specify only one.
    

  

  
Choices has effects, no matter if you see it or not.

Right now, if you put a 24 more hour time in Next Update of the last
CRL, you will have problems validating signatures than wore generated
when certificates were valid, but are been validated after the time
you put on Next Update field of the last CRL.

Magic values create confusion, that is why I think standards should
have a reference for this special situation.

---

Best regards,

Roberto Opazo
  






From denis.pinkas@bull.net  Fri Feb 25 04:59:18 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E85C3A69AA for ; Fri, 25 Feb 2011 04:59:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.342
X-Spam-Level: **
X-Spam-Status: No, score=2.342 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_BAD_ID=2.837]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+P8zvYLN3vB for ; Fri, 25 Feb 2011 04:59:12 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by core3.amsl.com (Postfix) with ESMTP id 5E3913A69AB for ; Fri, 25 Feb 2011 04:59:11 -0800 (PST)
Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (Bull S.A.) with ESMTP id CAEA715815E; Fri, 25 Feb 2011 14:08:00 +0100 (CET)
Received: from B016404 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2011022514000144:31490 ; Fri, 25 Feb 2011 14:00:01 +0100 
From: "Denis Pinkas"
To: "roberto"
Date: Fri, 25 Feb 2011 13:59:59 +0100
Message-Id: 
References: <4D669667.5090303@nist.gov>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: DreamMail 4.4.1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 25/02/2011 14:00:01, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 25/02/2011 14:00:02, Serialize complete at 25/02/2011 14:00:02
Content-Type: multipart/alternative;  boundary="----=_NextPart_11022513595858161483558_002"
Cc: pkix 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: denis.pinkas@bull.net
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Feb 2011 12:59:18 -0000

------=_NextPart_11022513595858161483558_002
Content-Transfer-Encoding: base64
Content-Type: text/plain; 
	charset="ISO-8859-1"

V2UgYXJlIGZhciBhd2F5IGZyb20gdGhlIG9yaWdpbmFsIHRvcGljLi4uDQpBIG1pbm9yIGNvcnJl
Y3Rpb24gdG8gdGhlIHRleHQ6DQpUaGUgdGV4dCBzdGF0ZXM6IA0KIkluIHRoaXMgc2NlbmFyaW8s
IHRoZSByZWx5aW5nIHBhcnR5IG5lZWRzIHRvIGZpbmQgYSBDUkwgd2l0aCB0aGlzVXBkYXRlIGFu
ZCBuZXh0VXBkYXRlIHRpbWVzIHRoYXQgc2F0aXNmeSB0aGVzZSB0d28gY3JpdGVyaWEiLg0KVGhl
IGZpcnN0IGNyaXRlcmlhIGlzIG5vdCBjb3JyZWN0bHkgc3RhdGVkOiANCiJUaGUgQ1JMIGlzIHN1
ZmZpY2llbnRseSByZWNlbnQgcmVsYXRpdmUgdG8gdGhlIHRpbWUgdGhlIHNpZ25hdHVyZSB3YXMg
Z2VuZXJhdGVkLg0KQXMgcHJldmlvdXNseSBkZXNjcmliZWQgaW4gdGhpcyB0aHJlYWQsIHRoZSBt
ZWFuaW5nIG9mICJzdWZmaWNpZW50bHkgcmVjZW50IiBtYXkgZGVwZW5kIG9uIHRoZSBhcHBsaWNh
dGlvbi4iICAgDQpQcm9wb3NlZCByZXdvcmRpbmc6DQoiIFRoZSBuZXh0VXBkYXRlIGZpZWxkIG9m
IHRoZSBDUkwgaXMgc3VmZmljaWVudGx5IGxhdGVyIHRoYW4gdGhlIHRpbWUgdGhlIHNpZ25hdHVy
ZSB3YXMgdGltZS1zdGFtcGVkIA0KKHNpbmNlIHlvdSBuZXZlciBrbm93IHdoZW4gdGhlIHNpZ25h
dHVyZSB3YXMgZ2VuZXJhdGVkKSIuDQpEZW5pcw0KDQotLS0tLSBNZXNzYWdlIHJl53UgLS0tLS0g
DQpEZSA6IHBraXgtYm91bmNlcyANCsAgOiBSb2JlcnRvIE9wYXpvIA0KRGF0ZSA6IDIwMTEtMDIt
MjQsIDE4OjMzOjI3DQpTdWpldCA6IFJlOiBbcGtpeF0gV2hhdCBzaG91bGQgYmUgaW4gIk5leHQg
VXBkYXRlIiBmaWVsZCBvZiB0aGUgbGFzdCBDUkw/DQoNCg0KVGhlIGlzc3VlIHRoYXQgeW91IHJh
aXNlIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggdGhlIHZhbHVlIG9mIG5leHRVcGRhdGUgaW4gdGhl
IGxhc3QgQ1JMLiAgWC41MDkgZGVmaW5lcyB0aGUgVmFsaWRpdHkgZmllbGQgKG5vdEJlZm9yZSBh
bmQgbm90QWZ0ZXIpIGluIGEgY2VydGlmaWNhdGUgYXMgZm9sbG93czoNCg0KICAgICAgdmFsaWRp
dHkgaXMgdGhlIHRpbWUgaW50ZXJ2YWwgZHVyaW5nIHdoaWNoIHRoZSBDQSB3YXJyYW50cyB0aGF0
DQogICAgICBpdCB3aWxsIG1haW50YWluIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzdGF0dXMgb2Yg
dGhlIGNlcnRpZmljYXRlLg0KDQpZb3UgY2Fubm90IHVzZSB0aGUgc2FtZSBwcm9jZXNzIHRvIGRl
dGVybWluZSB3aGV0aGVyIGEgY2VydGlmaWNhdGUgd2FzIHZhbGlkIGF0IHNvbWUgdGltZSBpbiB0
aGUgcGFzdCAoZS5nLiwgd2hlbiBhIHNpZ25hdHVyZSB3YXMgZ2VuZXJhdGVkKSB0aGF0IHlvdSB1
c2UgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgYSBjZXJ0aWZpY2F0ZSBpcyBjdXJyZW50bHkgdmFsaWQs
IHBhcnRpY3VsYXJseSBpZiB0aGUgY2VydGlmaWNhdGUgaGFzIGFscmVhZHkgZXhwaXJlZC4NCg0K
VGhlIHByb2JsZW0gaW4gdGhlIHNjZW5hcmlvIHRoYXQgeW91IGRlc2NyaWJlIGJlbG93IGlzbid0
IHRoZSB2YWx1ZSBvZiBuZXh0VXBkYXRlIGluIHRoZSBsYXN0IENSTCwgaXQgaXMgdGhlIHZhbGlk
YXRpb24gcHJvY2VkdXJlIHRoYXQgeW91IHRoaW5rIHJlbHlpbmcgcGFydGllcyBtYXkgdXNlLiAg
VGhlIHJlbHlpbmcgcGFydHkgaW4gdGhpcyBzY2VuYXJpbyBzaG91bGQgbm90IGJlIGNvbXBhcmlu
ZyB0aGUgbmV4dFVwZGF0ZSB0aW1lIGluIHRoZSBDUkwgdG8gdGhlIGN1cnJlbnQgdGltZS4gIElu
IHRoaXMgc2NlbmFyaW8sIHRoZSByZWx5aW5nIHBhcnR5IG5lZWRzIHRvIGZpbmQgYSBDUkwgd2l0
aCB0aGlzVXBkYXRlIGFuZCBuZXh0VXBkYXRlIHRpbWVzIHRoYXQgc2F0aXNmeSB0aGVzZSB0d28g
Y3JpdGVyaWE6DQoNCjEpICBUaGUgQ1JMIGlzIHN1ZmZpY2llbnRseSByZWNlbnQgcmVsYXRpdmUg
dG8gdGhlIHRpbWUgdGhlIHNpZ25hdHVyZSB3YXMgZ2VuZXJhdGVkLiAgQXMgcHJldmlvdXNseSBk
ZXNjcmliZWQgaW4gdGhpcyB0aHJlYWQsIHRoZSBtZWFuaW5nIG9mICJzdWZmaWNpZW50bHkgcmVj
ZW50IiBtYXkgZGVwZW5kIG9uIHRoZSBhcHBsaWNhdGlvbi4gIEl0IG1heSBtZWFuIGEgQ1JMIHdp
dGggYSBuZXh0VXBkYXRlIHRpbWUgdGhhdCBpcyBsYXRlciB0aGFuIHRoZSB0aW1lIHRoZSBzaWdu
YXR1cmUgd2FzIGdlbmVyYXRlZCAoZXZlbiBpZiB0aGUgdGhpc1VwZGF0ZSB0aW1lIHdhcyBiZWZv
cmUgdGhlIHNpZ25hdHVyZSB3YXMgZ2VuZXJhdGVkKSBvciBpdCBtYXkgbWVhbiBhIENSTCB3aXRo
IGEgdGhpc1VwZGF0ZSB0aW1lIHRoYXQgaXMgbG9uZyBlbm91Z2ggYWZ0ZXIgdGhlIHNpZ25hdHVy
ZSBnZW5lcmF0aW9uIHRpbWUgdG8gYWxsb3cgZm9yIGFueSBwb3RlbnRpYWwga2V5IGNvbXByb21p
c2UgdG8gaGF2ZSBiZWVuIHJlcG9ydGVkIGFuZCBwcm9jZXNzZWQuDQoNCjIpIFRoZSBDUkwgbXVz
dCBlaXRoZXIgaGF2ZSBhIHRoaXNVcGRhdGUgdGltZSB0aGF0IGlzIGJlZm9yZSB0aGUgbm90QWZ0
ZXIgdGltZSBpbiB0aGUgY2VydGlmaWNhdGUgb3IgaGF2ZSBhbiBleHBpcmVkQ2VydHNPbkNSTCBl
eHRlbnNpb24gdGhhdCBzcGVjaWZpZXMgYSB0aW1lIHRoYXQgaXMgYmVmb3JlIHRoZSBub3RBZnRl
ciB0aW1lIGluIHRoZSBjZXJ0aWZpY2F0ZS4gIChUaGUgZXhwaXJlZENlcnRzT25DUkwgZXh0ZW5z
aW9uIGluZGljYXRlcyB0aGF0IHRoZSBDUkwgaW5jbHVkZXMgcmV2b2NhdGlvbiBzdGF0dXMgZm9y
IGNlcnRpZmljYXRlcyB0aGF0IGV4cGlyZWQgb24gb3IgYWZ0ZXIgdGhlIHRpbWUgc3BlY2lmaWVk
IGluIHRoZSBleHRlbnNpb24uKSAgSWYgbmVpdGhlciBvZiB0aGVzZSBjb25kaXRpb25zIGFyZSBz
YXRpc2ZpZWQsIHRoZW4gdGhlIENSTCBtYXkgbm90IGluY2x1ZGUgc3RhdHVzIGluZm9ybWF0aW9u
IGZvciB0aGUgY2VydGlmaWNhdGUuDQoNCkNvbnNpZGVyIGEgc2NlbmFyaW8gc2ltaWxhciB0byB0
aGUgb25lIHlvdSBkZXNjcmliZSwgYnV0IGluIHdoaWNoIHRoZSBDQSBpcyBub3QgYXQgdGhlIGVu
ZCBvZiBpdHMgbGlmZS4gIEEgc3Vic2NyaWJlciBnZW5lcmF0ZXMgYSBzaWduYXR1cmUgdHdvIGRh
eXMgYmVmb3JlIGhpcyBvciBoZXIgY2VydGlmaWNhdGUgZXhwaXJlcywgYSByZWx5aW5nIHBhcnR5
IHdpc2hlcyB0byB2YWxpZGF0ZSB0aGlzIHNpZ25hdHVyZSAzIGRheXMgYWZ0ZXIgdGhlIGNlcnRp
ZmljYXRlIGV4cGlyZXMsIGFuZCB0aGUgQ0EgaXNzdWVzIENSTHMgb25jZSBhIGRheSB3aXRoIG5l
eHRVcGRhdGUgdGltZXMgdGhhdCBhcmUgMjQgaG91cnMgYWZ0ZXIgdGhlIHRoaXNVcGRhdGUgdGlt
ZXMuICBJZiB0aGUgcmVseWluZyBwYXJ0eSBpbnNpc3RlZCBvbiB1c2luZyBhIENSTCB3aXRoIGEg
bmV4dFVwZGF0ZSB0aW1lIHRoYXQgaXMgYWZ0ZXIgdGhlIGN1cnJlbnQgdGltZSwgdGhlIG9ubHkg
c3VjaCBDUkwgYXZhaWxhYmxlIHdvdWxkIGJlIG9uZSB0aGF0IHdhcyBpc3N1ZWQgYWZ0ZXIgdGhl
IGNlcnRpZmljYXRlIGV4cGlyZWQuICBTdWNoIGEgQ1JMIG1heSBub3QgcHJvdmlkZSBzdGF0dXMg
aW5mb3JtYXRpb24gZm9yIHRoZSBjZXJ0aWZpY2F0ZSBzaW5jZSBpdCBoYWQgYWxyZWFkeSBleHBp
cmVkIGJlZm9yZSB0aGUgQ1JMIHdhcyBpc3N1ZWQsIGFuZCBzbyBjYW5ub3QgYmUgdXNlZCB0byB2
ZXJpZnkgdGhhdCB0aGUgY2VydGlmaWNhdGUgaGFkIG5vdCBiZWVuIHJldm9rZWQuDQoNClNpbWls
YXJseSwgaWYgYSBDQSB0aGF0IHdhcyBnZXR0aW5nIHJlYWR5IHRvIHNodXQgZG93biBpc3N1ZWQg
aXRzIGxhc3QgQ1JMIHNob3J0bHkgYWZ0ZXIgdGhlIGZpbmFsIGNlcnRpZmljYXRlIHRoYXQgaXQg
aGFkIGlzc3VlZCBoYWQgZXhwaXJlZCwgdGhpcyBDUkwgY291bGQgYmUgZW1wdHkgc2luY2UgYSBD
Ukwgb25seSBuZWVkcyB0byBsaXN0IHJldm9rZWQgY2VydGlmaWNhdGVzIHRoYXQgaGF2ZSBub3Qg
eWV0IGV4cGlyZWQuICBTbyBhZ2FpbiwgdGhpcyBsYXN0IENSTCBjb3VsZCBub3QgYmUgdXNlZCB0
byBkZXRlcm1pbmUgd2hldGhlciBhIGNlcnRpZmljYXRlIHdhcyB2YWxpZCBhdCBzb21lIHRpbWUg
aW4gdGhlIHBhc3QgYmVmb3JlIGl0IGV4cGlyZWQsIHJlZ2FyZGxlc3Mgb2YgdGhlIHZhbHVlIG9m
IG5leHRVcGRhdGUgaW4gdGhlIENSTC4NCg0KSW4gZWl0aGVyIGNhc2UsIHRoZSByZWx5aW5nIHBh
cnR5IHdpbGwgbm90IGJlIGFibGUgdG8gb2J0YWluIGEgQ1JMIHdpdGggYSBuZXh0VXBhdGUgdGlt
ZSB0aGF0IGlzIGFmdGVyIHRoZSBjdXJyZW50IHRpbWUgdGhhdCBjYW4gYmUgcmVsaWVkIHVwb24g
dG8gaW5kaWNhdGUgd2hldGhlciB0aGUgY2VydGlmaWNhdGUgaGFkIGJlZW4gcmV2b2tlZCBiZWZv
cmUgaXQgZXhwaXJlZC4NCg0KT24gMDIvMjQvMjAxMSAxMToyMSBBTSwgUm9iZXJ0byBPcGF6byB3
cm90ZTogDQpCZWNhdXNlIG5vIGNob2ljZSBoYXMgYW55IGVmZmVjdCAob3RoZXIgdGhhbiBwZXJo
YXBzIGNvbmZ1c2luZyBhcHBzIHdpdGggdW5leHBlY3RlZCBtYWdpYyB2YWx1ZXMpLCBJIGRvbid0
IGFncmVlIHRoYXQgdGhlIHN0YW5kYXJkIG5lZWRzIHRvIHNwZWNpZnkgb25seSBvbmUuDQogICAg
DQpDaG9pY2VzIGhhcyBlZmZlY3RzLCBubyBtYXR0ZXIgaWYgeW91IHNlZSBpdCBvciBub3QuDQoN
ClJpZ2h0IG5vdywgaWYgeW91IHB1dCBhIDI0IG1vcmUgaG91ciB0aW1lIGluIE5leHQgVXBkYXRl
IG9mIHRoZSBsYXN0DQpDUkwsIHlvdSB3aWxsIGhhdmUgcHJvYmxlbXMgdmFsaWRhdGluZyBzaWdu
YXR1cmVzIHRoYW4gd29yZSBnZW5lcmF0ZWQNCndoZW4gY2VydGlmaWNhdGVzIHdlcmUgdmFsaWQs
IGJ1dCBhcmUgYmVlbiB2YWxpZGF0ZWQgYWZ0ZXIgdGhlIHRpbWUNCnlvdSBwdXQgb24gTmV4dCBV
cGRhdGUgZmllbGQgb2YgdGhlIGxhc3QgQ1JMLg0KDQpNYWdpYyB2YWx1ZXMgY3JlYXRlIGNvbmZ1
c2lvbiwgdGhhdCBpcyB3aHkgSSB0aGluayBzdGFuZGFyZHMgc2hvdWxkDQpoYXZlIGEgcmVmZXJl
bmNlIGZvciB0aGlzIHNwZWNpYWwgc2l0dWF0aW9uLg0KDQotLS0NCg0KQmVzdCByZWdhcmRzLA0K
DQpSb2JlcnRvIE9wYXpvDQogIA0K

------=_NextPart_11022513595858161483558_002
Content-Transfer-Encoding: base64
Content-Type: text/html; 
	charset="ISO-8859-1"

PEhUTUw+PEhFQUQ+PFRJVExFPjwvVElUTEU+DQo8TUVUQSBjb250ZW50PSJLc0RIVE1MRURMaWIu
b2N4LCBGcmVlV2FyZSBIVE1MIEVkaXRvciAxLjE2NC4yLCCpIEt1cnQgU2VuZmVyIiANCm5hbWU9
R0VORVJBVE9SPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9o
dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPjwvSEVBRD4NCjxCT0RZIHN0eWxlPSJGT05ULVNJWkU6
IDEwcHQ7IEZPTlQtRkFNSUxZOiBUYWhvbWEiIGxlZnRNYXJnaW49NSB0b3BNYXJnaW49NSANCiNm
ZmZmZmY+DQo8UD5XZSBhcmUgZmFyIGF3YXkgZnJvbSB0aGUgb3JpZ2luYWwgdG9waWMuLi48L1A+
DQo8UD5BIG1pbm9yIGNvcnJlY3Rpb24gdG8gdGhlIHRleHQ6PC9QPg0KPFA+VGhlIHRleHQgc3Rh
dGVzOiA8QlI+IkluIHRoaXMgc2NlbmFyaW8sIHRoZSByZWx5aW5nIHBhcnR5IG5lZWRzIHRvIGZp
bmQgYSBDUkwgDQp3aXRoIHRoaXNVcGRhdGUgYW5kIG5leHRVcGRhdGUgdGltZXMgdGhhdCBzYXRp
c2Z5IHRoZXNlIHR3byBjcml0ZXJpYSIuPC9QPg0KPFA+VGhlIGZpcnN0IGNyaXRlcmlhIGlzIG5v
dCBjb3JyZWN0bHkgc3RhdGVkOiA8QlI+IlRoZSBDUkwgaXMgc3VmZmljaWVudGx5IA0KcmVjZW50
IDxVPnJlbGF0aXZlIHRvIHRoZSB0aW1lIHRoZSBzaWduYXR1cmUgd2FzIGdlbmVyYXRlZDwvVT4u
PEJSPkFzIHByZXZpb3VzbHkgDQpkZXNjcmliZWQgaW4gdGhpcyB0aHJlYWQsIHRoZSBtZWFuaW5n
IG9mICJzdWZmaWNpZW50bHkgcmVjZW50IiBtYXkgZGVwZW5kIG9uIHRoZSANCmFwcGxpY2F0aW9u
LiImbmJzcDsmbmJzcDsgPC9QPg0KPFA+UHJvcG9zZWQgcmV3b3JkaW5nOjxCUj4iIFRoZSBuZXh0
VXBkYXRlIGZpZWxkIG9mIHRoZSBDUkwmbmJzcDtpcyBzdWZmaWNpZW50bHkgDQo8VT5sYXRlcjwv
VT4gdGhhbiB0aGUgdGltZSB0aGUgc2lnbmF0dXJlIHdhcyB0aW1lLXN0YW1wZWQgPEJSPihzaW5j
ZSB5b3UgbmV2ZXIgDQprbm93IHdoZW4gdGhlIHNpZ25hdHVyZSZuYnNwO3dhcyBnZW5lcmF0ZWQp
Ii48L1A+DQo8RElWPjwhLS1BSURfRlJPTU5BTUVfQkVHSU4tLT5EZW5pczwvRElWPg0KPERJVj4m
bmJzcDs8L0RJVj4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFE
RElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJw
eCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIA0KICBzdHlsZT0iRk9OVC1XRUlH
SFQ6IG5vcm1hbDsgRk9OVC1TSVpFOiA5cHQ7IExJTkUtSEVJR0hUOiBub3JtYWw7IEZPTlQtU1RZ
TEU6IG5vcm1hbDsgRk9OVC1WQVJJQU5UOiBub3JtYWwiPi0tLS0tIA0KICBNZXNzYWdlIHJl53Ug
LS0tLS0gPC9ESVY+DQogIDxESVYgDQogIHN0eWxlPSJGT05ULVdFSUdIVDogbm9ybWFsOyBGT05U
LVNJWkU6IDlwdDsgQkFDS0dST1VORDogI2U0ZTRlNDsgTElORS1IRUlHSFQ6IG5vcm1hbDsgRk9O
VC1TVFlMRTogbm9ybWFsOyBGT05ULVZBUklBTlQ6IG5vcm1hbDsgZm9udC1jb2xvcjogYmxhY2si
PjxCPkRlIA0KICA6PC9CPiA8QSBocmVmPSJtYWlsdG8gOnBraXgtYm91bmNlc0BpZXRmLm9yZyI+
cGtpeC1ib3VuY2VzPC9BPiA8L0RJVj4NCiAgPERJViANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBu
b3JtYWw7IEZPTlQtU0laRTogOXB0OyBMSU5FLUhFSUdIVDogbm9ybWFsOyBGT05ULVNUWUxFOiBu
b3JtYWw7IEZPTlQtVkFSSUFOVDogbm9ybWFsIj48Qj7AIA0KICA6PC9CPiA8QSBocmVmPSJtYWls
dG8gOnJvYmVydG9Ab3Bhem8uY2wiPlJvYmVydG8gT3Bhem88L0E+IDwvRElWPg0KICA8RElWIA0K
ICBzdHlsZT0iRk9OVC1XRUlHSFQ6IG5vcm1hbDsgRk9OVC1TSVpFOiA5cHQ7IExJTkUtSEVJR0hU
OiBub3JtYWw7IEZPTlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1WQVJJQU5UOiBub3JtYWwiPjxCPkRh
dGUgDQogIDo8L0I+IDIwMTEtMDItMjQsIDE4OjMzOjI3PC9ESVY+DQogIDxESVYgDQogIHN0eWxl
PSJGT05ULVdFSUdIVDogbm9ybWFsOyBGT05ULVNJWkU6IDlwdDsgTElORS1IRUlHSFQ6IG5vcm1h
bDsgRk9OVC1TVFlMRTogbm9ybWFsOyBGT05ULVZBUklBTlQ6IG5vcm1hbCI+PEI+U3VqZXQgDQog
IDo8L0I+IFJlOiBbcGtpeF0gV2hhdCBzaG91bGQgYmUgaW4gIk5leHQgVXBkYXRlIiBmaWVsZCBv
ZiB0aGUgbGFzdCBDUkw/PC9ESVY+DQogIDxESVY+PEJSPjwvRElWPg0KICA8RElWPjwvRElWPg0K
ICA8RElWPjwvRElWPg0KICA8RElWPlRoZSBpc3N1ZSB0aGF0IHlvdSByYWlzZSBoYXMgbm90aGlu
ZyB0byBkbyB3aXRoIHRoZSB2YWx1ZSBvZiBuZXh0VXBkYXRlIA0KICBpbiB0aGUgbGFzdCBDUkwu
Jm5ic3A7IFguNTA5IGRlZmluZXMgdGhlIFZhbGlkaXR5IGZpZWxkIChub3RCZWZvcmUgYW5kIA0K
ICBub3RBZnRlcikgaW4gYSBjZXJ0aWZpY2F0ZSBhcyBmb2xsb3dzOjxCUj48QlI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8Qj52YWxpZGl0eTwvQj4gaXMgdGhlIHRpbWUgaW50
ZXJ2YWwgZHVyaW5nIHdoaWNoIHRoZSBDQSB3YXJyYW50cyANCiAgdGhhdDxCUj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgaXQgd2lsbCBtYWludGFpbiBpbmZvcm1hdGlvbiBhYm91dCB0
aGUgDQogIHN0YXR1cyBvZiB0aGUgY2VydGlmaWNhdGUuPEJSPjxCUj5Zb3UgY2Fubm90IHVzZSB0
aGUgc2FtZSBwcm9jZXNzIHRvIGRldGVybWluZSANCiAgd2hldGhlciBhIGNlcnRpZmljYXRlIHdh
cyB2YWxpZCBhdCBzb21lIHRpbWUgaW4gdGhlIHBhc3QgKGUuZy4sIHdoZW4gYSANCiAgc2lnbmF0
dXJlIHdhcyBnZW5lcmF0ZWQpIHRoYXQgeW91IHVzZSB0byBkZXRlcm1pbmUgd2hldGhlciBhIGNl
cnRpZmljYXRlIGlzIA0KICBjdXJyZW50bHkgdmFsaWQsIHBhcnRpY3VsYXJseSBpZiB0aGUgY2Vy
dGlmaWNhdGUgaGFzIGFscmVhZHkgDQogIGV4cGlyZWQuPEJSPjxCUj5UaGUgcHJvYmxlbSBpbiB0
aGUgc2NlbmFyaW8gdGhhdCB5b3UgZGVzY3JpYmUgYmVsb3cgaXNuJ3QgdGhlIA0KICB2YWx1ZSBv
ZiBuZXh0VXBkYXRlIGluIHRoZSBsYXN0IENSTCwgaXQgaXMgdGhlIHZhbGlkYXRpb24gcHJvY2Vk
dXJlIHRoYXQgeW91IA0KICB0aGluayByZWx5aW5nIHBhcnRpZXMgbWF5IHVzZS4mbmJzcDsgVGhl
IHJlbHlpbmcgcGFydHkgaW4gdGhpcyBzY2VuYXJpbyANCiAgPEI+c2hvdWxkIG5vdDwvQj4gYmUg
Y29tcGFyaW5nIHRoZSBuZXh0VXBkYXRlIHRpbWUgaW4gdGhlIENSTCB0byB0aGUgY3VycmVudCAN
CiAgdGltZS4mbmJzcDsgSW4gdGhpcyBzY2VuYXJpbywgdGhlIHJlbHlpbmcgcGFydHkgbmVlZHMg
dG8gZmluZCBhIENSTCB3aXRoIA0KICB0aGlzVXBkYXRlIGFuZCBuZXh0VXBkYXRlIHRpbWVzIHRo
YXQgc2F0aXNmeSB0aGVzZSB0d28gDQogIGNyaXRlcmlhOjxCUj48QlI+MSkmbmJzcDsgVGhlIENS
TCBpcyBzdWZmaWNpZW50bHkgcmVjZW50IDxVPnJlbGF0aXZlIHRvIHRoZSANCiAgdGltZSB0aGUg
c2lnbmF0dXJlIHdhcyBnZW5lcmF0ZWQ8L1U+LiZuYnNwOyBBcyBwcmV2aW91c2x5IGRlc2NyaWJl
ZCBpbiB0aGlzIA0KICB0aHJlYWQsIHRoZSBtZWFuaW5nIG9mICJzdWZmaWNpZW50bHkgcmVjZW50
IiBtYXkgZGVwZW5kIG9uIHRoZSANCiAgYXBwbGljYXRpb24uJm5ic3A7IEl0IG1heSBtZWFuIGEg
Q1JMIHdpdGggYSBuZXh0VXBkYXRlIHRpbWUgdGhhdCBpcyBsYXRlciB0aGFuIA0KICB0aGUgdGlt
ZSB0aGUgc2lnbmF0dXJlIHdhcyBnZW5lcmF0ZWQgKGV2ZW4gaWYgdGhlIHRoaXNVcGRhdGUgdGlt
ZSB3YXMgYmVmb3JlIA0KICB0aGUgc2lnbmF0dXJlIHdhcyBnZW5lcmF0ZWQpIG9yIGl0IG1heSBt
ZWFuIGEgQ1JMIHdpdGggYSB0aGlzVXBkYXRlIHRpbWUgdGhhdCANCiAgaXMgbG9uZyBlbm91Z2gg
YWZ0ZXIgdGhlIHNpZ25hdHVyZSBnZW5lcmF0aW9uIHRpbWUgdG8gYWxsb3cgZm9yIGFueSBwb3Rl
bnRpYWwgDQogIGtleSBjb21wcm9taXNlIHRvIGhhdmUgYmVlbiByZXBvcnRlZCBhbmQgcHJvY2Vz
c2VkLjxCUj48QlI+MikgVGhlIENSTCANCiAgPEI+bXVzdDwvQj4gZWl0aGVyIGhhdmUgYSB0aGlz
VXBkYXRlIHRpbWUgdGhhdCBpcyBiZWZvcmUgdGhlIG5vdEFmdGVyIHRpbWUgaW4gDQogIHRoZSBj
ZXJ0aWZpY2F0ZSBvciBoYXZlIGFuIGV4cGlyZWRDZXJ0c09uQ1JMIGV4dGVuc2lvbiB0aGF0IHNw
ZWNpZmllcyBhIHRpbWUgDQogIHRoYXQgaXMgYmVmb3JlIHRoZSBub3RBZnRlciB0aW1lIGluIHRo
ZSBjZXJ0aWZpY2F0ZS4mbmJzcDsgKFRoZSANCiAgZXhwaXJlZENlcnRzT25DUkwgZXh0ZW5zaW9u
IGluZGljYXRlcyB0aGF0IHRoZSBDUkwgaW5jbHVkZXMgcmV2b2NhdGlvbiBzdGF0dXMgDQogIGZv
ciBjZXJ0aWZpY2F0ZXMgdGhhdCBleHBpcmVkIG9uIG9yIGFmdGVyIHRoZSB0aW1lIHNwZWNpZmll
ZCBpbiB0aGUgDQogIGV4dGVuc2lvbi4pJm5ic3A7IElmIG5laXRoZXIgb2YgdGhlc2UgY29uZGl0
aW9ucyBhcmUgc2F0aXNmaWVkLCB0aGVuIHRoZSBDUkwgDQogIG1heSBub3QgaW5jbHVkZSBzdGF0
dXMgaW5mb3JtYXRpb24gZm9yIHRoZSBjZXJ0aWZpY2F0ZS48QlI+PEJSPkNvbnNpZGVyIGEgDQog
IHNjZW5hcmlvIHNpbWlsYXIgdG8gdGhlIG9uZSB5b3UgZGVzY3JpYmUsIGJ1dCBpbiB3aGljaCB0
aGUgQ0EgaXMgbm90IGF0IHRoZSANCiAgZW5kIG9mIGl0cyBsaWZlLiZuYnNwOyBBIHN1YnNjcmli
ZXIgZ2VuZXJhdGVzIGEgc2lnbmF0dXJlIHR3byBkYXlzIGJlZm9yZSBoaXMgDQogIG9yIGhlciBj
ZXJ0aWZpY2F0ZSBleHBpcmVzLCBhIHJlbHlpbmcgcGFydHkgd2lzaGVzIHRvIHZhbGlkYXRlIHRo
aXMgc2lnbmF0dXJlIA0KICAzIGRheXMgYWZ0ZXIgdGhlIGNlcnRpZmljYXRlIGV4cGlyZXMsIGFu
ZCB0aGUgQ0EgaXNzdWVzIENSTHMgb25jZSBhIGRheSB3aXRoIA0KICBuZXh0VXBkYXRlIHRpbWVz
IHRoYXQgYXJlIDI0IGhvdXJzIGFmdGVyIHRoZSB0aGlzVXBkYXRlIHRpbWVzLiZuYnNwOyBJZiB0
aGUgDQogIHJlbHlpbmcgcGFydHkgaW5zaXN0ZWQgb24gdXNpbmcgYSBDUkwgd2l0aCBhIG5leHRV
cGRhdGUgdGltZSB0aGF0IGlzIGFmdGVyIHRoZSANCiAgY3VycmVudCB0aW1lLCB0aGUgb25seSBz
dWNoIENSTCBhdmFpbGFibGUgd291bGQgYmUgb25lIHRoYXQgd2FzIGlzc3VlZCBhZnRlciANCiAg
dGhlIGNlcnRpZmljYXRlIGV4cGlyZWQuJm5ic3A7IFN1Y2ggYSBDUkwgbWF5IG5vdCBwcm92aWRl
IHN0YXR1cyBpbmZvcm1hdGlvbiANCiAgZm9yIHRoZSBjZXJ0aWZpY2F0ZSBzaW5jZSBpdCBoYWQg
YWxyZWFkeSBleHBpcmVkIGJlZm9yZSB0aGUgQ1JMIHdhcyBpc3N1ZWQsIA0KICBhbmQgc28gY2Fu
bm90IGJlIHVzZWQgdG8gdmVyaWZ5IHRoYXQgdGhlIGNlcnRpZmljYXRlIGhhZCBub3QgYmVlbiAN
CiAgcmV2b2tlZC48QlI+PEJSPlNpbWlsYXJseSwgaWYgYSBDQSB0aGF0IHdhcyBnZXR0aW5nIHJl
YWR5IHRvIHNodXQgZG93biBpc3N1ZWQgDQogIGl0cyBsYXN0IENSTCBzaG9ydGx5IGFmdGVyIHRo
ZSBmaW5hbCBjZXJ0aWZpY2F0ZSB0aGF0IGl0IGhhZCBpc3N1ZWQgaGFkIA0KICBleHBpcmVkLCB0
aGlzIENSTCBjb3VsZCBiZSBlbXB0eSBzaW5jZSBhIENSTCBvbmx5IG5lZWRzIHRvIGxpc3QgcmV2
b2tlZCANCiAgY2VydGlmaWNhdGVzIHRoYXQgaGF2ZSBub3QgeWV0IGV4cGlyZWQuJm5ic3A7IFNv
IGFnYWluLCB0aGlzIGxhc3QgQ1JMIGNvdWxkIA0KICBub3QgYmUgdXNlZCB0byBkZXRlcm1pbmUg
d2hldGhlciBhIGNlcnRpZmljYXRlIHdhcyB2YWxpZCBhdCBzb21lIHRpbWUgaW4gdGhlIA0KICBw
YXN0IGJlZm9yZSBpdCBleHBpcmVkLCByZWdhcmRsZXNzIG9mIHRoZSB2YWx1ZSBvZiBuZXh0VXBk
YXRlIGluIHRoZSANCiAgQ1JMLjxCUj48QlI+SW4gZWl0aGVyIGNhc2UsIHRoZSByZWx5aW5nIHBh
cnR5IHdpbGwgbm90IGJlIGFibGUgdG8gb2J0YWluIGEgQ1JMIA0KICB3aXRoIGEgbmV4dFVwYXRl
IHRpbWUgdGhhdCBpcyBhZnRlciB0aGUgY3VycmVudCB0aW1lIHRoYXQgY2FuIGJlIHJlbGllZCB1
cG9uIA0KICB0byBpbmRpY2F0ZSB3aGV0aGVyIHRoZSBjZXJ0aWZpY2F0ZSBoYWQgYmVlbiByZXZv
a2VkIGJlZm9yZSBpdCANCiAgZXhwaXJlZC48QlI+PEJSPk9uIDAyLzI0LzIwMTEgMTE6MjEgQU0s
IFJvYmVydG8gT3Bhem8gd3JvdGU6IA0KICA8QkxPQ0tRVU9URSANCiAgY2l0ZT1taWQ6QUFOTGtU
aW4xa2JHTkEyTGF0bVcrdTh2OHZ6YnlRa1JHcG85TnJtNktOM0pHQG1haWwuZ21haWwuY29tIA0K
ICB0eXBlPSJjaXRlIj4NCiAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj48UFJFIHdyYXA9IiI+
QmVjYXVzZSBubyBjaG9pY2UgaGFzIGFueSBlZmZlY3QgKG90aGVyIHRoYW4gcGVyaGFwcyBjb25m
dXNpbmcgYXBwcyB3aXRoIHVuZXhwZWN0ZWQgbWFnaWMgdmFsdWVzKSwgSSBkb24ndCBhZ3JlZSB0
aGF0IHRoZSBzdGFuZGFyZCBuZWVkcyB0byBzcGVjaWZ5IG9ubHkgb25lLg0KICAgIDwvUFJFPjwv
QkxPQ0tRVU9URT48UFJFIHdyYXA9IiI+Q2hvaWNlcyBoYXMgZWZmZWN0cywgbm8gbWF0dGVyIGlm
IHlvdSBzZWUgaXQgb3Igbm90Lg0KDQpSaWdodCBub3csIGlmIHlvdSBwdXQgYSAyNCBtb3JlIGhv
dXIgdGltZSBpbiBOZXh0IFVwZGF0ZSBvZiB0aGUgbGFzdA0KQ1JMLCB5b3Ugd2lsbCBoYXZlIHBy
b2JsZW1zIHZhbGlkYXRpbmcgc2lnbmF0dXJlcyB0aGFuIHdvcmUgZ2VuZXJhdGVkDQp3aGVuIGNl
cnRpZmljYXRlcyB3ZXJlIHZhbGlkLCBidXQgYXJlIGJlZW4gdmFsaWRhdGVkIGFmdGVyIHRoZSB0
aW1lDQp5b3UgcHV0IG9uIE5leHQgVXBkYXRlIGZpZWxkIG9mIHRoZSBsYXN0IENSTC4NCg0KTWFn
aWMgdmFsdWVzIGNyZWF0ZSBjb25mdXNpb24sIHRoYXQgaXMgd2h5IEkgdGhpbmsgc3RhbmRhcmRz
IHNob3VsZA0KaGF2ZSBhIHJlZmVyZW5jZSBmb3IgdGhpcyBzcGVjaWFsIHNpdHVhdGlvbi4NCg0K
LS0tDQoNCkJlc3QgcmVnYXJkcywNCg0KUm9iZXJ0byBPcGF6bw0KICA8L1BSRT48L0JMT0NLUVVP
VEU+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo=

------=_NextPart_11022513595858161483558_002--




From DPKemp@missi.ncsc.mil  Fri Feb 25 07:49:27 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EF513A69FC for ; Fri, 25 Feb 2011 07:49:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Px+0you3QDdx for ; Fri, 25 Feb 2011 07:49:26 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id 2410A3A69F6 for ; Fri, 25 Feb 2011 07:49:25 -0800 (PST)
Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p1PFoIhl018675 for ; Fri, 25 Feb 2011 10:50:18 -0500 (EST)
Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 25 Feb 2011 10:49:40 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Fri, 25 Feb 2011 10:50:17 -0500
Message-ID: 
In-Reply-To: <20110223032432.6A4F43A6801@core3.amsl.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [pkix] nextUpdate as expiration date (was Re: What should be in "Next Update" field of the last CRL?)
Thread-Index: AcvU+S0ZegLLpR1jTFugpKw9L1JaBAAAmTHA
References: <201102182056.p1IKu8jn025982@fionn.es.net><20110220024150.027033A6CBA@core3.amsl.com><4D63F4D8.7040903@nist.gov><201102221903.p1MJ3cBL009517@spamav2.nist.gov><4D643650.20005@nist.gov> <20110223032432.6A4F43A6801@core3.amsl.com>
From: "Kemp, David P." 
To: "IETF PKIX" 
X-OriginalArrivalTime: 25 Feb 2011 15:49:40.0828 (UTC) FILETIME=[9D2559C0:01CBD503]
Subject: Re: [pkix] nextUpdate as expiration date (was Re: What should be in "Next Update" field of the last CRL?)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Feb 2011 15:49:27 -0000

-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of
Michael StJohns

> It's true that 4.4 has the "local decision to treat
> the CRL as being sufficiently up-to-date", but the
> "should not validate successfully" in the test text
> is going to be or was what gets/got implemented.
> Testable criteria always wins...
>
>    Mike


Agree completely.

Years ago when the Microsoft extension was discussed here, an
alternative proposal (an extension carrying the CA's preferred value of
epsilon, the time after nextUpdate at which a CRL should be considered
expired) was also discussed.  Even in the absence of such an extension,
it would have been nice if the PKI test suite had included an
RP-configurable value of epsilon.  Passing the test would require
applications to support accepting certs while in possession of a CRL
that is "fresh enough" after nextUpdate while rejecting certs if no CRL
is fresh enough.

But that's water under the bridge now, unless the test suite is ever
updated.

Dave


From kent@bbn.com  Mon Feb 28 07:08:54 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60C6E3A6C21 for ; Mon, 28 Feb 2011 07:08:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.37
X-Spam-Level: 
X-Spam-Status: No, score=-101.37 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFj+LhVYCd5E for ; Mon, 28 Feb 2011 07:08:53 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id A34BB3A6A06 for ; Mon, 28 Feb 2011 07:08:53 -0800 (PST)
Received: from dhcp89-089-216.bbn.com ([128.89.89.216]:49153) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pu4jR-000ByK-Lo; Mon, 28 Feb 2011 10:09:53 -0500
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:  <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com>     <438C7354-AC85-4EC6-88AE-3B1E4EE2E4EB@studiocaccia.com>  
Date: Mon, 28 Feb 2011 09:53:47 -0500
To: "Miller, Timothy J." 
From: Stephen Kent 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Feb 2011 15:08:54 -0000

At 8:25 AM -0500 2/24/11, Miller, Timothy J. wrote:
>On Feb 24, 2011, at 4:04 AM, Stephen Kent wrote:
>
>>  If a transaction occurs at time T, and a CRL is issued at T+delta,
>>  and if the CPS for the CA says that it processes all revocation
>>  requests in less than delta
>>  time, one CRL should suffice.  It may not be reasonable for an RP 
>>to wait for
>>  multiple CRL intervals to consider a transaction safe, depdnding on
>>  the frequency of issuance of CRLs, the CPS details, etc.
>
>I think you have to figure in epsilon, which I'll define as "the 
>time the CA CP/CPS defines as the maximum reporting window."  IOW, 
>if the CP says the CA will process revocation requests hourly and 
>publish a CRL immediately *and* requires Subscribers to report lost 
>or suspected compromised key material within 72 hours, then the CRL 
>you want is the CRL published at T+73h rather than T+1h.

good point.

>OTOH, a CP that permits retroactive revocation (revocation request 
>at time T for claimed time T-n) can really mess up your day.

and is a violation of the fundamental notion of CRL semantics :-). yes, there
is a CRL extension to express the notion of "I wish I had revoked 
this previously" but we don't support it in 5280, right?

Steve

From SChokhani@cygnacom.com  Mon Feb 28 07:16:56 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C54E3A69F5 for ; Mon, 28 Feb 2011 07:16:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsK8W1mR4+uW for ; Mon, 28 Feb 2011 07:16:55 -0800 (PST)
Received: from sottexchE2.entrust.com (sottexche2.entrust.com [216.191.252.22]) by core3.amsl.com (Postfix) with ESMTP id A2A313A69F3 for ; Mon, 28 Feb 2011 07:16:55 -0800 (PST)
Received: from scygexch7.cygnacom.com (10.4.60.22) by sottexchE2.entrust.com (216.191.252.22) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 28 Feb 2011 10:17:49 -0500
Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 28 Feb 2011 10:17:55 -0500
From: Santosh Chokhani 
To: Stephen Kent , "Miller, Timothy J." 
Date: Mon, 28 Feb 2011 10:17:54 -0500
Thread-Topic: [pkix] What should be in "Next Update" field of the last CRL?
Thread-Index: AcvXWhNnZfxSK2cSTlaE7kh4yJT0bwAAG+/g
Message-ID: 
References:  <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com>     <438C7354-AC85-4EC6-88AE-3B1E4EE2E4EB@studiocaccia.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Feb 2011 15:16:56 -0000

Steve,

As to your last comment, 5280 Section 5.3.2 does describe invalidity date.

-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Ste=
phen Kent
Sent: Monday, February 28, 2011 9:54 AM
To: Miller, Timothy J.
Cc: IETF PKIX
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?

At 8:25 AM -0500 2/24/11, Miller, Timothy J. wrote:
>On Feb 24, 2011, at 4:04 AM, Stephen Kent wrote:
>
>>  If a transaction occurs at time T, and a CRL is issued at T+delta,
>>  and if the CPS for the CA says that it processes all revocation
>>  requests in less than delta
>>  time, one CRL should suffice.  It may not be reasonable for an RP=20
>>to wait for
>>  multiple CRL intervals to consider a transaction safe, depdnding on
>>  the frequency of issuance of CRLs, the CPS details, etc.
>
>I think you have to figure in epsilon, which I'll define as "the=20
>time the CA CP/CPS defines as the maximum reporting window."  IOW,=20
>if the CP says the CA will process revocation requests hourly and=20
>publish a CRL immediately *and* requires Subscribers to report lost=20
>or suspected compromised key material within 72 hours, then the CRL=20
>you want is the CRL published at T+73h rather than T+1h.

good point.

>OTOH, a CP that permits retroactive revocation (revocation request=20
>at time T for claimed time T-n) can really mess up your day.

and is a violation of the fundamental notion of CRL semantics :-). yes, the=
re
is a CRL extension to express the notion of "I wish I had revoked=20
this previously" but we don't support it in 5280, right?

Steve
_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

From stefan@aaa-sec.com  Mon Feb 28 08:09:42 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58B6C3A6A96 for ; Mon, 28 Feb 2011 08:09:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.32
X-Spam-Level: 
X-Spam-Status: No, score=-102.32 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZ8AcGxabEtK for ; Mon, 28 Feb 2011 08:09:35 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by core3.amsl.com (Postfix) with ESMTP id AA95A3A6BEF for ; Mon, 28 Feb 2011 08:09:35 -0800 (PST)
Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E5D2C28D464 for ; Mon, 28 Feb 2011 17:10:38 +0100 (CET)
Received: (qmail 8002 invoked from network); 28 Feb 2011 16:10:33 -0000
Received: from unknown (HELO [192.168.1.8]) (stefan@fiddler.nu@[85.235.10.93]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 28 Feb 2011 16:10:33 -0000
User-Agent: Microsoft-MacOutlook/14.2.0.101115
Date: Mon, 28 Feb 2011 17:10:29 +0100
From: Stefan Santesson 
To: "Miller, Timothy J." , Roberto Opazo 
Message-ID: 
Thread-Topic: [pkix] What should be in "Next Update" field of the last CRL?
In-Reply-To: <8B079EAE-11C8-4DDC-B631-DE309206511B@mitre.org>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: IETF 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Feb 2011 16:09:42 -0000

On 11-02-24 6:27 PM, "Miller, Timothy J."  wrote:

>On Feb 24, 2011, at 10:21 AM, Roberto Opazo wrote:
>
>> Right now, if you put a 24 more hour time in Next Update of the last
>> CRL, you will have problems validating signatures than wore generated
>> when certificates were valid, but are been validated after the time
>> you put on Next Update field of the last CRL.
>
>Signature validation after certificate expiry is a *special case* that's
>already covered.  You validate using the CRL valid at the *time of
>signing*, not the final CRL from the PKI.
>
>This is why secure time stamping is so important.  Else you introduce the
>question of "what time was it signed?"


This in essence is the correct answer to the original question.
A last CRL issued after certificate expiry is not relevant for validating
that certificate. Unless the CRL includes the expired certificates on CRL
extension (not supported by RFC 5280), the certificate you are looking for
may not be listed in that CRL. Yet it may have been revoked.

/Stefan




From kent@bbn.com  Mon Feb 28 10:35:16 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70A163A6A1B for ; Mon, 28 Feb 2011 10:35:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.394
X-Spam-Level: 
X-Spam-Status: No, score=-102.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uL3LaEcq9L5 for ; Mon, 28 Feb 2011 10:35:15 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id AD0733A6C1D for ; Mon, 28 Feb 2011 10:35:15 -0800 (PST)
Received: from dhcp89-089-216.bbn.com ([128.89.89.216]:49165) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pu7xA-000G16-0g; Mon, 28 Feb 2011 13:36:16 -0500
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:  <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com>     <438C7354-AC85-4EC6-88AE-3B1E4EE2E4EB@studiocaccia.com>    
Date: Mon, 28 Feb 2011 11:43:00 -0500
To: Santosh Chokhani 
From: Stephen Kent 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Feb 2011 18:35:16 -0000

At 10:17 AM -0500 2/28/11, Santosh Chokhani wrote:
>Steve,
>
>As to your last comment, 5280 Section 5.3.2 does describe invalidity date.
>

That's a pity; it's a bad idea and I thought we deprecated it. Guess 
another one slipped through :-).

Steve

From SChokhani@cygnacom.com  Mon Feb 28 10:37:31 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025A23A6A1B for ; Mon, 28 Feb 2011 10:37:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlsKd96H6Xcc for ; Mon, 28 Feb 2011 10:37:30 -0800 (PST)
Received: from sottexchE1.entrust.com (sottexche1.entrust.com [216.191.252.21]) by core3.amsl.com (Postfix) with ESMTP id 039CC3A6C5F for ; Mon, 28 Feb 2011 10:37:29 -0800 (PST)
Received: from scygexch7.cygnacom.com (10.4.60.22) by sottexchE1.entrust.com (216.191.252.21) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 28 Feb 2011 13:38:17 -0500
Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 28 Feb 2011 13:38:27 -0500
From: Santosh Chokhani 
To: Stephen Kent 
Date: Mon, 28 Feb 2011 13:38:26 -0500
Thread-Topic: [pkix] What should be in "Next Update" field of the last CRL?
Thread-Index: AcvXdmSBlhQQ3DInRwmUw0YheIiwnwAAEDGA
Message-ID: 
References:  <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com>     <438C7354-AC85-4EC6-88AE-3B1E4EE2E4EB@studiocaccia.com>     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Feb 2011 18:37:31 -0000

Steve,

Why do you think it is a bad idea?

-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com]=20
Sent: Monday, February 28, 2011 11:43 AM
To: Santosh Chokhani
Cc: Miller, Timothy J.; IETF PKIX
Subject: RE: [pkix] What should be in "Next Update" field of the last CRL?

At 10:17 AM -0500 2/28/11, Santosh Chokhani wrote:
>Steve,
>
>As to your last comment, 5280 Section 5.3.2 does describe invalidity date.
>

That's a pity; it's a bad idea and I thought we deprecated it. Guess=20
another one slipped through :-).

Steve

From kent@bbn.com  Mon Feb 28 13:55:07 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40FA03A6A1E for ; Mon, 28 Feb 2011 13:55:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.462
X-Spam-Level: 
X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qw6LDCj61Fkn for ; Mon, 28 Feb 2011 13:55:06 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 707593A68B1 for ; Mon, 28 Feb 2011 13:55:06 -0800 (PST)
Received: from dhcp89-089-216.bbn.com ([128.89.89.216]:49203) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PuB4Y-00007u-TC; Mon, 28 Feb 2011 16:56:07 -0500
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:  <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com>     <438C7354-AC85-4EC6-88AE-3B1E4EE2E4EB@studiocaccia.com>      
Date: Mon, 28 Feb 2011 16:46:55 -0500
To: Santosh Chokhani 
From: Stephen Kent 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Feb 2011 21:55:07 -0000

At 1:38 PM -0500 2/28/11, Santosh Chokhani wrote:
>Steve,
>
>Why do you think it is a bad idea?
>

because it legitimizes the notion of "whoops, I should have revoked this
earlier, but I'm telling you now," i.e., a CRL "mulligan."

For NR purposes, an RP needs to know by which time it can acquire and 
archive a CRL for future reference, in case of a dispute. As others 
have noted, we did not
make this potentially useful info available in machine readable form, 
i.e., in an extension. So, absent that capability, I think the 
feature in question is of marginal use.

An RP that knows that it needs to wait for a specified interval for 
issuance of a CRL that will, once and for all, allow the RP to act on 
a transaction does not benefit from this "feature"  if the cert in 
question is not revoked.  If the cert is retroactively revoked, but 
after the transaction date, then there is utility. But, it is not 
clear how often this situation arises, and thus whether it is worth 
the added complexity and confusion caused by the feature.

Steve

From ietf@augustcellars.com  Mon Feb 28 15:17:03 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3EA63A6836 for ; Mon, 28 Feb 2011 15:17:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaCKrt4H0l5S for ; Mon, 28 Feb 2011 15:17:03 -0800 (PST)
Received: from new-smtp02.pacifier.net (new-smtp02.pacifier.net [64.255.237.176]) by core3.amsl.com (Postfix) with ESMTP id 040A33A6835 for ; Mon, 28 Feb 2011 15:17:03 -0800 (PST)
Received: from TITUS (static-66-14-119-7.bdsl.verizon.net [66.14.119.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by new-smtp02.pacifier.net (Postfix) with ESMTPSA id 9EA5F2CA24 for ; Mon, 28 Feb 2011 15:18:04 -0800 (PST)
From: "Jim Schaad" 
To: "'IETF PKIX'" 
Date: Mon, 28 Feb 2011 15:39:19 -0800
Message-ID: <000601cbd7a0$ba9e5930$2fdb0b90$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AcvXn/zKoFK68Ud/Qg2yBpvTdiUb6Q==
Content-Language: en-us
Subject: [pkix] Same notAfter date for CA and EE certificate
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Feb 2011 23:17:03 -0000

When reading the thread on how to issue the last CRL, the following text
popped into my head

An entry is added to the CRL as part of the next update
   following notification of revocation.  An entry MUST NOT be removed
   from the CRL until it appears on one regularly scheduled CRL issued
   beyond the revoked certificate's validity period.

The problem is that the MUST NOT cannot be followed if the EE and the CA
have the same expiration date.  Any CRL issued after the expiration date of
the revoked EE certificate would be after the validity period of the CA
certificate and thus not acceptable.

This is a potential issue for certificates that are issued at the last
second, and is more of an issue for historical checking of revocations.
I.e. you cannot do a query for a CRL that was issued delta time after a
signature operation.


Yet one more reason to recommend that a CA stop issuing certificates well
before its own expiration I guess.  Does anybody feel that the text should
be updated since the MUST NOT cannot possibly be satisfied.

Jim



From jun.hu@alcatel-lucent.com  Mon Feb 28 16:09:51 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 460DC3A6CF5 for ; Mon, 28 Feb 2011 16:09:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jl4PouB1v63N for ; Mon, 28 Feb 2011 16:09:48 -0800 (PST)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 841083A6CB1 for ; Mon, 28 Feb 2011 16:09:48 -0800 (PST)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p210AnjH020996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Feb 2011 18:10:49 -0600 (CST)
Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p210Amkv000661 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 28 Feb 2011 18:10:49 -0600
Received: from USNAVSXCHMBSC1.ndc.alcatel-lucent.com ([135.3.39.145]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 28 Feb 2011 18:10:48 -0600
From: "Hu, Jun (Jun)" 
To: "pkix@ietf.org" 
Date: Mon, 28 Feb 2011 18:10:56 -0600
Thread-Topic: CMPv2 CA vendor support
Thread-Index: AcvXpSLtLqVSMvqlSBiCcV3YXGifSA==
Message-ID: <098C866D3766674B95CCF197E1C2489B0B9A9391B2@USNAVSXCHMBSC1.ndc.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_098C866D3766674B95CCF197E1C2489B0B9A9391B2USNAVSXCHMBSC_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Subject: [pkix] CMPv2 CA vendor support
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Mar 2011 00:09:51 -0000

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

Hi,
I plan to implement CMPv2 on my product (which is a PKI end entity), one of=
 the key questions is:
Which CA software vendor already supported CMPv2?
I did googled around, but unable to find a up-to-date list of such vendors.=
..
So I'd like try my luck here, any input will be appreciated.
Thanks in advance!

---------------
Hu Jun




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











Hi,


I plan to implement CMPv2 on my product (which is a PKI end entity), o=
ne of the key questions is:


Which CA software vendor already supported CMPv2? 


I did googled around, but unable to find a up-to-date list of such ven=
dors…  


So I’d like try my luck here, any input will be appreciated.

Thanks in advance!


 



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


Hu Jun





 


 





--_000_098C866D3766674B95CCF197E1C2489B0B9A9391B2USNAVSXCHMBSC_--

From SChokhani@cygnacom.com  Mon Feb 28 16:11:17 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB3A03A6CF7 for ; Mon, 28 Feb 2011 16:11:14 -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=[AWL=0.150,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yYEhYuxfoTk for ; Mon, 28 Feb 2011 16:11:09 -0800 (PST)
Received: from sottexchE2.entrust.com (sottexche2.entrust.com [216.191.252.22]) by core3.amsl.com (Postfix) with ESMTP id 8BC123A6CFB for ; Mon, 28 Feb 2011 16:11:07 -0800 (PST)
Received: from scygexch7.cygnacom.com (10.4.60.22) by sottexchE2.entrust.com (216.191.252.22) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 28 Feb 2011 19:11:58 -0500
Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 28 Feb 2011 19:12:06 -0500
From: Santosh Chokhani 
To: Stephen Kent 
Date: Mon, 28 Feb 2011 19:12:04 -0500
Thread-Topic: [pkix] What should be in "Next Update" field of the last CRL?
Thread-Index: AcvXklFXq87XkAq1R5Cncpd93PaulgAEsC+A
Message-ID: 
References:  <215A0CDE-83E4-4D10-84BD-111BB6DAFD24@vigilsec.com>     <438C7354-AC85-4EC6-88AE-3B1E4EE2E4EB@studiocaccia.com>       
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF PKIX 
Subject: Re: [pkix] What should be in "Next Update" field of the last CRL?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Mar 2011 00:11:18 -0000

Steve,

The pro of having this feature is that archival of CRL provides you with so=
mething useful for investigatory purposes.

-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com]=20
Sent: Monday, February 28, 2011 4:47 PM
To: Santosh Chokhani
Cc: Miller, Timothy J.; IETF PKIX
Subject: RE: [pkix] What should be in "Next Update" field of the last CRL?

At 1:38 PM -0500 2/28/11, Santosh Chokhani wrote:
>Steve,
>
>Why do you think it is a bad idea?
>

because it legitimizes the notion of "whoops, I should have revoked this
earlier, but I'm telling you now," i.e., a CRL "mulligan."

For NR purposes, an RP needs to know by which time it can acquire and=20
archive a CRL for future reference, in case of a dispute. As others=20
have noted, we did not
make this potentially useful info available in machine readable form,=20
i.e., in an extension. So, absent that capability, I think the=20
feature in question is of marginal use.

An RP that knows that it needs to wait for a specified interval for=20
issuance of a CRL that will, once and for all, allow the RP to act on=20
a transaction does not benefit from this "feature"  if the cert in=20
question is not revoked.  If the cert is retroactively revoked, but=20
after the transaction date, then there is utility. But, it is not=20
clear how often this situation arises, and thus whether it is worth=20
the added complexity and confusion caused by the feature.

Steve

From tomasg@primekey.se  Mon Feb 28 23:43:32 2011
Return-Path: 
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EC763A6AC6 for ; Mon, 28 Feb 2011 23:43:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+1HTs+C7yn7 for ; Mon, 28 Feb 2011 23:43:31 -0800 (PST)
Received: from mail.primekey.se (walter.primekey.se [213.179.18.6]) by core3.amsl.com (Postfix) with ESMTP id CE0443A6AF9 for ; Mon, 28 Feb 2011 23:43:30 -0800 (PST)
Received: from [IPv6:::1] (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id C5F2AC3E29 for ; Tue,  1 Mar 2011 08:44:30 +0100 (CET)
Message-ID: <4D6CA3DD.8040202@primekey.se>
Date: Tue, 01 Mar 2011 08:44:29 +0100
From: Tomas Gustavsson 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
To: pkix@ietf.org
References: <098C866D3766674B95CCF197E1C2489B0B9A9391B2@USNAVSXCHMBSC1.ndc.alcatel-lucent.com>
In-Reply-To: <098C866D3766674B95CCF197E1C2489B0B9A9391B2@USNAVSXCHMBSC1.ndc.alcatel-lucent.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [pkix] CMPv2 CA vendor support
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Mar 2011 07:43:32 -0000

EJBCA (http://www.ejbca.org/) supports CMPv2, at least major parts of it 
(the stuff required by current users).

Cheers,
Tomas

On 03/01/2011 01:10 AM, Hu, Jun (Jun) wrote:
> Hi,
> I plan to implement CMPv2 on my product (which is a PKI end entity), one
> of the key questions is:
> Which CA software vendor already supported CMPv2?
> I did googled around, but unable to find a up-to-date list of such vendors…
> So I’d like try my luck here, any input will be appreciated.
> Thanks in advance!
> ---------------
> Hu Jun
>
>
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix